My take on why monoids seem to be thought of as concatenation in the Haskell community is that the other simple examples run into some difficulty with the way the type class system is set up. Specifically, the example you used requires a newtype wrapper, because the nats (ints really, we don't use nats much) are a monoid under both addition and multiplication. We don't have any better way of dealing with multiple instances, so we create a Sum newtype and a Product newtype. This adds enough friction that those instances seem to not get used all that much. Other examples of this are the Boolean monoid under conjunction or disjunction, and the monoid of endomorphisms under composition. Those instances all exist, but I rarely (if ever) see them used.

There are definitely some more general uses of the Monoid type class than concatenation that don't require newtypes, but they are slightly harder to understand, so they don't tend to get trotted out as examples. The best example I can think of is Ordering (LT | EQ | GT), which is a monoid in the sense of lexicographical ordering. You also have Function (a -> b) and Maybe b, which are each monoids when b is a monoid, but if b is a monoid under concatenation then those just look like concatenation too.

One other reason I think they're thought of as concatenation is that monoids under concatenation are extremely useful. The most common case is when appending things that are like strings. Strings are not performant, so for anything significant you want to use Text or ByteString. However, it's not uncommon to use Strings when you're first figuring things out. If you want to then switch over to Text and you used String appending (++), you'll have to find and replace every instance of that. If you instead used Monoid appending (<>), you can switch the types and everything will still work. Quite nice.

Haskellers just call them Monoid and happily include anything that's associative+identity. When talking to people not yet familiar with Haskell or abstract algebra, it's commonly a good idea to simplify the notion and call Monoid the same as concatenation. That's all.

    newtype Sum = Sum { getSum :: Int }
    instance Monoid Sum where
      mempty = Sum 0
      mappend (Sum a) (Sum b) = Sum (a + b)

I most definitely don't! :-)

I was trying to simplify to get a cross the point that the Haskell ecosystem contains small and very well factored abstractions, without busting out the mathjax and technical terms. I find the key understanding of Monoids (which lets me use them and gives me a useful intuition upon seeing one) to be "Oh this is just combining these things together" - which I explain to newcomers as "basically concatenation".

It's always hard to pick the correct amount of correctness to use :-)

Probably too late for you to see this, but free objects are very common in Haskell-land. And free monoids are basically concatenation. But you'll see all kind of monoids :)

Appending things is used as an example a lot of the time so people sort of get it into their heads that monoid = concatenation, which is obviously not true. I can't speak as to which monoids get used the most in Haskell but I have personally used it for appending string-like things, and also to unify data structures (combine the stuff in them basically). There is actually a library that will derive a Monoid instance for you if all of the types you're using are already instances.

http://hackage.haskell.org/package/generic-deriving-1.6.2/do...

yes, thats a commutative monoid. Thinking of a monoid as "concatenation" is much more general concept that includes that one

> A monoid could also be the natural numbers combined with addition for example.

Then you can think of it as concatenating two unary numbers.

I don't refactor with fear in my Rails apps since they have pretty good test coverage. I'm not saying it's perfect, but I've never had slow development because I wanted to refactor in this context.

What does this mean? I don't think most Haskell users spend a lot of time debugging the type system.