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