Re: guile and elisp

[Andy Wingo <wingo@pobox.com>]

Hi Mark,

Thanks for the mail. A couple of brief reactions:

On Sat 27 Mar 2010 14:07, Mark H Weaver <mhw@netris.org> writes:

> 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).

Yes. And I would put this even stronger, that if Scheme and Elisp were
mixed now, that our solution should have clean semantics, without the
need to migrate elisp.

> 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.

Hm, not sure if I follow; and in any case I'm not sure that modifying
existing Elisp code should really be on the table. But your next point
is interesting:

> The [E]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.

Good point, that Scheme's equal? (and assoc, and hash-ref) can treat #f
and nil as distinct, but Elisp's equalp can treat them as equivalent.
Thus we don't introduce any intransitivity into the language.

> 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 '().

We could, but I'm not sure I see the need: if Scheme's equal? treats
nil, #f, and '() as distinct, why bother? (As in: what inconsistencies
or problems does this approach create?)

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.

Thoughts?

Andy
-- 
http://wingolog.org/