I believe I agree with Eli completely on this one. The bottom line as I see it is as follows: 1) Syntax-case isn't more complicated, just more convenient. 2) Implicitly enforces hygiene, and makes hygiene break explicit rather than the reverse, which, IMO, is a rather important element. The default should be hygiene, not the other way around. Aaron W. Hsu On Fri, 29 Apr 2011 15:49:00 -0400, Eli Barzilay <eli@barzilay.org> wrote: > An hour and a half ago, John Cowan wrote: >> Scripsi: >> >> > > Is WG2 not going to have a syntax-case module? That would be >> > > unfortunate. What about syntax objects, or procedural syntax >> > > transformers? >> > >> > WG2 will have explicit renaming only. > > A huge step back. > > >> If you're curious: explicit renaming was voted up 4-0; syntactic >> closures voted down 1-3; and syntax-case tied with 3-3 (with one >> vote for sending it to a future WG), which means it failed. There >> were 11 WG members at the time, of which 2 did not vote at all. > > IMO this is one of the most important decisions, yet there is no > information that I see beyond the above: no mailing list discussion, > no wiki page on the trac thing. IMO it's much worse since it is a > step back from R6RS. > > I'm especially suspicious given (a) the importance of finally having a > macro system specified, (b) some of the usual anti-R6RS bias that was > expressed explicitly, and (c) some of the usual ignorance around > syntax-case, some of it likely to have affected the decision. > > For example, there's this post from Alex Shinn: > > http://lists.gnu.org/archive/html/chicken-users/2008-04/msg00013.html > > which is often waived as "proof" that ER is a much better choice. To > counter that, I'll make the reply that I once put on IRC explicit. > > Quoting my reply verbatim: > >> | 1) very, very large and baroque API and reader extensions >> | >> | 03:08 foof: For example, in 1) I complain it has a large API. >> | Since the API is larger than any other alternative low-level >> | hygienic macro system, I think it's a fair assessment. >> >> The "minimal API" of a `syntax-case' system is made of (1) >> `syntax-case', (2) `syntax', (3) `syntax->datum', and (4) >> `datum->syntax'. With (1) it is extremely straightforward to create >> something like `syntax-e' if it's not builtin -- and `syntax-case' >> itself is *no longer necessary*; (3) can be done in exactly the same >> way (applied recursively), so it's just a convenience. This leaves >> you with two things: (2) as a core lexical-scope-preserving quotation >> notation, and (4) as a way to construct new identifiers >> unhygienically. (4) is therefore the only real "complex API" here, >> and it's complexity is (very unsurprisingly) very similar to ER or SC >> since in all three cases you take a symbol and choose a lexical scope >> to put it in. The bottom line is if you count the number of concepts >> to deal with (eg, the different wrapper functions of SC, and the >> different arguments and how they're used in ER), all three systems are >> roughly at the same level of complexity. >> >> As a side-node "reader extensions" are, of course, not necessary at >> all. >> >> >> | 2) forces a single destructuring idiom tightly integrated with the >> | macro system, when this should be a purely orthogonal concept >> | >> | 03:11 foof: In idiomatic syntax-case uses you always destructure >> | with syntax-case, so 2) is a reasonable claim. >> >> The word "idiomatic" doesn't agree with "always". The fact is that if >> you have `syntax-e' (which, again, is straightforward to write with >> `syntax-case' for a Scheme that doesn't have it), then `syntax-case' >> is not necessary at all, and you get your separation. >> >> The only true fact here is that some schemes choose not to have >> `syntax-e', which contributes to using `syntax-case' more -- is that >> good? Well, I look at something like this: >> http://lists.gnu.org/archive/html/chicken-users/2009-06/msg00027.html >> and I feel sorry for people who hold on to the "defmacro simplicity" >> illusion -- holding on to it hard enough to not see how ridiculously >> complicated this code is. >> >> >> | You can do something like your blog post and recursively unwrap > > [Note: this blog post is > http://blog.racket-lang.org/2009/05/explicit-renaming-macros-implicitly.html > ] > >> | every expression with syntax->datum, but there's no standard >> | utility for this, it's relatively awkward, and is asymptotically >> | slower. >> >> The recursive bit is the only expensive thing there, but this is >> unnecessary -- in my blog post it's done only to mimic the silly >> defmacro-like code, but using just a plain `syntax-e' is enough to do >> the same style of programming. (For example, there's a library in PLT >> that defines `stx-car' etc.) >> >> >> | 3) makes it very difficult to play along with alternate macro >> | systems >> | >> | 03:13 foof: In 3) I understated my case - it's actually >> | *impossible* to play along with alternate macro systems, because >> | it hard-codes the type signature to every macro transformer. I >> | was leaving room for superhuman compatibility efforts that no >> | sane person would ever implement. >> >> Huh??? The "hard coded type signature" of macro transformers is a >> function from syntax to syntax, which `define-syntax' dictates. Both >> SC and ER work with a function wrapped in their own functions which >> make the syntax -> syntax result, so there is no collision at all. >> And at least `define-macro' and ER can be expressed with >> `syntax-case', but I don't think that the opposite holds (IIRC, >> Riastradh had an explanation for why the reverse direction is >> impossible). This makes `syntax-case' *more* hospitable to ER and SC >> than they are to it. >> >> >> | 4) implicit unhygienic interaction between SYNTAX-CASE and SYNTAX, >> | and in general confusing semantics >> | >> | 03:17 foof: By 4) I did not mean to imply there was anything >> | unhygienic going on, and am sorry some people have gotten that >> | impression. >> >> Yes, both "implicit" and "unhygienic" are completely irrelevant here. >> >> >> | To me the interaction between SYNTAX-CASE and SYNTAX is very >> | confusing, as it refers either to some dynamic binding in the >> | macro expander environment, or to some inserted lexical binding. >> >> Use `syntax-e', and you don't need that. But see above why that's as >> bad as writing any define-macro-like code, as in that post. >> >> >> | 5) identifier syntax (another huge, ugly can of worms I won't even >> | get into here) >> | >> | 03:20 foof: And I can debate 5) forever, but the simple fact that >> | it makes certain classes of macro that previously were possible, >> | impossible, is a pretty strong argument. >> >> I can debate this forever too --but-- whether identifier macros exist >> or not in your macro system is completely orthogonal to using >> `syntax-case'. This is purely an issue of how you want your macro >> expander to work, and `syntax-case' does not imply that identifier >> macros are available in any way. >> >> >> [The following is a side-remark since like I just said, it is >> absolutely unrelated to `syntax-case'.] >> >> | Why voluntarily take away power from macro programmers, for a >> | syntactic sugar hack that doesn't gain any expressitivity (in >> | terms of Fellesein expressitivity)? >> >> This sentence is amusingly ironic in at least (1) "take away power", >> and in (2) "syntactic sugar hack", but those two pale in comparison to >> invoking (3) "Fellesein expressitivity". To rephrase this more >> clearly: >> >> (1) It adds power -- there are certain things that can only be done >> with identifier macros (and I'm not talking about some theoretical >> convenience; e.g., the PLT contract system makes heavy use of >> that); >> >> (2) It's prtty far from what I'd consider a "hack"; >> >> (3) This is a concept that revolves around *local* transformations >> making your language more expressive -- identifier macros are >> certainly not needed if you do global transformations, but they >> *cannot* be emulated with local ones, therefore the resulting >> system is *more* expressive in exactly the sense that Felleisen is >> talking about. > > -- Programming is just another word for the lost art of thinking. _______________________________________________ Scheme-reports mailing list Scheme-reports@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
