Re: scm_system_environment - OK

[Dirk Herrmann]

Sorry for answering this late...

On 16 Dec 2000, Mikael Djurfeldt wrote:

> You have maintained the separation between symbols and environments.
> The role of symhash and weak_symhash is now handled by the weak key
> hash table "symbols".

Yes, although I'd like to clarify this a little bit:  Up to now I only
replaced scm_weak_symhash, because this was the hash table that stored
symbols weakly.  The other table, scm_symhash, is not yet replaced,
because this is the table that holds the bindings of the-root-module.

BTW:  an optimization would be to replace the weak-key hash table for the
symbols by some specialized hash table that does not store (<symbol> . #f)
pairs, but only weak symbols.  Maybe it could also be auto-resizing, but I
am not sure about that.

> You mean for scm_system_environment to store system bindings until
> we've broken Guile up into modules.  Since you've already done this
> work, I think we shouldn't make any changes but keep it.

Well, actually I am currently not quite sure what would be the right
thing to do.  Currently, as I said above, scm_symhash holds all bindings
of the later root module.  My plan was, to replace scm_symhash by a
leaf-environment called scm_system_environment.  This step is not
difficult, but I am not sure if this is what we want.  Later, we don't
want to operate on environments, but rather on modules.  The environments
are just a means to implement modules.  Thus, I wonder if instead of
introducing an _environment_ scm_system_environment to store the initial
bindings, we should rather introduce a _module_ scm_system_module, that
holds the bindings, and also has an explicit list of exported bindings
(for example in form of an export-environment).  This would also unify the
handling of the root module and all the user created modules.

However, the problem is, that we don't have a finished design for the
modules yet.  Switching to scm_system_environment might therefore make
sense as an intermediate solution.  However, my plan for the switch
included to replace all calls to scm_intern and friends with the
appropriate calls to scm_environment_define, scm_environment_ref,
scm_environment_set and scm_environment_cell, and then to deprecate these
functions.  With a definition of modules, these calls would then again
have to be changed to calls to scm_module_define, scm_module_ref,
scm_module_set and scm_module_cell, plus calls to scm_module_export where
this is appropriate (or maybe the module API will be quite different?)

Before I proceed, I'd like to hear opinions about what would be the best
way to go on and ideas about how the later module API could look like.

> Please forget about my comments and sorry for bugging you.  From the
> ChangeLog I got the impression that something scary was going on.  :)

No problem.  In fact, for me it is good to know that people look at the
things I do and don't hesitate to question or criticize.

Best regards,
Dirk Herrmann