From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: What replaces scm_register_module_xxx (Doc update?) Date: 21 Aug 2002 21:35:53 +0200 Sender: guile-devel-admin@gnu.org Message-ID: <874rdot36u.fsf@zagadka.ping.de> References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1029958511 7449 127.0.0.1 (21 Aug 2002 19:35:11 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 21 Aug 2002 19:35:11 +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 17hbG1-0001w2-00 for ; Wed, 21 Aug 2002 21:35: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 17hbH9-0005vN-00; Wed, 21 Aug 2002 15:36:19 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17hbGm-0005pB-00 for guile-devel@gnu.org; Wed, 21 Aug 2002 15:35:56 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17hbGh-0005oh-00 for guile-devel@gnu.org; Wed, 21 Aug 2002 15:35:55 -0400 Original-Received: from dialin.speedway43.dip252.dokom.de ([195.138.43.252] helo=zagadka.ping.de) by monty-python.gnu.org with smtp (Exim 4.10) id 17hbGh-0005oc-00 for guile-devel@gnu.org; Wed, 21 Aug 2002 15:35:51 -0400 Original-Received: (qmail 6815 invoked by uid 1000); 21 Aug 2002 19:35:54 -0000 Original-To: Dirk Herrmann In-Reply-To: Original-Lines: 102 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 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:1133 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1133 Dirk Herrmann 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