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
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
