Loading meetings/2025-11-25_Nokia_Ulm.md 0 → 100644 +205 −0 Original line number Original line Diff line number Diff line # Work Session November 25th to 28th, 2025 in Ulm. Major task of this session was to continue with the migration guide. Topics worth mentioning were: ## Attribute handling in import statements Rules for attribute propagation are sound. However, attributes attached to an import statement, can introduce complications for the TTCN-3 runtime: ```ttcn3 module A { type integer int; const charstring X := int.encode; // expected: "" } module B { import from A with { encode "B" } const charstring X := int.encode; // expected: "B" } module C { import from A with { encode "C" } const charstring X := int.encode; // expected: "C" } ``` A type is thought of only having one "slot" for encoding attributes. In this example, however, the type "A.int" is required to have three different attributes. Our current approach is to prohibit modification of attributes through imports. This means, the import statements across the test suite must not contradict each other and must not use `override` either. Also some more examples would be helpful. ## Predefined functions If something is a predefined function, a statement or an operation has historical reasons mostly. We discussed minor cleaning up. For example, moving `action` and `log` into the annex and moving `lengthof` and `sizeof` into the core body. The exact details are a topic for next TTF. ## Embedding Embedding was introduced as stepping stone for new language features that provide safe sharing of TTCN-3 behaviour between types. We decided to remove embedding for now, since introduction of new language features has lower priority. ## Controlling communication ports Originally we planned to remove `start`, `stop` and `halt` from the core language specification. These operations however are intertwined with `checkstate`, which we like to keep. Removing them would require awkward workarounds to keep `checkstate` working. We decided to leave port controlling operations as they are. ## Port `setencode` This feature is part of multiple encoding, which we'd like to remove. Therefore we would prefer to remove this feature, as well. ## Conversion functions Defining `charstring` as a subtype of `universal charstring` is simple from a language perspective. There might be issues on a implementation level however: The elements of `universal charstrings` are 4 bytes in size, while `charstring` only is 1 byte. This could introduce issues with the conversion functions. A possible solution would be introducing additional conversion functions for universal charstrings. ### OOP and exceptions We would like to keep the OOP document as it is, for now. Because Titan is the only tool currently that implements this extension and we have to focus on the core first and postpone discussions about OOP (together with embedding). We like to move the exceptions feature into the core or the extension document, _if_ it does not depend on object oriented feature. Moving it into the core could be a challenge though, since it requires to distinguish between compile time errors and run time errors. ## Keywords We discussed whether keywords from extensions should be reserved in the core language spec or not. We agreed that all keywords shall be reserved in the core language spec. Changes in syntax and keywords in extensions have to be kept to a minimum, though. And we should make use of predefined identifiers as much as possible. Because unlike keywords, compatibility issues with predefined identifiers are easy to resolve. Example for predefined identifiers: ```ttcn3 // An old version, when `object` was not reserved. module A language "2005" { const integer object := 1; } // A newer version that uses JSON objects module B { import from A all; control { var object obj := none; log(A.object); // You can use fully qualified identifiers to differenciate // between predefined `object` and imported constant. } } ``` Keywords on the other hand can introduce syntax ambiguity. For example, if `for` would be a valid identifier: ```ttcn3 // Naming a function "for" creates much parsing-trouble, when allowed. function for(in integer i) { log("parameter i is ", i); } control { var integer i; for(i:=10; i<10; i++); // is this a malformed function call // or a malformed counter-loop? } ``` What will become keyword in the end depends on the individual case and will be discussed during the next TTF. We did not come to a conclusion whether to include extension-syntax changes in the core language BNF as well. ## Templates Resolving issues with templates is difficult. Because individual requirements and implementation differ widely. We had multiple discussions, including with testers and tool vendors who could not participate in the TTF directly. A detailed description will be provided shortly. Here's the summary: - Not-parameterized templates are semantically equivalent to constants: The value is computed when the template is declared, once. - Parameterized templates are semantically equivalent to functions. The value is computed when the template is used. In this context the term 'used' means the same as 'applied' or 'instantiated'. - local parameterized template will be prohibited in the core language spec; to prevent unexpected behaviour by capturing variable data. Local parameterized template could be reintroduced with the behaviour types extension, though. To help with migration and to soften compatibility issues we plan to introduce some kind of module scope feature switch to enable re-evaluation of not-parameterized templates. This could be some form of macro, pragma, modifier or an attribute similar to implicit-omit. Such switch would make all constant templates to parameterized templates. For example: ```ttcn3 module M { testcase tc() { var charstring a[3] := {"a", "b", "c"}; var integer i := 0; template charstring t := a[i]; i := 2; if (not match("c", t)) { setverdict(pass); } else { setverdict(fail); } } } with { template "dynamic" } ``` > COMMENT(Matthias): Isn't this just `@lazy` with extra steps? Loading
meetings/2025-11-25_Nokia_Ulm.md 0 → 100644 +205 −0 Original line number Original line Diff line number Diff line # Work Session November 25th to 28th, 2025 in Ulm. Major task of this session was to continue with the migration guide. Topics worth mentioning were: ## Attribute handling in import statements Rules for attribute propagation are sound. However, attributes attached to an import statement, can introduce complications for the TTCN-3 runtime: ```ttcn3 module A { type integer int; const charstring X := int.encode; // expected: "" } module B { import from A with { encode "B" } const charstring X := int.encode; // expected: "B" } module C { import from A with { encode "C" } const charstring X := int.encode; // expected: "C" } ``` A type is thought of only having one "slot" for encoding attributes. In this example, however, the type "A.int" is required to have three different attributes. Our current approach is to prohibit modification of attributes through imports. This means, the import statements across the test suite must not contradict each other and must not use `override` either. Also some more examples would be helpful. ## Predefined functions If something is a predefined function, a statement or an operation has historical reasons mostly. We discussed minor cleaning up. For example, moving `action` and `log` into the annex and moving `lengthof` and `sizeof` into the core body. The exact details are a topic for next TTF. ## Embedding Embedding was introduced as stepping stone for new language features that provide safe sharing of TTCN-3 behaviour between types. We decided to remove embedding for now, since introduction of new language features has lower priority. ## Controlling communication ports Originally we planned to remove `start`, `stop` and `halt` from the core language specification. These operations however are intertwined with `checkstate`, which we like to keep. Removing them would require awkward workarounds to keep `checkstate` working. We decided to leave port controlling operations as they are. ## Port `setencode` This feature is part of multiple encoding, which we'd like to remove. Therefore we would prefer to remove this feature, as well. ## Conversion functions Defining `charstring` as a subtype of `universal charstring` is simple from a language perspective. There might be issues on a implementation level however: The elements of `universal charstrings` are 4 bytes in size, while `charstring` only is 1 byte. This could introduce issues with the conversion functions. A possible solution would be introducing additional conversion functions for universal charstrings. ### OOP and exceptions We would like to keep the OOP document as it is, for now. Because Titan is the only tool currently that implements this extension and we have to focus on the core first and postpone discussions about OOP (together with embedding). We like to move the exceptions feature into the core or the extension document, _if_ it does not depend on object oriented feature. Moving it into the core could be a challenge though, since it requires to distinguish between compile time errors and run time errors. ## Keywords We discussed whether keywords from extensions should be reserved in the core language spec or not. We agreed that all keywords shall be reserved in the core language spec. Changes in syntax and keywords in extensions have to be kept to a minimum, though. And we should make use of predefined identifiers as much as possible. Because unlike keywords, compatibility issues with predefined identifiers are easy to resolve. Example for predefined identifiers: ```ttcn3 // An old version, when `object` was not reserved. module A language "2005" { const integer object := 1; } // A newer version that uses JSON objects module B { import from A all; control { var object obj := none; log(A.object); // You can use fully qualified identifiers to differenciate // between predefined `object` and imported constant. } } ``` Keywords on the other hand can introduce syntax ambiguity. For example, if `for` would be a valid identifier: ```ttcn3 // Naming a function "for" creates much parsing-trouble, when allowed. function for(in integer i) { log("parameter i is ", i); } control { var integer i; for(i:=10; i<10; i++); // is this a malformed function call // or a malformed counter-loop? } ``` What will become keyword in the end depends on the individual case and will be discussed during the next TTF. We did not come to a conclusion whether to include extension-syntax changes in the core language BNF as well. ## Templates Resolving issues with templates is difficult. Because individual requirements and implementation differ widely. We had multiple discussions, including with testers and tool vendors who could not participate in the TTF directly. A detailed description will be provided shortly. Here's the summary: - Not-parameterized templates are semantically equivalent to constants: The value is computed when the template is declared, once. - Parameterized templates are semantically equivalent to functions. The value is computed when the template is used. In this context the term 'used' means the same as 'applied' or 'instantiated'. - local parameterized template will be prohibited in the core language spec; to prevent unexpected behaviour by capturing variable data. Local parameterized template could be reintroduced with the behaviour types extension, though. To help with migration and to soften compatibility issues we plan to introduce some kind of module scope feature switch to enable re-evaluation of not-parameterized templates. This could be some form of macro, pragma, modifier or an attribute similar to implicit-omit. Such switch would make all constant templates to parameterized templates. For example: ```ttcn3 module M { testcase tc() { var charstring a[3] := {"a", "b", "c"}; var integer i := 0; template charstring t := a[i]; i := 2; if (not match("c", t)) { setverdict(pass); } else { setverdict(fail); } } } with { template "dynamic" } ``` > COMMENT(Matthias): Isn't this just `@lazy` with extra steps?
