[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What replaces scm_register_module_xxx (Doc update?)
From: |
Marius Vollmer |
Subject: |
Re: What replaces scm_register_module_xxx (Doc update?) |
Date: |
21 Aug 2002 21:35:53 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Dirk Herrmann <address@hidden> 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
- Re: What replaces scm_register_module_xxx (Doc update?), (continued)
- Re: What replaces scm_register_module_xxx (Doc update?), Marius Vollmer, 2002/08/10
- Re: What replaces scm_register_module_xxx (Doc update?), Marius Vollmer, 2002/08/11
- Re: What replaces scm_register_module_xxx (Doc update?), Dirk Herrmann, 2002/08/17
- Re: What replaces scm_register_module_xxx (Doc update?), Neil Jerram, 2002/08/19
- Re: What replaces scm_register_module_xxx (Doc update?), Dirk Herrmann, 2002/08/24
- Re: What replaces scm_register_module_xxx (Doc update?), Neil Jerram, 2002/08/26
- Re: What replaces scm_register_module_xxx (Doc update?), Marius Vollmer, 2002/08/26
- Re: What replaces scm_register_module_xxx (Doc update?),
Marius Vollmer <=
- Re: What replaces scm_register_module_xxx (Doc update?), Marius Vollmer, 2002/08/12
- Re: What replaces scm_register_module_xxx (Doc update?), Dale P. Smith, 2002/08/17