emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs rewrite in a maintainable language


From: Taylan Ulrich Bayırlı/Kammer
Subject: Re: Emacs rewrite in a maintainable language
Date: Sun, 18 Oct 2015 21:35:22 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

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

Taylan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]