31-Dec-2013 05:53, Joseph Cassman пишет:
On Sunday, 29 December 2013 at 22:02:57 UTC, Dmitry Olshansky wrote:
[...]
Interesting idea. Seems to fill a need I have been facing with some
parsing code.
Since I was unclear about how its functionality compares to ForwardRange
I took a look through std.algorithm. If typed versions of
lookahead/lookbehind were added it seems like ForwardRange could be
replaced with this new range type, at least in certain places. For
example, it seems to me that the following code (from the article "On
Iteration"
https://www.informit.com/articles/article.aspx?p=1407357&seqNum=7)
ForwardRange findAdjacent(ForwardRange r){
if (!r.empty()) {
auto s = r.save();
s.popFront();
for (; !s.empty();
r.popFront(), s.popFront()) {
if (r.front() == s.front()) break;
}
}
return r;
}
The trick is that the name Forward range is misleading actually (I was
surprized myself). A proper name would be ForkableRange, indeed look at
this code:
auto s = r.save();
s.popFront();
s is a fork of r (independent view that has a live of its own).
The original algortihm even _reads_ easier if the correct term is used:
auto s = r.fork();
s.popFront();
...
Now it's clear that we fork a range and advance the forked copy one step
ahead of the original.
also could be written as
BufferedRange findAdjacent(BufferedRange r) {
for(;!r.empty;r.popFront()) {
if(r.front == r.lookahead(1)[0]) break;
}
return r;
}
Aye, just don't forget to test lookahead for empty instead of r.empty.
Perhaps the mark and/or slice functionality could be leveraged to do
something similar but be more performant.
If anyone can see how the new range type compares to ForwardRange that
would be cool.
I'm thinking there might be a way to bridge the new range type with
ForwardRange but not directly as defined at the moment.
A possibility I consider is to separate a Buffer object (not a range),
and let it be shared among views - light-weight buffer-ranges. Then if
we imagine that these light-weight buffer-ranges are working as marks
(i.e. they pin down the buffer) in the current proposal then they could
be forward ranges.
I need to think on this, as the ability to integrate well with
forwardish algorithms would be a great improvement.
--
Dmitry Olshansky
