We have a runtime type-checker that is incomplete - it passes when we expect a TList<Int> and we have a DList with non-Ints in it.

At one point, our type-checker was recursive in that it would look at all values within structures such as lists, to ensure types match, but this recursive nature was very slow, so we gutted it.

Recent efforts have been made to do much of this type-checking upon construction, such that:

• Dval cases contain “ValueTypes” corresponding to the types of data inside
  • i.e.,
  • a list [1] represented by | DList of items: List<Dval> would have simply been DList([DInt 1])
  • but we’ve updated the DList definition to | DList of ValueType * items: List<Dval>, and the Dval of [1] is now DList(ValueType.Known KnownType.KTInt, [DInt 1])
• upon construction, we ensure the Dvals have the appropriate ValueTypes, where relevant
• when type-checking, we can use these ValueTypes to non-recursively ensure we are type-safe

In most places throughout our codebase, it’s clear what the ValueType(s) of a Dval should be, and we can

• Given an existing DList(VT.int, [DInt 1; DInt 2]), if we call the function Builtin.List.filter (with any lambda), we know the output will be a List of the same internal type
• Math.asin will always return an Option of a Float — so we know the Dval should be roughly DEnum("Option", [VT.float], ...)

In other cases, we determine the appropriate ValueTypes dynamically, and fail if attempts are made at creating invalid/inconsistent Dvals

• when evaluating an EList([EInt 1; EInt 2]) (e.g. in let x = [1; 2]), we can dynamically determine that this should be a DList of VT.int
• When evaluating an EList([EInt 1; EString "two"]) (e.g. in let x = [1; "two"]), we should error, and let the user know they can’t have a list of inconsistently-typed data

We are currently pretty close to completing this effort, but some problems remain:

• we aren’t yet fully using newly-defined RuntimeErrors corresponding to these issues
• we don’t have good error messages for those RuntimeErrors, and it seems difficult to gather context required to do such