Hacker News Reader

Comment by dllthomas | Hacker News Reader

As others pointed out, the way Haskell uses the term "functor" is related to the way mathematicians had been using it for at least a decade before cfront.

I agree that a shared vocabulary is important, but standardizing in a way that makes the mathematical writings on the topic more accessible seems a big win. Moreover, "functor" is a bit more precise than "mappable" - a functor is a mapping that preserves structure. In what sense? The math can guide you. In this case, it means the functor laws.

That's not to say that coming up with other associations to help ease understanding is a problem - I have no problem with saying, "for now, think of Functor as 'mappable'". The equivalent for Monad would probably be "flatMappable", and Monoid would be "appendable".

View on HN

> As others pointed out, the way Haskell uses the term "functor" is related to the way mathematicians had been using it for at least a decade before cfront.

Rather a bit more than that. Eilenberg and Maclane's original paper defining the basic notions of category theory was published in 1945! http://www.ams.org/journals/tran/1945-058-00/S0002-9947-1945...

Thanks! I suspected that was the case, but the looser bound was much easier to be confident in with the level of effort I could spare.

For Monad, 'join' or the kleisli arrow (>=>) might give better intuition than bind/flatMap - maybe something like "contextComposable": kleisli arrow in the Identity monad is just function composition, and for everything else, it's function composition within a context, combining contexts according to 'join'.

I'm... hesitantly okay with "Functor == Mappable", but I really think Monad should be "Embedded DSL" and Monoid "mergeable". Or really Semigroup.

Monad is definitely abnormally difficult to humanize. The trio (T, ∀ a. a -> T a, ∀ a b. (a -> T b) -> (T a -> T b)) is really hard to nail down.

I like "embedded DSL" for Monad, although I think more specialized notions might provide more hooks to hang understanding on in particular cases.

I don't object to "mergeable" for Monoid, but I think I weakly prefer "appendable" since it seems to say a little more about how things merge (and of course the free monoid is exactly that).

Speaking again to the broader context, one thing I really like about Haskell's choice of naming these abstractions after the math is that this type of discussion has no bearing on what types adhere to the abstractions - we're not left arguing over whether Sum and Product are "really" appending, or set intersection is "really" merging. Integers are a clearly monoid under Sum and Product, and set intersection is clearly a semigroup but not a monoid (if our universe is open) because there is no identity.

Reply on news.ycombinator.com