Skip to content
This repository
tree: 589fce1fde
Fetching contributors…

Octocat-spinner-32-eaf2f5

Cannot retrieve contributors at this time

file 49 lines (35 sloc) 1.853 kb

Synopsis

compiler.pod - overview of Niecza compiler pipeline

Description

The Niecza compiler is currently completely static. It is a Perl 5 pipeline which converts Perl 6 code into C# code, then shells out to gmcs to generate a .exe file.

The compiler is structured as a series of phases, which do not match precisely with the source files.

Intermediate representations

Parse trees

These are created by the viv-generated parser and are very ephemeral; with one exception they are always deconstructed immediately by the action methods. Code to process them is entirely in Niecza::Actions except for some heredoc code.

Op trees

This is the most worthy of the name "AST". Op trees are built mostly from subclasses of Op, with some Body and RxOp objects mixed in. They contain unresolved symbol references, and are the most appropriate objects to return from macros once we have them. These trees are primarily constructed in Niecza::Actions during the "parse" phase, and are converted in-place into metamodel trees during "begin".

Metamodel trees

The metamodel trees are resolved to a specific data organization. They make all typological relationships and scoping explicit. They are constructed of many classes defined in src/Metamodel.pm; function bodies are represented using Op nodes, but it is important to keep in mind that at this stage Op nodes represent pure code and have no declarative or scoping functions. Most optimization passes work at this level.

CgOp trees

CgOp trees represent very concrete code. They are constructed by methods on Op and RxOp objects and consumed by src/CgOpToCLROp.pm, both during the "csharp" pass. This part of the design is still very much in flux; see nam.pod for a more forward-looking take on it.

Something went wrong with that request. Please try again.