Re: Emacs rewrite in a maintainable language

[Taylan Ulrich Bayırlı/Kammer]

"Stephen J. Turnbull" <address@hidden> writes:

> Taylan Ulrich Bayırlı         /Kammer writes:
>  > I've heard bad things about both defstruct and EIEIO for different
>  > reasons.  The fact that most Elisp code is shy of using even defstruct
>  > should tell us something.
>
> It does.  It tells us that RMS doesn't like abstract data types.
> AFAICT there's little inherent problem with defstruct from cl-macs (or
> cl-lib, I forget which), it's just a matter of style preference
> (originally rooted in the claim that cl.el was just syntactic sugar so
> it was a waste of pure space on small machines to require it).

OK, I didn't know of any past ordeals regarding defstruct.

>  > >> an FFI
>  > >
>  > > We're getting modules separately.
>  > 
>  > I'm not sure if that's comparable to an FFI.
>
> Does Guile's FFI refuse to load code if it doesn't call the I-swear-
> I'm-GPLed function?  That's another requirement for an FFI/module
> system in Emacs, at least for the present.

Would that really be a blocker if the feature just appears naturally as
part of the Guile integration?

(The answer to your question is no.  Guile is LGPL anyway.)

>  > I'll now leave this branch of the discussion too because it's
>  > probably not going to head in a good direction.  I would much
>  > rather do something constructive than try counter people's panicky
>  > reactions to Guile, whatever reason they have.
>
> I'm not panicking.  GuileEmacs has zero attraction for me *personally*
> because on the one hand its advocates admit it still needs work.  On
> the other none of its claimed advantages excite *me* one bit.

I didn't have you in mind when I said that. :-)

> If we can really rewrite all of Emacs with the exception of device
> drivers in Guile, then I'd definitely be excited (I think that's what
> Tom Tromey is talking about).  But I don't think that effort is likely
> to succeed in providing an efficient Emacs at all soon, although it
> might provide an efficient Emacs Lisp.  So we would end up with three
> implementation languages required to understand important (generic)
> components of Emacs.  Specifically I suppose that redisplay is likely
> to remain in C for a long time.  I don't think that's a win,
> especially with the e^i mental twist required when moving between
> Scheme code and Lisp code.

I don't think there's any clear plans to rewrite arbitrary or all parts
of Emacs's C code in Guile-Scheme.  The way I see it, the merge entails
broadly 1. letting Guile do all the things it can do better like
compiling and running Lisp (regardless of whether it's Guile's C or
Scheme code that does so), 2. having the Emacs-specific data types and
subroutines in Emacs's C core become libguile data types and libguile
procedures, without much change to the body of C code implementing them.

AFAIUI, that's precisely what GuileEmacs currently does, and the basic
strategy seems to work very well.  (It really works as a drop-in
replacement, just with bugs.)  For instance I can call the Elisp subr
`buffer-substring' not only from Elisp code that gets compiled by Guile,
I can also import the module `(elisp-functions)' in Scheme (or any other
language running on Guile) and have the subr normally found in
(symbol-function 'buffer-substring) appear within the Scheme variable
`buffer-substring' instead, with Scheme type 'procedure' and all the
related privileges of that type.

This offers a very nice integration on one hand (only Elisp strings are
a separate type from Guile strings), and requires no substantial change
to the C code behind many features on the other hand.

Actually rewriting parts of that C code in Scheme might be a future
endeavor, but I don't think it's a priority.  It might be a slow and
gradual process for the future, for those parts of the C code for which
it makes sense to rewrite in a higher level language.

> It doesn't bother me if somebody else wants to do the work, though.

Great. :-)


I do understand the worry about the additional language that might need
to be learned by some Emacs maintainers by the way.  That's one of the
actually sensible criticisms I've heard against GuileEmacs.  There's
probably no real solution to that, but I think it will be the correct
trade-off.  Scheme is more similar to than different from Elisp, and
Guile is gaining a huge amount of importance via Guix, and has also
otherwise become a really great general-purpose programming language.
It will most likely play a very important role in the future of GNU, so
I would say GNU hackers should look forward to learning it.  With Guix
you have Lisp in your initramfs, Lisp running your init system and
service management, Lisp driving your package manager, your package
recipes are Lisp expressions evaluating to Lisp objects, and so on and
so forth.  That Lisp is normally Guile Scheme, but if Emacs runs
seamlessly as part of Guile...

This is not a pipe dream.  Guix is working on the 0.9 release with very
steady progress, and GuileEmacs just needs some love.

Taylan