Re: Emacs rewrite in a maintainable language

[Stephen J. Turnbull]

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).

 > >> 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.

 > 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.

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.

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