From 32b7907ae816c68d3e2fc01f7ea5a8e2af35ec24 Mon Sep 17 00:00:00 2001
From: Matthias Simon <matthias.simon@nokia.com>
Date: Wed, 11 Dec 2024 11:07:06 +0100
Subject: [PATCH] Fix heading
---
meetings/2024-11-19.md | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/meetings/2024-11-19.md b/meetings/2024-11-19.md
index fc1377c..b74b17d 100644
--- a/meetings/2024-11-19.md
+++ b/meetings/2024-11-19.md
@@ -41,17 +41,17 @@ A combination of various strategies is probable:
* Break compatibility and rely on existing language tags.
* Provide tool for automatic conversion.
-# Coding style
+## Coding style
We should extend the ruleset for coding style of TTCN-3 examples (and conformance tests).
-# Templates
+### 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
+#### Template Evaluation
Various evaluation strategies for templates are required. However, the current
approach of lazy, fuzzy, var, const or parameterized templates is neither
@@ -96,14 +96,14 @@ template Point t := function (integer p) return Point {
Details need to be worked out in future discussions.
-## Special Template Symbols
+#### 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
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
@@ -111,17 +111,17 @@ annotations could be promoted to a type-conversion operator and template
literals are already part of the language.
-## Modified Templates
+#### Modified Templates
Modified template and modified inline template syntax might be unified and simplified.
-## List Templates
+#### List Templates
See [List Types](#list-types).
-## Differentiation of Values and template values
+#### Differentiation of Values and template values
Differencing between value and template value complicates the language and its specification.
@@ -141,7 +141,7 @@ This could also improve on compiler-pleasing through `valueof` and on
operations such as `omit`, `present`, ...
-# Type System
+### Type System
We discussed several aspects of the type system to identify opportunities for
simplification:
@@ -164,7 +164,7 @@ simplification:
variables, ...).
-## List Types
+#### List Types
Semantics of list types need harmonization and simplification.
@@ -223,7 +223,7 @@ c := c & {3,4}; // lengthof(c) == ?
```
-## Language Features
+### Language Features
Procedure based communication might be moved to an extension document.
@@ -253,7 +253,7 @@ Attributes might be simplified:
* multiple encodings is complicated and could be removed
-## Module organization
+### Module organization
`import` will be simplified if possible.
This would make `group` superfluous. However groups are used to structure
@@ -265,14 +265,14 @@ seldom. It's used primarily by framework developers. Possible improvements need
further discussion.
-## TCI/TRI/xTRI
+### 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
+### Extensions
Language features that were neither removed nor moved into the core, will
probably be merged into a common extensions document.
--
GitLab