6 ms·

In my only significant Haskell codebase, I end up using the Monoid abstraction a lot. I don't want people who have to read the code to have to cope with the wor

by rspeer 10y ago

In my only significant Haskell codebase, I end up using the Monoid abstraction a lot. I don't want people who have to read the code to have to cope with the word "Monoid". Monoids are simple, but the name makes them sound like they're "like monads but worse because you haven't heard of them". I wanted to rename "Monoid" to "Joinable" in my code ("Concatenatable" is too long). But it turns out you can't alias a type class while maintaining compatibility with libraries that use it.

involans 10y ago
Ironically, [join](http://hackage.haskell.org/package/base-4.9.0.0/docs/Control-Monad.html#v:join http://hackage.haskell.org/package/base-4.9.0.0/docs/Control...) is a function on `Monad`, not `Monoid` - so `Joinable` wouldn't have been a great choice.
MustardTiger 10y ago
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!
- rspeer 10y ago
  People who know Haskell can cope with much more indirection than a type alias. Also, I don't know many people who really know Haskell anyway. 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.
  - MustardTiger 10y ago
    >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.
tome 10y ago
Sure you can: {-# LANGUAGE ConstraintKinds #-} import Data.Monoid type Joinable = Monoid something :: Joinable m => m -> m -> m something = (<>) But like MustardTiger says, don't.
nilkn 10y ago
I understand your motivation, but this is a really bad idea. If I didn't know Haskell and I saw "Joinable", I wouldn't know that that meant. "Concatenatable" seems like it might be clearer, and it is a little bit but not completely, because the concept of "concatenation" doesn't apply to all monoids. For instance, here's a (not particularly useful) monoid that has nothing to do with concatenation: newtype Sum a = Sum { getSum :: a } instance (Num a) => Monoid (Sum a) where mempty = Sum 0 mappend (Sum a) (Sum b) = Sum (a + b) Finally, and perhaps most importantly, I seriously doubt anybody reading your codebase is going to do so in complete isolation of the rest of the Haskell ecosystem. They are going to encounter the word "monoid", so you're not really doing them any favors by hiding it from them. You're just forcing them to jump through the mental hurdles of reconciling your wording with what's used everywhere else.
- Iceland_jack 10y ago
  It's funny you pick that example since of natural numbers can be viewed as lists (jargon: they are both free monoids) with addition as concatenation: type Natural = [()] zero, one, two, three, four :: Natural zero = [] one = [()] two = [(), ()] three = [(), (), ()] four = [(), (), (), ()] ... concatenation `(++) :: Natural -> Natural -> Natural`: >>> four [(), (), (), ()] >>> three ++ one [(), (), (), ()] Your point still holds. Our (non-jargon) vocabulary simply isn't equipped to deal with this level of abstraction so we need jargon if we intend to be fully descriptive — existing words don't cut it and we are just at the bottom rung of the abstraction ladder. It's up to us as a community how much we care about faithfully describing things, Simon Peyton Jones himself claims tongue-in-cheek that their biggest mistake was not calling monads “warm fuzzy things”[0] :) [0] http://research.microsoft.com/en-us/um/people/simonpj/papers/haskell-retrospective/HaskellRetrospective.pdf http://research.microsoft.com/en-us/um/people/simonpj/papers...

by rspeer 10y ago

involans 10y ago

Ironically, [join](http://hackage.haskell.org/package/base-4.9.0.0/docs/Control-Monad.html#v:join http://hackage.haskell.org/package/base-4.9.0.0/docs/Control...) is a function on `Monad`, not `Monoid` - so `Joinable` wouldn't have been a great choice.

MustardTiger 10y ago

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!

rspeer 10y ago
People who know Haskell can cope with much more indirection than a type alias. Also, I don't know many people who really know Haskell anyway. 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.
- MustardTiger 10y ago
  >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.

tome 10y ago

Sure you can: {-# LANGUAGE ConstraintKinds #-} import Data.Monoid type Joinable = Monoid something :: Joinable m => m -> m -> m something = (<>) But like MustardTiger says, don't.

nilkn 10y ago

I understand your motivation, but this is a really bad idea. If I didn't know Haskell and I saw "Joinable", I wouldn't know that that meant. "Concatenatable" seems like it might be clearer, and it is a little bit but not completely, because the concept of "concatenation" doesn't apply to all monoids. For instance, here's a (not particularly useful) monoid that has nothing to do with concatenation: newtype Sum a = Sum { getSum :: a } instance (Num a) => Monoid (Sum a) where mempty = Sum 0 mappend (Sum a) (Sum b) = Sum (a + b) Finally, and perhaps most importantly, I seriously doubt anybody reading your codebase is going to do so in complete isolation of the rest of the Haskell ecosystem. They are going to encounter the word "monoid", so you're not really doing them any favors by hiding it from them. You're just forcing them to jump through the mental hurdles of reconciling your wording with what's used everywhere else.

Iceland_jack 10y ago
It's funny you pick that example since of natural numbers can be viewed as lists (jargon: they are both free monoids) with addition as concatenation: type Natural = [()] zero, one, two, three, four :: Natural zero = [] one = [()] two = [(), ()] three = [(), (), ()] four = [(), (), (), ()] ... concatenation `(++) :: Natural -> Natural -> Natural`: >>> four [(), (), (), ()] >>> three ++ one [(), (), (), ()] Your point still holds. Our (non-jargon) vocabulary simply isn't equipped to deal with this level of abstraction so we need jargon if we intend to be fully descriptive — existing words don't cut it and we are just at the bottom rung of the abstraction ladder. It's up to us as a community how much we care about faithfully describing things, Simon Peyton Jones himself claims tongue-in-cheek that their biggest mistake was not calling monads “warm fuzzy things”[0] :) [0] http://research.microsoft.com/en-us/um/people/simonpj/papers/haskell-retrospective/HaskellRetrospective.pdf http://research.microsoft.com/en-us/um/people/simonpj/papers...