Community
Participate
Working Groups
Consider for example the following expression: Set{1}.oclAsType(Sequence(Real)) It can't be parsed, error "illegal operation signature: (Sequence(OclType))". Of course expression like 1.oclAsType(Real) is parsed ok (well, it's can't be evaluated but this is another issue). The reason is that grammer (OCLLPGParser.g) defines such operation calls as follow: operationCallExpCS ::= oclAsType isMarkedPreCS '(' argumentsCSopt ')' operationCallExpCS ::= oclIsKindOf isMarkedPreCS '(' argumentsCSopt ')' operationCallExpCS ::= oclIsTypeOf isMarkedPreCS '(' argumentsCSopt ')' While 'argumentsCSopt' is actually reduced to 'oclExpressionCS' which can't be reduced to 'typeCS'. Rules above should be replaced with: operationCallExpCS ::= oclAsType isMarkedPreCS '(' typeCS ')' operationCallExpCS ::= oclIsKindOf isMarkedPreCS '(' typeCS ')' operationCallExpCS ::= oclIsTypeOf isMarkedPreCS '(' typeCS ')'
The OclAny operations oclIsKindOf etc. aren't applicable to CollectionTypes and TupleTypes, which the OCL specification indicates do not conform to OclAny. Note that Set{1}.oclAsType(Sequence(Real)) would expand as an implicit collect iterator to Set{1}->collect(oclAsType(Sequence(Real))) which doesn't make sense, as Integer cannot be cast to Sequence(Real). What one would want is to be able to write Set{1}->oclAsType(Sequence(Real)) but as I mentioned before, this operation does not apply to collections. So, the problem that I see is that the parser is providing the wrong error message; it should be "cannot find operation 'oclAsType'". This would be fixed by updating the rules for oclAsType/oclIsKindOf/oclIsTypeOf as you suggest. They happen to work for non-collection types only because oclExpressionCS reduces to enumLiteralExpCS and variableExpCS, which are both able to yield references to types. The typeCS is more appropriate. Good catch!
Should fix this in the first Europa maintenance release.
One more note on 'typeCS': There is the same problem with additionally defined operations that requires TypeExp as the parameter(s). I mean that for example 'myFunc(ecore::EPackage)' is parsed ok, but 'myFunc(Sequence(ecore::EPackage))' fails. The reason is the same as for 'oclAsType()'-like operations.
Christian, do you consider this one for 1.3? Not that it hurts too much, but seems to be a right move, and cleans QVT stuff a bit ;)
It's not always a good idea to be too precise in the grammar, since syntax errors are a bit obtuse. This looks like a strong case for a superset grammar that accepts typical user errors so that a more intelligible semantic error can be produced instead.
Attachment #146988 [details] to Bug 184048 eliminates all predefined functions (other than iterators) from the grammar, so they can no longer be parsed wrongly. Attachment #147054 [details] to Bug 259031 fixes a matching problem for Type arguments. This may fix the problem. Revision of OclAny inheritance behaviour almost certainly will.
The parser problems were fixed in 292112
Closing after over 18 months in resolved state.
