This page is part of the web mail archives of SRFI 46 from before July 7th, 2015. The new archives for SRFI 46 contain all messages, not just those from before July 7th, 2015.
Begin forwarded message:
From: oleg@xxxxxxxxx Date: Mon Dec 1, 2003 15:29:29 US/Eastern To: campbell@xxxxxxxxxxxx Subject: Re: Beyond SYNTAX-RULES Reply-To: oleg@xxxxxxxxx Taylor Campbell wrote:You might also be thinking 'um, why not just use SYNTAX-CASE?' There are several reasons: (1) Do you really _need_ full Scheme at macro-expand-time? Probably not, but you _might_ need some of the directives, such as UNHYGIENE. (2) Does the _implementor_ want to allow for arbitrary Scheme code at macro-expand-time? Maybe, maybe not: it introduces lots of problems regarding phase separation and syntactic environment towers. ... SYNTAX-RULES is sufficient for 90% of all of the macros you will ever need to write. Of the remaining 10%, SYNTAX-RIASTRADH probably solves 9%. The remaining 1% is solvable only through low-level macro systems such as R4RS's low-level system, SYNTAX-CASE, explicit renaming, syntactic closures, et cetera, and to try to specify them in a standard would open up a huge can of worms that no one wants to try opening.Amen. Frankly, I can't think of any way to put it better. Now that the Christmas season is upon us, perhaps I may be permitted to profess a few wishes. For one thing, it would be nice to clarify some gray areas in syntax-rules, for example, the one mentioned in http://pobox.com/~oleg/ftp/Scheme/macros.html#syntax-rule-dark-corner It has been mentioned that such an undefined behavior is a consequence of an incomplete specification for a top-level define (it is left unspecified if the top-level define binds or merely sets). It should be pointed out that two different syntax-rule macro-expanders may have different behavior on the same Scheme system. It seems what matters not what a Scheme system thinks define does, but what a macro-expander thinks the Scheme system thinks define does. Perhaps we can deterministically fix the macro-expander's thinking. Another wish is for the body of a top-level let-syntax and letrec-syntax to behave as the body of a top-level begin. For example, (let-syntax () (define foo 1)) (display foo) should print 1. Actually, it does so on Petite Chez Scheme, but not on many Scheme system. The above feature would make it possible to writemodular macros that expand into definitions. Otherwise, such macros mustbe either monolithic or top-level-namespace-polluting. I vaguely remember that something like that was discussed on Scheme 1998 workshop and agreed upon. http://www.schemers.org/Events/Workshops/Sep1998/minutes Perhaps we can standardize this practice in the SRFI. Regarding unhygiene.- (unhygiene UNHYGIENIC-GENERATOR-IDENTIFIER) Specifies an identifier to be used in the template to unhygienically produce identifiers. See the examples later for how to use this. There is no default if this directive is not specified.The original Kohlbecker algorithm (described in the paper "Hygienic Macro expansion" by Kohlbecker, Friedman, Felleisen and Duba) had a provision for unhygienic identifiers. Their discussion is quite illuminating. Two paragraphs of the second column of p. 157 (beginning with the sentence "Now that we have a hygienic expansion algorithm, we can think about the implementation of exceptions to the HC/ME rule") are very illuminating. They point out dangers in capturing identifiers and describe their design choice, which seems sensible. Of course, their system did not support macros generating macros (i.e., let-syntax). Incidentally, we can still use their design decision if we require that (unhygiene ...) may occur only in top-level macros. Al Petrofsky wrote:In practice (assuming we do not allow identifier concatenation), I think the first argument to the unhygiene operator will always be the identifier that was used to invoke the macro. (That statement might be way off: someone with more syntax-case experience please correct me if so, and provide motivation for other first arguments to datum->syntax-object.)macros in Dan Friedman's paper "Object-Oriented Style" show non-trivial uses of the first argument to datum->syntax-object. http://www.cs.indiana.edu/hyplan/dfried/ooo.pdf http://www.cs.indiana.edu/hyplan/dfried/ooo.ss Please see with-implicit, extend-shadow, and especially if-shadowed.