[Haskell-cafe] interaction between OS processes

[Albert Y. C. Lai]

Bryan O'Sullivan wrote:
> Your problem may be buffering-related (I haven't read your code to 
> check), but if so, there's a fair likelihood that it has nothing to do 
> with the OS.  GHC's runtime does its own buffer management on Handles. 
> It's quite possible that your deadlock lies at that level, rather than 
> anything lower.

Although GHC's runtime kind of re-invents buffering, it still follows 
the Unix convention, i.e., if stdio is determined to be attached to a 
tty, then default to line buffering, else default to block buffering. 
Indeed, I wager that it bothers to re-invent buffering because of some 
other technical necessity (green-threading comes to mind), and if it 
goes out of its way to re-invent buffering, why, of all conceivable 
conventions, the Unix convention again? E.g., why not take this 
opportunity to spare beginners a nasty surprise and default to line 
buffering across the board? It seems to me clearly that the answer is 
precisely to spare the Unix-informed programmers a nasty surprise. 
Therefore although GHC's runtime does its own buffering, a Unix 
education still informs you of what it does. The problem is the same and 
the solution is the same.

Even taking a step back, even if GHC or some other Haskell runtimes or 
some other language runtimes or even other VMs and OSes do not follow 
the Unix convention, a Unix course still serves to alert you of 
buffering issues, that buffering can be weird, that the OS does its 
weird buffering, that a language runtime may or may not add yet its 
weird buffering... You will develop a habit of double-checking with the 
docs and testing, not a habit of just assuming that what you see on a 
tty is what you get on a pipeline. Along the way, you will also see why 
getChar waits for a newline (and why sometimes even a newline doesn't 
suffice)...

It is similar to saying, if you use a high-level language on x86, you 
don't have to learn low-level 680x0. Ah, but knowing low-level 680x0 
informs you of certain issues of the high-level language (e.g., 
performance) and how to use it more successfully. This is despite 680x0 
is not the x86 you use.

It is similar to saying, if you use Haskell, you don't have to learn 
dependent typing. Ah, but knowing dependent typing informs you of 
certain typing issues and how to use the Haskell type system more 
successfully. This is despite tutorials on dependent typing talk about 
Clean or Coq rather than the Haskell you use.

It is similar to saying, if you use Java and C#, you don't have to learn 
Haskell. Ah, but knowing Haskell informs you of certain programming 
issues and how to use Java and C# more successfully. This is despite 
Haskell does not talk about objects.

It is education and personal growth. It is not just vocational training.