On Fri, Sep 25, 2015 at 4:09 PM, Edward Z. Yang <ezyang@mit.edu> wrote:

Excerpts from Reid Barton's message of 2015-09-25 12:36:48 -0700:
> GHC could provide MIN_VERSION_* macros for packages that have had their
> versions specified with -package or similar flags (which is how Cabal
> invokes GHC). That would go only a small way towards the original goals
> though.

This is exactly what the MIN_VERSION_* macros should do, and you can
generalize it to work even without -package: you get macros for EXPOSED
packages which are available for import. This says *nothing* about
the transitive dependencies of the packages you're depending on, but
it's more reasonable to have "one package, one version" invariant,
because having multiple versions of the package exposed would cause
a module name to be ambiguous (and unusable.)

Oh, I see. I had always assumed that GHC had some kind of solver to try to pick compatible versions of packages, but having done some experiments, I see that it always picks the newest exposed version of each direct dependency. So we can indeed define MIN_VERSION_* macros in accordance with the newest exposed version of each package.

There are still some edge cases, notably: if package foo reexports the contents of some modules from package bar, and the API of these modules changes between two versions of package bar, then you cannot reliably use MIN_VERSION_bar to detect these API changes in a module that imports the reexports from package foo (since the newest installed foo might not be built against the newest installed bar). In the more restrictive Cabal model, you can reliably do this of course. So it could break in an existing project. However this kind of situation (where the API of a package depends on the version of its dependencies) should hopefully be fairly rare in practice.

Regards,

Reid Barton