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