Issue 15627: Why not include Model to Text for generating ALF for (a subset of) UML?
Issue 16427: Definition of “Collection Class”
Issue 16428: Some Derived Associations Should Be Composite
Issue 16430: Allow Expressions to Just Conform to Primitive Types
Issue 16433: BehaviorInvocationExpression Should Have a Derived Implicit Binding
Issue 16438: Derivation of the Type of a ConditionalTestExpression
Issue 16446: NameExpression::assignment Derivation for a Parameter Name
Issue 16461: : ConcurrentClauses Should Have a Derived assignmentBefore
Issue 16465: Empty Type Names for Initialization Sequence and Construction Expressions
Issue 16466: NonFinalClause and SwitchClause Should Have Derived assignmentBeefore and assignmentAfter
Issue 16471: NamespaceDefinition::member type
Issue 16475: ActivityDefinition and OperationDefinition Bodies
Issue 16488: Non-deterministic behavior on "if statement"
Issue 16597: Indexing in sequence access expressions should be 0-based
Issue 16598: Need to clarify how objects are compared by collection classes
Issue 16599: The semantics of destroying part objects without accessible destructor must be specified
Issue 16600: Is it allowed to omit super destructor calls in an explicit destructor?
Issue 16601: Need a syntax for local names with composite semantics
Issue 16602: Missing syntax for RaiseExceptionAction
Issue 16604: Missing syntax for defining exception handlers
Issue 16605: Traditional for-statement not supported by Alf?
Issue 17509: Sequence feature invocation expressions
Issue 17512: Primitive type casts
Issue 18233: IncrementOrDecrementExpression::operator attribute is missing
Issue 18267: NameLeftHandSide needs a feature constraint
Issue 18281: Classify statements should start classifier behaviors
Issue 15627: Why not include Model to Text for generating ALF for (a subset of) UML? (alf-rtf)
Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
Why not include Model to Text for generating ALF for (a subset of) UML?
Subclause: 11.6 Collection Classes The rule for collection class in Section 11.6 would allow a class that multiply inherited from collection class instantiations, resulting in ambiguity of the call to toSequence. Perhaps the simplest rule would be to just consider as a “collection class” any class with a toSequence operation and an appropriate constructor.
Clauses: All of Part III on Abstract Syntax Derived associations whose derivations create new syntax elements, rather than referring to existing elements in the abstract syntax tree (e.g., ExtentOrExpression::expression) should be composition associations. This makes the ownership of these derived elements clear for the purpose of walking the abstract syntax tree to check static semantic constraints.
Clause: 13 Expression Abstract Syntax In general, constraints for expressions to be of a certain standard primitive type should, instead, allow them to be of a type that conforms to the required type. This allows for user-defined primitive types that are subtypes of the standard types
Subclause: 13.2.3 BehaviorInvocationExpression BehaviorInvocationExpression should have a derived attribute that is the implicit binding when the referent behavior is a template whose argument types can be inferred for the invocation. There should also be a constraint on when this is allowed
Subclause: 13.2.13 ConditionalTestExpression The derivation for the type of a ConditionalTestExpression should account for the case in which one of the result operands is empty, in which case the type of the conditional test expression should be the type of the other expression
Subclause: 13.2.34 NameExpression For a parameter name, nameExpressionAssignmentDerivation should only give the assignment as the assignment before the expression if there is one. Otherwise, it should create an effective assignment with the formal parameter as its source element, unless the parameter is an out parameter. If the parameter is a non-Alf element, then this will need to be wrapped in a new ExternalParameter syntax element.
Subclause: 14.2.8 ConcurrentClauses ConcurrentClauses should have a derived assignmentBefore association, since this is mentioned in the description of the concurrentClausesAssignmentsBefore condition.
Subclauses: 14.2.15 LocalNameDeclarationStatement and 15.2.19 PropertyDefinition In order to handle instance and sequence initialization expressions (per Subclauses 9.6 and 10.5.2), constraints for LocalNameDeclarationStatement and PropertyDefinition should allow for instance construction and sequence construction expressions with empty type names (which means the constructor name for an instance construction expression must also be optional).
Subclauses: 14.2.17 NonFinalClause and 14.2.21 SwitchClause NonFinalClause should have derived assignmentBefore and assignmentAfter associations, since these are mentioned in the description of the nonFinalClauseAssignmentsBefore and nonFinalClauseAssignmentsAfter constraints, respectively. Similarly for SwitchClause.
Subclause: 15.2.15 NamespaceDefinition It would be better if NamespaceDefinition::member had type ElementReference instead of Member, to account for members inherited from non-Alf UML elements.
Subclauses: 15.2.2 ActivityDefinition and 15.2.16 OperationDefinition OperationDefinition and ActivityDefinition should have derived attributes for their actual body that gets the subunit body if they are stubs (in all other cases, resolving subunits can be handled via the derivation of the members for the stub). They should also have constraints that there are no assignments before the actual body.
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.
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.
to
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.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.
In the section "Composition" of 10.5.2 we have the following example:
class C {
public a: A = new A();
public b: compose B = new B();
}
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.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.
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();
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).
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++) { ... }Subject: Sequence feature invocation expressions Subclauses: 8.3.10 Feature Invocation Expression, 13.2.17 FeatureInvocationExpression · A feature invocation expression with a primary whose multiplicity is 0..1 should not be considered a sequence feature expression, since the optionality is handled without the need for an expansion region. · Subclause 8.3.10 states that a sequence feature invocation expression is equivalent to a sequence expansions (collect) expression for the invocation. However, local names may not be assigned within the argument expression of a sequence expansion expression (because a sequence expansion expression maps to an expansion region, and fUML does not allow flows out of such regions other than through output expansion nodes). For a sequence feature invocation expression, the invocation tuple is repeatedly re-evaluated inside the argument expression of the equivalent sequence expansion expression. Therefore, local variable assignments should not be allowed within the expressions in the tuple of a feature invocation expression. These changes should also be accounted for in the constraints in Subclause 13.2.17.
Subject: Primitive type casts Subclauses: 8.5.5 CastExpressions Cast expressions should allow casting between Integer and UnlimitedNatural and between Integer and BitString, performing appropriate conversions
Specification: Action Language for Foundational UML (Alf) FTF Beta 2 (ptc/2012-08-43) Subclause: 8.4 Increment and Decrement Expressions The BNF in Subclause 8.4 parses the operator string of an increment or decrement expression into an “operator” attribute of the instance of IncrementOrDecrementExpression. However, no operator attribute is actually defined for IncrementOrDecrementExpression.
Specification: Action Language for Foundational UML (Alf): Concrete Syntax for a UML Action Language, v1.0, FTF Beta 2 (ptc/2012-08-43) Subclause: 13.2.35 NameLeftHandSide The FeatureLeftHandSide class has the constraint: “The expression of the feature reference of a feature left-hand side must have a multiplicity upper bound of 1.” A NameLeftHandSide needs to have a similar constraint, in the case that its target name disambiguates to a feature reference.
Specification: Action Language for Foundational UML (Alf): Concrete Syntax for a UML Action Language, FTF-Beta 2 (ptc/2012-08-43) Subclause: 9.16 classify Statements The semantics of classify statements does not mention what happens if any of the classes in the from list are active classes. The semantics of a UML reclassify object action are to NOT start the classifier behaviors of any such active classes. However, Alf does not provide any way to explicitly start classifier behaviors (this normally happens implicitly when an active object is constructed), so it would seem that the Alf classify statement SHOULD have the stated semantics of starting the classifier behaviors of any active classes in the from list. Otherwise, there would be no way to do so.