Re: [Scheme-reports] ANN: first draft of R7RS small language available

["Aaron W. Hsu" <arcfide@x>]

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:
>> 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@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports