[Haskell-cafe] Re: Control.Exception.evaluate - 'correct
definition' not so correct
lennart at augustsson.net
Fri May 9 18:13:39 EDT 2008
GHC already ignores the existence of seq, for instance when doing list
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.
On Tue, May 6, 2008 at 3:27 PM, Luke Palmer <lrpalmer at gmail.com> wrote:
> On Tue, May 6, 2008 at 2:50 AM, apfelmus <apfelmus at quantentunnel.de>
> > 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?
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe