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

[Leon Smith]

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

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.   I believe this is more likely to
significantly improve the current situation than distinguishing the two
types of bound alone.   However,  being able to specify both (and change
both) after the fact may prove to be even better.

Best,
Leon

On Sat, Aug 18, 2012 at 11:52 PM, wren ng thornton <wren at freegeek.org>wrote:

> On 8/17/12 11:28 AM, Leon Smith wrote:
>
>> 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.
>>
>
> I disagree. A hard constraint says "this package *will* break if you
> violate me". A soft constraint says "this package *may* break if you
> violate me". These are vastly different notions of boundary conditions, and
> they have nothing to do with a proactive vs reactionary stance towards
> specifying constraints (of either type).
>
> The current problems of always giving (hard) upper bounds, and the
> previous problems of never giving (soft) upper bounds--- both stem from a
> failure to distinguish hard from soft! The current/proactive approach fails
> because the given constraints are interpreted by Cabal as hard constraints,
> when in truth they are almost always soft constraints. The
> previous/reactionary approach fails because when the future breaks noone
> bothered to write down when the last time things were known to work.
>
> To evade both problems, one must distinguish these vastly different
> notions of boundary conditions. Hard constraints are necessary for
> blacklisting known-bad versions; soft constraints are necessary for
> whitelisting known-good versions. Having a constraint at all shows where
> the grey areas are, but it fails to indicate whether that grey is most
> likely to be black or white.
>
> --
> Live well,
> ~wren
>
>
> ______________________________**_________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/**mailman/listinfo/haskell-cafe<http://www.haskell.org/mailman/listinfo/haskell-cafe>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120822/20cb90e3/attachment.htm>