Re: What replaces scm_register_module_xxx (Doc update?)

[Marius Vollmer <mvo@zagadka.ping.de>]

Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes:

> I think it would be helpfull to explain that there is no relationship
> between modules named (a b) and (a b c).

Yes.

> > @deffn Procedure find-module name
> > @deffnx Setter (set! (find-module name) module)
> > The procedure @code{find-module} returns the module that has most
> > recently been registered with the name @var{NAME}.  When no module has
> > been registered under @var{NAME}, return @code{#f}.
> 
> I'd find it clearer when registering a module would be done using a
> function 'register-module' instead of using a setter.

Hmm, I was experimenting with the way Common Lisp does it.  They have
'find-class' that is also a setter for registering classes.  I don't
know yet whether I like it or not.  The text that I posted is not a
serious proposal, only some loose ideas.

> > @c An environment is a mapping from identifiers (or symbols) to
> > @c locations, i.e., a set of bindings.  There are top-level environments
> > @c and lexical environments.  Environment in which a lambda is excuted is
> > @c remembered as part of its definition.
> 
> What is the relationship between modules and top-level environments then?

They are identical.  (Are they?)

> > You can only add to the set of bindings of a module, you can not
> > remove bindings.  Also, you can only have a single binding for
> > each symbol in the set.  As a consequence, once you have added a
> > local or imported binding to a module, it can not be changed.
> > Attempting to bind a symbol to the same object that it is already
> > bound to is silently ignored.
> 
> With respect to modules this means that there is no undelete.  Good.  And,
> if this also applies to top-level environments, then memoization of
> variable locations can be used.
> 
> > These rules ensure that a module can only evolve in a simple manner.
> > Once you have looked up a binding in a module, you can be sure that it
> > remains valid and that all lookups with the same symbol in a module
> > will return the same binding.  When you need to make changes to a
> > module that are not allowed by these rules, you must abandon the old
> > module and create a new one.  Modules that use the old module in some
> > way need to be reconstructed as well, and so on.  See @pref{FIXME} for
> > more information about this.
> 
> Hmmm.  This needs to be clarified, especially with respect to memoized
> code.

Yes, this is actually the big point.

> > When Guile executes or compiles some code, it does this always in the
> > context of a module.  That module is called the @dfn{current module}.
> > Set settable procedure @code{current-module} can be used to access the
> > current module.  The global identifiers of the executed or compiled
> > code are looked up by finding the object that is bound to the
> > identifier symbol in the current module.  In certain contexts, the
> > object must be a variable so that it can be referenced or set, in
> > others, it is also allowed to be a macro transformer which is then used
> > to expand the evaluated form.
> 
> I think this paragraph is incorrect:  Only when guile executes some
> top-level expressions the lookups are done in the current module.

Yes, exactly.  I was only thinking about top-level forms, but haven't
said so explicitely.

> > To access bindings from another module, the desired bindings are
> > simply copied into the accessing module.  There are several ways to
> > select which bindings to copy exactly and how to transform the symbols
> > on the way.  Ultimately, however, imported bindings are added just
> > like local bindings.
> 
> That means, modifying a value at the location of a binding will also
> modify the value for the source module.

Ahh, good point.  I don't think we want to allow this.  That is,
'define' will only reuse local bindings and will complain about
existing imported bindings.  I had hoped that the distinction between
local and imported bindings doesn't need to be made...

> Ahh.  Conflicting imports will result in errors.  But:  What happens if an
> imported binding is overwritten by 'define' in the current module?
> According to R5RS, in such a case 'define' becomes 'set!'.  And this would
> influence the source module of the definition.  Hmmm.

Yes, no good.

> Can one use the same module several times, every time specifying
> some different SELECTION and RENAMER?  Can the same variable be
> imported several times under different names?

Yes, that is the intention, but I haven't thought about the consequences.

Thanks for your comments!

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel