ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0005884 | Part 01: TTCN-3 Core Language | Clarification | public | 08-05-2011 18:36 | 01-07-2011 14:46

Reporter | Philip Makedonski |
Assigned To | Ina Schieferdecker |
Priority | high | Severity | text | Reproducibility | N/A
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.3.2 (interim 2011) | Fixed in Version | v4.3.2 (interim 2011) |
Clause Reference(s) | 7.1.3
Source (company - Author) | University of GÃ¶ttingen - Philip Makedonski

Summary | 0005884: Relational operators and inlined values [Part 1: Clause 7.1.3]

Description

There has been some discussion regarding the possibility of using inlined value definitions with relational operators. Take for example:
type record R
{
integer a,
integer b
}
function f(){
var R vl_rec1 := {1,2}
var R vl_rec2 := {1,2}
if (vl_rec1 == vl_rec2) {} //(1)
if (vl_rec2 == {1,2}) {} //(2)
}
As of now, the BNF permits (1) but not (2).
Clause 7.1.3 states that:
"Two record values, set values, record of values or set of values are equal if and only if their effective value structures are compatible (see clause 6.3) and the actual values of all corresponding fields are equal. record values may also be compared to record of values and set values to set of values. In these cases the same rule applies as for comparing two record or set values."
This seems to imply that (2) above (and possibly similar cases) should be accepted as well, although there doesn't seem to be any further evidence pointing to this.
Some clarity on this would be highly appreciated:
- Is it intentional that (2) is not supported? (I can see various reasons for this, an official statement would be helpful, however)
The list operator (Clause 7.1.2) causes some confusion in a similar manner.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | es_20187301v040205m_CR5884.doc (99,840) 26-05-2011 15:24 http://oldforge.etsi.org/mantis/file_download.php?file_id=2507&type=bug core.bnf (57,277) 30-06-2011 17:51 http://oldforge.etsi.org/mantis/file_download.php?file_id=2542&type=bug

Issue History
Date Modified | Username | Field | Change
08-05-2011 18:36 | Philip Makedonski | New Issue |
08-05-2011 18:36 | Philip Makedonski | Clause Reference(s) | => 7.1.3
08-05-2011 18:36 | Philip Makedonski | Source (company - Author) | => University of GÃ¶ttingen - Philip Makedonski
24-05-2011 10:40 | Jacob Wieland - Spirent | Note Added: 0010004 |
24-05-2011 12:02 | Gyorgy Rethy | Status | new => assigned
24-05-2011 12:02 | Gyorgy Rethy | Assigned To | => Jacob Wieland - Spirent
24-05-2011 18:08 | Gyorgy Rethy | Target Version | => Edition 4.3.2 (interim)
24-05-2011 19:13 | Gyorgy Rethy | Priority | normal => high
25-05-2011 10:29 | Jacob Wieland - Spirent | Note Edited: 0010004 |
25-05-2011 10:31 | Jacob Wieland - Spirent | Note Edited: 0010004 |
25-05-2011 10:32 | Jacob Wieland - Spirent | Note Edited: 0010004 |
26-05-2011 13:05 | Jacob Wieland - Spirent | File Added: core.bnf |
26-05-2011 13:06 | Jacob Wieland - Spirent | File Deleted: core.bnf |
26-05-2011 13:06 | Jacob Wieland - Spirent | File Added: core.bnf |
26-05-2011 13:07 | Jacob Wieland - Spirent | Note Added: 0010086 |
26-05-2011 13:11 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Ina Schieferdecker
26-05-2011 15:24 | Jacob Wieland - Spirent | File Added: es_20187301v040205m_CR5884.doc |
26-05-2011 15:24 | Jacob Wieland - Spirent | Note Added: 0010090 |
30-06-2011 17:50 | Ina Schieferdecker | File Deleted: core.bnf |
30-06-2011 17:51 | Ina Schieferdecker | File Added: core.bnf |
30-06-2011 17:51 | Ina Schieferdecker | Note Added: 0010168 |
30-06-2011 17:52 | Ina Schieferdecker | Status | assigned => resolved
30-06-2011 17:52 | Ina Schieferdecker | Fixed in Version | => Edition 4.3.2 (interim)
30-06-2011 17:52 | Ina Schieferdecker | Resolution | open => fixed
01-07-2011 14:46 | Ina Schieferdecker | Status | resolved => closed

Notes

(0010004)
Jacob Wieland - Spirent
24-05-2011 10:40 (edited on: 25-05-2011 10:32)

I wholeheartedly agree.
To be minimally invasive (because the whole Single/Compound expression stuff is defined differently for values and templates), I propose the following changes to allow this:
507. EqualExpression ::= RelExpression {EqualOp RelExpression}
/* STATIC SEMANTICS - If more than one RelExpression exists, then the RelExpressions shall evaluate to specific values of compatible types.
If only one RelExpression exists, it shall not derive a CompoundExpression */
508. RelExpression ::= ShiftExpression [RelOp ShiftExpression] |
CompoundExpression
/* STATIC SEMANTICS - If both ShiftExpressions exist, then each ShiftExpression shall evaluate to a specific integer, Enumerated or float Value or derivatives of these types */
514. AddExpression ::= MulExpression {AddOp MulExpression}
/* STATIC SEMANTICS - Each MulExpression shall resolve to a specific Value. If more than one MulExpression exists and the AddOp resolves to StringOp then the MulExpressions shall be valid operands for StringOp. If more than one MulExpression exists and the AddOp does not resolve to StringOp then the MulExpression shall both resolve to type integer or float or derivatives of these types. If only one MulExpression exists, it shall not derive a CompoundExpression. */
515. MulExpression ::= UnaryExpression {MultiplyOp UnaryExpression} |
CompoundExpression
Only MulExpression and RelExpression can be CompoundExpressions because only equality and concatenation are defined on structured values.
The additional STATIC SEMANTIC restrictions are necesssary to avoid ambiguity between SingleExpression and CompoundExpression, i.e. the derivation SingleExpression =>* CompoundExpression must be forbidden so that rule
Expression ::= SingleExpression | CompoundExpression
remains unambiguous.

(0010086)
Jacob Wieland - Spirent
26-05-2011 13:07

added changed bnf

(0010090)
Jacob Wieland - Spirent
26-05-2011 15:24

added proposal in text-form, added notes/examples for concatenation/comparison operators

(0010168)
Ina Schieferdecker
30-06-2011 17:51

Implemented as proposed with small editorial changes