[Haskell-cafe] Re: Orthogonal Persistence in Haskell

[Claus Reinke]

>> with orthogonal persistence, everything a program touches might
>> persist, but usually, programs talk about the data being persistet (?),
>> not about whether that data is currently temporary or in long-term
>> storage. if you want to move such data between processes or storage
>> areas, you move the reference, and the system handles serialisation/
>> communication/deserialisation behind the scenes.
> 
> This is interesting, could you elaborate on it?
> How would you get data to move around by moving its reference?

more elaboration than the various papers, surveys, and phd theses 
listed in the references i provided?-) the idea is that i give you the 
reference, and you take care of looking at the data behind it, 
without me having to serialise the contents;-)

but ok, lets see whether i can get the idea accross by example:

a) suppose you want to move some x from list a to list b

    do you get the type of x, devise a type-specific traversal to
    serialise x from the source, move the flattened data from a to b, 
    and deserialise x in the target?

    or do you just write:

        test = move ([1..4],[3..5])
        move (x:as) b = (as,x:bs)

b) suppose you want to move some x from concurrent haskell
    process a to concurrent haskell process b

    do you get the type of x, devise a type-specific traversal to
    serialise x from the source, move the flattened data from a to b, 
    and deserialise x in the target?

    or do you write something like:
 
    test = do { av<-newEmptyMVar;
                     bv<-newEmptyMVar;
                     forkIO (putMVar av [1..]); 
                     forkIO (takeMVar bv >>= print . take 10);
                     move av bv }
    move av bv = takeMVar av >>= putMVar bv

c) suppose you want to move some x from os process a to
    os process b

    do you get the type of x, devise a type-specific traversal to
    serialise x from the source, move the flattened data from a to b, 
    and deserialise x in the target?

    yes. and if the type is not serialisable, you're stuck.

d) suppose you want to move some x from os process a to
    an os file, for later retrieval in process b

    do you get the type of x, devise a type-specific traversal to
    serialise x from the source, move the flattened data from a to b, 
    and deserialise x in the target?

    yes. and if the type is not serialisable, you're stuck.

now, why are c/d so much more troublesome than a/b? i don't
care whether the x to be moved is an integer, a matrix, a function,
or the list of primes - i just want it to be moved from a to b. or
rather, i move the reference to x, and the runtime system moves
whatever representation is behind that, if a move is necessary,
and without ever exposing that internal representation. and if i
happen to move x into a long-term storage area, it will persist
there for future reference, without further ado.

much more about that idea in the papers i mentioned. or, if you 
prefer something more recent, have a look at the Clean papers:

http://www.st.cs.ru.nl/Onderzoek/Publicaties/publicaties.html

a selection of entries related to dynamics and first-class i/o:

1997: 4. Pil, Marco, First Class File I/O
2003: 7. Arjen van Weelden and Rinus Plasmeijer. 
             Towards a Strongly Typed Functional Operating System.
2003: 6. Martijn Vervoort and Rinus Plasmeijer. 
             Lazy Dynamic Input/Output in the lazy functional language Clean
2004: 21. Arjen van Weelden, Rinus Plasmeijer. 
            A Functional Shell that Dynamically Combines Compiled Code.

hth,
claus