Re: scm_system_environment

[Mikael Djurfeldt]

Mikael Djurfeldt <address@hidden> writes:

> Hmm...  What is a "system environment"?

I realize I should add some more, since we are so out-of-phase wrt
time.  Also, please forgive if there are things I've misunderstood or
things where you are following a track different from what I expect,
because I'm currently a little out of touch.  (Will compensate that
during the X-mas holiday, though--he he. ;-)

1. Symbols

The main role of symhash (and it's weak sibling) was to hash names
into unique symbols.  Then it was contaminated by other functionality
as well, but the main role was this.

Note that this is a function which is orthogonal to the concept of
environments.  Therefore, for good modularity, the management of
symbols should be kept separate from the management of environments.
(There are tight connections, though.)

Therefore, whatever replaces symhash should probably reside in
symbols.c and not have a name suggesting that it is an environment.

2. System environment

There will of course be some kind of "core" module (a different thing
than the ) containing the basic bindings in Guile, but we haven't
defined the new set of modules yet.  If you are aiming at something
like this, I'd prefer if we could wait a little before introducing new
naming.  We should then instead immediately start to structure
bindings into modules so that we see what kind of partitioning we end
up with.  (We should actually do this now regardless.)

Note here that some of the basic bindings probably will go into a
safe-r5rs module (or something like that) while others will go into a
guile extension module etc...

3. Representation

If we are just hashing names into symbols, we don't need the heavy
data structure of an obarray.  I suggested "weak vector" for two
reasons:

1. To point out that whatever data structure is going to hold the
   symbols should be weak.  We definitely want to be able to "forget"
   symbols.

2. We should not try to "re-use" functionality in the environment
   code.  That would be bad modularity, and we might want to change
   the representation in order to speed up reading in the future.

   I mentioned "vector" because in my original implementation of weak
   hash tables, I used a vectors.  It was on average five times more
   efficient than the current implementation.  (Tom Lord replaced them
   with the alist-based ones.)

   I remember that they were reasonably compact---they had to be
   around five times longer than N.  This can be improved with smart
   hash techniques, such as double hashing.

Best,
Mikael