[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Implementing :TEMPORARY hash tables at the Lisp level?
> Date: Wed, 7 Sep 88 18:26:30 BST
> From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
> Functions can be compared with EQ, EQL, and EQUAL,
> Function objects can, but not the results of invocations of the FUNCTION
> special form. On p.89, CLtL says, "a perfectly valid implementation
> might simply cause every distinct evaluation of a FUNCTION form to
> produce a new closure object not EQ to any other."
Well, (FUNCTION F) where there is no local function binding of F is
supposedly equivalent to (SYMBOL-FUNCTION 'F); and this is what I had
in mind when comparing with #'EQ.
So a question is: can SYMBOL-FUNCTION return a new object each time?
If so, I think this should be changed since it is clearly pointless.
(let ((f #'(lambda () 1))) (eq f f)) => t
[and it had better], then
(flet ((f () 1)) (eq #'f #'f)) should => t
[though I agree that CLtL does not say it will or should => T].
> The precise behavior
> of the FUNCTION special form in this regard will frequently depend on
> whether the code is compiled or interpreted and whether the argument is
> a global function name, a local function name, or a lambda expression.
> For example, in Symbolics Common Lisp the function
> (defun fn-eq-test (a)
> (flet ((internal () (cons a a)))
> (eq #'internal #'internal)))
> returns NIL when interpreted, but T when compiled. The interpreter
> definition of FUNCTION simply makes a new lexical closure, while the
> compiler collapses equivalent lexical closures.
Because of the LET analogy above, I do not see any need to have FUNCTION
make a new closure when its argument is a symbol. When the argument is
a LAMBDA-expression, then "is it really the same" becomes more difficult,
and I can see an interpreter (or compiler) taking a shortcut.
That is: FLET should be the one taking the shortcut for symbols, not
I suppose this would be harder to describe, though.