On Wed, 12 Aug 2009 08:34:28 -0500 Derek Elkins <derek.a.elk...@gmail.com> wrote:
> On Tue, Aug 11, 2009 at 3:51 PM, Robin Green<gree...@greenrd.org> > wrote: > > On Wed, 12 Aug 2009 11:37:02 +0200 > > Peter Verswyvelen <bugf...@gmail.com> wrote: > > > >> Yes, sorry. > >> > >> But I think I already found the answer to my own question. > >> > >> DDC functions that are lazy don't allow side effects: > >> http://www.haskell.org/haskellwiki/DDC/EvaluationOrder > >> > >> Anyway it would be cool if the DDC EffectSystem would also work on > >> lazy functions :) > > > > As was just pointed out in the unsafeDestructiveAssign thread from > > which this thread was forked, effects are incompatible with > > non-strict evaluation. > > No, they aren't. At least, they aren't in any technical way. There > have been more than a few languages supporting both laziness and > mutation starting with Algol. OK, explicitly creating thunks, like in Algol, LISP and CAL, can work, because you can either prevent the programmer from using mutation inside a thunk (as in the CAL approach), or rely on the programmer to ensure that mutations are only done in a safe order (as in the "callback as thunk" approach, which can be done in almost any impure language). But if almost *every* expression is a thunk, as in a non-strict language like Haskell, and if moreover evaluation order can differ depending on the compiler/interpreter, or compiler version, or compiler flags, it becomes impractical to combine them. So yes, I agree, it's not an absolute technical incompatibility, it's a practical one. > > Also, effects would destroy modular reasoning. > > Again, it is purity, not laziness, that allows compositional > reasoning. Effects destroy compositional reasoning in a strict > language just as much. Not really - in a strict language, if in method M action A always happens before action B, then that fact will remain true in whichever context M is called (ignoring threading issues). In a non-strict, impure language, assuming monads are not used, if you have a function f which performs actions A and B, and two other functions g and h which both call f, the actions could happen in one order in g, and in the opposite order - or not at all - in h, because of a difference in data demanded by each function. Indeed, unless g and h are "top-level" functions (in the sense that they are main functions or invoked from some ghci-equivalent) the notion of "the" order the actions are performed in is ill-defined, because it could vary depending on which function g or h is being called from. Now, you could say, the strict order of evaluation can be simulated in a non-strict language on a case-by-case basis by using monads or whatever. Well, yes, but that would be missing the point, because the original point of this discussion was to avoid having to use monads. -- Robin _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
