[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: scm_system_environment - OK
Re: scm_system_environment - OK
Sun, 17 Dec 2000 16:53:58 +0100 (MET)
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.
- scm_system_environment, Mikael Djurfeldt, 2000/12/15
- Re: scm_system_environment, Mikael Djurfeldt, 2000/12/15
- scm_system_environment - OK, Mikael Djurfeldt, 2000/12/16
- Re: scm_system_environment - OK,
Dirk Herrmann <=
- Re: scm_system_environment - OK, Marius Vollmer, 2000/12/17
- Re: scm_system_environment - OK, Mikael Djurfeldt, 2000/12/17
- API for introduction of bindings, Mikael Djurfeldt, 2000/12/17
- Re: API for introduction of bindings, Dirk Herrmann, 2000/12/18
- Re: API for introduction of bindings, kxn30, 2000/12/18
- Re: API for introduction of bindings, Mikael Djurfeldt, 2000/12/18
- Re: API for introduction of bindings, Michael Livshin, 2000/12/18
- Re: API for introduction of bindings, Martin Grabmueller, 2000/12/18