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