Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Effectful Haskell: IO, Monads, Functors

slpopejoy.github.io

Post reply on HN
Print view View original

31–40 of 68 posts

Re: Effectful Haskell: IO, Monads, Functors

#31

Post by agumonkey »

freyrs3 wrote: post #16
nilved wrote: post #2

Naming is one area where Haskell's academic background is more curse than blessing. Numerous tutorials and blog posts would never have been written if only functor was named mappable and monad was named computation builder. They're named by analogy to category theory, but their usage in computer science is not at all similar.

Their usage in Haskell/OCaml etc is precisely faithful to their category theoretic definitions as can be in a general purpose language. This debate about naming monads is pretty tiresome after so many years, if one called it "computation builder" it wouldn't change their structure or convey any notion of the laws any better than term monad. A monad at it's core is a set of algebraic relations.

But most people take comfort in having almost meaningless names. I can't blame them, when I first saw FP, I was lost in a see of nonsense. After time you see that lots of things and names are just crutches, and that structures, shapes, patterns, recursion relationships are where to look for answers.

Re: Effectful Haskell: IO, Monads, Functors

#32

Post by heroku »

"We can see therefore how Monad offers strictly more powerful transformations than Functor. fmap can only transform an individual value “in place”, while >>= can return an empty list, or a list with more elements than the original. Functor is “structure preserving”, while Monad is “structure transforming”."

So for a list monad bind = flatMap fmap = map

is that correct?

Studying FP for quite a while first monad tutorial I come to fully understand finally.

Re: Effectful Haskell: IO, Monads, Functors

#33

Post by mmarx »

spion wrote: post #30
Retra wrote: post #27

Earlier quoted context omitted.

That's something you have to learn to do. It's like asking "where is the stack?" when you're just calling functions. If you don't develop some skill for seeing how your code implements underlying abstractions, you will be missing out. You can program without knowing what a stack is. But if you want to solve a problem using a stack, it helps to know that your function call stack can be 'overloaded' to solve stack prob…

What I meant was something different. The difference is that saying that "IO is a monad" is wrong in the mathematical sense too. IO is not a monad - the combination of (IO, bind, return) is the monad. It only makes sense to say the above in Haskell where there can be only one instance per type. The set of natural numbers N is not a monoid; {N, +, 0} is a monoid. The set may, at best, be "monoidal" (i.e. there exists…

> What I meant was something different. The difference is that saying that "IO is a monad" is wrong in the mathematical sense too.

It's relatively common to refer to the underlying set as a monoid (or whatever structure you're talking about) if it's clear from the context what the operations are, though.

> The set may, at best, be "monoidal" (i.e. there exists associative binary operator and a set member ZERO such that for all elements of the set, ZERO x == x ZERO == x).

That's a pretty useless definition, though, as every non-empty set trivially satisfies that condition (just pick any element as the zero element, and let the binary operation be the constant mapping to that element). Also, “monoidal” usually means a monoidal category, which is something very different from the underlying set of a monoid altogether.

Re: Effectful Haskell: IO, Monads, Functors

#34

Post by agumonkey »

Silhouette wrote: post #25
creichert wrote: post #5

Earlier quoted context omitted.

Their naming is similar enough to leverage existing research literature, and knowledge, though. Those with a background in math can map some of their existing knowledge. Those without a math background have a more precise vocabulary to understand the concepts and research further. Even if they are a bit foreign, I prefer the attempt to be precise.

It's worth observing that "background in math" here probably implies postgraduate study in a relevant field, which very few people will actually have done. The average new math graduate with a bachelor's degree might have heard of category theory but probably hasn't studied it during an undergraduate course. More generally, I think one problem the Haskell world has with attracting more developers is that it's dominat…

But most of the FP culture comes from abstract mathematics. Formal proofs (ml), Symbolic rewriting systems (lisp deriv), ... The issue is that people see programming as the semi concrete modification of devices (we need tangible at first), when these people saw programming as recursive logic over anything, that can be mapped later on actual (or virtual) hardware.

Re: Effectful Haskell: IO, Monads, Functors

#35

Post by chriswarbo »

heroku wrote: post #32

