[Haskell-cafe] How to spot Monads, Applicatives ...

[William Yager]

I often realize that something is a Monad or an Applicative or what have
you after I write out a helper function that I realize it has the same type
as >>= or <*> or whatever.

Monads must have the type * -> *. Otherwise you couldn't write out the
signatures for >>= and return (which both have "m a" in them).

To over-specify a bit, the type argument corresponds to what the monadic
action "returns". So an "m Int" returns an Int. Therefore, the "a" in
"State s a" certainly can't be fixed. It has to be whatever that particular
state action returns.

Let's pretend for a moment that it makes sense to have a non-fixed "s"
parameter.

For example, let's say we had

foo :: State S1 Int

bar :: Int -> State S2 String

OK, so we can't use

(>>=) :: m a -> (a -> m b) -> m b

Because we can't unify "m" with both "State S1" and "State S2". No problem,
let's write a new typeclass that has

(>>==) :: m s1 a -> (a -> m s2 b) -> m s2 b

Now, we can have

foo >>== bar :: State S2 String

However, how would you actually go about writing such a thing for the State
Monad? The S2 has to come from somewhere, and it's not clear to me here how
we're getting from an S1 to an S2. You could certainly embed such
transformations (e.g. by including a function of the type S1 -> S2), but
that would require an entirely different structure.

As for "effect" vs "side effect", I believe it's just that some people take
issue with the fact that "side effect" has the connotation of being
accidental. However, most academic materials on the subject do use "side
effect", presumably because there are other uses of the word "effect" (e.g.
"writing the code this way has the effect of simplifying...").

--Will

On Wed, Jun 15, 2016 at 8:54 AM, martin <martin.drautzburg at web.de> wrote:

> Hello all,
>
> I am at a stage, where I can use some of the Monads and Applicatives which
> are out there. But I hardly ever wrote my own
> instances. I am curious to learn about the thought processes which lead to
> the insight "hey that can be written nicely
> as an Applicative Functor"
>
> I suppose you can write everything without these type classes. Is it a
> promising approach to try without and then spot
> an element of repetition and factoring out that naturally leads to one of
> these typeclasses?
>
> Paticularly I am having difficulties with the *->* instances. E.g. why is
> the state "s" in the state monad the fixed
> type and the "a" the type parameter? When I am writing state code without
> the State monad the two look like equal
> candidates. Why not have "State a" monad, which threads an a-typed value
> and spits out states?
>
> While we're at it: would someone be so kind and explain what exactly is
> meant by an "effect"? I know that in haskell
> this is not the same as a "side effect" as there are no side-effects in
> haskell.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160615/2c9a81e2/attachment.html>