Strict getContents

[Li-yao Xia]

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.Text.html#unpack

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