Re: guile and elisp

[Mark H Weaver <mhw@netris.org>]

Hello all,

I still haven't found the time to fully evaluate all of these thorny
issues regarding nil, nor to present my perspectives as persuasively
as I'd like to.  Nonetheless I've thought about this issue a great
deal, and here are my thoughts:

First of all, we need to distinguish the equality predicates from the
values themselves.  It is very important to unify the values from lisp
and scheme, but the equality predicates needn't be unified, and imho
shouldn't be.

In my view, the best way to think of "nil" in guile is: "either #f or
'(), but we don't know which one", rather than as a distinct value in
its own right.  Almost every other language treats those two concepts
as distinct, and needs to be able to tell the difference between them
in order to implement its semantics properly.  In other words, every
"nil" is ambiguous from the point of view of other languages.

I think it's very important that we choose a path which can
potentially lead to clean semantics somewhere down the road in a
future guile-emacs universe with finely intermixed scheme and lisp
code (and other languages for that matter).

So what is the path to clean semantics that I'd like to make available
to future generations of guile-emacs?  I'd like it to be possible to
gradually convert instances of nil to either #f or '(), with the goal
of eventually deprecating nil altogether.  We can think of this
process as "annotating" otherwise ambiguous values, so that non-lisp
languages know how to treat them.  To enable that, we must be able
convert any instance of nil to #f or '() without breaking existing
lisp code.  The way to accomplish this is to have different equality
predicates.

The Lisp equality predicates, and the associated hash tables, alists,
etc, should not distinguish boolean-false and end-of-list (and here's
the important point) regardless of where the values being
compared/hashed came from.  The hacks involving intransitive equality
predicates only work when nil is used; they won't work reliably when
there is non-lisp code involved, nor if any of the aforementioned
annotation has been done.

The Scheme equality predicates should probably treat nil as Andy
proposes.  There is no clean way to handle "nil" in a language which
distinguishes the two concepts that lisp conflates, but Andy's
proposal is the best one I've heard.  Other non-lisp languages should
probably use similiar heuristics to deal with nil.

In addition, we might want to consider some kind of hacks to
automatically annotate data in various places.  We could provide
procedures such as "canonicalize-boolean" which converts nil to #f,
and "canonicalize-list" which converts nil to '() and mutates any nil
in the CDRs to '().

These procedures could be safely called on values which are known to
be of the corresponding types, because semantically, they are only
adding information to what would otherwise be an ambiguous value.
This is only possible if Lisp treats #f, '() and nil as the same
value.

What do you think?

    Mark