[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: TAILP-NIL (Version 5)
- To: Jon L White <jonl@lucid.com>
- Subject: Issue: TAILP-NIL (Version 5)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 14 Dec 88 13:35 EST
- Cc: barmar@Think.COM, cl-cleanup@sail.stanford.edu, masinter.pa@xerox.com
- In-reply-to: <8812140805.AA12044@bhopal>
- Line-fold: No
Date: Wed, 14 Dec 88 00:05:20 PST
From: Jon L White <jonl@lucid.com>
re: . . . (EQ is only
in Common Lisp as a concession to implementors who haven't figured out
how to implement EQL efficiently (it isn't hard), or hadn't figured it
out yet in 1984).
Hmmm, I may remember something similar said in the late 1960's or very
early 1970's about why EQ was still in the language -- but back then,
the contender was EQUAL rather than EQL. Plus ca change . . . maybe
there is a more fundamental reason than incompotent implementors.
Just to clarify what I meant, since as usual I didn't express myself
very clearly in the initial message: I think of EQL as the
implementation-independent version of EQ. The behavior of EQ is
different from EQL only in implementation-dependent situations that
portable programs are not supposed to depend on. This is very different
from EQUAL, which is a semantically different operation in a way that
is meaningful across all implementations.
Like,
maybe some folks implement their memory management systems in Lisp, and
are reluctant to give up all user-accessibility to this historic, object
identity function?
Could be. But I claim that EQ has no portable meaning distinct from EQL,
only an implementation-dependent meaning, so that indeed we should be speaking
in terms of "reluctance" rather than "semantics".
Anyway, that's more than enough time on that side-issue.