Francisco Solsona wrote:
> Most SRFI implementations are immature ...

They are?

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

That didn't quite make sense to me. Of course it's not about
discouraging implementations -- it strongly encourages a complete,
portable implementation!

> 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.

Only partly. My objections to SRFI-44 are that the rationale is not
compelling enough, the implementation outline is not sufficiently clear,
and that the SRFI as proposed is too likely to fail.

> 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.

But it doesn't provide features. It sets requirements for later SRFIs to
provide features. While that may be useful, I don't feel that it's
appropriate for a SRFI, and I don't think it's likely to succeed.

> I believe that that's a very *strong* rationale for a SRFI.

And I strongly disagree. Public naming standards without a concrete
implementation to back them up rarely succeed. (Are there any well-known
examples of it working?) Private naming standards for software projects
do work well, but only when there's incentive to follow them (typically
"this is the corporate standard, and you must follow it or justify
deviations"). But that's exactly the opposite of how the SRFI process
works.

> Now, if the problem is the set of core operations included ....

That's only part of the problem. The main problem is that this is the
wrong forum for proposals like this: First, "meta-SRFI" is just a fancy
way of saying "stuff that the SRFI FAQ explicitly recommends against."
Second, naming standards do not succeed unless they have a compelling
example[*] to encourage their use or a standards body to enforce them.
This proposal has no compelling example to follow, and it has no
standards body to enforce it.

That's why a few of us have strongly recommended that Scott & Taylor
publish the concrete collection types first. If their interface is
really as good as they claim, it should be no problem for them to follow
it while implementing concrete collections. Publish those, and we have a
*compelling* example to follow. At that point, it isn't even necessary
to publish SRFI-44.

Without the concrete collections, SRFI-44 isn't compelling. With them,
it isn't necessary. It would be much, much more useful as the coding
standard for a Sourceforge project or something similar.

[*] Like the "K&R" style of /The C Programming Language/ or the
    Hungarian Notation used throughout Windows interfaces. Both of those
    set examples that people wanted to follow, to remain consistent with
    well-known good examples.
--
Bradd W. Szonye
http://www.szonye.com/bradd