Re: Emacs Lisp's future

[Stefan Monnier]

> Imagine the round trip a value might take:

There's no translation involved, so no "round-trip" problem.
Instead the problem is that there are new kinds of data.  These can come
from Scheme and look weird from the Elisp side.

Basically, Scheme has #f, (), and nil as 3 distinct objects.
So Guile-Emacs picked one of those as being Elisp's nil, so as long as
you stay all within Elisp things work just fine (presumably), but as
soon as some Scheme gets into the picture you might get new values which
are similar to nil but aren't `eq' to it.

> I'd be happy to use the lower-level portions of Guile for compiling
> elisp more efficiently, but I'm adamantly against trying to support both
> Scheme and elisp simultaneously.

I tend to agree.  But I'm not sure it's easy to really stay 100% within
Elisp with a Guile-VM.  E.g. I suspect some errors signals coming from
Guile's runtime will end up using Scheme-style data and will end up
spilling into the Elisp side if we're not extra careful.


        Stefan