[Haskell-cafe] Replacing stdin from within Haskell

[Richard O'Keefe]

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

> On Fri, Jun 10, 2011 at 00:36, Richard O'Keefe <ok at cs.otago.ac.nz> 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.