RFC on range design for D2

[Sergey Gromov]

Benji Smith <dlanguage at benjismith.net> wrote:
> Sergey Gromov wrote:
> > Benji Smith <dlanguage at benjismith.net> wrote:
> >> Bill Baxter wrote:
> >>> Hmm, for FSMs you can't really define a good end state.  There may not
> >>> be any particular end state. ... ah, but wait I forgot.  That's the
> >>> beauty of a range -- the end "state" doesn't have to be a "state" per
> >>> se.  It can be any predicate you want it to be.  "Range" is misleading
> >>> in this case.  This is one of those cases where you just have to
> >>> remember "range" means "current value plus stopping criterion".
> >> That's what I was saying earlier.
> >>
> >> I think the mechanics are good. And for contiguous, sequential 
> >> containers, the word "range" is great. For other types of containers, or 
> >> other selection/iteration scenarios, you can shoehorn your mental model 
> >> into the "range" metaphor. But it's weird.
> > 
> > It seems to me like a misuse of ranges.  Do you really want to iterate 
> > over a state machine?  FSM is a mailbox with a 'message' hole.  You put 
> > messages into it and it does things.  How do you iterate over a mailbox?
> 
> Well, no. Not when you put it like that.
> 
> The example I posted earlier went something like this:
> 
>     MarkovModel<ApplicationState> model = ...;
>     for (ApplicationState state : model) {
>        state.doStuff();
>     }
> 
> It's not a bad abstraction. The model handles all of the semantics of 
> calculating the transition probabilities and selecting the next state, 
> so that the foreach loop doesn't have to muss with those details.
> 
> Yeah, it's a total misuse of the "range" metaphor, and that's exactly 
> what I'm saying. In Java, where I implemented this project, an 
> "iterator" is a tiny bit of logic for returning objects in a 
> (potentially endless, potentially reversible) sequence, primarily to 
> support looping constructs. Just because there's no underlying range of 
> objects doesn't mean they're not iterable.
> 
> Of course, Java iterators are *much* more limited constructs than these 
> new D ranges. But I still think the concept has merit. And, like you 
> said, calling them ranges makes them seem stupid. Because they're not 
> ranges.

Well, if you get an object out of there on every step, and that object 
source can exhaust at some point, then the abstraction is correct.

I agree that an input range is actually an arbitrary bounded iterator.  
But you also must agree that a random access iterator in C++ is actually 
an unbounded array.  You always can invent a better name for any 
particular case.  But C++ keeps calling them iterators to pronounce 
generocity and emphasize interchangeability to some degree.  You may not 
notice that calling a string pointer an iterator is a bit awkward and 
misleading, because you get used to it and learned to think that way.

There's no difference with ranges.  Some of them are actual ranges, some 
are not, some are plain abstractions.  You need to learn to think in 
ranges to use them naturally.  This is true for any new language you're 
learning, programming or human, if you want to use them efficiently.