From a38babf415deeecebc11160727780fa7d9460adf Mon Sep 17 00:00:00 2001
From: Matthias Simon <matthias.simon@nokia.com>
Date: Wed, 11 Dec 2024 09:58:36 +0100
Subject: [PATCH] Add meeting notes for November 2024
---
meetings/2024-11-19.md | 298 +++++++++++++++++++++++++++++++++++++++++
meetings/README.md | 23 ++++
2 files changed, 321 insertions(+)
create mode 100644 meetings/2024-11-19.md
create mode 100644 meetings/README.md
diff --git a/meetings/2024-11-19.md b/meetings/2024-11-19.md
new file mode 100644
index 0000000..b16d709
--- /dev/null
+++ b/meetings/2024-11-19.md
@@ -0,0 +1,298 @@
+# Work Sessions November 18th to 22nd, 2024
+
+## Agenda
+
+* Review maintenance CRs and migrate them to GitLab.
+* Review questionnaires and discuss potential work items for the new major
+ release.
+
+## Discussions
+
+### Structure of core language and extension documents
+
+**Core Language**
+
+We discussed reducing the size of the TTCN-3 core language by:
+
+* moving predefined functions, useful types and such into some kind of standard
+ library document.
+* Removing or deprecating features that could be substituted by other features
+ (e.g. arrays).
+* Moving features that are not used by the majority of users, but are
+ complementing the language into extension documents (e.g. procedure based
+ communication).
+* Introducing new language concepts, that simplify the language (e.g. advanced
+ parameterization, closures, ...).
+
+
+**Extensions**
+
+Further we discussed how to reorganize language extensions into smaller
+self-contained features and whether to aggregate them into a single language
+extension document.
+
+**Backward Compatibility**
+
+The question how to handle backward compatibility was not discussed in detail.
+A combination of various strategies is probable:
+* Redefine features as short-hand notation.
+* Make features optional by moving them to extensions.
+* Deprecate features.
+* Break compatibility and rely on existing language tags.
+* Provide tool for automatic conversion.
+
+
+# Templates
+
+Refining templates pose a big challenge for backward compatibility, but also
+many opportunities for simplification. We discussed several ideas without going
+too much into detail during this session:
+
+## Template Evaluation
+
+Various evaluation strategies for templates are required. However, the current
+approach of lazy, fuzzy, var, const or parameterized templates is neither
+intuitive nor well understood. Examples:
+
+```ttcn3
+function f(inout integer i) return integer {
+ var integer j := i;
+ i++;
+ return j;
+}
+
+control {
+ var integer i := 0;
+ var integer a := f(i);
+ var integer b := f(i);
+
+ log(a, b, i); // 0, 1, 2
+
+ template Point t(integer p) := {
+ x := a, // eager evaluation (during definition)
+ y := f(i), // eager evaluation (during definition)
+ z := p + f(i) // deferred evaluation (during invocation)
+ };
+
+ log(t(b), i); // {x := 0, y := 2, z := 4}, 4
+}
+```
+
+Different evaluation strategies could be modeled with help of new language
+features. For example lazy evaluation of previous template could be achieved by
+using closures:
+
+```ttcn3
+template Point t := function (integer p) return Point {
+ x := a,
+ y := f(i),
+ z := p + f(i),
+};
+```
+
+Details need to be worked out in future discussions.
+
+
+## Special Template Symbols
+
+`all from`, `permutation`, `complement`, `subset`, `superset`, ..., do not need
+to be part of the core language. They could be implemented as library
+functions, as language extensions or even by user-defined dynamic matching.
+
+
+## Inline Templates
+
+Inline templates consist of an optional type annotation part and a template literal.
+A dedicated notion for inline templates is not necessary, as they type
+annotations could be promoted to a type-conversion operator and template
+literals are already part of the language.
+
+
+## Modified Templates
+
+Modified template and modified inline template syntax might be unified and simplified.
+
+
+## List Templates
+
+See [List Types](#list-types).
+
+
+## Differentiation of Values and template values
+
+Differencing between value and template value complicates the language and its specification.
+
+One simplification is to extend the type system to handle templates as proper type.
+Example:
+
+```ttcn3
+var template integer i := 1;
+```
+
+`i` is a variable of type `template integer`. This type could be a variant-type of `integer` and matching symbols.
+
+Another simplification is to remove the differentiation between values and
+templates all together. For example: `var integer i := 1` would a shorthand for
+`var template(value) integer i := 1`.
+This could also improve on compiler-pleasing through `valueof` and on
+operations such as `omit`, `present`, ...
+
+
+# Type System
+
+We discussed several aspects of the type system to identify opportunities for
+simplification:
+
+* Substitute `anytype` with `any`. Type switch from OOP extension would be a
+ good addition.
+* Arrays
+ * remove custom indexing.
+ * should become short-hand notation.
+* `set` and `set of` should be reviewed (compatibility with records,
+ replacement possible?)
+* Should automatic typing be extended to unions and generics or should it
+ rather be moved to an extension?
+* Map type:
+ * Could be harmonized with `HashMap` from OOP extension.
+ * One could find overlap of `unmap` operations confusing.
+ * Some corner cases need clarification (e.g. `h[*] := {}`).
+* Sections describing type system could be simplified by introducing better
+ type terminolgy (subtyping, type-alias, equality, assignment, component
+ variables, ...).
+
+
+## List Types
+
+Semantics of list types need harmonization and simplification.
+
+**`lengthof`**
+
+```ttcn3
+lengthof('12*'H) // 3
+lengthof({1,2,?}) // 3
+lengthof({1,2,*}) // causes runtime error
+
+// Templates cannot be iterated or modified safely
+var template record of integer c := {1,2,*};
+c[lengthof(c)] := 5; // lengthof causes error
+```
+
+
+**uninitialized elements**
+
+```ttcn3
+control {
+ var record of integer a := {1,2,_}, b := {1,2,_,_};
+ log(equal(a, b)); // true
+ log(a==b); // implementation dependent (false)
+}
+
+function equal(record of integer a, record of integer b) return boolean {
+ if (lengthof(a) != lengthof(b)) {
+ return false;
+ }
+ for i := 0 to lengthof(a) {
+ if (a[i] != b[i]) {
+ return false;
+ }
+ }
+ return true
+}
+```
+
+```ttcn3
+var record of integer a := {1,9};
+a := {_,2,_} // how many elements will `a` have; 2 or 3?
+ // Is d equal to {1,2} or to {1,2,_}?
+```
+
+```ttcn3
+var record of integer a := {1,2};
+a[4] := 5;
+log(a); // {1,2,_,_,5}
+
+var charstring b := '12';
+b[4] := 5; // causes runtime error
+
+var record of integer c := {1,2,_}; // lengthof(c) == 3
+c := c & {3,4}; // lengthof(c) == ?
+
+```
+
+
+## Language Features
+
+Procedure based communication might be moved to an extension document.
+
+Some port control operations might be moved to an extension document or even be
+removed. Further discussion is needed.
+
+`checkstate` is used to wait for a port to be ready. Further discussion is
+needed, whether `checkstate` could be improved or even removed.
+
+The `receive` part of `check` operation could be removed probably.
+
+The `trigger` could be substituted by `check`.
+
+Decoded field references, `decmatch`, `@decode` could be simplified. It needs to be checked whether `=>` can be removed.
+
+We discussed whether `goto` could be removed or substituted by named loops.
+
+Component's `call` operation might be moved into an extension document.
+
+External actions (`action`) do not need to be part of the core language.
+
+Modifiers (pe.g. `@deterministic`, `@nocase`, `@nodefault`, ...) or often overlooked. Further discussion is needed whether there's opportunity to generalize them.
+
+Attributes might be simplified:
+ * remove `display`
+ * move reading and writing attributes to extension
+ * multiple encodings is complicated and could be removed
+
+
+## Module organization
+
+`import` will be simplified if possible.
+This would make `group` superfluous. However groups are used to structure
+modules and groups are also used by some language mappings.
+Simplifying import would further require to discuss importing of imports.
+
+Visibility features (`friend`, `private`, `protected`) are used by testers,
+seldom. It's used primarily by framework developers. Possible improvements need
+further discussion.
+
+
+## TCI/TRI/xTRI
+
+Might be merged into a single document. Language mappings for C and Java will
+become non-normative, the other language mappings will be removed.
+
+The future for mappings of XML to TLI needs further discussion.
+
+## Extensions
+
+Language features that were neither removed nor moved into the core, will
+probably be merged into a common extensions document.
+
+* Performance and real-time extension:
+ * `wait` --> core
+ * `timestamp` --> core
+ * remaining features --> extension
+* Configuration and Deployment features mostly stay as they are.
+* Advanced parameterisation:
+ * Type parameterisation: Could use some refinement (automatic type interence,
+ parametric type inference, generic types in ports, ...).
+ * Value parameterisation of types: Could be removed.
+* Behaviour types:
+ * Behaviour types (and closures) will probably move to core to help
+ simplification.
+ * Deferred behaviour will be removed.
+* Continuous signals will probably go to historic state
+* Advanced matching:
+ * Dynamic matching will probably move to core.
+ * Other features need further discussion.
+* Object oriented features:
+ * Exception-feature will probably move to core
+ * Some type operations (`=>`, `select class`) probably, too
+ * If and in what form user defined object will be merged into core is not
+ clear yet.
diff --git a/meetings/README.md b/meetings/README.md
new file mode 100644
index 0000000..897bce3
--- /dev/null
+++ b/meetings/README.md
@@ -0,0 +1,23 @@
+# TTCN-3 Meeting Notes
+
+This folder contains language related meeting notes of the TTCN-3 [task
+force](https://portal.etsi.org/xtfs/) sessions.
+
+## Purpose of the meeting notes
+
+Purpose of these notes is:
+* record decisions so they can be acted upon.
+* communicating design thinking and discussions to the wider community so we can get feedback.
+* recording rationale for decisions so we can remember why we did things.
+
+## Style of design notes
+
+The notes cover not just decisions but also discussions, options and rationale,
+so that others can follow along and provide input, and so that we don't forget
+them later.
+
+_The notes are not meeting minutes_. They do not record who said what, they aim
+to capture the shared thinking of the group.
+If there's disagreement, they will report that, but they won't focus on who
+wants what.
+
--
GitLab