[Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends

Simon Marlow marlowsd at gmail.com
Mon Aug 20 15:24:56 CEST 2012

On 15/08/2012 21:44, Johan Tibell wrote:
> On Wed, Aug 15, 2012 at 1:02 PM, Brandon Allbery <allbery.b at gmail.com> wrote:
>> So we are certain that the rounds of failures that led to their being
>> *added* will never happen again?
> It would be useful to have some examples of these. I'm not sure we had
> any when we wrote the policy (but Duncan would know more), but rather
> reasoned our way to the current policy by saying that things can
> theoretically break if we don't have upper bounds, therefore we need
> them.

I haven't read the whole thread (yet), but the main motivating example 
for upper bounds was when we split the base package (GHC 6.8) - 
virtually every package on Hackage broke.  Now at the time having upper 
bounds wouldn't have helped, because you would have got a depsolver 
failure instead of a type error.  But following the uproar about this we 
did two things: the next release of GHC (6.10) came with two versions of 
base, *and* we recommended that people add upper bounds.  As a result, 
packages with upper bounds survived the changes.

Now, you could argue that we're unlikely to do this again.  But the main 
reason we aren't likely to do this again is because it was so painful, 
even with upper bounds and compatibility libraries.  With better 
infrastructure and tools, *and* good dependency information, it should 
be possible to do significant reorganisations of the core packages.

As I said in my comments on Reddit[1], I'm not sure that removing upper 
bounds will help overall.  It removes one kind of failure, but 
introduces a new kind - and the new kind is scary, because existing 
working packages can suddenly become broken as a result of a change to a 
different package.  Will it be worse or better overall?  I have no idea. 
  What I'd rather see instead though is some work put into 
infrastructure on Hackage to make it easy to change the depdendencies on 
existing packages.



More information about the Haskell-Cafe mailing list