Implementing :TEMPORARY hash tables at the Lisp level?

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Wed, 14 Sep 88 17:49:57 PDT
    From: Jon L White <jonl@lucid.com>

    My first thought would be like yours -- that #'<symbol> in the absence of 
    lexical overrides return a unique pointer for as long as the function 
    remains the same.  Still, we would have to hear from the vendors for which 
    this would be an incompatible change.  

I know of at least one case in Symbolics Common Lisp where (eq #'foo #'foo)
returns false.  However, foo was defined with a non-Common-Lisp construct
(defun-in-flavor).  It wouldn't surprise me to learn that there are
implementations where the same thing happens when foo was defined with
FLET, in cases where the surrounding lexical environment structure is
sufficiently complex.  As you pointed out, the same thing can happen with
functions defined globally, in the implementation technique used in
Interlisp-10.

One could see how to add hair to a compiler to avoid these situations, but
it may be infeasible in an interpreter.

I remember a discussion among the Scheme folks on these issues a few
years ago, which I think came to the conclusion that EQ cannot be
well-defined on closures.  Two closures that look different, but can be
proved equivalent by an optimizing compiler, might end up EQ, and two
closures of the same function in what the user imagines to be the same
environment might end up distinct due to an optimizing compiler (stack
allocation) or a non-optimizing interpreter or compiler.

However, no one said that MAKE-HASH-TABLE's association from the :TEST
argument to the type of hashing has to be done with EQ.  One approach
is to get the function's name and then look up the name in a table.
Another is to embed the type of hashing in the test function's
definition, using a declaration that causes the compiler to attach
data to the compiled code.  Both of these rely on the fact that, at
least for the builtin hash functions, the type of hashing depends only
on the function and not on the environment in which it is enclosed.

					   It wouldn't be outlandish to let
    this fall into the realm of EQL -- just at Interlisp used EQP -- and extend
    EQL to cover "function" objects as well as numbers and characters.

I would resist this, as our hardware implementation of EQL would not be
capable of this extension.  Aside from that somewhat parochial viewpoint,
if equivalence of closures is something different from EQ, I have trouble
figuring out what it would be defined as that would have any meaning
that was both portable and effectively computable.