In the specification section, in the first subsection thereof,
lambda/match is defined in terms of the core lambda and a SRFI
200-like pattern matcher.
If I understand the intent of SRFI 201 correctly, any implementation
supporting SRFI 201 has to replace the core lambda with lambda/match
(or an equivalent form). For that to be compatible with the definition
of lambda in the revised Scheme reports, lambda/match has to be a
conservative extension of the core lambda, that is every valid use of
lambda has to be a valid use of lambda/match and, moreover, has to
have the same observed behavior.
If we consider
(lambda/match (_) _),
this will be rewritten into
(lambda args
(match args (`(,_) _)))
which is not the same as (lambda (_) _).
Besides this, two more things have to be addressed:
lambda/match has to support rest arguments so that it can replace the
core lambda. Supposedly,
(lambda/match (<pat1> . <pat2>) <body>)
is being rewritten to
(lambda args
(match args (`(,<pat1> . ,<pat2>)) <body>))
But what do we do if <pat2> is of the form (quote y) and, say, <pat1>
just x? The lambda/match then looks like (lambda/match (x quote y)
<body>) and is a normal lambda, but this is not to what it would be
written to.
Finally, at least the "WCS" matcher does not seem to support pattern
variables named like the keywords used like "and", "$", ... The core
lambda form, however, must be able to take any identifier whatsoever.
PS As reported on the mailing list of SRFI 200, the "FHD" matcher is
not compatible. Given the rule in SRFI 201 of how to rewrite
lambda/match into the core lambda, an extra level of
quasiquote/unquote shows up. For the "FHD" matcher, however, there is
no nested quasiquotation.
