To: J3                                                     J3/20-142
Subject: Conditional expressions - specifications
From: Malcolm Cohen
Date: 2020-October-06
Reference: 18-274


1. Introduction

This paper contains the formal specifications for the conditional
expressions feature. For background, please see 18-274.

By design, MERGE does not provide this functionality, as conceptually all
of its arguments are evaluated. Likewise, MERGE provides an elementwise
array merging facility, which this feature does not.

The "conditional arguments" part of the feature could be omitted this time
around if there is insufficient time or other resources. But as the syntax
is nearly identical, and it solves some real problems, we should add it
unless difficulties arise.


2. Formal specifications: conditional expressions

(1) Conditional expressions shall take the conceptual form:

    IF condition THEN then-consequent-expr ELSE else-consequent-expr ENDIF

    Note this is not a specification of the syntax, just the concept.

(2) The condition shall be a scalar logical expression.

(3) The consequent expressions shall have the same declared type, kind type
    parameters, and rank. Or, shall both be CLASS(*) with the same rank.

(4) The consequent expressions may have different length type parameters,
    shape, and dynamic type. Thus the conditional expression's declared
    type, kind type parameters, and rank are known at compile time, but
    the length type parameters and shape might not be (as usual).

(5) A conditional expression is a primary, and its syntax shall not require
    any change to the expression precedence rules.

(6) Only one of the consequent expressions is evaluated; this includes any
    nested expressions e.g. subscripts.

(7) If all three expressions are constant expressions, a conditional expr
    is also a constant expression.
Comment: Technically, since only one of the consequent expressions will be
         evaluated we need only require that one to be constant; however,
         that would be very confusing and so is rejected.

(8) Conditional expressions may be nested.

(9) If the syntax chosen lends itself to chaining, conditional expressions
    may be chained. That is, have the conceptual form
        IF condition THEN then-consequent-expr
        ELSEIF condition THEN elseif-consequent-expr-n ...
        ELSE else-consequent-expr
        END IF
    This is clearly easy to do (and understand) for a keyword-oriented
    syntax, but might not be with a more concise (and opaque) syntax.
    OTOH, a more concise syntax makes nesting less painful too.


3. Formal specifications: conditional arguments

(11) Conditional arguments may be used to conditionally pass variables as
     actual arguments.

(12) A conditional argument has the same syntax as a conditional expression
     except that if the dummy argument is optional, the ELSE consequent
     argument may be omitted.

(13) A conditional argument has the same type/kind/rank rules as for
     conditional expressions.

(14) A conditional argument is a variable if and only if all consequent
     arguments are variables.
(14alt) A conditional argument is a variable if and only if the selected
        consequent argument is a variable.

(15) If the dummy argument is INTENT(OUT) or INTENT(INOUT), the consequent
     arguments shall all be definable variables.

(16) An "unevaluated" consequent argument does not have any nested
     expressions, such as subscript expressions, evaluated.

(17) A conditional argument may be chained (if the syntax chosen is
     suitable) but may not be nested. That is, a conditional expression
     appearing as a consequent argument is an expression.
     Comment: This is to keep the argument form as simple as possible.

(18) Every consequent argument shall satisfy the requirements of the dummy
     argument. For example, if the dummy is allocatable or a coarray, all
     consequent arguments need to be allocatable or a coarray. Furthermore,
     if a restriction such as "shall not be coindexed" applies to the
     actual argument, it applies to the dummy arguments.

Comment: The consequent arguments may, in principle, have different
         attributes such as allocatable, pointer, and corank, as long as it
         is an "ordinary" dummy that accepts all of these.

===END===