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.
