"Bradd W. Szonye" <xxxxxx@szonye.com> writes:

> I'm trying to tell you that we need more experience with the interface
> to verify that it's good. I'm not claiming that it *isn't* good, but
> only that its quality is currently *unknown*. That doesn't make it bad,
> but it does make it immature, and the SRFI process is specifically
> supposed to discourage immature implementations.

Most SRFI implementations are immature, and in reality the SRFI
process is not about discouraging reference implementations, or
outlines of how a SRFIs can be implemented.

The SRFI process (http://srfi.schemers.org/srfi-process.html)
explicitly states this (regarding reference implementations):

    5. An outline of how it might be implemented. This should be
    considered a last resort, and in this case the rationale for the
    feature must be stronger.

so, I think we can safely assume (based on the last 70 messages to
this list), that the `rationale' for SRFI-44 is at the culprit.

Talking about SRFI-44's rationale, I think that it clearly states its
intention of offering a solid set of features that *other* (future)
specifications may follow.  It does not preclude adding more features
to future APIs.

I believe that that's a very *strong* rationale for a SRFI.  Now, if
the problem is the set of core operations included, then I expect the
discussion to help improve it, maybe even more drastic options such as
splitting the SRFI to provide different sets of core operations for
different (still _future_) specifications.

--Francisco