Re: guile: going the way of DEATH

[Telford Tendys <telford@triangle.triode.net.au>]

> 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've been saying the same since I started with guile.

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

Well being in flux is hopefully getting them toward some sort of order.
It is difficult to wave hands and make a perfect API appear, it is a
compromise between language design and the needs of users. Perl has
managed several major shuffles in it's structure without losing popularity.

Never the less, if there are aspects to the Tcl API that look good then
by all means post them up and see if we can use them.

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

GUI isn't a major issue to me at the moment, I can't speak for other
users but I feel that it is important that the door is left open for
GUI use but not important that any GUI stuff is well supported at this
stage. A good scripting language should be usable equally well with and
without GUI and should really not care where or how it is used.

GUI is one application among many.

> 4. Finally, Tcl was actively promoted for applications with frequent
>    bugfixes and releases.
> 
>    Guile in this sense, is doing the other way: the only 'official'
>    release is the brain-dead 1.2 (dunno about that one, but 1.0 took
>    about 8 (eight) seconds to load a 'guile' program on my old 486),
>    which is about 2 years old. On the other hand, the Red Bean folks
>    are quetly developing Guile at their site, making snapshots
>    available. However, snapshots are different from releases - they
>    don't give people a comfortable feeling of program's getting mature
>    and they don't give developers an incentive to make a program ready
>    for general public: one can just keep producing snapshots forever.
>    The snapshots are used just by a bunch of enthusiasts, thus lacking
>    wider feedback, so the developers may not get an idea of what
>    most people really need, what the *real* priorities must be!

Tcl is also older than guile (thinks?) and IMHO it is better to do something
right than do it quickly. Even now, Tcl isn't exactly dominant,
if anything is really big it's perl.

> In my opinion, the following must be immediately done about Guile:
> 
> 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.

Hiding the garbage collector would be excellent. No one knows how to
do it though, probably the current system is as close to hidden as possible.

>    Once we define and freeze the API, we may produce a Guile reference
>    manual which won't change in the future.

OK, if API must be frozen then all the more reason to make efforts to
get it right before getting it frozen. Making lots of releases each with
a different API is not going to help this end.

> 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

I'd toss out regular expressions since they are essentially a POSIX
thing and poorly supported on some (Microsoft) systems. I'm with you
on basic file I/O and console I/O because every system since CPM has
that and every programmer expects it. Anything supported by the ANSI
C library should be OK. R4RS is good because the spec is freely available.
I'd also like to add to the above that a SIMPLE BUT FLEXIBLE error handling
method should be supported that doesn't depend on owning any interrupts.

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

OK, the current module system is a bit of a shambles and everyone admits it.
Looking at the ELK web page, they claim to have dynamic loading completely
under control:

Full incremental, dynamic loading. This facility enables Scheme code
to load compiled Scheme extensions into the running interpreter (or
into the application) on demand. Complex Elk-based applications can be
decomposed into dynamically loadable components to avoid large,
monolithic executables. Furthermore, user-supplied extension need not
be written entirely in Scheme; they may include an efficient,
low-level layer written in C or C++.

Dynamic loading in Elk is supported on many platforms and is not
restricted to a dlopen() interface. Elk provides automatic
initialization of dynamically loaded extensions and takes care of C++
static constructors/destructors embedded in object files.

Does anyone know how they do their modules? Has anyone sat down and
written out a document to cover what exactly we want from a module
system and why? My main thoughts on the design aspects of a module
system are:

* What is the purpose of a module system?
--- Keep the core simple.
--- Keep extension programs in cohesive units.
--- Allow users to choose their degree of complexity.
--- Establish conventions for dynamic linking.

I think that we all agree on these points, maybe someone can add more.

* Questions on how to achieve the above:
--- Flat namespace or hierarchical namespace?
--- Conventions for symbols (e.g x::Y naming used in C++)?
--- Should we try to include some object-oriented conventions?

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

Just firming up exactly what the requirements are would be a good step
but I have to agree that getting the basics right is more important than
piling up the frills. The trouble is that there are a lot of good ideas
floating around and a lot of possible directions. When do you draw the
line, kill some things, keep others and call it done?

I'm in complete agreement about moving extensions out into modules
and I believe that is the direction that the current guile development
is going (possibly in a somewhat haphazard manner).

> 4. *Official* releases must be fairly frequent - every 3-4 months.
>    This would grant wide feedback, which, in turn, would grant, we are
>    working on right prioroties. Guile advertising must be somehow
>    aggressive - it must be emphasized that Guile IS a standard GNU
>    extension language, and it IS ready for general use. People must be
>    shown, how easy it is to write  stuff in Guile, how it simplifies
>    things compared to C/GTK+

Beats me why guile should have to advertise aggressively, as long as
it is making some progress and is useful to someone, why ram it down
the throats of people who don't want it? If someone is already comfortable
with Tcl/Tk then leave them comfortable, why would you even
want to get them to use some sort of Tcl->scheme translator unless
they themselves have some reason for leaving Tcl?

A few nice scheme web pages with tutorials, documentation, standards,
links to scheme applications and the whole bit would probably be a nice
way to show off a bit but there is already quite a lot of scheme stuff out
there, I'm not going to become a scheme evangelist, let alone start pushing
one particular dialect.

A tiny side-issue on garbage collection and ELK.

Seems to me that the ELK folks are targetting C++ coders first and C coders
just for completeness. I can see C++ gaining ground slowly on C but there
will always be C coders out there (people still use FORTRAN after all).
If you need to declare every automatic variable to the garbage collector
in C then you find it tedious. If you do it in C++ then you use a constructor
and it doesn't seem so hard anymore... maybe that is the angle that the
ELK folks are coming from; doesn't seem entirely foolish (but totally
incompatible with guile's conservative methods).

	- Tel