While pondering whether or not the 'map' function is lazy, I had a flash
of insight.
Let's assume that it is, and go with an example of
@results = map { process_item($_) } @files;
Now ponder the questions of how independent are the iterations of the
block. Must it compute each one in order? Can it use multiple threads?
Can it use cooperative coroutines but only run one at a time?
All those issues can be applied to the realization of a lazy list, after
it has been specified, and regardless of what construct was used to
produce the lazy list. We already know 'eager' and 'hyper'.
Without committing to any specifics, let's just suppose that there are
various methods available on a lazy list, for demanding and/or
controlling the realization of the list. You can have as many such
commands as you need, with as many options as you can think of. It is
open-ended and extensible as technology moves on.
So, given @results as a potential "work list", I could tell it to
proceed to work on those items in the background, on multiple cores,
with a specified priority. Or, I could tell it to work on one at a
time, but it's OK to block in the middle on IO and work on another one
in the meantime. Or, realize them all NOW and don't return until they
are done, or on the first error. Designing the list of such methods and
their options will be a task, but for now just suppose that such methods
will exist.
The default for a lazy list is to compute each item the first time it is
read. The default for a sequential iterator is to allow it to work
ahead as far as it likes, batching the calls.
But, you can change the settings in some detail, and you can command it
to do work now other than by reading from a single value. 'eager' is
equivalent to reading each value, using the current settings for that
list object.
--John
