Hi Henning, On 9/11/19 2:52 PM, Henning Thielemann wrote:
On Wed, 11 Sep 2019, Li-yao Xia wrote:
The easiest way to get a strict alternative seems to be to explicitly force the list, for example using ```length contents `seq` pure ()```, but that's far from an obvious solution.
I am not sure, whether this works reliably. Evaluating the length of 'contents' only generates the skeleton of the list but not immediately the element values. A cleaner way would be to use 'deepseq'.
That's an interesting question, because I'm pretty confident this is a reliable way to force getContents, but I'm less sure I can convince you of it easily. Thinking of how that could break, I believe that one would have to get out of their way in order to implement getContents such that forcing the list does not also make its characters available even after the file is closed, at which point the author of that function should stop and wonder whether it is worth the trouble, and I trust that the author, if they even considered the possibility, would reach the reasonable conclusion of "don't do that". Of course, that argument can go wrong in many ways, especially because it is full of subjective judgements. So to get some closure, let's look at the source code. Skipping over the intermediate steps that one would have to check for themselves anyway, it boils down to this unpack function: https://hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.IO.Handle.Tex... Near the end of the function is the line that adds a character c as part of the string that will be returned at the end, we can see that the cons comes with the character fully read by peekElemOf: unpackRB (c : acc) (i-1) Cheers, Li-yao