Endangered I/O operations

[Sigbjorn Finne]

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