13 Implementing a type system
This chapter covers
- Computing a type for any expression
- Representing types as objects
- Implementing type checking constraints by comparing computed types
Our example DSL lets domain experts specify each attribute as having a type of amount, date range, or percentage. An attribute’s type describes the values that the attribute can hold, and what meaning those values have. (You can think of a type as a set of values—often a very big set.) Attributes that have either amount or percentage as their type hold numbers, but a value of “$3.0” is different from “3.0%” or even “300%.” Attributes of type date range can hold a completely different range of values, such as “July 25, 2021 until August 7, 2021.” Ultimately, an attribute’s type determines what Runtime code is generated for that attribute.
In chapter 9, we added a type checking constraint to make sure that attributes that were dependent on each other through an initial value had matching types. That makes sense when just looking at the DSL content, but it’s also crucial to prevent incorrect or faulty behavior of the Runtime.
Note For our purposes, we’ll say that two types match when they are equal. We’ll briefly talk about type compatibility as well, in the “Beyond type equality” sidebar in section 13.3.