On Fri, 11 Sep 2009 02:05:43 -0500, Eli Barzilay <[email protected]> wrote:
> * The kind of hygiene-braking that makes a `make-foo' out of a *given* > `foo' has no problems. > > * The kind of break that invents an `abort' out of thin air is the one > you don't want. PLT does have a hygienic solution for that: > http://blog.plt-scheme.org/2008/02/dirty-looking-hygiene.html You don't need anything other than `syntax-rules' to perform this kind of hygienic insertion. For example, have a look at the following code: http://paste.lisp.org/display/86404 . I think adding a primitive syntax which performs similar insertion of appended identifiers would not compromise any hygienic princples. > * Besides the first item, `syntax-rules' suffers from a number of > additional problems. One is the heavy cost of doing any kind of > looping or other kinds of computations: in addition to making it > hard to follow (and if you read Joe's "Merely Eccentric" text you > probably know about that), it is slow. Usually that's not a > problem, but when you deal with macros that expand to macros > expansion times can become painful. If you can already think in CPS, writing hairy `syntax-rules' macros is no problem! :-) In practice, I have two problems with writing sufficiently complex `syntax-rules' macros. One is the unhygienic treatment of ellipses in `syntax-rules', and for this reason I'd like to see SRFI-46 included in more implementations. (It's *substantially* less ugly than the alternative of writing ((... ...) (... ...)) in macro-writing macro-writing macros.) The other issue is that it can become difficult to write certain programs in CPS; the addition of a `syntax-apply' primitive defined so that: (define-syntax foo (syntax-rules () ((_ a b) (b a)))) (syntax-apply (foo a b) k) -> (k (b a)) would make writing many complex macros substantially easier. > * Another problem: write a `bind' macro that does this: > > > (bind ((x 1) (x 1)) x) > bind: duplicate identifier in: (bind ((x 1) (x 1)) x) With a `syntax-error' syntax (should that be `syntax-violation'? `syntax-perturbation'? `syntax-felony'?) this would be possible in `syntax-rules' as well. I'm not asking everyone to write these hairy `syntax-rules' macros, but if they are expressible in the language, then a standard library of syntactic forms could be made available to macro authors to accomplish these kinds of difficult tasks. If this library were standardized, implementations could use a low-level macro system to implement these forms, which as you point out would increase performance and clarity of implementation, as well as aiding in debugging (for instance, through the use of `generate-temporaries' instead of the `syntax-rules' equivalent - which could also be provided as a syntactic primitive for `syntax-rules' users). In my mind, the primary benefit of `syntax-case' is that it encourages implementations to get the details of hygiene correct. Of the implementations that I've tested, Scheme48 is the only non-syntax-case implementation which does so. (If anyone is aware of other non-syntax-case implementations with correct implementations of hygiene, I'd love to hear about it.) This should be justification enough for the merits of `syntax-case' as an implementation technique for hygiene. However, I believe that macro *users* should use `syntax-rules' when possible as matter of conceptual clarity - both to avoid bringing in the semantics of phases and to ensure that hygiene is always preserved. Given that many substantially useful macros can be written without breaking of hygiene, I don't believe that it ought to be required for an implementation to provide any low-level macro system. `syntax-case' should be standardized and recommended, but not mandatory, if only to encourage macro *users* to avoid it when it is not necessary for the task at hand. -- Brian Mastenbrook [email protected] http://brian.mastenbrook.net/ _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
