Re: Implementing :TEMPORARY hash tables at the Lisp level?

[Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>]

>     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.
And, if

   (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
FUNCTION.

I suppose this would be harder to describe, though.

-- Jeff