Add drafts for release 5

# Basic Language Elements

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

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

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

> parameters, type parameters or fields.

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

### Uniqueness of identifiers

- a name must be unique in its scope

- a name reference must not be ambigious.

 - not shadowing

 - fields are okay

 - how about enums?

 - two execptions:

   - module definitions because import all and optional prefix

   - types, objects, ...

### Ordering of language elements

- Generally, the order in which declarations can be made is arbitrary.

- Inside a statement block or alternation block, however, a name shall not be used before it has been declared,

- additional rules for enumerated types, fields for records and sets and formal parameters.

### Cyclic Definitions

Direct and indirect cyclic defintions are not allowed with the exception of the following cases:

0. for recursive type definitions of records (clause 0.0), sets (clause 0.0), unions (clause 0.0)

0. recursive behaviour of functions (clause 0.0), altsteps (clause 0.0) and methods (clause 0.0)

0. cyclic import dependencies (clause 0.0)

### Group scopes

A group declaration is purely syntactical and does not have its own scope. See

clause 0.0 for details.

# 10. Declaring variables

A variable is a named memory location to store the value of a given type.

**Syntactic Structure**

```ebnf

VarDecl = "var" [TypeExpr] Declarator { "," Declarator} [With].

Declarator = name {"[" integer "]"} [":=" Expr].

```

**Semantic Description**

A _variable declaration_ adds a new variable with given _name_ into its enclosing scope. 

The initial value of a value type variable is _undefined_.

The initial value of a reference type variable is `null`.

A variable shall not be declared in module scope.

## 11. Declaring module parameters

A module parameter is a variable that can be assigned a value only once per test execution.

**Syntactic Structure**

```ebnf

ModuleparDecl = "modulepar" [TypeExpr] Declarator { "," Declarator} [With].

```

**Semantic Description**

## 12. Declaring constants

A constant is a variable that can be assigned a value only once per test execution.

**Syntactic Structure**

```ebnf

ConstDecl = "const" [TypeExpr] Declarator { "," Declarator} [With].

```

**Semantic Description**

#  Declaring dynamic behaviour

## General

- specify dynamic behaviour:

  - test-cases

  - default handling

  - calculate values

  - interact with SUT or platform

  - dynamic templates or behaviour through parameterization

> In TTCN-3, functions, altsteps and testcases are used to specify and

> structure test behaviour, define default behaviour and to structure

> computation in a module, etc. as described in the following clauses.

> Functions are used in TTCN-3 to express test behaviour, to organize test

> execution or to structure computation in a module, for example, to calculate

> a single value, to initialize a set of variables or to check some condition.

## Parameterization

### General

- defined incompletely

- semantically a parameter is a local variable

- each activate frame is its own location

### Formal parameters

- direction

    - in (default):

      - by value (copy, type compatibility)

      - optional default value (referencetypes == null)

      - recommended: no-side effects == constant evaluation

      - conflicting with: 5.4.1.1e

      - order

    - out:

      - by value (copy, type compatiblity)

      - copy back

    - inout:

      - by reference (type euqality, strong typing)

      - incremential changes visible

      - implcit deference

### Actual parameters

- assignment list notation allowed

> NOTE 1: Reference to a string element cannot be passed by reference as string types are not structured types.

what does this mean?

It is allowed to pass elements of structured values or templates (record, set, record of, set of, union and anytype values

or templates) by reference. Modification of parameters passed this way affects the original structured value or template.

Before passing the actual parameter, the rules for referencing the element on the left hand side of assignments are

applied, expanding the structured value so that the referenced element becomes accessible (see clauses 6.2 and 15.6 for

more details).

NOTE 2: Because inout parameters are passed by reference and component variables are effectively also accessed

by reference within a called function or altstep, passing parts of a structured component variable as an

actual inout parameter may have confusing effects inside the parameterized behaviour: changing either

the inout parameter or the component variable may also change the other simultaneously, which might

break the intended algorithm. For this reason, such situations should be avoided.

### Variadic parameters

## Invoking functions

## Prefedined Functions

## External functions

## Control functions

## Parmaterized templates

## Testcases

## Altsteps