I've removed comp.lang.lisp.franz, since I don't think this discussion is
relevant to Franz Lisp (which has nothing to do with the Lisp product from
Franz, Inc.).
In article <············@no-names.nerdc.ufl.edu> ···@prl.ufl.edu (Kelly Murray) writes:
>I believe that COMPILE takes either a lambda expression '(lambda()..) or a function name,
>and your function argument is neither (it's a function), so the error is appropriate.
Actually, CLtL1 specified that it could only be a lambda expression. In the
dpANS and CLtL2 it is extended to allow a lambda expression or a function.
But many implementations don't implement that feature yet.
In article <··················@telecaster.think.com> Barry Margolin,
······@think.com writes:
> I've removed comp.lang.lisp.franz, since I don't think this discussion
is
> relevant to Franz Lisp (which has nothing to do with the Lisp product
from
> Franz, Inc.).
It's not relevant to MCL either, since (despite of what the original
posting said), MCL will by default compile _all_ functions, independent
of how and where they are defined, so the need to call compile on an
interpreted function simply doesn't exist.
> dpANS and CLtL2 it is extended to allow a lambda expression or a
function.
> But many implementations don't implement that feature yet.
MCL are among these implementations, so in this respect, the thread is
still relevant for MCL, at least for portability reasons (but if you test
the function with compiled-function-p first, the explicit call on compile
in MCL should never occur, except for rare debugging occasions where you
have turned off automatic compiling).
________________________________________________________________________
Espen J. Vestre, ·····@coli.uni-sb.de
Universit�t des Saarlandes,
Computerlinguistik, Geb�ude 17.2
Postfach 1150, tel. +49 (681) 302 4501
D-66041 SAARBR�CKEN, Germany fax. +49 (681) 302 4351