[J3] Question about the conditional expression syntax in 21-157r2 (+ some functionality questions)

[Kurt W Hirchert]

I had been intending to write my own message with a similar suggestion.  
Note that if elseif-chaining is built into the syntax for conditional 
expressions and you remove the requirement for the parentheses, then
cond ? expr : cond2 ? expr2 : expr3
could be interpreted as what was
      (cond ? expr : cond2 ? expr2 : expr3)
or as
      (cond ? expr : (cond2 ? expr2 : expr3))

This is an ambiguous parse, but both interpretations have the some 
semantic meaning, so the easy "fix" would be to eliminate the 
elseif-chaining in the syntax rule and just do it by the repeated 
application of the simple rule.  Presumably, this would actual simplify 
the description of the semantics associated with this syntax.

Allow me to offer a couple of other motivating examples.  Imagine you 
wish to write code the emulates the BACK argument in SCAN, VERIFY, and 
INDEX.  With the parentheses required this might look like
IF ((PRESENT(BACK) ? BACK : .FALSE.)) THEN
     # backwards case
   ELSE
     # forwards case
   END IF
with one set of parentheses required by the IF statement and the other 
by the conditional expression.  I find the double set of parentheses 
annoying.  For another example, consider a three item short-circuit 
.AND..  With required parentheses, this would look like
IF ((L1() ? (L2() ? L3 : .FALSE) : .FALSE.)) THEN
If they are not required, it could be reduced to
IF (L1() ? L2() ? L3 : .FALSE : .FALSE.) THEN
I find the latter more clearly expresses the conditional .AND. chaining, 
but others may disagree.

-Kurt

P.S. I wrote this using C-like conditional expressions because Milan 
did, but I was under the impression that the version with "->" replacing 
"?" was more popular.  It certainly would be with me, both because it 
avoids "using up" the "?" character and because I find
IF (L1() -> L2() -> L3 : .FALSE : .FALSE.) THEN
a bit more intuitive than the version with "?".

P.P.S. Since people keep saying that the requirements for this feature 
have already been approved, I have a couple of questions about its 
semantics:

1. Robert Corbett has repeatedly suggested that this should be 
applicable elementally (if the cond is array-valued), but I have seen 
not indication whether this suggestion has been accepted.  I definitely 
see the value in it, but I note that it would impose added constraints 
on the similarity of the true and false expression.  I think we could 
"have our cake and eat it too" if the matching rules are slightly 
different different depending on whether or not the condition is scalar:
a. If the condition is scalar, the rank, type, and kind type parameters 
of the true and false expressions would be required to agree, but the 
extents and other type parameters could differ, allowing, for example,
(cond ? "true" : "false")    # differing lengths
b. If the condition is not scalar, the type and all type parameters of 
the true and false expressions would be required to agree, and those 
expressions would be required to be conformable with the condition 
(which determines the shape of the result).

2. Is this strictly an expression, or might something like
      (cond ? var : var2)
be used to select which _variable_ is to be associated with an 
INTENT(INOUT) or INTENT(OUT) dummy argument?  [If a straw vote is needed 
on this point, you might want to select between the positions "This 
should be allowed in F202X", "This should not be allowed in F202X, but 
we should not preclude its being allowed in a future revision", and 
"This feature should never be used in this way".]

On 6/30/2021 12:53 PM, Milan Curcic via J3 wrote:
> Hi Malcolm,
>
> In 21-157r2, you wrote:
>
> > Conditional expression with elseif-chaining:
> > ( cond ? expr : cond2 ? expr2 : expr3 )
>
> Are parens required? It seems to me that they don't need to be and we 
> could write:
>
> Conditional expression with elseif-chaining:
> cond ? expr : cond2 ? expr2 : expr3
>
> and if a programmer likes parens as a visual, they can add them.
>
> What do you think?
>
> Thanks,
> Milan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210630/db38f307/attachment-0001.htm>