[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[: Re: Reasons for withdrawal]



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

To: "Bradd W. Szonye" <bradd+srfi@xxxxxxxxxx>
Subject: Re: Reasons for withdrawal

On Tue, Oct 28, 2003 at 02:22:43PM -0800, Bradd W. Szonye wrote:
> scgmille@xxxxxxxxxxxxxxxxxx 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 -----

-- 

Attachment: pgpa5pQz3UAaD.pgp
Description: PGP signature