5 ms·

I'm really not feeling the music with these, if you know what I mean, which is a shame since it seems as though great lengths have been gone to to make it under

I'm really not feeling the music with these, if you know what I mean, which is a shame since it seems as though great lengths have been gone to to make it understandable. Are there other works you can recommend to learn more from?

jamesaguilar 13y ago
Agreed. The writer example was really telling. The whole syntax around using the function changes when you bring the monad into it. Even the placement of the function calls and the data.
- wvs 13y ago
  "half 8 >>= half" might look a lot different from "half . half $ 8", but they're actually identical in underlying structure! The monad version is just using the wrong operator for visual comparison. (.) composes two functions[1] but (>>=) composes a monad value with a monad function[2]. It'd be nice if we had an operator to compose two monad functions instead. We can define that operator in terms of (>>=): "g <=< f = \x -> f x >>= g". You can check that the types work out[3]. Notice the great similarity to (.). (It's because they're both categorical composition operators of functions.) Now we can write "half <=< half $ 8" and everything's dandy. [1]: (.) :: (b -> c) -> (a -> b) -> (a -> c) [2]: (>>=) :: m a -> (a -> m b) -> m b [3]: (<=<) :: (b -> m c) -> (a -> m b) -> (a -> m c)
  - jamesaguilar 13y ago
    This is impressive, but it does not make me want to try Haskell more.
    - wvs 13y ago
      Ahaha, I agree. Abstract monad derivations are quite a foreboding introduction.
  - tome 13y ago
    Absolutely right! (And you preempted my comment at the top level). I think one reason for "monad hell" is unawareness about this kind of composable style.
- deleted 13y ago
  [deleted]
gosub 13y ago
If you already know about high order functions and a bit of haskell notation, I suggest chapters 11 and 12 from "Learn You a Haskell for Great Good!" [1]. I think that following the explanation from Functors -> Applicative Functors -> Monoids -> Monads makes it easier to understand where monads come from and what problem they are trying to solve. [1] http://learnyouahaskell.com/chapters http://learnyouahaskell.com/chapters
- exDM69 13y ago
  There are different kinds of people, some might learn by going the theoretical path you described (functors -> monoids -> monads). I am not one of these people. I learn theory by doing thing in practice. I recommend starting out with IO and "learning monads" as you go. Too many people think they must "understand" monads first, but this might not be the right way to go depending on the person. "Guess the number" and other examples from Imperative programming 101 make great exercises.
deleted 13y ago
[deleted]
yummyfajitas 13y ago
I wrote one you might find helpful. It explains monads via a helpful real world analogy. http://www.chrisstucchio.com/blog/2013/write_some_fucking_code.html http://www.chrisstucchio.com/blog/2013/write_some_fucking_co...
egonschiele 13y ago
Post author here. If you tell me where you're stumbling, I might be able to fix it. You could also check out this post by sigfpe, one of my favorite posts on monads: http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...

jamesaguilar 13y ago

Agreed. The writer example was really telling. The whole syntax around using the function changes when you bring the monad into it. Even the placement of the function calls and the data.

wvs 13y ago
"half 8 >>= half" might look a lot different from "half . half $ 8", but they're actually identical in underlying structure! The monad version is just using the wrong operator for visual comparison. (.) composes two functions[1] but (>>=) composes a monad value with a monad function[2]. It'd be nice if we had an operator to compose two monad functions instead. We can define that operator in terms of (>>=): "g <=< f = \x -> f x >>= g". You can check that the types work out[3]. Notice the great similarity to (.). (It's because they're both categorical composition operators of functions.) Now we can write "half <=< half $ 8" and everything's dandy. [1]: (.) :: (b -> c) -> (a -> b) -> (a -> c) [2]: (>>=) :: m a -> (a -> m b) -> m b [3]: (<=<) :: (b -> m c) -> (a -> m b) -> (a -> m c)
- jamesaguilar 13y ago
  This is impressive, but it does not make me want to try Haskell more.
  - wvs 13y ago
    Ahaha, I agree. Abstract monad derivations are quite a foreboding introduction.
- tome 13y ago
  Absolutely right! (And you preempted my comment at the top level). I think one reason for "monad hell" is unawareness about this kind of composable style.
deleted 13y ago
[deleted]

gosub 13y ago

If you already know about high order functions and a bit of haskell notation, I suggest chapters 11 and 12 from "Learn You a Haskell for Great Good!" [1]. I think that following the explanation from Functors -> Applicative Functors -> Monoids -> Monads makes it easier to understand where monads come from and what problem they are trying to solve. [1] http://learnyouahaskell.com/chapters http://learnyouahaskell.com/chapters

exDM69 13y ago
There are different kinds of people, some might learn by going the theoretical path you described (functors -> monoids -> monads). I am not one of these people. I learn theory by doing thing in practice. I recommend starting out with IO and "learning monads" as you go. Too many people think they must "understand" monads first, but this might not be the right way to go depending on the person. "Guess the number" and other examples from Imperative programming 101 make great exercises.

deleted 13y ago

[deleted]

yummyfajitas 13y ago

I wrote one you might find helpful. It explains monads via a helpful real world analogy. http://www.chrisstucchio.com/blog/2013/write_some_fucking_code.html http://www.chrisstucchio.com/blog/2013/write_some_fucking_co...

egonschiele 13y ago

Post author here. If you tell me where you're stumbling, I might be able to fix it. You could also check out this post by sigfpe, one of my favorite posts on monads: http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...