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

[Vincent Hanquez]

On 2014-02-25 21:34, MightyByte wrote:
> On Tue, Feb 25, 2014 at 4:16 PM, Vincent Hanquez <tab at snarc.org> wrote:
>> If you're going to dig an old ghc version, what's stopping you from
>> downloading old packages manually from hackage ? I'm sure it can even be
>> automated (more or less).
> It's much more difficult because the scale is much greater.  Also, if
> people aren't putting in version bounds, then you have no clue what
> versions to try.  Leaving out version bounds is throwing away
> information.
I'm not saying this is not painful, but i've done it in the past, and 
using dichotomy and educated guesses (for example not using libraries 
released after a certain date), you converge pretty quickly on a solution.

But the bottom line is that it's not the common use case. I rarely have 
to dig old unused code.
>> However, I don't think we should optimise for this use case; I'ld rather use
>> maintained packages that are regularly updated.
> When I write code and get it working, I want it to work for all time.
> There's absolutely no reason we shouldn't be able to make that happen.
>   If we ignore this case, then Haskell will never be suitable for use
> in serious production situations.  Large organizations want to know
> that if they start using something it will continue to work.  (And
> don't respond to this with the "avoid success at all costs" line.
> Haskell is now mature enough that I and a growing number of other
> people use Haskell on a daily basis for mission-critical
> applications.)

This is moot IMHO. A large organisation would *not* rely on cabal, nor 
the PvP to actually download packages properly:
Not only this is insecure, and as Michael mentioned, you would not get 
the guarantee you need anyway.

Even if the above wasn't an issue, Haskell doesn't run in a bubble. I 
don't expect old ghc and old packages to work with newer operating 
systems and newer libraries forever.

>> Furthermore, some old libraries should not be used anymore. Consider old
>> libraries that have security issues for example. Whilst it's not the intent,
>> It's probably a good thing that those old libraries don't build anymore, and
>> people are forced to move to the latest maintained version.
> This argument does not hold water when getting a legacy piece of code
> working has significant intrinsic value.  There are plenty of
> situations where code can have great value to a person/organization
> even if it doesn't touch the wild internet.
Sure, in this case it doesn't apply to my "security issue" example, does 
it ?

-- 
Vincent