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 resolution of shadowed names in mutual blocks #1139

Open
jamescheney opened this issue May 8, 2022 · 2 comments
Open

Incorrect resolution of shadowed names in mutual blocks #1139

jamescheney opened this issue May 8, 2022 · 2 comments
Assignees
Labels
Milestone

Comments

@jamescheney
Copy link
Contributor

Consider the following (contrived) program:

mutual {
fun bar() { 42 }

fun baz() { 17 }

fun foo(f){ f() }

}

foo(bar)

This should call foo, then bar,then return 42. And it does.

Now consider the following, alpha-renamed program.

mutual {
fun bar() { 42 }

fun baz() { 17 }

fun foo(baz){ baz() }

}

foo(bar)

This should call foo, then bar, then return 42. And it does not.

From looking at the generated IR, for some reason the bindings of mutually recursive functions in mutual blocks are being used instead of local parameter names when there is a conflict.

In some examples in #1136 this appears to be making something work inside a mutual block by accident that otherwise doesn't.

@jamescheney jamescheney added the bug label May 8, 2022
@dhil dhil added this to the 0.9.7 milestone May 8, 2022
@jamescheney
Copy link
Contributor Author

Also:

mutual {

fun bar() { 42 }

fun baz() { "xyzzy" }

fun foo(baz){
 {baz()}
}

}

foo(bar)

runs and returns "xyzzy" : Int, which suggests that typechecking is doing the right thing but this is happening after typechecking... Indeed looking at the type of foo, it is correctly generalized to (() ~a~> b::Any) ~a~> b::Any which suggests that scope is being handled correctly at least until type inference.

@dhil dhil self-assigned this May 25, 2022
@dhil
Copy link
Member

dhil commented May 25, 2022

I will put this issue under "name shenanigans" umbrella of issues that I have been working on for some time. As with the other name issues, the proper solution here is to have a properly hygienic names. This is a non-trivial change, although, it is something I have nearly implemented in another patch https://github.com/dhil/links/tree/name-resolution. I will try to prioritise some time for landing that patch this summer.

@dhil dhil modified the milestones: 0.9.7, 0.9.8 Jul 22, 2022
@dhil dhil modified the milestones: 0.9.8, 0.9.9 Nov 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants