Re: [Haskell-cafe] Re: Control.Exception.evaluate - 'correct definition' not so correct

GHC already ignores the existence of seq, for instance when doing list fusion. The unconstrained seq function just ruins too many things. I say, move seq top a type class (where is used to be), and add an unsafeSeq for people who want to play dangerously. -- Lennart On Tue, May 6, 2008 at 3:27 PM, Luke Palmer wrote:

On Tue, May 6, 2008 at 2:50 AM, apfelmus wrote:

...

Concerning the folklore that seq destroys the monad laws, I would like to remark that as long as we don't apply seq to arguments that are functions, everything is fine. When seq is applied to functions, already simple laws like

f . id = f

are trashed, so it's hardly surprising that the monad laws are broken willy-nilly. That's because seq can be used to distinguish between

_|_ :: A -> B and \x -> _|_ :: A -> B

although there shouldn't be a semantic difference between them.

It seems that there is a culture developing where people intentionally ignore the existence of seq when reasoning about Haskell. Indeed I've heard many people argue that it shouldn't be in the language as it is now, that instead it should be a typeclass.

I wonder if it's possible for the compiler to do more aggressive optimizations if it, too, ignored the existence of seq. Would it make it easier to do various sorts of lambda lifting, and would it make strictness analysis easier?

Luke _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe