Re: Emacs rewrite in a maintainable language

[David Kastrup <dak@gnu.org>]

Daniel Colascione <dancol@dancol.org> writes:

> On 10/18/2015 12:35 PM, Taylan Ulrich Bayırlı/Kammer wrote:
>
>> Guile already supports finalizers (and much, much more) so you
>> wouldn't have needed to implement it from scratch for Elisp. :-)
>
> I'm sure we'll have to extend something sometime.

Sure.  But general programming facilities are not likely to be it.  in
spite of Taylan Ulrich's insistence, I am pretty sure that most of the
things in need of cross-community work are in the encoding area.  I'm
also pretty sure that the basic buffer mechanism (basically a string
with an insertion point) would warrant a more native reflection in GUILE
data structures.

>> record types (like an improved defstruct)
>
> We have EIEIO. And defstruct is fine for most use cases. Over in the
> modules discussion, we're talking about letting C modules define
> first-class types in elisp. That'd be neat, and defstruct could use the
> same machinery instead of a type symbol.
>
>> CLOS-like OOP
>
> EIEIO.
>
>> an FFI
>
> We're getting modules separately.
>
>> composable continuations
>
> We have them already in the form of generators. I don't want
> unrestricted call/cc.
>
>> a module system
>
> I don't want Guile's.

The underlying principle of GUILE's module system is to separate symbols
as globally interned strings from the associated variables containing
values.  Lisp symbols have 4 elements: print name, value cell, function
cell, property list.  GUILE symbols have the print name, everything else
is established separately.  That allows for designing arbitrary module
systems on top, so it would be feasible to give Elisp its own system.

>> hygienic macros
>
> Unhygienic macros are useful.

Nobody will take them from you.

> I don't want Guile's opinionated macros.  Besides, this point is
> out-of-date if Guile supports elisp, since existing elisp macros are
> unhygienic.
>
>> multiple-value returns
>
> Returning lists works fine, and everyone I know finds CL's multiple
> return feature confusing. We can live without it easily, since most
> other languages have managed to live without it.
>
> Besides: we support multiple return values _today_ in the form of
> locatives: we call them gv-ref and gv-deref.

Well, I'd want to have
<URL:http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17474> adopted in
order to make the C API more consistent.  I'd also want a single static
value for the empty string "" (regardless of encoding and r/w state
which does not make a difference when there are 0 characters).  And so
on.  Basically, getting any internal changes accepted or even discussed
as a GUILE outsider is a rather upstream battle.  Of course it doesn't
particularly help if you are banned from the developer list...

I digress.  Apart from the above-mentioned lack of streamlining the
no-return-value concepts of the C and Lisp APIs, the multiple-values
concept of Scheme is reasonably clear.  The programming constructs
around it are awkward, but there are by now destructuring forms of "let"
that are actually being reasonably nice to use when programming.

>> and threads
>
> Guile by itself sure as hell won't give us threads. You'll have to
> solve all the synchronization problems that adding threads will
> inflict on the Emacs core. The existing threads branch goes a long way
> toward doing that.

Sure, but using a thread-supporting underlying programming language
means that the Emacs code dealing with multithreading will only have to
concern itself with the Emacs-specific synchronization issues rather
than mixing this up with the interpreter-specific problems.

> I really don't want to shoehorn Guile into Emacs. It's the wrong
> runtime for the wrong language being advocated for the wrong reasons.
>
> I wouldn't mind taking _pieces_ of Guile --- in particular, maybe the
> JIT and GC

GUILE 2 has no JIT compiler and uses the Boehm GC (and still has not
fixed/worked-around/reported the finalizer problem in
<URL:http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19883>) so that's a
peculiar choice of things to take.

> --- and replacing the existing Emacs implementations of these runtime
> facilities, but I don't want Emacs linking against libguile.so, I
> don't want users to have to install a separate package, and I don't
> want our platform support to be limited by whatever Guile provides.
> Basically, I don't want our future in Guile's hands.

Well, in a nutshell you don't want the GUILE and Emacs communities to
join forces.  But that's what the strategic goal is.  Your main argument
is "we could make do without GUILE".  But that's not actually the
question.  Of course we could.

But basically if GUILE is not wanted as an extension language for Emacs,
GUILE's intended role as the extension language for GNU is a failure.

I think that if the Emacs and GUILE communities can get over their
respective "don't you mess with my project" stance and fears that GNU
overall would have something to gain.  This will require changes in
Emacs developer focus and attitudes, and it will require changes in
GUILE developer focus and attitudes, and currently there is a sizable
number of developers in both camps who would prefer the other camp to
drop off the surface of the Earth in order not to complicate matters.

I'm not convinced that this is the best way forward.

-- 
David Kastrup