[Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom?

[YueCompl]

Dear Cafe,

I kinda understand the [Floating](https://hackage.haskell.org/package/base/docs/GHC-Float.html#t:Floating <https://hackage.haskell.org/package/base/docs/GHC-Float.html#t:Floating>) class doesn't care about NaN, as not expecting all floating point implementations to have such semantics.

But [IEEE Silent NaN](https://en.wikipedia.org/wiki/NaN#Quiet_NaN <https://en.wikipedia.org/wiki/NaN#Quiet_NaN>) has become a norm today, I think it deserves more than mere [isNaN](https://hackage.haskell.org/package/base/docs/GHC-Float.html#v:isNaN <https://hackage.haskell.org/package/base/docs/GHC-Float.html#v:isNaN>) in the [RealFloat](https://hackage.haskell.org/package/base/docs/GHC-Float.html#t:RealFloat <https://hackage.haskell.org/package/base/docs/GHC-Float.html#t:RealFloat>) class.

While [Signaling NaN](https://en.wikipedia.org/wiki/NaN#Signaling_NaN <https://en.wikipedia.org/wiki/NaN#Signaling_NaN>) can be an `Exception` triggering bottom like "divide by zero" is, the silent `NaN` feels like a different kind of bottom, or some thing similar to `Nothing` as in the `Num a => Maybe a` monad?

Is Haskell's type system capable of encoding silent NaN as a special kind/type of bottom that handleable?

Though I don't think I've gained correct understanding at all, on "bottom"s, I'm interested in what options we have to encode them, especially ergonomics ways to handle them accordingly.

Best regards,
Compl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210803/7e6fe6da/attachment.html>