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

Incorrect inferred type for functions capturing globals with weak type variables #147

Open
jfecher opened this issue Jan 15, 2023 · 0 comments
Labels
panic A panic within the compiler

Comments

@jfecher
Copy link
Owner

jfecher commented Jan 15, 2023

If a function captures a global variable whose type contains a weak type variable (ie. one that will later be resolved but we do not yet know enough information to assign it a concrete type) the function will incorrectly be inferred to be polymorphic over this weak type variable, even if it is later resolved in the global. Example:

x = 3    // inferred type: Int a
f () = x // inferred type: forall a b. Unit -> Int a can b

This forall a portion is problematic since it will still be polymorphic even if the global is later resolved to a more specific type:

x = 3
f () = x

x + 4u8  // x is now known to be U8
// Type of f is still (forall a b. Unit -> Int a can b)

Attempting to print the type of f via --show-types will actually now show (forall U8 b. (Unit -> U8 can b)) since these forall-quantified variables are never meant to be bound over, but the treatment of them is the same as if they were unbound in the function type.

The correct inferred type of f would be forall b. Unit -> Int a can b with the now free a still referring to the same type variable used by x. There is a similar, common check for closures that close over values to not be polymorphic over the values that they close over, but this does not trigger in this instance since x is global and therefore not captured in the same way other globals are. It does hint that a possible solution may be to try to trigger this check either by enforcing all functions that close over globals with non-function values to be closures, but this may be overkill.

@jfecher jfecher added the panic A panic within the compiler label Jan 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
panic A panic within the compiler
Projects
None yet
Development

No branches or pull requests

1 participant