Re: Proposal: Make Eq type class single method

Thanks a lot Richard!

Le 25/10/2021 à 23:02, Richard Eisenberg a écrit :
> I will also offer my own counter-proposal to intrinsic-superclasses, 
> at https://gitlab.haskell.org/ghc/ghc/-/wikis/instance-templates.
>
> These all predate our current proposals process.
>
> 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.
>
> Do look at the proposals, but your mileage may vary.
>
> Richard
>
>> On Oct 25, 2021, at 4:50 PM, Hécate <[email protected]> wrote:
>>
>> There are the DefaultSuperclassInstances and Intrinsic Superclasses 
>> which aim to provide in-compiler support for such transitions:
>>
>> https://gitlab.haskell.org/ghc/ghc/-/wikis/intrinsic-superclasses
>>
>> But also code-modding would benefit from being used here, and maybe 
>> retrie (https://hackage.haskell.org/package/retrie)
>> would benefit from being used at scale?
>>
>>
>> Le 25/10/2021 à 19:05, Ryan Trinkle a écrit :
>>> Is there a language feature that could be built that would reduce 
>>> the cost of inter-package refactors like this in the future?
>>>
>>> On October 25, 2021 4:06:46 PM UTC, "Hécate" <[email protected]> 
>>> wrote:
>>>
>>>     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 :
>>>
>>>         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 
>>>
>>>
>>>     -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW:
>>>     https://glitchbra.in RUN: BSD
>>>     ------------------------------------------------------------------------
>>>     Libraries mailing list [email protected]
>>>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>> -- 
>> Hécate ✨
>> 🐦: @TechnoEmpress
>> IRC: Hecate
>> WWW:https://glitchbra.in
>> RUN: BSD
>> _______________________________________________
>> Libraries mailing list
>> [email protected]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW:https://glitchbra.in
RUN: BSD

_______________________________________________
Libraries mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries