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: Re: more syntax silliness Date: Mon, 26 Aug 2002 17:30:38 -0500 Sender: guile-devel-admin@gnu.org Message-ID: <02082617303817.19624@locke.free-expression.org> References: <0208191054570B.19624@locke.free-expression.org> <0208232354040Z.19624@locke.free-expression.org> <877kid70d5.fsf@zagadka.ping.de> 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 1030401237 26871 127.0.0.1 (26 Aug 2002 22:33:57 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 26 Aug 2002 22:33:57 +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 17jSQj-0006yi-00 for ; Tue, 27 Aug 2002 00:33:54 +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 17jSRz-0005CI-00; Mon, 26 Aug 2002 18:35:11 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17jSRT-0005A7-00 for guile-devel@gnu.org; Mon, 26 Aug 2002 18:34:39 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17jSRQ-000590-00 for guile-devel@gnu.org; Mon, 26 Aug 2002 18:34:38 -0400 Original-Received: from plounts.uits.indiana.edu ([129.79.1.73]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17jSRQ-00058e-00 for guile-devel@gnu.org; Mon, 26 Aug 2002 18:34:36 -0400 Original-Received: from stjoseph.uits.indiana.edu (stjoseph.uits.indiana.edu [129.79.1.78]) by plounts.uits.indiana.edu (8.12.1/8.12.1/IUPO) with ESMTP id g7QMYUqj014116; Mon, 26 Aug 2002 17:34:30 -0500 (EST) Original-Received: from locke.free-expression.org (dial-123-15.dial.indiana.edu [156.56.123.15]) by stjoseph.uits.indiana.edu (8.12.1/8.12.1/IUPO) with SMTP id g7QMYP6I016369; Mon, 26 Aug 2002 17:34:30 -0500 (EST) Original-To: Marius Vollmer X-Mailer: KMail [version 1.2] In-Reply-To: <877kid70d5.fsf@zagadka.ping.de> 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:1164 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1164 On Monday 26 August 2002 16:53, Marius Vollmer wrote: > Lynn Winebarger writes: > > > In case anyone was wondering, it's a bug in Chez. > > Do we inherit the bug? Our psyntax.ss comes straight from Chez, > AFAIK. I do not know. It comes from lazily evaluating let(rec)-syntax. (confirmed by Dybvig). Is that handled by psyntax.ss? I suppose it is since it's definitely not in the guile core. In any case, guile's macro system suffers from its own laziness problems that are independent of syntax-case. I was just trying to get a better grip on how macros are supposed to expand, rather than report a possible bug in Guile. That infrastructure can then be used for a clean module system, where you can import variables and macros from module A, and they will continue to reference variables and macros in module A. But I've been stymied by the specification of hygienic macros by Dybvig's TSPL and R5RS as they refer to "where" a macro is defined, but what they mean is "where" it is bound for it's "current" usage. You'll notice the examples I gave show how this wording can be misinterpreted. But now I've got a pretty good idea of how it works. I've written a pattern matcher and pattern expander (in Scheme), now I've just got to implement a rudimentary macro expander that handles hygeine and referential transparency. Once I've got that working, I can confirm my understanding of syntax-case, and hand compile them into C. By the way, is there any good reason that the tree codes ("special symbols") can't have their number encoded only the top 16 bits, rather than in bits 7->3 and then the top 16 bits too? This would make it easier to add tree codes that are handled in exactly the same way as the core ones are now, and should require only minimal changes to eval. At the bottom is an email between Dirk and I (at DIrk's encouragement). It shows why top-level bindings have to have a dual nature (I sent it to Dirk for workbook/compilation/evaluation.txt). Lynn On Mon, 19 Aug 2002, Lynn Winebarger wrote: > On Monday 19 August 2002 01:59, Dirk Herrmann wrote: > > > > Ahh. Thanks for the clarification. I assume the following: > > > > (define bar 5) ;; bar is normal variable > > (define (foo x) (+ x bar)) ;; bar references normal variable, no matter > > ;; what happens later. > > (define-syntax bar <...>) ;; syntax 'bar' shadows the normal variable > > ;; for further references > > (define (baz x) (bar x)) ;; bar references syntax and gets expanded > > (define bar 5) ;; Is this allowed and does it shadow the > > ;; syntax? > > > You know, I can't actually say that what I've said is demanded by any > specification. I just can't think of any other reasonable interpretation of > the second line. > That said, I tend to use Chez to test my interpretation. I could have > sworn it choked on redefining syntax as a normal variable, but it appears > not to, even identifier syntax. Perhaps I was testing with an older version > before. > > The R5RS refers to extending the "syntactic environment" with define-syntax > and that: > `Let-syntax' and `letrec-syntax' are analogous to `let' and `letrec', > but they bind syntactic keywords to macro transformers instead of > binding variables to locations that contain values. > > But it also says: > The syntactic keyword of a macro may shadow variable bindings, and local > variable bindings may shadow keyword bindings. > > However, shadowing a variable implies you've got 2 different scopes. If > you reused the same location for the macro binding as for the variable binding, > it's not the same as shadowing. > This is from a Petite Chez session: > > (define bar (lambda (x) (+ x 5))) > > (define baz (lambda (y) (+ 10 (bar y)))) > > (define-syntax bar (syntax-rules () ((_ x) (quote x)))) > > (baz 5) > 20 > > (define bar (lambda (x) (+ 7 x))) > > (baz 5) > 22 > > > What I should do is look at the formal semantics, but it does look like > macro bindings and variable bindings should kept separate but > nested in each other (when lexically scoped). The "interesting" part > would be to keep track of which top-level one to use, as it can apparently > switch back and forth. Maybe top level variables should have 2 slots > and a flag for which to use? > > Lynn > _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel