I'm not convinced that the binary library should "natively" support cyclic data. I think that if saying:
print x
would not terminate, then there's no reason that
puts bh x
should terminate. I like to think of "puts" as a binary version of print. (That is, of course, unless the instance writer for the Binary/Show instances of the type of x is smart enough to not keep writing the same thing over and over again.) I would challenge the interested party to write a Show instance of String which wouldn't loop indefinitely on "repeat 'x'". well, it is your choice to think of it as you like, but this is not what my original mail was about. i think the ability to make data persistant is a useful one and it should be as transperant to the programmer as possible. when i write something like: ones = 1 : ones
i don't think of "printing infinately many ones in memory" and i don't see why i should start thinking of it that way just because i want to make the object persistant. after all, one can think of the disk as a verys low memory.
Ok, it seems that you're really after persistence as opposed to just serialisation, which is what the Binary library provides. I'm not aware of any working implementations of this kind of persistence for current compilers, but it wouldn't be too much work to implement in GHC, as long as you don't mind the persistent data being only readable by particular binary that generated it, and refrain from any dynamic linking of Haskell code. Cheers, Simon
I recently read the paper "Lazy Dynamic Input/Output in the lazy functional language Clean" (http://www.cs.kun.nl/~clean/download/papers/2002/verm2002-LazyDynamicIO2.pdf). It describes some attractive capabilities with respect to persistence, though the supporting mechanism appears rather complicated. Does anyone with a deeper understanding of these issues have an opinion as to whether similar capabilities could (and should) be provided for Haskell? Dean
It describes some attractive capabilities with respect to persistence, though the supporting mechanism appears rather complicated. Does anyone with a deeper understanding of these issues have an opinion as to whether similar capabilities could (and should) be provided for Haskell?
Persistence is, indeed, a very attractive language feature. To see how useful they are (and how to solve some of the issues they raise), look at languages like PS-Algol and Pisa. Some of the main issues are: - Typechecking: if I write a value with type 'data T = L | R' (say) out to disk and then read it back in again, what can I do with the values when I read them back in? If the program that reads them in contains a type declaration 'data T = L | R', can I treat the value I read in as having that type? If the program that reads them in contains a type declaration 'data T = L | M | R', can I treat the value I read in as having that type? If the data written and then read back in involves standard library types like [Int] and (Int,Float), can you treat them as having that same type when you read them back in? The obvious solution to these issues is to access types through an abstract interface - don't use data constructors, don't use pattern matching. This is (part of) how Pisa solves the problem. But this makes your persistent data a 2nd class citizen. - Higher order functions and lazy evaluation: You need to write code out to disk because the data may contain unevaluated thunks and higher order functions. This is a bit tricky to add to existing compilers but quite feasible (e.g., I think someone at St Andrews did this with STG-Hugs at some point). More trickily, if a thunk refers to a standard library function, do you have to write it out too? (Obvious answer is yes). What if the thunk refers to a C function accessed through the foreign function interface, do you have to write it out too? (Obvious answer is yes but it's not clear how you'd implement this. - Coping with changes in on-disk representation as the compiler evolves. - Coping with portability problems between machines with different sizes of Float, Int, etc. -- Alastair Reid alastair@reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/
participants (3)
-
Alastair Reid -
Dean Herington -
Simon Marlow