We recently extended our runtime type-checking to recursively type-check structures such as lists, enums, and records. This resulted in redundant and resource-demanding type-checking overall.

Going forward, the following outlines our intentions with regard to type-checking:

• more type-checking should be done at “compile-time”
• during run-time,
  1. type-check structures at construction
  2. make type-checking an O(1) operation
• this will involve:
  • including type references in Dvals
    • e.g. add a TypeReference component to DList
  • ? including type args in Dvals
    • e.g. in DEnum
• consideration: only type-check the first element of a list

Suppose we have type A = { b: B } and type B = { c: C } and C = Int when we construct a C we should check its type when we put the C into the B, we should check that C is a C (but not that C is an Int) when we put the B into the A, we should check that B is a B (but not anything internal inside B)

Outstanding questions:

• should we rebrand TypeChecker to RuntimeTypeChecker? (probably OK as-is)

future non-redundant type-checking: typechecking tlist // potentially, DList would contain a type reference to the type of the list, // and we'd only have to check tNested v dNested // , in that scenario, in this context, we'd know that if the DList was formed with that TR and vals, // then ...