Issue 14583: OCL 2.1 7.4.9 true, self, Bag and String are not reserved words (ocl2-rtf) Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk) Nature: Uncategorized Issue Severity: Summary: [Splitting a major issue off from a number of minor issues in 14357, so that the resolutions do not get confused.] Define a variety of effectively reserved words such as true, self, Bag, String as reserved. Define which Complete OCL reserved words are Essential OCL reserved words. Resolution: Revised Text: In 7.4.9 replace That means that the keywords cannot occur anywhere in an OCL expression as the name of a package, a type, or a property. by That means that the keywords cannot occur as a name. A reserved word may be used as the name of a package, a type, a feature, a variable or a constraint by enclosing the word in underscore-prefixed single quotes. Add to 7.4.9 retaining alphabetical order false invalid null self true At the end of 7.4.9 add The following words are restricted. A restricted word can only be used as a name when preceded by a "::". A restricted word may also be used by enclosing the word in underscore-prefixed single quotes. Bag Boolean Collection Integer OclAny OclInvalid OclMessage OclVoid OrderedSet Real Sequence Set String Tuple UnlimitedNatural Note that operation names such as iterate, forAll, and oclType, are not reserved or restricted. In 9.3 VariableExpCS replace A variable expression is just a name that refers to a variable. VariableExpCS ::= simpleNameCS ... VariableExpCS.ast.referredVariable = env.lookup(simpleNameCS.ast).referredElement.oclAsType(VariableDeclaration) ... [1] simpleName must be a name of a visible VariableDeclaration in the current environment env.lookup (simpleNameCS.ast).referredElement.oclIsKindOf (VariableDeclaration) by A variable expression is just a name that refers to a variable or self. [A] VariableExpCS ::= simpleNameCS [B] VariableExpCS ::= 'self' ... [A] VariableExpCS.ast.referredVariable = env.lookup(simpleNameCS.ast).referredElement.oclAsType(VariableDeclaration) [B] VariableExpCS.ast.referredVariable = env.lookup('self').referredElement.oclAsType(VariableDeclaration) ... [1] [A] simpleNameCS must be a name of a visible VariableDeclaration in the current environment env.lookup (simpleNameCS.ast).referredElement.oclIsKindOf (VariableDeclaration) In 9.3 add restrictedKeywordCS This production rule represents any name that is not a reserved keyword. [A] restrictedKeywordCS ::= CollectionTypeIdentifierCS [B] restrictedKeywordCS ::= primitiveTypeCS [C] restrictedKeywordCS ::= oclTypeCS [D] restrictedKeywordCS ::= 'Tuple' Abstract syntax mapping restrictedKeywordCS.ast : String Synthesized attributes [A] restrictedKeywordCS.ast = CollectionTypeIdentifierCS.ast.name [B] restrictedKeywordCS.ast = primitiveTypeCS.ast.name [C] restrictedKeywordCS.ast = oclTypeCS.ast.name [D] restrictedKeywordCS.ast = 'Tuple' Inherited attributes -- none Disambiguating rules -- none In 9.3 add unreservedSimpleNameCS This production rule represents any name that is not a reserved keyword. [A] unreservedSimpleNameCS ::= simpleNameCS [B] unreservedSimpleNameCS ::= restrictedKeywordCS Abstract syntax mapping unreservedSimpleNameCS.ast : String Synthesized attributes [A] unreservedSimpleNameCS.ast = simpleNameCS.ast [B] unreservedSimpleNameCS.ast = restrictedKeywordCS.ast Inherited attributes -- none Disambiguating rules -- none In 9.3 pathNameCS replace pathNameCS ::= simpleNameCS (‘::’ pathNameCS )? ... pathNameCS.ast = Sequence{simpleNameCS.ast}->union(pathNameCS.ast) by [A] pathNameCS ::= simpleNameCS [B] pathNameCS ::= pathNameCS ‘::’ unreservedSimpleNameCS ... [A] pathNameCS.ast = Sequence{simpleNameCS .ast} [B] pathNameCS.ast = pathNameCS.ast->append(unreservedSimpleNameCS.ast) In 9.3 add primitiveTypeCS This production rule denotes a primitive type. Abstract syntax mapping [A] primitiveTypeCS ::= 'Boolean' [B] primitiveTypeCS ::= 'Integer' [C] primitiveTypeCS ::= 'Real' [D] primitiveTypeCS ::= 'String' [E] primitiveTypeCS ::= 'UnlimitedNatural' Synthesized attributes [A] primitiveTypeCS.ast = Boolean [B] primitiveTypeCS.ast = Integer [C] primitiveTypeCS.ast = Real [D] primitiveTypeCS.ast = String [E] primitiveTypeCS.ast = UnlimitedNatural Inherited attributes -- none Disambiguating rules -- none oclTypeCS This production rule denotes a built-in OCL type. Abstract syntax mapping [A] oclTypeCS ::= 'OclAny' [B] oclTypeCS ::= 'OclInvalid' [C] oclTypeCS ::= 'OclMessage' [D] oclTypeCS ::= 'OclVoid' Synthesized attributes [A] oclTypeCS.ast = OclAny [B] oclTypeCS.ast = OclInvalid [C] oclTypeCS.ast = OclMessage [D] oclTypeCS.ast = OclVoid Inherited attributes -- none Disambiguating rules -- none In 9.3 TypeCS replace A typename is either a Classifier, or a collection of some type. by A typename is either a reserved type, or a Classifier, or a collection of some element type, or a tuple of some element types. In 9.3 TypeCS add [D] typeCS ::= primitiveTypeCS [E] typeCS ::= oclTypeCS ... [D] typeCS.ast = primitiveTypeCS.ast [E] typeCS.ast = oclTypeCS.ast In 13.2 add 3: The following operations do not form part of Essential OCL @pre ^^ ^ 4. The following names are not reserved or restricted in Essential OCL OclMessage body context def derive endpackage init inv package post pre static Actions taken: October 27, 2009: received issue April 25, 2011: closed issue Discussion: and, else, endif, if, implies, in, let, not, or, then, xor These are defined as reserved words in OCL 2.1. No change; these words should be reserved for Essential OCL. body, context, def, derive, endpackage, init, inv, package, post, pre, static These are defined as reserved words in OCL 2.1. There is no need for these to be reserved words in Essential OCL and consequently in derived languages such as QVT. Change; these words to be reserved for Complete OCL only. false, invalid, null, self, true These are not defined as reserved words in OCL 2.1 although the grammar clearly uses them in reserved ways. This is very unusual. For instance true, false, self/this are reserved in Java/C++. If literal expression keywords are not reserved, a syntax mechanism to defeat the occlusion by an implicit source property is required, allowing a reference to perhaps ::true. It is possible to define a grammar in which all ambiguous usage favours these words, so that self::true comprises non-reserved names; very strange. Better to reserve the names and simplify tooling and readability. Change; these words should be reserved for Essential OCL. Boolean, Integer, Real, String, UnlimitedNatural, OclAny, OclInvalid, OclMessage, OclVoid These are not defined as reserved words in OCL 2.1 although the grammar again uses them in reserved ways. This is very unusual. For instance boolean/bool, int, double, void are reserved in Java/C++. It seems very undesirable that a nested environment should be able to occlude resolution of a primitive type name and very confusing that such a name should be used as a property name. Therefore the primitive type names should be reserved and therefore always visible rather than selectively visible from a root environment. If occlusion is permitted, a syntax mechanism to defeat the occlusion would be required, allowing a reference to perhaps ::Integer. It is possible to define a grammar in which all ambiguous usage favours these words, so that Integer::String comprises non-reserved names; very strange. However My::String seems reasonable and clear. This can be accommodated by a restricted keyword concept; a restricted keyword may only be used following a ::. Change; Boolean, Integer, Real, String, UnlimitedNatural, OclAny, OclInvalid, OclVoid to be restricted for Essential OCL. Change; OclMessage to be restricted for Complete OCL only. Bag, Collection, OrderedSet, Sequence, Set, Tuple These are not defined as reserved words in OCL 2.1 although the grammar again uses them in reserved ways. This is unusual. For instance class, struct, union are reserved in Java/C. The non-reserved status of the collection type names currently causes only minor parsing difficulties. Problems are avoidable because the () clause is unambiguous for type names and the {} clause is unambiguous for literals. However if Issue 12953 is resolved to allow the collection literal syntax to be enhanced to allow specification of an element type, such as Bag(String){}, it becomes difficult for a parser to distinguish the prefix from an implicit source operation call. Better to restrict the names and simplify tooling and readability. Change; Bag, Collection, OrderedSet, Sequence, Set, Tuple to be restricted for Essential OCL. iterate, forAll, oclIsNew, oclIsInState etc These are not defined as reserved words in OCL 2.1, although the grammar again appears to use them in reserved ways. The apparently reserved usage is very dependent on exact signatures and so non-reserved usage is also permitted. These words are OCL Standard Library features rather than types and consequently much more prone to extension in future specifications. No change; the grammar should accommodate non-reserved behaviour. Reserved word corrolaries : primitive type names In OCL 2.1, primitive type names are not distinct from simpleNameCS and so a pathNameCS covers a primitive type name. Once primitive type names are reserved it is necessary first to introduce primitiveTypeCS and oclTypeCS, and then to use it. primitiveTypeCS ::= 'Boolean' primitiveTypeCS ::= 'Integer' primitiveTypeCS ::= 'Real' primitiveTypeCS ::= 'String' primitiveTypeCS ::= 'UnlimitedNatural' oclTypeCS ::= 'OclAny' oclTypeCS ::= 'OclInvalid' oclTypeCS ::= 'OclMessage' oclTypeCS ::= 'OclVoid' typeCS ::= primitiveTypeCS typeCS ::= oclTypeCS Reserved word corrolaries : self In OCL 2.1, self is not distinct from a simpleNameCS. This is not true once self is reserved. It therefore necessary to add VariableExpCS ::= 'self' Restricted word corrolaries Support for restricted keywords needs a definition of restrictedKeywordCS and a reference to it. restrictedKeywordCS ::= CollectionTypeIdentifierCS restrictedKeywordCS ::= primitiveTypeCS restrictedKeywordCS ::= oclTypeCS restrictedKeywordCS ::= 'Tuple' unreservedSimpleNameCS ::= simpleNameCS unreservedSimpleNameCS ::= restrictedKeywordCS pathNameCS ::= simpleNameCS pathNameCS ::= pathNameCS '::' unreservedSimpleNameCS End of Annotations:===== ronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFABJo5kpUXeby/2dsb2JhbACCJi2XPL4jhD8E Date: Tue, 27 Oct 2009 10:29:01 +0000 From: Ed Willink User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) To: issues@omg.org Subject: OCL 2.1 7.4.9 true, self, Bag and String are not reserved words X-Plusnet-Relay: fc44846d38aa0c7e078c880bc3ca95af Hi Juergen [Splitting a major issue off from a number of minor issues in 14357, so that the resolutions do not get confused.] Define a variety of effectively reserved words such as true, self, Bag, String as reserved. Define which Complete OCL reserved words are Essential OCL reserved words. Regards Ed Willink X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHcO50pUXebi/2dsb2JhbADaJ4Q/BA Date: Tue, 27 Oct 2009 22:20:20 +0000 From: Ed Willink User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) To: "'ocl2-rtf@omg.org'" Subject: Re: Issue 14583 true, self, Bag and String are not reserved words X-Plusnet-Relay: 6725257ba1e4a147ba16be8ed88bc934 Hi Mariano Attached defines true, self as reserved words, Bag, String as restricted words and resolves the syntactical consequences. Issue pending ? 14585 requiring a TypeLiteralExpCS is a further consequence highlighted but not caused by this. Regards Ed Willink