Re: Guile in Emacs

[Thomas Lord <lord@emf.net>]

On Tue, 2010-04-13 at 12:07 -0400, Stefan Monnier wrote:

> 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.

Well, I'm not so sure that that's entirely true
and I'm also not so sure that that's the only 
consideration.

What you say is less than obviously true in this
way, at least:  Consider how modern browsers are
often written.  On the one hand there is some lower-level
library for rendering HTML and doing various HTTP magic.
On the other hand, there are higher levels that make
the complete application.  That lower level part gets re-used
in other applications.   A text editor isn't obviously
much (or perhaps at all) a different case.  It might
be desirable to start thinking of Emacs in two layers: an
embeddable library and, sure, a default application as its
basic front-end.   Emacs lisp library code would then 
be "emacs specific" in some sense (relative to the 
library) but not really application specific.

Beyond that:  While it might be the case that "most"
Emacs lisp library code is Emacs-specific in some sense,
some important code need not be.  One example is SCSH
(the Scheme "shell" for managing sub-processes).  
A possible future example is Unicode-oriented string
libraries.  "Most" of the code might be Emacs-specific 
but some important parts of the code need not be.

And, anyway, it's not the only consideration.  If 
Scheme were used by many GNU programs as an extension
language, then inter-process communication by writing
and reading Scheme s-exps would be more common.  Two
standard Scheme environments can exchange s-exps with
relatively little problem.   But toss in a very different
lisp - like Emacs lisp - and you start to have problems.
E.g., what does "nil" read as?  What's the syntax for
strings?  Are symbols case sensitive?




> 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).

Sure.  But if we're thinking of a long term strategy
rather than quick hacks, we should also keep in mind
that much of what is today in C in Emacs could well be
usefully replaced by Scheme code.

That's part of why I suggest (you know, given the infinite
amount of spare time we all have) the radical option of 
stripping Emacs lisp out and re-binding to Scheme:  because
that exercise would lead to some careful re-evaluation of
what needs to be in the C part and how best to make a 
clean interface to it.




> 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 fully agree that that matters.


> 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, ...


Yup.  A big "gotcha" trap to watch out for on that path
is Guile's C API.   The less intertwingled Guile's (or any
other implementations) assumptions about the C client can
be, the better and more flexible the result.   I.e., it would
be pretty much the same mistake as being too Emacs lisp centric
to be too Guile centric.   It would ideally be plausible to
swap out Guile for some other implementation, even if the 
initial investment and commitment is to use Guile.

-t



> 
>         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.
> 
>