A problem I have with all these SRFIs has to do with the names that implementers are to provide or use. For example, if I write a SRFI 200 implementation as a library (R6RS, R7RS, or implementation-specific), what names should it provide to the user?
It should provide the name 'match'
There are issues on R7RS systems with a macro that expands into a different macro of the same name (imported from a different library), and not all R6RS implementations avoid this problem either even though they are supposed to do so.
I don't really know if I can solve this.
Currently, SRFI 200 is just a piece of advice: use only these features of your favorite matcher. It doesn't say how to actually invoke a compliant matcher: that remains completely implementation-dependent.
It does contain a reference implementation, and it asserts that WCS and Racket already conform to SRFI-200
(and that FHD needs to be wrapped to conform)
In order to be an implementable and usable library, it needs to define and expose one or more stable names. (The names should not be uniqued with "srfi-200-" or the like, because if this SRFI becomes part of R7RS-large, it will no longer be important that it was first defined in SRFI 200.)
The stable names are: match for SRFI-200, define, lambda, let, let* and or for SRFI-201, and and-let* for SRFI-202.
SRFI 201 and 202 are meant to be clients of some matcher, but in order to make their implementations portable, they have to know what the name of a 200-compliant matcher is. Or is the intention that they can be used with any matcher? If so, then code using them will be inherently not portable, because there is no possibility of a bright line between matches that work and matches that don't.
One of the key ideas of SRFI-201 is that if an implementation already uses and recommends some syntax for pattern matching, the same syntax could be used in the core Scheme forms lambda, let and let*.
If the matchers aren't compatible, then the code using them wouldn't be portable anyway
I have an additional difficulty with SRFIs 201 and 202: these macros have the same names as those in the various base libraries. So you have two choices: all or nothing for each macro. It can be imported from the base library (or the SRFI 2 library) and not have the current functionality, or it can be imported from the SRFI library.
I don't see why this should be a problem. All the former uses of the core forms are not incompatible with the proposal (you'd run into the same issue with SRFI-71)
However, a compiler may handle the base-library versions separately in such a way as to be more efficient at runtime than the SRFI 201/202 macro definition. If so, it may be necessary to use the base library version in some cases where the additional function is not required. Within a single library, it is not possible to use both.
Except 'or', all the former uses of the proposed forms expand to the core forms.
However, if each new macro is given a standard name, then the user can use them with those names. If compile-time facilities are not a concern, the names can be excluded from the base-library import to avoid a conflict.
I don't think there's any conflict.
My recommendation for implementors would be to have their core forms available under names like core-lambda, core-define and so on, and to express srfi-200's forms under names lambda, define and so on. This would not break any existing code, and the changes in the reference implementation would be trivial.
The only exception to this is the 'or' form, which probably needs a special treatment from the compiler to be efficient.