[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: guile and elisp
From: |
Andy Wingo |
Subject: |
Re: guile and elisp |
Date: |
Sat, 27 Mar 2010 17:54:24 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) |
Hi Mark,
Thanks for the mail. A couple of brief reactions:
On Sat 27 Mar 2010 14:07, Mark H Weaver <address@hidden> 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/