Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> Ary Borenszweig wrote:
>>> - Is it possible to add elements to a range? Suppose a linked list, you want to traverse it's elements until a condition is met on an element, and then add something after it. Or before it. I see there's "put", but it also says "An output range models a one-pass forward writing iteration.", so I think it's not the same.
>>
>> Never. Ranges never grow. You need access to the "mother" container, which will offer primitives for insertion and removal of elements.
> 
> I agree. I don't think it is ever a good idea to try to add/remove elements of a container while iterating over it. foreach disallows it.

I've found this invaluable at times.  And it's actually supported by C++ containers.  Something along the lines of:

    for( auto i = c.begin(); i != c.end(); )
    {
        if( shouldRemove( *i ) )
            i = c.remove( i );
        else
            ++i;
    }

In fact, it may not even be possible to remove elements of a container outside the inspection loop.  For example, let's say the container is actually a SQL resultset and the iterator is a cursor.  It's easy to mark a row as 'deleted' in this instance, but storing information to perform a deletion later often simply can't be done.  Though I suppose you could argue that the 'container' abstraction may be inappropriate for such temporal data.


Sean

Bill Baxter wrote:
> On Sat, Sep 13, 2008 at 1:03 AM, Pablo Ripolles <in-call@gmx.net> wrote:
>>> Hmm.  One semantic issue I have is that the tip usually refers to the
>>> infinitessimal point at the end.  Not a thing with substance.  I'm
>>> having trouble feeling like I'm going to get an item back when I look
>>> at "x.tip".  Head has huge history being used for the item at the
>>> front of a list, so I think that's much less likely to cause anyone
>>> looking at D code to scratch their heads.  It will be obvious what it
>>> means even in relative isolation.  head/tip will often appear without
>>> "toe" in forward range algos.  So you need to be able to easily
>>> recognize what "tip" means without seeing that "toe" to give context.
>>> Toe on the other hand will probably almost always appear with his
>>> mate.
>>>
>>> Ooh, another scale thing, but a head is obviously a very different
>>> scale than a toe.  A foot is closer to the same scale.  Maybe
>>> head/foot is better than head/toe.  The connection between retreating
>>> / feet is stronger that retreating / toes, too!
>>>
>>> --bb
>> neither the tip of the tail, nor the tip of the wing, nor the tip of the flagellum are really infinitesimal...
>>
>> I'm not sure whether I understand your reasoning about the "tip" / "toe", I interpreted that "tip" could be a substitute of "toe"...
> 
> Nope.  I'm pretty sure that the discussion is about replacing "head"
> with "tip".  There's an expression "from tip to toe".

There's also a song entitled "tiptoe through the tulips," which will probably be stuck in my head for the rest of the day now.

> Well, there is only one tail... but it's what functional guys call
> everything but the head, so Anrdrei wants to avoid it.

And what was wrong with first/last?


Sean

Sean Kelly wrote:
> I've found this invaluable at times.  And it's actually supported by C++ containers.

It's a bad idea, as it can screw up optimization. For example, if you are using a change-and-swap method of updating a collection, the collection cached by the foreach may get trashed.

Walter Bright wrote:
> Sean Kelly wrote:
>> I've found this invaluable at times.  And it's actually supported by C++ containers.
> 
> It's a bad idea, as it can screw up optimization. For example, if you are using a change-and-swap method of updating a collection, the collection cached by the foreach may get trashed.

That's fine... the optimizer has to impose certain requirements.  For such things I'll simply continue using for loops.


Sean

Walter Bright wrote:
> Sean Kelly wrote:
>> I've found this invaluable at times.  And it's actually supported by C++ containers.
> 
> It's a bad idea, as it can screw up optimization. For example, if you are using a change-and-swap method of updating a collection, the collection cached by the foreach may get trashed.

I like the erase(remove) idiom used by STL, see http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Erase-Remove. Oddly enough, it's a variant of moveToFront, the function that allegedly nobody needs :o).

It's efficient and safe. Removing from a collection while iterating runs the risk of becoming quadratic if more than a few elements get removed.


Andrei

Sean Kelly Wrote:

