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

Re: compiled-function-p



] Date: Sun, 13 Dec 87 03:03:21 est
] From: eliot < (eliot handelman)eliot%edu.princeton.winnie@edu.princeton>

] > (defun this-will-not-work nil nil)
] THIS-WILL-NOT-WORK
] 
] > (compile 'this-will-not-work)
] [... it gets compiled ''']
] 
] (compiled-function-p 'this-will-not-work)
] NIL

It turns out that KCL is right!  THIS-WILL-NOT-WORK is a symbol, not
a compiled function object; (SYMBOL-FUNCTION 'THIS-WILL-NOT-WORK) is
the compiled function object.  Therefore,

	(compiled-function-p #'this-will-not-work) => T

A potential source of confusion here is that FUNCTIONP will say a
symbol is a function even though the actual function object is the
SYMBOl-VALUE.  Actually, Common Lisp, unlike Scheme, doesn't have
a separate function object type; symbols and lists beginning with
LAMBDA are counted as functions, and implementations can represent
closures, say, as lists beginning with CLOSURE.  Compiled-function
is (or at least can be) a real object type.

] Somebody might also tell me what is going wrong with dribble - seems to have
] a newline problem. Also read-line doesn't work at all - just returns an
] empty string. This is on 4.3 Unix.

KCL seems to have a general problem with the newlines after delimited
s-expressions.  READ-LINE may well work if you first clear out any
leftover newlines.  CLEAR-INPUT is (or used to be) useless here; you
had to write a READ-CHAR loop.

Jeff Dalton,                      JANET: J.Dalton@uk.ac.ed             
AI Applications Institute,        ARPA:  J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University.             UUCP:  ...!ukc!ed.ac.uk!J.Dalton