And now you would helpfully give everyone reading your code either a huge pain if they know haskell, or a completely wrong impression of what that class actually is if they don't. Great!
Do tell me more about how "concatenatable" is a "completely wrong" impression of what Monoids are for. I know you can use them to, like, multiply using abstract nonsense, but that's not why you care what a Monoid is. Monoids let you generalize `mappend` over many kinds of sequences.
People can cope with all kinds of bad things, regardless of whether or not they know haskell. That is not an argument in favor of bad things.
>I know you can use them to, like, multiply using abstract nonsense
What? There's nothing "abstract nonsense" about it. Integers are monoids. Things that can be appended is a subset of monoids, not a description of them.
It's such a Haskelly response to say that I am not allowed to use a concept for what it was designed for, unless I use it in its full generality.
No, it is partially wrong, as I said. Appending describes a subset of monoids, not monoids.
>It's such a Haskelly response to say that I am not allowed to use a concept for what it was designed for
What on earth are you talking about? I am not a haskell person and I said nothing even remotely resembling that.
I think that one bad habit that Haskell promotes is statements of this form, which are true in Haskell because of the way Haskell forces you to define typeclasses, but aren't really "true" of the concepts modeled by typeclasses. (Integer, +, 0) defines a monoid, as does (Integer, ×, 1).
> Things that can be appended is a subset of monoids, not a description of them.
The key operation that defines a monoid is the append operation ("mappend" in the definition of the Haskell typeclass Monoid, to avoid collision with the list-specific "append" operation), which for the monoid of integers over addition is (as the name suggests) addition.
>The key operation that defines a monoid is the append operation
No, it is the sole monoid operation. It is named mappend in haskell, but that does not make everything it encompasses into appending. Ask someone what operations can be done on "appendables" and you will get lots of answers like looping, sizeof, etc. Append always refers to collections in other languages, so the argument that it would help people to call something different "appendable" for those people is silly.
No, the specific statement is true neither in reality nor in Haskell, though statements of that form (which is what I said) are often true in Haskell (e.g., List is a Monad) though not reality.
Integers are not monoids. As I stated in GP, the combination (Integer, +, 0) defines a monoid -- as does (Integer, ×, 1); there's other monoids one could define on Integers, though those are the two most obvious and useful ones. Haskell, because its designed to make statements of the form type is a typeclass has to do one of two things to support the case where multiple useful instances of a typeclass can be defined involving a particular type -- one is the newtype wrapper approach used for Sum and Product with numeric types as monoids, with the base type participating in none of the instances; the other is to choose a primary instance that the base type participates in, and relegate the others to the newtype treatment (this is what is done with lists as monads in Haskell).
Both of these approaches are workarounds for the problem that typeclass instances aren't naturally defined by a participating type alone, but by the combination of a participating type, and one or more other values (some of which are usually functions.)
This is simply being pedantic. We're all well aware of the meaning of what I said, as it is how it is almost always said.
>Both of these approaches are workarounds for the problem that typeclass instances
That's not a problem, it is the point. That is what typeclasses were intended to be.