<div dir="ltr">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.<div><br></div><div>Monads must have the type * -> *. Otherwise you couldn't write out the signatures for >>= and return (which both have "m a" in them).</div><div><br></div><div>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.</div><div><br></div><div>Let's pretend for a moment that it makes sense to have a non-fixed "s" parameter.</div><div><br></div><div>For example, let's say we had</div><div><br></div><div>foo :: State S1 Int</div><div><br></div><div>bar :: Int -> State S2 String</div><div><br></div><div>OK, so we can't use </div><div><br></div><div>(>>=) :: m a -> (a -> m b) -> m b</div><div><br></div><div>Because we can't unify "m" with both "State S1" and "State S2". No problem, let's write a new typeclass that has</div><div><br></div><div>(>>==) :: m s1 a -> (a -> m s2 b) -> m s2 b</div><div><br></div><div>Now, we can have </div><div><br></div><div>foo >>== bar :: State S2 String</div><div><br></div><div>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.</div><div><br></div><div>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...").</div><div><br></div><div>--Will</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 15, 2016 at 8:54 AM, martin <span dir="ltr"><<a href="mailto:martin.drautzburg@web.de" target="_blank">martin.drautzburg@web.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello all,<br>
<br>
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<br>
instances. I am curious to learn about the thought processes which lead to the insight "hey that can be written nicely<br>
as an Applicative Functor"<br>
<br>
I suppose you can write everything without these type classes. Is it a promising approach to try without and then spot<br>
an element of repetition and factoring out that naturally leads to one of these typeclasses?<br>
<br>
Paticularly I am having difficulties with the *->* instances. E.g. why is the state "s" in the state monad the fixed<br>
type and the "a" the type parameter? When I am writing state code without the State monad the two look like equal<br>
candidates. Why not have "State a" monad, which threads an a-typed value and spits out states?<br>
<br>
While we're at it: would someone be so kind and explain what exactly is meant by an "effect"? I know that in haskell<br>
this is not the same as a "side effect" as there are no side-effects in haskell.<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div><br></div>