[Haskell-cafe] If you'd design a Haskell-like language, what would you do different?

[Scott Turner]

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