[Haskell-cafe] Re: Orthogonal Persistence in Haskell

Pasqualino 'Titto' Assini tittoassini at gmail.com
Fri Jun 22 06:03:40 EDT 2007


Many thanks Claus for the extended explanation, it makes perfect sense.

For more info I will now turn to the papers :-)

Talking about serialisation, an interesting paper has just appeared on 
lambda-the-ultimate:

HOT Pickles
http://lambda-the-ultimate.org/node/2305

Regards,

             titto



On Friday 22 June 2007 00:28:53 Claus Reinke wrote:
> >> 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
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe




More information about the Haskell-Cafe mailing list