In addition, I think that the non-lazy versions should either be re-written
so that their result lists can be consumed lazily or else they should use a
strict accumulator in order to avoid building up large unevaluated
expressions. This is exactly the same situation as for foldl vs. foldl'.
1 patch for repository http://darcs.net/screened:
Author: Ben Franksen <firstname.lastname@example.org>
Date: Tue Sep 11 20:40:16 CEST 2018
* document laziness of commuter functions and slightly improve commuterRLFL
The result lists of commuterRLFL are now produced in an alternating fashion,
so that both can be consumed lazily (from head to tail).
> * document laziness of commuter functions and slightly improve
Looks fine. I don't think I'd thought about laziness issues with
these functions before. But for the Id/List functions, I think
the behaviour is inevitable with the variants that aren't lazy
given the structure of the input; even if we don't have a large
unevaluated thunk we'll still be storing the full list, so there's
no asymptotic improvement to be had, unlike with foldl' (+) where
the result is constant size.
If we wanted to be sure commuterRLFL retains its new properties we'd
need to write some tests.