Fix typos

## Templates

We discussed changed covered in proposal #77 and received mixed feedback.

We discussed planned changes from proposal #77 and received mixed feedback.

Issues with TTCN-3 templates are challenging to resolve,

because different tools evaluate templates differently and

**Make all templates dynamic**

From a testers perspective it would make the most sense to evaluate templates

From a testers perspective it would make the most sense to evaluate all templates

when instantiated:

- it plays well with most use-cases

  tests)

- it aligns nicely with already existing language features (e.g.

  modified-templates, parameterized templates)

- its very intuitive

- it's very intuitive

A typical use of dynamic templates would be:

**Make all templates static**

The other extreme would be removing dynamically evaluated templates altogether.

Parameterized template syntax would be a shorthand notation for functions

Parameterized template syntax could be a shorthand notation for functions

returning templates.

This is the approach of proposal #77, essentially.

The idea behind is that rules for static templates and user-defined functions

are sufficient for modelling behaviour in any desired way, without

complicating any language mechanics.

complicating language mechanics.

In practice testers would have to rewrite most templates

to be parameterized templates, because most templates seem to have a dynamic

**Middle ground**

The middle ground would be specifying the way a template is evaluated,

The middle ground would be specifying the way a template is evaluated by

some kind of modifier. For example `@lazy`, `@dynamic` or `const`.

**Conclusion**

We stopped the discussion at one point to continue with the other language

We stopped the discussion at some point and continued with the other language

features. Core takeaways were:

- Proposal #77 is elegant, but not very practical

- Dynamic templates only is practical, but has poor support for

- Proposal #77 is sufficient, but not very practical

- Dynamic templates only, is practical but has poor support for

  programming in TTCN-3.

- Current middle ground solutions have poor acceptance.

- What ever to solution might be, all tool-vendors must provide identical

- What ever the solution might be, all tool-vendors must provide identical

  behaviour!

because it is easy to shoot yourself in the foot.

This suggestion was somewhat controversial, since interleave is used

and decisions how to use it should be project-specific and not enforced

by the standard committee.

confidently and decisions how to use it should be project-specific and not enforced

by the standards committee.

## Import

## Procedure Based Communication

No objection to move procedure based communication into an extension.

No objections to move procedure based communication into an extension.

## Module parameters

Module parameters be specified differently, but essentially stay the same.

Module parameters will be specified differently, but essentially stay the same.

## Types and Values