Compiled vs Interpreted

Put simply, the action tree is the AST with context. That context is info such as what type a function returns, or that two places in which a variable is used are in fact using the same variable. 

Because it needs to figure out and remember all this context, the code that g...

The parser adds structure to to the ordered list of tokens the lexer produces. To stop ambiguities, the parser must take into account parenthesis and the order of operations. 

Simply parsing operators isn’t terribly difficult, but as more language constructs get added, pars...

A programming language is generally structured as a pipeline. That is, it has several stages. 

Each stage has data formatted in a specific, well defined way. It also has functions to transform data from each stage to the next. 

The predominant parsing library is Bison. Bison works a lot like Flex. You write a file in a custom format that stores the grammar information, then Bison uses that to generate a C program that will do your parsing. I did not choose to use Bison. 

A token is a small unit of a language. 

A token might be a variable or function name (AKA an identifier), an operator or a number. 

The parser turns a list of tokens into a tree of nodes. A tree used for storing this type of data is known as an Abstract Syntax Tree, or AST. 

At least in Pinecone, the AST does not have any info about types or which identifiers are which. It is simply structured tokens. 

• Minimize context switching in workflow: context switching between C++ and Pinecone is bad enough without throwing in Bison’s grammar grammar
• Every time grammar changes bison has to be run before the build.
• A custom Parser is completely doable.

If you are writing an interpreted language, it makes a lot of sense to write it in a compiled one (like C, C++ or swift).

 If you plan to compile, a slower language (like python or Javascript) is more acceptable.

Once we have the action tree, running the code is easy. Each action node has a function ‘execute’ which takes some input, does whatever the action should (including possibly calling sub action) and returns the action’s output. This is the interpreter in action.