<div dir="ltr"><div><br></div>Here are some examples:<div><div><br></div><div>---------------------------------------------<br></div><div>data Foo = Bar | Baz</div><div><br></div><div>instance Eq Foo where</div><div>  _ == _ = True</div>

<div><br></div><div>instance Ord Foo where</div><div>  compare Bar Bar = EQ</div><div>  compare Bar Baz = LT<br></div><div>  compare _   _   = error &quot;I&#39;m partial!&quot;</div></div><div>---------------------------------------------</div>

<div><br></div><div>These would allow LVish&#39;s &quot;runPar&quot; to non-determinstically return Bar or Baz (thinking they&#39;re the same based on Eq).  Or it would allow runPar to nondeterministically crash based on different schedulings hitting the compare error or not [1].</div>

<div><br></div><div>FYI here&#39;s LVish:</div><div><br></div><div>    <a href="http://www.cs.indiana.edu/~rrnewton/haddock/lvish/">http://www.cs.indiana.edu/~rrnewton/haddock/lvish/</a></div><div>    <a href="https://github.com/iu-parfunc/lvars">https://github.com/iu-parfunc/lvars</a></div>

<div>    </div><div>(More info in this POPL paper: <a href="http://www.cs.indiana.edu/~rrnewton/papers/2013_07_LVish_quasiDet_working_draft.pdf">http://www.cs.indiana.edu/~rrnewton/papers/2013_07_LVish_quasiDet_working_draft.pdf</a>)</div>

<div><br></div><div>   -Ryan</div><div><br></div><div class="gmail_extra">[1] If you&#39;re curious why this happens, its because the Ord instance is used by, say, Data.Set and Data.Map for the keys.  If you&#39;re inserting elements in an arbitrary order, the final contents ARE deterministic, but the comparisons that are done along the way ARE NOT.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 1, 2013 at 4:13 PM, Ryan Newton <span dir="ltr">&lt;<a href="mailto:rrnewton@gmail.com" target="_blank">rrnewton@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hello all,<div><br></div><div>Normally, we don&#39;t worry *too* much about incorrect instances of standard classes (Num, Eq, Ord) etc.  They make the user&#39;s program wrong, but they don&#39;t compromise the type system.</div>


<div><br></div><div>Unfortunately, with the LVish parallel programming library we do have a situation where incorrect instances of Eq and Ord can cause the &quot;types to lie&quot;.  In particular, something that claims to be a pure, non-IO type, can actually yield a different result on different runs, including throwing exceptions on some runs but not others.</div>


<div><br></div><div>So what&#39;s the best way to lock down &quot;SafeEq&quot; and &quot;SafeOrd&quot; instances, taking control away from the user (at least with -XSafe is turned on)? </div><div><br></div><div>We could derive our own SafeEq and SafeOrd instances based on GHC.Generics.  BUT, that only helps if we can forbid the user from writing their own incorrect Generics instances when Safe Haskell is turned on.  It looks like GHC.Generics is currently marked as &quot;TrustWorthy&quot;:</div>


<div><br></div><div>    <a href="http://www.haskell.org/ghc/docs/7.4.1/html/libraries/ghc-prim-0.2.0.0/GHC-Generics.html" target="_blank">http://www.haskell.org/ghc/docs/7.4.1/html/libraries/ghc-prim-0.2.0.0/GHC-Generics.html</a><br>

</div>
<div><br></div><div>So.... could we get GHC.Generics marked as &quot;Unsafe&quot; and enable some more limited interface that is &quot;Trustworthy&quot;?  (Allowing the user ONLY to do &#39;deriving Generic&#39;).</div><div>


<br></div><div>This would be similar to the new policy in GHC 7.8 of only allowing derived Typeable instances...</div><span class=""><font color="#888888"><div><br></div><div>  -Ryan</div><div><br></div></font></span></div>


</blockquote></div><br></div></div>