On Thu, 2008-08-28 at 15:02 +0100, Simon Peyton-Jones wrote:
| Yes this means that Cabal is less general than autoconf. It was quite a | revelation when we discovered this during the design of Cabal - originally | we were going to have everything done programmatically in the Setup.hs | file, but then we realised that having the package configuration available | *as data* gave us a lot more scope for automation, albeit at the expense of | some generality.
Now there's a useful insight for the paper I hope Duncan (or someone) is going to write
configuration as code [autoconf] vs configuration as data [cabal]
and there are more fine distinctions even than that. Each change in the power of the language used for configuration changes the range of things that the developer and packager/user can do, and in opposite directions. It's fairly similar to the tradeoffs between deep and shalow embeddings, but I think we more intermediate points. The challenge is in characterising the relationship between the language and the things the developer and packager can do so that we can pick a useful point (or points) in that tradeoff. Before anyone thinks about writing a paper on this topic, I recommend you read all of Eelco's papers[1] first just to make sure he's not already done it! :-) Which is another point that there's lots that Cabal (and ghc) can learn from Nix and related stuff. Duncan [1] http://nixos.org/docs/papers.html