Malcolm Wallace wrote:
This does not necessarily mean it must be strictly H'98 compliant, but that would be a good approximation of the common language. What is that "good approximation"?
Haskell'98 + HierarchicalModules + FFI + CPP + ExistentialTypes is pretty well supported across all implementations as far as I know.
I think this is a decent approximation. The H98 + HierarchicalModules + FFI combination tends to be what most people actually mean when they say "Haskell 98", since both of those addenda were made shortly after H98 was finalized. Omitting CPP would impose a severe burden on anyone doing anything remotely interesting. "Interesting" doesn't just mean language extensions or instances for the latest typeclass, it can also include such mundane things as backporting Prelude patches. For example, my logfloat package has patches to correct Hugs Sept2006's definitions of isInfinite and isNaN for RealFloat Double and RealFloat Float. It's a very mundane patch, but Hugs seems sufficiently moribund that I don't expect a new version in the near future. I don't have any particular stance on ExistentialTypes. Another extension I think should be included in "a good approximation of the common language" is MPTCs (not including related features like fundeps and associated types). These are approved for haskell' and they're neigh ubiquitous in modern Haskell code. This does, however, surpass the limitations of most non-GHC/non-Hugs compilers. Which raises the question of whether our definition of "the common language" comes from Haskell users or compiler writers. I'm not sure how best to reconcile that, but MPTCs do seem crucial. At the risk of burdening the HP team, perhaps it would be worth separating the platform into two products. A "98plus" metapackage that only allows the commonly supported core language (H98+HM+FFI+CPP+?); and a "prime" metapackage for additional libraries that allow ubiquitous features which are supported by GHC, Hugs, and haskell'. Even if they haven't gotten there yet, most of the alternative compilers seem to already have the goal of implementing these "prime" features, so it doesn't make sense to disparage them from the platform project IMO.
2. time to require Haskell 98 + FFI + CPP, content depends on compiler 3. time to require Haskell 98 + FFI + CPP, a time-extras package with orphan Data instances
Of these two options, I don't mind, but many people express an anti-preference for orphan instances.
Yeah, orphan instances are bad. I'm with Edward Kmett here, for the time package, having compiler-dependent instances seems like the least evil. (For other packages, it depends on the classes and on how easy it would be to avoid the problem.) -- Live well, ~wren