Arguably then, anything which is an instance of Monad should be a monad.
I would certainly argue strongly for that.
If it ain't true, then small, irrelevant changes in a piece of code could break. For example, is it safe to make this change:
do f y ==> do x <- f y return x
I'd hope it would be. (And the change might be useful if I want to insert a check or a debugging printf in the code.)
I'm afraid it isn't true that all instances of Monad respect the monad laws, due to our old friend seq. See: http://www.haskell.org/pipermail/haskell/2002-May/009622.html I don't want this discussion to get out of hand. The only point I'm making here is that the Haskell definition doesn't *require* that every instance of (==) be equality, in the same way that it doesn't *require* that all Monad instances are monads, and all '+'s are additions etc. Libraries might rely on properties of these methods, but as far as is practical those assumptions should be documented. Cheers, Simon
Am Freitag, 26. März 2004 16:37 schrieb Simon Marlow:
[...]
I'm afraid it isn't true that all instances of Monad respect the monad laws, due to our old friend seq. See:
http://www.haskell.org/pipermail/haskell/2002-May/009622.html
By the way, is there some effort in restricting seq in order to resolve this problem?
I don't want this discussion to get out of hand.
Me, too. ;-)
The only point I'm making here is that the Haskell definition doesn't *require* that every instance of (==) be equality, in the same way that it doesn't *require* that all Monad instances are monads, and all '+'s are additions etc.
Hmm, than we have a different interpretation of the standard as far as (==) is concerned. Well, concerning Monad you're probably right because the Report only says "should" satisfy instead of "shall" satisfy or whatever. As far as I could see the Report says nothing about the meaning of (+).
Libraries might rely on properties of these methods, but as far as is practical those assumptions should be documented.
The problem is that probably a lot of libraries make assumptions like adherance to the Monad laws so that it's maybe difficult to document all these assumptions.
Cheers, Simon
Sorry, if I was a bit dissentious. Wolfgang
On Fri, 26 Mar 2004, Wolfgang Jeltsch wrote:
Hmm, than we have a different interpretation of the standard as far as (==) is concerned. Well, concerning Monad you're probably right because the Report only says "should" satisfy instead of "shall" satisfy or whatever. As far as I could see the Report says nothing about the meaning of (+).
Well, the next version of Haskell with Design by Contract will of course formally specify all those laws, so I won't be forced any more to pay attention to the difference between "shall" and "should". The sense of the latter being surely questionable, since a law that doesn't always hold, is not a law, but a hidden bug. It may seem a bit late that FP now gets, what has been into imperative practice in 1985. (Bibliography on http://www.stud.tu-ilmenau.de/~robertw/eiffel ) Robert
On Fri, Apr 02, 2004 at 10:39:19AM +0200, Robert Will wrote:
On Fri, 26 Mar 2004, Wolfgang Jeltsch wrote:
Hmm, than we have a different interpretation of the standard as far as (==) is concerned. Well, concerning Monad you're probably right because the Report only says "should" satisfy instead of "shall" satisfy or whatever. As far as I could see the Report says nothing about the meaning of (+).
Well, the next version of Haskell with Design by Contract will of course formally specify all those laws, so I won't be forced any more to pay attention to the difference between "shall" and "should". The sense of the latter being surely questionable, since a law that doesn't always hold, is not a law, but a hidden bug.
It may seem a bit late that FP now gets, what has been into imperative practice in 1985. (Bibliography on http://www.stud.tu-ilmenau.de/~robertw/eiffel )
I know of at least a few cases where formal laws do not actually hold. * Associativity of floating-point addition (etc.) This does cause problems in practice, as any numerical analyst will tell you. * A monad provided with a random number generator, which you could think of as an infinite list of Int's. The associativity law does not hold: each computation will get its own random bits, but they will be different random bits depending on which way you associate. I'm sure there are other useful examples where formal laws do not quite hold. Peace, Dylan
participants (4)
-
dpt＠lotus.bostoncoop.net -
Robert Will -
Simon Marlow -
Wolfgang Jeltsch