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

[malcolm at nag-j.co.jp]

Hi Ted,

 

Aury has it right.

 

That is,

 

CALL SUB(   (a>0 ? 1 : 2) )

 

The “(a>0 ? 1 : 2)” is a conditional-arg, not a conditional-expr.

 

CALL SUB( ((a>0 ? 1 : 2)) )

 

The actual argument is the <primary> “( <expr> )”.

Within that <primary>, the “<expr>” is indeed a conditional expression,

But the actual arg is the primary that is “parenthesised expression”.

 

It is fine to use conditional expressions *within* an actual argument, they just cannot *be* an actual argument.

 

That is what I was trying to say when I said that there was no loss of functionality because one can just add extra parentheses, then it stops being a conditional-expr and so avoids any constraint.

 

Well, that was what we were trying to say with C1535, but we failed to get the words right – see earlier discussion. There was no time to write a paper for the February meeting about that (you will note that I had negative free time available, not even being able to finish my top priority task). However there should be time to get this done well before the June meeting.

 

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 11:33 PM
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 < <mailto:j3-bounces at mailman.j3-fortran.org> 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' < <mailto:j3 at mailman.j3-fortran.org> j3 at mailman.j3-fortran.org>
Cc: Johnson, Ted < <mailto:tedj at hpe.com> 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/20260312/599f3b43/attachment-0001.htm>