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: 12 Oct 2002 15:35:16 +0200 Sender: guile-devel-admin@gnu.org Message-ID: <87u1jrok4r.fsf@zagadka.ping.de> References: <02090420222526.19624@locke.free-expression.org> <02091322183303.21934@locke.free-expression.org> <87it0vyx2f.fsf@zagadka.ping.de> <0209281703090C.01584@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 1034429967 4905 127.0.0.1 (12 Oct 2002 13:39:27 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 12 Oct 2002 13:39:27 +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 180MUH-0001Gz-00 for ; Sat, 12 Oct 2002 15:39:25 +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 180MTz-0006ku-00; Sat, 12 Oct 2002 09:39:08 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 180MTR-0005r0-00 for guile-devel@gnu.org; Sat, 12 Oct 2002 09:38:33 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 180MQN-00045O-00 for guile-devel@gnu.org; Sat, 12 Oct 2002 09:35:29 -0400 Original-Received: from dialin.speedway42.dip81.dokom.de ([195.138.42.81] helo=zagadka.ping.de) by monty-python.gnu.org with smtp (Exim 4.10) id 180MQD-00042U-00 for guile-devel@gnu.org; Sat, 12 Oct 2002 09:35:13 -0400 Original-Received: (qmail 26926 invoked by uid 1000); 12 Oct 2002 13:35:16 -0000 Original-To: Lynn Winebarger In-Reply-To: <0209281703090C.01584@locke.free-expression.org> Original-Lines: 138 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:1536 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1536 Lynn Winebarger writes: > On Tuesday 24 September 2002 15:03, Marius Vollmer wrote: > > Lynn Winebarger writes: > > > > > So part of the miscommunication is that I've stopped thinking of > > > "top-level" (lexically open) environments necessarily being at the > > > actual top-level of a lexical environment. > > > > What is there instead, then? Or, where would the open environments > > be, if not at the top of lexical environments? > > Well, the clearest example I can think of is in a threaded model. > Each thread could have its own top-level, _above_ the thread-global > top-level environment. Thus, in such a model, a identifier could reference different variables depending on the thread that executes the code that contains the identifier? This would indeed be something that is not covered by new-model.txt, but I don't really want to go there. I think we should not get too dynamic with variable lookups. Instead, we might have smart variables that do fancy things upon access. > These would essentially play the role dynamic roots play now, but > hopefully with cleaner (or at least uniform) semantics. How are our current dynamic roots related to variables and modules? > > > It complicates define a little, but not much. > > > > Can you spell out this complication? I think that will help me to > > understand better. > > Well, it's just _where_ will a define do its business. Let's say > I am interpreting `(define x 5) in the environment > `(,toplevel-B ,toplevel-A). Aha! I think I get it now. In my model, a chain of environment frames always ends in a single 'toplevel' frame that points to a module. In your model, frames which point to modules are not restricted to be at the end of the chain, right? There can also be two frames pointing to different modules, like in your example above, right? Is there a system that works like your example? Could we achieve the important eefects of your example by creating modules that mimic them? That is, instead of allowing more than one module-frame at the end of a frame chain, could we implement a module that, when put at the end of a chain, would behave as if two module-frames would there? > If x isn't bound in either A or B, it's clear (I think) you want > to create a binding for x in B (not A). Likewise, if x is bound in > B, then the define should just act as a set! on that binding. Now > what happens if x is bound in A? Should the define just be a set! > on the binding in A, or create a binding in B? We have already a situation that is similar to this: importing bindings from one module into another. The new-model.txt is not really affected by this; this needs to be addressed by the module system (which I don't really want to talk about here). > > [connection between a module mentioned at compile time, and the > > corresponding module used at run-time.] > > > > It would be a win if we can make that connection in a way that doesn't > > rely on module names. > > We can. [...] Sorry, I don't see how from your explanation. > > > (define a (load-module "foo")) > > > (define b (load-module "foo")) > > > (import a (prefix "a->")) > > > (import b (prefix "b->")) > > > (set! a->bar 5) > > > (set! b->bar 7) > > > a->bar => 5 > > > b->bar => 7 > > > > How would this work with macros? 'a->switch' might be a macro, but > > the compiler might not be able to figure this out since it can not > > know in general what 'a' refers to. > > As long as you can assume that "foo" refers to the same > compiled module at compile time (on the developer machine) as at > run-time (on the user machine), (I think we can assume this.) > or some reasonable variant thereof (via some versioning mechanism), > then I think the compiler can know whether its a macro or not. In your example, yes. But what about code like (define a (load-module (string-append "fo" "o"))) Is the compiler required to figure out what the string-append form evaluates to? I think it is easy to see that this does not work in general, for more complicated code. > I meant you could use modules as an object system with compiled > methods. Do we want that? That seems like a too large step to me. > > Could your macro expander be made to work with the new-model? I.e., > > assume you need to produce macro-free Scheme plus a few extensions > > like ':module-ref'. Could it do that? You can assume that you can > > use real uninterned symbols for local variables (so that there wont be > > any clashes between renamed local variables and global variables). > It is difficult, I think, because (if I'm not mistaken) the > reason the current module system is "interesting" is precisely > because variables aren't looked up until they're actually used No, I don't think so. In any case, the lazy lookup is not required by new-model.txt. > (part of the "lazy" macro expansion, except "lazy" usually refers to > something that has the same outcome whether you were lazy or not, > except not halting). Once they're resolved, aren't top-level > variable occurences replaced with references to bindings in the > current module environment? Or do top-level variables get > repeatedly looked up? They are replaced with references to 'variable' objects. > That said, it's not impossible. Ok. Can you modify new-model.txt so that it is to your liking? -- 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