RFC on range design for D2

[Benji Smith]

bearophile wrote:
> 6) Built-in data types are important, they aren't meant to replace a good standard library, where you can find more specialized and more efficient data structures. The built-in data types are meant to:
> - offer a very handy syntax, easy to use and remember, short to type too.
> - They have to be efficient in a very wide variety of situations, so they must avoid having really bad peformance in a large number of situations, while it's okay for them to be not much fast in any situation.
> - They are useful for example when you have little data, in 90% of the code where max performance isn't so important. In the other situations you are supposed able to import things like an IntrusiveRedBlackHashMap from the std lib.

I'd also add this:

A built-in data-type can't implement an interface, so there should be 
one and only one obvious implementation of its interface. For example, 
it would be a mistake to have a "File" as a built-in type, because a 
"File" really ought to implement an "InputStream" interface, so that 
people can write stream-consumer code generically.

It's one of the reasons I think dynamic arrays and associate arrays 
belong in the standard library (as List and Map interfaces) rather than 
as built-in types.

On a separate note...

I'm also a little skeptical about the range proposal (though I'll have 
to give it more thought any maybe play with an implementation before I 
can come to any firm conclusion). The proposal seems to cover the 
standard cases, of bounded and unbounded forward iteration, reverse 
iteration, etc.

But I can think of a few examples where the concept of "iteration" needs 
to be even more generalized.

For example, I worked on a project last year (in Java) that used a 
hidden markov model to navigate through the nodes of a graph, driving a 
montel carlo simulation.

I designed the MarkovModel<T> class to implement the Collection<T> 
interface so that I could use foreach iteration to crawl through the 
nodes of the graph. It basically looked like this:

     MarkovModel<SimulationState> model = ...;

     for (SimulationState state : model) {
        state.doStuff();
     }

The cool thing about this is that the simulation would continue running 
until it reached a natural termination point (a simulation state with no 
outbound state transition probabilities).

Depending upon the particulars of the model, it might never end. And 
although the ordering of the nodes was significant, it was never 
deterministic. Iterating through the states of a markov model is 
essentially a probabilistically guided random-walk through the elements 
of the collection.

For me, java iterators made a very natural design choice, since the 
iterator is such a dirt-simple interface (with just a "hasNext" and 
"next" method).

How would the D range proposal address the sorts of problems that 
require non-deterministic iteration? To me, the metaphor of a "range" is 
nice, but it doesn't cover all the cases I'd like to see in a 
general-purpose iteration metaphor.

Thanks!

--benji