4 ms·

If you're interesting in learning more about syntax-case in general, I've been learning more and FameInducedApathy on reddit sent me the following resources tha

• groovy2shoes 10y ago
  Great resources. I'd like to add "Syntactic Abstraction: The syntax-case Expander" (http://www.cs.indiana.edu/~dyb/pubs/bc-syntax-case.pdf http://www.cs.indiana.edu/~dyb/pubs/bc-syntax-case.pdf), which gives a high-level overview of how syntax-case may be implemented. I'd also like to point out that, contrary to popular belief (for some bewildering reason), syntax-case is capable of expressing non-hygienic macros via the `datum->syntax` function, which takes an identifier and a symbol, and returns a new identifier with the same name as the symbol and the same scope as the provided identifier. The R6RS even gives an example of writing a completely unhygienic, Common Lisp-like macro transformer via syntax-case (section 12.6 in the R6RS Libraries document [0]). syntax-case has a bad rap, but it's really not a difficult system to learn, and it's incredibly powerful. In particular, I think its "hygiene by default, with per-identifier hygiene-breaking when and where you want it" is the best possible policy for a macro system (as far as I'm aware, the only other macro system with the same policy, though imo with a much more intuitive interface, is Chicken's ir-macro-transformer for implicit-renaming macros [1]). The combination of syntactic pattern-matching and procedural expansion is extremely convenient, too: you never need to have a massive `let` form that binds the car, cadr, caddr, cadddr, ... of the input form because the patterns let you destructure and switch (as in case analysis, thus syntax-case) on the input form much as in ML-style pattern matching. Of course, you could argue that the pattern matching ought to be disjoint from the notion of a macro transformer, and I'm inclined to agree, but my understanding is that implementing it the way it is makes it easier to keep track of which variables are "pattern variables" which helps to provide hygiene (someone please correct me if I'm wrong). Whenever a new language comes out with an unhygienic macro system (as in, unhygienic by default), I immediately headdesk. Hygiene is a very desirable property of a macro system, and there's really no reason not to provide it. A simple hygienic macro system (like syntactic closures, for example) is only slightly more complicated to implement than an unhygienic one, and you're doing your target audience a huge favor. No, gensym is not enough. I'm also bewildered by arguments that define-macro (Common Lisp-style macros) is easier than syntax-rules. The builtin pattern-matching offered by syntax-rules makes writing macros so much easier. Yes, template macros are less powerful than procedural macros, but in my experience they cover upwards of 90% of macros you might want to write, and they do away with tons of boilerplate code. For the other 10%, most Scheme systems do offer procedural macros in addition. I was a little disappointed that R7RS left syntax-case out because it was nice to finally have a standard facility for defining low-level and procedural macros. Perhaps there's hope yet for R7RS-large. [0]: http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-13.html#node_sec_12.6 http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-13.html... [1]: http://wiki.call-cc.org/man/4/Macros#ir-macro-transformer http://wiki.call-cc.org/man/4/Macros#ir-macro-transformer