4 ms·

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 con

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

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.