[Translate] Compiler (9)-parsing

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

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

Compiler (9)-parsing

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
Part VIII: Abstract syntax tree

The Long march has gone a long way. We have an overview of the basic concepts of scanning and abstract syntax trees. Now it's time to move on to the resolution.

If you have started to struggle with the concept point, then I need to warn you that it will become more and more difficult from now on. Parsing may be the hardest part of the concept that you have in your head. We will deal with the morphemes found by the scanners, give them a meaning, and save the result object in the AST.

Make sure you understand the previous information before you move on.

Parsing objects

Our small language parser can be said to be quite simple. As with the scanner, we have a pointer to information about the file being scanned. We track errors and scanner objects in some way.

The remaining three fields are mapped directly from the values returned by the scanner: location, identifier, and lexical string.

Entrance

Parsefile is where the magic begins. Initializes the parser and begins the scan. If one or more errors occur, stop and output the error message. Otherwise, the file object is returned as the entry for the program.

Similar to the scanner, Init is ready to start. Any call to the parser function will cause the parser and scanner to move forward and cannot be backed up. The fuel is the line of code, so let's start the engine!

Parsefile is a partner for its release. This function creates the first object of the AST. Review Part Five again (how important is it to see grammatical rules?). We can think of this file object as the root of everything. This is what we have done, and the File object is the first object.

Idea, we didn't do any checking before we looked at the first expression. This is because our grammatical rules tell us that this should be the case. Otherwise, it is wrong. We expect to find some form of expression, if it is not found will be an annoying thing, no matter how, no indomitable forward it!

Finally, we need to make sure that the last identifier in the file is the end of the file (EOF). The syntax rule identifies that there should be no additional content after the root expression has been obtained. If you find anything else after the period, report a mistake. Announce to everyone, call everyone and taunt!

An expression

We have discussed the expression many times. Now, the task is to find an expression with parsegenexpr, but at first we don't know what type it is. However, the first identifier will tell us all the information we need. If we find an opening parenthesis, then there is a binary expression. If an integer is found, it is an integer. Otherwise, an error is generated and then continues.

Integers are the most easily parsed element. It has nothing to pay attention to in detail. The code itself is a good illustration of the problem.

However, a binary expression can be a little trickier. Calc 1 has only two value expressions, but in the near future we will add more types of expressions. Similar to Expression objects, we need a more generic way to do generic processing before special handling of each one. PARSEEXPR is used for this purpose.

First, expect to find an opening parenthesis. If it's not found, it's wrong. Next, you need to identify what type of expression this is. We know that the only expression type that is currently present is a binary expression, so next determine what operator the next identifier is. If you do not get the expected content, you need to report an error.

BINARYEXPR shows the process by which our parsers are constantly looping. We have found the opening parenthesis and the operator, so we need to look for the operands next. This process is done by recursive invocation of parsegenexpr. Build the entire tree on one layer at a continuous level until the end.

When we find all the operands, we expect to have a closing parenthesis to end the expression. Finally, return the Binaryexpr object as the result and insert it into the tree.

Expect, Next and Adderror

Expect is a great gadget function. We tell it what identifier we expect to get. If it's there, that's good. If not, report a mistake. Regardless, the position of the element is returned.

Next does not actually need to be explained. It just gets what the scanner finds, and then stores it in the parser's object.

Adderror adds an error to errorlist. If more than 10 errors are found, there is no need to continue. It will print errors and force the parser to exit with an error code.

Syntax analysis

Our parsing steps parse the syntax during its work, which ensures that the parsed source code conforms to the syntax rules.

The lack of anything is unacceptable. It's true!

Complete

This is what this step is all about. If you have a good grasp of this part, then the final step should be easy. As our grammar design gets deeper, the parser becomes more and more complex. For this, Calc 2 should be a good example.