Re: ELisp?

[Noah Lavine <noah.b.lavine@gmail.com>]

That makes sense. I was hoping we could skip the phase where we have
two lisp interpreters around, if Guile's ELisp implementation was good
enough, but maybe that will not be possible. Emacs already does
something similar to this for the programming language modes, where it
has another interpreter as a subprocess, so this doesn't sound so bad
technically.

One question I have is, how much of Emacs' C code can Guile use right
now? I guess Ken Raeburn's patches are the ones that address that, but
I don't know what is left to do.

(I also have the same question about ELisp - what of the language is
left to implement? Is it just adding more builtins?)

I don't know if this would work, but the way I was imagining it
happening is really just starting up Guile and loading Emacs source
files, one by one. If we have a complete ELisp implementation with all
of Emacs' C code, then in theory Emacs would start. I don't know what
would actually happen though.

A branch on Savannah sounds like a really good idea though. Then at
least there would be a central thing for people to look at and hack
on, and more people might get involved. Right now I suspect that most
people don't know what's happening or where to look. If you set up a
branch, I for one would love to check it out and perhaps contribute
some patches. Do you need permission from the Emacs maintainers to do
that, or anything else?

Noah

On Sun, Oct 9, 2011 at 9:37 AM,  <joakim@verona.se> wrote:
> Noah Lavine <noah.b.lavine@gmail.com> writes:
>
>> Hello all,
>>
>> Could anyone tell me the status of the ELisp implementation since July
>> 21st (the last update)?
>>
>> I'm especially interested now because of a thread on emacs-devel -
>> http://lists.gnu.org/archive/html/emacs-devel/2011-09/msg00753.html.People were talking about adding multithreading to Emacs. Some people
>> said that moving Emacs to Guile might be the best solution, but others
>> were pessimistic about that ever happening. It looks like the Emacs
>> people would really like to use Guile, and we would certainly like
>> them to. Also, every time Emacs implements a feature that Guile
>> already has, it's wasted effort when we eventually integrate them.
>>
>> It seems like Emacs-Guile integration is a project that is on the
>> verge of happening, and just needs some sort of push to get it over
>> the hump. I hope that this summer's SoC work can be the impetus.
>>
>> Noah
>>
>>
>
> I'm an Emacs developer(not the most prolific but I have contributed
> ImageMagick core integration and Webkit integration for Emacs 25)
>
> I'm now trying to learn non-trivial Guile usage so as to be useful in
> the future merge of Guile and Emacs.
>
> Currently, for me coming from the Emacs side is that I have no idea how
> integration would happen. I've studied the various attempts but haven't
> come to any conclusion.
>
> My naive approach would be to make an Emacs Guile branch on
> Savannah. The branch would unify incrementally the 3 different existing
> approaches:
>
>  - Nishidas patches to run Guile in Emacs
>  - Ken Raeburns patches to replace the Emacs Lisp engine
>  - Templetons implementation of Elisp in Guile
>
> This branch would initially use Nishidas strategy of just linking Guile
> and providing some simple interoperability functions. The version linked
> would be Templetons Elisp Guile version. So, there would be 2 lisp
> engines in Emacs for a while. When things work well the old Emacs lisp
> engine would be ripped out.
>
> As I'm coming from the Emacs side of things my interest is in getting
> Guile in the Emacs core efficiently. My motivation is somewhat selfish
> because I don't want to re-implement all the interesting features Guile
> has in Emacs, such as dynamic FFI etc..
>
> Of course there are many details to work out. A random example could
> be that we would like a cookie to indicate that eval-buffer should use
> guile rather than elisp for a buffer.
>
> The advantage of the above approach is that it is incremental. We gain
> exposure in the Emacs developer community. Since Emacs 24 is entering
> pretest its a good time to start to think of features for Emacs 25.
>
>
>
> --
> Joakim Verona
>
>
>