Loading meetings/2024-11-19.md→meetings/2024-11-19_Ericsson_Budapest.md +0 −0 File moved. View file meetings/2025-03-11.md→meetings/2025-03-11_Ericsson_Budapest.md +0 −0 File moved. View file meetings/2025-09-08.md→meetings/2025-09-08_Elvior_Tallinn.md +0 −0 File moved. View file meetings/2025-10-25_OpenSession.md 0 → 100644 +156 −0 Original line number Diff line number Diff line # Open Session on TTCN-3 Major Release, 21th October 2025 The session started with a recap covering motivation for a major release, migration from Mantis to GitLab issue tracker and planned document structure. The major part of this session was about discussing planned changes with tool vendors and TTCN-3 developers. ## Templates We discussed changed covered in proposal #77 and received mixed feedback. Issues with TTCN-3 templates are challenging to resolve, because different tools evaluate templates differently and because different user-groups have different needs and expectations. We all agreed on removing partial template evaluation from the standard. The biggest concern was the distinction between dynamic and static templates. We discussed three different approaches: **Make all templates dynamic** From a testers perspective it would make the most sense to evaluate templates when instantiated: - it plays well with most use-cases - it aligns nicely with TTCN-3 design goals (descriptive and non programmatic tests) - it aligns nicely with already existing language features (e.g. modified-templates, parameterized templates) - its very intuitive A typical use of dynamic templates would be: ```ttcn3 template float a := now; template float b := a; template float c := b; wait(now+10.0) if (now-valueof(c) >= 10.0) { // c is instantiated and evaluated here setverdict(fail); } ``` While this approach is comfortable for most cases, it has some drawbacks: It is not possible to pass a template between functions without automatically instantiating it. This makes it difficult to encapsulate and reuse test code. Also, dynamic templates create unexpected edge-cases. For example referencing component variables or local data. **Make all templates static** The other extreme would be removing dynamically evaluated templates altogether. Parameterized template syntax would be a shorthand notation for functions returning templates. This is the approach of proposal #77, essentially. The idea behind is that rules for static templates and user-defined functions are sufficient for modelling behaviour in any desired way, without complicating any language mechanics. In practice testers would have to rewrite most templates to be parameterized templates, because most templates seem to have a dynamic part. **Middle ground** The middle ground would be specifying the way a template is evaluated, some kind of modifier. For example `@lazy`, `@dynamic` or `const`. **Conclusion** We stopped the discussion at one point to continue with the other language features. Core takeaways were: - Proposal #77 is elegant, but not very practical - Dynamic templates only is practical, but has poor support for programming in TTCN-3. - Current middle ground solutions have poor acceptance. - What ever to solution might be, all tool-vendors must provide identical behaviour! ## Interleave We proposed to restrict the use of interleave to basic use-cases, because it is easy to shoot yourself in the foot. This suggestion was somewhat controversial, since interleave is used and decisions how to use it should be project-specific and not enforced by the standard committee. ## Import There were no objections on removing fine grained import control from the standard. Attaching attributes to import statements is required for ASN.1 and XML language mappings. We cannot remove it therefore. Extending rules for attribute propagation to prevent conflicts will probably be a good way forward. ## Procedure Based Communication No objection to move procedure based communication into an extension. ## Module parameters Module parameters be specified differently, but essentially stay the same. ## Types and Values Types stay the same essentially, but will be restructured. ## Strings No objections for planned string simplifications. ## Sets No objections. ## Setof No objections. ### lengthof/sizeof Current behaviour of `lengthof` is required to find the last initialized element; or also for appending elements. So probably we will keep `lengthof` behaviour and reinstate `sizeof`. ## anytype and open type No objections. ## Automatic type No objections to planned changes, since automatic type inheritance seems not to be used by this session's attendees. Loading
meetings/2025-10-25_OpenSession.md 0 → 100644 +156 −0 Original line number Diff line number Diff line # Open Session on TTCN-3 Major Release, 21th October 2025 The session started with a recap covering motivation for a major release, migration from Mantis to GitLab issue tracker and planned document structure. The major part of this session was about discussing planned changes with tool vendors and TTCN-3 developers. ## Templates We discussed changed covered in proposal #77 and received mixed feedback. Issues with TTCN-3 templates are challenging to resolve, because different tools evaluate templates differently and because different user-groups have different needs and expectations. We all agreed on removing partial template evaluation from the standard. The biggest concern was the distinction between dynamic and static templates. We discussed three different approaches: **Make all templates dynamic** From a testers perspective it would make the most sense to evaluate templates when instantiated: - it plays well with most use-cases - it aligns nicely with TTCN-3 design goals (descriptive and non programmatic tests) - it aligns nicely with already existing language features (e.g. modified-templates, parameterized templates) - its very intuitive A typical use of dynamic templates would be: ```ttcn3 template float a := now; template float b := a; template float c := b; wait(now+10.0) if (now-valueof(c) >= 10.0) { // c is instantiated and evaluated here setverdict(fail); } ``` While this approach is comfortable for most cases, it has some drawbacks: It is not possible to pass a template between functions without automatically instantiating it. This makes it difficult to encapsulate and reuse test code. Also, dynamic templates create unexpected edge-cases. For example referencing component variables or local data. **Make all templates static** The other extreme would be removing dynamically evaluated templates altogether. Parameterized template syntax would be a shorthand notation for functions returning templates. This is the approach of proposal #77, essentially. The idea behind is that rules for static templates and user-defined functions are sufficient for modelling behaviour in any desired way, without complicating any language mechanics. In practice testers would have to rewrite most templates to be parameterized templates, because most templates seem to have a dynamic part. **Middle ground** The middle ground would be specifying the way a template is evaluated, some kind of modifier. For example `@lazy`, `@dynamic` or `const`. **Conclusion** We stopped the discussion at one point to continue with the other language features. Core takeaways were: - Proposal #77 is elegant, but not very practical - Dynamic templates only is practical, but has poor support for programming in TTCN-3. - Current middle ground solutions have poor acceptance. - What ever to solution might be, all tool-vendors must provide identical behaviour! ## Interleave We proposed to restrict the use of interleave to basic use-cases, because it is easy to shoot yourself in the foot. This suggestion was somewhat controversial, since interleave is used and decisions how to use it should be project-specific and not enforced by the standard committee. ## Import There were no objections on removing fine grained import control from the standard. Attaching attributes to import statements is required for ASN.1 and XML language mappings. We cannot remove it therefore. Extending rules for attribute propagation to prevent conflicts will probably be a good way forward. ## Procedure Based Communication No objection to move procedure based communication into an extension. ## Module parameters Module parameters be specified differently, but essentially stay the same. ## Types and Values Types stay the same essentially, but will be restructured. ## Strings No objections for planned string simplifications. ## Sets No objections. ## Setof No objections. ### lengthof/sizeof Current behaviour of `lengthof` is required to find the last initialized element; or also for appending elements. So probably we will keep `lengthof` behaviour and reinstate `sizeof`. ## anytype and open type No objections. ## Automatic type No objections to planned changes, since automatic type inheritance seems not to be used by this session's attendees.
