02c8c2f9e1
This PR implements first-class support for nondependent let expressions in the elaborator; recall that a let expression `let x : t := v; b` is called *nondependent* if `fun x : t => b` typechecks, and the notation for a nondependent let expression is `have x := v; b`. Previously we encoded `have` using the `letFun` function, but now we make use of the `nondep` flag in the `Expr.letE` constructor for the encoding. This has been given full support throughout the metaprogramming interface and the elaborator. Key changes to the metaprogramming interface: - Local context `ldecl`s with `nondep := true` are generally treated as `cdecl`s. This is because in the body of a `have` expression the variable is opaque. Functions like `LocalDecl.isLet` by default return `false` for nondependent `ldecl`s. In the rare case where it is needed, they take an additional optional `allowNondep : Bool` flag (defaults to `false`) if the variable is being processed in a context where the value is relevant. - Functions such as `mkLetFVars` by default generalize nondependent let variables and create lambda expressions for them. The `generalizeNondepLet` flag (default true) can be set to false if `have` expressions should be produced instead. **Breaking change:** Uses of `letLambdaTelescope`/`mkLetFVars` need to use `generalizeNondepLet := false`. See the next item. - There are now some mapping functions to make telescoping operations more convenient. See `mapLetTelescope` and `mapLambdaLetTelescope`. There is also `mapLetDecl` as a counterpart to `withLetDecl` for creating `let`/`have` expressions. - Important note about the `generalizeNondepLet` flag: it should only be used for variables in a local context that the metaprogram "owns". Since nondependent let variables are treated as constants in most cases, the `value` field might refer to variables that do not exist, if for example those variables were cleared or reverted. Using `mapLetDecl` is always fine. - The simplifier will cache its let dependence calculations in the nondep field of let expressions. - The `intro` tactic still produces *dependent* local variables. Given that the simplifier will transform lets into haves, it would be surprising if that would prevent `intro` from creating a local variable whose value cannot be used. Note that nondependence of lets is not checked by the kernel. To external checker authors: If the elaborator gets the nondep flag wrong, we consider this to be an elaborator error. Feel free to typecheck `letE n t v b true` as if it were `app (lam n t b default) v` and please report issues. This PR follows up from #8751, which made sure the nondep flag was preserved in the C++ interface.
23 lines
567 B
Text
23 lines
567 B
Text
example (h : z = 9) : let x := 5; let y := 4; x + y = z := by
|
|
intro x
|
|
simp
|
|
guard_target =ₛ x + 4 = z
|
|
rw [h]
|
|
|
|
example (h : z = 9) : let x := 5; let y := 4; x + y = z := by
|
|
intro x
|
|
simp (config := { zetaDelta := true })
|
|
guard_target =ₛ 9 = z
|
|
rw [h]
|
|
|
|
example (h : z = 9) : let x := 5; let y := 4; x + y = z := by
|
|
intro x
|
|
simp [x]
|
|
guard_target =ₛ 9 = z
|
|
rw [h]
|
|
|
|
example (h : z = 9) : let x := 5; let y := 4; x + y = z := by
|
|
intro x
|
|
simp (config := { zetaDelta := true, zeta := false })
|
|
guard_target =ₛ have y := 4; 5 + y = z
|
|
rw [h]
|