From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dirk Herrmann Newsgroups: gmane.lisp.guile.devel Subject: Re: What replaces scm_register_module_xxx (Doc update?) Date: Sat, 17 Aug 2002 10:09:04 +0200 (CEST) Sender: guile-devel-admin@gnu.org Message-ID: References: <87hei1dltt.fsf@zagadka.ping.de> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: main.gmane.org 1029571753 23518 127.0.0.1 (17 Aug 2002 08:09:13 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 17 Aug 2002 08:09:13 +0000 (UTC) Cc: guile-devel@gnu.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17fydx-00066T-00 for ; Sat, 17 Aug 2002 10:09:09 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17fyet-0006lW-00; Sat, 17 Aug 2002 04:10:07 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17fye0-0006Sk-00 for guile-devel@gnu.org; Sat, 17 Aug 2002 04:09:12 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17fydx-0006OW-00 for guile-devel@gnu.org; Sat, 17 Aug 2002 04:09:11 -0400 Original-Received: from sallust.ida.ing.tu-bs.de ([134.169.132.52]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17fydw-0006Mn-00 for guile-devel@gnu.org; Sat, 17 Aug 2002 04:09:08 -0400 Original-Received: from localhost (dirk@localhost) by sallust.ida.ing.tu-bs.de (8.9.3+Sun/8.9.1) with ESMTP id KAA12767; Sat, 17 Aug 2002 10:09:04 +0200 (CEST) Original-To: Marius Vollmer In-Reply-To: <87hei1dltt.fsf@zagadka.ping.de> Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:1108 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1108 Hi, I have some comments and questions regarding the text. On 12 Aug 2002, Marius Vollmer wrote: > A Guile module is a data structure with the features described in the > following sections. You can work directly with the data structure in > your programs, but normally you refer to them indirectly via the > familiar hierachical names like @code{(ice-9 popen)}. I think it would be helpfull to explain that there is no relationship between modules named (a b) and (a b c). People might assume that there is some subset/superset relationship. Especially since I remember that once there was such a concept in guile. > @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. And, the possibility to register a module implies that people can create modules dynamically. But, there are no functions described to create modules dynamically. > @c I think the following paragraph is confusing here, especially > @c given that there are objects called ``envrionments'' in Guile > @c that are really modules. - mvo Yes, we should attempt to be cleaner with our names. Environments should be used for lexical environments. I also don't like the name 'variable' since it rather names a location than a variable. 'Location', on the other hand, is also not quite accurate, since local variables are also stored in locations, but for these there are no variables. At least we should not use names used in R5RS to name concepts which are not exactly the same. > @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? > 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. > 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. In other words, while executing a top-level expression, the current-module corresponds to the top-level environment of that expression. When a closure is created, is closes over the current top-level environment. As soon as a closure is executed, it is executed in the context of the module that corresponded to the top-level environment at the creation of the closure. > Execution of a @code{define} form can add a new variable binding to > the current module. When the symbol in the @code{define} form is > already bound to a variable, the binding itself is not changed, only > the value of the variable. When the symbol is bound but not to a > variable, an error is signalled. Maybe some clarification would be helpfull: There are also internal defines, which are not meant here. > 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. > Note in the previous example that if the current module had already > defined @code{open-pipe}, adding the binding from @code{(ice-9 popen)} > would have resulted in an error. For this reason (and others), there > is a second variation of interface specification that not only names a > module to be accessed, but also selects bindings from it and renames > them to suit the current module's needs. For example: 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. > The second variant of @var{spec} is > > @smalllisp > (MODULE-NAME [:select SELECTION] [:renamer RENAMER]) > @end smalllisp 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? Best regards, Dirk _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel