27 lines
2.6 KiB
Markdown
27 lines
2.6 KiB
Markdown
|
# 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.
|