[Haskell-cafe] Haskell-Cafe Digest, Vol 93, Issue 58

[Albert Y. C. Lai]

On 11-06-08 11:17 PM, Gregory Guthrie wrote:
> So the implication of the rules:
>    1) all IO must start from the top level, and there is only one IO
>    2) you cannot extract anything from an IO
>
> Seems to be that the whole program structure becomes a series of do... blocks, which is basically a sequential imperative looking style.
> The general advice of "Strive to keep as much of the program pure as possible" thus seems difficult.

Suppose you teach Java or C++ or any OOP, and you give out this basic 
homework to beginners: write a program to take two complex numbers from 
the user, then print their sum. You are assured to receive such flawed 
design:

class complex {
   double r, i;
public:
   complex() {
     cout << "please enter the real part:";
     cin >> r;
     cout << "please enter the imaginary part:";
     cin >> i;
   }
}

The urge to do I/O at all the wrong places is a born instinct. Humanity 
strives to organize programs (and articles) by stream of consciousness 
rather than by separation of concerns. Why do they ask the user in the 
constructor? Because that's where the editor cursor was when they 
remembered to ask the user. Similarly in Haskell, why do they read input 
in the data processing function? Because that's where the editor cursor 
was when they remembered to read input. This is universal to FP, OOP, 
IP, any P, with or without language restrictions.

For people who organize programs by stream of consciousness, Haskell's 
separation of IO does not help, but SML's and C++'s non-separation does 
not help either. Nothing helps. Don't worry about them.

For people who organize programs by separation of concerns, such as you 
and me: Haskell's separation of IO helps. This is what matters.