The concept is called parametricity: I can figure out what functions don’t do by looking at the types, I don’t have to read the implementation. I use this every day at work.

A better signature for sum is:

sum :: (Foldable f, Monoid a) ⇒ f a → a

Which limits things a lot more, to the level where I can know the possible implementations. I know that sum can’t just do a “plus one” because Monoid doesn’t have the concept of “one” - I also know the result can only be:

That signature isn’t sum, that’s fold from Data.Foldable. It doesn’t say anything about the contents being addable.

I go back and forth on whether Addable or AbelianGroup would be a better name for the typeclass. But to answer the post’s question as to why it’s not Magma: magma doesn’t include commutativity.

Yes, having AbelianMonoid would be better, there’d be even fewer implementations. AbelianGroup is too far for sum; we don’t need to talk about negating.

I’m not a mathematician, but from what I understand they don’t really have a concept of “zero” either, but rather “identity” and an associative binary operator. In the example @puffnfresh gave, for sum it would be 0 and (+). For product it’d be 1 and (*). And for set it’d be {} and union. And lots of other combinations.

The answer is that you don’t know anything about the monoid operation other than that it is (1) closed, (2) associative and (3) has an identity. In particular the usual operations of addition and multiplication over either the integers or certain subsets define monoids. Given a set S and an operation x and the monoid properties, you have no way of knowing anything else. For example, one really important (for CS ) monoid is the free monoid of strings over some set called an alphabet. In this case the operation is “append” and there is no fixed relationship to numbers at all. The original post is, as far as I can tell, satirizing the concept of replacing basic arithmetic in a programming language with more generic and less structured algebraic concepts.

This proposal brings the straightforward clarity of Monad to arithmetic, an area where Haskell has long suffered from comprehensibility bordering on practicality.

I’m a programmer at Atlassian, not a mathematician. The following makes sense to me:

And looks useful; from the type signature, I know that sum isn’t going to use multiplication, only addition.

How is that useful?

The concept is called parametricity: I can figure out what functions don’t do by looking at the types, I don’t have to read the implementation. I use this every day at work.

A better signature for sum is:

Which limits things a lot more, to the level where I can know the possible implementations. I know that sum can’t just do a “plus one” because Monoid doesn’t have the concept of “one” - I also know the result can only be:

`f a`

argumentThere is nothing else.

That signature isn’t

`sum`

, that’s`fold`

from`Data.Foldable`

. It doesn’t say anything about the contents being addable.I go back and forth on whether

`Addable`

or`AbelianGroup`

would be a better name for the typeclass. But to answer the post’s question as to why it’s not`Magma`

: magma doesn’t include commutativity.Yes, having AbelianMonoid would be better, there’d be even fewer implementations. AbelianGroup is too far for sum; we don’t need to talk about negating.

Monoids don’t have the concept of 1 ? Fascinating.

I’m not a mathematician, but from what I understand they don’t really have a concept of “zero” either, but rather “identity” and an associative binary operator. In the example @puffnfresh gave, for sum it would be

`0`

and`(+)`

. For product it’d be`1`

and`(*)`

. And for set it’d be`{}`

and`union`

. And lots of other combinations.The answer is that you don’t know anything about the monoid operation other than that it is (1) closed, (2) associative and (3) has an identity. In particular the usual operations of addition and multiplication over either the integers or certain subsets define monoids. Given a set S and an operation x and the monoid properties, you have no way of knowing anything else. For example, one really important (for CS ) monoid is the free monoid of strings over some set called an alphabet. In this case the operation is “append” and there is no fixed relationship to numbers at all. The original post is, as far as I can tell, satirizing the concept of replacing basic arithmetic in a programming language with more generic and less structured algebraic concepts.

will wonders never cease?

Well, that’s a relief.

The troll rating confirms that some people took the original positing seriously. Wow.