Re: guile and emacs and elisp, oh my!

[Thomas Lord]

On Sat, 2010-04-24 at 13:05 +0200, Andy Wingo wrote:
> Hi Tom,

Hello.

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

Glad to help.



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

An example is easier with elisp EQUAL and Scheme EQUAL?:
Because they give different results:

   (equal? #nil #f) => #f
   (equal nil f) => t

the two languages can not even reliably agree
when two keys in an equality-based association
are the same.


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

   (symbolp nil) =>  t
   (symbolp t) => t

Per old lisp tradition, they are symbols bound permanently
to themselves:

   (symbol-value nil) => nil
   (symbol-value t) => t
   (let ((t 3)) t) =>  ERROR: attempt to set a constant 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.

And I guess you will have to do the same for #t?

Suppose that Scheme's STRING->SYMBOL is made available
(directly or indirectly) to the Emacs lisp side.  Then:

    ,L elisp
    ;; for some symbol bound to sym:
    ;; 
    (eq sym (string->symbol (symbol-name sym)))
    => t     in all cases where sym is not nil or t
    => nil   otherwise

If Emacs lisp's INTERN is made available directly or
indirectly to Scheme:

    (eq? sym (intern (symbol->string sym)))
    => #t   in all cases where sym is not 'nil or 't
    => #f   otherwise

I find it hard to think through what code that might break
or what kinds of things it will make hard to write.  I find
strange, random exceptions to simple rules hard to think 
through in general.   That's why I describe the result here
as the kind of programming environment that nobody would
ever design on purpose - an environment that seems to have features
whose sole (apparent) purpose is to make programming harder.

Is upwards compatibility with elisp really worth that much?



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

Back in yesteryear, I was pretty optimistic about
joining Scheme and Emacs lisp, too.

Things were different, back then.  R5 was not yet
released.   R4RS and IEEE were the latest standards
and were the *first* to require that Scheme '() not 
be a false value.

Indeed, R3RS *required* '() to be false and stated:

    (eqv? '() #f) => *unspecified*

So, at first, we thought to just diverge from that
newfangled R4RS noise and Guile would be a Scheme
in which:

    (eq? '() #f) => #t

Additionally, all symbols would have a dynamic
binding slot (in effect, every symbol would be
a "fluid" in today's Guile terminology).

I don't recall that we had clearly thought through
the problem of '() (elisp's nil) not being a symbol.

Pressure grew to distinguish '() and #f and at 
some point, a proposal for #nil (very much like the
one you have now) was put forward.   At first I
thought that might work but it nagged at me.  The more
I thought about it, the less I believed that it or any
other "solution" could work.




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

So much for re-using code written for other 
Scheme implementations.   And, again: Scheme is 
already a touch suspect for having three distinct
equality predicates instead of the more customary
two.  Now you propose to add a fourth.

It's also unfortunate that this will make a mess
out of using the FFI.   When an extension function
written in C uses an equality predicate or a 
checks to see if something is a symbol: what should
be its policy - Scheme rules or Emacs lisp rules or
some kind of dynamically configrable option?


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

Perhaps.  But that "wealth" can be preserved in other ways.
For example, by writing tools that assist in the semi-manual
translation of Emacs lisp to Scheme.



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

Sure.  And I'm not one to stop you from following your 
dreams.

I think that there are some objective things to contemplate:
Disjointness of types, truth and falsity, uniformly represented lists, 
and universal equivalence and structural equivalence predicates
are *central* to many (perhaps most) idioms of lisp programming,
in every dialect, for as long as there has been lisp.  Those
are the basic aspects of values in general.

>From first principles you can correctly deduce that Emacs lisp
and Scheme must always disagree about disjointedness, the
representation of lists, equivalence, and structural equivalence.
It is trivial to get them to agree about falsity by introducing
#nil, but doing so makes the disjointedness, list representation,
and equivalence predicates even more problematic.   It's a "now you
have two problems" kind of situation.

>From historic reality you can also see that the decision to 
add #nil *greatly limits the prospects for Guile and Emacs in
the future*.   In particular, there will be a long-term 
barrier on re-using any third party Scheme code, FFI-extension
to Scheme, or new and better Scheme implementation.   The 
proposal here is to exit the isolated and lonely world of 
Emacs Lisp and start afresh in an isolated and lonely world
of Guile+Emacs Lisp.

You can have your dreams and, heck, you might be right.
After all, the problems of three little lisp values 
don't amount to a hill of beans in this crazy world.
But as for me, I'm not telling you get on that plane.
I don't think the Scheme Underground resistance movement
benefits.  And I'm pretty sure you're not really in love
with the whole plan. If you take that plane, if you ask me, one day
you'll regret it.  Maybe not today, maybe not tomorrow, but
soon and for the rest of your life.



> Anyway, rambling here at the end.

It's good to talk it through.

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

I suppose we shall.

-t



> Happy hacking,
> 
> Andy