Re: guile and emacs and elisp, oh my!

[Andy Wingo]

Hi Tom,

Thanks for your mail, it brought up some things I hadn't thought about.

On Sat 24 Apr 2010 00:43, Thomas Lord <address@hidden> writes:

> Sure, Schemers ought to be encouraged to write
> "(null? x)" rather than "(eq? x '())" but ... 
> what about "(eq? x y)"?  

To me, `(null? x)' checks nullity. `(eq? x '())' is ambiguous -- it
could be a check for nullity, or it could be a check for identity. `(eq?
x y)' to me is unambiguous though, it is a check for identity.

I would be interested to know if you had a case in mind in which the
introduction of nil to Scheme let to incorrect results via `(eq? x y)',
beyond those documented in Nil.html.

> More damingly, perhaps, what distinction does 
> Guile plan between the Scheme symbol, "'nil", and
> Emacs the Emacs lisp symbol, "nil"?  Do emacs
> lisp and Guile not even agree on what is and what 
> is not a symbol?

Irritating! I did not even realize that nil was a symbol.

Given that there appear to be few Elisp primitives that operate on
symbols, I imagine the way this will go will be for nil to not be a
symbol to Scheme, but we'll add some shims to elisp to have it be a
symbol, and have the elisp reader read 'nil as nil. There are only about
50 instances of 'nil in the emacs source, and some of them are ''nil, so
hopefully this will not cause too much of a problem.

To my (naively optimistic?) tastes, we're not at chaos yet; but this is
certainly a step in that direction.

> And: since Emacs lisp and Guile can't agree about
> equality (whichever flavor) - how do I write a 
> hash table library useful to both environments?

Scheme will probably get some new operators out of all of this: nil-car,
nil-cdr, nil-equal?, nil-hash, nil-assoc, etc. By default, a hash table
implemented in Scheme would treat nil and '() as distinct, though you
could implement one with nil-hash and nil-assoc and you get an
elisp-style hash table. Elisp hash tables use Elisp hash and assoc,
which are bound to nil-hash and nil-assoc or their equivalents.

> If, absent the historic liabilities, someone proposed
> a programming environment with multiple syntaxes, sure,
> but all sharing a common data representation - with
> (), #f, and Emacs lisp nil .... wouldn't you think they
> were kind of insane?   The multiple syntaxes part - fine.
> But the triad of (), #f, and nil?  It would seem, in my view, 
> to be a (mis-)feature designed mainly to make programming
> in that environment harder.

I am inclined to agree, though I would probably state things
differently: the Elisp code that is out there is liability, yes, but
wealth also.

As you note, we're always making these economic decisions, and with
regards to unknown (and often unquantifiable) costs and benefits -- well
you never really know until you step into that unknown, right? (And the
reasons that lead one to make those steps often go by slippery names
like "faith" or "instinct" or such things.)

Anyway, rambling here at the end. I respect your desire for a new lovely
Scheme Emacs; but I think I'm going to try for a future world that
includes Elisp and Elisp programmers. Maybe over time it all stays in
Elisp; that's fine. Maybe people find they like Scheme better, and
incrementally rewrite things in that language. That's cool too, and
personally I hope things go that way. But we'll see!

Happy hacking,

Andy
-- 
http://wingolog.org/