On Wed, Apr 9, 2008 at 1:25 AM, Andreas Eder <aeder at arcor.de> wrote:
> Why? If you really think about it, then I guess we should
> introduce macros like simp-flaggedp as Stavros suggested:
...
> > (if cdarx
> > (or (eq (car cdarx) 'simp)
> > (member 'simp cdarx :test #'eq)) << Andreas replaced memq by member
> > ;;Function call rarely called, so use a shorter but
> > ;; slower code sequence in this case rather than member
> > ;; which gives an inline loop
...
Andreas, the call to memq there was intentional, and it was also
intentional that it was (memq 'simp cdarx) rather than (memq 'simp
(cdr cdarx)). In GCL at least, member:test compiles to an inline
loop, while in fact it is very rare that that clause will be called,
so it is better to use a shorter code sequence (namely a procedure
call) for better cache performance. Then again, I am not sure how long
the inline loop is vs. the procedure call. I know how to use
disassemble to see the generated C code -- is there some way to see
the generated machine code?
> What is it about memq that makes it so sacred?
> There is that perfectly goo common lisp function member that does
> everything that memq does and more.
For those of us who are used to it, memq is a useful "chunk" (in the
cognitive psychology sense) -- it encapsulates the idea of looking for
an eq-match. I agree that member:test is more general, but that is not
necessarily a good thing, and the visual separation of the member
concept from the test concept is a bad idea -- I'd be much happier
with, say, mem:eq, mem:eql, mem:equal, etc. but of course that is not
CL syntax.
There is nothing sacrosanct about the Common Lisp choices for
functions. In fact, I'd argue that a lot of them (the worst case is
perhaps "loop") are atrocious unLisplike design and should be avoided.
-s