Enhance the experience of programming with booleans and integers

[TobiasWrigstad]

Add support for

• or
• not
• and (short-circuit)

Add support for negative integer literals

[TobiasWrigstad]

@albertnetymk I think this could be another good ticket for you once @EliasC or @kaeluka has walked you through the other one.

[EliasC]

A question/comment is about short-circuiting: what are the semantics when we have asynchronous method calls? If x is a reference to an active object, how should get x.foo() and get x.bar() be executed? It seems obvious that x.foo() should be called directly, but what about x.bar()? Do we wait with the second message send until we know the outcome of the first, or do we call them both and simply throw away the result (i.e. drop the get) if the first returns false?

The latter variant sounds most "parallel by default", but when considering side-effects, it could lead to surprising results. Consider for example the pattern

if (get x.isConsistent()) and (get x.sensitiveComputation())
  ...

With the latter approach, this would start the sensitive computation regardless of the state of x.

By the way, the current generated code does not short-circuit anything right now. Even false and (not false) is translated to:

int tmp1 = 0;
int tmp2 = 0;
int tmp3 = ! (tmp2);
int tmp4 = (tmp1 && tmp3);

[supercooldave]

In your example

if (get x.isConsistent()) and (get x.sensitiveComputation()) ...

The call x.sensitiveComputation() will not be made until after the first get returns, if at all. (This is ABS semantics)
Of course one could consider more parallel/speculative if-then-else semantics.

[albertnetymk]

I agree with this ABS semantics, which is more intuitive to me. BTW, what does ABS stands for? I can't find it by searching with ABS keyword.

The reason why the current boolean operator implementation doesn't take care of this short-circus is that we are translating Expr in encore to Statement in C. As I recall, either @EliasC or @kaeluka mentioned the argument behind this setup when they walked me through the code base, but I didn't comprehend it at that moment, still now.

It seems it's one overkill to me, for most Expr in encorce indeed have one-to-one correspondence with Expr in C.

[kaeluka]

ABS == "Abstract Behavioural Specification"

@albertnetymk: This seems to be one of the/the first papers on ABs: http://link.springer.com/chapter/10.1007/978-3-642-25271-6_8

I haven't read it myself though.

[TobiasWrigstad]

Great design questions!

Of course one could consider more parallel/speculative if-then-else semantics.

I would favour this! It seems more in the spirit of Encore, and short-circuiting boolean operators was always a hack anyway. Or at least encouraged hacky programming.

This would be less familiar than many mainstream languages, but at this point, that shouldn’t be a big concern.

A possible design would be to "guarantee nothing”, i.e., executing

expr1 and expr2 

may run both expr1 and expr2 in parallel (if deemed efficient), or it may start with either and run them sequentially in a short circuiting manner.

This feels more in the spirit of Encore than going with (what I initially suggested). Fewer guarantees means more opportunities for static//dynamic optimisation. If the programmer wants a short-circuiting and then she’d have to be explicit about it. We could eventually throw in an orelse statement (for some symbol) which is more clearly sequential.

—Tobias

[TobiasWrigstad]

Can someone make a decision on what to do here, document the choice in the spec (@kaeluka and @kikofernandez) and close this?

[supercooldave]

My view (decision) is that this fine-grained parallelism is not what we are aiming for, so lets just use the usual semantics of if-then-else and the usual short-circuiting and.

[EliasC]

Just a note to whoever is implementing this in the end. If we go with short-circuiting and/or we need to change the way C code is generated. As I said in July, right now false and (not false) is translated to:

int tmp1 = 0;
int tmp2 = 0;
int tmp3 = ! (tmp2);
int tmp4 = (tmp1 && tmp3);

The compiler probably needs to be made aware that it's translating a compound boolean expression and change the order in which it does the computations. This could work:

int tmp4 = ( ({tmp1 = 0; tmp1}) && ({tmp2 = 0; tmp3 = ! (tmp2); tmp3}));

[TobiasWrigstad]

@EliasC Is the current status that:

• We have or
• We have not
• We have and, but not short-circuiting?

If so, please close this.

@supercooldave — please open a separate ticket for that specific item.

[EliasC]

@TobiasWrigstad That's right!