As much as we might like to think that data types are fixed in place, data types are actually just as mutable as the values they categorize.

Consider the following:

Given: A type exists, by the name of Int.
Given: Another type exists, by the name of List.


How, then, could we describe a type named List<int>? Is it a derivative of Int? Is it a derivative of List? Is it its own separate type? Is List even a type at all?

Similarly, consider this:

Given: A type named Int.
Given: The type Int, Int is a tuple of Int.


So, what then, is Int, Int, Int? Is it a tuple of three Ints? Is it a tuple of one Int and one Int, Int? Is it a tuple of one Int, Int and one Int?

The fact of the matter is that types, just like expressions, can be, and frequently are combined into new types. This, when expressed as text, requires parsers to establish rules about operators, precedence, and the order in which type names are listed in order to represent them in memory.

So why not parse them the same way as expressions?

Pratt parsing is a relatively simple way to parse mathematical, or otherwise arithmetic expressions.

Bob Nystrom's article on Pratt Parsing (linked above) is probably the best and easiest article on the topic. I suggest reading it!

The Pratt Parsing technique can be applied to types in the same way as it can be to expressions.

More on compilers in following articles...