[Haskell-cafe] Getting containers updated in Stackage
Herbert Valerio Riedel
hvriedel at gmail.com
Mon Apr 3 08:17:56 UTC 2017
Hi,
On 2017-04-02 at 01:23:52 +0200, David Feuer wrote:
> The fact that GHC needs to have its own containers shouldn't prevent a
> consistent package set from using a different one. The only hypothetical
> problem would be if the GHC API leaked containers types, but I'm pretty
> sure it doesn't: they're all wrapped up in newtypes and exported
> abstractly, unless someone's made a mistake.
Fwiw, I just opened up the GHC api haddocks and arbitrarily picked a
module and sure enough I was able to find a use of an exposed container
type rightaway, specificially `IntMap`:
https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc-8.0.1/HscTypes.html#t:ModBreaks
I'd expect to easily find more leaked types from containers and other
dependencies.
Relatedly, I don't think it's a good idea to implement support for
internal/private dependencies at this point yet w/o first having the
tools to verify that types that are supposed to stay hidden don't leak
through the exposed API. Otoh, tools for doing this kind of static
analysis are also needed to verify the existing API versioning contract
we already use now. And once we have such go-to tooling, it should be
easy to build on top of that.
However, if we wanted to decouple `ghc` from `containers` (and possibly
other packages, such as process/transformers/unix/bytestring/binary) by
declaring the use of its `container` types private/internal to `ghc`'s
API, we could just go back to do what we did years ago (e.g. in GHC
7.0.4) by using renamed packages like `ghc-binary` (but also revisit the
reasons why we don't do this anymore...).
Another approach would be to make the `ghc` package recompilable by
`cabal`. I briefly tried that[1] but got side-tracked, and I still believe it should be possible to get the
`ghc` package to the point where it's an ordinary `cabal`-buildable
package.
[1]: Not the least, so I could upload it to Hackage and have its
Haddocks being generated without too much magic; but more
importantly so that cabal would be less constrained when solving
for install-plans when `ghc` is involved, as well as GHC HQ being
able to more easily pick up new dependencies for `ghc` w/o having
to introduce yet another congestion point in terms of dependency
constraints (i.e. packages depended upon by `ghc` are effectively
frozen to those picked by a given GHC release once `ghc` enters an
install-plan).
More information about the Haskell-Cafe
mailing list