Monoid update

[MatthijsBlom]

Fix #49

I recommend reviewing the commits individually, in order.
As some changes' contexts are bigger than GitHub's UI suggests, consider reviewing locally.

[ulysses4ever]

Thanks! And sorry for a long wait.

I think it's mergeable although I'd make different choices sometimes.

First, reviewing commit-by-commit on GitHub is hard. While it is true that reading your changes commit-by-commit makes more sense (and thank you for suggesting it), commenting those changes is another story. Comments you leave under a certain commit (as opposed to in the overall "Files changed" tab of a PR) are second-class citizens in certain ways making them really hard to track. So, I'd much prefer you did the mappend-><> substitution in a separate PR (I know it may make little sense on its own).

Second, my main pain point here is in textual changes: sometimes it feels like the new text spells out "monoid and semigroup" where just "monoid" would suffice, and this makes it harder to read. For instance,

It's possible to make instances of Semigroup and Monoid that don't follow these rules,

I think it could do with just "instances of Monoid". Especially given that just above it does say talk only about Monoids ("Before moving on to specific instances of Monoid"), and that's the style I 'd prefer because every time use say something about monoids this usually implies things about semigroups and unless there's a vbery particular need for mentioning semigoroups, I'd prefer to just read about monoids as a whole. But I understand that it's a stylistic choice, so I don't want to argue about it...

On the other hand, where old text talks about code specifically, I feel, it should mention both instances instead of one. E.g.

Here's the Monoid instance:

instance Semigroup (DiffList a) where
    DiffList f <> DiffList g = DiffList (\xs -> f (g xs))
instance Monoid (DiffList a) where
    mempty = DiffList (\xs -> [] ++ xs)
    (DiffList f) `mappend` (DiffList g) = DiffList (\xs -> f (g xs))

This doesn't make sense: it says "here's one instance" and shows two. It must say that two instancces are coming.

[MatthijsBlom]

Good to know reviewing individual commits on here is that annoying.

So, I'd much prefer you did the mappend-><> substitution in a separate PR (I know it may make little sense on its own).

I have extracted the first two commits into #154.

---

But I understand that it's a stylistic choice, so I don't want to argue about it...

The main reason I chose to mention Semigroup so often was to provide the reader with extra exposure to this new concept. They have likely never encountered it before, and the semigroup concept is easily overshadowed by that of the monoid.
I agree it makes the text harder to read. It was a tradeoff. I'll go over the text again after posting this reply to see how I can improve the text's flow.

[MatthijsBlom]

I rebased onto #154. Hopefully that will improve the diff when that PR is merged.

Feel free to nitpick.
After everything is settled I plan to squash into sensible chunks.

[ulysses4ever]

Thanks! A tiny bit of ideas inline but it's already quite good!

[ulysses4ever]

Suggested change

	A semigroup is when you have an associative binary function, and a monoid is when you also have a value which acts as an identity with respect to that function.
	A semigroup is when you have an associative binary function, and a monoid is when you have a semigroup and a value that acts as an identity with respect to that function.

[ulysses4ever]

Having just "also" there doesn't pull the weight I feel. It's important to be crystal clear about this hierarchy.

[MatthijsBlom]

The "that function" reference feels broken, that way.

Maybe a total rewrite?

Suggested change

	A semigroup is when you have an associative binary function, and a monoid is when you also have a value which acts as an identity with respect to that function.
	When you have an associative binary function, we call that a semigroup.
	And if you also have a value that acts as an identity with respect to that function, then we call it a monoid instead.

( The 'instead' is there to make clear that it is the whole that is called the 'monoid', not just the identity element by itself. )

[ulysses4ever]

Suggested change

	There are a lot of other monoids and semigroups to be found in the world of Haskell, which is why the `Monoid` and `Semigroup` type classes exist.
	There are a lot of other monoids and semigroups to be found in the world of Haskell, which is why the respective type classes (`Semigroup` and `Monoid`) exist.

would read a little cleaner I feel.

[MatthijsBlom]

I would agree, if this weren't the first time these classes were named/mentioned.

[ulysses4ever]

The ordering in "monoids and semigroups" is a bit confusing, I feel, because semigroups come first in the sense that any monoid is a semigroup as well. But maybe it's not a big deal. Just in case, I add a suggestion but it's up to you whether to acccept it.

Suggested change

	It's for types which can act like monoids and semigroups.
	It's for types which can act like semigroups and monoids.

[MatthijsBlom]

I do not expect the reader's intuition to be clear on this yet, at this point in the text, so I do not expect a problem.

If these two words are to be swapped, I think the preceding two occurrences should be swapped as well, to preserve the 'rhythm'.

Currently the 'most important' of the two comes first, in these two sentences, somewhat in agreement with the title of this section.