Newbie qustion about monads

[Juanma Barranquero]

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