On Fri, 11 Sep 2009, Aaron W. Hsu wrote: > On Tue, 08 Sep 2009 11:40:10 -0400, Andre van Tonder <[email protected]> > wrote: > >> On Tue, 8 Sep 2009, John Cowan wrote: >> >> No, if there is to be a Thing Two, they will have to be compatible. It >> really is a small change (simply disallow forward uses of macros) that >> significantly simplifies the expansion process (from 2-pass to 1-pass) >> by disallowing a corner case that is hardly ever even used by anybody. >> >> One pass is simpler for users to understand. Insisting on two-pass >> expansion >> in R6 is very much like insisting on two-pass for evaluation, e.g., >> insisting that >> >> (display x) >> (define x 1) >> >> should work just because the display is in the region of visibility of >> the binding. No Schemer today has this expectation for definitions. >> Neither should they for syntax definitions. The fact that you >> can make more things work with more passes does not mean it should be >> done. > > R6RS defines the body expansion process in Chapter 10 of the main document. > It also states that internal definitions follow LETREC* semantics. > > The expansion process laid out in chapter 10 can be paraphrased simply in > relation to definitions using 'define' and 'define-syntax' easily: do the > syntax first, then do the rest. In fact, this is a very natural way to think > about things, because we do have two phases going on. Macro forward > references, when thought of in these terms, do not seem to funny. They just > happen out of course. You delay evaluating definitions until you have all the > definitions and syntax ready within that current scope. > > That last part is important. Within that current scope allows us to create > two reasonable interpretations of the semantics, one which applies aptly to > the REPL and the other which makes more sense for normal code.
As far as macro expansion is concerned, I contend that the choice between one-pass or two-pass is really arbitrary. One is not more fundamental than the other, and I am unaware of any theoretical reasons to prefer two-pass. Therefore, one should look elsewhere for reasons to prefer one or the other. Here are some: One-pass is compatible with a REPL, and two-pass is not. Everything else being equal, it would be simply perverse to choose the option that is gratuitously incompatible with the REPL. Not to mention that the one-pass behavior is what a naive user used to a REPL would expect, not the two-pass. Even a sophisticated user will find it easier in general to read and parse a program left-to-right as much as possible, as opposed to the out-of-order macro uses that two-pass can give you. Technically, one pass is much simpler and less error-prone to develop and maintain, as I can attest from personal experience. Andre _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
