[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] ANN: first draft of R7RS small language available
An hour and a half ago, John Cowan wrote:
> > > 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:
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
> | 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:
> 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
> | 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
> (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
> (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