Re: Emacs rewrite in a maintainable language

[Tom Tromey <tom@tromey.com>]

John> Ok, you've got the PL side of me rather excited now. :) Are you planning
John> optimization passes during the transform from elisp to C?

There are already a bunch of optimization passes.

For translation to C specifically, I think the main thing of interest is
type inference.  That will enable unboxing optimizations.  Type
inference is working; but I haven't written the unboxing stuff yet.

The reason I think this is particularly interesting is that the C
compiler doesn't know much about the Lisp type system, so this is an
area where the higher-level compiler helps out.

John> I noticed your files lack a copyright or license. Is this
John> something you would be willing to assign to the FSF once the bugs
John> are worked out?

Sure, though Richard's message makes me question whether this is even
wanted.

John> For it to be worth the complexity, however, I'd like to see some
John> performance numbers, or examples of features it gains us that we
John> can't have easily otherwise (like transparent FFI).

The usual benefit of the translation approach is that you can automate
drudgery.  GCPRO is no longer needed, but there are still other things,
like unboxing everything, and remembering to write "NILP" in an "if"; or
even things that Emacs doesn't currently try to do, like "advice
hygiene" -- the idea that the core should only make direct calls to a
small set of functions and dispatch the rest via Ffuncall, which would,
e.g., let people experiment with advising "read" and other things.

I don't have performance numbers, but of course it will be faster, in
the same way that Emacs C code is faster than the corresponding lisp.  I
know the bytecode/LLVM experiment was not; but I think that is because
the Emacs bytecode is a particularly bad format.

Tom