Re: Emacs rewrite in a maintainable language

[John Wiegley]

>>>>> Drew Adams <address@hidden> writes:

> I'm not for it. I guess it depends on just how "whenever someone needs fast
> code" is interpreted, in practice.
> 
> I do not wish to see Emacs core developers start opting for something like
> this instead of using Lisp, with the excuse that they want their given code
> to be "fast".

If the gap between C (or a hypothetical Lisp-like), and Emacs Lisp, could be
reduced to zero, I'd absolutely want everything to be in Emacs Lisp. That has
been my dream for Emacs since I can remember, as I'm prefer playing on the
Lisp side much more than the C side.

I once tried to make Emacs Lisp my "primary language". The speed just wasn't
there, not to mention a few other things (control over memory layout, direct
access to file handles, integration with C libraries, etc). There are several
things we'd need to turn Emacs Lisp into a general purpose, well-performing
language, sufficient to replace all our C code.

>> compilation into C for some of the functions we have in Emacs core

> This is backwards from the direction we have been moving with Stefan and
> Eli, which is toward moving core stuff from C to Lisp when possible.

I want the C->Lisp direction. I was talking about proving any new candidate
that might replace C, to show it provides a comparable implementation.

>> (that is, reimplementing them as a proof of concept),

> OTOH, if it's _only_ to test POC, then I suppose it's hard to object. But I
> would not want to see compiling core Lisp code to the proposed language be
> taken seriously. That would be a step backward, IMO.

Don't worry, not suggesting that. :)

> Leave such code in Lisp, please. And move more core code to Lisp, when that
> is feasible. (As Eli has noted, most of the C code cannot feasibly be moved
> to Lisp.)

100% agreed.

> To whom are you trying to sell it? What's the point? Emacs is too slow? C is
> too hard to maintain?

The objective of the proposal is to not lose speed -- not necessarily to be
any faster -- and to gain contributors by offering a language closer to (if
not actually) Emacs Lisp.

> To be clear, if it is a question of using such a language _only_ for the
> equivalent of what C is _necessarily_ used for, it's hard to object.

Yes, only for that. As much as is practical, code should be in Emacs Lisp. I
fully back that as a strategy for the future, since C is not the dire
necessity it once was, per Richard's cute poem.

John