Effects as "pure" and "impure"

[andrewzhurov]

From what I gather, evaluation of a workflow is meant to be done in two stages:

1. Evaluate all pure Invocations
2. Gather all effects and evaluate them

If a pure Invocation fails - all workflow fails.
This is done to achive transactional guarantees at the "pure" level, when we either do it all or fail it all.
(we can't guarantee it for effects)

I wonder how the proposed join and fork fields are involved in this.
join is described as workflow continuation, so I guess it's meant for "pure" Instructions.
Whereas fork is for side-effectful ones?
I'm not sure I got it the way it's meant.

For me, it seems it would make it clear to distinguish between "pure" and "impure" effects.
So Effects would be

type Effects {
  pure      [&Instruction] // Continuation of workflow
  impure  [&Instruction] // Executed after all pure Invocations succeed
}

Alternatively, we could try to establish purity of an Instruction from the Instruction itself.
E.g., perhaps only wasm Instructions are pure.
Then it becomes redundant to specify it in fields, Effects would simply become [&Instruction].
If the assumption above is correct, we could even add another step to the execution of workflow to fail fast:
0. Resolve all "impure" inputs of "pure" Instructions.

This way, Instructions that await on impure inputs (e.g., a GET request), would have their inputs resolved before starting the execution.
I.e., these impure inputs would become decoupled from their Instructions.
Their resolved values could be baked via "awaited" that would provide for reproducibility.