qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method)

[Yitzchak Gale]

Michael Snoyman wrote:
>> I still have some concerns about the PVP's stance on a few issues, namely:
>>
>> 1. The upper bounds on non-upgradable packages, which I've raised elsewhere
>> in this thread.
>> 2. The lack of flexibility in interpretation. I think there's a qualitative
>> difference between depending on the text package by simply importing
>> Data.Text (Text), versus using some experimental features of a version 0.1
>> library.
>>
>> So I suppose if those points were addressed, a lot of my PVP skepticism
>> would disappear, and I'd be more inclined to coming back into the fold, so
>> to say.
>>
>> My question is: am I alone in thinking these are in fact issues with the
>> PVP?

Roman Cheplyaka wrote:
> No, you're not alone. And here are two other issues with PVP and upper
> bounds:
> http://ro-che.info/articles/2013-10-05-why-pvp-doesnt-work.html

I appreciate those concerns, but they are all concerns about
being able to build packages, not about the semantics of the PVP.

Trouble with building is being addressed by improvements in cabal,
combining better algorithms with better quick and easy ways
to intervene manually. I now find that even when thing go very wrong -
complex dependency SATs, errors in package versions or dependency
bounds in other people's packages, etc. - I can usually get a successful
build quite quickly, and I hope this will only continue to improve.

I agree 100% with Michael's #2 - dependency bounds ranges are a way
of expressing the package author's best assessment of what is needed,
and what will likely be needed in the foreseeable future, for the package
to build. They don't need to follow any hard and fast rules. But yes,
an upper bound is called for in most cases.

Roman is right that it is important for package authors to do the
best they can to support the latest versions of their dependencies.
But even when they do that, upper bounds are not useless. They are
important for people using your packages who need to support
a product version over time. And they are important semantic
information that you can easily make available for use by
current and future build tools.

Thanks,
Yitz