This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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



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

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?

> The next issue I want to address is the module system. 

Yay!

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

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

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

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.

 - Maciej