Henning Thielemann
Having sub-packages is also one thing I need, but your example is one where I think that sub-packages are the wrong approach. Uploading the imported package (the binary decision diagram one) to hackage.haskell.org and including it (in the symbolic model checker) with the concrete version number is the better way.
The developer in my hypothetical symbolic model checker example decided to include a specific version of a binary decision diagram package within his system, just as the developers of NuSMV decided to incorporate CUDD into their distribution. You cannot second guess his/her decision. You should assume the developer knows about hackage.haskell.org, and chose not to use it, say for legal reasons. I cannot help but observe that I have received several answers on this list that show a distrust in wishes of Cabal users. Instead of addressing the needs given by the question, some of the answers are of the form: you shouldn't be doing that, followed by a tortured method for cramming the problem into the existing set of abstractions. The point of the questions is to get people to reassess the set of abstractions.
Recently, when I discovered there is no direct support for linking the executables in a package with the library it defines,
You can define executables in a package which are automatically build - however Cabal will recompile the imported modules instead of using the compiled ones from the library part.
In a previous note, I showed how to get around this deficiency in Cabal using hook functions. With more use, I have since refined the code I sent to the list. If anyone wants the improved version, I'll send it to you. By the way, I think it is a tribute to the Cabal design, and the hook design in particular, that it was so easy for me to fix the problem using public interfaces, and just a small amount of code and effort.
I wondered why the advice was to separate the library and the executables into two packages even though both are meant to be used and distributed as a unit.
As far as I know the future plan is to split Cabal projects into library and executable parts and then to allow also multiple library parts. This way you could provide parts for special applications or different operating systems.
Please do not drop support for packaging a library with executables build on top of the library. The hook function hack noted above allows me to make it so that Cabal serves my needs, and one package can be used to distribute my system as a single unit.
Does Cabal not support things like packages within a package simply because Haskell libraries currently are not complex enough to require such a feature, or is there a guiding design principle with which these features are incompatible?
It was requested several times but it seems not to be designed and implemented so easily.
I bet it's easier than you think. You just have to dynamically generate package configuration files, just as I did to resolve my linking problem. John