Commented with Ericsson opinion after internal evaluation

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.

  library document.--- NO! WHY? What would be the advantage of it? 

* Removing or deprecating features that could be substituted by other features

  (e.g. arrays).

  (e.g. arrays). --- If it will be only a shorthand of record of length (fixed value) then ok

* 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, ...).

  parameterization, closures, ...). NO, more details (adv/disadv) needed

**Extensions**

# Coding style

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

We should extend the ruleset for coding style of TTCN-3 examples (and conformance tests).  -- Isn't it too large work?

# Templates

};

```

Details need to be worked out in future discussions.

Details need to be worked out in future discussions. -- if possible :)

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

functions, as language extensions or even by user-defined dynamic matching. -- Only to be moved to extension, but NOT functions, user-defined (???) dynamic (???) matchning. Semantics and syntax must be kept.

## Inline Templates

literals are already part of the language.

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

it is NOT type-conversion, but some kind of casting; inline templates are needed, used frequently

## Modified Templates

Modified template and modified inline template syntax might be unified and simplified.

Modified template and modified inline template syntax might be unified and simplified.  - HOW?

## List Templates

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

I guess it would be useful in the opposite direction value:= (value)template  - discussion needed, for us the existing definition is ok

This could also improve on compiler-pleasing 

// it is not a point how complicated the compiler is; the language shall be easy-to-use

through `valueof` and on

operations such as `omit`, `present`, ...

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.

* Substitute `anytype` with `any`. Type switch (---?????) from OOP extension would be a

  good addition. - anytype will be in an extension; not to make backward incompatible solutions just for fun; would clash with any timer, any component, etc.

* Arrays

  * remove custom indexing.

  * should become short-hand notation.

  * remove custom indexing. -- ok

  * should become short-hand notation.  -- ok

* `set` and `set of` should be reviewed (compatibility with records,

  replacement possible?)

  replacement possible?) -- record of and set of are different ROI := {1,2,3}  SOI1:={1,2,3} SOI2 := {1,3,2} SOI1==SOI2 but ROI != SOI2

* Should automatic typing be extended to unions and generics or should it

  rather be moved to an extension?

  rather be moved to an extension? NO

* 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[*] := {}`).

  * One could find overlap of `unmap` operations confusing.  -- Unmap can be used for ports and maps; new keyword would have been better; but now will cause backward incompability

  * 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, ...).

  variables, ...). -- If only definition harmonisation, then ok; if meaning changes, not

## List Types

    }

    return true

}

```

``` Shall be defined clearly, if the last elements are undefined it counts in the size/length or not

```ttcn3

var record of integer a := {1,9};

`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 `receive` part of `check` operation could be removed probably. //check(template) is a shorthand of check(receive(template)) ?? shall be checked if parsr can handle it in a simple way

The `trigger` could be substituted by `check`.

The `trigger` could be substituted by `check`. // no, the trigger takes the value out of the queqe, while check do not

Decoded field references, `decmatch`, `@decode` could be simplified. It needs to be checked whether `=>` can be removed.

Decoded field references, `decmatch`, `@decode` could be simplified. It needs to be checked whether `=>` can be removed. //=> is used in OOP for a different purpose. One of them shall be be modified (probably in OOP)

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.

External actions (`action`) do not need to be part of the core language. //Shall be, this is how something can be written to screen during execution

Modifiers (pe.g. `@deterministic`, `@nocase`, `@nodefault`, ...) or often overlooked. Further discussion is needed whether there's opportunity to generalize them.

Modifiers (pe.g. `@deterministic`, `@nocase`, `@nodefault`, ...) or often overlooked. Further discussion is needed whether there's opportunity to generalize them.  //@deterministis - fuzzy/lazy; the other two are useful

Attributes might be simplified:

  * remove `display`

## Module organization

`import` will be simplified if possible.  

This would make `group` superfluous. However groups are used to structure

`import` will be simplified if possible. // supported only import all 

This would make `group` superfluous. However groups are used to structure  //group of instructions are useful

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,

Visibility features (`friend`, `private`, `protected`) are used by testers,  //in many other languages these 3 categories exist

seldom. It's used primarily by framework developers. Possible improvements need

further discussion.

probably be merged into a common extensions document.

* Performance and real-time extension:

  * `wait` --> core

  * `timestamp` --> core

  * `wait` --> core  //discussion needed

  * `timestamp` --> core  //discussion needed

  * remaining features --> extension

* Configuration and Deployment features mostly stay as they are.

* Advanced parameterisation:

  * Value parameterisation of types: Could be removed.

* Behaviour types:

  * Behaviour types (and closures) will probably move to core to help

    simplification.

    simplification.  // Further rationale is needed, just for fun is not enough

  * Deferred behaviour will be removed.  

* Continuous signals will probably go to historic state

* Advanced matching:

  * Dynamic matching will probably move to core.

  * Dynamic matching will probably move to core.  //needs further discussion

  * Other features need further discussion.

* Object oriented features:

  * Exception-feature will probably move to core

  * Some type operations (`=>`, `select class`) probably, too

  * Exception-feature will probably move to core  //But how?

  * Some type operations (`=>`, `select class`) probably, too  //select class without class?; => is used for another purpose in core

  * If and in what form user defined object will be merged into core is not

    clear yet.

    clear yet.  // What is user defined object?