On 1/20/13 12:03 PM, Mark Lentczner wrote:
I believe the point of the Platform is so that the vast majority of developers have a stable, full featured Haskell environment to work from, and can mostly just use and depend on it.
Agreed.
It is not an aim that the platform's library set should be a "super-Prelude" that works multiple Haskell Implementations. That isn't to say we shouldn't be cautious about admitting packages using more exotic features of GHC: we should. But our caution should stem from concern about how they will impact user's code, and likely longevity and popularity of such extensions.
Which is exactly the point I was trying to make. As outdated as it is for a standard, Haskell2010 compliant code has the distinct benefit that it doesn't rely on anything that's liable to change in the foreseeable future. Certainly, one can go beyond H2010 and still be confident in portability to the future. But the further one strays, the more likely they are to run into things which will not survive the test of time. True, supporting research compilers is a personal goal of mine. However, the dictum to hew as close to H2010 as reasonable is something that stems from purely pragmatic concerns. Even if one is only interested in GHC, porting programs from one *version* of GHC to another can take a considerable amount of work when using advanced/experimental extensions to the language. If the goal is to provide a stable set of batteries, then the goal necessarily precludes advanced type hackery, since GHC's ability to infer types varies significantly from version to version. Of course, recognizing this point requires admitting to the fact that not all uses of a given extension are created equal. You can use type families in simple and straightforward ways which are unlikely to break, just as you can use fundeps in complex ways to forge type equality or force the compiler to solve Peano arithmetic. One of these is appropriate for the HP; one of them is not. The reason I brought up other compilers is that, if your code can be compiled on multiple compilers, then there's a very good chance that code will survive bitrot long enough to make it to the next upgrade, even in environments that can't afford to buy new equipment annually. Whereas, if your code broke anywhere in the transition from GHC 6.12 to GHC 7.4, then it's already demonstrated its instability. -- Live well, ~wren