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

[wren ng thornton]

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