<story><title>Haskell Concepts in One Sentence</title><url>https://torchhound.github.io/posts/haskellOneSentence.html</url></story><parent_chain><item><author>oblio</author><text>I&amp;#x27;m still kind of having problems with monads. Funnily enough, I recently found an article explaining what monoids are: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;fsharpforfunandprofit.com&amp;#x2F;posts&amp;#x2F;monoids-without-tears&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;fsharpforfunandprofit.com&amp;#x2F;posts&amp;#x2F;monoids-without-tear...&lt;/a&gt;&lt;p&gt;&lt;pre&gt;&lt;code&gt;    You start with a bunch of things, and some way of combining them two at a time.

    Rule 1 (Closure): The result of combining two things is always another one of the things.

    Rule 2 (Associativity): When combining more than two things, which pairwise combination you do first doesn&amp;#x27;t matter.

    Rule 3 (Identity element): There is a special thing called &amp;quot;zero&amp;quot; such that when you combine any thing with &amp;quot;zero&amp;quot; you get the original thing back.


    With these rules in place, we can come back to the definition of a monoid. A &amp;quot;monoid&amp;quot; is just a system that obeys all three rules. Simple!
&lt;/code&gt;&lt;/pre&gt;
Long explanation overall in the article, but based on 6th grade math. I understood it, and it stuck. Could someone extend the monad explanation from here? Maybe I&amp;#x27;ll finally get it :)</text></item></parent_chain><comment><author>dmit</author><text>This was way more difficult than I thought and still doesn&amp;#x27;t look right. But at least I get to strike &lt;i&gt;write a monad tutorial&lt;/i&gt; off of the bucket list.&lt;p&gt;&lt;pre&gt;&lt;code&gt;  You start with a bunch of transformations that either turn a thing into a (different) *useful* thing or into a *dead end*.
  
  Rule 1 (Left Identity): Applying a transformation to a useful thing is the same as simply transforming a plain thing.
  
  Rule 2 (Right Identity): A transformation that merely makes a thing useful has no effect when applied. Useful things stay the same, dead ends stay dead.
  
  Rule 3 (Associativity): You can merge any two transformations into one, which behaves the same as if you applied the first transformation to something and then applied the second transformation to the result.&lt;/code&gt;&lt;/pre&gt;</text></comment>
<story><title>Haskell Concepts in One Sentence</title><url>https://torchhound.github.io/posts/haskellOneSentence.html</url></story><parent_chain><item><author>oblio</author><text>I&amp;#x27;m still kind of having problems with monads. Funnily enough, I recently found an article explaining what monoids are: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;fsharpforfunandprofit.com&amp;#x2F;posts&amp;#x2F;monoids-without-tears&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;fsharpforfunandprofit.com&amp;#x2F;posts&amp;#x2F;monoids-without-tear...&lt;/a&gt;&lt;p&gt;&lt;pre&gt;&lt;code&gt;    You start with a bunch of things, and some way of combining them two at a time.

    Rule 1 (Closure): The result of combining two things is always another one of the things.

    Rule 2 (Associativity): When combining more than two things, which pairwise combination you do first doesn&amp;#x27;t matter.

    Rule 3 (Identity element): There is a special thing called &amp;quot;zero&amp;quot; such that when you combine any thing with &amp;quot;zero&amp;quot; you get the original thing back.


    With these rules in place, we can come back to the definition of a monoid. A &amp;quot;monoid&amp;quot; is just a system that obeys all three rules. Simple!
&lt;/code&gt;&lt;/pre&gt;
Long explanation overall in the article, but based on 6th grade math. I understood it, and it stuck. Could someone extend the monad explanation from here? Maybe I&amp;#x27;ll finally get it :)</text></item></parent_chain><comment><author>cynicalkane</author><text>Start with a functor--a parameterized type with fmap. Maybe t, Either e t, [t], IO t, State s t, and so on.&lt;p&gt;Consider a monad m and a function, a -&amp;gt; m b. Frequently you want to feed another monadic value, m a, into that function.&lt;p&gt;A monad gives you a function, &amp;gt;&amp;gt;=, that lets you take m a and feed it into a -&amp;gt; m b.&lt;p&gt;So any function that does IO, that looks like a -&amp;gt; IO b, you can take an IO a and plug it into a -&amp;gt; IO b. Any function that manipulates a state, you can take State a and plug it into a -&amp;gt; State b. This is the heart of a monad: gluing monadic functions together.&lt;p&gt;The meaning of &amp;gt;&amp;gt;= depends on the monad you&amp;#x27;re in. You also need return :: a -&amp;gt; m a, which can take a thing and put it in a monadic value.&lt;p&gt;There are monad laws also. A lot of times there&amp;#x27;s several ways to manipulate monads to do something, and the laws are needed to make sure they&amp;#x27;re all equivalent. For everyday monad use the laws aren&amp;#x27;t terribly important to remember, and GHC&amp;#x27;s linter will helpfully point out when you can use them.&lt;p&gt;That&amp;#x27;s my attempt at a short explanation. The &amp;quot;monad tutorial problem&amp;quot; has been weighing on my mind. The only way I ever understood monads was by reading and rereading the definition and examples. Tutorials never taught me anything.</text></comment>