Sean Kelly <sean@invisibleduck.org> 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?

AFAIK, after Andrei switched to isEmpty/next/first for an Input range some algos started to look ugly to him.  I can't remember him mentioning which algorithms made him so upset that he reconsidered the name. Perhaps it was something about input stream where you called its next and then accessed its first...  Probably it looked a bit bad.

But if we ever get rid of first/head/tip/Obama in Input range then I cannot see a reason why ban first/last.  It's the most clean and abstract pair of all the body/airplane/politician parts being proposed.

Pablo Ripolles wrote:
> Andrei Alexandrescu Wrote:
> 
>> Bill Baxter wrote:
>>
>> -- snip --
>>
>> Andrei
>>
>> P.S. The more I think of it, the more I like "tip" of the range. Short, poignant, easy to remember. Not pressing the red button just yet.
> 
> brilliant! I think "tip" is just fantastic!
> 
> "head" and "tip" wonderful couple.
> 
> yes, *this* one is as neutral as it can be! besides, the tip of something is unique! if you hold something by its toe, which one of how many are you holding? :)
> 
> -- snip --
>
> Cheers!
> 
> 

I don't think people know what rng.tip means at the first glance. I interpret it as a sharp, pointy object, and that makes no sense for an iterator/range.

I still favor "traditional" names e.g. ".tail", ".back" or ".last".

Cheers,
Kenny.

P.S. ".retreat" is a very nice name. I like it. :)

Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> Sergey Gromov wrote:
> > Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> >> Given that in D const is transitive, we can't operate with const the same way C++ does. Consider something as trivial as a copy:
> >>
> >> Tgt copy(Src, Tgt)(Src src, Tgt tgt)
> >> {
> >>      for (; !src.done; src.next) tgt.put(src.tip);
> >> }
> >>
> >> Problem is, you won't be able to copy e.g. an int[][] to another because the types aren't compatible.
> > 
> > If Src is an input range you must make a deep copy.  This holds true for your current design also.  So this algorithm is flawed and it's good if it won't compile.
> 
> Great point. I need to sleep on this some more.

Then I'll continue to think aloud.

------------------------

Here are implementations of a byte-oriented input range on top of a file in both 2- and 3-component input range bases.  I thought 2-component version would be simpler.  They turned out to be almost equivalent.

class FileByteRange2 {
  private FILE* file;

  bool empty() {
    int c = fgetc(file);
    if (c == -1) {
      return true;
    }
    ungetc(c, file);
    return false;
  }

  ubyte next() {
    int c = fgetc(file);
    if (c == -1) {
      throw new Exception("File is empty!");
    }
    return cast(ubyte) c;
  }
}

class FileByteRange3 {
  private FILE* file;
  private bool cached;

  ubyte head;

  bool done() {
    if (!cached) {
      int c = fgetc(file);
      if (c == -1) {
        return true;
      }
      head = cast(ubyte) c;
    }
    return false;
  }

  void next() {
    cached = false;
  }
}

-------------------------

A nice pair for .retreat() is .advance().  The words are even of the same length.  Although I find it hard to imagine advancing or retreating a range.  Needless to say that "next" has nothing to do with ranges at all.

------------------------

Done is not the word.  Range is empty.  It's not good when a range is
done for.
Besides, one can be done with a range before it's empty.

On 2008-09-13 12:42:56 -0400, Sergey Gromov <snake.scaly@gmail.com> said:

> A nice pair for .retreat() is .advance().  The words are even of the
> same length.

But then, why not .next() and .pull()? They're the same length too. :-)


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 2008-09-13 04:18:20 -0400, Pablo Ripolles <in-call@gmx.net> said:

> After having had some sleep, I kind of support Bill's proposal, that is, head/foot, definitely better than head/toe.  It's like the header and the footer! sounds very reasonable.  Of course I also like fore/aft, but thats because my aeronautical engineering bias.
> 
> tip is too ambiguous.
> 
> tail refers to all what comes after the head, not to its tip.
> 
> Cheers!

Anyone suggested head/rear yet?


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Michel Fortin Wrote:

