Several of the operations in the collection classes require that two general objects can be compared for equality (one example is Collection::includes).
The standard should clarify how the equality comparison is done. Will the equality operator == always be used, or is it possible for the user to define the condition for how to compare objects of a user-defined class?
If the equality operator == is used for all objects, this will limit the usefulness of the collection library. For some kinds of objects a comparison based on object identity is not appropriate.
We propose that object identity comparisons is only the default for class objects, and that it can be customized by defining an equals operation in the class.

Why not include Model to Text for generating ALF for (a subset of) UML?

It would be very good if the ALF standard could support a syntax for defining local names with "composite semantics". That is, names for which the value will be automatically destroyed when leaving the current scope. As it is now, objects for local names need to be created explicitly with 'new' and then destroyed explicitly by calling a destructor on the object. It is a very common pattern that objects only should live while inside a particular scope, and then it is error-prone to have to destroy all such objects manually.
Note that the proposed syntax must be within the minimum conformance subset of the language. Our proposal is to use a syntax similar to the following:

auto<MyClass> var = new MyClass();

When we read chapter 9.12 we conclude that the traditional for-statement of languages such as C/C++ and Java, is not supported by Alf. Only for-statements that iterate based on collections are supported now.
We think the traditional for-statement with loop variable initialization, termination condition and iteration step should be supported. For example
for (Integer i = 0; i < x; i++)

We are missing an Alf statement corresponding to the UML RaiseExceptionAction. Such a statement is needed in order to raise exceptions from Alf code. The syntax should be within the minimum conformance subset ("throw").

There should be an Alf statement that allows to define an exception handler for a block. The syntax should be within the minimum conformance subset (try - catch).

Why not include Model to Text for generating ALF for (a subset of) UML?

Defer

The RTF agrees that this is an issue worth considering, but, due to lack of time, decided to defer its resolution to a future RTF working on this specification.

When we read chapter 9.12 we conclude that the traditional for-statement of languages such as C/C++ and Java, is not supported by Alf. Only for-statements that iterate based on collections are supported now.
We think the traditional for-statement with loop variable initialization, termination condition and iteration step should be supported. For example
for (Integer i = 0; i < x; i++)

Defer

The RTF agrees that this is an issue worth considering, but, due to lack of time, decided to defer its resolution to a future RTF working on this specification.

There should be an Alf statement that allows to define an exception handler for a block. The syntax should be within the minimum conformance subset (try - catch).

Defer until fUML provides exceptions

The semantic basis for Alf is fUML, and, as of v1.2.1, fUML does not provide a specification of the semantics for exceptions. While exception raising and handling would be useful in Alf, its inclusion is deferred until the semantics for this are specified in fUML.

We are missing an Alf statement corresponding to the UML RaiseExceptionAction. Such a statement is needed in order to raise exceptions from Alf code. The syntax should be within the minimum conformance subset ("throw").

Defer until fUML provides exceptions

The semantic basis for Alf is fUML, and, as of v1.2.1, fUML does not provide a specification of the semantics for exceptions. While exception raising and handling would be useful in Alf, its inclusion is deferred until the semantics for this are specified in fUML.

It would be very good if the ALF standard could support a syntax for defining local names with "composite semantics". That is, names for which the value will be automatically destroyed when leaving the current scope. As it is now, objects for local names need to be created explicitly with 'new' and then destroyed explicitly by calling a destructor on the object. It is a very common pattern that objects only should live while inside a particular scope, and then it is error-prone to have to destroy all such objects manually.
Note that the proposed syntax must be within the minimum conformance subset of the language. Our proposal is to use a syntax similar to the following:

auto<MyClass> var = new MyClass();

Defer

The RTF agrees that this is an issue worth considering, but, due to lack of time, decided to defer its resolution to a future RTF working on this specification.

