Re: Emacs rewrite in a maintainable language

[David Kastrup]

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.

Then we 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?

You'd have used GUILE's guardians, and could have done this as an ELPA
package with a GUILE component.  No recompilation required for an end
user.

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

I don't consider options a problem.

-- 
David Kastrup