(Mis posted this as a direct reply to Bradd)
----- Forwarded message from -----

To: "Bradd W. Szonye" <xxxxxx@szonye.com>
Subject: Re: Reasons for withdrawal

On Tue, Oct 28, 2003 at 02:22:43PM -0800, Bradd W. Szonye wrote:
> xxxxxx@freenetproject.org wrote:
> > Additionally you must state what these major issues are, if they are
> > not the ones below.  Otherwise this is a redundant point.
>
> I've stated them enough already. If you don't remember them, you can
> re-read the archive. That's what it's for.
Again, I asked for points from an organizational standpoint.  If you
want to be difficult, I can't stop you, but its helping no one.

>
> >> 2. The reference implementation is incomplete. Evidence: There's no
> >>    implementation of set, and there's no implementation of bag as a
> >>    distinct type.
>
> > I argue that no distinct implementation of bag is required since
> > sequences must have all the properties of a bag.
>
> You specify it as a distinct type but don't implement it that way.
> That's an incomplete implementation.

What?  Sequences are not a distinct type from bags, they are a subtype.
Please reread the SRFI.

> > No implementation of set is valid.  This is an issue if the editors
> > feel this makes the SRFI illegal for being too 'meta'.
>
> No, it's not an issue for the editors. Read the SRFI process doc again.
> It's the consensus of the reviewers that determines whether the
> implementation is complete, not the editors.

The issue of whether we can create an SRFI that defines and implements
some interface but expects future SRFIs to extend it is very much up to
the editors.

>
> > I have admitted to weaknesses in equivalence, which have been fixed ....
>
> I haven't seen the fix yet. How long will it take to review it and
> possible re-implement it? Will it even get a proper review in your rush
> to finalize an immature SRFI? The draft period and withdrawal process
> exist for a reason.

The fix has been for quite some time up on at
http://sgmiller.org/code/srfi-44.html.  I announced it on this list
nearly two weeks ago.

> >> 4. The SRFI still lacks important primitive operations ....
>
> > I agree.  This however is a minor issue that can be easily fixed.
>
> Introducing new primitives is a "minor issue"?
There is one new primitive: *-get-any.  I see this as quite minor.
Please stop attempting to inflate the importance of the minor issues to
win an argument.

> >> 5. The SRFI does not document its relationship with other standards
> >>    and SRFIs.
>
> > I agree.  This is also a minor issue which is easily solved.
>
> Is it solved or not? And I would hardly call it a "minor issue" to
> violate one of the few requirements of the SRFI process.

Its only violating the srfi process to finalize it in this way.  I'm
trying to outline what the delta is between the SRFI and what you
consider finalization material.  If that delta is too large, than more
discussion is needed, if not then finalization can proceed.  Adding a
references section and a paragraph discussing parallels to other SRFIs
and R5RS is minor indeed.

> > If you feel there are damning incompatibilities, please state them.
>
> I have already. I shouldn't have had to, though. The SRFI was supposed
> to do that up-front.

Again, I impore you to restate them as points so we can discuss them as
adults.

>
> > This is subjective unless you are unwilling to agree to the premise
> > that future SRFIs defining more specific operators that can only be
> > applied to some or many (but not all) collections can define these
> > operators.
>
> That is insufficient, for reasons that Bear has already given.
And which I refuted. Feel free to continue to ignore me and disagree.

> >>    and is not yet mature enough for standardization."
>
> > This is subjective as well.  The major reason for being overdue is
> > that virtually no discussion happened during the summer break.
>
> What does summer break have to do with it? Engineers don't have a summer
> break. Even for the academics, there's been 30 days before summer and 60
> days after it. And you're still making revisions, and reviewers are
> still discussing the proposal. The proposal *has* been revised over 3
> times, and there are still major issues remaining.

Many of the list participants work for universities and use their time
off for other projects, vacations.  This is a well known lull.  Please
hand waving about major issues and start discussing them.

>
> This is not a mature proposal. Don't you get that?
Thank you once again for your subjective opinion.  Its very constructive
to the discussion.

> > It very much implements the collections it specifies.  Beyond that
> > this is the call of the editors once again.  I'll also refer you to
> > precedent set by SRFI-35 which both specifies conditions but defines
> > none, defering that to SRFI-36.
>
> Weren't they both proposed at the same time? The template and a concrete
> implementation? You'd do well to follow that lead.

The task of specifying the structure for collections and the collections
is far too large to cover in either one SRFI or all at once.  You may
not like it, but this is the right approach.  All other arguments aside,
this is the most widely agreed upon.

>
> > A poor implementation refers to an implementation of the SRFI that has
> > flaws.
>
> SRFI-44 has several flaws. It fails to meet the requirements of a SRFI,
> and several reviewers contend that it fails to meet its own goals.

You're contradicting yourself.  You refered to flaws in the
implementation, now you're saying the implementation is fine but the
SRFI is flawed.  You can't use one side to justify the other.

>
>     Any proposal still under active discussion and revision after 90
>     days is not ready for codification. It will then be withdrawn for a
>     (normal) minimum of 30 days after which it may be resubmitted.
>
> don't you understand? Read the SRFI Process Document. Read the FAQ.

I know the process. But this discussion is irrelevant to the viability
of the SRFI.

	Scott

----- End forwarded message -----

--