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