On 2016-06-15 11:54 AM, martin wrote:

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?

You mean like this? newtype MyState a s = Mk {unMk :: a -> (s, a)} thread_a_and_spit_out_s :: MyState a s -> a -> s thread_a_and_spit_out_s (Mk h) a = case h a of (s, _) -> s instance Monad (MyState a) where -- return :: s -> MyState a s return s = Mk (\a -> (s, a)) -- (>>=) :: MyState a s -> (s -> MyState a t) -> MyState a t Mk h >>= k = Mk (\a0 -> case h a0 of (s, a1) -> unMk (k s) a1) instance Functor (MyState a) where -- fmap :: (s -> t) -> MyState a s -> MyState a t fmap f (Mk h) = Mk (\a0 -> case (h a0) of (s, a1) -> (f s, a1)) instance Applicative (MyState a) where pure = return mf <*> mx = mf >>= \f -> mx >>= \x -> return (f x)

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.

It is just a change of attitude. I say "effect" when it is a purpose of my program, in fact likely a main purpose. I say "side effect" when it is not a purpose of my program. But since I write programs by intelligent design rather than by evolution, of course everything my program does is on purpose. The name "side effect" was coined when people had dispute over whether "function" should mean inert mathematical function or interactive computational procedure.

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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe