Fergus Henderson writes:
> Sigbjorn Finne, you wrote:
> >
> > OK, so stdin is not a global constant anymore, but is stashed away in
> > TLS somewhere.
>
> No! stdin _is_ a global constant.
> What is stashed away in TLS is the binding of stdin to whichever
> file it happens to be bound to. Of course if your thread implementation
> doesn't have TLS as such, you can put this binding in the thread-local
> IO state. (Your thread implementation *must* have this, if redirecting
> stdin for a thread can be implemented at all.)
>
Right, the implementation of IO could be an environment + state monad,
carrying around the current bindings for the standard handles (I gave
the type for the obvious way of representing this). But, the *thread
implementation* can be oblivious to all of this, which is a Good Thing
(threads aren't necessarily IO-bound, you could have one performing
ST actions, for instance).
If I'm understanding Lennart and you correctly (finally, I hear you
say!), the representation you prefer, would have an implementation
something like the following in a multi-threaded setting:
data Handle
= Stdin
| Stdout
| Stderr
| Other _FilePtr -- say
stdout = Stdout
and then have hPutStr do the following:
newtype IO a = IO ((Handle,Handle,Handle) -> PrimIO a)
hPutStr :: Handle -> String -> IO ()
hPutStr h str (stdin,stdout,stderr) =
case h of
Stdout -> primPutStr stdout str
Other fp -> primPutStr fp str
_ -> fail "...."
with putStr then just being
putStr str = hPutStr stdout str
whereas I want
stdout = getStdout
putStr str =
do
h <- stdout
hPutStr h str -- primPutStr (+valid handle check), really.
I don't think we're in violent disagreement here - the sink for
standard output is fixed wrt. to the IO context of the thread
executing, but all IO actions have an associated output stream.
My choice of how to do this would require the introduction of
IO operations for accessing a standard handle's current bindings (as
well as setting them), yours wouldn't require an extension - you win :-)
Regards,
--Sigbjorn
