Closed anatoliykmetyuk closed 9 years ago
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.
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.
Consider the following script:
Here, the following happens:
break
makes;
to have Success immediately on its activation+
receives Success message+
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:
Because
+
emitsSuccess
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 theprintln("World")
execution. Hence, causing an infinite activation loop without anything every outputted.