Guile Maintainership

[mstachow at alum dot mit dot edu]

I'm now officially the new maintainer of Guile.

I'd like to expand a bit on the short-term roadmap I outlined before
for Guile. What I like to see happen is a release or perhaps several
in the near future which will primarily focus on documentation and
improving the startup time. Greg Badros has volunteered to apply the Scwm
docstring system to Guile and subseequently coordinate the reference
documentation effort.

Startup time will be a trickier issue to handle. I know people have had
varying degrees of success applying such things as unexec, the freezer,
the compiler, improved GC, C-implemented modules, and so on. I would
like to hear from people who have tried these approaches and what
kind of success they saw.

Also, more generally, I would like to hear from people working on
projects that they are targeted for the Guile core. I know there
are a number of very ambitious projects out there, such as integrating
GOOPS, adding generational GC, replacing the numeric tower, and so on,
but since I have been unable to follow the list closely until now,
I don't have a clear idea of what the various projects are, who is
doing them, and what kind of state they are in.

Emailing me privately so as not to clutter the list may be a good idea.

Some medium-term improvements that I think are also important, though
not as important as the two top points above, are full R5RS compliance
and support for as many of the SRFIs (http://srfi.schemers.org) as
possible. This will provide a richer environment that is nontheless
compatible with many other Scheme systems, so there should be less
occasion for debates about the proper APIs for some of these things.

I think once the immediate needs of documentation and startup time
are addressed, there are two main areas of work. One is to provide
a better public face for Guile, and encourage people to contribute
useful extensions. This can be achieved by providing a repository
and managed namespace along the lines of CPAN. Jim and I discussed
this before but unfortunately never had time to work on it.

The other is to work on infrastructural improvements, such as many
of the larger projects I mentioned before, and moving such things
as networking, posix and regular expression support to separate
modules instead of having them all in the root namespace.
Once enough of those projects are ready and integrated, there will
probably have been enough changes that it would be reasonable to
call the result Guile 2.0.

Past that it's hard to predict what things will be important to work
on. I would certainly like to see translators exist and be usable (at least
elisp, and perhaps tcl, as well as a C-like syntax of some sort) in
the long run. I'd also like to see the compiler more tightly integrated.
And support for technologies such as the web (http/html/xml, etc),
CORBA and Gnome, as well as integration of Guile into more GNU programs,
such as Emacs and The Gimp are obviously all very important, even
though they are not core issues per se.

 - Maciej