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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
