2.6 KiB
Type Inference + Generics
The interpreter needs to evaluate expressions with an expectation of what type they will result in. For example, if it encounters an empty list expecting a list of ints, then it will return an empty list but the type information will convey that it is a list of ints. Currently the way it works is that it just returns a list where the internal type of the list is an empty variable type, which has been hard-coded to be a subclass of any list and have any list be a subclass of that type. Evaluating with knowledge of the expected type will also allow for enum members to be returned or referenced with a '.' + the enum member name, rather than having to name the enum type itself every single time.
Generics + Generic functions
Maybe I can also remove the 'object' type. I could have any function that can take in any opject just use a generic type parameter. E.g., The len function can be of type A[] -> int, where A is just not used in the return_type. Maybe for generic functions I will need to have the definition indicate it. E.g.,
func len<A> (list: A[]) -> int { ... }
You could probably still call the function without needing to specify A. E.g.,
ints: int[] = [0, 1, 2, 3, 4, 5]
num_ints = len(ints);
You won't need to, but still can do this:
num_ints = len<int>(ints);
It would probably quite hard to parse, however. How would the parser know the difference between that first < and a less than comparison between some variable len and some variable int? It would need to at some point start parsing for a type, but when will it know that? len<int>(ints) can be justifiably parsed as len less than int greater than ints, where ints has been wrapped in parentheses and you are comparing a booling to a list. But of course, the parser has no knowledge of what types expressions are. A similar situation would occur if I did len[int](ints) instead. It could be parsed as array len element number int, called with the argument ints.
Should I even allow the user to specify the type for a generic function? What would they need that for. Maybe they need to return an array of a higher type a type inferer would infer. For example, they need a function to return a object[], and it just so happens that they know that they start of with a int[], but will add objects later, or instead of int and object, any two types where the former is a subtype of the latter.
Um, actually. I think what I'll do is have the language infer the types for any generic functions, and then convert the return value to any types if you indicate it.