[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Implementing :TEMPORARY hash tables at the Lisp level?
- To: "David A. Moon" <Moon@scrc-stony-brook.arpa>, Jon L White <jonl%lucid.com@NSS.Cs.Ucl.AC.UK>
- Subject: Re: Implementing :TEMPORARY hash tables at the Lisp level?
- From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
- Date: Thu, 15 Sep 88 19:42:15 BST
- Cc: firstname.lastname@example.org, SEB1525 <@sail.stanford.edu:SEB1525@draper.com>, email@example.com, jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
- In-reply-to: David A. Moon's message of Thu, 15 Sep 88 13:36 EDT
> 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
> One could see how to add hair to a compiler to avoid these situations, but
> it may be infeasible in an interpreter.
Modulo certain efficiency considerations, as in Interlisp-10, I do not
think there is any particular difficulty in having (eq #'f #'f) return
true. Presumably, interpreters do not have any trouble with
(let ((f #'(lambda ...)))
(eq f f)) ==> t
Are there optimization considerations, as there are for numbers and
EQ, that argue against having EQ be well-defined to the extent of
being able to make comparisons such as (eq x #'eq) [which I think
is all that's needed for make-hash-table]?