Is this really the case? Or is just hard to implement? I mean, if...then...else is always kind of lazy in it's 2nd and 3rd argument, but I think DDC handles this correctly even with the presence of side effects (not sure, but it has a little presentation about it: http://cs.anu.edu.au/people/Ben.Lippmeier/talks/poisoning-20090618.pdf)
And it's still possible to reason about a function with side effects in DDC since the side effects are visible in the type signature (you might need a good editor that shows you the inferred signatures, as done with F#). I mean it's possible to reason about monadic ST or IO no? I agree it's hard to reason about code that is not honest about side effects in its type signature. So couldn't this be generalized? If might completely miss the point here since I'm not at all academic, I'm an old school imperative hacker. On Tue, Aug 11, 2009 at 10:51 PM, Robin Green<gree...@greenrd.org> wrote: > As was just pointed out in the unsafeDestructiveAssign thread from which > this thread was forked, effects are incompatible with non-strict > evaluation. The compiler is supposed to be able to reorder non-strict > evaluation to do optimisations, but that can't be done if effects > could happen. Also, effects would destroy modular reasoning. > -- > Robin > _______________________________________________ > 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
