time library dependencies
wren ng thornton
wren at community.haskell.org
Tue Jun 2 21:06:37 EDT 2009
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
>>> 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
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.)
More information about the Libraries