sjakobi
commented
2 years ago
Real: if the type also implementsFractional, thenfromRationalis a left inverse fortoRational, i.e.fromRational (toRational i) == i.Fractional:toRationalis total, and if the type also implementsReal, thenfromRationalis a left inverse fortoRational, i.e.fromRational (toRational i) == i.
It seems that NaN is the usual exception here:
ghci> toRational (0 / 0 :: Float)
(-510423550381407695195061911147652317184) % 1
ghci> fromRational $ toRational (0 / 0 :: Float) :: Float
-InfinityI think that's acceptable though. Many Float and Double instances already have documentation like this example from Fractional:
Note that due to the presence of NaN, not all elements of Double have an multiplicative inverse.
>>> 0/0 * (recip 0/0 :: Double) NaN
Bodigrim
michaelpj
cgibbard
chessai
mixphix
emilypi
tomjaguarpaw
chshersh
Motivation
In the process of writing https://github.com/haskell/core-libraries-committee/issues/40, I realised that the pairs of typeclass methods
toInteger/fromIntegerandtoRational/fromRationalactually do have some reasonable coherence laws that I expect everyone assumes. Nonetheless, it would be good to document these.Proposal
Add the following laws to the documentation of the following typeclasses:
Num: if the type also implementsIntegral, thenfromIntegeris a left inverse fortoInteger, i.e.fromInteger (toInteger i) == i.Integral:toIntegeris total, andfromIntegeris a left inverse for it, i.e.fromInteger (toInteger i) == i.Real: if the type also implementsFractional, thenfromRationalis a left inverse fortoRational, i.e.fromRational (toRational i) == i.Fractional:toRationalis total, and if the type also implementsReal, thenfromRationalis a left inverse fortoRational, i.e.fromRational (toRational i) == i.Note: we cannot say anything about the right inverse properties, because there is no way of telling when
fromInteger/fromRationalis outside it's range of precise functioning: it may be bottom or it may just return a different answer.Discussion
Are these good laws?
The main question is: are there instances that don't satisfy this? I made an effort here to check this. As far as I can tell, all of the main instances in
basesatisfy these laws. It's of course possible that instances in user code do not.Indeed, for the "central" use case of providing an isomorphism to a subset of the integers/rationals, it seems hard to question that these laws should hold. However, there may be other use cases that I haven't thought of where you might want to violate them!
The most plausible law that I could imagine being broken is the totality of
toInteger/toRational, in case the isomorphism is only between subsets of both types.Where should the documentation go?
For
Num/Integral, sinceNumis a superclass ofIntegral, we could put the documentation onIntegral, since that is where we know that we have both instances. However forRealandFractionalneither is a superclass of the other. As such, I opted for a consistent approach of putting the documentation on both typeclasses, including conditional language if necessary.