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

[Shafran, Aury]

Hi Ted,

Nothing prevents that – it is legal. Within the extra parentheses, the (cond ? X : Y) is a conditional-expr (not a conditional-arg, and so it can’t have .NIL., and it has the semantics of an expression, not an argument).
It’s the same as how “call foo(  var )” has different semantics than “call foo( (var) )”. The former, var is the actual argument, the latter it is a primary in an expression where the expression (var) is the actual argument.

Thanks,
Aury

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

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<mailto:j3-bounces at mailman.j3-fortran.org>> on behalf of malcolm--- via J3 <j3 at mailman.j3-fortran.org<mailto: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<mailto:j3 at mailman.j3-fortran.org>>
Cc: malcolm at nag-j.co.jp<mailto:malcolm at nag-j.co.jp> <malcolm at nag-j.co.jp<mailto: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<mailto: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<mailto:j3 at mailman.j3-fortran.org>>
Cc: Johnson, Ted <tedj at hpe.com<mailto: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/96addecf/attachment-0001.htm>