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: 10 Sep 2002 21:56:35 +0200 Sender: guile-devel-admin@gnu.org Message-ID: <87u1kxvcss.fsf@zagadka.ping.de> References: <02090420222526.19624@locke.free-expression.org> <0209081847342E.19624@locke.free-expression.org> <877khuydrn.fsf@zagadka.ping.de> <0209091930202H.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 1031687974 12204 127.0.0.1 (10 Sep 2002 19:59:34 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 10 Sep 2002 19:59:34 +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 17orAb-0003Aa-00 for ; Tue, 10 Sep 2002 21:59:33 +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 17orAe-0001r7-00; Tue, 10 Sep 2002 15:59:36 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17or9K-0001bh-00 for guile-devel@gnu.org; Tue, 10 Sep 2002 15:58:14 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17or9H-0001b5-00 for guile-devel@gnu.org; Tue, 10 Sep 2002 15:58:13 -0400 Original-Received: from dialin.speedway42.dip83.dokom.de ([195.138.42.83] helo=zagadka.ping.de) by monty-python.gnu.org with smtp (Exim 4.10) id 17or9H-0001b1-00 for guile-devel@gnu.org; Tue, 10 Sep 2002 15:58:11 -0400 Original-Received: (qmail 3471 invoked by uid 1000); 10 Sep 2002 19:56:36 -0000 Original-To: Lynn Winebarger In-Reply-To: <0209091930202H.19624@locke.free-expression.org> Original-Lines: 52 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:1324 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1324 Lynn Winebarger writes: > > Can you give example code that illustrates their use? > > Ok, I'll make up some incredibly bad notation > > (exporting-lambda () > (define-exportable foo 'whatever) > (define-exportable-syntax (lambda (x) (syntax-case x () ((_ f ...) (syntax 'xyzzy))))) > ....) > > If we have extlocs, this can be just a plain lambda that > happens to let import take references to some of its variables. > Then we can use the keyword "module" instead. 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. > Part of the disagreement is that I don't think we should > "evaluate in" modules. Partly this is a terminology issue: I think > "module" should be reserved for separately compilable units of > code that won't be invisibly dependent on whatever code happens > to be currently loaded ("invisibly" is because imports are clearly > visible to the module-using programmer, so are not prohibited). You can use our current modules that way, but the new model is not restricted to such a use. The concept of "evaluating in a module" is still there, even when modules are sealed compilation units. It's not strictly "evaluating" in a module, but the module is part of the compile time environment and determines the meaning of identifiers just as with our current situation, where modules are part of the run-time environment. > We should have some other terminology to describe other types of > namespaces. Being able to import/export variables is just one knob > on a namespace/environment/whatever. Yes, and that's why there are little module system specifics in the new model. You can implement a wide variety of modules that are compatible with it. > And then there's Dirk's view of modules as parameterizable to > get a handle on too. They are possible as well. -- 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