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

ID | Project | Category | View Status | Date Submitted | Last Update
0004904 | Part 01: TTCN-3 Core Language | Clarification | public | 23-02-2009 14:54 | 13-07-2009 07:23

Reporter | Jacob Wieland - Spirent |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | minor | Reproducibility | N/A
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.2.1 (published 2010-07) | Fixed in Version | v4.2.1 (published 2010-07) |
Clause Reference(s) | 15.3, 15.4. 5.2
Source (company - Author) | Testing Technology (Jacob Wieland)

Summary | 0004904: top-level templates and inline-templates of type default are not allowed

Description

In the standard, it is explicitly forbidden to define templates of type 'default'.
However, it is allowed to define constants, variables, even template variables (as I understand it), parameters and fields of type default.
In the 3.4. version, it is even explicitly allowed to have parameters with default values of type default, even though only the default value 'null' is allowed. (This is also inconsistent, why should ? or other matching mechanisms not be allowed as default value for template parameters of default type?)
Thus, it is possible to define a template of a record containing a default type field, but not a template of default type.
I think this restriction is unnecessary, so I would propose to simply drop it from the standard.
The other way to achieve consistency would be to forbid defaults also for constants and for everything that has to do with templates, i.e. it should not be possible to define templates of a type containing a default field.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR4904_discussionInput_v2.ppt (37,888) 22-04-2009 15:48 http://oldforge.etsi.org/mantis/file_download.php?file_id=2111&type=bug CR4904_resolution_v1.zip (874,798) 09-07-2009 10:59 http://oldforge.etsi.org/mantis/file_download.php?file_id=2200&type=bug CR4904_resolution_v2.zip (908,192) 13-07-2009 07:22 http://oldforge.etsi.org/mantis/file_download.php?file_id=2214&type=bug

