ch-ch-changes

[Denis Koroskin]

Andrei Alexandrescu Wrote:

> Don wrote:
> > Andrei Alexandrescu wrote:
> >> I've worked valiantly on defining the range infrastructure and making 
> >> std.algorithm work with it. I have to say that I'm even more pleased 
> >> with the result than I'd ever expected when I started. Ranges and 
> >> concepts really make for beautiful code, and I am sure pretty darn 
> >> efficient too.
> >>
> >> There's a lot to sink one's teeth in, but unfortunately the code 
> >> hinges on a compiler fix that Walter was kind enough to send me 
> >> privately. I did document the work, but the documentation doesn't 
> >> really make justice to the extraordinary possibilities that lay ahead 
> >> of us. Anyhow, here's a sneak preview into the up-and-coming ranges 
> >> and their algorithms.
> >>
> >> http://ssli.ee.washington.edu/~aalexand/d/web/phobos/std_range.html
> >> http://ssli.ee.washington.edu/~aalexand/d/web/phobos/std_algorithm.html
> >>
> >> Ranges are easy to define and compose efficiently. It was, however, a 
> >> pig to get a zip(r1, r2, ...) working that can mutate back the ranges 
> >> it iterates on. With that, it's very easy to e.g. sort multiple arrays 
> >> in parallel. Similarly, chain(r1, r2, ...) is able to offer e.g. 
> >> random iteration if all components offer it, which means that you can 
> >> do crazy things like sorting data that sits partially in one array and 
> >> partially in another.
> >>
> >> Singly-linked list ranges are in, and to my soothing I found an answer 
> >> to the container/range dichotomy in the form of a topology policy. A 
> >> range may or may not be able to modify the topology of the data it's 
> >> iterating over; if it can, it's a free-standing range, much like 
> >> built-in arrays are. If it can't, it's a limited range tied to a 
> >> container (of which I defined none so far, but give me time) and it's 
> >> only the container that can mess with the topology in controlled ways. 
> >> More on that later.
> >>
> >> Feedback welcome.
> >>
> >>
> >> Andrei
> > 
> > Awesome stuff. Will take some time to adjust my thought processes for this.
> > Some minor comments:
> > * Is Repeat simply a single-parameter form of Cycle? I can't see any 
> > difference between them.
> 
> Cycle takes a range and essentially provides a (potentially mutable!) 
> way of iterating it. Repeat just gives one element. At the moment that 
> element is also mutable, so the difference is moot. I'll consider 
> removing Repeat.
> 
> > * Uniq docs should at least add one word:  Iterates [[consecutively]] 
> > unique elements of the given range.
> > * find:
> > To find the last element of [[a bidirectional]] haystack satisfying 
> > pred, call find!(pred)(retro(haystack)).
> > 
> > (unless Retro also works for forward ranges, which seems unlikely).
> 
> Thanks (and correct).
> 
> > * There's no pushHeap. Is it planned?
> 
> I plan to do something nicer: make Heap an entity of its own instead of 
> a collection of disparate functions. I'm unsure about the name because I 
> mean "the computer science heap" as opposed to "the heap for allocating 
> memory".
> 
> 
> Andrei

Heap is often called a "pyramid" in russian literature, but I'm not sure if it is a worldwide-used term.