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 [long] Date: 23 Sep 2002 00:13:49 +0200 Sender: guile-devel-admin@gnu.org Message-ID: <87n0q9zn8i.fsf@zagadka.ping.de> References: <02090420222526.19624@locke.free-expression.org> <87n0qw45p4.fsf@zagadka.ping.de> <02091322183303.21934@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 1033223506 13919 127.0.0.1 (28 Sep 2002 14:31:46 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 28 Sep 2002 14:31:46 +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 17vIdE-0003cM-00 for ; Sat, 28 Sep 2002 16:31:44 +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 17vIdS-00005Q-00; Sat, 28 Sep 2002 10:31:58 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17vIcB-0008NF-00 for guile-devel@gnu.org; Sat, 28 Sep 2002 10:30:39 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17vIc6-0008MD-00 for guile-devel@gnu.org; Sat, 28 Sep 2002 10:30:37 -0400 Original-Received: from dialin.speedway42.dip1.dokom.de ([195.138.42.1] helo=zagadka.ping.de) by monty-python.gnu.org with smtp (Exim 4.10) id 17vIc3-0008L2-00 for guile-devel@gnu.org; Sat, 28 Sep 2002 10:30:31 -0400 Original-Received: (qmail 2979 invoked by uid 1000); 22 Sep 2002 22:13:49 -0000 Original-To: Lynn Winebarger Original-Lines: 135 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:1374 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1374 Lynn Winebarger writes: > The problem is the very definition of what modules are. That's > what I'm objecting to, and it is in there. I can only assume this > is in preservation of the current module system, Yes. > which is way too dynamic in nature. Others will disagree. If we _can_ have meaningful compilation together with our current, dynamic module system, we should offer it. A more static module system might allow better compilation, and we should try to not prohibit such a module system. Pretend that you have a Guile that implements the model as written down, with our current dynamic module system (or a slight variant of it). Assume that you have a specification for a new, static module system that you want to use with Guile. Is it possible to implement the new module system in such a way that the old compiler can generate code for it? (The code must only be correct, it must not be very good.) If not, what parts of the model stand in the way? What do you need so that the new module system can communicate with a new compiler, so that the new compiler can generate better code or produce better error messages, and can still generate correct code for the old module system? In any way, I don't see how we can proceed when we first need to agree on a new module system. The current system is widely used and we can only improve upon it in small steps. The 'new model' is a somewhat big small step, but I'm afraid we will not move at all when we don't make that step "because it is too small". > > 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. > > The biggest one is that there's a "current module" at evaluation > time and that it can be changed. That's a _huge_ requirement. I can't cleary see how you can do without a current module. It might not be an explicit global variable, but just as there is always a current lexical environment, there will be an associated current module, in my view. Can you sketch how the module system would work without a current module? > > 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. > > But, as I understand it, this is one of the problems that has > been encountered in practice (the interaction between macro expansion > and the "module" system). As far as I know, the problems stem from our imperfect integration of the macro expander and the module system, and because we currently expand macros lazily. Although this issue is not addressed directly, the new-model does not prohibit us to get it right. > > > 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. > > I almost always prefer code I'm using not to have some oddball > implicit semantics. If it's going to do something weird, I should specify > that it does something weird. Yes, I agree. The declarations should not be used to do something weird. The declarations can carry information about types of returned values when you want to allow the compiler to make use of this information. The most concrete declaration that I have in mind right now would be used to tell the compiler things like "this variable always holds R5RS 'car', feel free to produce inline code". But I start to think that we should allow declarations in other places, not just when defining a variable. You might want to import a binding and tell the compiler that it should/should not inline the contained function, say. So what about moving declarations from variables to bindings? When you import a binding, you get a new copy and can add to the declarations without affecting the declarations of the original binding. > I don't think it will hurt to reflect on this statement from > R5RS either: > > Following Algol, Scheme is a statically scoped programming language. > Each use of a variable is associated with a lexically apparent > binding of that variable. > > Now you may think I'm being pedantic, but I think discarding that > second sentence should at least give pause. Yes. But is R5RS true to this sentence itself? What about 'eval' and 'load'? Is it appearant to what variables a free reference in a form passed to 'eval' is associated with? What about a loading two files in succession where the second file uses a variable defined in the first? > >Is this related to the 'module' feature of recent versions of Dybvig's > >syntax-case implementation? If so, I think that it is implemented > >solely with renaming of identifiers and needs no support from the > >interpreter. Also, I think that the syntax-case modules are less > >powerful than ours since their semantics are fixed while ours can be > >cleanly extended. > > To the extent that we're talking about lexically scoped closures > with exportable bindings, yes I suppose. Though I'm not sure > what you mean by "cleanly extended". Maybe you can give > an example of what you mean. Hmm, scratch the "cleanly extensible". I was thinking about how our modules are implented as some data structures with associated operations and how you can work on these data structures and operation as long as you maintain the interface to the interpreter/compiler. Dybvig's macros are hackable as well, of course, and maybe more cleanly. I'll reply to the rest in a separate mail. -- 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