Re: scm_system_environment - OK

[Mikael Djurfeldt]

Dirk Herrmann <address@hidden> writes:

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

Hmm..  Actually, those two hash tables *together* held the symbols for
the root module.  (There was a strange loop in the lookup function
which started over with weak_symhash if symhash failed.)

I think it's OK to replace symhash and weak_symhash with one weak
table.

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

Yes, this is exactly the kinds of things I was referring to when
talking about "representation".  The fastest thing we could possibly
have is a weak vector (with resizing).  (A hash miss simply means
checking next entry (increment by one), and next etc until hit or free
slot is found, or up to a limit where the table needs growth and
rehashing.  More advanced hash techniques exist if this causes the
table to grow too large.)

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

Yes.

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

Exactly.

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

This is a kind of change that I'd really not want just to happen.
While it is good for Guile development if you don't wait for OK from
the maintainers if you know for sure what we would say about it, we
need to talk about more profound changes like this before you commit
the change.

[...]

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

Good.

Let's have a discussion on the list.  Let's introduce it under a
different title.

Mikael