Build system idea

[Sterling Clover]

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 at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users