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

Re: Reasons for withdrawal

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.

On Tue, Oct 28, 2003 at 08:56:51PM -0800, Bradd W. Szonye wrote:
> Tom Lord wrote:
> > We have in '*-get-{left,right}' a proposed naming convention.
> > Both meta-names name the same thing, according to the spec.
> Is this the get-left/right for bags? I've already raised this issue.
> These interfaces are inappropriate for bags, which have no concept of
> sequence -- if they did, they wouldn't be bags.

Ordered bags most certainly have a well defined concept of direction.  
Other bags may as well.  For example, a queue is a bag which is not 
ordered in the SRFI-44 sense (the ordering isn't value determined) but 
has a well defined left/right distinction.

> Which model does SRFI-44 follow? Is it attached to a compelling product
> that programmers imitate out of admiration? No. Is it a corporate or
> product standard that programmers are compelled to follow? No. Does it
> include a change process that allows the standard to evolve? No.

> I have, however, seen many failed coding standards that tried the
> approach of SRFI-44.

If you're right you'll see one more.  Whats the harm?

> This is *why* we've been recommending the "publish a concrete
> collections library worthy of imitation" approach. SRFI-44 is trying
> approach #2 above, but that's doomed to fail -- finalization is *totally
> inappropriate* for that kind of standard. Notice how SRFI authors try to
> imitate the interfaces of the "good" SRFIs? That's approach #1 above.

Many disagree with you.  And people imitate the interfaces of previous 
SRFIs in order to provide consistency.  In the area of SRFI-44, there is 
almost no precedent, so thats just not possible.  And interoperability 
is too critical to leave it to chance with your method #1.

> A naming standard SRFI is counterproductive and inappropriate. I've
> already explained how SRFI-44 isn't appropriate for a SRFI. I'll add to
> that: SRFI isn't appropriate for a naming standard. It's a poor fit in
> both directions.

And we're never going to agree.  I guess we'll both just have to live 
with it.

Attachment: pgpkioa6VqP1z.pgp
Description: PGP signature