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

Typechecking in recursive records shouldn't be confused by variables in an outer scope. #2023

Open
jneem opened this issue Aug 6, 2024 · 0 comments

Comments

@jneem
Copy link
Member

jneem commented Aug 6, 2024

This example

  (let x = "hi" in
    let a = {
      y = x,
      x = 1 + y,
    }
    in 1) : _

fails with

error: incompatible types
  ┌─ /home/jneeman/tweag/nickel/test2.ncl:4:15
  │
4 │       x = 1 + y,
  │               ^ this expression
  │
  = Expected an expression of type `Number`
  = Found an expression of type `String`

On discord, Yann suggested: "One possibility is to make a two-step pass where we first allocate fresh unification variable before anything else, so that we can already use the recursive environment, and then refine it (by shadowing) whenever an apparent type is available
Another possibility is to just not care about FromEnv. IIRC the most important case, or why we look at the apparent type is to use the information from the type annotation when available"

@jneem jneem added the type: bug label Aug 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant