9 ms·

They saved the best for last: 3.5 Naming Conventions Some names are inconsistent. For example Functor is not called Mappable while Traversable is not named

They saved the best for last: 3.5 Naming Conventions Some names are inconsistent. For example Functor is not called Mappable while Traversable is not named after abstract nonsense. It is best to focus on what things are instead of what they are called.

wz1000 10y ago
I don't really agree with the example that was chosen. "Functor" is a well defined term with a specific meaning. A much better example would be "Show"(Showable) vs "Traversable".
- tempodox 10y ago
  Nope. In OCaml, “Functor” is a well-defined term with a completely different meaning. Or go look what “Functor” means in Prolog. Well defined, completely different. If you really want to mess things up, use names that mean something different every day. But I would know what a “Mappable” should be, regardless of PL.
  - wz1000 10y ago
    https://en.wikipedia.org/wiki/Functor https://en.wikipedia.org/wiki/Functor
    - awj 10y ago
      ...you're kind of helping the "don't use Functor" argument here. Most programmers are programmers first and mathematicians second, if at all. Reusing terms from math that have been overloaded in programming domains is definitely going to create a scenario where many (most?) users don't correctly understand the terms you're using.
      - wz1000 10y ago
        A Functor is a fundamental category-theoretical term with a specific definition that simply isn't captured by something vague like "Mappable". Precision is important when talking about such terms. It is not at all clear that (-> a) is "Mappable". Lots of terms like Profunctor, Contravariant Functor, Bifunctor etc. (which are also the names of typecasses in Haskell) rely on the precise, category-theoretical definition of Functor.
  - MustardTiger 10y ago
    >In OCaml, “Functor” is a well-defined term with a completely different meaning No, it has the same meaning. It does not behave identically because the languages do not have identical designs. >But I would know what a “Mappable” should be, regardless of PL. Lots of people wouldn't, and would be wondering what cartography has to do with anything. And even for people familiar with the functional "map", now they would just have an incorrect idea of what Functor is. Lots of Functors are things most people would not think of as being "Mappable".
    - more_original 10y ago
      > >In OCaml, “Functor” is a well-defined term with a completely different meaning > No, it has the same meaning. It does not behave identically because the languages do not have identical designs. Functors in Haskell and OCaml are different things. Haskell Functors correspond to the category-theoretic notion of a functor (a thing mapping objects to objects and morphisms to morphisms in a reasonable manner). In OCaml and ML, Functors represent parameterized modules. These are not known to correspond to category-theoretic functors in any reasonable way (and there have been proposals for category-theoretic models of the ML module system). I guess the term Functor is a bit of a misnomer in the ML-like languages.
      - MustardTiger 10y ago
        >In OCaml and ML, Functors represent parameterized modules No, functors represent functions from a module to a module. Oh hey, that sounds just like the standard definition of a functor. As I said, the behavior is different because the languages are different, but both are named after the category theory functor, because they both emulate it.
        more_original 10y ago
        Please read up on the ML module system and its origins. http://cs.stackexchange.com/questions/9769/what-is-the-relation-between-functors-in-sml-and-category-theory http://cs.stackexchange.com/questions/9769/what-is-the-relat... Functors play very different roles in Haskell and OCaml/ML. In Haskell, the Functor class is there to implement the functoriality of a type. If F is a functor, then one implements maps of type F A -> F B from given A -> B in a functorial way. In ML, the term functor was chosen because they are not first-class functions, but "a level up" (much like a functor is a level up from the maps in the category that it operates on). However, if F is an ML functor, then there are no "maps" between the modules F(A) and F(B). The morphism part, which is the essence of a Functor in Haskell, is missing in ML. This is why I think that the functor terminology isn't very good in ML. Not everything that maps one thing to another is a functor.
posterboy 10y ago
only two problems in computer science and naming things is one of them
- zeendo 10y ago
  There are plenty of problems, but only two hard problems. Actually, I think there are three hard problems in CS. The third being pedants.
  - chriswarbo 10y ago
    The two hard problems are cache invalidation and naming things. The third is off-by-one errors.
    - 0xmohit 10y ago
      Perhaps one more: guaranteed once-only delivery.
      - tome 10y ago
        Perhaps one more: guaranteed once-only delivery.
  - deleted 10y ago
    [deleted]
posterboy 10y ago
> abstract nonsense this would get downvoted quickly if it was a comment
- Y_Y 10y ago
  https://en.wikipedia.org/wiki/Abstract_nonsense https://en.wikipedia.org/wiki/Abstract_nonsense
- tempodox 10y ago
  Then let's thank the holy quantum noise that it isn't. The holier-than-thou PL fanatics here are really insufferable.
  - wyager 10y ago
    The term sees wide (humorous) use in the Haskell community.
- mcguire 10y ago
  It's a technical term.
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.
pklausler 10y ago
Typeclass names could be made redundant in Haskell. If one could state a constraint in terms of a typeclass member, things would be more simple. E.g., "classOf fmap" as a synonym for Functor.
- taylorfausak 10y ago
  I tried this out in PureScript [1]. I also made each type class have only one member and didn't specify any class hierarchy. I like how it works, but I don't know if anyone else does. It allows you to recreate the category theory type classes [2] if you want to: class (HasMap f) <= Functor f class (Functor f, HasApply f) <= Apply f class (Apply f, HasPure f) <= Applicative f class (Apply m, HasChain m) <= Bind m class (Applicative m, Bind m) <= Monad m [1]: https://github.com/tfausak/purescript-neon/blob/v0.5.4/src/Neon/Class/HasMap.purs https://github.com/tfausak/purescript-neon/blob/v0.5.4/src/N... [2]: https://pursuit.purescript.org/packages/purescript-prelude/1.0.1/docs/Control.Monad#t:Monad https://pursuit.purescript.org/packages/purescript-prelude/1...

