edofic / effect-handlers

MIT License
19 stars 2 forks source link

Feature request #14

Open ohad opened 9 years ago

ohad commented 9 years ago

Do you think you could implement transparent code migration?

edofic commented 9 years ago

If I understand correctly you are talking about migrating a computation in progress to another machine.

At first glance it seems to me like a restricted version of this is possible. The restrictions being:

These restrictions seem quite severe but I think it just means integrating CloudHaskell.

ohad commented 9 years ago

Not at all!

The idea is that a computation returning a serializable value and involving algebraic effects whose parameter and arity types are serializable can be (extensionally) serialized into a value in the free monad (in a highly inefficient way!). The computation itself may involve non-serializable sub-parts, but these will not be sent over the network, merely be pre-computed.

The only thing the two machines should share is the interpreter part which reads a computation off the connection and executes it.

The handler implementation should be quite compact

andrejbauer commented 9 years ago

And what happens to non-terminating computations? Don't they generate rather large values in the free monad? Ok, you said it was inefficient...

ohad commented 9 years ago

Non-termination is a computational effect. What kind of strange programming language would include non-termination by default and still consider itself pure?

edofic commented 9 years ago

Haskell. Which is incidentally the language we are using.

andrejbauer commented 9 years ago

I think there's general leg pulling going on here. Let's just get back to coding ;-)