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