Skip to content

fix(subst): also bind expression-locals when substituting a form-local (#1056)#1057

Merged
strub merged 1 commit into
mainfrom
fix-1056
Jun 24, 2026
Merged

fix(subst): also bind expression-locals when substituting a form-local (#1056)#1057
strub merged 1 commit into
mainfrom
fix-1056

Conversation

@bgregoir

@bgregoir bgregoir commented Jun 23, 2026

Copy link
Copy Markdown
Contributor

When a quantified variable in a lemma statement is instantiated (e.g. apply (eager_f_sample z) substituting y -> z), the substitution only updated the form-level locals. Variables embedded inside program statements carried by the formula -- the s1/s2 bodies of an eager [...] judgement, for instance -- live as expression-level locals and were left untouched, producing an incorrect statement substitution.

In both substitution engines (ecCoreSubst.f_bind_local and ecSubst.add_flocal), when binding a form-local x |-> t, if t is translatable back to an expression we now also register the corresponding expression-local binding (bind_elocal / add_elocal). Forms that don't translate (CannotTranslate) are left as before.

tests/eager_call_instanciate.ec reproduces the bug and now passes.

Partially address #1056

@bgregoir

Copy link
Copy Markdown
Contributor Author

I suspect that the function EcSubst.add_flocal also has a similar problem

@strub strub added the bug label Jun 23, 2026
@strub strub changed the title a dirty fix to bug #1056 fix(subst): also bind expression-locals when substituting a form-local (#1056) Jun 23, 2026
#1056)

When a quantified variable in a lemma statement is instantiated (e.g. `apply (eager_f_sample z)` substituting `y` -> `z`), the substitution only updated the *form-level* locals. Variables embedded inside **program statements** carried by the formula -- the `s1`/`s2` bodies of an `eager [...]` judgement, for instance -- live as *expression-level* locals and were left untouched, producing an incorrect statement substitution.

In both substitution engines (`ecCoreSubst.f_bind_local` and `ecSubst.add_flocal`), when binding a form-local `x |-> t`, if `t` is translatable back to an expression we now also register the corresponding expression-local binding (`bind_elocal` / `add_elocal`). Forms that don't translate (`CannotTranslate`) are left as before.

`tests/eager_call_instanciate.ec` reproduces the bug and now passes.
@strub

strub commented Jun 23, 2026

Copy link
Copy Markdown
Member

@bgregoir By ignoring the CannotTranslate exception, this is half-solving the bug. But I suspect that if we do not ignore it, we are going to have a lot of regression. The real fix is not get rid of expressions once and for all, something that is out of scope of this PR.

In consequence, issue #1056 won't be closed by this PR.

@strub strub enabled auto-merge June 23, 2026 23:16
@strub strub added this pull request to the merge queue Jun 23, 2026
Merged via the queue into main with commit 615d335 Jun 24, 2026
19 checks passed
@strub strub deleted the fix-1056 branch June 24, 2026 00:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants