Skip to content

Implement --infer #305

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Tracked by #1600
certik opened this issue Mar 31, 2022 · 3 comments
Open
Tracked by #1600

Implement --infer #305

certik opened this issue Mar 31, 2022 · 3 comments

Comments

@certik
Copy link
Contributor

certik commented Mar 31, 2022

The --infer flag specified at the command line of lpython would infer the type of the variable from the RHS, thus allowing not to declare variable types in most cases. The return type of a function can be inferred from the "return" statements. The arguments of functions would still need to be typed, but later as we implement generics, say with syntax something like:

T = TypeVar("T")
def f(a: T, b: T):
    c = a + b
    return c

print(f(3, 4)) # would instantiate f as f(i32, i32) -> i32
print(f(3.5, 4.5)) # would instantiate f as f(f64, f64) -> f64

which with --infer would automatically infer the return type of "f" as T (as well as the type of c as T) and then the instantiation of the generics would correctly create full types at compile time.

Then we could go further, and --infer could simply make the following equivalent to the above:

def f(a, b):
    c = a + b
    return c

print(f(3, 4)) # would instantiate f as f(i32, i32) -> i32
print(f(3.5, 4.5)) # would instantiate f as f(f64, f64) -> f64

One tricky part is taht f(a, b) would technically be f(a: T, b: U), and I am currently not sure how one would infer the type of c = a + b. But maybe there is a way.


Initially --infer should not be on by default. It should be an opt-in feature, and we should gain experience with it and see if this is useful and if it can be on by default, or if will make Python code not as readable (such as like overuse of auto in C++). This option might be helpful for interactive use.

@namannimmo10
Copy link
Collaborator

namannimmo10 commented Mar 31, 2022

Initially --infer should not be on by default

+1

This would also be helpful while dealing with NumPy: #5 (comment)
In general, I think strict type checking is useful for a large codebase, as it is easier to find bugs, or rather I should say: one would encounter fewer bugs.

@certik certik mentioned this issue Mar 21, 2023
38 tasks
@rebcabin
Copy link
Contributor

Suggestion: when a constructor appears on the right-hand side of a definition, it's pure noise to repeat the hard type on the left-hand side. This ONE CASE should be safe always.

@certik
Copy link
Contributor Author

certik commented Apr 19, 2023

A related idea is to infer both the types as well as casting, e.g.:

  • 2 * 3.0 -> f64(2) * f64(3.0)
  • f32(3.0) * 3.0 -> f64(3.0) * f64(3.0)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants