HP Package Requirements

[wren ng thornton]

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