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.
scgmille@xxxxxxxxxxxxxxxxxx wrote:
> In an attempt to break this circular flame war, please state your
> objections in a point by point matter, citing evidence.
1. The draft period is already overdue, and there are still a few major
issues to resolve. A slight delay to deal with minor issues might be
OK, but extending the draft period for a re-design is not. That's
what the withdraw-and-resubmit process is for. Evidence: The SRFI
Process Document explains this clearly.
2. The reference implementation is incomplete. Evidence: There's no
implementation of set, and there's no implementation of bag as a
distinct type.
3. Dictionaries still aren't well-specified. Evidence: Author's own
admission.
4. The SRFI still lacks important primitives operations. Evidence: There
is no GET-ANY procedure to retrieve all dictionary elements that
match a given domain value. GET-ANY is necessary for dictionaries
with duplicate keys. It is both implementable and meaningful for all
dictionaries, even those with unique keys.
5. The SRFI does not document its relationship with other standards and
SRFIs. Specifically, it does not address potential incompatibilities.
The SRFI process requires this documentation. Evidence: SRFI Process
Document.
6. SRFI-44 does not address performance issues sufficiently, and its
claim to present a sufficient "generic" interface encourages
inefficient programming habits. Evidence: Conclusion based on
experience and best practices in the field of re-use.
7. The SRFI is immature. Evidence: Active discussion and major changes
implemented more than 90 days after the initial draft. As the SRFI
Process Document states: "Active discussion or revision after 90 days
normally suggests that a proposal has been revised at least 3 times
and is not yet mature enough for standardization."
8. The SRFI is not an implementation at all. Evidence: The SRFI itself
points out that it's a "meta-SRFI" -- it isn't even a plan for Scheme
implementations, it's a design document for future SRFIs. The SRFI
FAQ points out that this is the wrong venue for such documents.
SRFI-44 attempts to implicitly change the SRFI process by hiding a
change to that process inside a document that's nominally about
something else. Bad, bad idea.
Please remember these two things:
Note that [incomplete implementation] is never a permanent
rejection, because creation of an implementation of one of the other
types is a complete refutation of this basis for rejection.
The withdrawal and resubmission process exists so that you can re-open
the SRFI when it is mature.
Remember, even if a proposal becomes an final SRFI, the need for it
must be compelling enough for implementors to decide to incorporate
it into their systems, or it will have been a waste of time and
effort for everyone involved. If the quality of any SRFI is not
high, the likelihood of implementors adding this feature to their
implementation is extremely low.
There is an additional risk for a "meta-SRFI": A poor implementation can
disrupt the SRFI process itself, as people debate whether you should
consider the meta-SRFI binding. Consider the discussions about whether
implementors should follow SRFI-1's example, and then consider the
additional disruption created by a SRFI that's specifically intended to
set an example.
--
Bradd W. Szonye
http://www.szonye.com/bradd