This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.
"Bradd W. Szonye" <bradd+srfi@xxxxxxxxxx> 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