then-else and ==> operators

[AndreVanDelft]

~~> depends on both "do-then-else" and script return values

[AndreVanDelft]

Semantics of then-else

do-then-else is much like the ternary operator ...?...:... in C: do x then y else z

• activates x
• on each success y is activated (just like with ;); actions in x exclude the ones in y and vv.
• if x deactivates without success z is activated

The then- and else parts should be optional.

Grammatical priority

The grammatical priority should be consistent with the if-then and if-then-else construct and with Scala standards.

SubScript added a then for the if-construct, so that there is more symmetry with else, and the condition does not need to be parenthesized any more.

Also the "old" if and if-else binded strongly so that we needed extra parentheses in

if(cond) (a+b) else (c;d)

The construct in Scala only requires braces for the part with a semicolon:

if(cond) a+b else {c;d}

In this respect the SubScript parser was to be adapted to the Scala rule. The script speedButtonInput in LifeFrame is rewritten from

speedButtonInput = if (speed>minSpeed) speedDecButton
                 + if (speed<maxSpeed) speedIncButton

into

speedButtonInput = (if speed>minSpeed then speedDecButton)
                 + (if speed<maxSpeed then speedIncButton)

Dataflow operators

Built on do-then-else there are 3 left associative arrow operators:
binary ~~> and ~/~> and ternary ~~>....~/~>.

a ~~> b ~/~> c is parsed as the ternary form. Its meaning is comparable to the ternary operator .... ? .... : .... in C and Java; one may (or may not) omit either the "then" or the "else" part.

[AndreVanDelft]

then-else has become do-then-else; the then and the else parts are optional, but not both at the same time.