doc: fix typos in 'internals' (#1305)

2 files changed, 25 insertions, 25 deletions

diff --git a/doc/internals/AST.rst b/doc/internals/AST.rst
index 77dba1861..488fa6d71 100644
--- a/doc/internals/AST.rst
+++ b/doc/internals/AST.rst
@@ -11,16 +11,16 @@ The AST is the main data structure of the front-end and is created by the parser
 AST stands for Abstract Syntax Tree.
 
 This is a tree because it is a graph with nodes and links between nodes.  As the graph
-is acyclic and each node but the root has only one parent (the link that point to it).
-In the front-end there is only one root which represent the set of libraries.
+is acyclic and each node but the root has only one parent (the link that points to it).
+In the front-end there is only one root which represents the set of libraries.
 
 The tree is a syntax tree because it follows the grammar of the VHDL language: there
-is for example a node per operation (like `or`, `and` or `+`), a node per declaration,
-a node per statement, a node per design unit (like entity or architecture).  The front-end needs to represent the source file using the grammar because most of the
+is, for example, a node per operation (like `or`, `and` or `+`), a node per declaration,
+a node per statement, and a node per design unit (like entity or architecture).  The front-end needs to represent the source file using the grammar because most of the
 VHDL rules are defined according to the grammar.
 
 Finally, the tree is abstract because it is an abstraction of the source file.  Comments and layout aren't kept in the syntax tree.  Furthermore, if you rename a
-declaration or change the value of a literal, the tree will have exactely the same
+declaration or change the value of a literal, the tree will have exactly the same
 shape.
 
 But we can also say that the tree is neither abstract, nor syntaxic and nor a tree.
@@ -31,12 +31,12 @@ file can be reprinted (the name unparsed is also used) from the AST.  If a mecha
 is also added to deal with comments, the source file can even be pretty-printed from
 the AST.
 
-It is not purely syntaxic because the semantic analysis pass decorate the tree
-with semantic information.  For example the type of each expression and sub-expression
-is computed.  This is necessary to detect some semantic error like assigning an array
+It is not purely syntactic because the semantic analysis pass decorates the tree
+with semantic information.  For example, the type of each expression and sub-expression
+is computed.  This is necessary to detect some semantic errors like assigning an array
 to an integer.
 
-Finally, it is not anymore a tree because new links are added during semantic
+Finally, it is not a tree anymore because new links are added during semantic
 analysis.  Simple names are linked to their declaration.
 
 The AST in GHDL
@@ -47,16 +47,16 @@ The GHDL AST is described in file :file:`vhdl-nodes.ads`.
 An interesting particularity about the AST is the presence of a
 meta-model.
 
-The meta-model is not formally described.  What would be the
-meta-meta-model is very simple: there are elements and attributes.  An
+The meta-model is not formally described.  What the
+meta-meta-model would be is very simple: there are elements and attributes.  An
 element is composed of attributes, and an attribute is either a value
 (a flag, an integer, an enumeration) or a link to an element.
 
-(When someone wants to be clever, he often speaks about meta-model in
-order to confuse you.  Don't let him impress you.  The trick is to
-answer him with any sentence containing 'meta-meta-model').
+(When someone wants to be clever, they often speak about meta-model in
+order to confuse you.  Don't let them impress you.  The trick is to
+answer them with any sentence containing 'meta-meta-model').
 
-In the GHDL meta-mode, there are only 3 elements:
+In the GHDL meta-model, there are only 3 elements:
 
 * variable list of nodes (`List`).  These are like vectors as the
   length can be changed.
@@ -66,10 +66,10 @@ In the GHDL meta-mode, there are only 3 elements:
 * Nodes.  A node has a kind (`Iir_Kind` which is also defined in the file), and fields.
   The kind is set at creation and cannot be changed, while fields can be.
 
-Or without using the word meta-model, the AST is composed of nodes and
+Or without using the word "meta-model", the AST is composed of nodes and
 lists.
 
-The meta-model describes the type of the attributes: most of them are
+The meta-model describes the types of the attributes: most of them are
 either a node reference, a boolean flag or a enumerated type (like
 `Iir_Staticness`).  But there are also links: a reference to another
 node or to a list.
@@ -82,8 +82,8 @@ Why a meta-model ?
 
 All ASTs could have a meta-model, because the definition of elements
 and attributes is very generic.  But there is a detail: the definition
-of an element is static.  So for each node, the list of attribute and
-their type is static and each list is a list of the same element type.
+of an element is static.  So for each node, the list of attributes and
+their types is static and each list is a list of the same element type.
 So there is no bag, nor dynamic typing.  This is per the definition of
 the meta-meta-model.
 
@@ -103,14 +103,14 @@ display a node, it just gets the kind of the type, prints the kind name and quer
 all the fields of the node.  There is nothing particular to a specific kind, so you
 don't need to modify the dumper if you add a node.
 
-The dumper won't be a strong enough reason by itself to have a meta-model.  But
+The dumper wouldn't be a strong enough reason by itself to have a meta-model.  But
 the pass to create instances is a good one.  When a vhdl-2008 package is instantiated,
 at least the package declaration is created in the AST (this is needed because there
 are possibly new types).  And creating an instance using the meta-model is much
-simpler (and much more generic) that creating the instance using directly the nodes.
+simpler (and much more generic) that creating the instance using the nodes directly.
 The code to create instances is in files :file:`vhdl-sem_inst.ad[sb]`.
 
-The meta-model API is moslty automatically generated by the python
+The meta-model API is mostly automatically generated by the python
 script.
 
 Dealing with ownership
@@ -134,7 +134,7 @@ not.  Consider the following VHDL declaration:
 Both variables ``v1`` and ``v2`` share the same type and the same
 initial value.  The GHDL AST uses two different strategies:
 
-* For the type, there is two fields in the node:
+* For the type, there are two fields in the node:
   ``subtype_indication`` and ``type``.  The ``subtype_indication`` is
   owned and set only on the first variable to the output of the
   parser.  The ``type`` field is a reference and set on all variables
@@ -145,7 +145,7 @@ initial value.  The GHDL AST uses two different strategies:
   flag in the node (an attribute) named ``is_ref``.  It is set to
   false on the first variable and true for the others.
 
-The notion of ownership is highlighten by the Rust language, and
+The notion of ownership is highlighted by the Rust language, and
 indeed this is an important notion.  The implementation of the Rust
 AST has to be investigated.
 
diff --git a/doc/internals/Frontend.rst b/doc/internals/Frontend.rst
index fd5abd4e6..3751f1e39 100644
--- a/doc/internals/Frontend.rst
+++ b/doc/internals/Frontend.rst
@@ -27,4 +27,4 @@ checks if it is a keyword.  In that case it changes the token to the keyword tok
 The procedure `scan` is called to get the next token.  The location of the token and
 the location after the token are available to store it in the parser tree.
 
-The main clieant of the scanner is the parser.
+The main client of the scanner is the parser.