Your concern about the speed of eql vs. string= is rather misdirected. The
two do not do even remotely the same thing.
string= returns true if two stings are the same character for character.
(I'm here ignoring issues with fill-pointers, displaced arrays, etc.)
eql returns true iff the two arguments strings are the same object, i.e.,
if the arguments are eq.
Since constant folding is not required in Common Lisp, it is indeterminate
whether executing the form (eql "foo" "foo") in code returns true or false.
If the two strings are known not to be eq (e.g. if one was just freshly
created by the reader) then (eql "foo" (read)) will _always_ be false.
On Fri, Sep 13, 2013 at 6:40 AM, John Lapeyre <lapeyre.math122a at gmail.com>wrote:
> Hi,
>
> I wonder when it is appropriate to use use cond vs. case,ecase,...
>
> case compares using eql, which is slower than string=
>
> For example:
>
> (I)
>
> (cond ((string= item "string1") forms1)
> ((string= item "string2") forms2)
> ....
>
> (II)
>
> (case item
> ("string1" forms1)
> ("string2" forms2)
> ....
>
> (I) may be faster than (II), but (II) may be
> more clear and less error-prone than (I).
>
> This is a general lisp question, but googling for a bit
> turned up nothing. One could write case-string=.
> My guess is that, in practice, the penalty for
> using eql has not been significant.
>
> In the sbcl source, case, ecase, tyepecase, etc. are
> defined more-or-less like this:
>
> (defmacro case (keyform &body cases)
> (case-body 'case keyform cases t 'eql nil nil nil))
>
> The code to generate the bodies is somewhat involved,
> but is mostly error checking.
>
> > (case-body 'mycase 'keyform '((1 1) (2 2)) t '= nil nil nil)
>
> (LET ((#:G1424768 KEYFORM))
> (DECLARE (IGNORABLE #:G1424768))
> (COND ((= #:G1424768 '1) NIL 1) ((= #:G1424768 '2) NIL 2)))
>
> --John
>
> ______________________________**_________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/**mailman/listinfo/maxima<http://www.math.utexas.edu/mailman/listinfo/maxima>;
>