is std.algorithm.joiner lazy?

Puming via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Thu Apr 7 19:16:36 PDT 2016


On Friday, 8 April 2016 at 01:14:11 UTC, Jonathan M Davis wrote:
> [...]
>
> Well, given your example, I would strongly argue that you 
> should write a range that calls read in its constructor and in 
> popFront rather (so that calling front multiple times doesn't 
> matter) rather than using map. While map can theoretically be 
> used the way that you're trying to use it, it's really intended 
> for converting an element using rather than doing stuff like 
> I/O in it. Also, if the range that you give map is random 
> access (like an array would be), then opIndex could be used to 
> access random elements, which _really_ wouldn't work with 
> reading from a file. So, I think that map is just plain a bad 
> choice for what you're trying to do.
>

Well, I used map because of when viewing the scenario in a data 
flow, map seems an intuitive choise:

what I have: a bunch of large files, each file containing 
sections of data, each sections is composed of many lines of 
record. For each file, I have an list of indices.

what I want: given a list of files and indices for each file, I 
want to construct a lazy stream of records for other program to 
use.

here is the data flow:

query constraints
-> [(filePath, [index])]
-> [(File, [index])] // map, needs cache
-> [[section]] // map, needs cache
-> [[[record]]]  // joiner.joiner
-> Range of record

And after reading cache's docs, I get that cache is perfect for 
converting a Range with front side effect into a Range with 
popFront side effect.

So if cache and map works harmoniously, they should do the same 
trick as manually writing two Ranges here.

>
> - Jonathan M Davis




More information about the Digitalmars-d-learn mailing list