RFC on range design for D2

[Bill Baxter]

On Thu, Sep 11, 2008 at 9:41 AM, Benji Smith <dlanguage at benjismith.net> wrote:
> Bill Baxter wrote:
>>
>> So far though we don't seem to be able to come up with a good example
>> other of where ranges are weak than traversing a list back and forth.
>>
>> ...
>>
>> But it is a little fishy that we can't come up with any other example
>> besides sliding a bead on a wire back and forth.
>
> I dunno about that.
>
> I can think of lots of examples where the "range" metaphor is an awkward
> interloper between the container and the iteration logic:
>
> maps, sets, bags, markov models, graphs, trees (especially in a
> breadth-first traversal)

Iterators for maps, sets, bags, graphs, trees are usually either for
pointing to a found element or for iterating over the whole thing.
With ranges the former just becomes a degenerate range where only one
end is actually important.  The other end would probably be then end()
of the container in the STL sense.
The latter is no problem if you just want to forward iterate over everything.

> The word "range" and the idea of the range "moving", "shrinking", or being
> "empty" only matches my concept of "iteration" if I think strictly in terms
> of sequential containers (arrays, slices, lists, etc).

For the one-way ranges, the range is equivalent to a forward iterator
plus an end().  You can do exactly the same things with it.  The end()
may very happily not actually exist, though, if not needed, or if it
depends on some dynamic condition, like for your HMM example.

> I think the range methaphor is a very cool way of connecting sequential
> containers with algorithms (especially divide-and-conquer algorithms, which
> seem particularly well-suited to the range metaphor).
>
> But if I want to visit each <p> node in a DOM tree, I have a hard time
> visualizing how a "range" fits into that process.

For that you just use a forward range, which is just forward iterator
plus a stopping criterion, that's all.

> Maybe it's just terminology. I'm not sure yet.

Maybe.

There is one thing so far that we can point to and say "ranges aren't
so great for this".  That's the case where you want to scan forward
*and* backward over your data.  But I now believe that std lib
functions can cover that usage case in a non-burdensome way, too.

--bb