[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issue: TAILP-NIL (Version 5)

    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.

    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.