Re: Emacs rewrite in a maintainable language

[taylanbayirli@gmail.com (Taylan Ulrich Bayırlı/Kammer)]

Daniel Colascione <dancol@dancol.org> writes:

> On 10/18/2015 12:35 PM, Taylan Ulrich Bayırlı/Kammer wrote:
>> Daniel Colascione <dancol@dancol.org> writes:
>> 
>>> On 10/18/2015 11:35 AM, David Kastrup wrote:
>>>> Daniel Colascione <dancol@dancol.org> writes:
>>>>> Wanting to use one language is, IMHO, a poor choice for wanting to
>>>>> completely swap out a language. I am opposed to Guilemacs, not only on
>>>>> technical grounds, but also because elisp is essential to Emacs (and
>>>>> not just an optional extension system), and I want its implementation
>>>>> to live alongside the rest of the Emacs core code.
>>>>
>>>> I'm not convinced that it's a bad idea to separate the Elisp
>>>> implementation more from the Emacs core code.  It provides a
>>>> well-documented interface between the two: hacking the C code in Emacs
>>>> remains a considerable inside job and is not documented on its own.
>>>>
>>>> So I consider this a strength rather than a weakness of the GuileEmacs
>>>> proposition in the long term.
>>>
>>> I disagree. Integrating the interpreter and the editor makes integrated
>>> changes easy. It also makes elisp releases synchronous with Emacs ones.
>>> I don't think a strong library separate here gives us anything useful.
>>>
>>> Consider my recent change to add finalizers to elisp. I saw a need for
>>> the feature and just implemented it directly in Emacs. What would the
>>> equivalent be in a guilemacs world? I'd have had to make the change
>>> upstream in guile (where I suspect the process is much more involved),
>>> wait for a stable release of guile, added Emacs support, and then still
>>> not have been able to rely on the feature until Emacs dropped support
>>> for the last version of Guile to lack the feature.
>>>
>>> We'd have to go to all that trouble for what, exactly? A cleaner
>>> internal API? I don't buy it. Guilemacs has other disadvantages:
>>> currently, Emacs supports _only_ elisp as a first-class extension
>>> language. Guilemacs would invite people to write Emacs extensions in
>>> Scheme, JavaScript, and whatever else Guile ends up supporting, which
>>> will create fragmentation. A unified elisp ecosystem is a strength.
>> 
>> 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.

I think Guile is probably more fertile ground for improvement of
language semantics and implementation.

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

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.

You say "this and that will fix that" but it's already fixed in Guile.

Guile also already supports defining new types in C.

>> an FFI
>
> We're getting modules separately.

I'm not sure if that's comparable to an FFI.

>> composable continuations
>
> We have them already in the form of generators. I don't want
> unrestricted call/cc.

Call/cc is not composable.  Composable continuations can implement
generators and more, without having the problems of call/cc.

>> a module system
>
> I don't want Guile's.

And I do ... but it would be better if we stick to technical points
instead of personal preference. :-)

>> hygienic macros
>
> Unhygienic macros are useful. 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.

Guile supports hygienic and unhygienic macros.  Hygienic macros are also
better called "not broken by default" macros, if we're going to start
using slants. ;-)

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

MV returns can be very useful (and natural) for some things.
Programmers should have the choice to use them.

> Besides: we support multiple return values _today_ in the form of
> locatives: we call them gv-ref and gv-deref.

I don't think that's the same thing.

>> 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.
>
> 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 --- 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.
>
> More broadly, I don't think the Emacs lisp implementation is anywhere
> close to being a priority. It's adequate for now, especially given that
> we have lexical binding and real closures. The IDE-like features we're
> missing are much more important.

You want a lot of things and don't want a lot of things but only some of
them seem to be backed by concrete reasons instead of personal opinion.


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.

Taylan