Just thinking  aloud:<div><br></div><div>What if  we add  &quot;-current&quot;  ?</div><div><br></div><div>pacage -current </div><div><br></div><div>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</div>

<div><br></div><div>If the cabal file is local then current == any.</div><div><br></div><div>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.</div>

<div><br></div><div>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</div><br class="Apple-interchange-newline">

<br><div class="gmail_quote">2012/8/24 wren ng thornton <span dir="ltr">&lt;<a href="mailto:wren@freegeek.org" target="_blank">wren@freegeek.org</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On 8/22/12 12:35 PM, David Menendez wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As I see it, there are four possibilities for a given version of dependency:<br>
<br>
1. The version DOES work. The author (or some delegate) has compiled<br>
the package against this version and the resulting code is considered<br>
good.<br>
2. The version SHOULD work. No one has tested against this version,<br>
but the versioning policy promises not to break anything.<br>
3. The version MIGHT NOT work. No one has tested against this version,<br>
and the versioning policy allows breaking changes.<br>
4. The version DOES NOT work. This has been tested and the resulting<br>
code (if any) is considered not good.<br>
<br>
Obviously, cases 1 and 4 can only apply to previously released<br>
versions. The PVP requires setting upper bounds in order to<br>
distinguish cases 2 and 3 for the sake of future compatibility.<br>
Leaving off upper bounds except when incompatibility is known<br>
essentially combines cases 2 and 3.<br>
</blockquote>
<br></div>
Right-o.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So there are two failure modes:<br>
<br>
I. A version which DOES work is outside the bounds (that is, in case<br>
3). I think eliminating case 3 is too extreme. I like the idea of<br>
temporarily overriding upper bounds with a command-line option. The<br>
danger here is that we might actually be in case 4, in which case we<br>
don&#39;t want to override the bounds, but requiring an explicit override<br>
gives users a chance to determine if a particular version is<br>
disallowed because it is untested or because it is known to be<br>
incompatible.<br>
</blockquote>
<br></div>
There are two failure modes with overriding stated bounds, however. On the one hand, the code could fail to compile. Okay, we know we&#39;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&#39;re actually in case 4, but the user does not know this. This is why it&#39;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.<br>


<br>
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&#39;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&#39;ll do so in an informed way.<div class="HOEnZb">

<div class="h5"><br>
<br>
-- <br>
Live well,<br>
~wren<br>
<br>
______________________________<u></u>_________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Alberto.<br>