Re: Emacs rewrite in a maintainable language

[Daniel Colascione]

On 10/18/2015 12:35 PM, Taylan Ulrich Bayırlı/Kammer wrote:
> Daniel Colascione <address@hidden> writes:
> 
>> On 10/18/2015 11:35 AM, David Kastrup wrote:
>>> Daniel Colascione <address@hidden> 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.

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

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

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

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

signature.asc
Description: OpenPGP digital signature