> On 2008-09-13 04:18:20 -0400, Pablo Ripolles <in-call@gmx.net> said:
> 
> > After having had some sleep, I kind of support Bill's proposal, that is, head/foot, definitely better than head/toe.  It's like the header and the footer! sounds very reasonable.  Of course I also like fore/aft, but thats because my aeronautical engineering bias.
> > 
> > tip is too ambiguous.
> > 
> > tail refers to all what comes after the head, not to its tip.
> > 
> > Cheers!
> 
> Anyone suggested head/rear yet?

Hello, if I remember well, yes.  I also like it!  I don't recall the argument against it though...

KennyTM~ Wrote:

> Pablo Ripolles wrote:
> > Andrei Alexandrescu Wrote:
> > 
> >> Bill Baxter wrote:
>  >>
>  >> -- snip --
> >>
> >> Andrei
> >>
> >> P.S. The more I think of it, the more I like "tip" of the range. Short, poignant, easy to remember. Not pressing the red button just yet.
> > 
> > brilliant! I think "tip" is just fantastic!
> > 
> > "head" and "tip" wonderful couple.
> > 
> > yes, *this* one is as neutral as it can be! besides, the tip of something is unique! if you hold something by its toe, which one of how many are you holding? :)
> > 
> > -- snip --
> >
> > Cheers!
> > 
> > 
> 
> I don't think people know what rng.tip means at the first glance. I interpret it as a sharp, pointy object, and that makes no sense for an iterator/range.
> 
> I still favor "traditional" names e.g. ".tail", ".back" or ".last".

Well, me too although I misinterpreted as an alternative to .toe which wasn't the intent anyway... :$

So, yes, I agree .tip is not a nice option, however not for its "sharpness"...

Cheers!

On Sun, Sep 14, 2008 at 9:29 PM, Pablo Ripolles <in-call@gmx.net> wrote:
> Michel Fortin Wrote:
>
>> On 2008-09-13 04:18:20 -0400, Pablo Ripolles <in-call@gmx.net> said:
>>
>> > After having had some sleep, I kind of support Bill's proposal, that is, head/foot, definitely better than head/toe.  It's like the header and the footer! sounds very reasonable.  Of course I also like fore/aft, but thats because my aeronautical engineering bias.
>> >
>> > tip is too ambiguous.
>> >
>> > tail refers to all what comes after the head, not to its tip.
>> >
>> > Cheers!
>>
>> Anyone suggested head/rear yet?
>
> Hello, if I remember well, yes.  I also like it!  I don't recall the argument against it though...

I think it was that if you're thinking body parts, then "rear" means someone's bottom.  There's an expression -- "get your head out of your rear" -- that comes to mind.

--bb

On Sun, Sep 14, 2008 at 8:55 PM, Michel Fortin <michel.fortin@michelf.com> wrote:
> On 2008-09-13 12:42:56 -0400, Sergey Gromov <snake.scaly@gmail.com> said:
>
>> A nice pair for .retreat() is .advance().  The words are even of the
>> same length.

My reasoning was that if you pick any pair of antonyms then its going to suggest that the operation applies to the same thing.  It's the opposite direction *and* the opposite thing, which is why I compared it to the "contrapositive" in another message.   I like retreat because it's the exact opposite of a word that's similar to "next", but not.  Therefore it doesn't lead you to expect that it manipulates the same element.

Another way of looking at it is that both ends are actually doing the same thing -- they're both "advancing" or doing "next".  Just their notion of next is different.  In that sense you could call it more like the "converse" operation.  You could use a notation like STL reverse iterators and have "rhead" and "rnext", (where r is for "reverse").  I like that in that it recognizes that.  I don't like using made-up words, though.

> But then, why not .next() and .pull()? They're the same length too. :-)

I thought about pull -- I think I discarded it sounds like you're pulling something in from somewhere and as a result your range should become bigger.

--bb

Dave wrote:
> 
> "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?

Intersect is good but doesn't reveal an important detail: the operation is not commutative.

Andrei