5 ms·

>People who know Haskell can cope with much more indirection than a type alias. People can cope with all kinds of bad things, regardless of whether or not they

>People who know Haskell can cope with much more indirection than a type alias. 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.

rspeer 10y ago
So the name `mappend` is "completely wrong" in your opinion? 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.
- MustardTiger 10y ago
  >So the name `mappend` is "completely wrong" in your opinion? 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.
dragonwriter 10y ago
> Integers are monoids. 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.
- MustardTiger 10y ago
  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.

rspeer 10y ago

So the name `mappend` is "completely wrong" in your opinion? 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.

MustardTiger 10y ago
>So the name `mappend` is "completely wrong" in your opinion? 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.

dragonwriter 10y ago

> Integers are monoids. 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.

MustardTiger 10y ago
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.