MIN_VERSION macros

[Edward Z. Yang]

Excerpts from Reid Barton's message of 2015-09-25 12:36:48 -0700:
> It knows at some point, but it doesn't necessarily know before parsing the
> module, at which point it is too late. I can have two versions of a package
> A, and two other packages B and C that depend on different versions of A,
> and depending on whether a module M uses package B or package C, M will see
> different versions of package A automatically. This is all slightly
> magical, and I have to say I don't entirely understand how GHC decides
> which versions to expose in general, but that's how GHC works today and
> it's quite convenient.

Well, this is half true.

The main "problem" is that GHC is actually a lot more flexible than
Cabal's model allows: Cabal enforces that for any package, there is
only one version of it in a program.  But GHC can link any combination
of packages (in GHC 7.8, it could link one instance of a package
per package name and version; in GHC 7.10, it can link arbitrary
instances together as long as they have distinct version names.)

But I don't think this is a problem...

> 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.)

> (Also, I wonder how MIN_VERSION_* fits into a Backpack world...)

We have to support version bounds for BC, so... as well as BC can be :)

Edward