Call for withdrawal

["Bradd W. Szonye" <bradd+srfi@xxxxxxxxxx>]

> Bradd W. Szonye wrote:
>> 2. Implement them as an optional library.
>>    Disadvantages: This doesn't work well in PLT when the library makes
>>    changes to core-language interfaces. If you write a module in R5RS
>>    Scheme, you can't redefine the R5RS bindings. Unlike Scheme-48, the
>>    PLT module system does not permit shadowing (and for good reason,
>>    IMO). You can avoid this by implementing a SRFI as its own language,
>>    but then you run into the same problem when you try to combine two of
>>    them.

scgmille@xxxxxxxxxxxxxxxxxx wrote:
> Thats absolutely untrue.  It is in fact a violation of R5RS to
> prohibit overriding of the procedures and syntax from R5RS.

You can override the procedures. However, it's very difficult to do it
in a way that also allows modular programming. PLT Scheme obeys the
overriding rules at top level but not within a module (which is fine,
because the module feature is an extension with its own rules). Their
rules for modules also make good engineering sense.

However, it does not easily support things like modular *changes* to
existing languages. That's not because it's a poor implementation, but
because those changes are very difficult to design in a modular way.

In other words, changes like SRFI-44's original vector-set! are
difficult to implement in PLT because changes like that are poorly
suited for modularity and reusability, not because PLT has a poor Scheme
implementation. 

Also, those conflicts violate the requirements for releasing an SRFI,
which "must list related standards and SRFIs, including dependencies,
conflicts, and replacements."

>> And I'll repeat what I said to Taylor: Until you've actually used
>> this to create concrete collections, you're publishing a "Scheme
>> Request for Design Docs," not a request for implementation.

> Yes, the SRFI name itself is a bad match for what is occuring here,
> but it is still the right venue.  

I disagree. Again, the SRFI Process Document states that all SRFIs "must
contain a detailed specification. This should be detailed enough that a
conforming implementation could be completely created from this
description."

As written, a Scheme implementation cannot completely create a set or a
bag, because there is no concrete specification for a set or bag. I
think it's very arrogant of you to insist that this is the right venue
for your design doc, when the SRFI FAQ disagrees:

    Q: I really think that there should be a place to archive
       non-implementation documents.
    A: You're not alone! There seem to be lots of people who disagree
       with the editors on this point ....

    Q: Why do I have to include a reference implementation? 
    A: See the discussion above about preliminary ideas. SRFIs are about
       implementation. If you haven't either: (a) built one, or (b) have
       a very clear outline of how to build one, then you aren't
       documenting anything useful about implementation.

There is no clear outline on how to build a bag or set. There's no
implementation of those collections at all. In an SRFI, you can't just
wave your hands and insist that the implementation is obvious. Until you
provide an actual implementation, there's no guarantee that your design
doc is implementable at all. Yes, you've implemented parts of it, but
large chunks are missing, and the SRFI itself is not sufficient to
create an implementation.

You could easily resolve this problem by actually specifying and
implementing at least one collection of each type listed. Then it would
be useful both as a SRFI and as a "meta-SRFI." But as written, it is not
a SRFI, and it is not mature enough to inspire confidence in its use as
a meta-SRFI.

Note the last section of the SRFI Process Document:

    The editors may not reject a proposal because they disagree with the
    importance of the proposal, or because they think it is a
    wrong-headed approach to the problem. The editors may, however,
    reject a proposal because it does not meet the requirements listed
    here. 

    In particular, lack of a reference implementation (as defined above)
    is grounds for rejection. This can only occur if the ``reference
    implementation'' requirement is being met by an outlined
    implementation (type 5), and there is consensus that the
    implementation outline is not adequate.

Parts of this SRFI are implemented only in outline form, if even that.
My opinion is that the outline is not adequate, because there's no proof
of concept. Even if you don't want to specify a concrete bag and set in
the SRFI itself, I insist that examples of use are necessary to
demonstrate that the interface description is actually implementable.

    Note that this 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. 

Again, I recommend that you set aside your personal desires and
recognize that this SRFI is incomplete.
-- 
Bradd W. Szonye
http://www.szonye.com/bradd