On Thu, 2006-08-10 at 19:31 +0300, Einar Karttunen wrote:
> Hello
>> There was a discussion about the semantics of the package
> dependencies on #haskell. Continuing here for clarity.
>> build-depends: foo > 1 && < 3
> vs
> build-depends: foo > 1, foo < 3
>> and the same with configuration stuff:
>> packages(foo >1 && < 3)
> vs
> packages(foo > 1) && packages(foo < 3)
>>> Current Cabal and the configurations patch interpret these as:
> * "packages(foo >1 && < 3)"
> * there exists a package foo such that the version is >1 and <3
>> * "packages(foo > 1) && packages(foo < 3)"
> * there exists a package foo such that the version is >1 *and*
> * there exists a package foo such that the version is <3
>> This means that the semantics are very simple, each package
> and depend can be handled in isolation. This has not caused
> problems but should be documented more clearly.
>> The alternative solution is to make package names have
> per-configuration and per-build-depend-line specific scope
> and add an environment to the semantics. This would eliminate
> a class of errors, but on the other hand make reasoning
> about the semantics harder.
Isn't the semantics quite simple:
for each package mentioned in build depends, a candidate package must
satisfy all constraints.
for the current implemented semantics it's:
for each dependency there must exist a candidate package that satisfies
it.
So "build-depends: foo > 1, foo < 3" means linking with foo twice (and
possibly different versions)! This seems like nonsense. If that's what
it means then it should be an error condition with a helpful message to
use "build-depends: foo > 1 && < 3" instead.
Similarly if we go with "packages(foo >1 && < 3)" meaning something
different from "packages(foo > 1) && packages(foo < 3)" then is the
latter not simply an error?
Duncan