[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