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

[Edward Kmett]

On Tue, Feb 25, 2014 at 10:16 AM, Brandon Allbery <allbery.b at gmail.com>wrote:

> On Tue, Feb 25, 2014 at 2:21 AM, Sven Panne <svenpanne at gmail.com> wrote:
>
>> Regarding upper bounds: I never understood what their advantage should
>> be, IMHO they only lead to a version hell where you can't compile your
>> stuff anymore *only* because of the bounds, not because of anything
>> else.
>>
>
> A couple months ago we had yet another example of "that will never happen"
> caused by people ignoring upper bounds. Developers never saw any problem,
> of course; and who cares about all the users who had compiles explode with
> unexpected errors? I think it took less than two weeks after someone
> patched up the most visibly affected packages before developers were
> shouting to remove upper bounds from the PVP again, because the affected
> users are just users and apparently not important enough to consider when
> setting versioning policy.
>

I tried living without upper bounds. My attempt was not motivated out of
disdain for users, but from the fact that all of the complaints I had had
had been about the opposite, constraints that were too tight. The change
was motivate largely by a desire to *improve* end user experience.

However, after removing the bounds, the situations users wound up in were
very hard to fix. From a POSIWID perspective, the purpose of removing upper
bounds is to make Haskell nigh unusable without sandboxing or --force.

Consequently, I reverted to PVP compliance within a month. Yes, compliance.
Despite Henning's attempt to grab the moral high ground there, the PVP does
not *require* the use of qualified imports to depend on minor versions, it
merely indicates that doing so is a slight risk.

To minimize breakage when new package versions are released, you can use
> dependencies that are insensitive to minor version changes (e.g. foo >=
> 1.2.1 && < 1.3). However, note that this approach is slightly risky: when
> a package exports more things than before, there is a chance that your code
> will fail to compile due to new name-clash errors. The risk from new name
> clashes may be small, but you are on the safe side if you import
> identifiers explicitly or using qualification<http://www.haskell.org/haskellwiki/Import_modules_properly>
> .


-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140225/5c220e96/attachment.html>