Commit 32b7907a authored by Matthias Simon's avatar Matthias Simon
Browse files

Fix heading

parent cf10218e

meetings/2024-11-19.md

+14 −14
Original line number Diff line number Diff line
@@ -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.