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.