API for introduction of bindings

[Mikael Djurfeldt]

Dirk Herrmann <address@hidden> writes:

> [M]y 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.

I have previously promised to coordinate development towards a new
module system.  However, I've been more busy than I've expected.  In a
few days, my Christmas holiday will start, so, although I hope to get
help from others, I really think we should try to replace the old
module system during Christmas.

So, my suggestion is that while we can talk about the new API, we wait
with making big changes until the details about the new module system
becomes clearer.  This should only be a matter of a couple of weeks.

I suggest that we instead focus on the problem of dividing the current
set of bindings into a nice hierarchy of modules, like
"(core safe-r5rs)", "(core r5rs)", etc.  (I think Maciej and Jim had a
preliminary proposal, Maciej? Jim?)

Regarding your suggestion above, I think the action of creating new
bindings during initialization of a module is common enough that it
could be an advantage to use calls which have the module as an
implicit argument, set by scm_select_module (i.e. the module would not
be explicitly passed as an argument => functions like gh_new_procedure
would not need to take an extra module argument).

Mikael