[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:25:21PM -0800, Tom Lord wrote:
> 
> 
> 
>     > From: scgmille@xxxxxxxxxxxxxxxxxx
> 
>     > > You have an interface spec that gives two names to one specification.
>     > > Hello?!?!  Anybody home?
> 
>     > You clearly didn't read *-get-left, *-get-right for the other
>     > collection=20 types.  I will ask you again to read the SRFI
>     > carefully.
> 
> 
> We have in '*-get-{left,right}' a proposed naming convention.
> 
> Both meta-names name the same thing, according to the spec.
> 
> The spec does not provide any information on either:
> 
> 	*) why an implementor should choose one name over the
>            other
> 
> 	*) why a system that relies on the naming convention should
>            use one name in preference to the other
> 
> 
> So, what's the point of them?   Neither users or implementors are
> benefited by the distinction.
> 
> You're saying: well, look at how they're used for particular
> collection types.   
> 
> Swell -- summarizing how they are used is the job of the naming
> convention spec:  a job left undone in this case.
> 
> What is the value of this apparently contentless naming convention
> distinction?
> 
> Why don't we also have (with the same spec):

<snip>  You're being obtuse Tom.

*-get-left,right returns an undefined value for arbitrary collections.  
For sequences and ordered collections it has a very well defined 
meaning.  In the former case it returns the 0th and n-1th items 
respectively, in the latter case the least and most precedent values 
respectively.  This fits naturally with the left and right folds as well 
as the left and right insert operators on sequences.

Imagine a user defines a fetch-and-compute-left function which takes a 
collection, uses get-left to obtain a value and does something to it.  
The reason get-left still works but doesn't return any particular value 
for arbitrary collections is so that fetch-and-compute-left can be 
passed a collection which does have a meaning or one for which it 
doesn't.  Concrete example; the programmer can pass an ordered bag, 
which is implementing a queue.  This will cause the computation to occur 
on a FIFO.  Later, because she doesn't want to rewrite the computation 
logic bound to fetch-and-compute-left but wants to instead pass random 
values, she passes Bradd's hypothetical grab-bag.  Because its not 
ordered and the definition of *-get-left doesn't constrain the value 
except for those collections noted, it too can be passed to 
fetch-and-compute-left and the desired result occurs.

Every operator in the SRFI has been thought through in this manner.  
Nothing is there without a reason.

	Scott

> I don't know if you've noticed but, you know, quite absent any srfi,
> people regularly write code that uses naming conventions that "fit"
> with intuitive expectations and emulate existing standard interfaces.
> What value is there in a srfi that says "*-get-left implies some
> intuitive expectations (but we won't try to say what those are).

If you'd like me to add a paragraph describing the left and right handed 
operators, I'd be glad to.  Don't assume they're just a whim I had after 
eating a bit of underdone potato.

	Scott

Attachment: pgpYehh2ZTuEc.pgp
Description: PGP signature