[J3] conditional-arg and the handling of additional (expr) parens

[malcolm at nag-j.co.jp]

Hi Ted,

 

Apart from agreeing with Robert (except possible C1535 is *intended* to
resolve a syntactic ambiguity, but the wording is poor to say the least). I
thought I would try to directly answer your questions, and explain our
thinking.

 

<<< 

I believe something like this should be rejected - attempting to turn .NIL.
into an expr, or trying to turn the whole conditional-arg into an expr. Yes,
or no?

 

call foo( ((cond ? (X) : (.NIL.))) )

>>> 

 

Yes it is an error - does not follow the BNF.

 

<<< 

I don't see how ((.NIL.)) could ever be correct based on 25-007r1

>>> 

 

I agree, it cannot ever be correct. The .NIL. token is only permitted as the
only token between the question mark and colon of a conditional argument, or
the colon and closing parenthesis of a conditional argument. In other
contexts, .NIL. could be the user-defined operator .NIL. - no ambiguity
because a user-defined operator cannot be immediately followed by a colon or
right parenthesis.

 

<<< 

Since a bare ((.NIL.)) doesn't appear to be valid , I would assume call foo(
(( .true. ? .NIL. : X)) ) hits up against C1535 as well. If not, why?

>>> 

 

It is invalid because the conditional-arg BNF is not reachable when enclosed
in parentheses, preceded by an operator, etc etc etc. The condition-arg BNF
is only reachable as an entire actual argument. C1535 does not come into
play.

 

<<< 

Also I wanted to see if "C1535 An actual-arg that is an expr shall not be a
variable or a conditional-arg" was intended to prevent converting a whole
conditional-arg into an expr.

>>> 

 

Per previous discussion on the mailing list, C1535 was intended to say that
an actual argument can be a conditional-arg but cannot be a
conditional-expr, because that would be ambiguous. The words are not quite
right though. In all expression contexts other than as a whole actual
argument, one can have a conditional-expr. The conditional-expr BNF does not
include the .NIL. token.

 

There is no loss of functionality from the disambiguation - if one wants to
pass the value of a conditional expression as an actual argument, just
wrapping it in an extra set of parentheses suffices to avoid the ambiguity.

 

Hope I have helped and not confused things further.

 

Cheers,

--

..................Malcolm Cohen, NAG Oxford/Tokyo.

 

From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Johnson, Ted via
J3
Sent: Wednesday, March 11, 2026 4:48 AM
To: 'General J3 interest list' <j3 at mailman.j3-fortran.org>
Cc: Johnson, Ted <tedj at hpe.com>
Subject: [J3] conditional-arg and the handling of additional (expr) parens

 

I'm trying to understand the impact of adding some wrapping parens to create
an expr, within the context of conditional arguments.

 

I believe something like this should be rejected - attempting to turn .NIL.
into an expr, or trying to turn the whole conditional-arg into an expr. Yes,
or no?

 

call foo( ((cond ? (X) : (.NIL.))) )

 

I don't see how ((.NIL.)) could ever be correct based on 25-007r1.

 

Also I wanted to see if "C1535 An actual-arg that is an expr shall not be a
variable or a conditional-arg" was intended to prevent converting a whole
conditional-arg into an expr.

 

Since a bare ((.NIL.)) doesn't appear to be valid , I would assume call foo(
(( .true. ? .NIL. : X)) ) hits up against C1535 as well. If not, why?

 

Thanks.

 

-ted

 

 

 

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