Continue section 5 and 16

## General

TTCN-3:

- built from modules

- libraries

- suites

- for testing (predefined elements and types)

- value semantics

- abstract data types, TCI/TRI

Module:

- tests

- test components

- communication interfaces (ports)

- messages and other types

- constants

- templates

- behaviour (programmatic and static (== interleave/alt))

- custom entry points

Attribute:

- meta data

TTCN-3 Modules are used to structure a test suite into composable parts. A

module may reuse other modules by importing them.

A module defines test components, communication ports, user-defined types,

constants, test data templates, behaviour, etc.

The type-system of TTCN-3 provides a rich set of predefined and user-defined

types (i.e. maps, subtypes, etc.); including types specialized for testing

(i.e. components, ports, etc.)

A special kind of data structure, called a _template_, provides a pattern

matching mechanism for test-data.

User-defined behaviour (i.e. functions, test cases, etc.) is specified by the use of program

statements, such as `if-else` and `do-while`. Behaviour may also declare local

variables and constants.

The concept of global variables is not supported in TTCN-3.

A module control function calls test-cases and controls their execution.

Expressions specify the computation of values for variables, constants, parameters, etc.

Finally, meta-information, such as encoding information and user-defined

attributes may be associated to most TTCN-3 language elements.

> NOTE: The terms "definition" and "declaration" are used interchangeable

> throughout the present document.

## Scope rules

### General

- a scope unit is a region that associates names with a TTCN-3 language element.

- names are identifiers

- every name in TTCN-3 belongs to exactly one scope unit

- scope units can be nested

- scope units form a hierarchical with the root-scope as the root

A scope unit is a region that associates a name with a TTCN-3 language element.

Scope units may be nested and form a hierarchy with the _root scope_ as the root.

> NOTE: A language object has a scope, if it can own declarations, formal

> parameters, type parameters or fields.

The _root scope_ owns the predefined names, such as `integer` or `log`, and the module names.

A _module scope_ owns the names of its definitions and imported names.

- a name is visible, if there is a path from the name reference to the name definition

> NOTE: Scopes are conceptional: This standard does not dictate a specific implementation,

> its left to the developer how to implement scope rules.

> NOTE: Scopes are conceptional: This standard does not dictate a specific implementation;

> it is left to the vendor how to implement scope rules.

> NOTE: A TTCN-3 language element may have a name and a scope unit. For

> example, a function has a name at least one scope unit for parameters and

> locals.

> NOTE: If a language object owns declarations, formal

> parameters, type parameters or fields, then it has a scope, too.

### Uniqueness of identifiers

A names shall be a valid TTCN-3 identifier.

A name shall be owned by exactly one scope unit.

- a name must be unique in its scope

- a name reference must not be ambigious.

 - not shadowing

structure test behaviour, define default behaviour and to structure computation

in a module.

Further, the extension for [object oriented features] permits declaring [methods].

Platform specific behaviour may be provided by the means of [external

functions].

Parameterization may be used to specify dynamic behaviour -- or [dynamic

templates](15.2).

TTCN-3 distinguishes between different kinds of parameterization:

- _value parameterization_ as specified in the following chapters.

- _type parameterization_ as specified in [advanced parameterization

extension].

TTCN-3 distinguishes between _value parameterization_ as specified in the

following chapters and _type parameterization_ as specified in [advanced

parameterization extension].

> NOTE: technically there is also indirect parameterization through the use of

> references. But it is strongly recommended to favor the more explicit _value

> parameterization_ over _indirect parameterization through references_ when

> possible; because the later can introduce subtle inconsistencies between

> individual tools and use-cases.

> individual tools and edge-cases.

> NOTE: The term _parameterization_ will be used interchangeably with _value

> parameterization_ in this document, unless stated differently.

> NOTE: Parameters are very similar to variables in the sense they provide a

> memory location to store the value of a specific type. Parameters also have a

> initial value assignment (default parameter) and follow assignment rules as

> variables.

TTCN-3 language elements that support value parameterization are: [functions],

[external functions], [testcases], [altsteps] and [parameterized templates].

A _formal parameter_ shall not reference any formal parameters defined in the

same _formal parameter list_.

A _formal parameter_ may have an _initial value assignment_. Such a parameter

is called _default parameter_ and is described in [default parameters].

> NOTE: Referencing type-parameters, visible components (e.g. `mtc`, `self`, ...)

> or even variables of the runs-on component is permitted.

A _formal parameter_ is either an _in-parameter_, indicated by the `in`

keyword, _inout-parameter_, indicated by the `inout` keyword, or

A _formal parameter_ without any of these keywords is considered an

_in-parameter_.

An _in-parameter_ is _passed by value_. 

A _out-parameter_ is also _passed by value_.

Each invocation of the parameterized TTCN-3 language object has its own copy.

A _formal parameter_ of kind `in` may have an _initial value assignment_.

