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@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
