Precedence of ternary conditional expression in Clafer

[wasowski]

I have done a bit of testing on if-then-else with clafer compiler. I tried both 0.3.6.1 and 0.4.0. They do differ a bit in handling my examples, but both seem to require that the subexpressions are (almost?) always parenthesized as in if (...) then (some ...) else (a.b.c) .

This is quite non-standard in programming languages. Usually the ternary operator gets a very low precedence and if - then -else can be written without parenthesis. I think this is both in C like languages (? :) and in ML-like languages (if-then-else).

This is not super urgent but we could consider looking into the grammar to fix it. Usability for users would improve slightly.

[mantkiew]

I looked at the grammar and it's not clear where to move the if/then/else rule. Should it have the lowest possible precedence?

E.g., we could allow the code

if x then some y else all a1; a2 : A | a1 > a2

to have that, we would have to make the grammar like this:

EImpliesElse.   Exp ::= "if" Exp "then" Exp "else" Exp ;
EDeclAllDisj.   Exp1   ::= "all" "disj" Decl "|" Exp1 ;
EDeclAll.        Exp1   ::= "all"        Decl "|" Exp1 ;
EDeclQuantDisj.  Exp1   ::= Quant "disj" Decl "|" Exp1 ;
EDeclQuant.      Exp1   ::= Quant        Decl "|" Exp1 ;
EGMax.          Exp2  ::= "max" Exp3 ;
EGMin.          Exp2  ::= "min" Exp3 ;
....
etc.

The grammar would allow code like this (I suppose because it is right associative by default).

if 
   if x then z else y
   then some x
   else if no w
             then if z then u else o
             else some p

which would put parenthesis as follows

(if 
   (if x then z else y)
   then (some x)
   else (if (no w)
             then (if z then u else o)
             else (some p)
           )
)

[mantkiew]

See test cases:

• ifthenelse.cfr,
• nested-ifthenelse.cfr.