From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.lisp.guile.devel Subject: comments on new-model.txt Date: Wed, 4 Sep 2002 20:22:25 -0500 Sender: guile-devel-admin@gnu.org Message-ID: <02090420222526.19624@locke.free-expression.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1031189131 11685 127.0.0.1 (5 Sep 2002 01:25:31 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 5 Sep 2002 01:25:31 +0000 (UTC) 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 17mlOh-000324-00 for ; Thu, 05 Sep 2002 03:25:27 +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 17mlQI-00056B-00; Wed, 04 Sep 2002 21:27:06 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17mlPo-00054p-00 for guile-devel@gnu.org; Wed, 04 Sep 2002 21:26:36 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17mlPm-00054d-00 for guile-devel@gnu.org; Wed, 04 Sep 2002 21:26:35 -0400 Original-Received: from julesburg.uits.indiana.edu ([129.79.1.75]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17mlPl-00054Z-00 for guile-devel@gnu.org; Wed, 04 Sep 2002 21:26:33 -0400 Original-Received: from stjoseph.uits.indiana.edu (stjoseph.uits.indiana.edu [129.79.1.78]) by julesburg.uits.indiana.edu (8.12.1/8.12.1/IUPO) with ESMTP id g851QUeP015492 for ; Wed, 4 Sep 2002 20:26:30 -0500 (EST) Original-Received: from locke.free-expression.org (dial-118-60.dial.indiana.edu [156.56.118.60]) by stjoseph.uits.indiana.edu (8.12.1/8.12.1/IUPO) with SMTP id g851QTRL010014 for ; Wed, 4 Sep 2002 20:26:30 -0500 (EST) Original-To: guile-devel@gnu.org X-Mailer: KMail [version 1.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:1287 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1287 Marius has written a detailed proposal for a new model, most of which is dedicated to the nature of modules and scoping rules. I'm glad he did, because Guile needs some clear direction on this front. That said, I'm a little distressed by the proposed module/variable semantics. Before directly commenting, I would like to point out that there are at least 3(*) orthogonal choices to be made in defining a type of environment: (1) Is the environment lexically closed or open? That is, can new bindings be added to it, or is the set of bindings immutable once initialized? (2) Is it a black box to code defined externally? In other words, can values be exported or not? (3) Is the code that uses the environment a body or interactive? In a (lambda) body, there is a well-defined lexographic boundary between definitions (both variable and syntax) and other code (both before and after macro expansion). In an interactive environment, executing a lambda at one point in time can result in a "variable not bound" error, when at other times it might not. Environments that are open in sense (1) are usually referred to as top-level, though there is no absolute reason such an environment must in fact be at the top-level. The properties described by (2) could also be called closed and open. Indeed, compiler writers refer to exported values as ones that have escaped (from the optimizer, perhaps). Unfortunately, that nomenclature is easily confused with (1). 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 It may be desirable to have other types of environments readily available as well (perhaps "top-level" environments for each thread that inherit from a global "top-level" environment?), but I don't believe they should be considered part of the module system. 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. 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). A (global/top-level) variable is precisely its name in a program. If you want to make a special generic kind of box that, when bound to a variable is, let's call it "transparently generic", go for it, but don't say variables don't have names. 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. To handle optimization, I believe we could adopt special forms that import values and bind them to local (possibly immutable) variables. So (import ...) would give you a variable such that side-effects on it are seen by 's code. import->local would bind the variable locally to its value in , preserving (im)mutability import->local/mutable would bind a locally mutable copy. import->local/immutable would bind a locally immutable copy. I believe these would be sufficient for compiler optimizations. A "core" module would contain all the basic scheme forms (immutable) and these could be imported/localized into the top-level interaction environment, while most modules would just import them directly. Lynn _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel