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.