tweag/nickel

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

Opened this issue · 0 comments

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"