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

[Johnson, Ted]

Thanks, Robert and Malcom.

Yes, the .NIL. case, to me, is pretty cut and dried. I don't see how .NIL. could be anything other than .NIL., and if present it forces the conditional-arg interpretation of the construct.

However, if the .NIL. token is not present I do not see what could prevent "call foo(   ((( cond ? X : Y )))   )".

((cond ? X : Y)) is  a conditional-expr which is allowed as an actual arg. What rule prevents this as you suggest?

If the intent was to prevent this - did we miss adding a rule for something like "an actual-arg that is a conditional-arg shall not be a conditional-expr" or similar?

-ted

From: J3 <j3-bounces at mailman.j3-fortran.org> on behalf of malcolm--- via J3 <j3 at mailman.j3-fortran.org>
Date: Tuesday, March 10, 2026 at 6:48 PM
To: 'General J3 interest list' <j3 at mailman.j3-fortran.org>
Cc: malcolm at nag-j.co.jp <malcolm at nag-j.co.jp>
Subject: Re: [J3] conditional-arg and the handling of additional (expr) parens

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/96717bf6/attachment-0001.htm>