Hello all, I wanted to know what the status of the encapsulations feature in Cabal is. Presented in HIW'11, the intent was for it to be used to support private dependencies in Cabal. However, while this is was implemented in the modular solver, it looks like it was never wired up with Cabal proper. Andres, you mentioned you might be getting around to looking at this again? Since we have more fine-grained linker symbols in GHC HEAD, this feature ought to work better.
In any case, when I was reviewing the HIW'11, I realized that the semantics of encapsulations discussed there are not quite the ones you might actually want. In particular, there was an example where C encapsulates its dependency on B, but if C has another (non-encapsulated) dependency D which depends on B, now the global choice of B (witnessed through C.D.B) and C.B are required to be the same. However, it might also be useful for these two dependencies to still be different, even in this case. In particular, it may be useful to encapsulate a package *even if it shows up in the interface.* Such packages can be used for: - Building compatibility layers between multiple versions of a package (here, we want to build-depends on the same package multiple times, in an encapsulated way) - Using the encapsulations feature to represent Backpack style mix-ins, where packages with holes are considered encapsulated. (I'm not 100% this is the right way to go about implementing this, but it's one possibility). Cheers, Edward _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
