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

On 2014-02-25 21:34, MightyByte 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

On Tue, Feb 25, 2014 at 4:16 PM, Vincent Hanquez wrote: 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