#3676: realToFrac doesn't sanely convert between floating types
----------------------------------+-----------------------------------------
Reporter: draconx | Owner:
Type: bug | Status: new
Priority: normal | Milestone: _|_
Component: libraries (other) | Version: 6.12.1
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: x86_64 (amd64) | Failure: None/Unknown
----------------------------------+-----------------------------------------
Changes (by daniel.is.fischer):
* cc: daniel.is.fischer@… (added)
Comment:
Summarising:
There is no good solution to the problem while the conversions go
(potentially, without rewrite rules) via `Rational`. Having 'illegal'
`Rational` values like `1 :% 0` generated by parsing `Infinity` and so on
is not a big problem because those are immediately passed to
`fromRational`, so their treatment is confined to one place and they can
be handled meaningfully there. But if they could be generated by
`toRational`, ''every'' operation on `Rational`s would have to check for
these values (and it's not always clear how to handle them).
The options I'm aware of are
1. non-overloaded conversion functions between each pair of types
2. a two-parameter conversion class
3. adding `toMaxFloat` and `fromMaxFloat` functions to `RealFloat`
4. adding a dedicated pseudo-numeric type for conversions
All of them have downsides. 1. and 2. would require a number of functions
resp. instances quadratic in the number of involved types - yuck. 1. would
even rule out polymorphic code. 3. has the problem of what `MaxFloat`
should be and any choice would cause breakage when a larger `RealFloat`
type is introduced. 4: A type with the sole purpose of facilitating
numeric conversions in the standard libraries is quite wartish (and new
types could introduce new unrepresentable values).
I think 4. is the least undesirable option, but still it would be a lot of
work to implement (it involves a change to the language report, among
other things) for dubious benefit.
Unless renewed concern is expressed, I think we should mark it as low
priority.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3676#comment:18>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
