The ^>= operator in .cabal files

[sclv]

@Bodigrim

it’s incompatible, in which case I must put foo >= X.Y-1 && < X.Y, because now I know that this is not a speculative bound.

I think that there should be a way to specify the intended meaning of caret such that this does not require a revision. There’s a monotonicity property we can use to guide this.

[Bodigrim]

@hasufell

So you agree that … hackage should actually reject packages without upper bounds? This is one of the possible solutions, but status quo is broken.

We are slowly moving into this direction: cabal check has recently started to warn on misssing upper bounds.

[hasufell]

@Bodigrim

But if I used a soft bound foo ^>= X.Y-1, I must make a revision in both cases. Either foo-X.Y is compatible, in which case I should write foo ^>= X.Y-1 || ^>= X.Y; or it’s incompatible, in which case I must put foo >= X.Y-1 && < X.Y, because now I know that this is not a speculative bound. Guaranteed busywork in both scenarios!

Those things are fine if there’s automation behind it (e.g. CI) and possibly a user interface that lets me click which bounds to update (not edit a 500LOC cabal file by hand in an online editor from the 90s).

Given that automation and user interface… not specifying defensive upper bounds might work the same way as well.

[arybczak]

FWIW cabal should warn about this, but this should never become a hard failure during hackage uploads, if only because it’s trivial to bypass it e.g. by setting missing upper bounds to < 10000.

[enlico]

In line with @chreekat’s comment, I don’t see why lower bounds and upper bounds should be treated particularly differently. Sure, the future is truly unknown, but the past can also be unknown for practical reasons, like “I don’t really want to spend time checking if my project builds with from such a package since the big-bang”.

So the difference between “I don’t know if it works with” and “I know it doesn’t work with” is relevant for both versions newer than the one I’m using, and older.

I like the ?

[andreasabel]

Well, the difference is that we have full information on the past (at least in our ideal digital world) bu not on the future.
The point you make about not spending the effort to find out the exact lower bounds is valid, but it wonder if speculative lower bounds have enough applications to be worth the language change.
My proposal is motivated by common practice, with use-cases recurring at each release of a new GHC or major bump in a library.