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.)
> I don't like this at all, for the following reasons:
Your implementation-related arguments are all bogus.
[...]
> But, the standard handles can be made thread-local, just provide
> access to them through IO! A straightforward implementation
> of IO in a multi-threaded setting might be
>
> type Triple a = (a,a,a)
> newtype IO a = IO (Triple Handle -> _RealWorld -> (_RealWorld, a))
>
> Creating new processes (using Concurrent Haskell's forkIO, say) can
> then easily be augmented to functionally change the interpretation of
> the standard handles for a process. This solution is simple, modular
> and does not require TLS or other RTS Magic.
... and works fine if `stdin', `stdout', and `stderr' are constants!
> I'm only arguing that make the standard handles be connected to IO,
> which is the only context they can *ever* be used.
The fact that the standard handles can only ever be used in conjunction
with an IO is exactly why they can be constant. Think of the
constant value as an index into your triple in IO.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
