On Wednesday, 7 October 2015 at 15:06:55 UTC, Mike Parker wrote:
> I'm looking for ideas on how to label the ranges returned from take and drop. Some examples of what I think are appropriate categories for other types of ranges:
>
> Generative - iota, recurrence, sequence
> Compositional - chain, roundRobin, transposed
> Iterative - retro, stride, lockstep
> XXX - take, drop

I'm guessing you're thinking about categorizing the list at

http://dlang.org/phobos/std_range.html

, right? ;)

That would, IMHO, be a nice usability/discoverability improvement, especially for new users!

:)

Further, I've thought about adding some kind standardized graphical explanation for the ranges and algorithms in Phobos.

I've Googled a bit on this topic, say:

"algorithm visualization"

but I can't seem to find any concrete work on this topic. Refs ideas anyone?

What file format would be preferred for such graphical descriptions? I'm guessing SVG would be a good contender.

A supercool thing would be if we, with the help of D's marvellous meta-programming and CT/RT-reflection, could auto-generate these visualizations.

On Friday, 9 October 2015 at 10:01:47 UTC, Per Nordlöw wrote:
> I've Googled a bit on this topic, say:
>
> "algorithm visualization"

"Software Visualization" seems to be the correct research term.

On Friday, 9 October 2015 at 10:01:47 UTC, Per Nordlöw wrote:

>
> I'm guessing you're thinking about categorizing the list at
>
> http://dlang.org/phobos/std_range.html
>
> , right? ;)
>
> That would, IMHO, be a nice usability/discoverability improvement, especially for new users!
>
> :)
>

This is for the "Learning D" book I'm currently doing revisions on. In the chapter on std.range and std.algorithm, there was an imbalance with the latter being neatly categorized into the different modules. It looked odd having the std.range stuff all lumped under one section heading. One of the technical reviewers (rightly) didn't like my initial "Selfish" category, and I agree.

On Friday, 9 October 2015 at 16:08:58 UTC, Mike Parker wrote:
> This is for the "Learning D" book I'm currently doing revisions on. In the chapter on std.range and std.algorithm, there was an imbalance with the latter being neatly categorized into the different modules. It looked odd having the std.range stuff all lumped under one section heading. One of the technical reviewers (rightly) didn't like my initial "Selfish" category, and I agree.

I can certainly understand trying to categorize ranges like this, but at the same time, it seems like there's such a range of things - pun intended :) - that they can do that it quickly becomes about as tenable to categorize ranges as it does to categorize _all_ functions, which is pretty questionable IMHO. In general, I don't think I'd even bother trying to categorize them except to the extent required to figure out which package or module to stuff them in (like you have to do with any function), but it can be more important to categorize stuff in a teaching setting.

- Jonathan M Davis

On Wednesday, 7 October 2015 at 15:39:03 UTC, Jonathan M Davis wrote:
> Eager is far more general. Also, while the drop* functions are eager, the take* functions are not.

I don't recall the precise details of these particular ranges off the top of my head (away from computer so can't easily check), but one nasty little detail of supposedly lazy ranges is that they are often eager for the first element, lazy thereafter -- and even there it's subtly different from 'true' laziness inasmuch as the new values are generated at the point of popping rather than the point of access to the new front.

In most cases that's an implementation detail, but it gets _very_ interesting when the elements of your range are non-deterministic.