Re: Emacs Lisp's future

[Taylan Ulrich Bayirli/Kammer]

David Kastrup <address@hidden> writes:

> Of course, that glosses over the fact that the end of a list may well
> be implicitly checked for by using sentinels and other quite
> legitimate programming practices.
>
> For example, two proper lists generally have a common tail, even if
> that tail is only '(), and finding that tail is done by trimming the
> longer list to the size of the shorter one and then cdr-ing the
> remaining lists in synch until arriving at a matching value.
>
> Using "equal" for that comparison is not an option, and using "eq" is
> no longer guaranteed to terminate without error.  The solution is to
> declare the algorithm not well-written.

So the problem is that two same-length lists are normally guaranteed to
have an `eq' element at some point in Lisps, and Guile breaks this
guarantee.  That seems like a legitimate concern; thanks for bringing it
up.

Fortunately, making use of this should be relatively rare, and the fix
is relatively simple too.

(In the algorithm you mentioned, the naive solution is to do an
additional (and (null list1-rest) (null list2-rest)) at each cdr instead
of only an (eq list1-rest list2-rest), and the smart solution to
canonicalize the null objects at the ends during the length
calculation/truncation which will inevitably visit the ends of both
lists, if the algorithm needs to be as efficient as possible.)

Considering also that the issue will only arise during inter-operation
of the languages, which should be limited to rare situations like
internal Scheme code raising an error that's handled in Elisp, the
combined chance of this issue ever hitting a pure Elisp user seems
minuscule.

All in all, it's not a concern for Emacs users who don't mess with
Scheme, and quite a small one for those who do.

Taylan