guile/devel/policy/plans.text

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.