Re: guile and elisp

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

(BTW, I'm deliberately writing "lisp" instead of "elisp" because these
discussions should be relevant to any lisp dialect that uses nil for
both false and eol, and in the future guile might support other lisps).

On Sat, Mar 27, 2010 at 05:54:24PM +0100, Andy Wingo wrote:
> I'm not sure (I keep saying "not sure", and I'm really not :) that
> *value* or *identity* is the way to solve this problem. To me the
> question is more of *property* -- is this value false, is it equal? to
> another, is it a boolean, etc.

Well, if we can assume that all non-lisp code in the guile system will
robustly handle nil by using the appropriate predicates, then yes,
that's a fine solution with clear semantics.  I just don't think
we can safely assume that.

Someday there may be significant libraries and other complex software
developed elsewhere being used in guile-emacs.  Most code outside of
the lisp world has never had to cope with an ambiguous "maybe boolean
false or maybe the empty list" value.  When that code meets the lisp
world, I guarantee you'll start seeing obscure bugs crop up.  The
system as a whole will not be as robust as it could be.

A lot of code outside of lisp uses equality to test boolean values.
If nil is distinct from #f, then that code will fail.

A lot of code assumes that if a value is boolean, then it cannot be a
list, and vice versa.

Some code looks up booleans and/or lists in hash tables or other
structures.  That code won't deal gracefully with list structures
containing nil.

Some object-oriented languages may overload an operation depending on
whether a parameter is a boolean or a list.  I don't see how such code
can deal with nil gracefully without being significantly rewritten.

Using your proposed intransitive equality predicates would handle many
of the common cases properly, but not all of them.

I see no way to handle these kinds of problems robustly without
gradually deprecating nil.  My proposal allows instances of nil to be
incrementally "annotated" by changing them to #f or '().

Lisp code treats all three values the same, so from lisp's point of
view these annotations are harmless and effectively no-ops.  But each
annotation has the potential to prevent some obscure nil-related bugs
from breaking non-lisp code which wasn't designed to handle nil.

These annotations could be done in response to the discovery of a
nil-related bug, or they could be done preemptively to reduce the
probability of such bugs before they occur.

They could be done either in the lisp sources, or elsewhere using my
proposed "canonicalize-*" procedures, perhaps where values are passed
from lisp to non-lisp code, or upon entry to code which is known not
to handle nil gracefully.

So, I guess I should have been more broad when I said that I want
"clear semantics".  More than that, I want to be able to robustly mix
lisp code with other code that was never designed to interface well
with lisp, with a minimum of obscure bugs cropping up.  The gradual
deprecation of nil (or at least the option of eventually doing so) is
the only path I see to toward that end.

   Regards,
     Mark