Re: guile: going the way of DEATH

[Jim Blandy <jimb@red-bean.com>]

Yes, Guile is overdue for a release.  I hope to make one within the
next month; for the task list for the 1.3 release, see
http://www.red-bean.com/~jimb/guile/.  That list includes issues
certain users I chose considered "most critical".

At the moment, I am occupied with packing for my move to the midwest,
which will occur the weekend of August 22.  I expect to be back to
work by Mon Aug 31.  I don't see any reason the 1.3 release won't
happen in September.


> What I'm gonna say will probably offend many of you. But my point is
> that it is better to discuss it now, before Guile is completely dead.

If the Guile maintainer finds constructive criticism offensive, Guile
is already dead.  I wasn't offended by this post.

> 1. Tcl is a *small* library, which is critical for an extension
>    language: libtcl.so is ~400K. Guile is very big - current version
>    of libguile.so is more than 1Mb - almost three times as big as
>    libtcl.

I'm not sure I can reproduce these numbers.  Running `size' (which
omits debugging information) on libtcl 8.0 and the latest libguile on
Solaris/SPARC gives me 357kb for Guile and 348kb for Tcl.

Keep in mind that that Guile library includes a lot of weird stuff;
once we've broken it out into dynamically linked modules, I think it
will be smaller than Tcl.


> 2. Tcl was written from scratch and consisted of a small number of
>    clean interfaces, defining the language and a small C API for
>    extensions. This was enough (and still is). All other Tcl-related
>    stuff is just a bunch of optional extensions.
> 
>    On the opposite, Guile was initially based on one implementation of
>    Scheme (SCM) with some pieces borrowed from another one. This led
>    to a horrible mix of interfaces and interdependencies in the code.
>    Also, nobody even tried to define both Scheme and C API - they are
>    still in flux and dirty, lacking logical order.

I agree that Tcl's API is cleaner than Guile's.  However, people have
tried to define the Scheme and C API, but the job wasn't really
finished (in my opinion).  I also think this problem looks worse than
it is, because of the lack of documentation.  There is some unity
there; you just have to know where to find it.

Guile's documentation (or lack thereof) is its biggest weakness.
Adopting SCWM's docstring system will help with this; a well-organized
manual will too.  Documentation is at the top of my post-1.3 task
list.  Guile 1.4 will be released with the manual.

I think we will need to clean up the interfaces as we go along.

> 3. Tcl has a very elegant GUI toolkit, which is not just a set of
>    X11 or Motif bindings.

Guile has interfaces to both Tk and GTK, but neither are quite mature,
as far as I know.  I think the GTK interface has a lot of potential,
and I hope to focus on bringing it up to the level of Tk as soon as
the documentation and module situations are cleared up.

> 4. Finally, Tcl was actively promoted for applications with frequent
>    bugfixes and releases.

I neglected Guile for the seven months before this June.  This is a
fair criticism, and I'm trying to fix that.

>    the only 'official' [Guile] release is the brain-dead 1.2...  On
>    the other hand, the Red Bean folks are quetly developing Guile at
>    their site, making snapshots available.  However, snapshots are
>    different from releases

(Just to be clear, here --- the folks doing Guile at Red Bean *are*
the official Guile developers.)

I agree that snapshots are different from releases.  As I said, this
will be addressed by the release of 1.3 in September.

> 1. Interfaces must be defined and frozen. I mean both Scheme and C
>    ones. This is the most important thing now. The users (people
>    developing using Guile) must have a clean set of API and be sure
>    they won't change from release to release (at least,
>    significantly). 
> 
>    OTOH, nobody cares what really is inside Guile - whether it is SCM
>    or VSCM, or SIOD - this must be *completely hidden* from a user.
>    Same goes for garbage collection engine.
> 
>    Once we define and freeze the API, we may produce a Guile reference
>    manual which won't change in the future.

I actually think we should document the interfaces as they stand, and
then provide clean alternatives.  The gh_ functions are meant to be a
first shot at the clean alternative.

Let us assume that the gh_enter clumsiness is resolved in some way, as
discussed a few weeks ago on this list.  Given that assumption, I
don't know of any garbage collection systems that are less obtrusive
than Guile's.


> 2. Small is not just good. It is vital for an extension language. The
>    API must be *small*. Let's learn from Tcl. I'd suggest the
>    following set of API:
> 
>    Scheme: R4RS, *basic* process I/O, formatted I/O, symbol table
>    access, regular expressions, *very basic* OS interface (directory
>    reads, system(), exec) - I'm literally going through the Tcl
>    reference manual
> 
>    C: interpreter management, file loading, string code
>    interpretation, module creation API - modules must be .so files to
>    be dynamically loaded. This will give us the extensions development
>    framework.

I think I've posted to this list several times along a very similar
bent.  Without going into details, this is pretty much what we plan to
do.


>    Until THE Guile is ready, I'd suggest temporary stopping of the
>    development of some other ambitious Guile-related projects: SCSH
>    compatibility and the compiler.

I think you're assuming Guile development is more centralized than it
is.  I'm not actually spending any time myself on those projects;
Bernard and Russ work on Hobbit and SCSH because it pleases them.
Their time is not mine to allocate.

Perhaps the division of Guile could be delegated, but good delegation
requires a concrete plan; I want to release 1.3 before spending the
time to develop that plan.


> 3. Once it is done, several extensions must be developed (as .so
>    modules):
> 
>    POSIX O/S services - to allow those developing OS utilities in
>    Guile greater control.
> 
>    Low level socket interface - for the same reason.
> 
>    A GUI module. I am not sure it should be Tk. After all, Tk still
>    contains a lot of Tcl legacy bindings, which would mess the things
>    up. I'd rather go for some C GUI toolkit and would make Guile
>    high-level bindings for it, learning from Tcl/Tk success. The
>    bindings must be really high level - not just the mapping to C API.
> 
>    So far, the most obvious and attractive choice is GTK. It is stable
>    enough, it is THE GNU GUI toolkit, and it is supposed to be a GUI
>    of forthcoming GNU Desktop - Gnome.

For starters, all the above are actually done, and exist.  The first
two are built into Guile, and the third is Marius's personal thing.
I'm hoping to work with Pat Eyler before and after the 1.3 release to
make these things easier to find on the Guile web site.

The next thing is, I think you should be a little careful about
people's feelings here.  One gets the impression that you haven't been
following discussion here much, because a lot of the issues you raise
have been discussed, recently.  You're kind of in the position of
telling people to do what they're already doing.

> 4. *Official* releases must be fairly frequent - every 3-4 months.

You are right.  Mea culpa.  I'm fixing this.


In general, I think your comments are on the mark.  Guile development
has been very slow in the last year.  However, I think we're back on
track now, if a bit behind schedule.