feat: mutliple prologue steps

[julio4]

Following #43

Should be enought to close #31 for now, even if it provides "partial" solution

[SozinM]

so we remove 0?

[julio4]

This is basically useless as PROLOGUE_INDEX = usize::MIN but it makes the whole logic correct (else we should just remove PROLOGUE_INDEX altogether). It should be optimized away at compilation anyway.

[julio4]

We can discuss this as well. When we break within a prologue, should we break out of the pipeline, or just go to pipeline steps? I believe breaking out makes more sense

[karim-agha]

How about we reduce complexity here and instead of adding the ability to have multiple epilogue and prologue steps and then worry about all the implications of that, instead we create a new type of step that ships with rblib called say All that combine multiple steps into one?

So what your trying to achieve here would be represented as

pipeline
  .with_step(Step1)
  .with_prologue(All([Step2, Step3]))

Wdyt?

We can then configure the break/continue behavior at this combinatorial step level on a case by case basis.

[karim-agha]

How about we reduce complexity here and instead of adding the ability to have multiple epilogue and prologue steps and then worry about all the implications of that, instead we create a new type of step that ships with rblib called say All that combine multiple steps into one?

So what your trying to achieve here would be represented as

pipeline
  .with_step(Step1)
  .with_prologue(All([Step2, Step3]))

Wdyt?

We can then configure the break/continue behavior at this combinatorial step level on a case by case basis.

This will leave the current pipeline logic as is and move the behavior into combinators.

We might end up with combinator functions such as:

• All, run all steps regardless of output
• UntilBreak, run steps until first Break
• Any
• etc

[julio4]

How about we reduce complexity here and instead of adding the ability to have multiple epilogue and prologue steps and then worry about all the implications of that, instead we create a new type of step that ships with rblib called say All that combine multiple steps into one?
So what your trying to achieve here would be represented as

pipeline
  .with_step(Step1)
  .with_prologue(All([Step2, Step3]))

Wdyt?
We can then configure the break/continue behavior at this combinatorial step level on a case by case basis.

This will leave the current pipeline logic as is and move the behavior into combinators.

We might end up with combinator functions such as:

• All, run all steps regardless of output
• UntilBreak, run steps until first Break
• Any
• etc

I'm all for encapsulating complexity separately as pipeline is already quite complex.
But I'm just wondering what would be the difference between a pipeline vs a combination of steps (appart to get loop control flow)?

[karim-agha]

How about we reduce complexity here and instead of adding the ability to have multiple epilogue and prologue steps and then worry about all the implications of that, instead we create a new type of step that ships with rblib called say All that combine multiple steps into one?

So what your trying to achieve here would be represented as

pipeline

.with_step(Step1)

.with_prologue(All([Step2, Step3]))

Wdyt?

We can then configure the break/continue behavior at this combinatorial step level on a case by case basis.

This will leave the current pipeline logic as is and move the behavior into combinators.

We might end up with combinator functions such as:

• All, run all steps regardless of output

• UntilBreak, run steps until first Break

• Any

• etc

I'm all for encapsulating complexity separately as pipeline is already quite complex.

But I'm just wondering what would be the difference between a pipeline vs a combination of steps (appart to get loop control flow)?

A pipeline may include nested pipelines with loops. A combinator step ensures that you have a flat list of steps that will eventually terminate.

Another combinator step I can think of is Atomic. That takes a list of steps and either all succeed or the payload is reverted to its initial state.

[julio4]

A pipeline may include nested pipelines with loops. A combinator step ensures that you have a flat list of steps that will eventually terminate.

Another combinator step I can think of is Atomic. That takes a list of steps and either all succeed or the payload is reverted to its initial state.

To follow up on this. Should we close this PR and revert implementation for epilogue for consistency?
Or merge this and revert both prologue/epilogue when we have a combinator step

[akundaz]

To follow up on this. Should we close this PR and revert implementation for epilogue for consistency? Or merge this and revert both prologue/epilogue when we have a combinator step

I would prefer we get something merged for now (and also not revert the epilogue change) since flashtestations requires the additional prologue and flashblocks requires the additional epilogue