guile-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]