Re: ELisp?

[joakim@verona.se]

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