Issue 15625: The Model file includes the UML Primitive Types package rather than referencing it.
Issue 15626: Need to replace the CMOF file for the abstract syntax by a UML file for UML 2.4
Issue 15627: Why not include Model to Text for generating ALF for (a subset of) UML?
Issue 16006: StructuredMember should be renamed to StructuredElement
Issue 16015: Correction to Section 8.3.6, Property Access Expressions
Issue 16413: Null Template Binding Arguments
Issue 16414: Boolean Literals Cannot Be Used as Identifiers
Issue 16415: Error in Synthesis of Null Expressions
Issue 16416: Parenthesizing Left Hand Sides
Issue 16417: Missing Cross Reference in Subclause 9.6
Issue 16418: Evaluation of Loop Variable Definitions
Issue 16419: Return Statements with no Expression
Issue 16420: Implicit Imports
Issue 16421: Error in Singleton Examples
Issue 16422: Error in ProcessQueue Example
Issue 16423: Constructors and Diamond Inheritance
Issue 16424: Synthesis of the Name of a Reception Definition
Issue 16425: IndexOf Return Type
Issue 16426: Errors in Collection Function Table
Issue 16427: Definition of “Collection Class”
Issue 16428: Some Derived Associations Should Be Composite
Issue 16429: Errors in Abstract Syntax Attribute Names
Issue 16430: Allow Expressions to Just Conform to Primitive Types
Issue 16431: Type Conformance for Compound Assignments for Bit Strings
Issue 16432: Errors in BehaviorInvocationExpression Constraints
Issue 16433: BehaviorInvocationExpression Should Have a Derived Implicit Binding
Issue 16434: binaryExpressionOperandMultiplicity Constraint is Too Strong for EqualityExpression
Issue 16435: Derived Attributes for LeftHandSide
Issue 16436: Require Non-Template Classifier
Issue 16437: Corrections to updateAssignments for ConditionalTestExpression
Issue 16438: Derivation of the Type of a ConditionalTestExpression
Issue 16439: Constraint Needed on FeatureLeftHandSide
Issue 16440: Derivations of type, lower and upper for Invocation Expressions
Issue 16441: Corrections to InvocationExpression::parameterElements
Issue 16442: literalExpressionTypeDerivation Is Not Necessary
Issue 16443: Errors in LogicalExpression Constraints
Issue 16444: Problem with the NamedExpression Conversion Constraints
Issue 16445: NamedTuple Needs a Constraint
Issue 16446: NameExpression::assignment Derivation for a Parameter Name
Issue 16447: NameExpression Should Override updateAssignments
Issue 16448: Problems with NameLeftHandSide Constraints
Issue 16449: PositionalTuple Needs a Constraint
Issue 16450: Error in propertyAccessExpressionLowerDerivation
Issue 16451: QualifiedName::templateName Needs a Description
Issue 16452: Error in qualifiedNameDisambiguationDerivation
Issue 16453: SequenceConstructionExpression::typeName May Be Empty
Issue 16454: SequenceConstructionExpression Constraints
Issue 16455: SequenceConstructionExpression Needs to Override updateAssignments
Issue 16456: SequenceOperationExpression Should Override parameterElements
Issue 16457: SequenceOperationExpression Constraints
Issue 16458: Correction to shiftExpressionOperands Constraint
Issue 16459: Correction to superInvocationExpressionTarget Constraint
Issue 16460: Block Assignment Constraints
Issue 16461: : ConcurrentClauses Should Have a Derived assignmentBefore
Issue 16462: ForStatement Should Have a Composition Association to Block
Issue 16463: localNameDeclarationStatementAssignmentsAfter constraint
Issue 16464: Derivation of LocalNameDeclaration::type
Issue 16465: Empty Type Names for Initialization Sequence and Construction Expressions
Issue 16466: NonFinalClause and SwitchClause Should Have Derived assignmentBeefore and assignmentAfter
Issue 16467: SwitchClause Should Have a switchClauseCase Constraint
Issue 16468: Errors in Descriptions of SwitchStatement constraints
Issue 16469: ElementImportReference Constraint
Issue 16470: Errors in ImportedMember
Issue 16471: NamespaceDefinition::member type
Issue 16472: NamespaceDefinition::ownedMember Should Be Ordered
Issue 16473: Description of operationDefinitionRedefinition
Issue 16474: Constructor Return Type
Issue 16475: ActivityDefinition and OperationDefinition Bodies
Issue 16476: Assignments Before a Property Initializer
Issue 16477: Description of SignalDefinition::isSameKindAs
Issue 16478: Errors in Constraint Names
Issue 16479: Errors in QuickSort Example
Issue 16480: Errors in the Online Bookstore Example
Issue 16481: Errors in the Property Management Service Example
Issue 16482: Errors in the Collection Classes Implemenation
Issue 16488: Non-deterministic behavior on "if statement"
Issue 16586: Typo in sequence functions?
Issue 16591: Problem with parameters of CollectionFunctions::removeAll
Issue 16592: Problem with parameters of CollectionFunctions::replaceOne
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 16606: Should be allowed to use return statement in all behaviors
Issue 15625: The Model file includes the UML Primitive Types package rather than referencing it. (alf-ftf)
Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
The Model file includes the UML Primitive Types package rather than referencing it.
issue15625
Need to replace the CMOF file for the abstract syntax by a UML file for UML 2.4
Why not include Model to Text for generating ALF for (a subset of) UML?
In order to play with ALF I have thrown together a parser for my own use. Along the way I have found a small error in the spec regarding the Abstract Syntax for ALF. Many clauses in the spec (Beta 1) refer to 'StructuredElement' and those same clauses say that StructuredElement is defined in clause 10.4.4. However, in clause 10.4.4 the element appears to be named 'StructuredMember' instead. It looks to me like StructuredMember should be renamed to StructuredElement since the term 'Element' appears to be the convention used throughout the rest of the spec.
There is a small problem in section 8.3.6 regarding property access expressions.
The problem is that the concrete syntax defined in that section will not
actually match the examples given in that section.
---------
Here is the concrete syntax defined in that section...
PropertyAccessExpression(e: PropertyAccessExpression)
= FeatureReference(e.featureReference)
FeatureReference(f: FeatureReference)
= FeatureTargetExpression(f.expression) "." NameBinding(f.nameBinding)
FeatureTargetExpression(e: Expression)
= NameTargetExpression(e)
| NonNamePrimaryExpression(e)
NameTargetExpression(e: NameExpression)
= ColonQualifiedName(e.name)
Note that NameTargetExpression only allows ColonQualifiedName(s) to be used to
define a PropertyAccessExpression.
-------
Here are the examples of property access expressions from the same section...
poleValue.im
this.node
members.name
jack.house
Note that, because NameTargetExpression only allows ColonQualifiedName(s), none
of the above examples matches the concrete syntax.
----------
I suspect that NameTargetExpression should be defined to be a QualifiedName,
which is defined to be either a DotQualifiedName, an UnqualifiedName, or a
ColonQualifiedName, so...
NameTargetExpression(e: NameExpression)
= QualifiedName(e.name)
where QualifiedName is defined elsewhere as:
QualifiedName(q: QualifedName)
= ColonQualifiedName(q)
| DotQualifiedName(q)
| UnqualifiedName(q)
Subclause: 6.2 Templates The rule in Subclause 6.2 for constructing the name of an equivalent bound element does not account for the possibility that one of the arguments may be null (i.e., “any”). While the syntax for template bindings in qualified names (Subclause 8.2) does not allow “any” to be used as a template argument, such an argument can result from the rules for the implicit binding for a template behavior as given in Subclause 8.3.9.
Subclause 7.5: Names Subclause 7.5 should says that reserved words cannot be used as identifiers, but it should also note that Boolean literals (which are not classified as reserved words) can also not be used as identifiers.
Subclause: 8.3.15: Sequence Construction Expressions In Subclause 8.3.15, the parsing of a NullExpression should set the hasMultiplicity=true for the SequenceConstructionExpression, otherwise the derivation of the lower and upper attributes (see Subclause 13.2.46) will result in those both being 1 instead of both being 0.
Subclause: 8.8 Assignment Expressions It should be allowed to parenthesize a left hand side. This makes it possible to parse the left hand side simply as an expression and then check afterward if it is correct (as is done in the grammar given in the annex). It is also consistent with Java syntax.
Subclause: 9.6 Local Name Declaration Statements Subclause 9.6 should have a cross reference to the abstract syntax class InstanceCreationExpression, since the InstanceInitializationExpression production creates an instance of that class.
Subclause: 9.12 for Statements It should be made clear that the expressions in the loop variable definitions of a for statement are evaluated sequentially in the order of the loop variables (per the mapping). (Or, if the expressions are evaluated concurrently, then there needs to be a constraint that the same name cannot be assigned in more than one of those expressions.)
Subclauses: 9.14 return Statements A return statement without an expression should be allowed for a behavior without a return parameter.
Subclause: 10.1 Overview It is only necessary to require implicit imports of standard model library packages into model units. Any direct or indirect subunits of a model library unit with implicit imports will have visibility upwards of the packages imported into the model unit. Also, applying «ModelLibrary» to a subunit cannot prevent this visibility of the standard model library packages, and so this stereotype is also actually only effective on a model unit.
Subclause 10.4.2 Classes In the Singleton example use in Subclause 10.4.2 under Semantics, “allinstances” should be “allInstances”.
Subclause: 10.4.3 Active Classes In the ProcessQueue example in Subclause 10.4.3, “sign” that appears twice in the classifier behavior should be “sig”.
Subclause: 10.5.3.1 Constructors At the end of Subclause 10.5.3.1 it states that: “In the absence of explicit constructor invocations at the start of a constructor body (and also in the case of the default constructor behavior), a super constructor invocation is made implicitly for each immediate superclass, in the order the superclasses appear in the specializes list of the class containing the constructor, before executing any statements in the constructor body.” However, if the immediate superclasses themselves have common ancestors (so called “diamond inheritance”), applying this rule recursively will result in the constructors of these common ancestors being called multiple times.
Subclause 10.5.4: ReceptionDefinition
In the syntax for ReceptionDefinition, the condition for d.name should be {d.name=d.signal.nameBinding->last().name}.
Subclause: 11.3.6 Sequence Functions In Table 11-14, the return type of IndexOf should be Integer, not any.
Subclause: 11.5 Collection Functions In Table 11-15, “ordered nonuique” [sic] appears twice (first column, second and third rows) and should be replaced with “sequence”. remove, removeAll and removeOne should return “T[*] sequence”.
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.
Subclauses: 13.2.31 NamedExpression, 15.2.9 EnumerationDefinition, 15.2.15 NamespaceDefinition, and 15.2.16 OperationDefinition • NamedExpression::isBitStringConverstion should be isBitStringConversion • EnumerationDefinition::classDefinitionSpecializationReferent should be enumerationDefinitionSpecializationReferent • NamespaceDefinition::annotationAllowed should not be abstract. • OperationDefinition::redefinedOperations should be redefinedOperation
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.2 The assignmentExpressionCompoundAssignmentTypeConformance constraint should also handle compound assignments for bit string operators.
Subclause: 13.2.3 BehaviorInvocationExpression • The behaviorInvocationExpressionReferentDerivation should allow for resolution of the target to an association end. • The behaviorInvocationExpressionArgumentCompatibility constraint should note that it only applies if the target does not disambiguate to a feature reference.
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.4 The binaryExpressionOperandMultiplicity constraint requires that the operands of a binary expression have a multiplicity upper bound of 1. However, an equality expression (a kind of binary expression) is allowed to compare to “null”, which has a multiplicity upper bound of zero.
Subclause: 13.2.6 LeftHandSide A left hand side should have derived type, lower and upper attributes, since these are defined in Subclause 8.8.
Subclauses: 13.2.8 CastExpression and 13.2.10 Classification Expression The castExpressionTypeResolution and classificationExpressionTypeName constraints should require a non-template classifier
Subclause: 13.2.13 ConditionalTestExpression The description of the updateAssignments operation for ConditionalTestExpression should clearly state that assignments can be made in the first operand expression. It should also state that the type of newly defined names is the effective common ancestor of the types of the name in each of the second and third operands
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.18 There needs to be a constraint on FeatureLeftHandSide that it resolves to a single referent that is a structural feature.
Subclause: 13.2.23 InvocationExpression The derivations of type, lower and upper inherited in InvocationExpression are based on the return parameter of the referent of the expression. This doesn’t work for referents that are not behaviors or operations. Specifically: • For an InstanceCreationExpression, the referent may be a classifier (Class or DataType), in which case, the type needs to be the referent itself and lower and upper need to both be 1. • For a BehaviorInvocationExpression, the referent may be an association end, in which case the type, lower and upper need to be the same as for the end.
Subclause: 13.2.23 InvocationExpression • The return parameter of the InvocationExpression::parameterElements helper operation should be ordered. • The definition of InvocationExpression::parameterElements should also handle the case in which the reference is an association end.
Subclause: 13.2.28 LiteralExpression The constraint literalExpressionTypeDerivation (“The type of a literal expression is given by the type of the literal, as defined for each subclass below.”) is not necessary, since it doesn’t provide any actual constraint. (Plus, in the current document organization, not all of the subclasses are “below” the subclause on LiteralExpression.)
Subclause: 13.2.29 LogicalExpression • The definitions of the logicalExpressionIsBitStringConversion1 and logicalExpressionIsBitStringConversion2 constraints mention “shift expression” when they should say “logical expression”. • The logicalExpressionOperands constraint should allow for BitString and Integer operands (per the semantics of logical expression in Subclause 8.6.7). • The logicalExpressionTypeDeriviation constraint should give the type BitString if the expression is bit-wise.
Subclause: 13.2.31 NamedExpression The constraints namedExpressionIsBitStringConversion and namedExpressionIsCollectionConversion cannot really be checked within the context of NamedExpression, since there is no way from that context to determine what the type of the “corresponding parameter” is.
Subclause: 13.2.33 NamedTuple NamedTuple should have a constraint that its argument names all correspond to parameter names of its invocation and that no argument name appears more than once.
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: 13.2.34 NameExpression NameExpression should override updateAssignments to return the assignments after its derived propertyAccess expression, if it has one (i.e., if it disambiguates to a feature reference).
Subclause: 13.2.35 NameLeftHandSide • There needs to be a constraint on NameLeftHandSide that if its name is qualified, and does not disambiguate to a feature, then it resolves to a parameter of the behavior containing the left-hand side, and, if it disambiguates to a feature, it resolves to a single referent that is a structural feature. • In the nameLeftHandSideAssignmentAfterDerivation constraint, if the named left hand side has an index, then the assignments after the left hand side should be the assignments after the index. • The derivations for assignmentBefore and assignmentAfter for NameLeftHandSide need to account for the possibility of the name disambiguating to a feature reference
Subclause: 13.2.40 PositionalTuple PositionalTuple should have a constraint that it does not have more arguments than its invocation has parameters.
Subclause: 13.2.41 PropertyAccessExpression The propertyAccessExpressionLowerDerivation constraint description refers to upper bounds when it should refer to lower bounds
Subclause: 13.2.42 QualifiedName QualifiedName::templateName needs a description
Subclause: 13.2.42 QualifiedName In the description of qualifiedNameDisambiguationDerivation, “If a qualified name is not ambiguous or it resolves to a namespace…” should be “If a qualified name is not ambiguous or it has a qualification that resolves to a namespace…”
Subclause: 13.2.46 SequenceConstructionExpression The description of the sequenceConstructionExpressionType constraint should make it clear that it is legal for the typeName property to be empty (corresponding to a type name notation of “any”).
Subclause: 13.2.46 SerquenceConstructionExpression • SequenceConstructionExpression needs constraints on the type and multiplicity of its sequence elements. However, the rules here (and as stated in Subclause 8.3.15) need to allow for bit string conversion of integer elements for a bit string sequence. • The description of the sequenceExpansionExpressionVariableSourceDerivation constraint should also state that the type of the assigned source for the expansion variable is the type of the primary expression and the multiplicity bounds are both 1. • SequenceExpansionExpression needs a constraint that no names defined before the argument expression may be reassigned in the argument expression (per the Semantics in Subclause 8.3.19), not just the expansion variable. • The description of the sequenceExpansionExpressionListUpperDerivation constraint says “lower bound” when in should say “upper bound”.
Subclause: 13.2.46 SequenceConstructionExpression SequenceConstructionExpression needs to override updateAssignments. For a sequence expression list, the assignments before each element expression should be the assignment after the previous one and the assignments after the sequence construction expression are the assignments after the last element expression. For a sequence range the assignments before both expressions are the assignments before the sequence construction expression and the assignments after the sequence construction expression are the assignments after the expressions. There should also be a constraint on sequence ranges that the same local name cannot be assigned in both expressions
Subclause: 13.2.50 SequenceOperationExpression SequenceOperationExpression should override the parameterElements operation to only return the parameters after the first, since the argument for the first parameter is given by the primary expression not in the tuple.
Subclause: 13.2.50 SequenceOperationExpression • SequenceOperationExpression needs a constraint that a name may not be assigned in both the primary expression and any tuple argument expression. • SequenceOperationExpression should have a derived association with an optional LeftHandSide that is created in the case of an “in place” operation and must have its constraints satisfied. The sequenceOperationExpressionTargetCompatibility constraint should also require that, for an “in place” operation, the primary expression have the form of a left-hand side and, if for a local name, the local name must already exist.
Subclause: 13.2.53 ShiftExpression The description of the shiftExpressionOperands constraint should say “The first operand expression of a shift expression must have the type BitString or Integer. The second operand expression must have the type Integer.” (per Subclause 8.6.3).
Subclause: 13.2.55 SuperInvocationExpression The superInvocationExpressionImplicitTarget constraint should include the condition that the containing behavior has only a single superclass
Subclause: 14.2.4 Block • The second sentence of the description of the Block::assignmentAfter derived property mentions “statement” twice when it should say “block”. • The blockAssignmentsBefore constraint should have the definition “The assignments before the first statement of a block are the same as the assignments before the block.”
Subclause: 14.2.8 ConcurrentClauses ConcurrentClauses should have a derived assignmentBefore association, since this is mentioned in the description of the concurrentClausesAssignmentsBefore condition.
Subclause: 14.2.12 for Statements ForStatement should have a composition association with its body Block.
Subclause 14.2.15 LocalNameDeclarationStatement The localNameDeclarationStatementAssignmentsAfter constraint states “The assignments after a local name declaration statement are the assignments before the statement plus a new assignment for the local name defined by the statement.” The assignments should be the assignments after the expression of the statement plus the new assignment (so as to include assignments made in the expression).
Subclause: 14.2.15 The localNameDeclarationTypeDerivation requires the type of the statement to be the type of the expression if no type name is given. However, this is not correct, since the only way that the type name could be empty is if it is given as “any”, in which case the local name should be untyped.
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: 14.2.21 SwitchClause SwitchClause should have a switchClauseCases constraint the states “All the cases expressions of a switch clause must have a multiplicity no greater than 1.”
Subclause: 14.2.22 • The description of the switchStatementExpression constraint should be “The expression of a switch statement must have a multiplicity no greater than 1.” • The description of the switchStatementEnclosedStatements constraint should be “A switch statement is the enclosing statement for the statements in all of its switch clauses.” • The switchStatementAssignmentsBefore constraint should state that the assignments before the clauses of a switch statement are the assignments after the expression of the switch statement.
Subclause: 15.2.8 ElementImportReference ElementImportReference should have a constraint that its referent must be a packageable element.
Subclause: 15.2.12 ImportedMember • The description of ImportedMember::isSameKind is written in terms of distinguishability rather than same kind. • An ImportedMember should not generally be considered a feature, even if it is a feature of the namespace it is imported from, since it is not a feature of the namespace it is imported into.
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.
Subclause: 15.2.15 NamespaceDefinition NamespaceDefinition::ownedMember association should be ordered. (This is important at least for activity and operation parameters.)
Subclause: 15.2.16 OperationDefinition In the description of OperationDefinition::operationDefinitionRedefinition, “signal referent” should be “single referent”.
Subclause: 15.2.16 OperationDefinition OperationDefinition must take into account that the return type of a constructor is not explicitly declared, but is still included in the operation signature (per Subclause 10.5.3.1).
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.
Subclause: 15.2.19 PropertyDefinition The propertyDefinitionInitializer constraint should also state that there are no assignments before the initializer expression.
Subclause: 15.2.21 SignalDefinition The description of SignalDefinition::isSameKindAs mentions “Reception” where it should say “Signal”.
Subclauses: Various subclauses in Part III Abstract Syntax The following constraint names should be corrected as shown: • expressionAssignmentsAfterDerivation -> expressionAssignmentAfterDerivation • bitStringUnaryExpresionIsBitStringConversionDerivation -> bitStringUnaryExpressionIsBitStringConversionDerivation • loopVariableIsCollectionConversionDerivation -> loopVariableDefinitionIsCollectionConversionDerivation • importedElementNotStub -> importedMemberNotStub • importedElementFeatureDerivation -> importedMemberIsFeatureDerivation • forAllOrExistOrOneExpressionTypeDerivation -> forAllOrExistsOrOneExpressionTypeDerivation • forAllOrExistOrOneExpressionLowerDerivation -> forAllOrExistsOrOneExpressionLowerDerivation • forAllOrExistOrOneExpressionUpperDerivation -> forAllOrExistsOrOneExpressionUpperDerivation • forAllOrExistOrOneExpressionArgument -> forAllOrExistsOrOneExpressionArgument • relationalExpressionIsTypeDerivation -> relationalExpressionTypeDerivation • relationalExpressionIsLowerDerivation -> relationalExpressionLowerDerivation • relationalExpressionIsUpperDerivation -> relationalExpressionUpperDerivation • unboundedLiteralExpressionDerivation -> unboundedLiteralExpressionTypeDerivation • namespaceDefinitionMemberDistinguishaibility -> namespaceDefinitionMemberDistinguishability • operationDefinitionIsConstructorDefinition -> operationDefinitionIsDestructorDerivation • operationDefinitionIsDestructorDefinition -> operationDefinitionIsDestructorDerivation • operationDefinitionRedefinedOperationsDerivation -> operationDefinitionRedefinedOperationConstraint • propertyDefinitionIsBitStringConversion -> propertyDefinitionIsBitStringConversionDerivation • incrementOrDecrementExpressionIsDataValueUpdate -> incrementOrDecrementExpressionIsDataValueUpdateDerivation • incrementOrDecrementExpressionFeature -> incrementOrDecrementExpressionFeatureDerivation • incrementOrDecrementExpressionAssignment -> incrementOrDecrementExpressionAssignmentDerivation
Subclause: C.1 Quicksort Activity In the “functional” QuickSort example: • x cannot be set only in the else part of an if statement • The sequence operation “remove” should be “removeAt” • The recursive call to “QuickSort” should be “Quicksort”.
Subclause: C.2 Online Bookstore • In the example class Order, the statement “accept (OrderDelivery)” should be “accept (OrderDelivered)”. Also, the nested activities have to be operations, because nested activities don’t have the containing class as their context. • In the example activity EstablishCustomer, “TIM::current_date” should be replaced with “TIM::GetCurrentDate()”. • The ProcessCharge activity should import Ordering::CreditCardCharge::ChargeData. • In the graphical model for the Ordering example, the Customer class is shown as having a purchasesMade attribute that is not set in the EstablishCustomer activity, but that activity instead shows a phone attribute being set that is missing from the class.
Subclause: C.3 Property Management Service • To be consistent with the implementation of ‘create reply’, the association of Property to Location should be optional. • In the ‘create property’ example, the mandatory ‘property type’ needs to be set in the propertyData instance creation expression. • In the establish operation, two occurrences of “request.name” should be replaced with “request.’property name’”. • In the acquire, update, delete and retrieve operations, the reply and error out parameters need to be set to null values before the if statement and the select expressions should have “[1]” at the end. • In the acquire, update and dispose operations, the reference to ‘Property Type’ should be ‘Property Status’ and the assignment in the second if clause should be equality. • The update operation needs to import 'Property Management'::'Data Model'::Locations::Location. Also, “request.’property location’” should be “request.’property location identifier’” (three times), “request.’serial number’ “should be “request.’property serial number’” and “request.size” should be “request.’property size’”.
Subclause: C.4 Alf Standard Library Collection Classes Implementation • All the collection implementation classes have an incorrect namespace declaration containing “Collections::CollectionClasses”, rather than just “CollectionClasses”. They also import “Alf::Library::FunctionBehaviors::Collections::CollectionFunctions” rather than “Alf::Library::CollectionFunctions”. • Return types should not be given on constructors. • Several classes have destructors that call CollectionImpl<T>::destroy, but CollectionImpl has no such destructor. • The classes that have multiple specializations have to redefine indistinguishable operations inherited from both classes. • In C.4.2 CollectionImpl, o excludesAll and includesAll have seq as their parameter, but incorrectly use the name “element” in their bodies. o In the first statement of removeOne, “self” is used instead of “this”. o In the last statement of retainAll, there should not be “()” after “preSize”. • In C.4.3 OrderedCollectionImpl, o In the body of addAt, the call to “addAllAt” should be proceeded by “this.”. o In the body of indexOf, the reference to “indexof” should be “indexOf”. • In C.4.5 OrderedSet, o In the body of equals, “OrdredCollcetionImpl” should be “OrderedCollectionImpl”. o In the body of subOrderedSet, the constructor “OrderedSet” should be “OrderedSet<T>”. • In C.4.6 Bag, the super constructor call should be to CollectionImpl, not OrderedCollection. • In C.4.7 List, o CollectionClasses::Impl::List should specialize CollectionClasses::List, not CollectionClasses::OrderedSet. o subList should return List<T>, not OrderedSet<T>. o In subList, the constructor “List” should be “List<T>”. o The parameter for setContent should be a “sequence”. • In C.4.8 Queue, o Queue should specialize CollectionClasses::Queue, not CollectionClasses::Set. o In the body of removeFirst, “toSequence” should be “toSequence()”. o removeFirstOne should have a return multiploicity of 1..1. o The body of removeFirstOne should return the argument element or null, depending on whether the element was actually found for deletion. • In C.4.9 Deque, o Deque should specialize CollectionClasses::Deque in addition to Queue. o The super constructor call should be super.Queue<T>::Queue, not just super, and the super destructor call should be super.Queue<T>::destroy. o The implementation of removeLastOne removes all occurrences of the given element, not just the last one. o toSequence cannot return “this.content”, since “content” is private to Queue. o The (constructor) operation Queue is inherited from both superclasses and must be redefined.
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.
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.
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”).
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”.
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++) { ... }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.