Simon Marlow simonmar@microsoft.com writes:
I'm currently re-implementing GHC's I/O library, and I'd like to get people's opinions on the following I/O extensions currently provided by GHC - should we continue to provide them or not.
1. IOExts.hConnectTo
This was designed to be a way to have one handle automatically flushed before we flush another handle (eg. outputting to stderr causes stdout to be flushed first). The current implementation has a number of problems: errors and blocking arenn't handled properly when doing the connected flush. If no-one is using it, I'd like to get rid of it.
If you handle std{in,out,err} connectedness in other ways, I think you've covered 99.2% of the uses of hConnectTo. Neat idea borrowed from Korn & Vo's SFIO, but it hasn't proved to be all that useful.
2. IOExts.withHandleFor
This is a cunning hack to allow you to temporarily redirect one handle to another, like 2>&1 in shell speak. I'm dubious as to whether it works consistently - there's certainly not enough error checking in the implementation, so if no-one is using it I'd like to drop it.
Don't mind seeing it going. --sigbjorn