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: comments on new-model.txt Date: 05 Sep 2002 21:06:15 +0200 Sender: guile-devel-admin@gnu.org Message-ID: <87n0qw45p4.fsf@zagadka.ping.de> References: <02090420222526.19624@locke.free-expression.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1031252886 24469 127.0.0.1 (5 Sep 2002 19:08:06 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 5 Sep 2002 19:08:06 +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 17n1z0-0006M7-00 for ; Thu, 05 Sep 2002 21:08:02 +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 17n20W-0005OK-00; Thu, 05 Sep 2002 15:09:36 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17n1zA-0004uk-00 for guile-devel@gnu.org; Thu, 05 Sep 2002 15:08:12 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17n1z0-0004tq-00 for guile-devel@gnu.org; Thu, 05 Sep 2002 15:08:11 -0400 Original-Received: from dialin.speedway42.dip103.dokom.de ([195.138.42.103] helo=zagadka.ping.de) by monty-python.gnu.org with smtp (Exim 4.10) id 17n1yz-0004t7-00 for guile-devel@gnu.org; Thu, 05 Sep 2002 15:08:02 -0400 Original-Received: (qmail 14133 invoked by uid 1000); 5 Sep 2002 19:06:15 -0000 Original-To: Lynn Winebarger In-Reply-To: <02090420222526.19624@locke.free-expression.org> Original-Lines: 95 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:1310 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1310 Lynn Winebarger writes: > Marius has written a detailed proposal for a new model, most of > which is dedicated to the nature of modules and scoping rules. Ick, it's in CVS (workbook/compilation/), but I'm not yet really prepared to defend it! ;) Actually, I have tried to keep the module system out of the model as much as possible. The interface between the module system and a hypthetical compiler is quite minimal. The module system is very important for the overall behavior of the system, but my intention is to allow large changes to the module system without having to change the compiler. The biggest requirement that the proposal puts on the module system is that modules can only ever grow; you can not remove bindings or change existing ones. I expect this to be a popular point for debate, and I don't know if I can defend it successfully. But the current model rests on this requirement. (When you want to change a module in a way that is not allowed, like removing a binding, or importing a name from a different module, you need to make a new module with the same name and fill it from scratch, probably by recompiling/reloading it. Modules that depend on your module might also need to be recompiled/reloaded to pick up the changes. Maybe we can have support for constructing new modules in a way that they export the exact same bindings that a given other module does. That way, the recompile avalanche could be stopped early.) > Marius' proposed system makes choices . > If by a module we mean a set of code that is meant as a unit for > separate compilation, I believe the right choices are > . I hope that the model is 'open' enough to allow all variants. I'd say that when you have a model that allows , you can get the other variants via additional, external restrictions that don't require changes to the model. For example, the lexical option for (1) can be implemented within the module system by allowing a module to be 'sealed' so that no further bindings can be added to it. That is compatible with the model. Option 'closed' for (2) can likewise be implemented within the module system by simply not offering any way to export names. The model doesn't care. Option 'body' for (3) is harder to enforce in the module system, but it is easy to add in the macro expansion pass which is also not treated in detail in the proposal. My goal for the new model was to specify something that would be straightforward to implement, offer enough opportunities for a smart compiler to optimize things, and still be reasonably flexible for interactive use. > There is no reason to require macros to always be macros. R5RS does > not have any such requirement and there are plenty of compilers for it. You can change a macro into a function, but you need to recompile/reload your code for it to take effect. That's about all that the model implies. Also, you can't redefine a name in a module, but I think that is reasonable. > I do not agree with the stated use of the word "variable". That term > has such a standard definition that I believe it is only confusing to > recast it to mean "generic box" (in the "smart variable" case). Well, it's only terminology. What you seem to call "variable", I would call "identifier". I agree that terminology is important, ultimately, and I can change the word "variable" to "box" or "location", but I don't want to be distracted by this just yet. > Rather than tying imported variables to solely to modules, I > believe GUILE should adopt 2 new types of variables, extloc and > extvar (or whatever) corresponding to ilocs and variables, but > carrying a reference to their environment with them. Space might be > conserved by pointing into a table of environments rather than using > a whole pointer. In this way we can untie option 2 from options 1 > and 3. I don't understand. Can you explain? > To handle optimization, I believe we could adopt special forms > that import values and bind them to local (possibly immutable) > variables. [...] This sounds more complicated than the 'declarations' feature of the proposal. The declarations have the advantage that you don't need to do anything special when importing a name, the burdon is on the definer of the name. -- 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