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