-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
-
-XXX - ???
-
-*** C-like syntax for Scheme
-*** elisp
-*** tcl
-*** python
-
-* The Guile wishlist
-
-** 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 <generic> called <arithmetic-generic>.
-
- 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 <arithmetic-generic> 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
- <arithmetic-generic>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.
HCoop / bpt / guile.git / commitdiff