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