Re: Emacs rewrite in a maintainable language

[David Kastrup]

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

My personal opinion is that It's unlikely to survive into GuileEmacs for
mostly technical reasons.  The best one could do is make it stick when a
module calls Emacs-specific functionality.  But if it uses the general
GUILE stuff (namely could be called from a standard GUILE interpreter),
Emacs cannot really make a licensing claim that sticks.

> 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 like arbitrary precision integers and rationals and the whole numeric
stack.  I also like the availability of applications and libraries that
have not been written specifically for Emacs: replacing much of the
backend behind Emacs Calc with native Jacal would be an interesting
feat, and there are a number of other pathways opening up.

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

Well, it would move the worlds of SCSH and Scwm closer to Emacs.  Eshell
never took off, partly because of being severely underdocumented, partly
(related) because of being a one-person project.  Run Scsh inside of
Emacs and things may become interesting.

Elisp is not used for creating scripts to any serious degree, the
existence of rep notwithstanding (show of hands: which Emacs developer
ever worked with rep or even knows it?).

GUILE can (and will) be used for scripting.  So for GNU integration and
desktop cohesion, this may be a strategical step.  It also muddies the
application boundaries when Scheme applications gain enough glue to
integrate nicely into Emacs and that's something that makes the GPL
stickier again.

So I do see longterm goals and strategies that could be opened by a good
integration of GUILE as a core part of Emacs.

The most relevant obstacle _will_ be to overcome the "don't mess with my
project" stance in both Emacs and GUILE from people that have come to
like the respective culture and environment of the isolated projects.

-- 
David Kastrup