"+" operator propagates Success message while having the work left to do

[anatoliykmetyuk]

Consider the following script:

live = (break ; println("Hello")) + println("World")

Here, the following happens:

1. break makes ; to have Success immediately on its activation
2. + receives Success message
3. + emits the Success message upwards the graph and activates its another operand, println("World")

This behaviour starts to cause a real trouble in the following script:

live = ((break ; println("Hello")) + println("World")) ...

Because + emits Success too early, the topmost sequential operator also receives it too early and activates the next operand, ... while the first one, + still has work to do (it waits for the println("World") execution. Hence, causing an infinite activation loop without anything every outputted.

[anatoliykmetyuk]

There are two possible expected behaviours I see. First, treat a break as an actual script action. In this case, we need to prevent + from activating its other operands and make it have success and deactivate right away. Second, treat a break as a purely "administrative" action which will be ignored by the + operator. It will just spawn its other operands as usually, but without emitting a Success message.

I think, break is better to be treated as an administrative action. In fact, if it happens somewhere after other, "real" actions, then from +'s point of view, these previous real actions have already started a script. It the break happens as a first atom of a sequential script, then it prevents any real action on that script. Can we consider a total absence of action to be a "real" script action meaningful for "+"? I doubt.

[AndreVanDelft]

I think break has a fine and simple definition; there is no need to change that.

Let's write p and q instead of println("Hello") and println("World")

break; p equals 1 (in SubScript syntax (+), since break makes the sequence end successfully. break; p + q thus equals 1 + q.

What does this do? At activation, bot 1 and q are activated; 1 succeeds so that the entire expression succeeds (it has an or-like flavour). There is no behavioristic law about + that says that q should now be deactivated.

Now consider the script (1+q)... The(1+q)operand succeeds immediately, and since this happens in a sequential loop, the activation of that loop causes an attempt to infinit activations of(1+q)`. We will get an OutOfMemoryException, but conceptually we would expect a kind of deadlock for the script execution.

That is just the behaviour that the programmer specifies. If this is not the intended behaviour, the programmer should specify something else. Changes to the meaning of break will be confusing to VM programmers and to application programmers.

BTW ACP researchers have stated already over 25 years ago:

livelock = deadlock

That statement applies here quite well; only this livelock is in the context of a silent step whereas we only have an empty step AKA 1 here. Only, the activation and other run time behaviour of a 1 takes some time and other resources, hence we may well compare it to a silent step. See for instance page 70 of Process theory based on bisimulation semantics.