| 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
|    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.