8 February 2005 J3/05-104r1 Subject: Embed a decision within an expression From: Van Snyder Reference: 03-258r1, section 2.8.1; 04-192, 04-357r1 04-393 Number: TBD Title: Embed a decision within an expression. Submitted By: J3 Status: For consideration. Basic Functionality: Provide a mechanism to embed a decision within an expression. Rationale If one needs to embed one of several values within an expression, depending upon a condition, the available methods are o Nearly duplicate the statement containing the expression with a different entity within the different instances and select between them using the condition, o Copy one of the values into a temporary variable depending upon the condition and use that temporary variable within the expression, or o Associate a pointer with one of the variables depending on the condition~--- if the entities to be selected are variables. In the first case, assuming m alternatives for each of n entities within the statement, m^n instances of the statement are needed. In the second case, the program must endure the expenses of an auxiliary variable and the time to copy it, both of which could be substantial in the array case. In the third case, which only works if the values are variables, the variables have to have the pointer or target attribute, which could have negative implications for optimization. The same considerations apply if one needs to associate one of several entities as an actual argument. It's even worse in the case of using a temporary variable if the associated dummy argument does not have INTENT(IN), because one needs to do the selection and copying twice. It would be useful to be able to embed a decision within an expression. This would avoid all of the problems outlined above. In the case of an actual argument or a target in a pointer assignment, it would be useful to allow procedures or procedure pointers to be the alternative entities. Estimated Impact: This is part of the proposal in J3 paper 04-393, whose antecedent was 04-357r1. At J3 meeting 169, the proposal in 04-357r1 was judged to be at 4 on the JKR scale. Surely this proposal, being only part of the previous one, is not larger. Detailed Specification: Provide a mechanism, called here a ``conditional form,'' to embed a decision within an expression. The syntax shall provide for a condition and two alternative entities. If an actual argument is a conditional form, and the alternatives are either variables or procedures, to be useful the selected entity itself, rather than the value of it, must become the actual argument. Indeed, in the case of an argument that is a procedure, it does not have a value. No matter what syntax is used, if there is no special description it cannot be called a function reference or an operation, because the result would be a value separate from the desired entity itself. One might think that it would be acceptable to call it a function reference or operation that returns a pointer associated with the appropriate alternative entity, but that won't work either, because of the absurd outcome of interp F95/74. That would also require the alternatives to have the target attribute, which would have negative implications for optimization. Maybe a new term that doesn't carry the baggage of ``pointer'' or ``target,'' such as ``referent,'' could be used to describe the result, allowing the form to be called a function reference or an operation. That seems like a lot of work to invest for one purpose. It is important that the alternative that is not selected, and all expressions within it, are not evaluated. The condition that selects between the alternatives may be a proxy indicating the nonexistence of values necessary for these evaluations. If one of the alternative entities has the pointer attribute and the other does not, the one that does not shall have the target attribute, and the result has the target attribute. If the alternative that has the pointer attribute is selected, the result is its target. Otherwise, the alternative entities shall have the same characteristics. If one of them is the NULL intrinsic without an argument, the result characteristics are inferred from the other. If they are both the NULL intrinsic without an argument, the result characteristics are inferred from the context of the appearance of the conditional form, exactly as would be the case if the NULL intrinsic had appeared on its own instead. Examples: Several syntaxes are possible. Two under consideration are similar to a function reference, and similar to an operator. A = B + IF ( X > 0.0, SQRT(X), 0.0 ) or A = B + X > 0.0 ? SQRT(X) : 0.0 History: