Fri Apr 1 23:27:20 EST 2005
> In the interest of moving forward while Manuel considers how we might
> create a compatible general-purpose matcher, I would like for us to vote
> to include syntax-case while leaving open the possibility of changing
> the pattern matcher at a later time. In other words, I'd like for us
> to have, by default, a subset of syntax-case essentially as it exists
> today, so that we have some version of it in R6RS even if we fail to
> come up with a compatible general matcher.
> An alternative is to wait until after we've succeeded in coming up
> with a compatible general matcher or given up the attempt to do so,
> but I feel like time is passing quickly and we need to start reaching
> closure on this and other issues.
> I've included below a revised version of the proposal I sent out before
> the Utah meeting, amended as Matthew and I (the macro subcommittee)
> agreed at the Utah meeting. It also accounts for the declaration of
> indirect exports (what we had been calling implicit exports). The latter
> can go away if we don't agree on a module system.
> If we decide to include syntax-case, I will write a more formal
> description and post it to the twiki.
Just as an early remark, I may say that I really dislike the ... notation
in this form of pattern matching. I think that it is particularly obscure
as soon as more than one ... appears in a clause. This is one of my main
motivation for designing a new pattern matching language.
You did not say a word about hygiene. I presume that you assume hygiene,
right? What about non-hygienic macros? If we happen to want non-hygienic
macros, should they have a nice syntax such as SYNTAX-CASE?
More information about the R6RS