From: Michael Park
Subject: (compiled-function-p #'(lambda (x) (+ x x)))
Date: 
Message-ID: <ff20888b.0305192110.6654c1d9@posting.google.com>
(compiled-function-p #'(lambda (x) (+ x x)))  => T

#'(lambda (x) (+ x x))  => #<Interpreted Function ...

Why is it compiled in the first case? It makes no sense.

From: Juanjo
Subject: Re: (compiled-function-p #'(lambda (x) (+ x x)))
Date: 
Message-ID: <ab4b7d4.0305200059.5640ba24@posting.google.com>
···········@whoever.com (Michael Park) wrote in message news:<····························@posting.google.com>...
> (compiled-function-p #'(lambda (x) (+ x x)))  => T
> #'(lambda (x) (+ x x))  => #<Interpreted Function ...
> Why is it compiled in the first case? It makes no sense.

ECL had the same "bug", so to say. The problem is that according to
ANSI a compiled function is one in which all macro have been expanded,
there are no load-time values to be evaluated, etc. An interpreted
function is a function that still has to be "processed" somehow. For
instance, EcoLisp used to keep functions as lists, and every time that
function had to be evaluated, macros needed to be expanded.

ECL is a descendent from EcoLisp which now bytecompiles everything.
Therefore, all function objects should return T with
COMPILED-FUNCTION-P. However, even between function objects we have a
distinction between functions which are in machine code and functions
which have to be "interpreted". I believe CMUCL does the same
distinction. This is the reason for printing these functions as
#<interpreted-function (for ECL) or #<Interpreted Function for
(CMUCL).

Juanjo
From: Mario S. Mommer
Subject: Re: (compiled-function-p #'(lambda (x) (+ x x)))
Date: 
Message-ID: <fzk7cmt7mz.fsf@cupid.igpm.rwth-aachen.de>
···········@whoever.com (Michael Park) writes:
> (compiled-function-p #'(lambda (x) (+ x x)))  => T
> 
> #'(lambda (x) (+ x x))  => #<Interpreted Function ...
> 
> Why is it compiled in the first case? It makes no sense.

What implementation are you using? It looks like a bug.
From: Dave Seaman
Subject: Re: (compiled-function-p #'(lambda (x) (+ x x)))
Date: 
Message-ID: <bada3f$shm$2@mozo.cc.purdue.edu>
On 19 May 2003 22:10:20 -0700, Michael Park wrote:
> (compiled-function-p #'(lambda (x) (+ x x)))  => T

> #'(lambda (x) (+ x x))  => #<Interpreted Function ...

> Why is it compiled in the first case? It makes no sense.

Some implementations of lisp have incremental compilation.  That means
expressions are compiled on the spot, as soon as you type them.

Here is a dialog from MCL (Macintosh Common Lisp):

? (compiled-function-p #'(lambda (x) (+ x x)))
T
? #'(lambda (x) (+ x x))
#<Anonymous Function #xABBB96>
? (compiled-function-p *)
T



-- 
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/index.cfm?action=book&bookid=228>
From: Eric Marsden
Subject: Re: (compiled-function-p #'(lambda (x) (+ x x)))
Date: 
Message-ID: <wzi3cj9py1y.fsf@melbourne.laas.fr>
>>>>> "mp" == Michael Park <···········@whoever.com> writes:

  mp> (compiled-function-p #'(lambda (x) (+ x x)))  => T
  mp> #'(lambda (x) (+ x x))  => #<Interpreted Function ...
  mp> 
  mp> Why is it compiled in the first case? It makes no sense.

it looks like you are using CMUCL, which says that all functions are
compiled, even interpreted functions. This is incorrect, because
interpreted functions don't respect the constraints of minimal
compilation (CLtS Section 3.2.2.2); for instance calls to a compiler
macro are expanded lazily at evaluation time, not when the function is
defined.

In the rare cases where you need to distinguish between interpreted
and compiled functions at runtime, you can work around this bug in
CMUCL by using TYPE-OF:

,----
| USER> (type-of (lambda (x) (+ x x)))
| eval:interpreted-function
| USER> (type-of (compile nil (lambda (x) (+ x x))))
| (function (t) number)
`----

-- 
Eric Marsden                          <URL:http://www.laas.fr/~emarsden/>