[Haskell-cafe] IO is not a monad

[Lennart Augustsson]

I don't think disallowing seq for functions makes them any more
second class than not allow == for functions.  I'm willing to
sacrifice seq on functions to get parametricity back.
There is a good reason seq cannot be defined for functions in
the pure lambda calculus...  It doesn't belong there. :)

	-- Lennart

On Jan 23, 2007, at 11:06 , Yitzchak Gale wrote:

> Hi,
>
> Lennart Augustsson wrote:
>> Could you explain why would a class Seq not be sufficient?
>> If there were a class Seq, I'd not want functions to be in
>> that class.
>
> Oh, I see. Well that is pretty much the same
> as ignoring seq altogether. I am hoping to get
> a better answer than that - where we can see
> how strictness questions fit in with the theory
> of monads.
>
> Anyway - why do you not want seq for functions?
> Are you making functions second-class citizens
> in Haskell, so that function-valued expressions
> can no longer be lazy? If not, then how do you
> force strictness in a function-valued expression?
>
> For example:
>
> Prelude Data.List> let fs = [const 0, const 1]::[Int->Int]
> Prelude Data.List> let nextf f g = fs !! ((f (0::Int) + g (0::Int)) 
> `mod`2)
> Prelude Data.List> :t nextf
> nextf :: (Int -> Int) -> (Int -> Int) -> Int -> Int
> Prelude Data.List> foldl' nextf id (concat $ replicate 100000 fs) 5
> 0
> Prelude Data.List> foldl nextf id (concat $ replicate 100000 fs) 5
> *** Exception: stack overflow
>
> Regards,
> Yitz