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

[Manuel M T Chakravarty]

Sittampalam, Ganesh:
> Aaron Denney wrote:
>> On 2008-04-23, Sittampalam, Ganesh
> <ganesh.sittampalam at credit-suisse.com> wrote:
>>> There's plenty of code out there that doesn't have the benefit of a
>>> vigilant user community ready to spring into action. For example,
>>> Credit Suisse has several tens of thousands of lines of code written
>
>>> by internal users who are not Haskell experts, and it would be
> rather
>>> hard to explain to them that they needed to go through it all and
> fix
>>> it.
>
>> What makes them need to update to Haskell' instead of sticking with
> Haskell '98?
>
> (a) the fact that the code already uses several GHC extensions that  
> will
> be in Haskell' and we would like to be closer to standard code
> (b) the expectation that at some point implementations will stop
> supporting
> H98

Care for legacy code is important, but H' will have to break backwards  
compatibility in some places.  And especially where you already rely  
on GHC extensions, you can't really expect that H' will adopt features  
that have been available as GHC extensions in exactly the form that  
they were implemented in GHC.

We should be careful about where we break existing code, and we should  
try to support automatic translation of H98 to H' code, but any  
changes that we do not make now will become even more difficult in the  
future when there is even more Haskell code.  Look at what is  
happening now already, industrial users applying pressure on the  
committee to not change the language too much for the sake of legacy  
code.  A clear indication that anything we don't change now, we will  
have to live with forever.

Hence, anything that is *important* to change, we should change now.   
We should mitigate the pain by having a H98 to H' translator and  
Haskell compilers will surely support a Haskell98 compatibility mode  
as long as there are enough users interested in such a feature.  (This  
is not unlike the transition from K&R C to ANSI C.)

Manuel