I think a lot of people have raised a lot of important concerns. Henning's point, I think, is particularly enlightening: "I would not like the name safeWithFile, because withFile is already safe. It's hGetContents that is unsafe." It also composes very poorly—using the contents of more than one file to compute a result will lead to a double application of deepseq. I'm not sure how to address those concerns. One possible path is to have a safeHGetContents, along with RULES in Control.DeepSeq to attempt to erase the double deepseq. I would support adding this function under the name `withFile`, in a new module exported by the deepseq package, as Henning seems to be suggesting. I don't think it's particularly important, but this pattern arises often enough that I think it's worthwhile. John L. On Mon, Oct 13, 2014 at 12:14 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote:
On Sun, 12 Oct 2014, Oliver Charles wrote:
Where are you suggesting this library goes? Your `safeWithFile` needs
`NFData`, but that's in `deepseq` which isn't a dependency of `base`.
It would certainly be located in 'deepseq' or a dependent library. Maybe Control.DeepSeq.IO.withFile would be good. Then it would be clear, that it is just a deepseq variant of withFile.
I would not like the name safeWithFile, because withFile is already safe. It's hGetContents that is unsafe.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries