3 ms·

In the talk he says that continuations compose much better than monads. Can someone elaborate on this?

jerf 7y ago
In a Java context, I'd say it's undeniably true. Haskell-style composition of monadic values depends on type system features that Java doesn't have and on no account should even be thinking about adding at this point in time. And that's ignoring the syntax mess it would be in Java today, too. In a Haskell context, since continuations are typically implemented as a monadic value, the statement would be more or less nonsensical. But I don't think that would be the context in question. Edit: noelwelsh speaks of another level of composition than I was, where one is trying to take, say, State and STM and create a new monadic value that does both those things. The analysis given there is correct as well. My point here is more syntactic and basic functioning, in that even if you pick a single monadic value type to stick with, it's not going to play well in Java anyhow. So, in conclusion, generalized monad-type code in Java is just comprehensively not really possible. Continuations, or what are being called that in modern times, however, fit into Java-type languages, as proved by several very similar languages that have had them for many years, and they work fine.
- pron 7y ago
  We're trying to minimize and discourage the use of monads, not encourage it :) Having said that, monads don't compose well regardless of language.
noelwelsh 7y ago
Monads don't compose, in the sense that if you two monads of different types you can't always mash them together to create a single monad that encompasses both of the effect the two monads represent. This is not surprising as (side-)effects don't in general compose so there is no reason that monads should. Now I disagree with Ron's assertion that continuations compose better than monads. Here's why: All monads can be expressed in terms of the continuation monad. As the name suggests this is just a monadic encoding of continuations. (See https://www.schoolofhaskell.com/school/to-infinity-and-beyond/pick-of-the-week/the-mother-of-all-monads https://www.schoolofhaskell.com/school/to-infinity-and-beyon...). If your language has continuations built-in then all programs are effectively running in some "ambient" monad that can express all other monads. Just like if you have exceptions you're effectively running within an error-handling monad. So essentially rather than writing `F A` (or `F[A]` or `F<A>` or whatever syntax your language supports) to represent effectful programs all programs are implicitly running within such an effect type.
- pron 7y ago
  It's true that monads and delimited continuations are equivalent, but what we have here aren't any delimited continuations but what's known as multi-prompt delimited continuations, and I call them "scoped continuations" (http://blog.paralleluniverse.co/2015/08/07/scoped-continuations/ http://blog.paralleluniverse.co/2015/08/07/scoped-continuati...). Those compose well, and their pure-FP counterpart is algebraic effect systems (based on monads, but don't use monad transformers).
- rjn 7y ago
  There are ways to compose monads, https://en.wikibooks.org/wiki/Haskell/Monad_transformers https://en.wikibooks.org/wiki/Haskell/Monad_transformers

jerf 7y ago

In a Java context, I'd say it's undeniably true. Haskell-style composition of monadic values depends on type system features that Java doesn't have and on no account should even be thinking about adding at this point in time. And that's ignoring the syntax mess it would be in Java today, too. In a Haskell context, since continuations are typically implemented as a monadic value, the statement would be more or less nonsensical. But I don't think that would be the context in question. Edit: noelwelsh speaks of another level of composition than I was, where one is trying to take, say, State and STM and create a new monadic value that does both those things. The analysis given there is correct as well. My point here is more syntactic and basic functioning, in that even if you pick a single monadic value type to stick with, it's not going to play well in Java anyhow. So, in conclusion, generalized monad-type code in Java is just comprehensively not really possible. Continuations, or what are being called that in modern times, however, fit into Java-type languages, as proved by several very similar languages that have had them for many years, and they work fine.

pron 7y ago
We're trying to minimize and discourage the use of monads, not encourage it :) Having said that, monads don't compose well regardless of language.

noelwelsh 7y ago

Monads don't compose, in the sense that if you two monads of different types you can't always mash them together to create a single monad that encompasses both of the effect the two monads represent. This is not surprising as (side-)effects don't in general compose so there is no reason that monads should. Now I disagree with Ron's assertion that continuations compose better than monads. Here's why: All monads can be expressed in terms of the continuation monad. As the name suggests this is just a monadic encoding of continuations. (See https://www.schoolofhaskell.com/school/to-infinity-and-beyond/pick-of-the-week/the-mother-of-all-monads https://www.schoolofhaskell.com/school/to-infinity-and-beyon...). If your language has continuations built-in then all programs are effectively running in some "ambient" monad that can express all other monads. Just like if you have exceptions you're effectively running within an error-handling monad. So essentially rather than writing `F A` (or `F[A]` or `F<A>` or whatever syntax your language supports) to represent effectful programs all programs are implicitly running within such an effect type.

pron 7y ago
It's true that monads and delimited continuations are equivalent, but what we have here aren't any delimited continuations but what's known as multi-prompt delimited continuations, and I call them "scoped continuations" (http://blog.paralleluniverse.co/2015/08/07/scoped-continuations/ http://blog.paralleluniverse.co/2015/08/07/scoped-continuati...). Those compose well, and their pure-FP counterpart is algebraic effect systems (based on monads, but don't use monad transformers).
rjn 7y ago
There are ways to compose monads, https://en.wikibooks.org/wiki/Haskell/Monad_transformers https://en.wikibooks.org/wiki/Haskell/Monad_transformers