in reply to Lazy Lists as a model for implicit parallelism
In general a map can aggregate multiple values per call to the transforming block, so accessing @result[7] would fill @result eagerly up to index 7, so the expected output looks something like this:
[0][1][2][3][4]13 [5][6][7]57 3
I seem to recall that TimToady actually said that map (and likewise for) do guarantee an order of execution, so even if the compiler can prove that the block passed to map will only ever return exactly one item, it will still process them in the way I described.
The :injective flag is a nice idea on your behalf, but since the array has to know how to evaluate itself (not just the map) that's a bigger change than just adding a flag to a builtin, it requires a different underlying List implementation.
Together with the other flags you propose I think that there are too many confusing options on how to process lists. If we do integrate them into the language, we'll see dozens of threads on perlmonks discussing the merits and drawbacks of the various flags when they are really just premature optimizations.
The current state of the specification also suggests that laziness is not strict, ie the map is actually allowed to process more than it has to, as long as it doesn't suck up infinite resources when trying to process an infinite list.
So my proposal is to use (lexically scoped) pragmas instead:
use List qw/strict-lazy/; # now all list processing is haskell-like strictly lazy # this is mostly good for testing laziness ;) use List qw/parallel/; # allow parallel processing of lazy lists, even when # when it's not that lazy. This is the default.
I think that all further attempts to control what happens under the hood are
|
|---|