Re: Shrinking the C core

[Gerd Möllmann]

Arthur Miller <arthur.miller@live.com> writes:

>>> IMNSHO, discussing a rewrite of Emacs in _any_ language is waste of
>>> time and energy.  We've seen this many times (because people still
>>> insist on bringing this up from time to time).  From where I stand,
>>> the main reason is not even the fact that we decided not to do that,
>>> but the fact that such a rewrite will never happen in practice.  Such
>>> a rewrite is a massive job which requires very good knowledge of Emacs
>>> internals and features, and a lot of time.  People who come close to
>>> the required knowledge level are not interested in doing this job
>>> (because they understand the futility), and those who think it should
>>> be done simply don't know enough and/or don't have enough time on
>>> their hands to pull it through.
>>>
>>> If Emacs will ever be "rewritten", it will not be Emacs, but a
>>> text-processing system with a very different architecture and design,
>>> which will take from the Emacs experience the lessons we learned and
>>> implement them differently, to produce a system whose starting point
>>> is closer to the needs of today's users and whose main technologies
>>> are more modern from the get-go.
>>
>>I couldn't agree more.
>>
>>To me, a rewrite is quatsch, while adding CL facilities to Emacs makes a
>>lot of sense.
>
> I use to say often: either CL will come to Emacs or Emacs to CL, whichever
> way around. We need some of features available on CL platforms, sbcl
> notably: built-in concurrency and better garbage collectors from the get-go; 
> and
> some of the CL language features, namespaces notably, would be very nice to
> have.

I agree.  Alas, others, who haven't seem the light yet, don't :-).

> I am not sure which one is easier to achieve, porting elisp to cl, or
> rewriting core to have all those features.

I don't know either, of course. I guess it depends on the feature.  Some
random thoughts:

I'm pretty sure that CL packages could be added to Emacs as it is, if
some people would work on it.

I'm also pretty sure that an incremental + generational GC could be
added, at least as an option, because I would have almost done it some
20+ years ago.  It was torpedoed by a patent issue concerning
mostly-copying GC.  The patent has since expired. A lot of work, of
course.  I think some people do or have done something in this area, but
I don't know details.

I'm not at all sure that non-cooperative multi-threading could be added
to Emacs.  But I'm also not sure how a CL core would help here.

On the other hand, I'm pretty convinced that an Emacs core written in CL
would have to be close to 100% compatible with the existing C core to be
accepted by users.  That includes a CL rewrite of the C Elisp, including
byte code interpreter.

That's a massive endeavor.  My hair stands up when I remember the
compatibility problems I faced with the new redisplay ages ago.
Multiply that by some factor > 1.  But maybe that's a burnt child
dreading the fire :-).

I'm also not sure how a CL (not Elisp) program would look like using a
CL Emacs core.  Is it nice enough, so to speak?  Think of Emacs strings,
which couldn't be CL strings because of text properties, buffer-local
variables...

(Another ansatz might be to make Emacs C core a lib.  I haven't given
that much thought, but it could be more promising than rewriting the
whole shit in CL :-).)

> CFFI would also be nice to have so
> that users can extend Emacs themselves with other libraries and not have to 
> wait
> for the core devs to do it for them. That would also lessen the burden on
> maintaining that stuff in the core.

FFI for Emacs once existed, I think Dave Love wrote one, for instance.
Don't know what became of that.  Might be an issue with interfacing to
non-free libs.