ALF 1.1 RTF Avatar
  1. OMG Issue

ALF11 — Indexing in sequence access expressions should be 0-based

  • Key: ALF11-14
  • Legacy Issue Number: 16597
  • Status: closed  
  • Source: IBM ( Mattias Mohlin)
  • Summary:

    The proposal is to change

    For example, given the sequence
    a = Integer[]

    {10, 20, 30, 40}
    the sequence access expression a[3] evaluates to 30. Note that indexing is from 1.


    For example, given the sequence
    a = Integer[]{10, 20, 30, 40}

    the sequence access expression a[2] evaluates to 30. Note that indexing is from 0.

    Indexing in sequence access expressions should be 0-based. The main reason is that most popular languages use 0-based indexing. In particular this is true for Java, which Alf is syntactically compatible with at the minimum conformance level. Besides from confusing users, 1-based indexing makes it unnecessary hard to copy/paste existing Java code to be reused in an Alf context.
    Also, the ALF standard says the following in the introduction: "Alf has a largely C-legacy (“Java like”) syntax, since that is most familiar to the community that programs detailed behaviors."
    In the same spirit of being familiar to the community, Alf really should use 0-based indexing.

  • Reported: ALF 1.0b1 — Fri, 14 Oct 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    Add indexing annotations

    In UML, indexing of ordered multiplicity elements is clearly 1-based. Further, while the issue only suggests that 0-based indexing be used for sequence access expressions, it would be inconsistent to use 0-based indexing for that but not also for indexing in relevant sequence and collection library functions (e.g., at, includingAt, etc.). However, the Alf sequence and collection functions are intentionally similar to corresponding functions in OCL, which are also 1-based.

    Nevertheless, the possible confusion between 0-based indexing and 1-based indexing is a reasonable concern, particularly the difficulty mentioned in the issue description with copying and pasting existing C-like code that might be syntactically compatible with Alf but would assume 0-based indexing. A compromise would be to provide means for both 0-based and 1-based indexing in Alf. The following options were considered to allow this.

    1. Provide alternate notations and library functions for 0-based and 1-based indexing.
      Pro: This option would allow the free intermixing of the use of 0-based and 1-based indexing, at the preference of the modeler, with the syntax clearly showing which is being used at any one point.
      Con: This option would add complexity in the language, with duplicative notations and functions for essentially the same capabilities. Further, the current indexed notation (such as "a[i]") would need to become 0-based, since that is the C-like notation used in other languages, with an alternate notation (such as "a@1") introduced for 1-based indexing, which would be backwards incompatible. There is a similar problem with certain existing 1-based-indexing collection functions (such as addAt) that have the same names as 0-based-indexing library operations in Java.
    2. Allow implementations to have a global option for using 0-based or 1-based indexing or allow them as different conformance points.
      Pro: This option would require no syntactic change to Alf and would be a simple semantic variation to implement.
      Con: This option would mean that syntactically identical Alf code within identical UML models would execute differently in different implementations, which would violate the intent of rigorous, standard semantics for Alf. (The only semantic variation currently allowed in Alf is that allowed by the fUML specification.)
    3. Leave indexing from 1 as the default, but add an IndexFrom0 stereotype to the existing ActionLanguage profile. When this stereotype was applied to an Alf unit, or to a UML namespace containing Alf text somewhere within it, then indexing would be 0-based within that scope.
      Pro: This option would allow 0-based indexing to be used within as wide a scope as desired by the modeler, but its use would still be identified explicitly in the model.
      Con: When looking at an Alf text snippet within a wider UML model, it would not be clear whether 0-based or 1-based indexing was being used, without looking at all containing namespaces to see if the stereotype was applied. Also accidentally removing an application of the stereotype, or moving Alf text outside of its scope, could significantly change the semantics of the Alf text, without any local change being made.
    4. Leave indexing from 1 as the default, but introduce a statement-level @indexFrom0 annotation such that 0-based indexing was used within the statement so annotated (which could, e.g., be a block statement containing a sequence of nested statements, for all of which 0-based indexing would apply).
      Pro: With this option, the use of 0-based indexing would be clearly identified locally in the Alf text where it is used.
      Con: If 0-based indexing is to be used generally or widely within a UML model, with the Alf text spread throughout the model, then the annotation would need to be applied within each snippet of Alf that was to use 0-based indexing. It would also not be possible to specify indexing from 0 for property initialization or other uses of Alf expressions outside the context of Alf statements.

    After consideration, it was decided to select option 4. The disadvantage of this option is that, of the options considered, it makes it the most difficult to use 0-based indexing generally with Alf within a UML model. However, 1-based indexing is what is consistent with the underlying UML semantics of Alf, and the intent is not to accommodate moving away from this, but, rather, to allow the easy migration from existing pre-Alf action code, when appropriate. Option 4 allows for this, while also clearly marking, in a standard way, those areas of Alf text using (non-default) 0-based indexing.

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