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

[Maciej Stachowiak <mstachow@mit.edu>]

jimb@red-bean.com writes:
> 
> 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.
> 

Way cool. 

> > 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.

I agree with you on all itmes you explicitly listed.

> 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 agree with this attitude as well (in fact I had assumed 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.
> 

I will look up some better Stalin references, but yes, I believe it is
stock Scheme codew with no declarations, the only significant change
being the lack of `load' (which is dealing with a problem a `sealed
module system' as you describe it could also solve). I have heard of
some optimizations Stalin does and they are pretty amazing - for
instance it can find all sites where a procedure can possibly be
called with `apply' and generate inline code to do the application
without any extra consing. Stalin does an amazing amount of
dataflow analysis.

> 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.

A sealed module system would definitely help to optimize a lot, but I
think reaching Stalin-level optimizability would require even more
changes, some of which may be in conflict with Guile's useful dynamic
properties. For instance, I think the feature of importing or creating
a module at runtime is very useful - it can be used to isolate
untrusted code for instance. But it also conflicts with some smart
optimizations.

 - Maciej