RFC on range design for D2

[Andrei Alexandrescu]

Benji Smith wrote:
> 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.

Hmm, HMMs :o). If you could do it with Java's hasNext and next, you can 
do it with D's isEmpty and next. There's no difference.


Andrei