From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dirk Herrmann Newsgroups: gmane.lisp.guile.devel Subject: Re: Syntax checks Date: Sat, 13 Apr 2002 11:01:26 +0200 (MEST) Sender: guile-devel-admin@gnu.org Message-ID: References: <02040915485508.29769@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 1018688599 20362 127.0.0.1 (13 Apr 2002 09:03:19 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 13 Apr 2002 09:03:19 +0000 (UTC) Cc: Marius Vollmer , 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 16wJRH-0005IJ-00 for ; Sat, 13 Apr 2002 11:03:19 +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 16wJR6-0003bY-00; Sat, 13 Apr 2002 05:03:08 -0400 Original-Received: from marvin.ida.ing.tu-bs.de ([134.169.132.60]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16wJPa-0003a2-00 for ; Sat, 13 Apr 2002 05:01:34 -0400 Original-Received: from localhost (dirk@localhost) by marvin.ida.ing.tu-bs.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id g3D91QH22828; Sat, 13 Apr 2002 11:01:27 +0200 X-Authentication-Warning: marvin.ida.ing.tu-bs.de: dirk owned process doing -bs Original-To: Lynn Winebarger In-Reply-To: <02040915485508.29769@locke.free-expression.org> 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:363 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:363 On Tue, 9 Apr 2002, Lynn Winebarger wrote: > The real question (lingering from at least late 2000) seems to be > whether lambda abstractions should delay expansion as well as evaluation. > My first impulse is to say it shouldn't, that macros are "evaluated" at read > time. Among other effects of using lambda to delay expansion, you have > introduced a definite evaluation ordering of applications. I'm guessing one > of the appeals of this behaviour is that in > (define (foo x) (bar x)) > (define (bar x) (+ x 5)) > (define-syntax bar (syntax-rules () ((_ x) (+ x 5)))) > > the 2 definitions of bar work "the same". However, IMO, the second > definition should yield an error in (foo 4) because it's evaluation time > and bar evaluates to a macro, and 5 is not "syntax". > Mainly, however, I see this as a kind of lexical scoping - if you > re-evaluated macros whenever they changed, you have a kind of > dynamic scope. I know this was characterized by Marius in the opposite > way in the earlier (late 2000) discussion. I.e. that because macro expanding > at read time captures whatever value of the syntax binding was lying around > rather than the binding itself (to be used over and over), it is "dynamic". Well, > I don't have a great counter to this, it's just my intuition says that expanding > at read time gives you a "what you get is what you write" promise of > lexicality. Or actually that the other scheme is even more dynamic than > expanding at read time. Besides which the expansion stage is supposed to > occur (completely) before either interpretation or compilation, not intertwined > with it. I guess I sort of see define-syntax as implicitly introducing a new, > inescapable and non-bracketed scope. > Probably the most compelling reason to expand at read time, though is that > any sane compilation system would not go re-compiling every bit of code just > because someone redefines lambda or if at the repl. I agree with you that re-compilation in case of a macro redefinition is of questionable worth. Moreover, I don't see a demand for it: Guile does not provide such a feature, and I can't remember that I ever saw a user requesting it on the list. But, IMO the way guile currently does it is broken (IMO). Look at the following example: (define (foo x) (if x (bar) (bar))) (defmacro bar () ''first) (foo #t) --> first (defmacro bar () ''second) (foo #t) --> first (foo #f) --> second (foo #t) --> first First, we see that macro expansion happens during evaluation. Otherwise, if expansion was done after 'read, the references to 'bar would not be expanded: 'bar is not known to be a macro at that time. Second, we see that there is no re-compilation. Otherwise the second execution of (foo #t) would have resulted in 'second. Third, we see that macro expansion is only done in those paths which are actually executed. Otherwise after the first execution of (foo #t) _all_ references to 'bar would have been replaced by 'first. IMO, the current solution is broken. Depending on the evaluation order and the actual execution paths that are taken, you can get completely different expansions, although the code is syntactically the same. It is easy to create an example where it depends on _input data_ how the expansion will be done. Ugh. Thus, I sugggest to first go the way that Lynn suggests: Do expansion after reading, but don't care about re-compilation. If we later decide for re-compilation, we can think about possible solutions then. Best regards Dirk Herrmann _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel