Update meeting notes

# Meeting notes: Göttingen 24.03.2026 to 27.03.2026

## Discussion 24.03.2026

### Table of Contents (order)

- General order should be kept, some language elements may be put to some other

  place.

- Nothing to do now

### Section structure (introductory description, syntactical structure, semantic description, restriction, example) should be kept

- Skipping unnecessary parts is allowed (e.g., no restrictions)

### Rules for wording in section structure

- BNF terms in syntactical structure should be reused in the text.

- Syntactical structure should be in sync with BNF.

- First paragraph in semantic description should define the terms (e.g.,

  parameters in syntactical structure).

- Preference technical terms over enumerations (e.g., lists of types)

- Highlighting of language elements need to clarified.

  - Bold: Reference to language element (e.g., array) or a general term (e.g.,

    see chapter 3) (producing a hyperlink, during editing to be highlighted in

    red)

  - Bold/Courier: Reference to keyword

  - Italic: local technical terms (including local syntax descriptions)

  - Courier (without Bold): Code (e.g., variable names, predefined functions)

- NOTES cannot include binding rules.

- Restrictions:

  - Check for general restrictions, e.g., handling of uninitialized variables

  - Restrictions may be moved

  - Check/reduce interference of restrictions

  - Restrictions cannot enforce different coding styles

  - Reasons for not obvious restrictions should be explained

- Examples:

  - Examples in one chapter should be self-contained

  - Coverage of examples should be sufficient

  - Always explain examples

  - Simple naming conventions should be followed

  - Parenthesis: Opening parenthesis not on a separate line, closing

    parenthesis on the same indentation of the opening statement.

  - Examples should be self-descriptive (e.g., no single character identifier

    for a type name)

  - Examples should be numbered (with exception of one-line examples)

## Discussion 25.03.26

### BNF discussion

- Working assumption: one BNF for Core and extensions

- Check implementation of static semantics in BNF rules

### Keywords/reserved words

- Keywords (for, while, etc.), Reserved words (predefined identifiers,

  predefined functions, useful types)

- Look for clashes with ASN.1, XML, JSON

- Testcast rule: reserved words cannot be used in definitions, can be used for

  fields and be imported.

- One list for extensions and Core

- Keywords and reserved words should not be reused by users.

## Discussion 26.03.2026

- Term: Test execution to be defined

## Discussion 27.03.2026

- Gitlab will not be in sync due to working procedure for standard writing

  - Gusztav will take care of open CRs submitted by him

  - CRs will be moved to DONE state

# Meeting notes: Berlin 12.10.2026 to 15.10.2026

## Discussion: range-based loops

Iterating over partially-initialized values seems to be challenging for tool

vendors to implement, in particular the assignment of `UNINITIALIZED` to the

iterator variable.

We therefore agreed to require the range-expression en to be

completely-qualified, if we iterator variable is defined outside the loop.

We also agreed to keep the current style of the specification. We don't plan to

specify the range-based loop as short-hand for the counter-loop, anymore.

## Discussion: log-statement

The `log` statement won't be made a function, because the special parameter

handling rules of the statement had to be aligned with those of functions and

we won't be able to implement this change in this TTF.

## Discussion: implicit omit for modified templates

```ttcn3

    type record R {

        integer i,

        integer j optional

    }

    var template R t1 :=  { i := 1, j := 2 }

    var template R modifies t1 t2 := { i := 2 } with { optional "implicit omit" }

```

Common understanding was: Implicit omit will change the modification from `{i:=2}` to `{i:=2,j:=omit}`

The content of t2 will be `{i:=2, j:=omit}`.

## Discussion: length matching attribute 

```ttcn3

    var template bitstring t1 := ? length(1..5)

    var template bitstring t2:= t1 length(3..7)

    log(t2) // What length-constraint will t2 have?

```

Following approaches have been discussed:

- **Overwrite length attribute**: Every template has a value and (at most one)

  length-constraint. But this statement is a implementation detail and not the

  behaviour one would expect.

- **Intersection**: Logically sound: `t1` restricts string to length(1..5),

  when we restrict this set further, the resulting set is: `? length(3..5)`.

  A very similar behaviour is already specified by subtyping, too.

## Discussion: AnyValueOrNone length matching omit

```ttcn3

    type record R { record of integer f1 optional }

    var template R t := { f1 := * length(1..4) }

    p.send({f1 := omit})

    p.receive(t); // does t match?

```

We assume that (in context of optional fields) `* length(1..4)` is semantically

equivalent to `? length(1..4) ifpresen`. Therefore template `t` should match.

## Discussion: decmatch omit

A note in table 12 in clause 15 mentions a `decmatch` can match omitted fields.

```ttcn3

    type record R { bitstring f1 optional }

    p.send(R:{f1 := omit});

    p.receive({f1 := decmatch integer:*}) // does it match?

```

Resolution: Calling `decmatch` without actual data shall raise an error. In

this particular example a user shall wrap the `decmatch` in a ifpresent clause:

```ttcn3

    p.receive({f1 := decmatch integer:* }) // decoding error

    p.receive({f1 := decmatch integer:* ifpresent}) // okay

```

## Discussion: modifying partially initialized templates

Question: Are the assignment-rules for modified templates the same as for 

the regular assignments?

Resolution: No.

Normal assignment overwrites the value on the left-hand side (first example).

Modifies expression does not (second example).

```ttcn3 example="regular assignment -- templates"

    var template R r := { f1 := 1,  f2 := 2 }

    var template R s := { f1 := 11 }

    // assigned list notation assignment does not modify previous values

    r := { f1 := 11 } // result: { r1 := 11, f2 := 2 }

    // If a partially initialized value is assigned to a completely

    // initialized variable, fields uninitialized at the right-hand side

    // of the assignment shall also become uninitialized at the left-hand

    // side. [19.1]

    r := s;           // result: { f1 := 11, f2 := - }

```

