question of decimal pointed literals

[Lennart Augustsson]

"S.D.Mechveliani" wrote:

> Can we solve and close the problem of the meaning of decimal pointed
> leterals?

There is no problem, it's clearly specified by the report.
(There is a problem with Hugs, it doesn't implement literals properly.
Or has that ancient bug been fixed?)


> > "The floating point literal f is equivalent to
> > fromRational (n Ratio.% d), where fromRational is a
> > method in class Fractional and Ratio.% constructs a rational from
> > two integers, as defined in the Ratio library. The integers n and
> > d are chosen so that n/d = f."
>
> By saying  "input is in decimal representation (`0.9')"
> I meant that a number `0.9' is written by a programmer keeping in
> mind a decimal representation.
> Further, according to the citation,  0.9 --> fromRational (9%10),
>                                      0.2 --> fromRational (1%5)
>
> are stored as the values of type     Fractional a => a.

The literal itself must be stored as a Rational (i.e. `Ratio Integer'), but the
result of the `fromRational L' has type `(Fractional a) => a' as you said.


> (1) What is this `a' for our example of
>                              toRational (fromRational (0.9)) == 9%10
> ?

It depends, see below.


>
> (2) Why Haskell does not report an ambiguity error?

Because any ambigous type is subjected to the defaulting mechanism.
If the ambigous type variable belongs to class `Num' it is defaulted
according to the defaults in scope in that module.  The standard default
is `(Integer, Double)', so the the pick in this case is Double.  So the intermediate
result after fromRational is of type Double.  So you will lose precision.


> For `a' may be Rational, Double, Float - just anything of Fractional.
> If we take Lennart's assertion
>   > Input in decimal representation is stored as a Rational number.
>   > There is absolutely no loss of precision.
>
> then it should be  `a' = Rational.
> Then, in particular,               toRational (0.d) == d%10  = True
>
> for any decimal literal  d   and  * any other behavior is a bug. *
> Is this really so?

No, since what you wrote is equivalent to
    toRational (fromRational (d%10)) == d%10
and as I described it is subject to defaulting.  If you do
    default (Integer, Rational)
in your module you'll get equality.


    -- Lennart