On 2011-12-23 13:46, Conor McBride wrote:
The plan is to make a clearer distinction between "being" and "doing" by splitting types clearly into an effect part and a value part, in a sort of a Levy-style call-by-push-value way. The notation
[<list of effects>]<value type>
is a computation type whose inhabitants might *do* some of the effects in order to produce a value which *is* of the given value type.
The list of effects is arbitrary, and localizable, by means of defining handlers. So it's not a single monad.
It's probably still disappointing.
On the contrary!
Haskell doesn't draw a clear line in types between the effect part and the value part, or support easy fluidity of shifting roles between the two. Rather we have two modes: (1) the implicit partiality mode, where the value part is the whole of the type and the notation is applicative; (2) the explicit side-effect mode, where the type is an effect operator applied to the value type and the notation is imperative.
I was drawn to call-by-push-value a few years ago while attempting to create a language which would support both call-by-value and call-by-name. I haven't had the skill to express what I have felt to be the shortcoming of Haskell, but I believe you've put your finger right on it.
it's an attempt to re-rationalise techniques that emerged from Haskell programming. Exactly.
Haskell has grown a wealth of features/libraries/techniques for combining monads, yet the fundamental monad, evaluation, has a separate place in the language. -- Scott Turner