On 2013-03-25 19:00:42 +, Alberto G. Corona said:
It is possible as long as there is a empty event and there is a
operation that mix two events to créate an state and an operation that
mix an state and a event to créate an state.
I just read thisat a time I am learning FRP
Hi Luc,
I really don't know what exactly what FRP is. Every time i read about it, I
figure out different things depending on the library.
I used the term event in a wider way as something that happens in the
computation no matter if it is generated inside or outside. Workflow
does not handle
Hi Michael,
On Sun, Mar 24, 2013 at 05:13:35PM -0500, Michael Better wrote:
Isn't this similar to the problem Cloud Haskell had to solve to send code
to another process to run?
As much as I know, the sendable code of 'Cloud Haskell' is limited, you
can't just send any kind of function.
What do you mean by monoid? It's not clear to me how a state (essentially a
structure with many fields) can be a monoid...
I figured out that the Writer monad may be good for that purpose.
On Mon, Mar 25, 2013 at 1:50 AM, Alberto G. Corona agocor...@gmail.comwrote:
That is the advantage of
Workflow is impressive! I didn't know you could serialize IO
states/computations.
On Mon, Mar 25, 2013 at 2:06 AM, Alberto G. Corona agocor...@gmail.comwrote:
the package Workflow serialize also the state of a computation, so it can
be re-started and continued. It uses also the above
On Mon, Mar 25, 2013 at 8:53 AM, Corentin Dupont
corentin.dup...@gmail.comwrote:
Workflow is impressive! I didn't know you could serialize IO
states/computations.
In certain constrained cases you can. General case, as I said earlier, is
kinda impossible without serializing the entire machine
It is possible as long as there is a empty event and there is a operation
that mix two events to créate an state and an operation that mix an state
and a event to créate an state.
Then, if the events are serializable, the deserialization of the state from
a serialized list of events would be
Corentin:
Thanks. It is not exactly the serialization of IO state computations,
but when re-started, the IO state is recreated from
the serialized intermediate results. It makes use of a simple idea,
although it is not easy to realize it practically.
I suppose that scala does something similar
Hi Café,
I have a DSL like this:
data Exp where
OnEvent :: EventName - (Int - Exp) - Exp
(...)
The OnEvent element carries a function (the handler to be called when the
event happens), and that makes my DSL non showable/serializable.
How could I fix that? This is a real handicap not to
Hi Corentin,
I have a DSL like this:
data Exp where
OnEvent :: EventName - (Int - Exp) - Exp
(...)
The OnEvent element carries a function (the handler to be called when the
event happens), and that makes my DSL non showable/serializable.
How could I fix that? This is a real
Hi Daniel,
in my game the handlers are supplied by the players as part of little
programs that they submit. An haskell interpreter is reading the program
code submitted and inserts it in the game.
So there is an infinite number of handlers...
I was thinking of hiding the parameters of the handlers
On Sun, Mar 24, 2013 at 4:16 PM, Corentin Dupont
corentin.dup...@gmail.comwrote:
Hi Daniel,
in my game the handlers are supplied by the players as part of little
programs that they submit. An haskell interpreter is reading the program
code submitted and inserts it in the game.
So there is an
Hi Brandon,
in fact, that's what I'm doing. I record the list of actions performed by
the players, including the submission of the code. I serialize this list of
actions instead of the state of the game. When deserializing, I replay all
the players actions from scratch to get back to the same
On Sun, Mar 24, 2013 at 5:44 PM, Corentin Dupont
corentin.dup...@gmail.comwrote:
But I always bothered me that this state is not serializable...
I am not quite sure how to respond to that. You seem to be asking for magic.
That kind of state has never been sanely serializeable. Not in Haskell,
Isn't this similar to the problem Cloud Haskell had to solve to send code
to another process to run?
Mike
On Mar 24, 2013 5:06 PM, Brandon Allbery allber...@gmail.com wrote:
On Sun, Mar 24, 2013 at 5:44 PM, Corentin Dupont
corentin.dup...@gmail.com wrote:
But I always bothered me that this
I also came across Scala's Swarm, making use serializable delimited
continuations. Looks good!
http://www.scala-lang.org/node/3485
On Sun, Mar 24, 2013 at 11:13 PM, Michael Better mbet...@gmail.com wrote:
Isn't this similar to the problem Cloud Haskell had to solve to send code
to another
On Sun, Mar 24, 2013 at 11:05 PM, Brandon Allbery allber...@gmail.comwrote:
On Sun, Mar 24, 2013 at 5:44 PM, Corentin Dupont
corentin.dup...@gmail.com wrote:
But I always bothered me that this state is not serializable...
I am not quite sure how to respond to that. You seem to be asking
That is the advantage of recording the sequence of events instead of the
final state: that the state don´t need to be seriallizable. And this
indeed the way to serlize something that can be decomposed in events. I
think that this is elegant.. Specially if the events and the state are
elements of
the package Workflow serialize also the state of a computation, so it can
be re-started and continued. It uses also the above mentioned event trick
to serialize the state.
By the way you can use the workflow monad transformer to recover the state
of the game. You don´t need to serialize anything
19 matches
Mail list logo
