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

ID | Project | Category | View Status | Date Submitted | Last Update
0005671 | Part 01: TTCN-3 Core Language | Clarification | public | 30-08-2010 10:28 | 20-05-2011 15:51

Reporter | Gyorgy Rethy |
Assigned To | Gyorgy Rethy |
Priority | low | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | won't fix |
Platform |  | OS |  | OS Version |
Product Version | v4.1.1 (published 2009-06) |
Target Version | v4.3.2 (interim 2011) | Fixed in Version |  |
Clause Reference(s) | general
Source (company - Author) | L.M.Ericssson

Summary | 0005671: Bound-unbound should be handled in a consistent way

Description

Curently "boundness" and "unboundness" is not handled consistently in case of record/set and record/set of types:
- record ofs with a whole is handled as completely initialized
- records with a "whole" (field is uninitialized) is partly initialized
- constants needs not be completely initialized (to be checked and discus if this was the intention or should be changed)
- unclear if a not-completely-initialized value/template can be assigned to a variable (directly, i.e. not participating in an expresion)

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR5671.doc (110,592) 02-09-2010 11:02 http://oldforge.etsi.org/mantis/file_download.php?file_id=2436&type=bug

Issue History
Date Modified | Username | Field | Change
30-08-2010 10:28 | Gyorgy Rethy | New Issue |
30-08-2010 10:28 | Gyorgy Rethy | Clause Reference(s) | => general
30-08-2010 10:28 | Gyorgy Rethy | Source (company - Author) | => L.M.Ericssson
30-08-2010 11:15 | Gyorgy Rethy | Status | new => assigned
30-08-2010 11:15 | Gyorgy Rethy | Assigned To | => Jacob Wieland - Spirent
31-08-2010 10:39 | Jacob Wieland - Spirent | Note Added: 0009660 |
02-09-2010 10:50 | Jacob Wieland - Spirent | File Added: CR5671.doc |
02-09-2010 10:53 | Jacob Wieland - Spirent | Note Added: 0009694 |
02-09-2010 10:56 | Jacob Wieland - Spirent | File Deleted: CR5671.doc |
02-09-2010 10:56 | Jacob Wieland - Spirent | File Added: CR5671.doc |
02-09-2010 11:00 | Jacob Wieland - Spirent | File Deleted: CR5671.doc |
02-09-2010 11:02 | Jacob Wieland - Spirent | File Added: CR5671.doc |
02-09-2010 11:03 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
03-09-2010 09:23 | Gyorgy Rethy | Target Version | => Edition 4.3.1 (not yet published)
26-11-2010 15:17 | Gyorgy Rethy | Note Added: 0009809 |
26-11-2010 15:18 | Gyorgy Rethy | Note Added: 0009810 |
29-11-2010 09:29 | Jacob Wieland - Spirent | Note Added: 0009817 |
29-11-2010 10:50 | Gyorgy Rethy | Note Added: 0009821 |
29-11-2010 10:51 | Gyorgy Rethy | Priority | normal => low
03-12-2010 10:11 | Gyorgy Rethy | Target Version | Edition 4.3.1 (not yet published) => Edition 4.3.2 (interim)
20-05-2011 15:51 | Gyorgy Rethy | Note Added: 0010002 |
20-05-2011 15:51 | Gyorgy Rethy | Status | assigned => closed
20-05-2011 15:51 | Gyorgy Rethy | Resolution | open => won't fix

Notes

(0009660)
Jacob Wieland - Spirent
31-08-2010 10:39

Regarding the record ofs:
Section 3.1 (completely initialized) states:
Values and templates of structured types and arrays are completely initialized if all their fields and elements are completely initialized.
Although it should probably be 'variables' instead of 'values'. This error continues in the whole section.
The question where a not completely initialized variable can be used is answered in section 11.1.
d) Use of uninitialized or not completely initialized value variables at other places than the left hand side of assignments or as actual parameters passed to inout or out formal parameters shall cause an error.
The same restriction is reiterated for template variables.
For operation expressions, function calls and predefined function calls, this restriction is also reiterated for the operands (i.e. have to be completely initialized).
=============================================================================
Regarding the constants:
Constants are assigned a VALUE (see section 10). Since only VARIABLES can be unbound or partially initialized, values are always fully initialized structures and therefore a constant is also always fully initialized.
==============================================================================
Regarding the unbound-assignment question, section 19.1 states clearly:
"During execution of an assignment, the right-hand side of the assignment shall evaluate to a value or template. The effect of an assignment is to bind the variable to the value of the expression or to a template. The expression shall contain no unbound variables."
===============================================================================
Unfortunately, there is no clear definition what a value actually is, although lots of definitions depend on that. Thus, I think a definition like:
A value is either
- a basic value (string, integer, float, enumerated) or
- a structured value (record, set, union) where all mandatory fields contain values and all optional fields contain either values or are omitted. For union values exactly one variant must be chosen and contain a value.
Also, the term evaluation is used frequently in the standard but also not defined. So, maybe another definition needs to be added here.
The evaluation of a value expression yields a value.
The evaluation of a template expression yields a template.
An expression is evaluated by evaluating all operation expressions and replacing them with the result of the evaluation. The order of evaluation is left-to-right-inside-out. An operation expression is evaluated by performing the operation on its evaluated operands.
==============================================================================
SUMMARY:
in essence, the standard is consistent and the CR is moot. The only problem that I could find is the missing definitions of value and evaluate (and the mentioning of values instead of variables in the initialized definitions).
Therefore, the questions could be clarified by fixing this.