```ttcn3 example="modified inline template"

    template R r := { f1 := 1,  f2 := 2 }

    template R s := { f1 := 11 }

    var template t2 := modifies r := { f1 := 11 } // result: { r1 := 11, f2 := 2 }

    // In case that the BaseTemplateBody on the right hand side of the modified

    // template contains references to variables, these are evaluated before the

    // modification and any uninitialized fields or elements in these variables

    // are treated as unspecified, i.e. as if specified with the not used symbol

    // "-" for the following modification algorithm.

    // [15.5]

    var template t2 := modifies r := s; // result: { r1 := 11, f2 := 2 }

```

## Discussion: Concatenation of templates

Problem:

- combined-matching-mechanisms (e.g. `'1*' length(5)`) are not included in the

  concatenation rules.

- concatenation rules for binary string templates with variable length are

  missing (e.v. `'1*' length(1..5)`).

- some results of concatenation are not representable in TTCN-3

  (e.g. `'1*1*'B length(6) & '1*1*'B length(6)`).

```

      // specified

      a := '1'B & * length(5) & '1'B & ? length(5)

      log(a) // Output: '1?????1?????'B

      // not specified

      a := '1*'B length(6) & '1*'B length(6)

      log(a) // Output? '1?????1?????'B or '1*1*' length(12)

      // not specified

      a := '1*1*'B length(6) & '1*1*'B length(6)

      log(a) // Output? '1*1*1*1*'B or '1*1*1*1*'B length(12)

      // specified, error: because of variable length of AnyValue

      a := '1'B & ? length(1..3);

      // unspecified, no rule for combined-matching with variable length

      a := '1'B & '1*' length(1..3)

```

Discussion:

- Can we specify a mathematically correct concat operation?

  - Not possible without incompatible changes and considerate effort (i.e. no

    business value).

- Leaving the rules as they are is not an option, since we want to have

  language semantics implemented consistently across tools.

- Raising errors eagerly is too restrictive for existing tests.

- Dropping length-restrictions when needed.

Resolution: Drop length-restrictions.

We keep compatibility at a pragmatic level for the price of loosing some

precision in matching. A concrete proposal needs to be presented.

## Discussion: Language Simplifications

TTCN-3 core language does not have a common concept for things that can store a

value (_value construct_, constants, variables, ...) and no concept for

template-types either.

Unfortunately we missed the time-frame to discuss these changes; since this

kind of simplification requires changes across many chapters in the standard

(e.g. Types and Values, Expressions, Templates, ...) and we have not come to a

evaluation for any compatibility issues.

Therefore, we decided to keep the changes to the necessary minimum:

> if necessary changes cannot be done in the available time,

> let's keep the original structure and do some changes.

### Template Types

The core language specification infers template types only implicitly. So,

every context in which a template occurs is handled independently (i.e.

variables, module parameters, formal parameters, return values, expressions,

automatic type inference, type compatibility, ...)

This would be easy on BNF-level:

```ebnf

VarDecl := "var" [TypeExpr] Name [":=" Expr].

TypeExpr := NestedTypeOrType | "template" NestedTypeOrType

```

Above would be incompatible to current specification:

```

var a := 1; // "normal" variable with type `integer`

var template a := 1; // template variable with type `integer`

// Unified form is unspecified

var a := integer:1; // "normal" variable with type `template integer`.

```

Introducing the concept of a template type is not possible within this

time-frame. Secondly, it was missed to be mentioned in the migration guide.

### Value Construct

The definition of variables, constant, module parameters, locals, component

variables, parameters, values and templates would greatly benefit from a common

concept.

They share rules like type compatibility, scoping, assignment, life-time, ...

Biggest challenge was agreeing on how constants are to be specified.

There have been a few proposals, but we could not reach a common understanding

for given time-frame.

We therefore agreed to focus on finishing the milestone and just simplify the

chapters where needed.

# Clarification: "Compile-time" for Constants

The term "compile-time" is not defined:

> Constants used within type definitions have to have values known at compile-time

> [10. Declaring Constants]

> **Static parameterization**:

> ...known at compile time or [...] by the start of the test suite execution.

> NOTE: the test system is aware of its value before execution time.

> NOTE: All types are known at compile time, i.e. are statically bound.

> [3.1 Terms and Definition]

Later restrictions in clause 10 has a much better wording (some version of

"constant expression"). However, restriction only covers constant expressions

with constants and misses variables, module parameters and parameters; it seems

to imply global type definitions, but local types are unspecified:

```ttcn3

function f(in integer n) {

    const integer len := bit2int(int2bit(n))

    var integer a[len+3]; // error: `len` is not a constant-expressions since it depends on a parameter.

    var integer b[n+3];  // unclear, if allowed.

}

```

# Discussion: null for address

> Using the dot notation [...] for referencing a field [...] of an address

> value, which actual value is null shall cause an error

> [11.1.h]

This restriction is too restrictive and out-of-place: As soon a variable is set

to `null` it would not be possible to change individual fields anymore. This error

should only be raised in a right-hand side context.

```ttcn3

    type record R {

        integer f1

    }

    type R address;

    control {

        var address addr := null;

        log(addr.f1) // error

        addr.f1 := 2; // error?

    }

```

Secondly, expansion rules in clause 7 are a better place to cover these rules

since variables are not the only place where `address` can be a type (e.g.

fields, elements, ...):

```ttcn3

type record R {

    integer f1

}

type R address;

control {

    var address addr[100];

    addr[10] := null;

    addr[10].f1 := 2; 

}

```