This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Hello everybody, 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. John Osterhout's Tcl was designed with several goals in mind. So far, Guile hasn't addressed any of them: 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. 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. 3. Tcl has a very elegant GUI toolkit, which is not just a set of X11 or Motif bindings. 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! All the above, in my opinion, is steadily leading us to the death of Guile. People will forget about it long before the next release and the only thing they will remeber would be the "Guile vs Tcl" flamewar, which led to nothing. Still, I think we have a chance. We must learn a number of lessons and if we do that, we'll be able to revive the project and to make Guile a standard and reliable GNU extension language. 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. Once we define and freeze the API, we may produce a Guile reference manual which won't change in the future. 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. And that's basically it. This would be THE Guile and it would be a perfect base for further extensions development. People would be able to provide extensions without cluttering Guile itself. After all, not everybody needs SCSH compatibility, let alone the notorious Ice - 'Guile Operating System'. 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. In the meantime, we may adapt the existing version of Guile to THE Guile. But in the future, we may consider rewriting the Guile interpreter from scratch to get away from SCM legacy. 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. 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+ I'd like to hear your comments. In particular, I'd like to hear from Guile development team. What I propose requires significant changes in their practices, so I'd like to know, what they think about it... Regards, -- Alexander L. Belikoff Bloomberg L.P. / BFM Financial Research Ltd. abel@bfr.co.il