Several of the operations in the collection classes require that two general objects can be compared for equality (one example is Collection::includes).
The standard should clarify how the equality comparison is done. Will the equality operator == always be used, or is it possible for the user to define the condition for how to compare objects of a user-defined class?
If the equality operator == is used for all objects, this will limit the usefulness of the collection library. For some kinds of objects a comparison based on object identity is not appropriate.
We propose that object identity comparisons is only the default for class objects, and that it can be customized by defining an equals operation in the class.

Defer

The RTF agrees that this is an issue worth considering, but, due to lack of time, decided to defer its resolution to a future RTF working on this specification.

The proposal is to change

For example, given the sequence
a = Integer[]

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.

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.

Assume we have an object typed by a class C which inherits another class D. If an object of C is destroyed by calling an explicit destructor, and this destructor does not contain any call to a super destructor of D, what will then happen? Will the object be destroyed without calling any destructor in the super class? This would seem error-prone. We need a clarification whether this is allowed or not, and if it is allowed how the super-class part of the object will be destroyed.

Close, with explanation

In 10.5.3.2, it clearly states

When an object is destroyed using an explicit destructor, the default destructor behavior is not performed, so any desired calls to superclass or composite part destructors must be made explicitly.

There is no requirement that any superclass or composite part destructor calls actually be made, however – to do so is a modeler responsibility. The intent is that an explicit destructor overrides the default behavior, and it is up to the modeler to decide what the replacement behavior should be, which includes whether or not to call any other destructors. This is similar to the freedom allowed in a constructor on whether or not to call superclass constructors.

Whether or not an explicit destructor makes calls to any relevant superclass or composite part desctructors, a destructor call on an object always results in the entire object being destroyed. That is because, as stated in 8.3.10, the actual destruction of the object happens "after the completion of the call to the destructor", regardless of what the destructor does or does not do. And this destruction happens using a destroy object action with isDestroyOwnedObjects=true (see 17.10), so composite parts are also always destroyed, whether or not destructors have been called on them.

In the section "Composition" of 10.5.2 we have the following example:

class C

When an instance of class C is destroyed, the object it holds for attribute b will also be automatically destroyed, but the object it holds for attribute a will not.

However, assume now that the class B has no accessible destructor. For example, it may have an explicit destructor with parameters and/or non-public visibility so that the default destructor is no longer available (see 10.5.3.2). What will then happen when the C instance is destroyed?
We think there should be a constraint that types of composite attributes must have a public constructor with no parameters. If this is missing, it is a static semantic error.

Close

If a class is defined using Alf, as is the example class in the description of this issue, then it will always have at least one destructor, and its instances can only be destroyed using Alf by calling a destructor. Even c.destroy() will call the default destructor, if no explicit destructor has been specified.

Since C::a is not composite, the default destructor will not call the A destructor on a – this is basic to the semantics of composite attributes in Alf, and may be exactly what is desired. If it is desired that the object in a be destroyed, then it is the responsibility of the modeler to provide an explicit destructor that does this. There does not seem any reason to make this mandatory.

On the other hand, if an instance of c is destroyed using a destroy-object action, outside of Alf, then the semantics for that will, presumably, be as given by fUML. In that case, there is even an option on the action to not destroy objects referenced via composite attributes and links. No rules in Alf can prevent possible problems from using such low-level actions.

The non-deterministic behavior is an issue to evaluate the correctness of algorithm written in ALF. it is very difficult to test and check non determinist behavior. The formal approach use for ALF is the good right but also support a determinitic behavior.

Sequential if statement clauses are deterministic

Alf syntax allows both sequential clauses (if/else if/else) and concurrent clauses (if/or if). As the name indicates, the execution of sequential clauses is sequential and determinate, just as for a traditional if statement. So, one can avoid introducing indeterminate behavior by just not using concurrent clauses.

(One can also annotate an if statement as @determinate, which indicates that at most one condition will evaluate to true. This asserts determinate behavior even when using concurrent clauses. However, it is a modeler responsibility to ensure this assertion is true, and there is no required language check of this.)

CreateAction links to only one classifier. It should be multiple.

Decline