(0009694)
Jacob Wieland - Spirent
02-09-2010 10:53

I've added the following definitions:
value, reference, evaluation (and they should be read in that order because evaluation depends on value and reference)
I've changed some definitions, especially 'partially initialized' and 'completely initialized' to use these terms.
I've also changed the definition of value notation as it didn't make any sense to me whatsoever.
I hope this is clarification enough for this CR.

(0009809)
Gyorgy Rethy
26-11-2010 15:17

Just a few examples of inconsistency:
type record Record { integer x1, integer x2}
const Record cg_rec := { x2 := 5 } //allowed!? (not forbidden)
function f1(in Record pl_rec) {
var integer vl_int := pl_rec.x2
}
function f3() {
var integer vl_int;
var Record vl_rec := {x2:=5} //partly initialized
f1(cg_rec)} //allowed!?
f1({x2 := 5}) //allowed!
vl_int := vl_rec.f2 //allowed, but not allowed to do the same within a function by passing vl_rec as in parameter
f1(vl_rec)} //not allowed!
}
function f4(inout Record pl_rec) {...}
function f5() {
var Record vl_rec := {x2:=5} //partly initialized
var template Record vt_rec := {x2:=5} //partly initialized
f4(vl_rec)} //allowed!
f4(vt_rec)} //not allowed!
}
We can argue if const Record cg_rec := { x2 := 5 } is allowed or not; I know the general theory on type/value systems and saying myself that a valid/legal value of a type shall be a complete instance of the type. However, "value" is not defined in the standard and its also talks about "variable value"s in contexts, when the content of a variable is not necessary completely initialized. Therefore, what a "variable value" and a "constant value" exactly means, is not clearly defined. Hence, if a tool allows partly initialized constants, it cannot be claimed to be non-conformant to the standard.
And whatever is the decision regarding constants, there is still the case of literal values(inline templates) vs. constants and variables.
Probably it is just due to the incompleteness of the text, that incomplete value variables can be passed to inout parameters, while incomplete template variables cannot. But still, these are inconsistencies.
Btw., it is unclear, why we mix the direction of the "content flow" with the completeness of this content. In another words, why partly initialized values (or how to call it?)cannot be passed to in parameters? This has several use cases:
a) during testing, the database containing data of the simulated users is typically being completed step-by-step or some data (fields) may even remain unbound all the time (e.g. redirected_to_number)). Currently it is not possible to write a function to process part of the data AND to assure that the function only reads but not changes the data in the database. This is because incomplete data cannot be passed to in parameters.
b) during constracting a message the user need to calculate some parameter by using a few already available other parameters from the partly constructed message. Again, it is not possible to assure, that the function making the calculation is not changing the content, because no partly initialized data can be passed to in parameters.
Pls. note, that in both cases above, passing the fields used within the called function one-by-one as separate parameters is not possible:
- maintenance and backward compatibility: changes within the function could change the function interface (new data required) that would break existing "user" code and
- convenience, efficiency and readibility: the number of such parameters is often quite significant.

(0009810)
Gyorgy Rethy
26-11-2010 15:18

