Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!linac!att!ucbvax!bloom-beacon!dont-send-mail-to-path-lines
From: jonl%kuwait@lucid.COM (Jon L White)
Newsgroups: comp.lang.scheme
Subject: Why memq vs memv vs member, etc.?
Message-ID: <9105160656.AA01319@kuwait>
Date: 16 May 91 06:56:03 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 26

re: Interestingly, the MEMQ provided as an extension by the implementation
    (Lucid) ran at about the same speed as a naively programmed MEMQ.  So
    the presence of a good compiler suggests keeping language constructs
    to a minimum, more a Scheme idea than a Common Lisp idea.

In some later releases of Lucid's lisp, MEMQ is tweaked more than 
simply "a naively programmed MEMQ"; but the benefit over the more
naive verions really isn't very much because, as you point out, the 
"Production Quality" compiler does a pretty good job with the naive 
code [assuming, of course, that you haven't confused the issues of
the two compilers.]

Also, later releases of the "Production Quality" compiler do carry out 
more of the static-analysis to convert MEMBER into MEMQ when possible. 
This is neither a difficult nor a "deep code transformation; instead, it 
is one of style imposed by the end-user community.  With a  language as 
large as Common Lisp, *many* optimizations are possible; the question
remains: which ones are practical, useful, and actually used?

Interestingly, the presence of MEMQ in the Lucid extensions set has 
little if anything at all to do with speed.  The thread of Common Lisp's
history (from PDP10 MacLisp in particular) and the desire not to see 
spurious variants on this common concept were prominent factors.


-- JonL --