What if instead of upper (and lower) bounds we just specify our interface requirements? Like "package bull-shit should provide value Foo.Bar.baz :: forall a. [a] -> [a] -> [a] or more general". Sure, it won't help dealing with strictness/lazyness, but it would capture most interface differences. And, in case the requirements aren't specified, we could also specify the default, like "bool-shit 2.0 is known to fulfil this requirement; if yours doesn't, consider installing this one".
On Aug 17, 2012, at 7:28 PM, Leon Smith <leon.p.sm...@gmail.com> wrote: > I see good arguments on both sides of the upper bounds debate, though at the > current time I think the best solution is to omit upper bounds (and I have > done so for most/all of my packages on hackage). But I cannot agree with > this enough: > > On Thu, Aug 16, 2012 at 4:45 AM, Joachim Breitner <m...@joachim-breitner.de> > wrote: > I think what we’d need is a more relaxed policy with modifying a > package’s meta data on hackage. What if hackage would allow uploading a > new package with the same version number, as long as it is identical up > to an extended version range? Then the first person who stumbles over an > upper bound that turned out to be too tight can just fix it and upload > the fixed package directly, without waiting for the author to react. > > I think that constraint ranges of a given package should be able to both be > extended and restricted after the fact. Those in favor of the reactionary > approach (as I am at the moment, or Bryan O'Sullivan) would find the ability > of to restrict the version range useful, while those in favor of the > proactive approach (like Joachim Breitner or Doug Beardsley) would find the > ability to extend the version range useful. > > I suspect that attitudes towards upper bounds may well change if we can set > version ranges after the fact. I know mine very well might. And the > difference between reactionary and proactive approaches I think is a > potential justification for the "hard" and "soft" upper bounds; perhaps we > should instead call them "reactionary" and "proactive" upper bounds instead. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
