68 messages
1234
Open this post in threaded view
|

Open this post in threaded view
|

 Hi > The following is one of the laws. > > (x >>= f) >>= g == x >>= (\v -> f v >>= g) Or stated another way: (x >>= f) >>= g == x >>= (f >>= g) Now it should be easier to see that this is simply associativity. It's easy enough to violate, if you want to - but I don't have any nice simple examples to hand. Thanks Neil _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe
Open this post in threaded view
|

 Now it should be easier to see that this is simply associativity. It's easy enough to violate, if you want to - but I don't have any nicesimple examples to hand.I have recently been reading a tutorial or paper where a Monad that violated this law was presented. The authors shrugged it off as not important, that the notation gained by implementing the operation as a Monad was worth it, but what is not clear is what the consequences of violating such associativity are. Does violating this law introduce the potential that your program will not do what you think it should?/mike. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe
Open this post in threaded view
|

Open this post in threaded view
|

Open this post in threaded view
|

Open this post in threaded view
|

Open this post in threaded view
|

Open this post in threaded view
|

 On Feb 11, 2008 1:35 PM, Andrew Butterfield <[hidden email]> wrote: > Hugs> 1.0 + (2.5e-15 + 2.5e-15) > 1.00000000000001 :: Double > Hugs> (1.0 + 2.5e-15) + 2.5e-15 > 1.0 :: Double Prelude> (1e30 + (-1e30)) + 1 1.0 Prelude> 1e30 + ((-1e30) + 1) 0.0 I love this example from David Goldberg (http://docs.sun.com/source/806-3568/ncg_goldberg.html). -- Felipe. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe
Open this post in threaded view
|

Open this post in threaded view
|

Open this post in threaded view
|

Open this post in threaded view
|

Open this post in threaded view
|

 IOn Feb 11, 2008 9:46 AM, Miguel Mitrofanov <[hidden email]> wrote: > It's well known that "ListT m" monad violates this law in general > (though it satisfies it for some particular monads m). For example, I went through this example in quite a bit of detail a while ago and wrote it up here: http://sigfpe.blogspot.com/2006/11/why-isnt-listt-monad.html . I tried to show not just why the monad laws fails to hold for ListT [], but also show how it almost holds. -- Dan _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe
Open this post in threaded view
|

Open this post in threaded view
|

 In reply to this post by Andrew Butterfield Am Montag, 11. Februar 2008 16:35 schrieb Andrew Butterfield: > This is precisely Jerzy's point - you can have many mathematical laws as > you like but there is no guarantee that a programming languages > implementation will satisfy them. But people writing instances of type classes should take care of satisfying the laws since other libraries will most likely expect this. Best wishes, Wolfgang _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe
Open this post in threaded view
|

Open this post in threaded view
|

 In reply to this post by Wolfgang Jeltsch-2 On Feb 11, 2008 11:24 AM, Wolfgang Jeltsch <[hidden email]> wrote: >     a < b && b < c => a < c > > If an Ord instances doesn't obey these laws than it's likely to make Set and > Map behave strangely. Some months ago I pointed out that Ratio Int (which is an Ord instance) doesn't satisfy this property.  I provided a patch to fix the problem, but my bug report was closed as wontfix: http://hackage.haskell.org/trac/ghc/ticket/1517. -- I'm doing Science and I'm still alive. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe
Open this post in threaded view
|