Re: Elisp development news

[Neil Jerram]

>>>>> "Ken" == Ken Raeburn <address@hidden> writes:

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

    Ken> This looks great!

Thanks!

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

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

I completely agree.  From a slightly more pragmatic point of view, we
might find for performance reasons (and for lack of a compiler!) that
we need to move something into C in the future.  But the stuff that
exists right now is over-engineering IMO.

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

I presume you meant "less ... less" here rather than "more ... less".

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

I think Alex Shinn has started looking at multibyte strings now for
Guile.

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

Just as long as we're not wasting our time because someone somewhere
has changed the long term plan without telling us!  On the other hand,
even if that were to happen, we can't be wasting our time if we think
of our work as editing primitives for Guile with Elisp language
support.  And the huge existing body of Elisp code makes it worthwhile
aiming for exact compatibility even if we are not destined to become
the official Emacs.

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

Hmmm.  I wonder if coop threading and async I/O would be enough to do
the trick in most cases here?

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

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

Variable aliases???  What are they?

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

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

Good luck then!  Anything that I could you help with in this area?

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

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

I think you're right overall but I don't see what you mean in detail
by "if things aren't quoted".  Can you explain?

Regards,
        Neil