The Monad Called Free (2014) • Hacker News Board

Re: The Monad Called Free (2014)

#41

Post by lisper » Sun, Feb 08, 2026, 3:11 AM UTC

anon291 wrote: post #21

lisper wrote: post #14

Earlier quoted context omitted.

> You need a Monad type in order to express that certain things are supposed to happen after other things This is the kind of explanation that drives me absolutely batshit crazy because it is fundamentally at odds with: > Do you understand "flatmap"? Good, that's literally all a monad is: a flatmappable. So, I think I understand flatmap, assuming that this is what you mean: https://www.w3schools.com/Jsref/jsref_array…

Because you're not used to abstract algebra. JavaScript arrays form a monad with flatmap as the join operator. There are multiple ways to make a monad with list like structures. And you are correct. Monads have nothing to do with sequencing (I mean any more than any other non commutative operator -- remember x^2 is not the same as 2^x) Haskell handles sequencing by reducing to weak head normal form which is controlle…

OK, so the defining characteristic of a monad M is that:

a.M(b).M(c) = a.M(function(x){return b(x).M(c)})

So the next question is: why should I care about that pattern in particular?

Re: The Monad Called Free (2014)

#42

Post by anon291 » Sun, Feb 08, 2026, 2:56 PM UTC

KPGv2 wrote: post #37

anon291 wrote: post #20

Earlier quoted context omitted.

There is an implied order of operations in Haskell. Haskell always reduces to weak head normal form. This implies an ordering. Monads have nothing to do with order (they follow the same ordering as Haskell's normalization guarantees). > JavaScript decided to standardize on a Monad-shaped "thenable" specification for representing asynchronous processes, Its impossible for something to be monad shaped. All asynchronous…

> All asynchronous interfaces form a monad whether you decide to follow the Haskell monad type class or decide to do something els JS's then is categorically not a monad because it doesn't follow the monad laws. fn1 : a -> Promise fn2 : b -> c fn3 : b -> Promise With JavaScript, composing fn1 and fn2 with then gives you a -> Promise . So then is isomorphic to map. With JavaScript, composing fn1 and fn3 with then give…

I mean, JavaScript is weakly typed and then always lifts its argument. Speaking of isomorphism doesn't make sense unless you're talking about a typed portion of the language.

Re: The Monad Called Free (2014)

#43

Post by anon291 » Sun, Feb 08, 2026, 2:58 PM UTC

lisper wrote: post #41

anon291 wrote: post #21

Earlier quoted context omitted.

Because you're not used to abstract algebra. JavaScript arrays form a monad with flatmap as the join operator. There are multiple ways to make a monad with list like structures. And you are correct. Monads have nothing to do with sequencing (I mean any more than any other non commutative operator -- remember x^2 is not the same as 2^x) Haskell handles sequencing by reducing to weak head normal form which is controlle…

OK, so the defining characteristic of a monad M is that: a.M(b).M(c) = a.M(function(x){return b(x).M(c)}) So the next question is: why should I care about that pattern in particular?

You don't? There's nothing special about monads. I don't know why everyone cares so much about them.

There are a few generic transforms you can use to avoid boilerplate. You can reason about your code more easily if your monad follows all the monad laws. But let's be real.. most programmers don't know how to reason about their code anyway, so it's a moot point

Re: The Monad Called Free (2014)

#44

Post by anon291 » Tue, Feb 10, 2026, 8:05 AM UTC

KPGv2 wrote: post #39

anon291 wrote: post #33

Earlier quoted context omitted.

There is no 'so?' Haskell tends towards applicatives and monads because monads and applicatives are the preferences of haskellers. Just like JavaScript people may like dynamic typing, etc. These are design choices. By modeling various things as monads, you get the various principled monad extensions. Unlike normal programming where leaky abstractions are the expectation, using algebraic structures with principled law…

> Nothing like monoids exist in other languages Monoids exist in plenty other languages. Hell, I use them in TypeScript.

Once again, TypeScript is a nice type checker for JavaScript, but the semantics of TypeScript are untyped.