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