suggestion for a small extension to configurations

[Duncan Coutts]

On Mon, 2007-11-05 at 12:17 +0000, Ross Paterson wrote:

> Your examples use base, for which there will be only one version in a GHC
> installation.  But there might be multiple versions of other packages,
> so testing on them is a bit more complicated.
> 
> How does a repackager control the selection? 

I was hoping they would not have to. In fact that was rather the point,
that this package predicate should identify a special case where a user
visible flag is not necessary.

> (On the other hand, it may be that flags are to coarse a control for
> them anyway; they might want to specify versions or version ranges
> too.)

There is certainly a case to be made for a user/packager wanting to
throw in additional constraints, like bytestring <= 0.9 when they have
bytestring-1.0 available. Indeed just for testing purposes it's useful
to be able to control which version of a package is chosen when there
are several possible (satisfiable) choices.

> > So we still introduce a backtracking point, it's just that now it's
> > backtracking without a named flag. This is ok because the decision about
> > which branch to take is completely determined once the environment picks
> > a version for the dependent package in question.
> 
> If this is just sugar for flags, won't it still backtrack just as much?

Yes. I was confused.

Can anyone see a rationale in putting these extra generated flags last?
It does change the order in which we explore the space of flag
assignments. Given the restricted form of constraints that package
predicates give rise to, should we put the extra flags first or last?
(first/last wrt to any other explicitly declared flags)

> Also, when one branches on a flag, the first alternative is preferred
> if both work. Presumably this will still be the case, so one might
> sometimes have to write an inverted test with an empty then-branch.

Yes, or if you need something special you can use the existing flag
syntax I guess.

Duncan