Hi Gershom,
On Tue, Mar 31, 2015 at 11:22 PM, Gershom B
One way to look at a particular build is in an n-dimensional state space (of the Hilbert sort) determined by all its dependencies, not least the compiler itself. The solver acts as a particle traversing this space. But this description is too simple. Our state of dependencies and constraints itself varies and grows over time. So another approach is to think of the dependencies as a transitive graph, where each node may vary along a time axis, and as they slide along the axis, this in turn affects their children. We now have not just one Hilbert space, but a collection of them related by branching trees as authors locally modify the dependencies of their packages.
I don't know if you intended this to be a satirical remark about the package upper bounds, but I think you really hit the nail on the head. When we ask package authors to put upper bounds on their dependencies, what we are really doing is asking them to propagate information about _future_ incompatibilities back into the present. As none of us has access to future information [1], the upper bounds on our dependencies amount to a collection of bad guesses [2]. I think we should consider taking a more empirical approach [3]. One way (but certainly not the only way) to approach this would be to require packages to be uploaded to Hackage with a kind of "build-certificate," certifying that a successful build plan was possible given the state of Hackage at a particular timestamp. This allows us to infer minimal upper bounds for all of the package's transitive dependencies. Once the build-certificate is authenticated, Hackage only needs to store the latest timestamp of a successful build, so the overhead is very low. In this scheme, author-specified upper bounds would be relegated to ruling out known incompatibilities with already-released versions of dependencies. Of course, build failures will still occur. By using anonymous build-reporting to track the timestamp of the earliest failed build of a package, we can automatically infer the _true_ upper bounds on its dependencies. If contradictory reports occur, they can be resolved by the trustees or the package's maintainers. Just some food for thought. I hope the timing of my e-mail will not discourage anyone from taking my suggestions seriously. [1]. If I am mistaken and you think you do have access to future information, please respond privately; I have some questions for you about the stock market. [2]. If you've never had an upper bounds problem on a package you maintain, I'm happy for you, but there is mounting evidence that as a community, we are very bad guessers, on average. [3]. The PVP is orthogonal to this. It is a convenient set of assumptions and a reasonably good set of norms; nothing more. -- Thomas Tuegel