On 8/22/12 9:18 AM, Leon Smith wrote:
I think we actually agree more than we disagree; I do think distinguishing hard and soft upper bounds (no matter what they are called) would help, and I'm just trying to justify them to some of the more dismissive attitudes towards the idea
Hopefully. Though you suggested conflating the hard/soft distinction and the reactive/proactive distinction, and I can't see how that would even make sense. The former is a matter of ontology (i.e., categorization of what things can/do/should exist), whereas the latter is a matter of policy (i.e., how people can/do/should behave). Clearly there's some relation between the two, but the distinctions are talking about completely different topics.
The only thing I think we (might) disagree on is the relative importance of distinguishing hard and soft bounds versus being able to change bounds easily after the fact (and *without* changing the version number associated with the package.) And on that count, given the choice, I pick being able to change bounds after the fact, hands down.
Well sure, just updating Cabal to say it has soft upper bounds doesn't mean much unless they're actually overridable somehow ;)
I'm still dubious of being able to override hard bounds with a commandline flag. If the hard bound is valid then when you pass the flag to ignore the bound either (a) the code won't compile ---so the flag doesn't help any---, or (b) the code will compile in a way known to be silently wrong/buggy ---so the flag is evil. Circumventing a (valid) hard bound is going to require altering the code, so what benefit is there in avoiding to alter the .cabal file at the same time?
The only case I can conceive of it being helpful to circumvent a hard bound is if, in fact, the statement of the hard bound is incorrect. But, if that's the case, it's a bug; and surely correcting that bug should warrant nudging the fourth version number, ne? Also, this situation doesn't strike me as being common enough to warrant the effort of implementation. If it came for free from whatever work it takes to implement soft bounds (which must necessarily be overridable), I wouldn't really care. But if eliminating this burden would help in getting soft bounds implemented, then I see no downside to axing it.
-- Live well, ~wren _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
