OCL21 — Issue: Syntax of Operation Call, Iterator, and Iterate Expressions

Description: Syntax for the above constructions is extremely ambiguous and it might involve backtracking.
Rationale: According to OCL specification

• self.f(x, y)
• Set {1,2,3}

  ->select(x, y| x+y = 3)

• Set {1,2,3,4,5,6}

  ->iterate(x; acc:Integer=0 | acc + x)
  describe an operation call, an iterator, and an iterate expression.
  In order to make the distinction between an iterator call and an operation call we need in this case a three token lookahead, starting from x. The problem gets even more complicated if we consider that an argument for an operation call can be an expression.
  In order to solve this problem, which is a potential source of problems for the implementation (error-prone, inefficiency aso), we think that these OCL constructs should contain some extra syntax markers. There are several choices:

• change the comma marker from iterator calls to something else, maybe a semicolon
• add a syntax marker to an iterator name
• do not allow the default types
  The above choices will allow to a deterministic parser to deal with the enumerated problems more efficiently. I do not agree with textual language in which variables are given a default type according to the context in which they are used, especially if these languages are design for industrial use. The same problems were in previous versions of C standard, which allowed implicit type int for variables in constructions like
  x;
  Now, the latest C standard states that variables with default type are not allowed.

The exposition of the OCL grammar is poor. In OCL 2.3 the status of iterator names was clarified as not-reserved words which makes the naive parsing approach outlined above more challenging. Instead it is necessary to pursue a syntactic parse and then resolve semantics in a tree walk. The 'problems' have not prevented OCL tool being built.
Users would not be well-served by a major resyntaxing to introduce new punctuation.
Disposition: Closed, no change