Issue History
Date Modified | Username | Field | Change
23-02-2009 14:54 | Jacob Wieland - Spirent | New Issue |
23-02-2009 14:54 | Jacob Wieland - Spirent | Status | new => assigned
23-02-2009 14:54 | Jacob Wieland - Spirent | Assigned To | => Ina Schieferdecker
23-02-2009 14:54 | Jacob Wieland - Spirent | Clause Reference(s) | => 15.3, 15.4. 5.2
23-02-2009 14:54 | Jacob Wieland - Spirent | Source (company - Author) | => Testing Technology (Jacob Wieland)
27-02-2009 10:31 | Gyorgy Rethy | Note Added: 0008205 |
27-02-2009 13:25 | Jacob Wieland - Spirent | Note Added: 0008206 |
27-02-2009 13:59 | Gyorgy Rethy | Note Added: 0008207 |
27-02-2009 14:01 | Gyorgy Rethy | Note Edited: 0008207 |
28-02-2009 10:31 | Jacob Wieland - Spirent | Note Added: 0008208 |
03-03-2009 11:04 | Gyorgy Rethy | Note Added: 0008221 |
10-03-2009 10:22 | Ina Schieferdecker | Target Version | => Edition 4.2.1 (not yet published)
20-04-2009 11:48 | Ina Schieferdecker | Assigned To | Ina Schieferdecker => Gyorgy Rethy
21-04-2009 15:04 | Gyorgy Rethy | File Added: what can be of default type.doc |
21-04-2009 15:07 | Gyorgy Rethy | File Deleted: what can be of default type.doc |
21-04-2009 15:07 | Gyorgy Rethy | File Added: what can be of default type.doc |
22-04-2009 11:06 | Gyorgy Rethy | File Deleted: what can be of default type.doc |
22-04-2009 11:13 | Gyorgy Rethy | File Added: CR4904_discussionInput_v1.ppt |
22-04-2009 11:14 | Gyorgy Rethy | Note Added: 0008531 |
22-04-2009 12:16 | Jacob Wieland - Spirent | Note Added: 0008533 |
22-04-2009 12:17 | Jacob Wieland - Spirent | Note Edited: 0008533 |
22-04-2009 14:14 | Gyorgy Rethy | File Deleted: CR4904_discussionInput_v1.ppt |
22-04-2009 14:14 | Gyorgy Rethy | File Added: CR4904_discussionInput_v1.ppt |
22-04-2009 14:19 | Gyorgy Rethy | Note Added: 0008538 |
22-04-2009 14:52 | Jacob Wieland - Spirent | Note Added: 0008540 |
22-04-2009 15:07 | Gyorgy Rethy | Note Added: 0008541 |
22-04-2009 15:48 | Gyorgy Rethy | File Added: CR4904_discussionInput_v2.ppt |
22-04-2009 15:55 | Gyorgy Rethy | Note Added: 0008542 |
22-04-2009 16:46 | Jacob Wieland - Spirent | Note Added: 0008545 |
22-04-2009 18:27 | Gyorgy Rethy | Note Added: 0008548 |
22-04-2009 18:27 | Gyorgy Rethy | File Deleted: CR4904_discussionInput_v1.ppt |
24-04-2009 12:01 | Jacob Wieland - Spirent | Note Added: 0008552 |
07-07-2009 08:08 | Ina Schieferdecker | Note Added: 0008851 |
08-07-2009 16:17 | Ina Schieferdecker | Note Deleted: 0008851 |
09-07-2009 10:59 | Gyorgy Rethy | File Added: CR4904_resolution_v1.zip |
09-07-2009 11:02 | Gyorgy Rethy | Note Added: 0008881 |
09-07-2009 11:06 | Gyorgy Rethy | Note Edited: 0008881 |
09-07-2009 11:07 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Ina Schieferdecker
09-07-2009 11:07 | Gyorgy Rethy | Resolution | open => fixed
13-07-2009 07:22 | Ina Schieferdecker | File Added: CR4904_resolution_v2.zip |
13-07-2009 07:22 | Ina Schieferdecker | Note Added: 0008894 |
13-07-2009 07:23 | Ina Schieferdecker | Status | assigned => resolved
13-07-2009 07:23 | Ina Schieferdecker | Fixed in Version | => Edition 4.2.1 (not yet published)
13-07-2009 07:23 | Ina Schieferdecker | Status | resolved => closed

Notes

(0008205)
Gyorgy Rethy
27-02-2009 10:31

default is not allowed for template variables: "11.2 Template variables
A TTCN-3 template variable stores templates.". I.e. in this respect, the same restriction apply to template variables as to templates (they do differ from templates only in the dynamics of defining the content).
If you think about the use of defaults, if would make no sense to allow defaults for templates; default variables store handles of activated defaults, which has local significance only and loose sense outside of the given component. Hence, default values are not know when writing global definitions and cannot be sent outside of a component.
If this is not specified clearly enough in the text, the explanation shall be made more clear.

(0008206)
Jacob Wieland - Spirent
27-02-2009 13:25

Then why allow template parameters of type default (and restrict their default value explicitly to only 'null'?) This seems inconsistent (or maybe it is just a copy/paste error?).
Also, you forget that templates can not only be used for sending/receiving messages. They can also used locally with the 'match' operation or with the 'select' statement. In that respect, a template that enumerates certain activated defaults could be a valid template.
An example:
function deactivateIfMatches(default d, template default dt) {
if (match(d, dt)) {
deactivate(d);
}
}
then suppose, you get passed a default parameter and you want to deactivate it only, if it is one of a list of defaults which you have stored in variables.
deactivateIfMatches(d, (d1, d2, d3))
The same could be true if you want to deactivate it unless it is one of the list:
deactivateIfMatches(d, complement(d1, d2, d3))
Of course, these scenarios may be far fetched, but if such things work for other data types, why should default be any different? I could understand a restriction that default values cannot be sent and therefore any receive operation using a template with defaults would make no sense, either. But, this should not be achieved by restricting the definition of templates of that type, but by restricting the communication statements.
Sure, as globally, no default references are known, for global templates only the matching mechanisms which do not refer to any specific default instance are allowed (like ?, *, etc.), but, for generic or local templates, no such restriction is necessary.

