MIN_VERSION macros

[Reid Barton]

On Fri, Sep 25, 2015 at 4:09 PM, Edward Z. Yang <ezyang at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150925/1723911a/attachment-0001.html>