Re: advice needed for multi-threading patch

[Ken Raeburn <raeburn@raeburn.org>]

On Aug 27, 2009, at 01:07, Miles Bader wrote:
> Ken Raeburn <raeburn@raeburn.org> writes:
>> in part, to replace the most fundamental layer -- representation,
>> allocation and GC -- with Guile.
>
> Do we actually want to do this?  How is guile regarded these days  
> (back
> in the day, it was a horrid bloated mess)?

I still think of this project partly as being in the "let's see how it  
works out and decide if we want to keep it" stage, or even "let's try  
this big application and see what problems we find in Guile".  So I'm  
not quite ready to answer -- or ask -- if we want to do it.  With a  
bit more polish, and some more intense testing, and performance  
analysis, maybe...

I can't really speak to how Guile is regarded; I do much more stuff in  
the Emacs and Guile internals than with ordinary applications that  
might use it, and I'm by no stretch of the imagination any kind of  
Scheme expert.  But I don't think how Guile is regarded should be as  
important as how Guile *is*.  If there are real problems with using it  
in Emacs -- as opposed to everyone just remembering how it *used* to  
be considered a "horrid bloated mess" -- then we can try to fix them  
on the Guile side, or decide to drop the project.

It's had performance problems for some time, but recent work has made  
some big improvements, putting it back in competition with some of the  
other implementations, and there's a bit of talk about compiling not  
just to VM byte codes but even to native code for some architectures  
someday.  It sounds a bit like pie-in-the-sky stuff, and some of these  
sorts of things have moved very slowly in Guile development in the  
past, but the guy doing the compiler and optimizer work right now is  
making some good progress, and I wouldn't put it past him.  There's  
also some GC system work happening, but I haven't been following that  
closely.  And if we wind up in a situation where doing such work  
benefits both Guile and Emacs because one is using the code from the  
other, it *could* be good for both projects.  (And, of course, if it  
goes badly, it could make it harder to improve things all around.)   
Thread support is another example -- if Emacs were already using Guile  
underneath the Lisp engine, thread support would probably be quite a  
bit easier.

My reasoning for trying this is in some ways political as well as  
technical.  Guile is touted as the GNU project's extension language.   
Yet one of the highest-profile, most-extensible and most-extended  
programs GNU ships doesn't use it, but instead uses a separate,  
private implementation of a rather similar language.  If "GNU's  
extension language" isn't good enough for this application, and can't  
be made good enough, then maybe we should declare it a failure as  
"GNU's extension language" and either do something else or drop the  
idea entirely.  But I don't think we've gotten to that point.

And on the technical side, I'm trying to keep most of the work in the  
Emacs "application-level" code non-specific to Guile, so if someone  
decides to replace the Lisp engine with something other than Guile, my  
changes to isolate the implementation details and assumptions made may  
still not be wasted.

BTW, if anyone is interested in helping on the Guile-Emacs work, I'd  
love to have some help.  There's quite a number of pieces still to be  
tackled, some purely on the Emacs side, others having to do with  
making the interaction between the two work better....

Ken