Re: Emacs rewrite in a maintainable language

[David Kastrup]

"John Wiegley" <address@hidden> writes:

>>>>>> Óscar Fuentes <address@hidden> writes:
>
>>> A subset of Elisp that doesn't have dynamic binding might well produce code
>>> that could be of use to us,
>
>> That's what I had in mind all the time. We could aim to the subset of Elisp
>> that can be translated to a fast enough target code, while remaining
>> superior to C in convenience.
>
>> Or a more radical approach: a Lispy language, easy to learn by those
>> who already know Elisp, but which can be translated all the way to
>> something as performant as the current C code, while being capable of
>> interacting with it. This way, whenever someone needs fast code, he
>> would use this other dialect instead of writing C, or the slow Elisp
>> (or avoiding the task altogether.)
>
> If it can leverage what the contributor already knows about Elisp, I'm
> all for it. I wonder what RMS' and Eli's reaction would be.

Shrug.  There is the GUILE branch.  In my opinion its largest obstacle
towards acceptance is the failure of GUILE strings to offer a comparable
feature set to Emacs multibyte strings: nothing outside of the Unicode
range, no byte transparent reproduction.

This needs an overhaul of GUILE's string handling (which delegates parts
of it to helper libraries, some of those being under control of GNU,
some not).

Another tricky thing is that '() and #f (boolean false) are different
entities which Lisp both represents as nil.  That will make things
somewhat more awkward when writing code for Elisp in Scheme.  But the
string thing is a performance killer (the branch currently converts back
and forth between "Emacs string" and "GUILE string" or possibly byte
vectors all the time if I understand correctly).

> If they are amenable, would you be willing to prototype it? If we
> could see a language description for the subset/alternate, and a
> sample compilation into C for some of the functions we have in Emacs
> core (that is, reimplementing them as a proof of concept), that would
> help sell it.

GUILE's byte compiler is supposed to do a better job than Elisp.  It's
still not native, but the layering of GUILE's compiler might make native
code generation more realistic than with Elisp.

-- 
David Kastrup