[Haskell-cafe] IO is not a monad
lennart at augustsson.net
Tue Jan 23 19:46:41 EST 2007
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. :)
On Jan 23, 2007, at 11:06 , Yitzchak Gale wrote:
> 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))
> Prelude Data.List> :t nextf
> nextf :: (Int -> Int) -> (Int -> Int) -> Int -> Int
> Prelude Data.List> foldl' nextf id (concat $ replicate 100000 fs) 5
> Prelude Data.List> foldl nextf id (concat $ replicate 100000 fs) 5
> *** Exception: stack overflow
More information about the Haskell-Cafe