To: J3 J3/19-258 From: Van Snyder Subject: Syntax for conditional form Date: 2019-October-17 Reference: 18-274 1. Syntax of a conditional form =============================== Insert the conditional form as an entity of basic syntax, probably described in a new subclause between 6.2.5 Statement Labels, and 6.2.6 Delimiters, or in clause 9 Use of data objects: R611a <> IF ( ) THEN ( ) [ ELSE IF ( ) THEN ( ) ] ... [ ELSE ( ) ] END IF R611b <> <> <> C602a (R611a) If is not an actual argument that corresponds to an optional dummy argument, or is not a that appears within a that is an actual argument that corresponds to an optional dummy argument, ELSE ( ) shall appear. Insert a list item after (4)(b)(iii) in the description of constant expressions: (4') a in which every and every is a constant expression, Define the variable in several contexts to be a , with a constraint that is or , and if is it has the appropriate characterists etc.: NEWUNIT = ID = SIZE = IOLENGTH = in in in in Allow in Replace and in with Allow as the actual argument to PRESENT, in which every that is not a is an optional dummy argument. From 18-274 ============================================================ 6. Alternative syntax discussion Firstly, some design principles: (a) it should be visibly different from function syntax, because it is not a function; (b) it should be visibly different from operator syntax, because it is not an operation; (c) the difference should be "near the front" of the conditional expression so as to simplify parsing by computers as well as humans; (d) it should nest unambigously, and any parentheses needed should be part of the syntax (otherwise the "variable" case cannot be nested); (e) it should be readable & Fortran-like and not like line noise, -- readability is self-evidently desirable. Both (a) and (b) are desirable because (i) this does not follow the usual "evaluate the arguments/operands and call the function/do the operation", (ii) we do not want to affect operator priorities, and (iii) we do not want to invade the user namespace unnecessarily. Some possible (and some have actually been proposed) examples: (1) ? : satisfies (a)-(c), but not (d) or (e); (2) (? : : ?) satisfies (a)-(d), but not (e); (3) (? | : ?) satisfies (a)-(d), but is even worse on (e); (4) .ANDTHEN. .ORELSE. satisfies (a),(c),(e) but not (b) or (d), and only provides short-cut logical conditions, not general selection; (5) .IF. .THEN. .ELSE. .ENDIF. satisfies (a), (b), (d), but not (c) and is weak on (e). The "line noise" versions (2) and (3) are not definitive. I chose to put question marks to draw the distinction between the syntactic grouping (? ... ?) and ordinary parentheses (which turn variables into expressions). Other line noise variations are certainly possible if preferred. (It should also be noted that line noise does not do missing optional arguments very well, nor "ELSEIF" style chaining, so more work would be required if we choose that syntax.)