3 ms·

It is more of a contract. The library author is stating this package was developed against these dependencies and versions. It is known to work well in these

It is more of a contract. The library author is stating this package was developed against these dependencies and versions. It is known to work well in these cases. This does not mean it will not compile. In fact often the fix is simply for the author or developer to relax the version bounds and everything will be fine. Lastly, many of these issues arise not because of a direct dependency but an indirect one. The problem is that GHC will not allow you to depend on two packages which themselves depend on different versions of the same package. Once this is fixed, along with sandboxing, will eliminate the vast majority of the cabal hell problem.

taeric 13y ago
I still feel you are being a touch unfair to the dynamic world. Many times, bringing in a dependency just works. The analogy I have in my mind is a digital computer for a bike. The general "contract" is simply that you will somehow get a pulse to the computer for each rotation of a tire with a known size. The details of how the bike is constructed are ultimately irrelevant. Further, because this is such a general contract, it doesn't actually matter if you hook it to the wheel or not. You can, in fact, use such a computer in a non bike device with success.
- tel 13y ago
  There's work to provide this "module by contract" notion you're talking about exactly (http://www.mpi-sws.org/~skilpat/backpack/ http://www.mpi-sws.org/~skilpat/backpack/) but it's very new and far from implementation. OCaml does a good job of this and is usually the poster child for parametric modules done right. That said, dynamic languages allow this kind of contractual module imputation by the virtue of allowing absolutely anything to be considered a module and hashed out at runtime. At the least this means carrying around a lot of tagging/runtime typing information so you can call up runtime errors. At the most, it means that your whole system is held together by an increasingly wide set of unchecked and uncheckable assumptions. Cabal hell is annoying but at least it's checking.

taeric 13y ago

I still feel you are being a touch unfair to the dynamic world. Many times, bringing in a dependency just works. The analogy I have in my mind is a digital computer for a bike. The general "contract" is simply that you will somehow get a pulse to the computer for each rotation of a tire with a known size. The details of how the bike is constructed are ultimately irrelevant. Further, because this is such a general contract, it doesn't actually matter if you hook it to the wheel or not. You can, in fact, use such a computer in a non bike device with success.

tel 13y ago
There's work to provide this "module by contract" notion you're talking about exactly (http://www.mpi-sws.org/~skilpat/backpack/ http://www.mpi-sws.org/~skilpat/backpack/) but it's very new and far from implementation. OCaml does a good job of this and is usually the poster child for parametric modules done right. That said, dynamic languages allow this kind of contractual module imputation by the virtue of allowing absolutely anything to be considered a module and hashed out at runtime. At the least this means carrying around a lot of tagging/runtime typing information so you can call up runtime errors. At the most, it means that your whole system is held together by an increasingly wide set of unchecked and uncheckable assumptions. Cabal hell is annoying but at least it's checking.