The implementation is correct, because allowing nested tuples leads to ambiguity. Look at the following example: value = 1@2@3@4.
Is it one tuple with 4 entries, or with 3 entries where one is a nested tuple?
If the separator is , then one has to use brackets and the notation is precise: value = (1, (2, 3), 4).
The implementation already prints the correct error message in case a tuple with separators is nested in another tuple with separators:
error: tuple type My_Tuple_Type, which contains separators, may not contain another tuple with separators
Solution: update the LRM to be clear that nesting tuples is only allowed of the nested tuple does not use separators.
florianschanda
commented
4 months ago
According to
tuple_aggregatein https://github.com/bmw-software-engineering/trlc/blob/92947777b0d034c37b2db1fb82502c420ca50326/language-reference-manual/lrm.trlc#L1731 the LRM allows nesting tuples, becausevalueitself can again be atuple_aggregate. However, the implementation does not allow it.The implementation is correct, because allowing nested tuples leads to ambiguity. Look at the following example:
value = 1@2@3@4. Is it one tuple with 4 entries, or with 3 entries where one is a nested tuple? If the separator is,then one has to use brackets and the notation is precise:value = (1, (2, 3), 4). The implementation already prints the correct error message in case a tuple with separators is nested in another tuple with separators:Solution: update the LRM to be clear that nesting tuples is only allowed of the nested tuple does not use separators.
The issue has been detected in the context of https://github.com/bmw-software-engineering/trlc/pull/64.