ALF 1.1 RTF Avatar
  1. OMG Issue

ALF11 — Inconsistent rules for local names defined in if and switch statement clauses.

  • Key: ALF11-43
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In subclause 9.8 "if Statements", under Semantics/Names it says "New local names may only be defined in the clause blocks of an if statement that has a final else clause and then only if the same names are defined in every clause." This effectively prevents the use of local names even for values needed only within just one clause of an if statement, or defining such local names at all in the case of an if statement without an else clause. There is a similar rule for switch statements.

    This is inconsistent with the rules for local names defined in, e.g., while statements. In subclause 9.10 "while statements", under Semantics/Names, it states "Local names within the body block of a while statement may be used within that block, but they are prohibited from being used outside the block. This is because they could be uninitialized if the while statement does not execute its body." This is a more convenient rule, covering basically the same concern for uninitialized local names as in the case of if statements.

    The rules for local names defined in if and switch statements should be eased and made consistent with the rule for the body of a while statement.

  • Reported: ALF 1.0 — Thu, 17 Dec 2015 23:06 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    Make local name definition rules consistent

    In 9.1 (Overview for Clause 9 Statements) it states that "The scope of...local names is generally from the point at which they are defined lexically to the end of the statement sequence, though there are special rules for conditional statements...and loop statements...." The simplest thing to do would be to just remove the special rules for conditional statements and loop statements. Rather than have (somewhat complicated and currently inconsistent) rules for what local names are defined after conditional and loop statements, local names first defined within conditional and loop statements would always continue to be defined in statements lexically after the conditional or loop statement. In the case that the conditional or loop clause within which the local name is defined is not actually executed, then the value of the local name would simply be null. This is also consistent with the overall design decision for Alf to not have "block scoping" of local names (per the general rule quoted above) and to not require declaration of local names before their first assignment.

    In order to map this, any clause of an if or switch statement that does not contain a definition of a name defined in some other clause would be mapped with a value specification action that generated a null value for the name. There would actually not need to be any update to the mapping of for loop statements, since, in this case, the loop node mapped from the statement already has an output pin for any name defined within it, and this will simply be empty ('null") if not set because the body of the loop did not execute.

    While not mentioned in the issue (or, currently, in 9.1), there are also similar special rules for names defined in the blocks of accept clauses of compound accept statements. These rules can also be removed, with mapping handled similarly to the case of conditional statements.

    Further, to be consistent, the rules for conditional logical and conditional test expressions should also be changed in a similar way. That is, local names defined only in a single the conditionally-evaluated operand of these expressions should be allowed, with their value being null if the operand is not evaluated. (This will also fix a problem with the current mapping of conditional logical expressions, which is done in terms of equivalent conditional text expressions, but which does not take into account that the restrictions on local names are not actually currently consistent between conditional logical and conditional test expressions.)

  • Updated: Thu, 22 Jun 2017 16:40 GMT