[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] ANN: first draft of R7RS small language available
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@x> wrote:
> 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.
Programming is just another word for the lost art of thinking.
Scheme-reports mailing list