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.

--
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports