[Haskell-cafe] IO is not a monad

[Aaron McDaid]

Could seq be changed so that it will not give an error if it finds
undefined? Am I right in thinking that seq is supposed to
theoretically do nothing, but simply give a hint to the compiler so to
speak? If that is true, it should merely attempt to evaluate it, but
ignore it if it cannot evaluate it.
Is it realistic or desirable to change seq like this?

Anyway, as far as I can see it is already true that
   (>>= f) . return = f
because 'equality' for Monads simply means they do that same thing
when 'executed' or whatever. The only thing that can currently find a
difference between the above monads is seq and seq is a funny thing.

Aaron

On 2/7/07, Yitzchak Gale <gale at sefer.org> wrote:
> Just for the record, I think this completes the
> requirements of my challenge. Please comment!
> Is this correct?
> Thanks.
>
> > 1. Find a way to model strictness/laziness properties
> > of Haskell functions in a category in a way that is
> > reasonably rich.
>
> We use HaskL, the category of Haskell types, Haskell
> functions, and strict composition:
>
> f .! g = f `seq` g `seq` (f . g)
>
> Let undef = \_ -> undefined. A function f is strict iff
> f .! undef = undef, lazy iff f .! undef /= undef, and
> convergent iff f .! g /= undef for all g /= undef.
>
> We consider only functors for which fmap is a
> morphism.
> A functor preserves strictness iff fmap is strict.
> A functor preserves laziness iff fmap is convergent.
>
> Note that with these definitions, undefined is lazy.
>
> > 2. Map monads in that category to Haskell, and
> > see what we get.
>
> Assume that return /= undef, and that >>= is convergent
> in its second argument.
>
> The monad laws are:
>
> 1. (>>= return) = id
> 2. (>>= f) . return = f
> 3. (>>= g) . (>>= f) = (>>= (>>= g) . f)
> 4. >>= is strict in its second argument.
>
> > 3. Compare that to the traditional concept of
> > a monad in Haskell.
>
> As long as we are careful to use the points-free
> version, the laws are the same as the traditional
> monad laws. In particular, we can use the usual
> composition for these laws. But we must add the
> strictness law.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>