Re: compiling interpreted functions

[bill@cambridge.apple.com (Bill St. Clair)]

At 10:01 AM 10/11/93 +0000, Espen J. Vestre wrote:
>In article <9310072041.AA15230@telecaster.think.com> Barry Margolin,
>barmar@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).

CLtL2 says (p. 677), "The consequences of calling COMPILE on a function
that is already compiled are unspecified."

The draft ANSI standard says, "If the definition is already a compiled
function, COPILE either produces that function itself (i.e. is an identity
operation) or an equivalent function.

Hence, MCL is definitely not in conformance to the ANSI standard.
"The consequences are unspecified" means that it must be "harmless",
but portable programs cannot depend on the result. I don't think
that signalling an error is considered "harmless", but I can't find
a definition of that term anywhere.

In any case, I consider this an MCL bug, and have fixed it in my
development sources.