[Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
wren ng thornton
wren at freegeek.org
Sun Aug 19 05:52:09 CEST 2012
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.
More information about the Haskell-Cafe