Configurations proposal

[Duncan Coutts]

On Sun, 2006-10-29 at 10:55 +0200, Einar Karttunen wrote:
> On 26.10 15:49, Duncan Coutts wrote:
> > Yes, if we were to not allow changing the exposed modules then people
> > could achieve the same effect using CPP.
> 
> Can we agree at least on a subset of the functionality to make the
> simple cases work. It seems to me that there are two real design
> issues:
> 
> * Should the clist/flist specification be a simple pure functional
>   language *or* a constraint solving one.
> 
> * How much should we try to protect users from evil package writers
>   with wrong ideas how to package things. 

We do have to bear in mind how hard it'll be for cabal-get to be able to
do dependency analysis. The decisions we make about optional
configurations has a big impact on this. It also has a big effect on how
easy it is to make 'native' packages for distros which typically don't
have extremely sophisticated dependency systems.

There's also the important issue of binary packages. We're all used to
building from source which gives us a lot of flexibility, but most users
expect binary packages. For example Debian and most other commercial
distros and Windows of course. It is important that we be able to make
sensible binary packages. If the configuration language encourages
package authors to go too crazy and one would need 2^n different binary
packages then I'd say that we've failed.

Remember that the main use case of configurations is just to cope with
minor things like modules moving from one package to another or slight
differences in the way things are implemented on different platforms or
Haskell implementations.

> Personally I prefer functional semantics and keeping things simple
> rather than trying to limit the language because of the things
> package writers could do with it.

Of course we're doing this already with the split between flags and not
allowing 'available' tests in the configuration guards. This is exactly
to make it impossible to express certain wrong packaging ideas.

I'm much less concerned about whether the exposed modules should be
changeable in configuration stanzas.

Though again, we should bear in mind things like binary packages.

> A third issue is syntax - but this is not so important. All the ideas
> on the list have seemed fine, but if we go the functional way we could
> just make it a subset of Haskell with (==), (&&), (||), not, and Bool
> and String literals.

I don't mind. Propose something concrete.

Duncan