On Tue, Oct 28, 2003 at 08:25:21PM -0800, Tom Lord wrote:
>
>
>
>     > From: xxxxxx@freenetproject.org
>
>     > > 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