Fix some typos

meetings/2025-03-11.md

@@ -2,15 +2,14 @@
 
 ## Range-based loop alignment
 
-We discussed proposed changes for issue #23 and and #30 and came to a
-resolution that fixes most misalignments with only minor changes to the current
-behaviour:
+We discussed proposed changes for issue #23 and #30 and came to a resolution
+that fixes most misalignments with only minor changes to the current behaviour:
 
 - Automatic type inference will be included, but no new BNF productions will be
   added.
 - Templates will not be included in for-range-loop declarations, to avoid open
   edge cases with `lengthof`.
-- The perception for assignment of an uninitialized iterator variable will be
+- The description for assignment of an uninitialized iterator variable will be
   added.
 - The examples will be reorganized to reflect above changes.
 
@@ -32,12 +31,12 @@ and compile a proposal.
 
 We discussed the current state of template evaluation and its implementation in
 different tools. We recognized the validity of the different use-cases for
-all different types of template and aggreed that the current specification is
+all different types of template and agreed that the current specification is
 not clear enough and needs to be revised.
 
 One cause for confusion is the meaning of "parameterization". It is not clear
 if this means parameterization in the sense of formal and actual parameters or
-if it is used a general term for any kind of referring to a source of values
+if it is used as a general term for any kind of referring to a source of values
 (constants, functions, ...).  
 Issue #49 will be used to identify and clarify the different usage of the term
 parameterization.
@@ -49,7 +48,7 @@ Further discussion and proposals for template evaluation and deprecation of
 ## Type Terminology
 
 We agreed that the current terms do not serve us well and should be revised.
-Harmonization of charstring should be taking into account and its consequences
+Harmonization of charstring should be taken into account and its consequences
 need to be studied.
 
 Issue #50 will be used to track the progress on this topic.
@@ -57,7 +56,7 @@ Issue #50 will be used to track the progress on this topic.
 
 ## Structured Types
 
-The discussion the following structured types will be tracked by issue #51.
+The discussion of the following structured types will be tracked by issue #51.
 
 ### `set` and `set of`
 
@@ -69,9 +68,9 @@ specification.
 
 We discussed use-cases and limitations of `anytype` and `any`.
 
-`anytype` is widely used various language mapping but has the limitation to be
-contrained to a single module. `any` is more flexible, but does not allow
-explicit selection of types and it's use is limited to external functions only.
+`anytype` is widely used in various language mapping but has the limitation to be
+constrained to a single module. `any` is more flexible, but does not allow
+explicit selection of types and its use is limited to external functions only.
 
 We agreed to merge `any` and `anytype`. The new open type will be called
 `anytype` since it is older and more established.
@@ -115,7 +114,7 @@ b := 1;        // ERROR: integer is not part of the subtype
 ```
 
 This new behaviour models what is known as "sum types", "variant types",
-"tagged unions", ... and helps to specifiy polymorphic functions such as `substr`:
+"tagged unions", ... and helps to specify polymorphic functions such as `substr`:
 
 ```ttcn3
 type anytype listtype (hexstring, octetstring, bitstring, charstring);
@@ -141,7 +140,7 @@ type record R {
 }
 ```
 
-This proposal was rejected, since it people are used to it and the benefit of
+This proposal was rejected, since people are used to it and the benefit of
 this restriction is not convincing.
 
 ### Map-types
@@ -153,8 +152,8 @@ implementation" without special syntax (like it was done with containers in
 C++).
 
 We could not see the benefits of changing the current specification and decided
-to keep it as it is, but at least review the specification of `unmap` to delete
-elements.
+to keep it as it is. But at least we want to review the specification of
+`unmap` to delete elements.
 
 ## Automatic types
 
@@ -166,8 +165,8 @@ such feature would create unnecessary implementation effort for tool vendors.
 
 Speaking in favor of automatic typing, it was argued that implementation effort
 is only minimal since type inference is already implemented in every tool
-anyway. It was also argued that automatic typing can also lead to
-higher code quality by improving readablity and preventing potential errors
+anyway. It was also argued that automatic typing can lead to
+higher code quality by improving readability and preventing potential errors
 rooted in type compatibility during assignment:
 
 ```ttcn3
