HP Package Requirements
wren ng thornton
wren at freegeek.org
Mon Jan 21 06:32:58 CET 2013
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.
> 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.
More information about the Libraries