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: Syntax checks Date: Tue, 9 Apr 2002 15:48:55 -0500 Sender: guile-devel-admin@gnu.org Message-ID: <02040915485508.29769@locke.free-expression.org> References: <87d6xb3i7u.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 1018385676 3419 127.0.0.1 (9 Apr 2002 20:54:36 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 9 Apr 2002 20:54:36 +0000 (UTC) Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16v2dP-0000t1-00 for ; Tue, 09 Apr 2002 22:54:35 +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 16v2cu-0002WA-00; Tue, 09 Apr 2002 16:54:04 -0400 Original-Received: from epimetheus.hosting4u.net ([209.15.2.70]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16v2bB-0002Qh-00 for ; Tue, 09 Apr 2002 16:52:17 -0400 Original-Received: (qmail 15145 invoked from network); 9 Apr 2002 20:52:14 -0000 Original-Received: from leo.hosting4u.net (HELO free-expression.org) (209.15.2.51) by mail-gate.hosting4u.net with SMTP; 9 Apr 2002 20:52:14 -0000 Original-Received: from locke.free-expression.org ([156.56.117.126]) by free-expression.org ; Tue, 09 Apr 2002 15:52:08 -0500 Original-To: Marius Vollmer , Guile Development List X-Mailer: KMail [version 1.2] In-Reply-To: <87d6xb3i7u.fsf@zagadka.ping.de> X-Rcpt-To: Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.8 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:347 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:347 On Sunday 07 April 2002 05:40, Marius Vollmer wrote: > Neil Jerram writes: > > Also, does this fit into a more general picture of how we should > > evolve the interactions between transformation, evaluation, > > compilation etc.? (I don't claim that such a picture exists, but it > > would be nicer if it did.) > [snip] > But having a compiler for Guile is still an important goal, but we > should do it Right rather than rush it. I plan to attack it from > above, by first straighten out the module system to be friendly to > compiler semantics, redoing our current memoizer to be no longer > tangled with the evaluator and then having a way to write memoized > code to disk and load it back in. Down that road are enough > design problems that are important for good compiler support, long > before we come close to worrying about how to produce native > machine code (or even cross compiling). Are you actively working on the module system/first class environments? The TODO list currently only lists 1.6 and "Eventually" as target times. I am interested in this particular task, but am still poking around the source. It's not entirely clear what the exact difference between environments and modules is (or should be). Well, there's import/export and syntax readers. I did go back and read a lot of discussion from late 2000/early 2001, but I'm not sure how much has sunk in yet. Also, while I'm aware modules should act orthogonally to objects in terms of introducing namespaces, it seems to me the module system should allow constructs similar to the imperative object-oriented languages. Before I go on, though, I'd like to find out if there's any point to doing so. > > [interaction of macros and compilation should interact how? ] > Common Lisp will offer good hints, I guess. This is what I want > to iron out when separating the memoizer from the evaluator. I > want to make these questions 'central' to Guile, that is, the > basic semantics of Guile are affected by this, not just the > odd-ball compiler user. This will ensure that compilation is > consistent with using Guile interactively. 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. Lynn _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel