I think that memq is hardly a documentation problem.
Far more of a problem is a situation is welcoming any novice to make their
first notion of an esthetic change to working programs permanent, when there
is disagreement about their advisability, and in fact better alternatives
are offered.
Grave problems, which we are still sorting out 20+ years later, were
introduced in just such a situation, where the novice was an MIT undergrad
who decided he knew so much about programming languages, types, compiling,
and optimization, that he rewrote translate() and compile() and introduced
an extra layer of abstraction (actually, complexity and bugs) into the
macsyma-to-lisp communication.
I'm not sure how to make everyone (else) happy, but I would like memq
defined as a macro, and its use encouraged.
RJF
> -----Original Message-----
> From: maxima-bounces at math.utexas.edu
> [mailto:maxima-bounces at math.utexas.edu] On Behalf Of Robert Dodier
> Sent: Saturday, April 12, 2008 9:57 AM
> To: fateman at EECS.Berkeley.EDU
> Cc: Andreas Eder; maxima at math.utexas.edu
> Subject: Re: [Maxima] More on memq
>
> On 4/12/08, Richard Fateman <fateman at cs.berkeley.edu> wrote:
>
> > If you replace memq by the appropriate macro expansion, my
> guess is it would
> > be FASTER than member by the same or a larger factor.
>
> A much better reason for replacing archaisms with CL is that
> outsiders (i.e., anyone who has spent less than a couple of
> years on the project) will understand the code better.
> Execution time does matter but it is a secondary or tertiary
> consideration in this case.
>
> FWIW
>
> Robert Dodier
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>