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

[Henning Thielemann]

Am 24.02.2014 20:56, schrieb Edward Kmett:

> As far as I know the only serious proponent of using qualified imports
> for all imports /all/ the time is you.

First, there are some important packages like containers and bytestring 
that clearly are intended for qualified imports, and I really like that 
insertFM was replaced by Map.insert in the past. Second, your argument 
addresses a person not the issue.

> Name conflicts don't affect you. We get that. We got that loud and clear
> virtually every time the naming of pretty much anything has arisen on
> this mailing list for the last few years.

Sure, because there is no general discussion about the pros and cons of 
various naming styles. That's why it is discussed for every single 
identifier. How should a general discussion look like? What could be its 
outcome? That I am no longer allowed to propose the qualified import style?

> That doesn't change the fact that your practice and common practice diverge.

And I challenge the common practice, because it prefers convenience for 
few package authors over convenience for many package user (that may not 
even be a Haskell programmer).

For an example let me look at your lens package. You use unqualified and 
implicit imports. That is according to the PVP you would need to use 
tight version bounds like "containers >=0.4.0 && <0.5.0.1", but you 
don't. That is, your package does not conform to the PVP. It implies 
that users may have to fix your package when one of the imported 
packages starts to export identifiers that clash with those from "lens". 
Of course, there is no need to conform to the PVP. But it works best if 
many people adhere to it.

I have not written the PVP, that is, there must be at least one other 
person who cares. I understand the need for it and try to comply to it. 
Maybe I am in a minority. Looking at Hackage it seems I am in a 
minority. But I believe I am in the minority who cares whether packages 
work together. Shall I capitulate to the majority which does not seem to 
care about package interoperability?

I am also ok if sloppy common practice happens in many Hackage packages. 
I do not need to use them. But I need to use 'base'.