Proposal: Applicative => Monad: Call for consensus

[Conor McBride]

Ahem

On 17 Jan 2011, at 17:22, Tyson Whitehead wrote:

> On January 15, 2011 22:43:32 Jan-Willem Maessen wrote:
>> For example, I find it relatively easy to
>> understand >>= in the continuation monad, but have to spend a long
>> time puzzling my way through join.
>
> It's not that bad once you get used to thinking of it.  Join simply  
> merges an
> inner computation into an outer one.

[..]

> Something a lot more friendly to the notation would be if A, B, and  
> C were
> independent computations whose combined results were to determine  
> another
> computation via a function g.  This result, along with D and E,  
> where then to
> be fed into yet another function f.  This is simply expressed as
>
> f <$> join (g <$> A <*> B <*> C) <*> D <*> E

Funnily enough, SHE lets you write

   (| f (| g A B C @ |) D E |)

where the postfixed @ denotes a join: g's effects happen "after" those
of A, B and C, but "before" those of D and E.

[..]

I'm tempted to support

   if <- b then t else f

for

   (b >>= \ z -> if z then t else f)

and

   case <- s of {p1 -> e1; ..}

similarly.

> The unfortunate pain you pay for this additional power is manually  
> having to
> specify the application (<$> and <*>) and merging (join).  If the  
> compiler
> could figure this all out for you based on the underlying types, wow!

To achieve such a thing, one would need to ensure a slightly more
deliberate separation of "value" and "computation" in the presentation
of types. In Haskell, we use, e.g., [Int], for

   * pure computations of lists of integers
   * nondeterministic computations of integers

and we spend syntax (do-notation, lifting operators) to distinguish the
two modes of usage. If every type was clearly decomposable into its
computation and value components, the above possibilities would be
distinct (but isomorphic) and we could spend less syntax on plumbing
in programs.

I fear it's too late to reorganize Haskell along these lines, but it's
bound to happen in some language (Disciple? Eff?) sometime.

As any ML programmer will tell you, functional programming is really
cool, even when it isn't purely functional programming.

All the best

Conor