Re: Guile in Emacs

[joakim]

Stefan Monnier <address@hidden> writes:

>> I dunno.  Maybe.  I'd guess that, no, that's not a 
>> good strategy.   Four reasons come quickly to mind:
>
> I agree with your conclusion but for a very different reason.
> In my opinion the actual language used is not very important because
> most of the code that will be used with Emacs will be written
> specifically for Emacs.
> The availability of alternative implementations is also of no use
> because changing the underlying implementation is the part that's
> difficult (at least with Emacs's current structure).
>
> What matters is that we reuse some existing implementation and benefit
> from all the work done on it, so we don't have to spend time working on
> the Elisp byte-compiler.
>
> I like the idea of Guile not because it's using a "standard preexisting
> language with libraries and experienced coders", but because it'll give
> us a bunch of hackers working on efficient implementation,
> multithreading, ...
>
>
>         Stefan
>
>
> PS: The same holds for the redisplay engine; I really hope/wish we will
> be able to switch to some other project's redisplay engine at some point.
>

IMHO it would be interesting to have Emacs as a set of components which
could be plugged together, which also happened to include an elisp
interpreter. This could work sort of like JNI in Java, or some other
component model(Like one of the lightweight corba implementations)

A start would be a plug-in model that allowed C plugins to be jacked
into Emacs. That could allow other runtimes, like Guile, to run in Emacs
and affect the Emacs internal state.

-- 
Joakim Verona