Skip to content

saw-core: Move 'Variable' constructor from FlatTermF to TermF. #2475

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

Merged
merged 2 commits into from
Jul 9, 2025

Conversation

brianhuffman
Copy link
Contributor

With the plan to move away from de Bruijn indices for variable binding, the 'Variable' constructor will play a more specialized role, and so it makes more sense to be out of FlatTermF.

With the plan to move away from de Bruijn indices for variable
binding, the 'Variable' constructor will play a more specialized
role, and so it makes more sense to be out of FlatTermF.
@brianhuffman
Copy link
Contributor Author

There are a few regression test failures. Maybe this has to do with putting scWhnf in the wrong place in a TypeInfer instance in SCTypeCheck? I'll look into it.

@sauclovian-g
Copy link
Contributor

It's odd that all the failures are specifically timeouts.

@brianhuffman
Copy link
Contributor Author

Not all of the failures are timeouts: test_hoist_ifs_in_goal gets a real failure. I ran it locally, and here's the output:

[20:25:00.636] Loading file "test.saw"
[20:25:00.684] WARNING: assuming goal prove_print is unsat
[20:25:00.689] Run-time error: encountered call to the Cryptol 'error' function: undefined

Very interesting! Now I'm thinking that I made something slightly more strict than before. I'll read over the diffs carefully and try to find something. But the business with cryptol error makes me think there's another latent bug that I just uncovered.

@sauclovian-g
Copy link
Contributor

Hmm, apparently I can't read. :-|

but yes, that's definitely plausible, could definitely result in timeouts...

@brianhuffman
Copy link
Contributor Author

It turns out I made a couple of mistakes in Rewriter.doHoistIfs and SharedTerm.instantiateLocalVars. I'll see if that taking care of those fixes the problem.

@brianhuffman
Copy link
Contributor Author

Investigating test_hoist_ifs_in_goal, I can see that there are differences in the behavior of the rewriter on this branch. I must have broken something in the matching algorithm.

@brianhuffman
Copy link
Contributor Author

I found it: I needed to add a case to the alphaEquiv function. There was no incomplete pattern-match warning because alphaEquiv matches on two constructors at once, and uses a wildcard pattern to cover all the different-constructor cases. We should think about whether there's a better way to do this.

@sauclovian-g
Copy link
Contributor

For things like that I'll often leave a collection of cases at the bottom:

-- Make sure the compiler warns if new constructors appear and we forget to
-- add cases
  :
termf (Pi _) _ = False
termf (LocalVar _) _ = False
termf (Constant _) _ = False
termf (Variable _) _ = False

@brianhuffman brianhuffman merged commit 8707f15 into master Jul 9, 2025
37 checks passed
@brianhuffman brianhuffman deleted the bh/variable branch July 9, 2025 01:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants