Hacker News new | ask | show | jobs
by tathougies 2986 days ago
> Why are you, presumably a Haskell programmer, surprised when someone repeated that usage in 2018 on an internet forum?

I hate the way monads in general are talked about in the Haskell community (I also do not like the language for other algebraic terms). In particular, it is common to say 'data type X is a monad'. This statement is completely nonsensical. A monad is a thing along with some operations. Haskell data is a concrete description of how to store a thing. By itself, a piece of data has no operations associated with it. There is no way a particular data type could be a monad, since a data type is just a thing.

The proper terminology is 'X forms a monad along with these functions' or 'X has an instance for the Monad type class' (this is different, because the monad type class allows for a subset of monads, not general monads). I am on a personal mission to rid the Haskell world of sloppy language because it confuses beginners, in my opinion. For a long time, I thought monads were a thing. Then I realized they're just an algebraic structure, like groups or rings.

When we say things like 'monads don't compose' it makes it seem like there is some deficiency in the idea of a monad that makes them not compose, rather than a realization that monad composition results in zero or more ways to combine two arbitrary monads. Thinking just the former makes you wonder if monads ought to be fixed. Realizing the latter means you realize that the lack of a fix indicates that putting two monads together can accomplish a variety of tasks, only one of which is likely suited to your use case.

2 comments

> …it is common to say 'data type X is a monad'. This statement is completely nonsensical…

I think the reason for this is that in Haskell we model algebraic structures using typeclasses, which are dispatched by type. So we say “X is a monoid, with mempty and mappend defined as follows”:

    instance Monoid X where
      mempty = …
      mappend = …
Instead of “X, emptyX, and appendX form a monoid”:

    instance Monoid X emptyX appendX
    emptyX = …
    appendX = …
This leads to what I call the “newtype hack” for distinguishing different monoids (resp. monads, &c.) on the same underlying type.
Thanks for writing this. I understand now where you come from and am sympathetic to your reasoning. Thanks again!