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: Syntax checks Date: 07 May 2002 21:24:52 +0200 Sender: guile-devel-admin@gnu.org Message-ID: <87offrkbgb.fsf@zagadka.ping.de> References: <02040915485508.29769@locke.free-expression.org> <878z7qp3pl.fsf@zagadka.ping.de> <0204291855460E.10649@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 1020800256 14786 127.0.0.1 (7 May 2002 19:37:36 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 7 May 2002 19:37:36 +0000 (UTC) Cc: Guile Development List Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 175AmG-0003qA-00 for ; Tue, 07 May 2002 21:37:36 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 175AdU-0004SY-00; Tue, 07 May 2002 15:28:32 -0400 Original-Received: from dialin.speedway42.dip59.dokom.de ([195.138.42.59] helo=zagadka.ping.de) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 175AZy-00044v-00 for ; Tue, 07 May 2002 15:24:54 -0400 Original-Received: (qmail 3776 invoked by uid 1000); 7 May 2002 19:24:52 -0000 Original-To: Lynn Winebarger In-Reply-To: <0204291855460E.10649@locke.free-expression.org> Original-Lines: 67 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.9 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:585 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:585 Lynn Winebarger writes: > Sorry for taking so long, I've been browsing guile. Heh, no problem. I enjoy not getting e-mail more and more... ;-) > [...] How will generics interact with the module system? How will > classes interact with nested modules? I'll try to write some > (currently non-interpretable) code to illustrate what I'm thinking > about and how it should evaluate. My current stance on this is that generics and classes should not be treated specially by the module system. Just like functions, generics and classes are nameless objects that just happen to be accessible via some name (or more than one, or none). Thus, modules should only be there to manage the name-space, not to create new (merged) generics, etc. > It's interesting because the old code continues to refer to the > variable binding and yet you can't create a new reference to that > location. This seems to be the logical result of requiring the > ability to specify syntax in non-operator positions > ("identifier-syntax"). My thinking is that while they're logically > separate environments, they should should be implemented in one > table, where each entry has 2 possible entries (one for syntax and > one for variable). Yes, indeed. Guile is somewhat confused about this right now: it does symbol -> variable -> macro instead of symbol -> macro. > > Also, I think we should extend this to bindings in modules: when > > the list of exported bindings of a module changes (say), the > > current proposal is to automatically correct all existing uses of > > the affected bindings. I now think it will be better to fix the > > list of imported bindings when executing a 'define-module' or > > 'use-modules' (if it survives) statement. This is Dirk's > > signatures idea, and I now finally got it, I think. When you want > > a changed export list to take effect, you need to reload/recompile > > the files that are affected by it. > > > I've looked at signatures.texi, but I don't see how this > relates. Not much, I'd say. The main thing I took away from signatures is that they are compile-time constructs, not run-time constructs. (If I understood them right.) That is, what binding comes from what module is fixed at compile time, not at load time. Knowing at compile time which module to look in for a given symbol is important for macros, and also for doing important optimizations (such as inlining of fixnum-+, say). > I'm not actually sure adding bindings to a module _after_ its > definition/lexical scope should be possible at all. Redefinition of > the entire module, yes. But then the old definition/bindings would > be still in use by the other modules that used it. Yes, my view as well. > Another issue - how would you direct the compiler to export C > "bindings" (e.g. a trampoline shared library and header file). What do you mean? How to export bindings from a module defined in C? > This touches on something I've noticed while browsing - why are > there so many smobs in the core interpreter? Is it because you > can't export macros to C automatically, or is there a deeper reason? I don't understand. How would macros reduce the need for smobs? _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel