More platform packages

[Johan Tibell]

Hi Greg,

On Wed, Jan 23, 2013 at 9:43 AM, Gregory Collins
<greg at gregorycollins.net> wrote:
> Hopefully you've noticed the proposal I made this morning for attoparsec to
> join the list of platform packages. I wanted to bring up a matter for
> discussion before I propose more packages for inclusion. I'd very much like
> for the following packages written by Bryan to make it into the platform:
>
> aeson
> criterion
> mwc-random
> statistics

These are all good packages, I'd also like to see them in the platform.

> The question is: what do we do, in general, if we want a package but its
> inclusion would force us to pull in other non-platform packages?
> Specifically re: the above list, statistics depends on erf and
> math-functions, aeson depends on hashable and unordered-containers, and
> criterion depends on aeson, hastache, and vector-algorithms.

I think we should first check if the dependencies themselves are
something we want in the platform. If they are, there's no real
problem, we just propose that they all be added.

With the exception of math-functions, which uses non-standard naming
(i.e. underscore_names) and hastache, which might be a bit of a niche
library, I think the dependencies you listed should go into the
platform.

> I remember that we ran into the same issue vis-a-vis vector pulling in the
> "primitive" package, but I'm not sure that the discussion was resolved in a
> way that sets a usable precedent. Here my gut feeling would be that
> "hastache" doesn't cut it as a platform package, we probably want to fold
> unordered-containers into containers in the long term, erf and
> math-functions are probably OK to include as they are.

For primitive Mark and I sat down with Roman and went through the API
and we considered it good enough (i.e. useful on its own) to be
proposed for inclusion as well.

I am considering folding unordered-containers into containers, but I
need to consider what extra obligations/problems being part of the GHC
release (which containers is part of) brings.

> What should we do in these cases? Asking package maintainers to shoulder the
> burden of gutting or completely refactoring their packages to get rid of
> dependencies we don't like seems contrary to the spirit of what we are
> trying to accomplish here. Our procedures seem to be mostly geared around
> refining an individual package's API and then having up-and-down votes on
> inclusion/exclusion. I worry that this is going to disqualify libraries that
> we really, *really* want to include because their maintainers won't want to
> do the pointless busywork that might be required alone.

I think we should avoid pointless busywork too. :) Before we worry too
much about what might happen, lets have a look at the APIs in question
and see if they would work well in the platform as they're currently
written. Once we have a list of concrete problems (if there are any),
we can discuss them with the maintainers.

> Should we instead establish a loose "strike force" (I hesitate to use the
> word "committee") that would work to further these kinds of long-term goals
> by helping maintainers refactor things to make them more platform-friendly?

I think putting in the work to make the changes you'd like to see is a
good way to get them done. :)

-- Johan