Stricness of floor etc

[Simon Marlow]

> Looking at
>=20
> ghc --show-iface .../ghc/lib/ghc-5.05/imports/base/GHC/Float.hi
>=20
> I see
>=20
> floor1 :: forall b. (GHC.Real.Integral b) =3D>
>           Double -> b
>             __S L
>=20
> properFraction2 :: forall b. (GHC.Real.Integral b) =3D>
>                    Double -> (b, Double)
>             __S L
>=20
> decodeFloat2 :: Double
>             __S U(L)m
>=20
> My understanding of this is that floor and properFraction of Doubles
> have a lazy argument while decodeFloat has a strict=20
> constructor of lazy
> values. It's not clear to me why the U(L) strictness isn't=20
> inherited by
> properFraction and then float, nor do I understand why decodeFloat is
> not strict in its argument when it seems to be working=20
> exclusively with
> unboxed values. Unfortunately decodeDouble# in=20
> PrimopWrappers.hi doesn't
> seem to have a strictness description so I can't see what's going on
> there.
>=20
> So I guess what I'm asking is are these strictnesses the best that can
> be inferred or could GHC do better?

This floor is the dictionary selector, and for various (complicated
looking) reasons it is lazy in its dictionary argument.  It does some
dictionary selections which might be shared, before returning a
function.

> Of course a strict floor (Double to Int and Integer) is what=20
> I'm really
> hoping for (without having to specify it explicitly with $!=20
> in my code).

There are specialised versions of floor for Double -> Int and Double ->
Integer.  You *ought* to get good code out if you call floor at one of
these types.  If not, please send us the example.

> Incidentally, what are 'm's in the strictness descriptions?

It means the function returns a manifest constructor, which can be
eliminated with CPR (constructed product result optimisation).

Cheers,
	Simon