Re: Everyone is thinking about the future

[forcer <forcer at mindless dot com>]

Telford Tendys <telford@eng.uts.edu.au> writes:

> > - The numerical tower will be replaced.
> 
> The current tower is a bit messy but reasonable. The trouble is
> that it is monolithic -- when I added matricies I found myself
> writing a completely new tower that had the prefix ``matrix-''
> in front of everything. The BLAS wrappers were similar.

I was thinking more about the GMP library inclusion. The one big
problem now seems to be on how to efficiently add numbers. The
GOOPS type dispatch seems nice, but i think GOOPS would be a
little overhead. (my first idea was to have a "fixnum" type,
e.g. int, and a "bignum" type which has an extra tag that indexes
into an array of basic functions. But i haven't thought through
this yet, and i'm not too familar with the speed implications)

> > - The environments will be replaced.
> > - The module system will be replaced.
> 
> Is there yet a cohesive concept of what these things do and how?
> I'd be happy to release my code as guile modules but I'm yet to figure
> out how it should be done... Can I release some modules on shared object
> form and some in scheme form?

The environment stuff is in guile-doc/ref/env.texi at least in
it's proposed form. We might see it's inclusion sooner or
later. The module stuff will be rebuilt on top of this.

Scheme modules are easy to write - check the ice-9 tree - whereas
shared library modules are a bit more difficult right
now. Somewhere in the guile CVS is an explanation on how it
works. :]

> > - Most of the stuff in the guile core is slowly being put out into
> >   modules.
> 
> This last one is the most important. I would like to see guile
> cut into independent chunks, each with an independent maintainer to
> prevent monolithic vitrification:
> 
> * A storage system with
> --- garbage collector
> --- type flags
> --- really primitive types, just strings and numbers should be enough

Strings, i have to add, in the Guile character set and storage
type ...

> * A hash table system that sits on the storage system
> * A port system that can read and write files but does not know
>   about any data types (except ports). Must have a way of allowing
>   higher level units to register types for reading and writing (difficult)

Not too difficult. The current port implementation is a bit
messy, but nice.

> * A general purpose evaluator that contains
> --- namespaces
> --- symbols
> --- conditionals / loops / function-definitions / procedure-calls

* An environment subsystem on which the evaluator sits

> * A numerical tower that works with or without the evaluator
>   (i.e. depends only on the storage system)

libgmp comes to mind

> * A POSIX chunk to provide system interfaces

Would be better as a "real" module

> * Advanced string manipulation

SRFI 13

> * etc... from here bolt on what you like

SRFI's, most importantly

> The missing link in all of this is how to allow these modules to fit
> together in a dynamic fashion (e.g. punt POSIX if it doesn't work on your
> system, etc).

Easy. Have a "core" guile, and modules that use the core's
external API to extend guile. SMOBs are quite nice.

	- Jorgen

-- 
((email . "forcer@mindless.com")       (www . "http://forcix.cx/")
 (irc   . "forcer@#StarWars (IRCnet)") (gpg . "/other/forcer.gpg"))