[J3] Conditional expressions and arguments

[Robert Corbett]

I proposed allowing variables
and pointers to have conditional
forms when /DATA was deciding
the semantics of conditional
forms.  You were there.  /DATA
decided that only values and
arguments would have
conditional forms.  Other
members of DATA argued that
my proposed semantics made
the semantics of conditional
forms too complicated and too
error prone.

At this point in the development
of the 202X standard, I do not
want to touch anything concerning
conditional forms.  I am happy
with what is there now, and I do
not want to put it at risk.  This
is the third try at conditional
forms in which I have
participated.  It is the first
that seems likely to succeed.

Bob Corbett

> On Sep 1, 2021, at 5:46 PM, Van Snyder via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> 
> Conditional expressions can select variables, not just expressions.
> 
> This outcome would be useful in every variable-definition context, not only as actual arguments. Add <conditional-expr>  to R902 with appropriate constraints, at least "every <expr> in <conditional-expr> shall be a variable."
> 
> Was it proposed and rejected, or never proposed?
> 
> Does C1004 (in 21-007r2) need to include corank? Probably not, but it's worth pondering the question.
> 
> 10.1.4p7 needs to say something about coindexing, so that C1029 continues to be meaningful. Something like "A <conditional-expr> is coindexed if any of its <expr>s are coindexed." This would also cover other cases (if there are any) where a coindexed object is prohibited. If there are cases where a coindexed object is required, a more nuanced description would be needed, such as "potentially coindexed" (for C1029 and other cases where coindexing is prohibited) if any <expr> is coindexed, or "coindexed" if all of the <expr>s are coindexed where coindexing is required.
> 
> C1541 needs a caveat about explicit interface.
> 
> Some of the material in C1538-C1544 needs to apply to <data-target> (put it somewhere near C1028).
> 
> The syntax for conditional arguments introduced the .NIL. symbol.
> 
> The .NIL. outcome would be useful in an output list.
> 
> The .NIL. symbol was proposed in about 1986 to denote a disassociated pointer (because "nil" is the reserved word in Pascal for this purpose), especially for pointer initilization, for which there was no provision in Fortran 90:
> 
>     real, pointer :: X => .NIL.
> 
> or
> 
>     x => .NIL.
> instead of
>     x => NULL()
> or
>     nullify ( x )
> 
> Now that we have the .NIL. symbol, is there any reason not to use it for this purpose also? Of course, as an actual argument, it couldn't be used for generic resolution, and maybe not at all, because it would have no type. In pointer assignment or initialization, or as an actual argument in the non-generic case, its type, kind, and rank could be taken from those of the actual argument because explicit interface is required for pointer dummy arguments. This isn't really different from the NULL() case.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210901/a9c9debe/attachment.htm>