We do have, although not with easy access, an additional declarative layer "built in" 90% of the time as configuration as type signature. An autoconf style approach to this where each type signature dependency is declared seperately would be needlessly complex and painful. However, there is room for a fruitful middle ground. Thanks to Hackage, at least for those packages that build properly and haddock on it, we have, although not in the best format, information on the type signatures of the functions of packages, across various package versions. So if I, when writing a cabal script, don't particularly want to figure out the exact range of, e.g., Network, packages that provide the correct API, it would be fairly reasonable to statically determine which functions from the Network package that are called, and which versions of Network on hackage provide them, and with the appropriate types no less. Thus, given that we need "Network," a tool could determine what the correct allowable range of versions is, and thus avoid both over- and under- specification. This same tool could be run over existing .cabal files on hackage, statically determining when they are likely to either over- or under- specify, and alerting package maintainers to this. --Sterl. On Aug 28, 2008, at 10:02 AM, 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]
Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users