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. 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. 3. IOExts.hGetBuf, IOExts.hPutBuf, IOExts.hGetBufBA, IOExts.hPutBufBA These are the "non-blocking" versions of hGetBufFull, hPutBufFull etc. I can't remember why we have both blocking and non-blocking versions, although I distinctly remember implementing and documenting them :-) If anyone is using, or knows of a good use for, the non-blocking versions, then I'll keep them. Otherwise, I'd like to rename hGetBufFull to hGetBuf, and similarly for the others. Cheers, Simon