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
