[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emacs-lisp/cl.el (pushnew): void-variable x

From: Miles Bader
Subject: Re: emacs-lisp/cl.el (pushnew): void-variable x
Date: Thu, 21 Sep 2006 18:37:48 +0900

address@hidden (Kim F. Storm) writes:
>> A change to `pushnew' is not necessary anyway: for simple cases (a value
>> with no side-effects), the change to `member*' is enough to do the job,
>> so `pushnew' itself can just be reverted to what it was before Richard's
>> change (just calling adjoin).
> IIUC, the rationale for Richard's original change was to allow a
> program using pushnew to be evalled in non-compiled form without
> loading cl (because it needs the _function_ adjoin defined there).

That doesn't make any sense -- pushnew is defined in cl.el, so if
non-compiled code is using it, it must have already loaded cl.el anyway
(so it doesn't matter what cl-stuff it uses).

IIRC, the reason for Richard's change was simply to make pushnew with
default arguments (no :test keyword arg) usable in compiled code that
only does (eval-when-compile (require 'cl)) -- before that wasn't the
case because the default predicate for pushnew/adjoin/member* was `eql',
which prevented the cl compile-time optimizations from removing calls to

My change to the member* (and adjoin) _compiler-macros_, and the addition
of memql, fixes that very common case, allowing the cl compiler macros
to do their job and get rid of runtime calls to cl functions in most cases.

>> [Non-simple cases can easily be handled as well by making the `adjoin'
>> compiler-macro bind the value when it's non-simple.]
> It doesn't help in the non-compiled case.

As I mention above, it doesn't matter in the non-compiled case (pushnew
is a macro in cl.el, so if non-compiled code is using pushnew, it must
have loaded cl.el anyway).


Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]