Summary: A synchronous action is defined as a request where the sending
object pauses to wait for results. Synonym: synchronous request [OMA].

1) The OMA is not specific on this issue, but the understanding in
CORBA is that a request is only specific with respect to a thread.

• So, in UML, does the sending object truly pause to wait for results?
• Or is it just a thread of that object that pauses for results?
  (in that case, the definition should be clarified)

2) Another possible interpretation of a synchronous action is that
such a request is always associated with a response (contrarily to
an asynchronous request which has no associated response ?).
The sending object has then an obligation to collect that response.

If that interpretation was true, then synchronous action would
map to both synchronous request and def

Fixed in adopted spec

Currently, the signature of CollectionFunctions::removeAll is:

removeAll<T> (inout seq: T[*] sequence, in element: T)

According to the associated description, it should probably be (taking into account issue 16426 which requires a return parameter):

removeAll<T> (inout seq1: T[*] sequence, in seq2:T[*] sequence) : T[*] sequence

And the description should also be corrected to read “Remove all elements of seq2 from seq1” (“from” instead of “to”).

agreed

I think there is a typo page 184:

Difference

(in seq1: any[*] sequence,

in seq2: any[*] sequence nonunique):

any[*] sequence

it’s not necessary to show “nonunique” for seq2.

I don’t recall having seen something about that in existing issues (sorry if I missed it). I’ll raise an issue for that.

agreed

The Alf standard says
"A return statement may only be used within the definition of a behavior that has a return parameter."
We think it must be allowed to always use a return statement. If the context behavior has no return parameter then no expression should be provided in the return statement.

This is a duplicate of Issue 16419.

The signature of replaceOne is :
replaceOne<T> (in seq: T[*] sequence, in element: T, in newElement: T): T[*] sequence

The direction of parameter “seq” should probably be “inout”.

agreed

Need to replace the CMOF file for the abstract syntax by a UML file for UML 2.4

Agreed, the Alf abstract syntax is supposed to be based on UML 2.4.

The Model file includes the UML Primitive Types package rather than referencing it.

This occurs in the Alf Standard Library model XMI file. This file actually contains a spurious UML package, with a nested AuxiliaryConstructs, with PrimitiveTypes nested within that (as well as a number of other, empty packages). This included UML package should be removed. Note that all primitive type references elsewhere in the file already use hrefs with normative URIs, not references to the nested PrimitiveTypes package

The abstract syntax defined in Section 8.3.7 (Invocation Expressions) and
Section 8.3.9 (Behavior Invocation Expressions) will not match this
expression...

this.monitor.getActiveSensor().getReading()

(NOTE: the above expression is used as an example in Section 8.5.6 - Isolation
Expressions)

The issue seems to be that the definition of InvocationExpression does not
repeat.

Here is the current definition for InvocationExpression...

InvocationExpression= InvocationTarget Tuple
InvocationTarget= BehaviorInvocationTarget

Maybe the definition for InvocationTarget should be something like this?...

InvocationExpression= InvocationTarget Tuple

The expression “this.monitor.getActiveSensor().getReading()” is not a behavior invocation expression, it is a feature invocation expression. The production needed is the one for FeatureInvocationTarget in Subclause 8.3.10:

FeatureInvocationTarget(e: FeatureInvocationExpression)
= FeatureReference(e.target) | "this"

The expression given in the issues parses in full as follows:

FeatureInvocationExpression
FeatureInvocationTarget
FeatureReference
FeatureTargetExpression
NonNamePrimaryExpression
InvocationExpression [ <- Note recursion on InvocationExpression here ]
FeatureInvocationExpression
FeatureInvocationTarget
FeatureReference
FeatureTargetExpression
NonNamePrimaryExpression
PropertyAccessExpression
FeatureReference
FeatureTargetExpression
NonNamePrimaryExpression
ThisExpression
NameBinding
Name
“monitor”
NameBinding
Name
“getActiveSensor”
Tuple
NameBinding
Name
“getReading”
Tuple