I would also like to point to this previous discussion on Reddit:
https://reddit.com/r/haskell/comments/e8ovcz/what_would_be_the_right_process_to_go_about/
I don’t have much experience with Rust, but we might actually want to check what their experience is. In that Reddit thread anydalch writes:
i think rust has proven this approach too unergonomic to be reasonable even in a language whose design goals skew much more towards Correctness than haskell’s
I wonder if Rust experts would agree.
Some other interesting suggestions. First by gilgamec:
even if you did this, you’d still have problems with nan. In order to avoid the problem, you would have to explicitly make partial functions, e.g.
class PartialEq a where peq :: a -> a -> Maybe Bool pneq :: a -> a -> Maybe Bool class PartialEq a => Eq a where (==) :: a -> a -> Bool (==) a b = case peq a b of Just v -> b -- total by definition!
And by rampion:
I think you’d have an easier time with the “parse, don’t validate” approach, since then you wouldn’t need to shim in a whole new class, just a data type, which is way easier.
instance Eq ComparableDouble instance Ord ComparableDouble parseComparableDouble :: Double -> Maybe ComparableDouble fromComparableDouble :: ComparableDouble -> Double
And by cartazio:
the real fix is to add support for signalling Nans and over time make that the default RTS flags. I’m working on that.
every other approach doesn’t really help anyone.