Re: Elisp development news

[Ken Raeburn]

Neil Jerram <address@hidden> writes:
> [ lots of wonderful stuff! ]

This looks great!  

> I'd like to merge this work back into the main development branch,
> both to encourage further use and development, and to avoid bitrot,
> but there are some (possibly controversial) changes to the libguile C
> code that I'd like to discuss and agree or rework first.  Those
> changes are ...

Removing a bunch of the elisp-oriented support looks like a good thing
to me.  The less that needs to be written in C (not counting Scheme
mechanically translated to C for performance), the better the argument
for Scheme and Guile specifically as an extension language that can
easily subsume the roles of other extension languages.  Maybe I'm just
being silly, but my thinking is along the lines of, "If Scheme is so
great, why do you have to write all this C code?"  (Probably followed
up by, "Okay, so if performance is so important, why don't you have a
better compiler?")

Having more of it in C also means less work in the event that someone
tries to port it to a different Scheme system -- or replace Guile's
Scheme engine.

> guile> (use-modules (lang elisp interface))
> guile> (load-emacs)
>[...]
> That's 3279 lines ("wc -l") of Elisp code already, which isn't bad!

Woo hoo!

> I think that progress beyond this point basically means implementing
> multilingual and multibyte strings properly for Guile.  Which is a
> _lot_ of work and requires IMO a very clear plan for Guile's role with
> respect to Emacs.

Multilingual, multibyte strings are definitely going to be important
for Emacs, but IMHO Guile needs them anyways.  Jim had written up a
bunch of stuff about it a while back, and I'm sure he had Emacs in
mind.

To be honest, though, I'm not sure I want to make specific plans at
this point -- not unless they include such vague notions as "let's see
how good we can make the performance in a year or so, and then we'll
think about maybe replacing the existing elisp engine".  Between
lackluster performance of my (still very rough and unoptimized)
plugging of Guile into Emacs, and the work still needed in elisp
translation, I'm worried that the performance could turn out to be
pretty poor, at least initially.  Emacs is way too high-profile to
make radical changes that degrade performance, especially without huge
practical benefits.

(The benefits I keep hoping for are multithreaded programming in
elisp, and being able to do stuff through the UI while work is being
done in other threads.  Like editing while Gnus fetches mail and news
from multiple sources in parallel, without having to rewrite
absolutely everything to be event-driven.  But multithreaded support
and dynamic binding handling and fast execution aren't an easy
combination.)


> Other possible problems with this approach are that it might not be
> possible to implement buffer local variables properly, and that
> address@hidden' might become too inefficient when we implement full support
> for undefining Scheme variables.  So we might in future have to
> transform Elisp variable references after all.

It gets worse -- there are now frame-local bindings and variable
aliases.


> Ultimately, most of these primitive definitions should really come
> from the Emacs C code itself, translated or preprocessed in a way that
> makes it compile with Guile.  I think this is pretty close to the work
> that Ken Raeburn has been doing on the Emacs codebase.

Yes.  The Emacs 21 work and some changes in Guile have pushed me back
quite a ways, and caused me to devote all my time to making the main
Emacs code less dependent on the Lisp object representation (outside
of the lisp engine itself of course).  But with the release out, I've
started trying to push forward again.  I had, at one point long ago,
an Emacs that would run using the Guile object representation for
numbers and cons cells, and smobs for most other stuff; it had some
bugs that needed to be worked out.  Right now, I'll be happy when I
get back to the point of having it all compile once again. :-(


> - Character syntax is `?a' rather than `#\a'.  (Not done.  More
>   precisely, `?a' in Elisp isn't character syntax but an alternative
>   integer syntax.  Note that we could support most of the `?a' syntax
>   simply by doing 
>
>       (define ?a (char->integer #\a)
>       (define ?b (char->integer #\b)
>
>   and so on.)

Only if things aren't quoted.  I think the reader changes will be
needed.

Ken