> Bill Baxter wrote:
> > On Sat, Sep 13, 2008 at 1:03 AM, Pablo Ripolles <in-call@gmx.net> wrote:
> >>> Hmm.  One semantic issue I have is that the tip usually refers to the infinitessimal point at the end.  Not a thing with substance.  I'm having trouble feeling like I'm going to get an item back when I look at "x.tip".  Head has huge history being used for the item at the front of a list, so I think that's much less likely to cause anyone looking at D code to scratch their heads.  It will be obvious what it means even in relative isolation.  head/tip will often appear without "toe" in forward range algos.  So you need to be able to easily recognize what "tip" means without seeing that "toe" to give context. Toe on the other hand will probably almost always appear with his mate.
> >>>
> >>> Ooh, another scale thing, but a head is obviously a very different scale than a toe.  A foot is closer to the same scale.  Maybe head/foot is better than head/toe.  The connection between retreating / feet is stronger that retreating / toes, too!
> >>>
> >>> --bb
> >> neither the tip of the tail, nor the tip of the wing, nor the tip of the flagellum are really infinitesimal...
> >>
> >> I'm not sure whether I understand your reasoning about the "tip" / "toe", I interpreted that "tip" could be a substitute of "toe"...
> > 
> > Nope.  I'm pretty sure that the discussion is about replacing "head" with "tip".  There's an expression "from tip to toe".
> 
> There's also a song entitled "tiptoe through the tulips," which will probably be stuck in my head for the rest of the day now.
> 
> > Well, there is only one tail... but it's what functional guys call everything but the head, so Anrdrei wants to avoid it.
> 
> And what was wrong with first/last?

Another few possibilities

fore/aft
front/back
start/end
begin/end

Jerry Quinn wrote:
> Sean Kelly Wrote:
> 
>> Bill Baxter wrote:
>>> On Sat, Sep 13, 2008 at 1:03 AM, Pablo Ripolles <in-call@gmx.net> wrote:
>>>>> Hmm.  One semantic issue I have is that the tip usually refers to the infinitessimal point at the end.  Not a thing with substance.  I'm having trouble feeling like I'm going to get an item back when I look at "x.tip".  Head has huge history being used for the item at the front of a list, so I think that's much less likely to cause anyone looking at D code to scratch their heads.  It will be obvious what it means even in relative isolation.  head/tip will often appear without "toe" in forward range algos.  So you need to be able to easily recognize what "tip" means without seeing that "toe" to give context. Toe on the other hand will probably almost always appear with his mate.
>>>>>
>>>>> Ooh, another scale thing, but a head is obviously a very different scale than a toe.  A foot is closer to the same scale.  Maybe head/foot is better than head/toe.  The connection between retreating / feet is stronger that retreating / toes, too!
>>>>>
>>>>> --bb
>>>> neither the tip of the tail, nor the tip of the wing, nor the tip of the flagellum are really infinitesimal...
>>>>
>>>> I'm not sure whether I understand your reasoning about the "tip" / "toe", I interpreted that "tip" could be a substitute of "toe"...
>>> Nope.  I'm pretty sure that the discussion is about replacing "head" with "tip".  There's an expression "from tip to toe".
>> There's also a song entitled "tiptoe through the tulips," which will probably be stuck in my head for the rest of the day now.
>>
>>> Well, there is only one tail... but it's what functional guys call everything but the head, so Anrdrei wants to avoid it.
>> And what was wrong with first/last?
> 
> Another few possibilities
> 
> fore/aft
> front/back
> start/end
> begin/end
> 

Bow/stern?

Of course, if we ever get a tree implementation, we have to use port/starboard :p

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:gadn7c$oe5$4@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?

Thanks,

- Dave

On Sat, Sep 13, 2008 at 12:16 PM, downs <default_357-line@yahoo.de> wrote:
> Jerry Quinn wrote:
>> Sean Kelly Wrote:
>>
>>
>> Another few possibilities
>>
>> fore/aft
>> front/back
>> start/end
>> begin/end
>>
>
> Bow/stern?
>
> Of course, if we ever get a tree implementation, we have to use port/starboard :p

PeanutButter/Jelly?
Sonny/Cher?

Ooh I know:
Obama/McCain!

Then we can have fun seeing how far to the left() McCain can go and
how far to the right() Obama can!  It's a race to see who can get to
the middle ground mass appeal positions first!

Seriously though,  its head/foot.  End of story.

--bb

Sean Kelly <sean@invisibleduck.org> wrote:
> Walter Bright wrote:
> > Andrei Alexandrescu wrote:
> >> Ary Borenszweig wrote:
> >>> - Is it possible to add elements to a range? Suppose a linked list, you want to traverse it's elements until a condition is met on an element, and then add something after it. Or before it. I see there's "put", but it also says "An output range models a one-pass forward writing iteration.", so I think it's not the same.
> >>
> >> Never. Ranges never grow. You need access to the "mother" container, which will offer primitives for insertion and removal of elements.
> > 
> > I agree. I don't think it is ever a good idea to try to add/remove elements of a container while iterating over it. foreach disallows it.
> 
> In fact, it may not even be possible to remove elements of a container outside the inspection loop.  For example, let's say the container is actually a SQL resultset and the iterator is a cursor.  It's easy to mark a row as 'deleted' in this instance, but storing information to perform a deletion later often simply can't be done.  Though I suppose you could argue that the 'container' abstraction may be inappropriate for such temporal data.

I think that the Input Range abstraction works fine here.  That is, the 'head' of the Select range is actually a cursor object which has a markForDeletion() method.  It may be bad to allow deletion in generic case, but you can always have a special case to work around.