CLDouble is nothing like a long double

[jedbrown]

This affects all versions of GHC. Why does the type exist when it is just a synonym for CDouble? Either it should actually become a `long double' as the documentation says or it should just not exist. From Foreign/C/Types.hs:

-- HACK: Currently no long double in the FFI, so we simply re-use double
-- | Haskell type representing the C @long double@ type.
FLOATING_TYPE(CLDouble,tyConCLDouble,"CLDouble",HTYPE_DOUBLE)

[igloo]

Sounds reasonable, and like it should be easy to fix.

[simonmar]

Let's just remove it.

[jedbrown]

I personally don't have a problem with that, but some people care a lot about quad precision, mostly for very ill-conditioned problems or in order to get away with a numerically unstable method.

[igloo]

Well, currently it doesn't provide quad precision anyway, so nothing is lost by removing it.

However, there are a couple of issues with removing it:

• The FFI addendum says that we should provide it

• The code is a CPP tangle with the GHC, hugs and nhc implementations of it. I don't know if anything really implements it.

There's also more work involved in implementing it than I'd previously realised. I'll revisit it after removing decodeDoubleInteger.

[simonmar]

Wouldn't we have to implement long double as a new primitive type in GHC, provide support in all the code generators, including support for passing long double to C functions in all the native backends? It's a lot of work.

[igloo]

I've removed GHC's CLDouble pretense, and opened #3353 "Add CLDouble support" to add proper support.