The user-spec for the type system is to treat them as nominal annotations, and not a property of the value that they are paired with (hence why they are sometimes called "typeAnnotation" internally).
There are a variety of reasons for this (some of them admittedly unsatisfying), but it has important implications across the codebase. Any changes to the mental model of types, even at a purely presentational layer, can have knock-on effects down the line.
The current impact of the type system is rather hard to quantify, but it is used in the following components:
Parts (and Part execution via the PartManager)
MQL
Globals
Tables
Serialization
It is important to note that these components actually treat types differently:
MQL treats types as a language feature, and makes assignability checks between a callsite's argument types and formal parameters. It does not handle table types!
Globals treat types as an annotation, and only uses them in the UI layer to resolve editors for typed values.
Tables use column types, and check assignability on all row sets.
Serialization treats types as having 1:1 pairings with a serializer function. The serializer does not look at type hierarchy.
Parts treat types as documentation, and make no assignability checks whatsoever (even in option calculation!)
This hodge-podge of mental models leaves a mess whenever they conflict (as can be seen in #78). We need to come up with a consistent idea of what Types are actually supposed to be, tighten up the type system, and reorient ourselves and the codebase towards that.
The user-spec for the type system is to treat them as nominal annotations, and not a property of the value that they are paired with (hence why they are sometimes called "typeAnnotation" internally).
There are a variety of reasons for this (some of them admittedly unsatisfying), but it has important implications across the codebase. Any changes to the mental model of types, even at a purely presentational layer, can have knock-on effects down the line.
The current impact of the type system is rather hard to quantify, but it is used in the following components:
It is important to note that these components actually treat types differently:
This hodge-podge of mental models leaves a mess whenever they conflict (as can be seen in #78). We need to come up with a consistent idea of what Types are actually supposed to be, tighten up the type system, and reorient ourselves and the codebase towards that.