[Haskell-cafe] question about Data.Binary and Double instance

[David Roundy]

On Wed, Apr 18, 2007 at 12:34:58PM +1000, Duncan Coutts wrote:
> We can't actually guarantee that we have any IEEE format types
> available. The isIEEE will tell you if a particular type is indeed IEEE
> but what do we do if isIEEE CDouble = False ?

All the computer architectures I've ever used had IEEE format types.
Perhaps we could add to the standard libraries a IEEEDouble type and
conversions between it and ordinary types.  This would put the ugly ARM
hackery where it belongs, I suppose.

> Perhaps we just don't care about ARM or other arches where GHC runs that
> do not use IEEE formats, I don't know. If that were the case we'd say
> something like:

I don't.

> instance Binary Double where
>   put d = assert (isIEEE (undefined :: Double)) $ do
>             write (poke d)

I'd rather have this or nothing.  It may be that there are people out there
who want to serialize and read Doubles to and from Haskell, but I imagine
most people want to read or write formats that can interoperate with other
languages (which is the only reason I'm looking into Binary now).

It's rather inconvenient (and took me quite some time to track down) having
such a non-standard serialization for Double.

If there were no Binary instance for Double, I could write this myself, but
alas, once an instance is declared, there's no way to undeclare it, and the
workarounds aren't pretty.  I suppose I can

newtype DDouble = D Double
unD (D d) = d

instance Binary DDouble where
  put (D d_ = assert (isIEEE (undefined :: Double)) $ write (poke d)

putDouble = put . D

> If we do care about ARM and the like then we need some way to translate
> from the native Double encoding to an IEEE double external format. I
> don't know how to do that. I also worry we'll end up with lots of
> #ifdefs.

I'd say lots of #ifdefs are okay.  This is a low-level library dealing with
low-level architecture differences.

> The other problem with doing this efficiently is that we have to worry
> about alignment for that poke d operation. If we don't know the
> alignment we have to poke into an aligned side buffer and copy over.
> Similar issues apply to reading.

Right now, efficiency is less of a concern to me than ease.  I imagine the
efficiency can be fixed up later? I'd think you could statically check the
alignment with a bit of type hackery (and note that I said I thought *you*
could, not *I* could).  Something like creating two monad types, an aligned
one and an arbitrary one, and at run-time select which monad to use, so the
check could occur just once.
-- 
David Roundy
http://www.darcs.net