[gizmo686]

Linear types don't help here.

The complaint is that with lazyIO, even if your code does the write before closing the file, the actual order the operations occur in could change, to put the close first.

If you look at the lazyIO documentation, you will see:

>Although this module calls unsafeInterleaveIO for you, it cannot take the responsibility from you. Using this module is still as unsafe as calling unsafeInterleaveIO manually. Thus we recommend to wrap the lazy I/O monad into a custom newtype with a restricted set of operations which is considered safe for interleaving I/O actions.

https://hackage.haskell.org/package/lazyio-0.1.0.4/docs/Syst...

TLDR, don't use lazy IO.

[taktoa]

The lazyio package is not what people are talking about when they say "lazy IO".

[dragonwriter]

> The lazyio package is not what people are talking about when they say "lazy IO".

I don't know which people you are talking about, but it clearly was in this specific subthread which started with a complaint about “LazyIO”, not “lazy IO”, and where the only use of “lazy IO” in a post before yours was in a post where all previous references were to “lazyIO” and it's specific package documentation, and contextually the “lazy IO” references was about the same thing, not something else.

[alisonkisk]

You can write bad code in any language if you try hard enough. No one should use lazyio (or any library) for important work without checking the code or at least the docs to see if the code is intentionally bad (and renaming "unsafeInterleaveIO" to "lazyIO.InterleaveIO" is intentionally bad).

One of Haskell's known weaknesses is that there are no curated catalogs of high quality libraries. The industrial strength stuff sits on package servers alongside the broken toys.

I once got an apology from a major luminary in Haskell, author of dozens of high quality packages, because I used a package he wrote that turned out to be an abandoned broken experiment, but not documented as such.