MIN_VERSION macros

[Edward Z. Yang]

Hi all,

I've implemented this: https://phabricator.haskell.org/D1349

Cheers,
Edward

Excerpts from Reid Barton's message of 2015-09-25 15:15:09 -0700:
> 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