Re: [Haskell-cafe] Replacing stdin from within Haskell

On 11/06/2011, at 3:42 AM, Brandon Allbery wrote:

On Fri, Jun 10, 2011 at 00:36, Richard O'Keefe wrote:

...

The point is that they *could* have. The fact that they do not has nothing whatever to do with UNIX. It was a Haskell design decision.

I have this feeling you're looking at it backwards... The question was whether GHC could do this. My answer was based on "given the way GHC's I/O manager works, it would require the OS to support thread-independent file descriptors"; if I understand you correctly, this is an unacceptable approach, the only valid one being "given that OSes don't implement per-thread file handles, GHC is not designed to do this". So, why is that a privileged viewpoint?

No, you do not understand me correctly. Amongst other things, I said nothing about per-thread file handles. In fact, the whole point of what I said was that there is no *necessary* connection between operating system file handles and the things visible to Haskell source code whatever. Given that - a forkIO process can use Haskell file handles created in the parent process - the threads created by forkIO are not necessarily the same as operating system threads per-OS-thread file descriptors wouldn't be that much help anyway. Much about GHC has changed and will change. If anyone had seriously *wanted* GHC to support per-forkIO-thread standard-input and -output, it could have been designed to do that. It seems extremely odd to regard the current implementation as providing a "privileged viewpoint". Haskell threads are supposed to be lightweight cheap things that programmers can use without worrying about how big to make the stack (as in POSIX threads) or without worrying about running out of OS resources (like file descriptors) due to hidden resource allocation. The more ad hoc features get wired into Haskell threads, the harder it gets to implement them, the riskier it seems to use them, and the harder it gets to understand them. *This* is the privileged viewpoint: per-thread-stdin is not supported because nobody much *wants* it to be. There are other mechanisms (monad transformers, implicit parameters) for solving this problem.