On Wed, 2007-04-18 at 21:12 -0700, David Roundy wrote:
On Thu, Apr 19, 2007 at 10:20:21AM +1000, Duncan Coutts wrote:
and people will for ever be defining newtype wrappers or complaining that the whole library isn't parametrised by the endianness or whatever. For existing formats you need much more flexibility and control. The Binary class is to make it really convenient to serialise Haskell types, and it's built on top of the layer that gives you full control.
We intend to work more on this other side of the library in the coming couple of months. If you could tell us a bit more about your use case, that'd be great.
I just want to read in a file full of Doubles (written in binary format from C++) and print out text (into a pipe or file to be read by gnuplot). It's not a high-performancs use (the file is only a megabyte or so), but it's something that *ought* to be easy, and so far as I can tell, it requires tricky hackery.
Right, it should be simple. With the api I'm hacking on at the moment you just have primitives like (importing Data.Binary.Get as Get): Get.word :: Get Word Get.word8 :: Get Word8 and you'd need: Get.double :: Get Double --IEEE double format As you noticed, that's not a primitive which we have yet. With that it should be really easy to get a sequence of them: Get.run (mapM (const Get.double) [0..n]) :: Lazy.ByteString -> [Double] or whatever.
I suppose I was just disappointed, because I'd figured that the Binary library was there to do what I wanted. :( It was something I could have done in five minutes (counting tuning the gnuplot file) in perl, and it's embarrassing (which makes it frustrating) to fail in Haskell to complete it in... I couldn't say how long, an hour or so?
Yeah, we've concentrated so far on the serialisation of Haskell values, not reading/writing externally defined binary formats. I don't think we've been especially clear on that. But we do intend to tackle both. Duncan