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: David Kastrup
Subject: Re: Emacs rewrite in a maintainable language
Date: Tue, 13 Oct 2015 17:20:53 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: David Kastrup <address@hidden>
>> Date: Tue, 13 Oct 2015 12:01:50 +0200
>> 
>> > If it can leverage what the contributor already knows about Elisp,
>> > I'm all for it. I wonder what RMS' and Eli's reaction would be.
>> 
>> There is the GUILE branch.
>
> First, Guile's Scheme is not Emacs Lisp, there are significant
> differences.

Uh, the topic was rewriting Emacs in a Lisp-like language performing
better than Elisp.  I was pointing out that treating this topic as if
something like that would be totally new was leaving out a significant
bit of history.

> Second, Guile itself is written in C, so what exactly is gained here?

As I wrote and you removed in order to pretend I didn't, the GUILE
compiler stack is posited a whole lot better for native code generation
than Elisp and does a better job even on its own byte code machine.

> Third, AFAIR the Guile branch doesn't replace all of Emacs's C core.

Most definitely not.

> Fourth, that branch is far from ready for prime time (as you know and
> point out).

So it makes more sense to discuss branches that have not even started?
Without even considering the lessons learnt so far on the GUILE branch?
Is this discussion intended to stay at the level of pipe dreams?

>> GUILE's byte compiler is supposed to do a better job than Elisp.
>
> But for now it has known problems with ELisp (some tests fail).  Also,
> at least Guile's own byte code (the *.go files) are not
> architecture-independent, so building a Guile Emacs will need a long
> compilation on the target machine.  Not a catastrophe, but hardly a
> nice thing.

Yes, certainly much worse than our fantasy Lisp-like language compiling
into machine code that has no problem interfacing with half of Emacs and
replacing the rest.

-- 
David Kastrup



reply via email to

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