Revised RFC on range design for D2

[Pablo Ripolles]

Andrei Alexandrescu Wrote:

> Dave wrote:
> > 
> > "Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
> > news:gadn7c$oe5$4 at digitalmars.com...
> >> Pablo Ripolles wrote:
> >>> Andrei Alexandrescu Wrote:
> >>>
> >>>> In wake of the many excellent comments and suggestions made here, I 
> >>>> made one more pass through the draft proposal for ranges.
> >>>>
> >>>> http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
> >>>>
> >>>> There are some comments in red illustrating some uncertainties (not 
> >>>> all), and the names of the primitives have been updated. Bicycle 
> >>>> shed galore! But don't forget to comment on the reactor as well :o).
> >>>>
> >>>>
> >>>> Andrei
> >>>
> >>>
> >>> Well, it looks prety clean! :D
> >>>
> >>> However, I'm not completely sure I like these "head" and "toe" names 
> >>> selection.  It projects to much on it, doesn't it?  couldn't it be 
> >>> more neutral?  perhaps more conceptual?  I haven't been able to read 
> >>> the last days' comments... but my last impressions were that this 
> >>> "head" was not the best choice.
> >>>
> >>> If "head" is the header item, why not call it "header"?
> >>>
> >>> If ''toe" is the last item, why not call it "last"?
> >>>
> >>> Other comment goes for the "done" property, for the seek of 
> >>> consistence shouldn't it better be named "isDone"?
> >>>
> >>> Cheers!
> >>
> >> Thanks. One problem in coding with first and last was that sometimes 
> >> the code looks unnatural, especially when your range exposes a few 
> >> more functions. In a stream parser, dealing with the "first" element 
> >> is not the most natural way to think of it. But I agree that first and 
> >> last are definitely palatable and natural most of the time. But then 
> >> again, shouldn't any design have the inevitable cutesy that makes it 
> >> memorable? :o)
> >>
> >> Andrei
> > 
> >  From the limited posts I've had the time to read, it seems this topic 
> > has probably been already beaten to death, but how about "tail" instead 
> > of "toe".
> > 
> > And instead of the "yellow" primitive, why not "intersect(r,s)" , 
> > "intersection(r,s)", "r.contains(s)" , "r.intersect(s)" , etc.
> > 
> > Wasn't "intersect" the original?
> 
> Intersect is good but doesn't reveal an important detail: the operation 
> is not commutative.

What about wedge(r, s) or r.wedge(s)? Perhaps meet(r, s) or r.meet(s)?

The source of these proposals is based on the symbols and terms used in the field of algebraic topology.  The meet operation in commutative topologies is the standard intersection, whereas in noncommutative topologies it is implemented employing noncommutative intersection.  In both cases the term (meet) and the symbol (wedge) are used.

Cheers!