# 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.

# Coding style

We should extend the ruleset for coding style of TTCN-3 examples (and conformance tests).

# 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.

//since now there is no type-conversion operator this is not true -- AG


## 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
//NO: shall cause runtime error - AG
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.