core node

The parse tree can be seen as three separate trees, each with its own kind of node. Each of these node takes up part of the overall tree’s functionality.

While we are talking about three different objects here, the way these objects are represented using classes differs. We’ll talk about that a bit more later on.

API node

This is what the casual user sees when they are constructing parsers.

The API node contains all the publicly documented members:

• The parse and safeParse methods.
• The 🛠️tuners of a given parser type.
• The 🛠️pipe tuners too.

A constructor

The API

Polymorphic

The API node is the only node which is allowed to be polymorphic. This means having separate classes for each node type and having separate members for each type.

That includes:

1. 🛠️️tuners, whic

This is for performance reasons. Code that uses polymorphic objects performs much worse than code that doesn’t, because it can’t be optimized in the same way.

1. The construction tree, which is where all methods like 🛠️️tuners are defined and what combinators are invoked on. It’s a relatively thin wrapper around the other parts of the tree.
2. The execution tree, which is the way separate parser cores call each other. This tree can’t be navigated or inspected, as each apply method is an opaque closure.
3. The explorable tree, which is an object representation of the parse tree that mirrors the way it was constructed. This version of the tree is explorable and nodes from this tree are what ends up in parse stacks.

These trees handle different aspects