Implementing :TEMPORARY hash tables at the Lisp level?

[Jon L White <jonl@lucid.com>]

[I've read ahead to look at other comments on this issue, and will try
to coordinate my comments on several such messages.]

First, I think someone already pointed out that CASE is not the proper 
common lisp construct to use since:
	   (case x ((#'eq #'equal) ...))
is simply equivalent to:
	   (case x (((function eq) (function equal)) ...))
and one definitely doesn't intend to compare the value  of x with some 
"internal" list (function eq)!   [Query: should an implementation give 
you a warning msg when finding such a situation in CASE?]


re: The internal implementation of a Common Lisp need not be written using
    portable constructs.

Right.  In fact, Interlisp did "cons" up a new value each time you
called the equivalent of SYMBOL-FUNCTION, because the function cell
did _not_ contain a Lisp object, but something more hardware and/or
firmware specific.  Of course, access and update of that cell is via a 
functional interface, which "mediates" between the expected type of
value and that actually stored in memory.  Thus in that implmentation:
		(eq #'eq #'eq)
would be guaranteed not to work the way this discussion has been assuming 
it to work.  Consequently, Interlisp had the function EQP -- somewhat a 
forerunner of the Common Lisp EQL -- which would tell you when two 
different "compiled code pointers" were in fact pointing to the same piece
of compiled code, but would simply be EQ on most other cases.  [I don't
know how XAIS/ENVOS's Common Lisp product handles this matter; probably 
something less tied to the tricks "firmware".]


re: I suspect that in most CL implementations, #'<symbol> always returns the
    same thing for symbols that do not have a lexical function binding, so
    the above code would work.  

Sigh, I wish you were right.  I know of at least one implmenetation where
(function <symbol>) simply acts like (quote <symbol>); although this
"always returns the same thing", it definitely isn't what you expect
[i.e., it would not be FUNCTIONP under the revised x3j13 sense.]
I think it would be a good idea for an X3J13 "Cleanup" to address this. 
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.  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.



-- JonL --