On 4/5/08, Barton Willis <willisb at unk.edu> wrote:
> Oh sure, every little improvement helps. But given this data, why do we
> worry so much about memq? Is memq a big problem for other Lisp versions?
Well, depending on the lisp implementation replacing memq gives me
between 7% and 10% speedup when running the test-suite. I think
this isn't so little.
On 4/5/08, Robert Dodier <robert.dodier at gmail.com> wrote:
>Well, there is a better reason for replacing MEMQ with MEMBER,
>which is that MEMBER is a CL function and MEMQ is not.
>There are many other trivial reimplementations of CL functions
>to which the same applies. Yes, I know that Maxima was
>originally written in a non-CL Lisp. That's fine, however, we
>needn't perpetuate its idiosyncrasies forever. I am hoping that
>we can bring more developers on board, and towards that end,
>it helps to replace non-CL functions by their CL equivalents.
I couldn't say it better!
On 4/5/08, Raymond Toy <toy.raymond at gmail.com> wrote:
>So what? I use (defun square (x) (* x x)) all the time. Does that make
>it bad? MEMQ was perfectly fine. Now when I look at the code I have to
>ask why is it member with :test 'eq and not the default 'eql? What
>makes it special? When MEMQ is used it's pretty clear that's
>what is wanted.
I think asking why it is :test '#eq and not the simple member is
the point and frankly memq isn#t really clearer as long as you
haven't bee brought up on maclisp.
>I don't see MEMQ as an idiosyncrasy. If you want to get rid of those,
>replace the &aux stuff, or ((lambda (foo) ...) args).
That is all pretty good common lisp stuff, but I agree it can be
quite unclear about what is meant and I *do* try to change it to
clearer code over the time, e.g. look at the changes to simp.lisp
where I just changed all the lambda-bindings to let-bindings. One
of the big things on my agenda is to eventually get rid of all the
maclisp argument calling stuff like (arg i) (setarg ..) etc.
Andreas