(0008207)
Gyorgy Rethy
27-02-2009 13:59 (edited on: 27-02-2009 14:01)

The user do not need a template for that. Even if default is allowed in templates, only concrete values and the AnyValue matching would be possible to use, as the concrete default values are not known. But using AnyValue is the same as a non-null value or isvalue. Thus, the same use case can be coded by more than one alternative ways, e.g.
type record of default RD;
function deactivateIfMatches(default d, RD rd) {
for (var integer i := 0; i<lengthof(rd); i:=i+1) {
if (rd[i]==d) {deactivate(d)}
}
}
But allowing defaults in templates is too dangerouos and I cannot see a real use case for it, i.e. a problem, which cannot be solved by coding techniques available today. The same is true to the other examples you mention.
Inconsistencies, of course, shall be removed. This will be the task of the next language maintenance project.

(0008208)
Jacob Wieland - Spirent
28-02-2009 10:31

The problem I have with this is the following:
If it is so "dangerous" do define templates of type default, then why is it not forbidden also to define templates of a structured type that contains a default type element somewhere? Either this must also be forbidden (as it is as "dangerous" as defining a top-level default type template), or the top-level template must be allowed. The reason, as I see it is, that it is of course USEFUL to have structured types that can also contain default fields (as your alternative implementation of my example shows). If it were also forbidden, it would not even be possible to implement such a scenario as I have described.
Thus, since such a restriction would be impractical, I still think that simply forbidding all communication operations to use templates that contain a default value, which can easily be checked statically, would avert the "danger" that you are talking about, as well.
The benefit of this approach is, of course, that the powerful and elegant matching mechanisms that exist in the language can be used for all types, and it is not necessary to use the "cruder" means of iterating over arrays or suchlike.
The same arguments can also be applied to component types, of course.

(0008221)
Gyorgy Rethy
03-03-2009 11:04

Component types do differ: component references are unique within the test system, while default references are unique within a test component only. I agree with you in that top-level default types and default fields shall be handled in the same way. For me it would be also fine to disallow any templates containing default (i.e. top-level or in embedded fields) in sending operations only.

(0008531)
Gyorgy Rethy
22-04-2009 11:14

The file CR4904_discussionInput_v1.ppt contains exactly what its name suggests: input for the discussion.

(0008533)
Jacob Wieland - Spirent
22-04-2009 12:16 (edited on: 22-04-2009 12:17)

Somehow, the discussion input presentation seems to ignore most of the discussion which took place before and also negates the compromise that seemed to have been reached.
The question remains: Why forbid elegant means of matching (via match/select opterations) for one data type that is allowed for all other data types?
Every unnecessary restriction makes the language harder to use (no one can keep all the restrictions in mind) and also harder to compile (every restriction must be checked which slows down the compiler). Both these things make developing test suites more expensive as it will take more time.
The danger that a component-local default reference is passed outside its scope can also be averted by restricting the means of passing such references to other scopes (i.e. communication operations, starting of ptcs, maybe external functions).
The advantage of this approach is
a) it is understandable (and thus easier to keep in mind as the arbitrary restriction on templates)
b) it is consistent with the handling of other data types that are only used locally,
c) it is as easy/hard to check as the other proposed restriction.
Thus, I think it is a better approach as it has not all of the drawbacks and some advantages over the other while still achieving the same goal of averting the aforementioned danger.

(0008538)
Gyorgy Rethy
22-04-2009 14:19

Pls. don't mix up persnal view with an STF discussion. Could you give a concrete example on - how to create a meaningful default template? - exactly what matching could be used on it that cannot be solved by using existing operations on values?

(0008540)
Jacob Wieland - Spirent
22-04-2009 14:52

