time library dependencies

[wren ng thornton]

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