Such parameter is called _default parameter_ and is described in [default parameters].

A _formal parameter_ shall behave like a variable in respect to assignment,

type compatibility, evaluation rules and memory (i.e. each parameter has its

distinct copy of a value, see following note)

> NOTE: The term _value_ means all representable data in TTCN-3 and includes

> references, too. The referenced object may be unique, but a copy reference

> itself is stored in the parameter's memory location.

Access to parameters passed by reference (i.e. `inout`) shall dereference implicitly.

A _formal parameter_ gets assigned its value when the parameterized TTCN-3

language element is passed an [actual parameter]; when a function is invoked,

when a template is instantiated, etc.

**Restrictions**

1. Formal parameters for templates shall be `in`-parameters only.

2. Formal parameters for altsteps shall be `in`-parameters only.

3. String type parameters shall not be `inout` parameters.

A _inout-parameter_ is _passed by reference_.

**Examples**

}

```

```ttcn3 example="cannot reference a parameter from the same formal parameter list"

```ttcn3 example="shall not reference other parameters in the same scope"

external function f(integer n, integer a[n]); // error

external function g(integer n, integer a := n*2); // error

external function h(integer n, record length(n) of integer a); // error

```

```ttcn3 example="each invocation has its own copy"

// each invocation of function `fib` has its own copy of parameter n.

function fib(in integer n) return integer {

    if (n < 2) {

        return 1

    }

    return fib(n-2) + fib(n-1)

}

control {

    var integer v := fib(2); // expect: v == 2

}

```ttcn3 example="only in-parameters may have a default value"

external function f(in integer p := 1); // okay

external function g(inout integer p := 1); // error

external function h(out integer p := 1); // error

```

```ttcn3 example="pass by value: changes not visible"

function f(in integer i) {

}

```ttcn3 example="in only for templates"

template integer t1(inout integer p) := p // error

template integer t2(out integer p) := p // error

```

```ttcn3 example="pass by reference"

function f(inout integer i) {

    i := i + 1;

}

control {

    var integer i := 0;

    f(i)

    log(i) // expected output: 1

}

```ttcn3 example="in only for altsteps"

altstep as1(inout integer p) {} // error

altstep as2(inout integer p) {} // error

```

```ttcn3 example="pass reference by reference"

// TODO: write test to change the passed inout variable to

type component PTC {}

testcase tc() {

    var PTC a := PTC.create("a");

    var PTC b := PTC.create("b");

    var PTC c;

```ttcn3 example="automatic dereferencing"

function inc(inout integer p) { p := p + 1 }

control {

    var integer i := 1;

    inc(i); // expect: i == 2

}

```

### Actual parameters

### Actual parameters

- empty parameter list may be omitted for parameterized object that are not functions, testcase, altstep, external functions

- notations

  - list notation

  - assignment notation (evaluated in order of actual arguments)

  - midex notation

- passing an parameter to a formal parameter is semantically equivalent to an assignment.

  - this implies that value expansion is (left-hand side reference semantics)

- 5.4.2.m aliasing (of structs and unions) in the same function is forbidden (can we actually enforce that?)

When a parameterized TTCN-3 language element is invoked

- actual parameters are mapped on the

- evaluated in the order they are passed

- evaluated in the scope of the caller

- assignment list notation

_- assignment list notation

- special rules altsteps, templates

- direction

- parameter kind:

    - in (default):

      - by value (copy, type compatibility)

      - optional default value (referencetypes == null)

      - implcit deference

      - no reference to elements of string types

- semantically a parameter is a local variable

- each activate frame is its own location

- default parameter

- assignment list notation allowed (evaluated in order of actual arguments)

- non-l-values (values of templates, defaults, ... must be `in`

An _in-parameter_ is _passed by value_. 

A _out-parameter_ is also _passed by value_.

A _inout-parameter_ is _passed by reference_.

- expanding rules for referencing the elemnt on the left hand side. (6.2, 15.6)

}

```

```ttcn3 example="each invocation has its own copy"

// each invocation of function `fib` has its own copy of parameter n.

function fib(in integer n) return integer {

    if (n < 2) {

        return 1

    }

    return fib(n-2) + fib(n-1)

}

control {

    var integer v := fib(2); // expect: v == 2

}

```

```ttcn3 example="pass by value: changes not visible"

function f(in integer i) {

}

```

```ttcn3 example="pass by reference"

function f(inout integer i) {

    i := i + 1;

}

control {

    var integer i := 0;

    f(i)

    log(i) // expected output: 1

}

```

```ttcn3 example="pass reference by reference"

// TODO: write test to change the passed inout variable to

type component PTC {}

testcase tc() {

    var PTC a := PTC.create("a");

    var PTC b := PTC.create("b");

    var PTC c;

}

```

> NOTE: Passing variables of components as inout-parameter can cause unintended

> side-effects, and should be avoided.