On Friday 13 June 2003 3:02 am, John Meacham wrote:
so, I have been wanting to implement serialize to database functionality for haskell in a certain way which may or may not be possible..
what would be nice is if I could dump an entire complex haskell data structure (perhaps cyclic, but not infinite) to a hash-table database [..]
This comes up every now and then. The lack of an existing library to do anything like this is because there's a bunch of tricky issues to deal with. It seems that to get anywhere with this, you have to decide not to deal with some of the following: 1) Writing unevaluated thunks out (your 'not infinite' comment above suggests you have already dropped this). 2) Writing out datastructures which contain functions: data T = App (T -> T) T | Const Int 3) Writing out partial applications like 'Prelude.foldr (:) Nil'. [2 and 3 lead to problems establishing function identity and versioning problems. For example, when you read that back in, will you assume that it means the version of Prelude.foldr provided by your compiler or will you need to read the function (in source-, intermediate- or machine- code)? Partial applications involving locally defined functions are especially tricky since we don't have a natural 'name' we can use to identify them.] 4) Versioning issues caused by change of compiler options or change of compiler version, or change of compiler. e.g., if I compile the code with -O2 and then try to read it into a program compiled with -O 5) Versioning issues caused by change in source code. e.g., if I write it out, add a new constructor to a datatype and recompile. e.g., if I write it out of one program and read it into another. [4 and 5 together amount to asking 'How do you decide if two types are the same? Haskell provides an answer for two types in a single program or translation unit but things get hazy when you have two programs, etc.] 6) Making sharing too observable. When you talk about writing cyclic datastructures out, you are talking about a property (i.e., sharing) of Haskell datastructures which varies between compilers and might even vary with level of optimization. I think what you mean is that you would like the property that a (fully evaluated) data structure which consumes finite heap space should require finite disk space. Indeed, we'd like the space to be at most a constant factor bigger. This amounts to the same thing but doesn't require us to delve into black holes like defining when sharing happens in Haskell implementations. There's probably a few more details... -- Alastair Reid