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.

Live well,

More information about the Libraries mailing list