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: 24 Sep 2002 22:03:36 +0200 Sender: guile-devel-admin@gnu.org Message-ID: <87it0vyx2f.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 1033223524 14001 127.0.0.1 (28 Sep 2002 14:32:04 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 28 Sep 2002 14:32:04 +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 17vIdV-0003db-00 for ; Sat, 28 Sep 2002 16:32:01 +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 17vIdj-00007C-00; Sat, 28 Sep 2002 10:32:15 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17vIcC-0008NV-00 for guile-devel@gnu.org; Sat, 28 Sep 2002 10:30:40 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17vIc9-0008Mx-00 for guile-devel@gnu.org; Sat, 28 Sep 2002 10:30:39 -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-0008L4-00 for guile-devel@gnu.org; Sat, 28 Sep 2002 10:30:31 -0400 Original-Received: (qmail 5595 invoked by uid 1000); 24 Sep 2002 20:03:36 -0000 Original-To: Lynn Winebarger In-Reply-To: <02091322183303.21934@locke.free-expression.org> Original-Lines: 117 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:1375 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1375 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? > It complicates define a little, but not much. Can you spell out this complication? I think that will help me to understand better. > > [...] > No. There's no (good) reason for modules to have inherent > names. There are good reasons for them to have fixed file names, > but not names that inhere in the module itself (any more than there > is for functions, at least). Yes, good point. The model does rely on module names only for the 'module-ref' statement. That statement is meant to be used by macro expanders so that a macro expansion can refer to names from the module of the macro definition without having to export/import those names. It would be a win if we can make that connection in a way that doesn't rely on module names. We can change ':module-ref' to allow arbitrary code to be executed for retrieving the module. That is (:module-ref MODULE ID) would refer to the binding named ID in the module returned by evaluating the expression MODULE. But how are the identifiers of the expression MODULE looked up? Maybe it will work to specify that it is always evaluated in the "(guile)" module. That is quite a complicated scenario, in my opinion. I think it is OK to just require that modules that are used in a ':module-ref' statement must be findable via names. Parameterized modules can embedd the parameter values in their names, like (scheme-report-environment 5). When parameterization gets more complicated, we probably should use GOOPS instead of modules for this. > (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. A solution would be to say that you can't _only_ compile some code, you can only execute it and (optionally) compile it at the same time. This is something to keep in mind, I'd say. > So in this model, you could use modules you object with compiled > methods if you like. I don't understand. Come again? ;) > If you can't tell, I think Guile should handle its own linking > and loading, at least as far as its own compiled modules go. Yes. I want 'load' to load compiled code as well. > As regards syntax-case and macros/modules: I don't believe Guile > should use Dybvig's portable Scheme implementation. If we get something better, great! But this is a separate issue, I'd say. (Larceny has a nice compiler front-end, I think.) > Even if it we had a compiler, it does explicitly use symbols for > renaming that somehow have to be unique across compiler runs. Hmm, the renaming is only done for local variables, not for the global ones. We have a problem right now because the renamed local identifiers might clash with the not-renamed globale ones, tho... > (define foo-macro > (lambda (x) > (syntax-case x () > ((_ y ...) > (let ((z +)) > (syntax (z y ...))))))) Shouldn't that be 'define-syntax' instead of 'define', or am I missing something? > Really, this is just an attempt to import z from the let inside of > foo-macro into the environment in which "foo" is expanded. > > Now, what should happen when a macro imported from the module is > used is the same: newly introduced identifiers should get labeled by > the module environment, and everything else should retain whatever > lexical environment it had. This will avoid both capturing syntax > from the interactive top-level, and missing syntax from the module. > Since macros are perfectly capable of relying on values of imported > variables (and side-effects on those and resulting dynamic macro > behaviour), And macros can introduce macros they imported from yet > another module, it will all work (I think, anyway). 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). -- 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