time library dependencies

[Duncan Coutts]

On Thu, 2009-06-04 at 16:02 +0100, Bayley, Alistair wrote:
> > From: libraries-bounces at haskell.org 
> > [mailto:libraries-bounces at haskell.org] On Behalf Of Duncan Coutts
> > 
> > > What are the code standards for the HP libs? I was under 
> > the impression
> > > that it was best to maintain H98 compatibility where possible,
> > > especially so for libraries in the old standard libs 
> > distribution. I did
> > > a quick search for platform standards but didn't find 
> > anything relevant.
> > 
> > It's yet to be discussed on this list. Perhaps this is a good
> > opportunity to start that discussion. Do you want to draft a 
> > reasonable starting position?
> 
> 
> Maybe, maybe not... I might make better progress with some more
> questions.
> 
> What are the long-term goals of the HP? Do you want to be able to bundle
> compilers other than ghc?

That's an interesting question and one I do not have a firm position on
myself. The HP is supposed to be practical so I don't think we want to
hold things back unduly. However if we can stick to a reasonable subset
of language features then it is at least possible for other compilers to
have a target. It gets harder and harder however as GHC adds more.

So this is yet another question where we want to look for community
discussion and try and get consensus.

> At present the HP is ghc+extralibs, so we could say that anything that
> ghc will compile is acceptable. This does seem to preclude the
> possibility of bundling alternative compilers in the future, though.
> 
> So what is a reasonable common subset? Malcolm suggested:
>   H98 + HierarchicalModules + FFI + CPP + ExistentialTypes

The subset is certainly ok. There are a number of others that are more
controversial, especially the ones needed for typing the ST monad and
some of the generics packages.

> Do we care about compilers that are stable but not (actively)
> maintained? Without wanting to offend anyone here, Hugs, hbc, and nhc
> seem to be pretty much "feature stable". Would we rather look to the
> future; to compilers that support a wider range of extensions? (Rank-2
> or rank-n types spring to mind, esp. in the context of the time library.
> That would eliminate nhc, but I think Hugs is still in the running.)
> MPTCs? MPTCs + fundeps?

I don't know. I'd like an answer too.

> What external tools can library authors assume are available? hsc2hs?
> c2hs? cpphs? I see that alex and happy are specified in the
> haskell-platform.cabal as being present.

They can assume precisely those available in the platform. If we add
cpphs and c2hs, then libs can use those.

> And then there's other possible code standards...

Yep, that's a fun topic though fortunately mostly orthogonal to the
issue of language extensions. Coding standards tend not to impose
dependencies.

>  - Layout and indentation: do we run everything through a pretty printer
> to standardise layout?

That seems extreme to me.

>  - Test coverage: should we require a minimum coverage threshold from
> HPC?

I hope we can move in this direction.

>  - lint-style checks: ghc -Wall? Catch?

There's at least some subset of -Wall we can probably agree on.

>  - any more? ...

We've got a list of suggestions here:
http://trac.haskell.org/haskell-platform/wiki/AddingPackages

currently:
  * Does it meet a stated end-user need?
      * Do similar systems include such a library (e.g. Python)?
      * Is it portable?
      * Does it add additional C libraries? 
      * Does it follow the package versioning system?
      * Is the code of good quality?
      * Does it have history? 
      * Is it on hackage?
      * Does it provide haddocks?
      * Does it have a test suite?
      * Does it have a maintainer?
      * Does it require new Haskell dependencies? (invariant: the
        platform must be closed wrt. deps)
      * Does it have a simple/configure-based Cabal build?
      * Does it conflict/compete with existing functionality?
      * Does it reuse existing types?
      * Does it follow the hierarchical naming conventions? 
      * Is it -Wall clean?
      * Does it have demonstrated users?
      * Have declared correctness or performance statements?
      * Is it BSD licensed?
      * Will the maintainer continue to maintain it, as demand grows ?
      * Is it thread-safe?

Duncan