Hi Mark, Thanks for the mail. A couple of brief reactions:
On Sat 27 Mar 2010 14:07, Mark H Weaver <[email protected]> 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/
