Skip to content
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

Limit unification of types and function argument types #459

Draft
wants to merge 2 commits into
base: develop
Choose a base branch
from

Conversation

JSAbrahams
Copy link
Owner

@JSAbrahams JSAbrahams commented Feb 4, 2023

Summary

In short, if we have a variable used within a function, say:

# some variable x is declared and used a bunch
f(x)

We can use type inference to get the type of x even if we don't assign it a type above.
However, if we already know the type of x, then at most the check stage should check that it is a valid argument to the function.
If we instead match it directly, we can get weird situations if the function signature specifies the argument is a union.
Then the unification stage will also state that x is this union, which can lead to erroneous output:

Example

def f(x: {Int, Str}) -> Int => 10

def x := 10
f(x)

Will give the following:

# function definition here
x: Union[int, str] = 10
f(x)

While we expect:

x: int = 10
f(x)

Code quality

Move propagate logic to Constraint, moving logic away from Name which shouldn't be there.

Added Tests

WIP: Argument types still leak out unnecessarily in tests:

  • readme_examples/factorial
  • call/input

JSAbrahams and others added 2 commits January 22, 2023 22:13
* Classes inherit all from parent

- Remove INIT token
- in uses __contains__ magic method
- Remove Mamba specific magic methods

* Filter out parent fields in assign check
However, argument types still leak out
unnecessarily in:
- readme_examples/factorial
- call/input
@JSAbrahams JSAbrahams added code quality: general Code quality issue not relevant to a particular module bug: check Something in the type check module isn't working (as intended) labels Feb 4, 2023
@JSAbrahams JSAbrahams added this to the v0.3.7 | Type alias milestone Feb 4, 2023
@JSAbrahams JSAbrahams self-assigned this Feb 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug: check Something in the type check module isn't working (as intended) code quality: general Code quality issue not relevant to a particular module
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant