[Translate] Compiler (8)-Abstract syntax tree

This is a creation in Article, where the information may have evolved or changed.

Here's the original.
———— Translation Divider Line ————

Compiler (8)-Abstract syntax tree

The first part: Introduction
Part II: compilation, Translation and interpretation
Part III: Compiler Design Overview
Part IV: Language Design Overview
Part V: Calc 1 Language Specification sheet
Part VI: Identifiers
Part VII: Scanning

Before you build the parser, you should first talk about how to handle the target data.

You need to use some kind of abstract data type to hold all the data that needs to be parsed. The tree-shaped data structure is a good fit for our needs. This tree describes the grammatical structure of the programming language, which is aptly called the Abstract Syntax tree (AST).

Ast

Tree data structures always start from one root, and so are our. Typically, in a mature compiler, you typically have an object that represents a package or program. In our case, we have only one file, so we will have an object called file.

Other parts of this object can be found in our syntax blueprint. Again, let's review the fifth part of our rules for creating grammar. It tells us exactly what we need. Do you feel happy that you have established standards? It still provides strong support when we start parsing and grammar analysis.

Other objects that need to be created: expressions and integers.

Go interface

Before you construct the objects you need, consider what they should look like. What do we know about it?

We know that the scanner will provide us with three things:

The string that we scanned. May be the value "42".
represents an identifier for an element. Token. Lparen is an opening parenthesis.
the position at which the element begins. The number between the base and base of the file plus the size of the file.

The things that coexist in all the objects in the tree are their positions. Where they start and where they end. For example, an error report does not care what type of object it is. Just need to know how much it's positioned. So we created a Node interface that has two methods for starting Pos, and end-of-position.

Next, there is a recurring element in our grammar rules: expressions. An expression can be an integer, or a string of elements wrapped in parentheses. Its interface will be called Expr. Any Expr object must implement an interface that Exprnode a full match to Node at the same time.

You can now pass objects through each interface between different parts of the compiler, and you can use type assertions to get their true type if you want. This should be clearer when we get to the resolution step.

Object

We need to implement three objects and one helper object:

integer
-expression
File

We'll start with an Integer. We have previously considered that integer types are actually not different from other objects. You can spend a lot of time creating objects for each type of language, or you can create just one object to hold all the basic types.

Basiclit is such an object. Whether we have integers, floating-point numbers, strings, or characters, it doesn't matter. This object can meet all of the above requirements. Of course, we only need integers at the moment, but in the end we always make some additions. This object holds a syntax string that tells us the identifier of the object type, where the syntax string begins, and the string identifier.

Skip the expression first, and first look at File. This object is similar. As a starting point, it has a field: Root. Looking back at the syntax rules, you can see that a file holds an expression that appears as the root of everything else.

Now the expression is a special type. From a mathematical standpoint, they are two-valued expressions. There are several elements that need to be tracked: an operator, a left and right parenthesis, and two or more operands, and an operand that can be an expression.

A two-valued expression is not always our only expression type. Eventually, we'll need more types. Only the left and right brackets are available for each expression in our language. This is where universal expressions can help. Its only function is to handle parentheses. This object is embedded in all the sub-expressions.

The beauty of Go is that any object can "inherit" the embedded object in a way that is embedded. This is not a true inheritance, but the compiler is smart enough. In any case, the result is the same for our purposes.

As already mentioned, binaryexpr needs to have an operator and a set of operand objects. We have a field to hold the operand and its position in the code. The operands are stored in a slice that fully satisfy the Expr interface.

AST Tools

If you need to query the AST, a way to traverse the tree can help. This simple Walk function is provided for this purpose.

With the Print method, the AST can be printed out, and only the entire tree is traversed and the information for each node is printed sequentially.

Keep moving

We're going to do the parsing step soon, but I want to make sure the AST code is clear. Nested definitions are easy to confuse, and some methods do not provide the context in which they are used. Please review this article and the previous article before continuing.

Thank God, assembling all the pieces and parsing them should make things clearer.