Just a few examples of inconsistency:
type record Record { integer x1, integer x2}
const Record cg_rec := { x2 := 5 } //allowed!? (not forbidden)
function f1(in Record pl_rec) {
var integer vl_int := pl_rec.x2
}
function f3() {
var integer vl_int;
var Record vl_rec := {x2:=5} //partly initialized
f1(cg_rec)} //allowed!?
f1({x2 := 5}) //allowed!
vl_int := vl_rec.f2 //allowed, but not allowed to do the same within a function by passing vl_rec as in parameter
f1(vl_rec)} //not allowed!
}
function f4(inout Record pl_rec) {...}
function f5() {
var Record vl_rec := {x2:=5} //partly initialized
var template Record vt_rec := {x2:=5} //partly initialized
f4(vl_rec)} //allowed!
f4(vt_rec)} //not allowed!
}
We can argue if const Record cg_rec := { x2 := 5 } is allowed or not; I know the general theory on type/value systems and saying myself that a valid/legal value of a type shall be a complete instance of the type. However, "value" is not defined in the standard and its also talks about "variable value"s in contexts, when the content of a variable is not necessary completely initialized. Therefore, what a "variable value" and a "constant value" exactly means, is not clearly defined. Hence, if a tool allows partly initialized constants, it cannot be claimed to be non-conformant to the standard.
And whatever is the decision regarding constants, there is still the case of literal values(inline templates) vs. constants and variables.
Probably it is just due to the incompleteness of the text, that incomplete value variables can be passed to inout parameters, while incomplete template variables cannot. But still, these are inconsistencies.
Btw., it is unclear, why we mix the direction of the "content flow" with the completeness of this content. In another words, why partly initialized values (or how to call it?)cannot be passed to in parameters? This has several use cases:
a) during testing, the database containing data of the simulated users is typically being completed step-by-step or some data (fields) may even remain unbound all the time (e.g. redirected_to_number)). Currently it is not possible to write a function to process part of the data AND to assure that the function only reads but not changes the data in the database. This is because incomplete data cannot be passed to in parameters.
b) during constracting a message the user need to calculate some parameter by using a few already available other parameters from the partly constructed message. Again, it is not possible to assure, that the function making the calculation is not changing the content, because no partly initialized data can be passed to in parameters.
Pls. note, that in both cases above, passing the fields used within the called function one-by-one as separate parameters is not possible:
- maintenance and backward compatibility: changes within the function could change the function interface (new data required) that would break existing "user" code and
- convenience, efficiency and readibility: the number of such parameters is often quite significant.

(0009817)
Jacob Wieland - Spirent
29-11-2010 09:29

Here's my opinion on what should be consistently allowed/disallowed:
type record Record { integer x1, integer x2}
const Record cg_rec := { x2 := 5 } //allowed!? (not forbidden)
FORBIDDEN
function f1(in Record pl_rec) {
var integer vl_int := pl_rec.x2
}
function f3() {
var integer vl_int;
var Record vl_rec := {x2:=5} //partly initialized
ALLOWED (although I still would forbid this syntax and allow only assignment using dotted notation to avoid confusion with the whole implicit/explicit omit issue)
f1(cg_rec)} //allowed!?
FORBIDDEN
f1({x2 := 5}) //allowed!
FORBIDDEN (not completely initialized in parameter)
vl_int := vl_rec.f2 //allowed, but not allowed to do the same within a function by passing vl_rec as in parameter
FORBIDDEN (dottet notation on right-hand-side should only work on completely initialized variables)
f1(vl_rec)} //not allowed!
FORBIDDEN (not completely initialized in parameter)
}
function f4(inout Record pl_rec) {...}
function f5() {
var Record vl_rec := {x2:=5} //partly initialized
ALLOWED (although should be forbidden, see above)
var template Record vt_rec := {x2:=5} //partly initialized
ALLOWED (althoudh should also be forbidden, see above)
f4(vl_rec)} //allowed!
ALLOWED
f4(vt_rec)} //not allowed!
FORBIDDEN (but only because of missing template modifier in formal parameter in f4, otherwise should also be allowed)
}
The reasoning behind forbidding not completely initialzed variables as r-values is that this allows tools to generate efficient code (not having to do lots of is-this-field-initialized-checking at runtime which is time-consuming)/catch user errors already at compile time to prevent costly error-finding in the running code.
So, while it might be appealing to allow the users the freedom to leave everything partially initialized, this will always backfire later on as the two above problems cannot be avoided otherwise.
If you need to pass data structures around that you need to initialize part-by-part, you should use optional fields for the parts that you want to initialize later on. That way, it in in the hands of the user to know (or ask, if necessary) if a field is already initialized before usage. So, the language already allows your use-cases by usage of that feature.
The argument of the breaking of existing code because of additional parameters is moot because that has been solved with the feature of the parameters with default values. This feature (together with the name-assignment-parameter-syntax) also pretty much solves the issue of the a-lot-of-parameters problem.
For these reasons, in my opinion we should clarify the standard in such a way that
a) a value is a completely initialized construct
b) a constant is initialized with a value at declaration
c) all variables can be partially initialized
d) partially initialized variables can only be used on the left-hand-side of an assignment (or as an out-parameter which is the same as left-hand-side of an assigment).
If this in the real world leads to unmanageably clumsy code, we should think of shorthand notations which do not imply performance/maintenance issues as allowing partially initialized constructs everywhere does.
Personally, for the same reasons and from a compiler-constructor's point of view, I would even forbid partially initialized variables as that is a feature which has no place in a type-safe language.

(0009821)
Gyorgy Rethy
29-11-2010 10:50

I propose to put aside this CR as we cannot even agree what is allowed today and what is not (I'm talking about the actual text, not about what should be or not should be; but seems text itself should be analysed in more detail). This week we shall concentrate on CRs that have the chance to be resolved.

(0010002)
Gyorgy Rethy
20-05-2011 15:51

CR is withdrawn.