wz1000 10y ago

I don't really agree with the example that was chosen. "Functor" is a well defined term with a specific meaning. A much better example would be "Show"(Showable) vs "Traversable".

tempodox 10y ago
Nope. In OCaml, “Functor” is a well-defined term with a completely different meaning. Or go look what “Functor” means in Prolog. Well defined, completely different. If you really want to mess things up, use names that mean something different every day. But I would know what a “Mappable” should be, regardless of PL.
- wz1000 10y ago
  https://en.wikipedia.org/wiki/Functor https://en.wikipedia.org/wiki/Functor
  - awj 10y ago
    ...you're kind of helping the "don't use Functor" argument here. Most programmers are programmers first and mathematicians second, if at all. Reusing terms from math that have been overloaded in programming domains is definitely going to create a scenario where many (most?) users don't correctly understand the terms you're using.
    - wz1000 10y ago
      A Functor is a fundamental category-theoretical term with a specific definition that simply isn't captured by something vague like "Mappable". Precision is important when talking about such terms. It is not at all clear that (-> a) is "Mappable". Lots of terms like Profunctor, Contravariant Functor, Bifunctor etc. (which are also the names of typecasses in Haskell) rely on the precise, category-theoretical definition of Functor.
- MustardTiger 10y ago
  >In OCaml, “Functor” is a well-defined term with a completely different meaning No, it has the same meaning. It does not behave identically because the languages do not have identical designs. >But I would know what a “Mappable” should be, regardless of PL. Lots of people wouldn't, and would be wondering what cartography has to do with anything. And even for people familiar with the functional "map", now they would just have an incorrect idea of what Functor is. Lots of Functors are things most people would not think of as being "Mappable".
  - more_original 10y ago
    > >In OCaml, “Functor” is a well-defined term with a completely different meaning > No, it has the same meaning. It does not behave identically because the languages do not have identical designs. Functors in Haskell and OCaml are different things. Haskell Functors correspond to the category-theoretic notion of a functor (a thing mapping objects to objects and morphisms to morphisms in a reasonable manner). In OCaml and ML, Functors represent parameterized modules. These are not known to correspond to category-theoretic functors in any reasonable way (and there have been proposals for category-theoretic models of the ML module system). I guess the term Functor is a bit of a misnomer in the ML-like languages.
    - MustardTiger 10y ago
      >In OCaml and ML, Functors represent parameterized modules No, functors represent functions from a module to a module. Oh hey, that sounds just like the standard definition of a functor. As I said, the behavior is different because the languages are different, but both are named after the category theory functor, because they both emulate it.
      - more_original 10y ago
        Please read up on the ML module system and its origins. http://cs.stackexchange.com/questions/9769/what-is-the-relation-between-functors-in-sml-and-category-theory http://cs.stackexchange.com/questions/9769/what-is-the-relat... Functors play very different roles in Haskell and OCaml/ML. In Haskell, the Functor class is there to implement the functoriality of a type. If F is a functor, then one implements maps of type F A -> F B from given A -> B in a functorial way. In ML, the term functor was chosen because they are not first-class functions, but "a level up" (much like a functor is a level up from the maps in the category that it operates on). However, if F is an ML functor, then there are no "maps" between the modules F(A) and F(B). The morphism part, which is the essence of a Functor in Haskell, is missing in ML. This is why I think that the functor terminology isn't very good in ML. Not everything that maps one thing to another is a functor.

posterboy 10y ago

only two problems in computer science and naming things is one of them

zeendo 10y ago
There are plenty of problems, but only two hard problems. Actually, I think there are three hard problems in CS. The third being pedants.
- chriswarbo 10y ago
  The two hard problems are cache invalidation and naming things. The third is off-by-one errors.
  - 0xmohit 10y ago
    Perhaps one more: guaranteed once-only delivery.
    - tome 10y ago
      Perhaps one more: guaranteed once-only delivery.
- deleted 10y ago
  [deleted]

posterboy 10y ago

> abstract nonsense this would get downvoted quickly if it was a comment

Y_Y 10y ago
https://en.wikipedia.org/wiki/Abstract_nonsense https://en.wikipedia.org/wiki/Abstract_nonsense
tempodox 10y ago
Then let's thank the holy quantum noise that it isn't. The holier-than-thou PL fanatics here are really insufferable.
- wyager 10y ago
  The term sees wide (humorous) use in the Haskell community.
mcguire 10y ago
It's a technical term.

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.

pklausler 10y ago

Typeclass names could be made redundant in Haskell. If one could state a constraint in terms of a typeclass member, things would be more simple. E.g., "classOf fmap" as a synonym for Functor.

taylorfausak 10y ago
I tried this out in PureScript [1]. I also made each type class have only one member and didn't specify any class hierarchy. I like how it works, but I don't know if anyone else does. It allows you to recreate the category theory type classes [2] if you want to: class (HasMap f) <= Functor f class (Functor f, HasApply f) <= Apply f class (Apply f, HasPure f) <= Applicative f class (Apply m, HasChain m) <= Bind m class (Applicative m, Bind m) <= Monad m [1]: https://github.com/tfausak/purescript-neon/blob/v0.5.4/src/Neon/Class/HasMap.purs https://github.com/tfausak/purescript-neon/blob/v0.5.4/src/N... [2]: https://pursuit.purescript.org/packages/purescript-prelude/1.0.1/docs/Control.Monad#t:Monad https://pursuit.purescript.org/packages/purescript-prelude/1...