HP Package Requirements

[Conrad Parker]

On 14 January 2013 06:49, wren ng thornton <wren at freegeek.org> wrote:
> 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.

I disagree. I thought the point of the Haskell Platform was to provide
a curated set of tools and libraries that can be relied upon for
production code.

Regarding compilers, we have barely enough people working on GHC to
meet its practical requirements (eg. architecture ports), and it's
simply unrealistic to expect that we'll find 3x as many people with
motivation and skills to bring other compilers up to the same level of
performance, features and polish.

Conversely, research compilers with a simpler codebase are useful for
testing out new ideas (like UHC's javascript backend), and shouldn't
have to be burdened with expectations of strict release schedules,
portability, and prioritizing performance bugs.

Conrad.