Re: guile and emacs and elisp, oh my!

[Thomas Lord]

So, because this thread is a large confusing 
tangle of issues I'll mention that *this* message
is about the treatment of elisp nil vs. Scheme () and #f
in Guile.

Andy, thanks.  I do think that what you have there in
Guile's elisp integration plans is
plausibly "the best that can be done".  If the 
requirement is to have elisp and Scheme unified
within a single programming environment, I doubt anyone
could do much better.  This is not to say I think
the result is particularly satisfying.

And, I don't want to dwell on the topic.   Last time I
mentioned something off-hand it led to several 10s of 
messages of dubious appropriateness for this list (and 
who the hell am I to comment on this list at all).
But as XCDD semi-famously put it: "There's something 
*wrong* on the Internet," so I'll briefly say my piece
here and hope not to be too disruptive.  (Just disruptive
enough? :-)   (Everyone should please think thrice 
before replying and remember that this subthread
ultimately is likely to have very little impact or
importance so it isn't essential to comment here unless
you really, really have something useful to say.)

The reason I asked about what you had in mind for Guile
re nil v. () v. #f is because I think the issue is a 
quite fine, compact illustration of what I understand
to be the root causes of what Tom Tromey described
as the "chaos" that results in trying to build 
multi-lingual solutions that somehow (and then a miracle
happens) unify legacy languages into a coherent 
programming language.

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

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?

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?

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.

So there is a non-trivial and hard to measure but also
hard to ignore cost to trying to duct tape these two languages
together.   It makes a mess.  It makes something that nobody
in their right mind would come close to designing from 
first principles without the historical baggage or the
economic incentive of tying in to the Emacs legacy.

So there is a cost benefit analysis to be done and, to 
be clear, I'm sure nobody can objectively claim a right
answer here - we're in the realm of pure opinion.

I say screw it. 

Let Emacs lisp live and the current implementation
thrive and incrementally evolve.  Tromey said all that
better than I do.

And also note that the corpus of Emacs lisp code is
finite and also not *that* huge -- so on a friendly
fork (partially) screw that corpus of code and make a
pure Scheme version.  Technically it's a much simpler task
and leads to a much more coherent programming environment.

Now there's competition there (presumably friendly).  Maybe
the benefits of Scheme aren't good enough and Emacs Lisp 
should prevail.  Maybe the other way around.  Who knows?
But this hybrid approach is such a muddle I don't see how people
aren't going to spend 10+ years spitting in that gutter 
(I was going to say "pissing down that drain" but decided
not to be so crude) and not getting very far.

Go for it, I say.  Fork the M.F.P. in a friendly way and
float a pure Scheme version that is anemic in extension 
packages.  Invest the programming language smarts not in
putting elisp and Scheme together in a run-time but rather
in assisting the semi-manual translation of elisp to the Scheme
environment.   Get out a solid Scheme Emacs first and *then*
worry about how to import all of that legacy elisp code.
The route you're going is pure politics-driven-engineering.
The friendly fork / Scheme-first route -- I'd bet an entire 
$0.25 you *could* get somewhere worth going in 18-24 months.
The route you are going?  I think that *at best* you yield a 
temporary and tiny improvement in elisp performance - more likely
you produce nothing that ever sticks.  I'm not trying to be
harsh - just (hopefully) helpfully honest.

-t


On Fri, 2010-04-23 at 10:28 +0200, Andy Wingo wrote:
> On Fri 23 Apr 2010 04:00, Thomas Lord <address@hidden> writes:
> 
> > On Thu, 2010-04-22 at 11:35 +0200, Andy Wingo wrote:
> >> good nil/null
> >> interoperability
> >
> > May I ask: what do you have and why do you consider
> > it to be good?
> 
> We've just started docs on this one, but here's the initial thread:
> 
>   http://thread.gmane.org/gmane.lisp.guile.devel/10232
> 
> Here's the docs from master (this link will probably vanish in a few
> weeks):
> 
>   http://hydra.nixos.org/build/367041/download/2/guile.html/Nil.html#Nil
> 
> It's a little different since you last asked me about this; I took your
> feedback into account, I think, but do let me know if we're missing
> something.
> 
> I think it's good because Scheme or Elisp lists and booleans can be
> passed back and forth, and traversing those lists or testing values for
> truth Just Works(tm). Of course, there are a couple of pitfalls; these
> are noted in the docs there.
> 
> Cheers,
> 
> Andy