I also have done some work on a set of classes which will let you read in and write out XDR encoded data, (as is used in NFS and other rpc protocols) in a hopefully efficient manner. I am working on figuring out how to modify DrIFT to auto-derive instances of it. the near-term goal is an nfs server written in haskell (for a virtual filesystem) as well as an efficient on-disk format for data. Another side effect of this work is that the code also generates a unique hash which is only dependant on the type of the encoded data, the idea being that I can tag the beginning of on-disk data with it and have some degree of insured type-safety. John On Tue, Aug 21, 2001 at 08:22:01AM -0400, Mark Carroll wrote:
On 21 Aug 2001, Ketil Malde wrote: (snip)
Can you use Read and Show? I mean, not ideal for all purposes, but very standard. (snip)
I figured it would be quite a waste having the computer convert the data to human-readable form and then parsing it again when a human's not going to be reading the intervening datastream. Even just converting the numbers to ASCII and back takes time when there's quite a few of them.
(snip)
Well, 'efficiently' is a problem. :-)
Apparently so! (-: Thanks anyway.
Of course, I can get by with an inefficient version where I have to write some pickling and unpickling code for lots of my types, until something better shows up! I assume it will someday.
-- Mark
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@repetae.net ---------------------------------------------------------------------------