Re: What's after guile-1.4? (was: Re: Questions... I am new to scheme)

[Jim Blandy <jimb@red-bean.com>]

Here are my plans for Guile:

Guile 1.4 will have full documentation.  I've been dragging on that
lately, but hopefully I'll get some writing done this weekend.

The next issue I want to address is the module system.  Guile needs to
have the following qualities (note that package != module):
  - It should be easy for people to distribute independent Guile packages.
  - Once you've downloaded a Guile package, installing it should be as
    easy as 'configure; make install'.
  - The above should be true whether the package is written in Scheme, C
    (yielding either dynamic or static libraries), or any other language
    that Guile supports.
  - It should be possible to use packages in combinations not
    explicitly planned for by their authors.  That is, the system
    should allow people to write packages in such a way that they
    won't conflict with other polite packages.
  - Guile itself should be segregated into independent packages.
    The true Guile core should contain nothing but an R5RS interpreter
    and enough to autoload any module.  Then, stuff like POSIX,
    sockets, readline, and uniform arrays should be dynamically linked
    in on demand.  Perhaps even threading could be segregated out, but
    that's the kind of wild statement one should back up with a
    design, so don't take it too seriously.

Also, as time goes on, I think people will write more compilers and
pre-processors that generate code for Guile to run.  At the moment:
  - Hobbit generates C code from Scheme code.
  - Chris Hanson has volunteered to work on a byte compiler and
    interpreter as his time permits.
  - Things like GWrap and Marius's GTK stuff generate interface code
    from specs.

So we can add to the list of qualities further:
  - Guile should recommend build and installation procedures as much
    as is helpful.
  - Guile should provide dependency tracking, to warn you when
    something is out of date.  The only reason this is so clumsy with
    C code is that the different compilers and makes can't agree on
    how it should be done; since we are designing these tools anew, we
    can do much better.

Now, there's a lot there which is outside the scope of a module
system.  But, unfortunately, it seems to be easy to design a module
system that gets in the way of those, or doesn't help as much as it
seems it should.  So I want to keep them in mind as we design it.
Perhaps Guile 1.5 will have the module system essentially in place.

Then I would like to try to reliably support real system threads.
This is one of those tasks that will involve going over every line of
Guile with a fine-toothed comb, but Niibe-san has already done some of
the hardest work.  I hope he'll be willing to help me with this.


As I go along, I want to tackle the following:

I want Guile to become more stable.

I want to help Maciej in any way I can with the Guile Modules AND
Packages archive (the GMAP).

I would like to turn the GH interface into a SRFI, so that people
can write C code to link with a variety of Scheme systems.  Probably
the SRFI will require conservative GC.  Someone else can write another
SRFI that extends that one with a standard for explicit marking.

I would like Guile to have a generational GC.  If Greg Harvey's plans
work out, great.  If he decides to pass the baton, or someone else
gets something good running finst, then that's fine too.  (Note: I'm
not saying Greg's plans won't work.  I'm just saying that the Guile
project isn't loyal to any particular project in progress, and that
we'll accept the first solid implementation.)

I would like to improve Guile's text-processing speed.  Gary Houston
has sent me some patches I want to look over this weekend.

I would like Guile to support Unicode.  I want to look at Perl and Tcl
for ideas.

I would like Guile to have decent support for numeric computation.
Most likely this means giving Guile good tools for communicating with
numeric code written in other languages, as RnRS Scheme is inherently
unsuitable for numeric work (too much polymorphism).  However, I can't
do the design work myself, so I'm relying on the guile-numeric mailing
list.