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:

patch 8729af8cea4e67e3582d17fac1a08b988d45b1f3
Author: Ben Franksen <ben.franksen@online.de>
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).

Attachments

• document-laziness-of-commuter-functions-and-slightly-improve-commuterrlfl.dpatch
• patch-preview.txt
• unnamed

>   * document laziness of commuter functions and slightly improve 
commuterRLFL

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.