Newbie qustion about monads
Juanma Barranquero
jmbarranquero at laley.wke.es
Thu Oct 2 16:01:54 EDT 2003
On Thu, 2 Oct 2003 08:08:16 -0400
Derek Elkins <ddarius at hotpop.com> wrote:
> 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
More information about the Haskell-Cafe
mailing list