HP Package Requirements
wren ng thornton
wren at freegeek.org
Sun Jan 13 23:49:28 CET 2013
On 1/13/13 8:55 AM, Gregory Collins wrote:
> A especially strong -1 from me to any effort to enforce Haskell 98
> compatibility for Haskell Platform packages: that standard is 15 years old
> now, and has been superseded by Haskell 2010.
I think it would be unjust to require H2010 compliance, however I do
think it would be good to strongly suggest that people hew closer to the
standard than they would in non-platform code.
In particular, some extensions have long been widely regarded as
"standard Haskell" (e.g., MPTCs, RankNTypes, Flexible...) and I see no
reason to preclude them, even if there are concerns about how exactly to
codify them in a new Haskell standard. And other extensions are simple
syntactic adjustments (e.g., KindSignatures, GADTSyntax) which would be
unproblematic to codify, but haven't been for whatever reason; these too
have little reason to be excluded from the platform.
However, there are other extensions which are unlikely to ever spread
beyond GHC (e.g., ImplicitParams) and still others that are still
experimental within GHC (e.g., DataKinds, and frankly TypeFamilies).
These extensions should, IMO, be looked on with caution. Granted, TFs
and fundeps are too useful to exclude from the platform, but they
definitely cause issues for other compilers like UHC and jhc. Since the
goal of the platform is to provide a common core for Haskell ---not for
GHC--- we must be wary of including these things, no matter how
desirable they are. While it wouldn't be productive to outright exclude
problematic extensions like these, I do think it should be subject of
debate when deciding whether to add a new package or not.
It's this belief that only GHC matters which is part of the reason why
other compilers like UHC and jhc have had such difficulty getting a
foothold. I for one welcome competition and was very sad to see Hugs go
by the wayside. Competition helps foster creativity and helps keep us
from getting stuck in accidental dead ends brought on by monopoly. But
supporting UHC and jhc means more than paying lip service to the idea
that it'd be nice to have competitors; it means actually making some
sacrifices in order to help them along. The H98 and H2010 specifications
may be out of date, but the platform should be a reasonable target for
any aspiring Haskell compiler to master. Including every research
extension GHC has accrued over the years sets the bar too high for any
practical team to target. Even with its popularity, I doubt GHC itself
would support many of these extensions, were not for the historical
accident that they were implemented in GHC the first time around.
More information about the Libraries