[Yhc] instance Monad IO bug

[shackell at cs.york.ac.uk]

Ah oops, tried to remove the Either as an optimization, forgot that IO
isn't strict in the value ;-)

It should probably be something like

  newtype IO a = IO (World -> _E a)

where _E is just a box to prevent evaluation (it's used in primitive
handling already).

  data _E a = _E a

Then the IO monad would be

instance Monad IO where
   (IO x) >>= yf = IO $ \ w -> let xe = x w
                              in case xe of
                                 _E xv -> case yf xv of
                                            IO y -> y w

   (IO x) >> (IO y) = IO $ \ w -> case x w of
                                   _E _ -> y w

   return a = IO $ \ w -> _E a

>  Maybe an artificial "dependingOn", like
> seq but that doesn't even evaluate its argument to WHNF, is needed?
> (inspired by jhc's primitive dependingOn :: a -> b -> a, which is the
> OPPOSITE argument order (like const, rather than seq) and I'm not sure
> if it has the semantics I'm suggesting, but, whatever...)

Unfortunately the problem isn't (>>), it's return.

    return a = IO $ \ w -> a    -- necessarily evaluates a = wrong

Thus 'return undefined' as soon as you apply it to World (i.e. deIO it) it
goes bang.

The amuzing thing is that none of the conformance tests (and some of them
are serious programs) rely on the laziness of IO values. Otherwise I'm
sure I would have spotted my braino ;-)

Tom