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

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

> > Guile 1.4 will have full documentation.  I've been dragging on that
> > lately, but hopefully I'll get some writing done this weekend.
> > 
> 
> Will there be a 1.3.x before then so that incremental improvements
> made so far (most notably the 1.3 read performance problem) can be
> made available to users?

Yes.  1.3.2 will be out in the next few weeks or so, depending on what
Mikael threatens me with. :)  There may be others.

> > 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'.
> 
> This is really more an issue for package authors. Of course, the guile
> can help by provinding infrastructure, such as a package build system
> template and Autoconf/Automake macros.

Right --- most of these things aren't really module system specs per
se.  It's more like, "If you can't see a nice way to make the module
system and this requirement live happily together, go back to the
drawing board."

> >   - 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.
> 
> I've thought about this a bit, and there are some things it might be
> wasteful to get rid of. For example it would be silly to try to
> separate out, any mechanisms and data types used internally to
> implement Guile, such as hash tables (assuming those continue to be
> used as the basis of obarrays or whatever). Perhaps it would be
> sufficient to place the Scheme bindings for those things in a separate
> module that lives in the same library.

Some things are definitely in that class, and we will put them in
their own modules.  However, I don't see any reason to keep the items
I listed explicitly in the core.

Note that moving something out into its own dynamically linked library
does not necessarily mean we will *distribute* it separately from
Guile.  The distribution has the fuzzy goal of providing the stuff
everyone wants to assume is present without being too big.
Segregating code into separate libraries has the goal of making Guile
easier to understand, however you choose to distribute or install it.


> > 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). 
> 
> While this is generally true, a smart compiler that does some type
> inference can do very well. I believe Stalin is the canonical example.
> It supposedly generates better code than good FORTRAN implementations
> from some problems, out of Scheme code written in a natural style.

Are you *sure* you're talking about stock Scheme code, without special
declarations?  If so, then I really want to see that paper.  With
declarations, anything is possible.


> Of course, this is probably not relevant to guile, since dynamism and
> interoperability with other languages must take precedence over raw
> performance, but this is more a function of Guile's design tradeoffs
> than properties of the RnRS language.

I think it is relevant to Guile, because Guile is not just an
implementation --- it is also a language.  I hope tools like Hobbit
will continue to evolve, and we would like to consider the impact our
decisions have on their ability to generate spiffy code.

That's why things like "sealed" modules (i.e., you can find all the
references to car, and you see that it's never redefined, so you can
inline it) are relevant to Guile, even if Guile doesn't actually
perform that optimization.