guile and emacs (was Re: JACAL, scm)

[Ken Raeburn]

Miroslav Silovic <address@hidden> writes:
> I find the idea of having both elisp implementation and Guile
> implementation linked together within the same application mildly
> distasteful, and if you do that, #f and () equality is the least of
> your problems

I find it distasteful as well, but I think it's the way things would
go, at least initially.  The Emacs developers seem opposed to simply
throwing out the existing Lisp interpreter, and right at this moment,
I see no great benefit in it either.  (I'm pretty sure my guile-emacs
loses currently on both speed and memory size, even if it were fully
functional.)  But in time, there may be plenty of things we might be
able to offer, in areas where work is happening in Guile but not (or
not much) in Emacs:

 - faster execution through the Guile VM, or dynamic compilation
   to machine code, or optimized translation to C
 - better memory management
 - better GC
   - immediate reclamation of certain short-lived objects
   - concurrent and/or generational GC
 - multiple threads of execution
 - a clean module system

And of course the combining of efforts of the Emacs and Guile teams on
a single language engine, allocator, etc, rather than two separate
ones.

My impression is that starting the argument now will bring us to the
conclusion that there's little to be gained, and a lot of risk.  But
if we get a Guile Emacs running -- one with both interpreters and a
common object representation -- then we can really see where we stand
in comparison to the existing Lisp interpreter, and measure
performance in concrete terms.  *Then* we can think about whether it
makes sense to replace the existing interpreter.

Even if we decide not to, Guile will still get further exposure if
it's available as an additional extension language to Emacs, which
(I'm guessing) is probably more popular than many of the currently
most common Guile applications put together.

We only lose completely if the final decision is not to incorporate
any of the work.

>   (you're going to have two fundamentally different GCs
> waging war over which one rules the heap).

Not necessarily.  What I'm working on right now is changing the Emacs
core code to use the Guile object representation, allocator, and GC,
with the current Lisp evaluator and related code mostly still used.  A
few functions and macros operating on the "converted" types like cons
cells now call out to the Guile versions.  Unfortunately, some basic
Emacs Lisp types like strings and symbols don't map quite so easily to
Scheme types, and are smobs at the moment.

But I'm not at the point of having the Guile interpreter reachable in
any useful way yet.  When I get a little further, perhaps I'll be able
to borrow some of Keisuke's work in that area.


Neil Jerram <address@hidden> writes:
> Perhaps I'm over optimistic, but I think that, by putting together Ken
> Raeburn's, Keisuke's and my/Mikael's work we could make a Guile-based
> Emacs quite soon (say, by the end of next year).

That would be great.  My time has been way too limited, I wish I were
a lot further along with my part than I am currently.  But I'm trying
to catch up to the current Guile and Emacs code bases now...

> On the ()/#f issue, please ignore my naive question of a few weeks
> ago.  I've since reread Ken's and Jim's notes on the subject and
> understood the issue better.  (Note - a key part of this

Please -- they're Jim's notes, not mine.  I just had a note about
Mikael's transformation work and how it wasn't using Jim's proposal.
Much as I like working with them, I consider myself relatively
inexperienced with Lisp and Scheme.  I've got my opinions on the
matter, but the One Correct Answer eludes me.

> understanding, which these notes consider so obvious that they don't
> bother stating it, is the realization that conversion when passing
> values between Scheme and Elisp is not a practical option.)

I don't consider it obvious.  As someone pointed out, few are likely
to think this about Tcl or Perl.  It seems to me that it's only
because Scheme and Lisp are so similar that most people refuse to
consider requiring conversion, even if some of the specific details
don't line up nicely between the two.

Yes, I think we'll probably wind up with shared data between Lisp and
Scheme, because people want it badly enough.  I just don't think it
should be considered a given....

> (I don't have the URL for Jim's notes here, but you can find them by
> starting from gemacs.sourceforge.net and going via Ken Raeburn's
> page.)

A nice roundabout way of getting there. :-)

http://sanpietro.red-bean.com/guile/guile/old/3114.html


Rob Browning <address@hidden> writes:
>   1) Is guile really still planning to be an emacs engine that can
>      handle guile and elisp code simultaneously and allow tight
>      interactions between the two?  To know this we need to know if
>      that's something the primary emacs developers are even interested
>      in these days.

I hope so.  As I said, there's resistance to actually removing the
existing Lisp engine, but someday perhaps we'll be able to offer
benefits making it worthwhile.

> Answering some of these questions may really require some good old
> fashioned research.  For example, it doesn't really matter whether or
> not we think we want to be the emacs lisp engine if the main emacs
> developers aren't really interested.  While we *could* go under the
> "build it and they will come" model.  There's a reasonable chance that
> such an effort could be wasted, and I'm not interested in trying to
> push guile on uninterested parties.  There's too much else to do that
> people really want.

Actually, that's the model I'm working under. :-)

There's been a little discussion on the emacs-hackers list.  I think
there's interest in being able to use Guile, but I haven't had enough
ammunition to even try to shoot for replacing the elisp engine.  I'd
rather duck that argument for now, and revisit it when we know more.

Ken