patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Cale Gibbard]

2008/4/22 Aaron Denney <wnoise at ofb.net>:
> On 2008-04-22, Simon Marlow <marlowsd at gmail.com> wrote:
>
> > Chris Smith wrote:
>  >> I know it would break
>  >> nearly every single piece of Haskell code I've ever written.  As such,
>  >> I'm biased toward thinking it's an extremely bad idea.
>  >
>  > Absolutely.  Given that, we'd need a *very* good reason to make the change.
>
>  Surely we don't expect the majority of Haskell code to work unchanged as
>  Haskell' code?
>

And if we're not going to break things in Haskell', then when *are* we
going to break them? Making all the little fiddly changes at once
seems like a better plan than standardising on one thing and then
changing things away from that in the implementations shortly
afterwards. It also seems like a better plan than forking the language
over what are essentially library issues. (This is a sort of minor
one, but there other things, like 'fail', which I certainly would hope
we don't just live with forever.)

If the only goal of Haskell' is to standardise current practices, then
I agree this change makes no sense, but it also seems not to make much
sense to standardise a Prelude which people strongly want to change.

Also, the Haskell 98 Prelude has already been reported on, and
probably should continue to be supported in some way or another.

By the way, as Don suggests, I do strongly advocate this change, and
Dan Doel has already given a very nice summary of why. With regard to
reason #1 in his list, I'd just like to add that due to the fact that
(.) is an associative operator, a composition chain written in terms
of (.) effectively has more subexpressions than one written in terms
of ($), and is thus at least marginally easier to refactor and reason
about. I've found that favouring (.) and being comfortable with
expressing things in terms of function composition very much puts one
in the right mindset for functional programming.

 - Cale