Loading meetings/2025-09-08.md 0 → 100644 +179 −0 Original line number Diff line number Diff line # Work Session September 8th to 11nd, 2025 in Tallinn. This work session's main purpose was to review the planned changes for the next major release and assign work items for the migration guide. Generally speaking, the changes for the major release will be as outlined in previous sessions, with some minor details. Some topics were discussed in more detail: ## Types and Values Nomenclatures have to be refined. For example `default` and enumerated types should not be structured types; basic string types could be moved into a list-types section; a definition for reference types could be useful, etc. Since we don't intend to change behaviour, finishing this task not required for the migration guide. But rather a topic for the major release of the core language specification. # Open Type Last session we discussed to merge `anytype` and `any`. As it turned out such merge is not just a matter of definition, but more complicated than we anticipated: The open type behaves as union on TTCN-3 language level, but on TCI/TRI level it behaves more like an empty interface in Go or a void-pointer in C. When we pass `anytype` to an external function a TciValue with type `union` will be transmitted. However, when we pass `any` the runtime variant will be transmitted directly. If a tool implements TCI/TRI that won't make a difference. However, it will be difficult to implement, if the tool generates highly efficient code, internalized codecs, etc. Therefore we probably won't merge those two types. However, `anytype` could help with a different issue: **Unknown embedded payloads** TTCN-3 promotes simple, flat, descriptive code. So, when we encounter `anytype` or `any`, it usually is because someone tried to implement smart software engineering patterns. Being smart in TTCN-3 often leads to code that is difficult to maintain. Our usual advice is to stick with as much simple, static TTCN-3 code as possible. However, we also acknowledge that testing unknown embedded payloads is a common problem, that hasn't necessarily a simple, flat, descriptive solution. We discussed this problem and potential improvements. The way forward is proposing a new extension as trial before any changes will make it in the core language specification. Details will be provided and discussed in a separate proposal. # Template evaluation (lazy/fuzzy) The standard unfortunately allows different readings for template evaluation. This makes removing lazy/fuzzy without breaking compatibility difficult. We discussed possible complications and solutions. The proposal in issue #77 will be presented in the next workshop. # Unification of String types `charstring` will be subtype of `universal charstring`. The TTCN-3 specification can be simplified by defining `charstring` as subtype of `universal charstring`, without introducing compatibility issues. Further we want to use the opportunity to introduce a new name for the rather cumbersome `universal charstring`. `string` is a good candidate. pro: - `string` is a well known term for character strings con: - existing test suites might use this keyword already - "string" is already used by TTCN-3 to describe all string types. # range-based loop Current range-based loop is difficult to implement as a simple counter-loop, because iterating over partially initialized values causes the assignment statement to error when reading and assigning an uninitialized value. If we want to specify the for-range loop as short-hand, forbidding the use of predeclared iteration-variables could be a compromise. A proposal will be provided. # Uninitialized Trailing Elements One particular question for the behaviour of range-based loops uncovered an widespread issue in the standard: How many iterations would a for-loop have when visiting the elements of value `{1,-, -}`. If the loop uses the `lenghtof` function for iteration then the answer is 1. If the loop uses the semantics described in 6.2.3 then the answer should be 3. The later answer, 3, would be common sense. However, many parts in the standard suggest the answer to be 1: - the definition of completely initialized suggests only the first elements count. - all list-types, except record-of, explicitly use `lengthof` to determine the end of the list. - `lengthof` ignores trailing elements. - `lengthof` returns the length of a record-of. - length is used as synonym for number of elements in various places. This pedantic reading creates very subtle issues. A possible way to make TTCN-3 more approachable would be just including uninitialized elements in the length definition. A proposal will be provided. # Import Statement Restricting the import statement to `import from M [-> name] all` seems sufficient. Key observation is that an import does not create new types, but aliases. As a consequence a module cannot be imported multiple times with different attributes; and renaming a module will just be for convenience, so we do not need to type long module names. The suggestion to import individual elements was rejected: [CR8192](https://labs.etsi.org/rep/mts/ttcn3/standard/-/blob/main/docs/mantis/CR8192-Simplify_import_statement.md). The exact behaviour of attaching attributes will be discuss in a different session. # Attribute Handling Attribute handling can be simplified. Attributes such as `display` will be removed. The multiple-encodings feature and all-references (`encode (const all) ""`) will also be removed (or at least moved into a extension) Also the rules for attribute propagation should be reviewed. There seem to be inconsistencies, which we could not discuss without exceeding our timeframe. ```ttcn3 module M { group "G" { type integer A type A B type A C with { encode "C" } type integer D with { encode "D" } type integer D E type integer D F with { encode "F" } } with { encode "G" } type record R { integer f1, A f2, C f3, } with { encode "R" } type R S with { encode "S" } } ``` Loading
meetings/2025-09-08.md 0 → 100644 +179 −0 Original line number Diff line number Diff line # Work Session September 8th to 11nd, 2025 in Tallinn. This work session's main purpose was to review the planned changes for the next major release and assign work items for the migration guide. Generally speaking, the changes for the major release will be as outlined in previous sessions, with some minor details. Some topics were discussed in more detail: ## Types and Values Nomenclatures have to be refined. For example `default` and enumerated types should not be structured types; basic string types could be moved into a list-types section; a definition for reference types could be useful, etc. Since we don't intend to change behaviour, finishing this task not required for the migration guide. But rather a topic for the major release of the core language specification. # Open Type Last session we discussed to merge `anytype` and `any`. As it turned out such merge is not just a matter of definition, but more complicated than we anticipated: The open type behaves as union on TTCN-3 language level, but on TCI/TRI level it behaves more like an empty interface in Go or a void-pointer in C. When we pass `anytype` to an external function a TciValue with type `union` will be transmitted. However, when we pass `any` the runtime variant will be transmitted directly. If a tool implements TCI/TRI that won't make a difference. However, it will be difficult to implement, if the tool generates highly efficient code, internalized codecs, etc. Therefore we probably won't merge those two types. However, `anytype` could help with a different issue: **Unknown embedded payloads** TTCN-3 promotes simple, flat, descriptive code. So, when we encounter `anytype` or `any`, it usually is because someone tried to implement smart software engineering patterns. Being smart in TTCN-3 often leads to code that is difficult to maintain. Our usual advice is to stick with as much simple, static TTCN-3 code as possible. However, we also acknowledge that testing unknown embedded payloads is a common problem, that hasn't necessarily a simple, flat, descriptive solution. We discussed this problem and potential improvements. The way forward is proposing a new extension as trial before any changes will make it in the core language specification. Details will be provided and discussed in a separate proposal. # Template evaluation (lazy/fuzzy) The standard unfortunately allows different readings for template evaluation. This makes removing lazy/fuzzy without breaking compatibility difficult. We discussed possible complications and solutions. The proposal in issue #77 will be presented in the next workshop. # Unification of String types `charstring` will be subtype of `universal charstring`. The TTCN-3 specification can be simplified by defining `charstring` as subtype of `universal charstring`, without introducing compatibility issues. Further we want to use the opportunity to introduce a new name for the rather cumbersome `universal charstring`. `string` is a good candidate. pro: - `string` is a well known term for character strings con: - existing test suites might use this keyword already - "string" is already used by TTCN-3 to describe all string types. # range-based loop Current range-based loop is difficult to implement as a simple counter-loop, because iterating over partially initialized values causes the assignment statement to error when reading and assigning an uninitialized value. If we want to specify the for-range loop as short-hand, forbidding the use of predeclared iteration-variables could be a compromise. A proposal will be provided. # Uninitialized Trailing Elements One particular question for the behaviour of range-based loops uncovered an widespread issue in the standard: How many iterations would a for-loop have when visiting the elements of value `{1,-, -}`. If the loop uses the `lenghtof` function for iteration then the answer is 1. If the loop uses the semantics described in 6.2.3 then the answer should be 3. The later answer, 3, would be common sense. However, many parts in the standard suggest the answer to be 1: - the definition of completely initialized suggests only the first elements count. - all list-types, except record-of, explicitly use `lengthof` to determine the end of the list. - `lengthof` ignores trailing elements. - `lengthof` returns the length of a record-of. - length is used as synonym for number of elements in various places. This pedantic reading creates very subtle issues. A possible way to make TTCN-3 more approachable would be just including uninitialized elements in the length definition. A proposal will be provided. # Import Statement Restricting the import statement to `import from M [-> name] all` seems sufficient. Key observation is that an import does not create new types, but aliases. As a consequence a module cannot be imported multiple times with different attributes; and renaming a module will just be for convenience, so we do not need to type long module names. The suggestion to import individual elements was rejected: [CR8192](https://labs.etsi.org/rep/mts/ttcn3/standard/-/blob/main/docs/mantis/CR8192-Simplify_import_statement.md). The exact behaviour of attaching attributes will be discuss in a different session. # Attribute Handling Attribute handling can be simplified. Attributes such as `display` will be removed. The multiple-encodings feature and all-references (`encode (const all) ""`) will also be removed (or at least moved into a extension) Also the rules for attribute propagation should be reviewed. There seem to be inconsistencies, which we could not discuss without exceeding our timeframe. ```ttcn3 module M { group "G" { type integer A type A B type A C with { encode "C" } type integer D with { encode "D" } type integer D E type integer D F with { encode "F" } } with { encode "G" } type record R { integer f1, A f2, C f3, } with { encode "R" } type R S with { encode "S" } } ```
