Strict getContents

[Vanessa McHale]

Wouldn't it be more sensible to not interleave IO in the first place?

Cheers,
Vanessa

On 9/11/19 8:13 PM, Li-yao Xia wrote:
> 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
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries