Manuel wrote:
As John Launchbury has said, given Haskell's current rise in popularity, anything that we do not fix with H' will be much harder, if not impossible, to fix in the future.
On Thu, 24 Apr 2008 09:21:41 +0100, Neil Mitchell wrote:
That is a very good point. Perhaps we're already a little too late.
In general, I truly hope that this is not the case. Part of what makes Haskell such a great environment is the sense that the language values doing things right, trying out new ideas and adopting them when they work, and that the Haskell community takes pride in what we have as a language. I'm certainly willing to give up some effort fixing my old code in order to use such a language. Now, I realize that me fixing my old Haskell code means something like ten thousand lines at most, while for others it may mean a couple orders of magnitude more work; maybe it's best just to ignore me. But it would be a shame if, in the course of trying to do the right thing for Haskell's large popularity, we ended up diluting the things about the language that make it popular. So I'd argue that, in Haskell' and later on as well, it should be just a fact of life that code will occasionally break as the language evolves. If there's a consensus that something is broken, it should be fixed. If people want their code from 10 years ago to work on today's latest compiler, then there will be lots of intangible costs to achieving that goal, and I'm not sure the current spirit of Haskell will survive those costs. Unfortunately, that cost, which might be expressed as "Haskell won't be as nifty a language any more", is hard to take seriously; but I'm nevertheless convinced that it has to be taken seriously. That said, three caveats: 1. If the goal of Haskell' in particular is to codify existing practice, that's quite the admirable goal given how far behind (10 years!) things currently are in having a language standard. So this is more about how we should think about life after Haskell', rather than the current Haskell' effort. 2. Nothing I said is an argument for intentionally making people's lives painful. For example, there's no need to take approaches that break people's code between consecutive versions of Haskell with no easy way of making the code work with both. Neil said this better elsewhere, so I won't repeat it. 3. Don't get me wrong; I'm definitely not arguing for this ($) associativity change, for example, and my objection is the backward compatibility. But ultimately, it's more like a combination of incompatibility and the lack of a really compelling story on why it should be one way or the other. I have a hard time calling this a "fix"; it's more like a change of personal taste. If I saw this as really broken, then I'd say we need to talk about how to fix it. -- Chris