This file describes the current status and future plans for Guile development. * Status To give you an idea how far we are from the things described above, here is the status of some topics. Guile used to suck, but it doesn't any more. ** Documentation XXX - Losta stuff, and talk also about updating the web page. ** Object oriented programming Guile's object system is GOOPS. XXX - Some notes about characteristics and motivations. ** Multithreading At the moment, Guile supports co-operative threading on several platforms. We do *not* support true kernel threads at present, not because we don't think that would be way cool, but because it's really, really hard. We're taking continually taking steps towards that goal, however. Current status is that necessary basic changes to the garbage collector and the signal handling has been done. (Few are aware of it, but the SCM_DEFER_INTS/SCM_ALLOW_INTS macros no longer have any effect!) The major remaining work is to protect common resources using mutecis. *** Using Guile's COOP threads in a POSIX threaded application A recent change has made it possible to mix use of Guile's COOP threads and POSIX threads in a single application. This is useful, since some GNOME libraries links with pthreads by default. (Guile still has to run in a single POSIX thread, and the two thread systems needs to use independent sets of thread synchronization mechanisms, however.) ** Graphical toolkit You can access Gtk+ from Guile by using the (separate) guile-gtk package. The basic machinery of guile-gtk is mostly done but individual features of Gtk+ are missing. Adding these features is mostly the job of taking a look whether they are safe to export in unmodified form and when that is the case, writing a couple of easy lines of descriptions for the feature. This is mostly busy work. XXX - guile-tcltk? * Near Future What is planned for the near future. ** Breakpoints and single-stepping in the debugger Guile now has a debugger (try `(debug)'). We are planning to implement breakpoints and single-stepping, and then announce the debugger in README file and documentation. ** A new module system Integration of Jost Boekemeiers environment implementation. Greg Badros has promised to try to integrate them. On top of that, a new module system will be implemented, but: 1) We're not settled yet, 2) we're really trying to settle it, and 3) we're discovering why the rest of the Scheme scene isn't settled on this issue either. There will be a C API to the new module system. ** Factorization of Guile into function libraries Although Guile is meant to support composing a system from modules well, it does not make use of this principle itself. The core is quite monolithic and includes a lot of things that could be separated out. We will be moving such things as networking, posix and regular expression support to separate modules instead of having them all in the root namespace. ** Faster startup We will make Guile start up quicker. Guile's current slow startup is primarily due to 1. inefficient code in a time-critical place in the current module system, and, 2. that too much code is loaded at startup. ** Translators *** Framework Framework making it easy for application developers to add new translations. This includes the engines from flex and bison + a way to add new grammars from Scheme. *** C-like syntax for Scheme *** elisp *** tcl *** python *** Java * The Guile wishlist ** A byte compiler! New developments have made it possible to create very fast byte code interpreters. We are willing to replace the current Guile evaluator when a suitable candidate byte code interpreters turns up. It should fulfill the following criteria: *** It should be or promise to become significantly faster than the current evaluator. *** It should support or promise to support debugging and backtraces not much less informative than the current ones. *** It should support conservative GC. *** It should be possible to integrate with large parts of the existing Guile infrastructure. ** Revision and stabilization of interfaces Along with the updating the documentation, we should clean up the interfaces of Guile. It should be well defined which existing Scheme procedures and C functions and macros are supported as part of the "Guile language" and which are temporary procedures used in the implementation of Guile or historical remnants. ** Full R5RS compliance XXX ** SRFIs XXX ** Reorganization of the numeric code Numeric tower 3. Introduce a subclass of called . Such objects contain 7 pointers to C functions handling the argument combinations (), (INUM), (REAL), (INUM, INUM), (REAL, INUM), (INUM, REAL) and (REAL, REAL). When an is applied, it first uses simple if-statements to dispatch onto one of these "primitive methods". If that fails, it behaves as an ordinary generic, i.e., it does type dispatch. 4. Turn all standard Guile arithmetic, and comparison operators into s and break up numbers.c into independent modules. After this, we can easily add new types to the numeric tower. The new types will be handled a little bit slower than INUMs and REALs, but I think it will be fast enough. Some fundamental changes have already been done that make floating point calculations more efficient. ** Low-level support for hygienic macros Instead of a well integrated support for hygieneic macros, Guile provides three redundant ways of defining unhygienic macros: `procedure->macro', `defmacro' (with `defmacro-public'), and, `define-macro' (which lacks a "public" version). There is a syntax-case macro module (hygienic), but that macro system is written in Scheme and makes loading time extend even further beyond it's current unacceptable level. Guile macros are not compatible with Guile's module system. If you export a macro, you need to explicitly export all bindings which it uses. This needs to be fixed. It might be benefitial to separate memoization and execution to better support macro expansion and compile time optimizations. The result of the macro expansion and memoization pass could be permanentaly stored on disk to reduce the load time of large programs. This would also make the integration of a real compiler easier. See next point. ** Compiler Hobbit doesn't support all of the Guile language, produces inefficient code, and is a very unstructured program which can't be developed further. It iss very important that the compiler and interpreter agree as much as possible on the language they're implementing. Users should be able to write code, run it in the interpreter, and then just switch over to the compiler and have everything work just as it did before. To make this possible, the compiler and interpreter should share as much code as possible. For example, the module system should be designed to support both. They should use the same parser and the same macro expander. ** CORBA The way many of the major applications in the GNOME/Gtk+ world are moving is this: Core application code is written in C or some other similarly low-level langauge. However, internally it consists of Bonobo components. Bonobo components should in theory be accessible from any language (someone really ought to write ORBit-guile) and can be recomposed in ways other how the application originally intended. Thus, Gimp and Gnumeric will eventually in effect provide pieces that can be used from Guile (and other langauges) and recombined; however, these components will be written to the Bonobo API, not the Guile API, and will require a CORBA mapping for the target language to work. There are advantages and disadvantages to doing things this way as compared to writing Guile modules; but in either case we must be prepared to play in this brave new world of components by ensuring Guile has the proper tools available, because I don't think we are going to convince the GNOME people that Guile modules provide all they want from a component model. ** POSIX threads support XXX ** Faster GC We hope so. If someone came up with a running GC that's faster than what we've got now, that would be extremely interesting. But this isn't a primary focus. ** Test suite XXX ** Internationalization/multilingualization XXX ** Integration of Guile into GNU programs XXX *** Emacs XXX *** The Gimp XXX ** Soft typing XXX - combine with compiler section? ** Importing changes from SCM XXX ** Guile module repository 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. ** More frequent releases We will try to make Guile releases more frequently. ------------------- XXX - add the following to HACKING? ** The CVS repository *** The current CVS version of Guile should always compile The current CVS version of Guile should always compile and not contain major bugs. *** Applying patches A Guile developer should always fully understand the code in a patch which he applies, and is responsible for the quality of the applied patch. *** Experimental code Experimental code should be kept in the local working copy or committed onto a branch. The only exception is when some kind of feedback is needed from other developers or users.