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

Reporting generated ty var names does not consider nesting #42

Open
azdavis opened this issue Jul 1, 2023 · 2 comments
Open

Reporting generated ty var names does not consider nesting #42

azdavis opened this issue Jul 1, 2023 · 2 comments
Labels
bug Something isn't working

Comments

@azdavis
Copy link
Owner

azdavis commented Jul 1, 2023

Environment

  • Millet version: v0.12.2

Steps to reproduce

Given:

fun foo x =
  let
    fun bar y = (x, y)
  in
    bar
  end

Hover over the def and usage of x, y, and bar.

Expected behavior

  • x has type ?a
  • y has type ?b
  • bar has type ?b -> ?a * ?b

Actual behavior

  • x and y both are shown as type ?a
  • bar is shown as type ?a -> ?a * ?a at def and "most general" usage, but ?b -> ?a * ?b at "this usage" usage

Comments

This is because we associate the bound ty var from the ty scheme with the meta var when generalizing. But we do not then shift the bound var when crossing another binding site as we should (since bound vars are de brujin indices) and so e.g. the type of bar is shown incorrectly.

We might be able to hack a fix by pushing and popping the current level of generalizing sites (vals). Or maybe we already have this info with the meta var ranks.

Note that there is no actual type-checker unsoundness or incorrect inference, it just is displaying types incorrectly when hovering sometimes. For instance the type of foo is computed as ?a -> ?b -> ?a * ?b, and this is correctly reported.

@azdavis azdavis added the bug Something isn't working label Jul 1, 2023
@azdavis
Copy link
Owner Author

azdavis commented Jul 1, 2023

@azdavis
Copy link
Owner Author

azdavis commented Jul 2, 2023

Thinking about it more, I don’t think the meta var rank is enough information to offset the bound var index. We don’t know how many variables will be generalized and therefore bound at a given generalization site (val binding) until we do it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant