Showing changes from revision #2 to #3:
Added | Removed | Changed
Personal incomprehensible notes about type inference.
Basic types
$u_{b,c}$ word with $c$ copies of $b$-bit unsigned quantities. Often the actually implemented values are restricted to $b=8,16,32,64$.
$s_{b,c}$ word with $c$ copies of $b$-bit signed quantities. Often the actually implemented values are restricted to $b=8,16,32,64$.
$e_{b,c}$ word with $c$ copies of $b$-bit embedded quantities. An embedded quantity is an artificial interpretation as an unsigned value where $b=7,15,31,63$.
The aim is the standard “type inferred” language system where a subset of the variables and expressions have explicit type annotations and all other variables/expressions have a consistent type inferred.
Big problem is that fixed-bit size integers are not closed under many useful operations. Get a slightly different interpretation of what the types mean.
Operations
A concrete atomic operation $\oplus$ is a set of functions with various types (corresponding to the operations actually implemented on a particular CPU), eg, silly example $\{\oplus:u_{8,16}\times u_{8,16}\rightarrow u_{8,16},\oplus:u_{16,8}\times u_{16,8}\rightarrow u_{16,8}\}$.
The most basic type inference is just standard Hindley-Milner type inference: e.g.,
given $a:u_{16,8}$ and $c \leftarrow a \oplus b$ we can infer $b:u_{16,8}$ and $c:u_{16,8}$.
equally given $a:u_{16,8}$, $c:u_{8,16}$ and $c \leftarrow a \oplus b$ we get an error that there is no operation with compatible type whatever type we try for $b$.
“Intuitively” any “program” (i.e. sequence of assignments of expression trees to variables) has been successfully typed when
Every “variable” has exactly one type.
For any operation $f$, given the types of all inputs and outputs there is a concrete atomic operation $f$ with that type.
No arbitrary type choices have been made. (This basically says that for any inferred type, at enough points in the web of type inferences there was enough explicit annotation, combined with restricted instruction types, to fully determine what the inferred types must be.) This criterion is actually a bit more subtle dealing with embedded types due to lack of principal types.
Unfortunately this system is not able to do some pretty simple things for an actual instruction set.
Extension involves adding some additional embedded type values along with a set of “promotion”/“reinterpretation” rules. One tricky bit is that we no longer have a simple notion of a single principal type.
[note from Robert Smart: Hi David. Can’t quite work out how to send you a private message, so just delete this. I think my Closure Oriented Programming Language design addresses your issues. (Slightly inaccurate) doc here, and slides. Happy to give the talk anywhere. Will be in the Old Dart late Sept, early Oct for daughters wedding in Wales.]