> observably different from `undefined` If we understand `undefined` as meaning a computation that never ends, then you cannot ever observe whether one `undefined` is or is not equivalent to another. In strict languages, this is especially obvious.
In any case, I don't accept a concept of `monads` that changes so drastically based upon the host language. The laws for monads only apply to actual values and combinators of the monad algebra - and, since `undefined` is not a value, it need not apply. Similarly, algebraic laws for integer arithmetic don't need to account for `undefined`. And our geometry abstractions and theorems don't need to account for `undefined`. Attempting to shoehorn `undefined` into your reasoning about domain algebras and models and monads is simply a mistake. Regards, Dave On Sun, Jan 22, 2012 at 6:49 AM, Sebastian Fischer <fisc...@nii.ac.jp>wrote: > On Sat, Jan 21, 2012 at 8:09 PM, David Barbour <dmbarb...@gmail.com> > wrote: > > In any case, I think the monad identity concept messed up. The property: > > return x >>= f = f x > > > > Logically only has meaning when `=` applies to values in the domain. > > `undefined` is not a value in the domain. > > > > We can define monads - which meet monad laws - even in strict languages. > > In strict languages both `return undefined >>= f` and `f undefined` > are observably equivalent to `undefined` so the law holds. > > In a lazy language both sides might be observably different from > `undefined` but need to be consistently so. The point of equational > laws is that one can replace one side with the other without observing > a difference. Your implementation of `StrictT` violates this > principle. > > Sebastian >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
