persist and retrieve of IO type?

Daryoush Mehrtash

9 Apr 2010 9 Apr '10

4:17 p.m.

Is there a way to persist a [IO ()] to say a file then retrieve it later and execute it using a sequence function? Thanks, Daryoush

Attachments:

attachment.html (text/html — 150 bytes)

Show replies by date

Ivan Lazar Miljenovic

10 Apr 10 Apr

2:46 a.m.

Daryoush Mehrtash writes:

...

Is there a way to persist a [IO ()] to say a file then retrieve it later and execute it using a sequence function?

I'm not sure I understand what you're wanting... you can pass around values of type "IO ()" around, but they won't be executed until you actually use them... -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Jon Fairbairn

5:19 a.m.

Ivan Lazar Miljenovic writes:

...

Daryoush Mehrtash writes:

...
Is there a way to persist a [IO ()] to say a file then retrieve it later and execute it using a sequence function?

I'm not sure I understand what you're wanting... you can pass around values of type "IO ()" around, but they won't be executed until you actually use them...

It sounds more like he wants two functions something like save:: FilePath -> [IO ()] -> IO () restore:: FilePath -> IO [IO ()] to which the answer would be no. -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk

Svein Ove Aas

9:27 a.m.

On Sat, Apr 10, 2010 at 11:19 AM, Jon Fairbairn wrote:

...

It sounds more like he wants two functions something like

save:: FilePath -> [IO ()] -> IO () restore:: FilePath -> IO [IO ()]

to which the answer would be no.

It's an insoluble problem in general - the parameters baked into the thunk may be infinite, or at least too large to persist, and the functions may not be around if you try to load the persisted data into a different version of the executable - but it's an interesting problem to attempt solving. Given that GHC 6.12 has added some of the base functionality required (i.e. dynamic linking), I was planning to take a bash at it (persisting functions in general, not just IO actions) in the summer. I don't know if that would help you, though. It's certainly not a good idea in general, and at any rate there's a good chance I won't succeed. (Of course, thunks aren't /actually/ infinite, in memory. Part of the project would be an attempt to persist the thunks, allowing lazy evaluation after reading them back in. Naturally this would only work with the exact same executable, but that's not necessarily a problem.) -- Svein Ove Aas

Stephen Tetley

11:33 a.m.

Hello all There has been Persistent Haskell - which was one of the Scottish tradition of persistent languages; being a sassenach myself I've no knowledge of whether it was actually implemented. Best wishes Stephen

Daryoush Mehrtash

1:32 p.m.

Can you please explain this: ....the parameters baked into the thunk may be infinite....

...

daryoush On Sat, Apr 10, 2010 at 6:27 AM, Svein Ove Aas wrote:

...

On Sat, Apr 10, 2010 at 11:19 AM, Jon Fairbairn wrote:

...
It sounds more like he wants two functions something like

save:: FilePath -> [IO ()] -> IO () restore:: FilePath -> IO [IO ()]

to which the answer would be no.

It's an insoluble problem in general - the parameters baked into the thunk may be infinite, or at least too large to persist, and the functions may not be around if you try to load the persisted data into a different version of the executable - but it's an interesting problem to attempt solving.

Given that GHC 6.12 has added some of the base functionality required (i.e. dynamic linking), I was planning to take a bash at it (persisting functions in general, not just IO actions) in the summer.

I don't know if that would help you, though. It's certainly not a good idea in general, and at any rate there's a good chance I won't succeed.

(Of course, thunks aren't /actually/ infinite, in memory. Part of the project would be an attempt to persist the thunks, allowing lazy evaluation after reading them back in. Naturally this would only work with the exact same executable, but that's not necessarily a problem.)

-- Svein Ove Aas _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Svein Ove Aas

2:32 p.m.

On Sat, Apr 10, 2010 at 7:32 PM, Daryoush Mehrtash wrote:

...

Can you please explain this:

...
....the parameters baked into the thunk may be infinite....

I'm a bit bushed today, I think.. I was thinking of thunks. A haskell value can be infinite, since it's lazily evaluated; however, at the machine level a thunk is just a function pointer plus a bunch of value (possibly meaning other thunk) references - eminently walkable, assuming the GHC developers don't decide to alter the format. So, there are two ways a function serializer could work, taking currying into account: - Store the function pointer (or, preferably, the matching symbol name), force all the values and write those out along with it. This has the advantage of being less likely to break on upgrades, but since the values may be infinite.. yeah. - Store the function pointer, and walk the value references, storing the entire tree of thunks/function pointers pointed to by the original function value, but don't force any values. This at least guarantees that the serialized form is finite. All things considered, I'll be shooting for option #2. -- Svein Ove Aas

5521

Age (days ago)

5522

Last active (days ago)

List overview

Download

6 comments

5 participants

participants (5)

Daryoush Mehrtash
Ivan Lazar Miljenovic
Jon Fairbairn
Stephen Tetley
Svein Ove Aas