3 ms·

What? The statement is true in reality, it is not true in haskell. Haskell does not provide a Monoid instance for Integer, you have to use Sum or Product. >T

What? The statement is true in reality, it is not true in haskell. Haskell does not provide a Monoid instance for Integer, you have to use Sum or Product. >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.

dragonwriter 10y ago
> The statement is true in reality, it is not true in haskell. 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.)
- deleted 10y ago
  [deleted]
- MustardTiger 10y ago
  >Integers are not monoids. As I stated in GP, the combination (Integer, +, 0) defines a monoid 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.

dragonwriter 10y ago

> The statement is true in reality, it is not true in haskell. 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.)

deleted 10y ago
[deleted]
MustardTiger 10y ago
>Integers are not monoids. As I stated in GP, the combination (Integer, +, 0) defines a monoid 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.