[Haskell-cafe] A handy little consequence of the Cont monad

[Derek Elkins]

On Mon, 2008-02-04 at 16:56 -0500, Cale Gibbard wrote:
> On 04/02/2008, Philip Armstrong <phil at kantaka.co.uk> wrote:
> >
> > I've always liked $ for this kind of code, if you want to keep the
> > arguments around:
> >
> >    next xs = runCont $ sequence $ map Cont xs
> >
> > seems quite natural to me.
> >
> 
> I'd probably write that as
> 
> nest xs = runCont . sequence . map Cont $ xs
> 
> or else as:
> 
> nest xs = runCont . sequence $ map Cont xs
> 
> so as not to abuse the fact that ($) really has the wrong
> associativity. (I didn't really give that aspect of the code a
> moment's thought, or else I'd probably have made it either points-free
> or used the first form above. I've been bitten by the MR enough times
> that I'm wary of eta-reducing the last parameter out of functions --
> of course, the explicit type signature means it doesn't matter.)
> 
> It would be nice to flip the associativity of ($) someday. It loses
> little in the way of expressiveness, since one can generally replace
> the first (n-1) instances of ($) with (.) straightforwardly (the one
> exception to this being when there are other operator symbols like
> (***) acting on the functions involved, but these cases are fairly
> rare, and it's arguably clearer to leave those parens in).
> 
> What it would buy us to make ($) left associative is that we could,
> for instance, remove the parens from an expression like:
> 
> f (g x) (h y) (k z)
> 
> getting:
> 
> f $ g x $ h y $ k z

and also, pointedly,
f $! g x $! h y $! k z
or even just
f $! x $! y

> Perhaps for Haskell 2. :)

We'll get rid of the monomorphism restriction then too and you won't
have to be wary.