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 <[EMAIL PROTECTED]> wrote: > On Tue, May 6, 2008 at 2:50 AM, apfelmus <[EMAIL PROTECTED]> > 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 >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
