[J3] Question about the conditional expression syntax in 21-157r2 (+ some functionality questions)
Kurt W Hirchert
kurthirchert at gmail.com
Wed Jun 30 20:09:18 UTC 2021
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>
More information about the J3
mailing list