4 ms·

So... a Haskell approach?

by jfoutz 10y ago

m_mueller 10y ago
I'm not very literate with Haskell, but didn't OP have to do a quirky hack with reading the length of the file into the void in order to get rid of open file handles? That doesn't seem to me like Haskell is well designed at letting me take over resource management if the need arises.
- DasIch 10y ago
  This is a problem with that specific API and and not an issue with Haskell in general. Conduit and Pipes both solve this problem.
- lomnakkus 10y ago
  It's easily avoided: Just never use the lazy I/O functions. (Not sure if hlint perhaps has a warning you can apply here. It probably should.) There are real non-brittle solutions to streaming I/O, pipes[1], conduit[2], or io-streams[3] being the most popular AFAICT. (The latter is probably the easiest to use, but is somewhat less 'composable' than the other two, especially if you have monad transformer stacks, etc.) Either that, or just use strict I/O if you're just working with smallish files. Essentially lazy I/O was a mistake that's unfortunately very hard to fix nowadays without presumably breaking a lot of working-but-potentially-brittle code. Perhaps the time is ripe for starting to actually deprecate them officially... at least almost everyone in the Haskell community seems to agree that it was a mistake and they are a constant trap for newbies. [1] http://hackage.haskell.org/package/pipes http://hackage.haskell.org/package/pipes [2] https://hackage.haskell.org/package/conduit https://hackage.haskell.org/package/conduit [3] https://hackage.haskell.org/package/io-streams https://hackage.haskell.org/package/io-streams
  - paulajohnson 10y ago
    I wouldn't want to see lazy IO disappear altogether because if you are just processing a file line by line then its a quick and dirty solution that will work fine in practice. However I agree it should come with health warnings and pointers to more scaleable solutions.
    - lomnakkus 10y ago
      Strict I/O is absolutely fine for most of those "process-a-file" use cases and io-streams works for the rest.

So... a Haskell approach?

by jfoutz 10y ago

So... a Haskell approach?

I'm not very literate with Haskell, but didn't OP have to do a quirky hack with reading the length of the file into the void in order to get rid of open file handles? That doesn't seem to me like Haskell is well designed at letting me take over resource management if the need arises.

DasIch 10y ago
This is a problem with that specific API and and not an issue with Haskell in general. Conduit and Pipes both solve this problem.
lomnakkus 10y ago
It's easily avoided: Just never use the lazy I/O functions. (Not sure if hlint perhaps has a warning you can apply here. It probably should.) There are real non-brittle solutions to streaming I/O, pipes[1], conduit[2], or io-streams[3] being the most popular AFAICT. (The latter is probably the easiest to use, but is somewhat less 'composable' than the other two, especially if you have monad transformer stacks, etc.) Either that, or just use strict I/O if you're just working with smallish files. Essentially lazy I/O was a mistake that's unfortunately very hard to fix nowadays without presumably breaking a lot of working-but-potentially-brittle code. Perhaps the time is ripe for starting to actually deprecate them officially... at least almost everyone in the Haskell community seems to agree that it was a mistake and they are a constant trap for newbies. [1] http://hackage.haskell.org/package/pipes http://hackage.haskell.org/package/pipes [2] https://hackage.haskell.org/package/conduit https://hackage.haskell.org/package/conduit [3] https://hackage.haskell.org/package/io-streams https://hackage.haskell.org/package/io-streams
- paulajohnson 10y ago
  I wouldn't want to see lazy IO disappear altogether because if you are just processing a file line by line then its a quick and dirty solution that will work fine in practice. However I agree it should come with health warnings and pointers to more scaleable solutions.
  - lomnakkus 10y ago
    Strict I/O is absolutely fine for most of those "process-a-file" use cases and io-streams works for the rest.