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

[Alberto G. Corona]

Just thinking  aloud:

What if  we add  "-current"  ?

pacage -current

Would select the versions of the package that were current art the time the
cabal file was uploaded and sucessfully compiled in hackage,  if the packae
is installed from hackage

If the cabal file is local then current == any.

This option would eliminate the need to guess bounds for package
dependencies. It would also give more guaranties that the package will
compile sucessfully when downloaded from hackage.

Certainly,it would not guarantee it if your version of ghc differs from the
one in Hackage, but it would make things more simple and would reduce the
spectrum of possible failures


2012/8/24 wren ng thornton <wren at freegeek.org>

> On 8/22/12 12:35 PM, David Menendez wrote:
>
>> As I see it, there are four possibilities for a given version of
>> dependency:
>>
>> 1. The version DOES work. The author (or some delegate) has compiled
>> the package against this version and the resulting code is considered
>> good.
>> 2. The version SHOULD work. No one has tested against this version,
>> but the versioning policy promises not to break anything.
>> 3. The version MIGHT NOT work. No one has tested against this version,
>> and the versioning policy allows breaking changes.
>> 4. The version DOES NOT work. This has been tested and the resulting
>> code (if any) is considered not good.
>>
>> Obviously, cases 1 and 4 can only apply to previously released
>> versions. The PVP requires setting upper bounds in order to
>> distinguish cases 2 and 3 for the sake of future compatibility.
>> Leaving off upper bounds except when incompatibility is known
>> essentially combines cases 2 and 3.
>>
>
> Right-o.
>
>
>
>  So there are two failure modes:
>>
>> I. A version which DOES work is outside the bounds (that is, in case
>> 3). I think eliminating case 3 is too extreme. I like the idea of
>> temporarily overriding upper bounds with a command-line option. The
>> danger here is that we might actually be in case 4, in which case we
>> don't want to override the bounds, but requiring an explicit override
>> gives users a chance to determine if a particular version is
>> disallowed because it is untested or because it is known to be
>> incompatible.
>>
>
> There are two failure modes with overriding stated bounds, however. On the
> one hand, the code could fail to compile. Okay, we know we're in case 4;
> all is well. On the other hand the code could successfully compile in ways
> the package designer knows to be buggy/wrong; we're actually in case 4, but
> the user does not know this. This is why it's problematic to simply allow
> overriding constraints. The package developer has some special knowledge
> that the compiler lacks, but if all constraints are considered equal then
> the developer has no way to convey that knowledge to the user (i.e., in an
> automated machine-checkable way). Consequently, the user can end up in a
> bad place because they thought this second failure mode was actually the
> success mode.
>
> This is why I advocate distinguishing hard constraints from soft
> constraints. By making this distinction, the developer has a means of
> conveying their knowledge to users. A soft bound defines an explicit
> boundary between case 1 and cases 2--4, which can be automatically (per
> PVP) extended to an implicit boundary between cases 1--2 and cases 3--4; a
> boundary which, as you say, can only be truly discovered after the code has
> been published. Extending soft boundaries in this way should be safe; at
> least it's as safe as possible with the foresight available to us. On the
> other hand, a hard bound defines an explicit boundary between case 4 and
> cases 1--3. If these are overridable, things may break silently as
> discussed above--- but the important thing is, in virtue of distinguishing
> hard and soft bounds, the user is made aware of this fact. By
> distinguishing hard and soft bounds, the developer can convey their special
> knowledge to the user. The user can ignore this information, but at least
> they'll do so in an informed way.
>
>
> --
> 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>
>



-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120923/7e0ee7f3/attachment.htm>