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

[Daniel Trstenjak]

Hi Michael,

> (b) having the longer name will allow the unqualified import approach ...

The longer name just reduces the possibility of conflicts, which might
be already sufficient and in the case of 'zeroBits' it might be really
the right thing.

I think the point of proponents of qualified imports is, that by having
'Bits.zero' instead of 'zeroBits' you're typing almost the same amount
of characters, but the first solution is safer. 

I don't think that anybody would like to write 'Bits.zeroBits', sure you
could still explicitly import 'zeroBits' and still have the same safety,
but then you have more work with the imports, and at the end nobody 
wants to do more work and this seems to be the common ground of users
and non users of qualified imports ;).

> But that's only one half of the "package interoperability" issue. I face this
> first hand on a daily basis with my Stackage maintenance. I spend far more time
> reporting issues of restrictive upper bounds than I do with broken builds from
> upstream changes. So I look at this as purely a game of statistics: are you
> more likely to have code break because version 1.2 of text changes the type of
> the map function and you didn't have an upper bound, or because two
> dependencies of yours have *conflicting* versions bounds on a package like
> aeson[2]? In my experience, the latter occurs far more often than the former.

I mostly came to the conclusion, that the PVP is perfectly fine for
binaries/executables, especially in conjunction with a cabal sandbox,
but in a lot of cases annoying for libraries.


Greetings,
Daniel