7 ms·

It's not that monads "require" higher kinded types, it's that , like an interface, monads only start really "buying" their "cost" when there are _many_ differen

by platz 5y ago

It's not that monads "require" higher kinded types, it's that , like an interface, monads only start really "buying" their "cost" when there are _many_ different things that can be monads. Then the common abstraction of the monad can be used to interact with these things that all share this common property, in a unified way. Finally, higher kinded types is what makes the idea of _many_ different things that can be monads manageable for the programmer, because if the underlying thing that the monad represents keeps changing into different forms, it's very easy to loose track of what structure or concept it currently represents without the types to keep track of that for you.

adamgordonbell 5y ago
yeah, that's better put. The usefulness of it, to me, is how the bind/flatmap can be generic over type constructors, but type constructors aren't a clojure concept. It's a static typing thing. To have an interface for monads, you need to have HKT don't you? To declare the type of bind? It could be useful otherwise. It would just seem like a slightly different thing.
- jerf 5y ago
  You can also theoretically go the completely opposite direction and use dynamic typing. You have the usual tradeoffs related to that, plus maybe a couple new wrinkles, but it can work.
- fiddlerwoaroof 5y ago
  Someone once told me “continuations are isomorphic to monads” and I eventually realized that the best way to do something monad-like in JS was to write functions that take a callback as their last argument and then higher order functions that manage threading the callbacks around, occasionally transforming it to slot in impure behaviors. I really disagree with the notion “HKT are necessary for monads”, though: they’re necessary to statically check that your monadic code is correct, but asside from things that rely on return-type inference, you can just implement those type-checks as runtime checks (or leave them out entirely): if the architecture of side-effects in your app is arranged around monadic principles, you can write all the same generic transformations (and, in fact, designing your dynamically typed code this way can get you a good fraction of the correctness benefits of static typechecking)
  - fiddlerwoaroof 5y ago
    One example here. CLOS-style multimethods are a reasonably good runtime analog of the way typeclasses work: typeclasses use type inference to thread a dictionary of functions around, multimethods do roughly the same thing with dynamic type-checks. This means multimethods have overhead typeclasses don’t have, but it also means that multimethods don’t have the “closed-world” assumption and can be extended dynamically.
jerf 5y ago
I think there's a lot of people confusing the bricks of functional programming with what you can build with them. The interesting thing about 'monads' isn't bind and return. The interesting thing is the Control.Monad functions that build on them, and by making something that conforms to the monadic interface, you get to use them: https://hackage.haskell.org/package/base-4.15.0.0/docs/Control-Monad.html#g:5 https://hackage.haskell.org/package/base-4.15.0.0/docs/Contr... Just like the special thing about iterators isn't that you can get the "next" thing. That's not impressive on its own. The magic is in the tools you get that can generically use and manipulate iterators if they conform to a particular interface.
- lalaithion 5y ago
  Example of a time when the Control.Monad functions were useful to me: https://lalaithion.xyz/posts/practical_monad.html https://lalaithion.xyz/posts/practical_monad.html
- endgame 5y ago
  Exactly this. The power of an abstraction is roughly the product of two metrics: 1. How many things "fit" this abstraction? 2. What does this abstraction let me say? The abstraction "Monad" has many inhabitants, and the Control.Monad module shows that it lets you say many things -> it is a very useful abstraction. The abstraction "Applicative" has many more inhabitants, but lets you say fewer things -> it is still a useful abstraction.
pharmakom 5y ago
I think this is only partly true. The other big benefit of monads is that they can automatically work with syntactic-sugar such as do-notation to allow non-linear code to be written in a linear way. Monads and syntax, even without HKT, allow the user to write their own async-await, option, result, list, etc. expressions.

by platz 5y ago

adamgordonbell 5y ago

yeah, that's better put. The usefulness of it, to me, is how the bind/flatmap can be generic over type constructors, but type constructors aren't a clojure concept. It's a static typing thing. To have an interface for monads, you need to have HKT don't you? To declare the type of bind? It could be useful otherwise. It would just seem like a slightly different thing.

jerf 5y ago
You can also theoretically go the completely opposite direction and use dynamic typing. You have the usual tradeoffs related to that, plus maybe a couple new wrinkles, but it can work.
fiddlerwoaroof 5y ago
Someone once told me “continuations are isomorphic to monads” and I eventually realized that the best way to do something monad-like in JS was to write functions that take a callback as their last argument and then higher order functions that manage threading the callbacks around, occasionally transforming it to slot in impure behaviors. I really disagree with the notion “HKT are necessary for monads”, though: they’re necessary to statically check that your monadic code is correct, but asside from things that rely on return-type inference, you can just implement those type-checks as runtime checks (or leave them out entirely): if the architecture of side-effects in your app is arranged around monadic principles, you can write all the same generic transformations (and, in fact, designing your dynamically typed code this way can get you a good fraction of the correctness benefits of static typechecking)
- fiddlerwoaroof 5y ago
  One example here. CLOS-style multimethods are a reasonably good runtime analog of the way typeclasses work: typeclasses use type inference to thread a dictionary of functions around, multimethods do roughly the same thing with dynamic type-checks. This means multimethods have overhead typeclasses don’t have, but it also means that multimethods don’t have the “closed-world” assumption and can be extended dynamically.

jerf 5y ago

I think there's a lot of people confusing the bricks of functional programming with what you can build with them. The interesting thing about 'monads' isn't bind and return. The interesting thing is the Control.Monad functions that build on them, and by making something that conforms to the monadic interface, you get to use them: https://hackage.haskell.org/package/base-4.15.0.0/docs/Control-Monad.html#g:5 https://hackage.haskell.org/package/base-4.15.0.0/docs/Contr... Just like the special thing about iterators isn't that you can get the "next" thing. That's not impressive on its own. The magic is in the tools you get that can generically use and manipulate iterators if they conform to a particular interface.

lalaithion 5y ago
Example of a time when the Control.Monad functions were useful to me: https://lalaithion.xyz/posts/practical_monad.html https://lalaithion.xyz/posts/practical_monad.html
endgame 5y ago
Exactly this. The power of an abstraction is roughly the product of two metrics: 1. How many things "fit" this abstraction? 2. What does this abstraction let me say? The abstraction "Monad" has many inhabitants, and the Control.Monad module shows that it lets you say many things -> it is a very useful abstraction. The abstraction "Applicative" has many more inhabitants, but lets you say fewer things -> it is still a useful abstraction.

pharmakom 5y ago

I think this is only partly true. The other big benefit of monads is that they can automatically work with syntactic-sugar such as do-notation to allow non-linear code to be written in a linear way. Monads and syntax, even without HKT, allow the user to write their own async-await, option, result, list, etc. expressions.