@@ -202,11 +201,11 @@ We postponed the decision for now, since it is not a critical issue.
 
 ## Type Semantics
 
-During discussion if its possible to import the same module twice (no, it's
-not), it became apparent that we need to introduce new concepts to the language
+During discussion if it's possible to import the same module twice (no, it's
+not), it became apparent that we need to introduce new concepts to the language's
 type system.
 
-The definition of __type synonym__, __type alias__, __subtype__ need to be reviewed.
+The definition of __type synonym__, __type alias__, __subtype__ needs to be reviewed.
 
 This could include __type compatibility__, __type equivalence__ and __strong typing__.
 
@@ -216,7 +215,7 @@ Currently there are two uses for __strong typing__:
   value is not changed.
 - in port communication to ensure that the encoding of a value is as expected.
 
-Issue $52 will be used to track the progress on this topic.
+Issue #52 will be used to track the progress on this topic.
 
 ## Expressions
 
@@ -240,12 +239,12 @@ Further work on this topic will be continued in issue #53.
 
 ## Definition of Templates
 
-Templates are __the__ central concept of TTCN-3. The evolution of the language,
+Templates are _the_ central concept of TTCN-3. Evolution of the language,
 however, has led to a situation where the standard has become difficult to
 understand. For example, when talking about "values" sometimes the term refers
-to a concrete value without matching symbols, sometimes to a concrete value or
+to a concrete value without matching symbols, but sometimes to
 the value of a template. When talking about "templates" sometimes the term
-refers to a value of template type, sometimes just to the template-type.
+refers to a value of template, sometimes just to the template-type.
 
 For the next major release we agreed to refine the terminology and how
 templates are specified.
@@ -258,7 +257,6 @@ Issue #54 will be used to track the progress on this topic.
 Index-access, length, concatenation, value list assignment, assignment-lists,
 handling of uninitialized elements and templates needs harmonization.
 
-
 Issue #22 will track that progress.
 
 
@@ -266,7 +264,7 @@ Issue #22 will track that progress.
 
 Interleave is required for certain used cases. Waiting for some messages to
 arrive during error-handling, to name one example. However in its current state
-it's too easy to create extremly complex and opaque behaviour.
+it's too easy to create extremely complex and opaque behaviour.
 
 Issue #55 will be used to discuss possible improvements.
 
@@ -282,12 +280,12 @@ Issue #56 will be used to track the progress on this topic.
 
 ## `with` statements and attributes
 
-Similar to the import statment, the `with` statement should be simplified.
+Similar to the import statement, the `with` statement should be simplified.
 
-We discussed that the `with` statement is useed for attaching attributes to
+We discussed that the `with` statement is used for attaching attributes to
 module-definitions of modules or groups and to types and their fields directly.
 
-"Allrefs" seem not to be used in practice, as is the `display` attribute and
+"AllRefs" seem not to be used in practice, as is the `display` attribute and
 multi-encodings.
 
 Issue #57 will provide a proposal for simplification without losing
@@ -324,7 +322,7 @@ since the standard already provided a way to break out of nested loops using
 After extensive discussion we came to the conclusion that preprocessing macros
 should stay part of the core language specification.
 
-It should be reviewd, though, since the some macros (`__SCOPE__` and
+It should be reviewed, though, since the some macros (`__SCOPE__` and
 `__MODULE__`) cannot be used as macro but rather as a predefined constant.
 
 ## Goto
@@ -333,13 +331,13 @@ We had mixed feelings about `goto`. On the one hand its use is discouraged in
 many environments, on the other hand, it can a be a powerful tool (given it's
 properly specified and used).
 
-Goto could be a candidate for previously mentioned convenience extension.
+Goto could be a candidate a convenience extension.
 Further discussion is needed.
 
 
 ## Convenience extension
 
-Many language features strictly speaking are not necessary, but provide the
+Many language features, strictly speaking, are not necessary, but provide the
 convenience of writing less code, providing modern programming patterns, ...
 
 An extension package could help us providing the best of both worlds: A core