diff --git a/notes_max.md b/notes_max.md index 6ee6773d472ccc029713f344aeeb97437850743d..3b771c846278c9851d416d2f969afdc6b68b05cb 100644 --- a/notes_max.md +++ b/notes_max.md @@ -127,4 +127,20 @@ Since memory statements have already been converted into variable declarations ( In case of `string` literals the output type is also a `string`. However, in the case of integer literals we can only determine that the output type is some integer, the place where the literal is employed determines the integer type. It is valid to use this for byteshifting, but also for operating on floating-point types. In the case of decimal literals we can use these for operations on floating point types. But again: whether it is a `float` or a `double` depends on the place where the literal is used. - **variable expression**: - Refers to some variable declared somewhere. Hence the return type is the same as the type of the variable. \ No newline at end of file + Refers to some variable declared somewhere. Hence the return type is the same as the type of the variable. + +## Type Inference - The Concrete Algorithmic Steps + +Lets start with places where the parser types (i.e. not the types assigned to the nodes in the expression trees) are actually specified: + +- Function and component arguments +- Function return types +- Local variable declarations (from both regular and channel variables) +- Struct fields +- Enum variants + +For now we do not consider struct/enum/union literals yet. We perform type inference in bodies of functions/components. Whenever we actually lay out a monomorphed proctype we already know the polymorphic arguments of that proctype. Hence, by definition, we know all the types of the proctype arguments and function return types of the proctype we're resolving. + +Hence we encounter: +- Inferred types of variable declarations: These may be fully inferred, partially inferred, or depend on the polymorphic variables of the wrapping proctype's polymorphic arguments (which are determined). Hence if they're somehow inferred, then we mark them as such. +- Inferred types of polyargs of called functions/components: Special case where we use the return type of the proctype and the expressions used as arguments to determine the polymorphic types. Once we know the polymorphic types we may determine other types, or the other way around. Now that I think about it, this seems like a special case of inference in the call/literal expression itself. So there seems to be no reason to pay particular attention to this. \ No newline at end of file