<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Thanks a lot Richard!<br>
</p>
<div class="moz-cite-prefix">Le 25/10/2021 à 23:02, Richard
Eisenberg a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:010f017cb9434d5c-1400f594-ee8e-41c9-b1be-dc86b7ad64d3-000000@us-east-2.amazonses.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
I will also offer my own counter-proposal to
intrinsic-superclasses, at <a
href="https://gitlab.haskell.org/ghc/ghc/-/wikis/instance-templates"
class="moz-txt-link-freetext" moz-do-not-send="true">https://gitlab.haskell.org/ghc/ghc/-/wikis/instance-templates</a>.
<div class=""><br class="">
</div>
<div class="">These all predate our current proposals process.</div>
<div class=""><br class="">
</div>
<div class="">I believe they were all conceived to solve the
Applicative/Monad problem (for those of you who weren't around
then: Applicative was not always a superclass of Monad), and I'm
not sure they will work perfectly here: we might need to make a
new class, say, Equality and keep the current Eq as a subclass.</div>
<div class=""><br class="">
</div>
<div class="">Do look at the proposals, but your mileage may vary.</div>
<div class=""><br class="">
</div>
<div class="">Richard<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Oct 25, 2021, at 4:50 PM, Hécate <<a
href="mailto:hecate@glitchbra.in"
class="moz-txt-link-freetext" moz-do-not-send="true">hecate@glitchbra.in</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<div class="">
<p class="">There are the DefaultSuperclassInstances and
Intrinsic Superclasses which aim to provide
in-compiler support for such transitions:<br class="">
<br class="">
<a class="moz-txt-link-freetext"
href="https://gitlab.haskell.org/ghc/ghc/-/wikis/intrinsic-superclasses"
moz-do-not-send="true">https://gitlab.haskell.org/ghc/ghc/-/wikis/intrinsic-superclasses</a><br
class="">
<br class="">
But also code-modding would benefit from being used
here, and maybe retrie (<a
class="moz-txt-link-freetext"
href="https://hackage.haskell.org/package/retrie"
moz-do-not-send="true">https://hackage.haskell.org/package/retrie</a>)
<br class="">
would benefit from being used at scale?<br class="">
<br class="">
<br class="">
</p>
<div class="moz-cite-prefix">Le 25/10/2021 à 19:05, Ryan
Trinkle a écrit :<br class="">
</div>
<blockquote type="cite"
cite="mid:7D6D4326-4D9E-4F9B-B7BB-D12592B4238D@trinkle.org"
class="">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8" class="">
Is there a language feature that could be built that
would reduce the cost of inter-package refactors like
this in the future?<br class="">
<br class="">
<div class="gmail_quote">On October 25, 2021 4:06:46
PM UTC, "Hécate" <a class="moz-txt-link-rfc2396E"
href="mailto:hecate@glitchbra.in"
moz-do-not-send="true"><hecate@glitchbra.in></a>
wrote:
<blockquote class="gmail_quote" style="margin: 0pt
0pt 0pt 0.8ex; border-left: 1px solid rgb(204,
204, 204); padding-left: 1ex;">
<pre dir="auto" class="k9mail">Hi Joachim :)
I will have to express a friendly but firm disagreement on the argument of a
"one time cost".
You will also have to open PRs for every library, change pedagogical
material,
broadcast those changes to developers, and provide scripts for code-modding
tools in order to automate this on proprietary codebases.
Side-proposal
If you really want to break a bunch of things and fix mistake of the past,
I would suggest to really go for the throat and have PartialEq,
PartialOrd, Eq, and Ord
We could finally get rid of the Eq instance for the various IEEE types
like Double, and promote
property testing to the wider public to verify that the laws are indeed
respected by the implementations.
module NewClasses where
import Prelude hiding (Eq(..), Ord(..))
-- | Equality comparisons which are partial equivalence relations.
class PartialEq a where
(==) :: a -> a -> Bool
-- | Equality comparisons which are equivalence relations.
-- It is laws-only and manual implementations would be
-- verified through property testing.
class PartialEq a => Eq a
-- | Partial order
class PartialEq a => PartialOrd a where
compare' :: a -> a -> Maybe Ordering
(<) :: a -> a -> Bool
(<=) :: a -> a -> Bool
(>) :: a -> a -> Bool
(>=) :: a -> a -> Bool
-- | Total order
class (PartialOrd a, Eq a) => Ord a where
compare :: a -> a -> Ordering
max :: a -> a -> a
min :: a -> a -> a
Cheers,
Hécate
Le 25/10/2021 à 15:22, Joachim Breitner a écrit :
<blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Hi,
ah, yes, let me summarize my main motivation (perf benefits were just a
side-benefit I was hoping for):
You can’t implement (/=) faster than (==) (up to, in the worst case,
the cost of a single `not`, which often gets optimized away anyways).
As such, having (/=) in Eq was a (small) mistake back then, and it’s
worth fixing.
There is one time cost of asking developers to _remove_ code. But code
that was probably not worth writing in the first place! And I don’t
blame them, the Eq class _invites_ writing that code.
Then the benefits are twofold:
* No more awkwards explanations about silly things in the likely first
type class that developers care about.
* Less code to read, maintain, compile in all the libraries that _do_
define (/=) right now.
* Devs who instantiate Eq in the future will not be tricked into
wondering if they need to implement (/=) and why.
So even if “helps teaching beginners” doesn’t beat “having to bug
maintainers”, then maybe the second point (“saving all develpers time
and effort in the future”) does?
Cheers,
Joachim
</blockquote>
<div class="k9mail-signature">--
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW: <a href="https://glitchbra.in/" moz-do-not-send="true" class="moz-txt-link-freetext">https://glitchbra.in</a>
RUN: BSD<hr class="">Libraries mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:Libraries@haskell.org" moz-do-not-send="true">Libraries@haskell.org</a>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" moz-do-not-send="true" class="moz-txt-link-freetext">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a>
</div></pre>
</blockquote>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW: <a class="moz-txt-link-freetext" href="https://glitchbra.in/" moz-do-not-send="true">https://glitchbra.in</a>
RUN: BSD</pre>
</div>
_______________________________________________<br
class="">
Libraries mailing list<br class="">
<a href="mailto:Libraries@haskell.org"
class="moz-txt-link-freetext" moz-do-not-send="true">Libraries@haskell.org</a><br
class="">
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW: <a class="moz-txt-link-freetext" href="https://glitchbra.in">https://glitchbra.in</a>
RUN: BSD</pre>
</body>
</html>