Stacked Execution of events
14 views
Skip to first unread message
tyr.b...@gmail.com
Jun 13, 2019, 4:18:45 PM6/13/19
to The Programming Language Céu
I was reading the online tutorial, page 13 "Internal Events: Stacked Execution" and had the following question.
What is the reason that when emitting an event, the execution of the current trail immediately halts and only resumes after completing the trails that await that event?
Why not the following semantics? After emitting an event, the exeuction of the current trail continues (possibly emitting more events) until it awaits for some other event. Only then céu starts executing the parallel trails that await the emitted events.
Are there reasons why the second semantics would be undesirable?
What is the reason that when emitting an event, the execution of the current trail immediately halts and only resumes after completing the trails that await that event?
Why not the following semantics? After emitting an event, the exeuction of the current trail continues (possibly emitting more events) until it awaits for some other event. Only then céu starts executing the parallel trails that await the emitted events.
Are there reasons why the second semantics would be undesirable?
Francisco Sant'anna
Jun 17, 2019, 11:51:51 AM6/17/19
to ceu-...@googlegroups.com
On Thu, Jun 13, 2019, 17:18 <tyr.b...@gmail.com> wrote:
I was reading the online tutorial, page 13 "Internal Events: Stacked Execution" and had the following question.
What is the reason that when emitting an event, the execution of the current trail immediately halts and only resumes after completing the trails that await that event?
It seems to us that the stack-based semantics is more useful in practice.
You emit an event and expects its effect to complete before proceeding to the next statement just like a you do for function calls.
Any dependency pattern, e.g., update some value in response to a chain of events and then access it, depends on this this semantics.
Why not the following semantics? After emitting an event, the exeuction of the current trail continues (possibly emitting more events) until it awaits for some other event. Only then céu starts executing the parallel trails that await the emitted events.
Are there reasons why the second semantics would be undesirable?
Do you see any reasons why the first would be undesirable?
tyr.b...@gmail.com
Jun 18, 2019, 2:35:26 PM6/18/19
to The Programming Language Céu
I agree with you. I came up with the following example that shows that completing the effects of an event immediately is desired.
```
event none e;
var int v = 0;
par/and do
loop do // a simple loop that
await e; // when 'e' occurs
_printf("%d\n", v); // prints value of 'v'
end
with
v = v + 1;
emit e; // other trail prints '1'
v = v + 1;
emit e; // other trail prints '2'
end
escape v;
```
With the semantics of Céu, this prints '1' '2'. While with the semantics I proposed this would print '2' '2' which is not what you would intuitively expect.
A minor note is that the programmer needs to be aware that trails can not only halt on "await" but also on "emit". But I guess this is something that can be taught.
Op maandag 17 juni 2019 17:51:51 UTC+2 schreef Francisco Sant'Anna:
```
event none e;
var int v = 0;
par/and do
loop do // a simple loop that
await e; // when 'e' occurs
_printf("%d\n", v); // prints value of 'v'
end
with
v = v + 1;
emit e; // other trail prints '1'
v = v + 1;
emit e; // other trail prints '2'
end
escape v;
```
With the semantics of Céu, this prints '1' '2'. While with the semantics I proposed this would print '2' '2' which is not what you would intuitively expect.
A minor note is that the programmer needs to be aware that trails can not only halt on "await" but also on "emit". But I guess this is something that can be taught.
Op maandag 17 juni 2019 17:51:51 UTC+2 schreef Francisco Sant'Anna:
Reply all
Reply to author
Forward
0 new messages