That is beside the point. It is not necessary that I provide an example. Please address the issues I have raised and do not simply dismiss them as personal opinon.
Of course, everything can be done with value operations. That is true for all other types, as well and we allow templates there nonetheless to allow short-hand notations for complex predicates. If templates could only be used for communication, I would see your point, but since that is not the case, I think it is invalid.
Since there is an elegant syntax (like value-list, complement, subset, superset, ?) which enables you to write down very complicated things in a relatively short way, why forbid users to USE this syntax for this special type and force them to write the complicated algorithms themselves if they actually need such a complicated check. If I were a TTCN-3 user, I would wonder about such idiosyncracies. Just because you and I cannot think of a meaningful real-world example doesn't mean that there isn't one. Why restrict the language unnecessarily? That is my question.
You want to reach a certain goal to avoid programming errors, fine. There are two (proposed) ways to reach that goal. Your proposal restricts the language more than necessary for reaching the goal because it restricts valid possible applications of the template mechanism. My proposal restricts the language exactly as necessary to reach the goal because it still allows templates containing default values to be used by match operations or select constructs.
So, why is your proposal better? Shouldn't we keep the language as simple and flexible and usable as possible?

(0008541)
Gyorgy Rethy
22-04-2009 15:07

Hi Jacob,
what I meant on personal opinion is my sentence from 3rd of March: "For me it would be also fine ..." etc.
Your notes/comments are taken into consideration properly.
You wrote: "It is not necessary that I provide an example.". As you are asking to change the language rules, a proper reason has to be provided. Either a use-case example that cannot be solved by the existing language features or the solution is over-complicated, or e.g. a language inconsistency issue. The reason you provided currently falls into the second category. So it can be solved both in the more strict or in the more loose directions. In TTCN-3 we prefer if more errors can be found compile time that hints the solution in the more strict direction.

(0008542)
Gyorgy Rethy
22-04-2009 15:55

In CR4904_discussionInput_v2.ppt: more analysis added on possible use of matching with defaults.

(0008545)
Jacob Wieland - Spirent
22-04-2009 16:46

Okay, sorry for the misunderstanding. I don't think that every language feature must be motivated by a now-existing real-world use-case. The consistency of the language is much more important in my view.
I don't think that it can be argued that in one proposal more can be checked at compile time than in the other.
The proposal to restrict the communication statements to only templates not containing values/fields of default type can also be checked at compile time as the type of the sent template is always known.
The only exception is the anytype type where the contents are not known. However, the same problem occurs as well in your more restrictive variant, i.e. if all templates are forbidden for types that are/contain values of type default, this can be circumvented by using anytype instead (and using the anytype to encapsulate a value of type default).
This obviously can only be checked at runtime (in either version).

(0008548)
Gyorgy Rethy
22-04-2009 18:27

STF discussion on 22/April/2009:
- the inconsistency raised by the CR exists in the standard;
- template formal parameters, template variables and function template returns are not forbidden to be of default type but table 10 prevents to assign them any content (even specific value);
- the proposal of the STF is to consistently forbid all template-kind language elements to be of default type;
- ask the tool vendors if there is any problem with the prposed changes;
- check if this restriction can be done in a single place in the standard instead of spreading t over several clauses;
- in addition check, if sending/receiving default values is forbidden explicitly

(0008552)
Jacob Wieland - Spirent
24-04-2009 12:01

For consistency's sake, if you want to forbid all templates for type default, then all templates for structured types that contain type default should also be forbidden.

(0008881)
Gyorgy Rethy
09-07-2009 11:02 (edited on: 09-07-2009 11:06)

CR4904_resolution_v1.doc: Resolution according to the CR resolution meeting decision. Not much text but spread almost all over Part-1. Therefore the whole Part-1 file is included, with modifications. To be checked.

(0008894)
Ina Schieferdecker
13-07-2009 07:22

editorial corrections - see v2