On Thu, 2 Oct 2003 08:08:16 -0400
Derek Elkins
The Count monad with return defined as Count 0 a with >>= adding them is an instance of the Writer/Output monad. Using 1 and addition isn't. It's also a potentially useful monad. I've seen the equivalent called the Complexity monad before.
Interesting.
This isn't state, this is, again, a (broken) instance of the Writer/Output monad. The return should use the empty list and your >>= doesn't even make sense.
Excuse me, but from my perspective is not a broken instance of Writer/Output because it didn't try to be an instance of anything... :) And I wasn't interested in making >>= "make sense" (I've said already that I don't think Counted or Accum where useful monads-to-be, just toys to help me learn Haskell) in any sense, *other than* the fact that they satisfy *or* not satisfy the 1st. monadic law. That's what I was trying to know. Even if my >>= is meaningless, mathematical- or computer science-wise, the question I asked is: Could I define >>= so, and == so, and the resulting type would satisfy 1st law?
m1 = (return 'a') >>= dupAcc -- Ac "aaa" 'a' m2 = dupAcc 'a' -- Ac "aa" 'a'
Which shows that your monad is broken. As Markus mentions, -you- have to make sure the monad laws hold, they don't come for free. If they don't hold, you don't have a monad.
Yeah. That's why I'm asking the limits of "hold". Observable behaviour, as Alastair said, is a nice explanation.
In fact, I believe the monad laws together effectively state that both >>= and return are "pure" with respect to whatever computation is being modelled. So the associativity condition says that it doesn't matter which >>= is evaluated first.
Yes. But if I do have a return function which turns on/off a LED outside my computer, and the state of this LED is irrelevant to my computation, is that "return" pure or not? :)
Another thing that should be noted, is that most monads are completely useless without "primitive" computations. [snip] So again, with Accum, you need a "primitive" computation that actually is effectful while return and >>= aren't
In Counted, reverseCounted did a "useful" (for some ad hoc definition of "useful") computation: it turned a list into a reverse list inside the monad. Unless I'm misunderstading my own examples, that is.
A more profound kind, as it usually isn't possible to define a reasonable instance of Eq for monads.
Which resolves into Alastair's definition.
Anyways, these laws are the ones from the Category Theory definition of monads (slightly restructured), obviously they aren't talking about Haskell's Eq or even computable equality in general.
Well, yeah, but this is Haskell and not Category Theory. If an instance of Monad satisfies a weaker 1st law that a mathematical monad should, but it is still useful and "acts like a Monad", I don't see the problem. Anyway, I think that I know understand what's "expected" from a Monad instance. Thanks for your comments (and everyone else's, of course). Juanma