3 ms·

Thanks for the write-up, very interesting! Reading it I had a few questions: 1. How can DAG based workflows express events that are iterative in nature, ie. wo

by pwm 8y ago

Thanks for the write-up, very interesting! Reading it I had a few questions: 1. How can DAG based workflows express events that are iterative in nature, ie. would result in a cycle? For example I have an empty shopping cart as a start state and I want to put X items in it? 2. Is undo/rollback possible? If so how does cleanup work and does an undo/rollback means forking into a new state as opposed to going back to a previous state we logically want to be in?

Smaug123 8y ago
cart { let! item1 = item let! item2 = anotherItem … } No cycle there! You'd use some kind of state monad to keep track, and each let! simply adds something to the state. For example, you could end up with the computation expression producing a `Cart = Cart of Item list`, which contains a list of the things that were added. Your question about going back to a previous state: it depends on what style you're using. * At my day job, we use the "initial algebra" style (which is something of an abuse of F#'s type system but which gives you absolute power). In this style, your computation expression produces a structure isomorphic to a list of "this was added, then this was added, then this was removed, then this was added, …". It is then the job of some further processing step to convert this into more useful forms, like deduplicating carts which have the same contents. * One could instead produce the cart as you went, and it would Just Work (tm). Note that in F#, most data structures are immutable, so "rolling back" to the list [item1; item2] from the list [item3; item1; item2] is exactly the same as taking the tail of that input list. You won't fork the state by producing another list which happens to have the same contents; they are the same list. In general, F# structures tend to do structural equality.
- pwm 8y ago
  Sorry, I probably wasn't clear in my initial question. What I meant is how do DAG based workflows deal with computational graphs that contains cycles? Eg. we have 2 states: Cart and Payment and 2 events: PutItem and Checkout. A simple (external) DSL describing this graph could look like: Cart --PutItem--> Cart Cart --Checkout-> Payment Does the workflow engine in the article exclude situations like this? Regarding forking what I meant is that if you have: A --event--> B ^ / \--undo---/ then if your invariant is to be a DAG then you could "unroll" the cycle into some new state C that you would make semantically equivalent to A. A --event--> B --undo--> C This works but causes state explosion.

by pwm 8y ago

Smaug123 8y ago

cart { let! item1 = item let! item2 = anotherItem … } No cycle there! You'd use some kind of state monad to keep track, and each let! simply adds something to the state. For example, you could end up with the computation expression producing a `Cart = Cart of Item list`, which contains a list of the things that were added. Your question about going back to a previous state: it depends on what style you're using. * At my day job, we use the "initial algebra" style (which is something of an abuse of F#'s type system but which gives you absolute power). In this style, your computation expression produces a structure isomorphic to a list of "this was added, then this was added, then this was removed, then this was added, …". It is then the job of some further processing step to convert this into more useful forms, like deduplicating carts which have the same contents. * One could instead produce the cart as you went, and it would Just Work (tm). Note that in F#, most data structures are immutable, so "rolling back" to the list [item1; item2] from the list [item3; item1; item2] is exactly the same as taking the tail of that input list. You won't fork the state by producing another list which happens to have the same contents; they are the same list. In general, F# structures tend to do structural equality.

pwm 8y ago
Sorry, I probably wasn't clear in my initial question. What I meant is how do DAG based workflows deal with computational graphs that contains cycles? Eg. we have 2 states: Cart and Payment and 2 events: PutItem and Checkout. A simple (external) DSL describing this graph could look like: Cart --PutItem--> Cart Cart --Checkout-> Payment Does the workflow engine in the article exclude situations like this? Regarding forking what I meant is that if you have: A --event--> B ^ / \--undo---/ then if your invariant is to be a DAG then you could "unroll" the cycle into some new state C that you would make semantically equivalent to A. A --event--> B --undo--> C This works but causes state explosion.