"We can see therefore how Monad offers strictly more powerful transformations than Functor. fmap can only transform an individual value “in place”, while >>= can return an empty list, or a list with more elements than the original. Functor is “structure preserving”, while Monad is “structure transforming”." So for a list monad bind = flatMap fmap = map is that correct? Studying FP for quite a while first monad tutori…

> So for a list monad bind = flatMap fmap = map

> is that correct?

Yes, although Haskell calls "flatMap" "concatMap". Of course "return" is just "\x -> [x]", AKA "(: [])".

Instead of bind (">>="), you can implement Monads using "join" instead. For lists, "join" is simply "concat".

Re: Effectful Haskell: IO, Monads, Functors

#36

Post by spion »

mmarx wrote: post #33
spion wrote: post #30

Earlier quoted context omitted.

What I meant was something different. The difference is that saying that "IO is a monad" is wrong in the mathematical sense too. IO is not a monad - the combination of (IO, bind, return) is the monad. It only makes sense to say the above in Haskell where there can be only one instance per type. The set of natural numbers N is not a monoid; {N, +, 0} is a monoid. The set may, at best, be "monoidal" (i.e. there exists…

> What I meant was something different. The difference is that saying that "IO is a monad" is wrong in the mathematical sense too. It's relatively common to refer to the underlying set as a monoid (or whatever structure you're talking about) if it's clear from the context what the operations are, though. > The set may, at best, be "monoidal" (i.e. there exists associative binary operator and a set member ZERO such th…

> It's relatively common to refer to the underlying set as a monoid (or whatever structure you're talking about) if it's clear from the context what the operations are, though.

Relatively common even outside Haskell?

Re: Effectful Haskell: IO, Monads, Functors

#37

Post by mmarx »

spion wrote: post #36
mmarx wrote: post #33

Earlier quoted context omitted.

> What I meant was something different. The difference is that saying that "IO is a monad" is wrong in the mathematical sense too. It's relatively common to refer to the underlying set as a monoid (or whatever structure you're talking about) if it's clear from the context what the operations are, though. > The set may, at best, be "monoidal" (i.e. there exists associative binary operator and a set member ZERO such th…

> It's relatively common to refer to the underlying set as a monoid (or whatever structure you're talking about) if it's clear from the context what the operations are, though. Relatively common even outside Haskell?

> Relatively common even outside Haskell?

It's common throughout mathematics. So common, in fact, that there's even a wikipedia article on the phenomenon[0].

“Common examples occur when speaking of compound mathematical objects. […] Similarly, one often refers to a group (G, \star) as simply G when the group operation is clear from context.”

[0] https://en.wikipedia.org/wiki/Abuse_of_notation

Re: Effectful Haskell: IO, Monads, Functors

#39

Post by spopejoy »

nilved wrote: post #2

Naming is one area where Haskell's academic background is more curse than blessing. Numerous tutorials and blog posts would never have been written if only functor was named mappable and monad was named computation builder. They're named by analogy to category theory, but their usage in computer science is not at all similar.

How is the list monad a "computation builder"? Sounds to me like "programmable semicolons" and other nonsense: Monad is a typeclass that means very different things depending on what type you're using. It's the shape that has meaning: this level of abstraction is just going to be hard to grasp correctly no matter what you call it.

Likewise with "Mappable": in most other languages, `map` is only an operation on lists or list-like things. `ask` in `Reader` is implementable with Functor only: by what tortured metaphor does `Mappable` help you understand that? Also it sounds like Java. Yuck :)

Names are a bikeshed. Monad, Applicative and Functor have the advantage of at least being rigorous, I can't see any other name being better.

Re: Effectful Haskell: IO, Monads, Functors

#40

Post by wetmore »

nilved wrote: post #2

Naming is one area where Haskell's academic background is more curse than blessing. Numerous tutorials and blog posts would never have been written if only functor was named mappable and monad was named computation builder. They're named by analogy to category theory, but their usage in computer science is not at all similar.

A decent indication that it's not as simple as "well just call it x instead" is that each time I see a comment like this there is often a new "easy" word for monad. Yours is new to me, so I'll add it to the list:

Monads are hard, let's call them

- FlatMappable

- AndThenable

- Joinable

- Chainable (or, Daisychain)

- Computation Builder

Post reply on HN