[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: API for introduction of bindings
From: |
Dirk Herrmann |
Subject: |
Re: API for introduction of bindings |
Date: |
Mon, 18 Dec 2000 11:09:33 +0100 (MET) |
On 17 Dec 2000, Mikael Djurfeldt wrote:
> 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).
Well, I'd prefer if the module was explicit. I think the main reason is
just that I somehow feel it would be the right thing, although I can
certainly also give you a couple of 'real' reasons:
* We can expect that a single file will hold definitions for different
modules, for example in list.c we will have definitions for r5rs, but
also for some srfi plus guile extensions. Moving the code of the
definitions around in such a file is more error prone if the target
module of the definition somehow depends on the relative position of the
code within the file. The same applies for moving functions between
different files.
* Grepping for definitions in a certain module is easier if the target
module is explicitly given in the definition.
* If the target module is determined at the callers side, it is possible
to optimize a set of definitions for the same target module, since the
looking up has to be performed only once. (This is probably not of
interest for the startup initializations. However, maybe there is some
code that would benefit: With threads, each lookup of the current
module requires a call to getspecific.)
Besides these reasons, I don't think that giving the target module
explicitly is that much of an overhead. The switch to the new set of
snarfing macros will force us to touch every definition anyway. As this
switch can be done incrementally, so can the adding of the target module
names, where some 'root' module is the default for the old style
SCM_DEFINE definitions.
Best regards,
Dirk Herrmann
- 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, 2000/12/17
- 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 <=
- 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