Construct DatatypeRef and DatatypeSortRef for datatype terms and sorts - #120
Merged
Conversation
Neither _to_expr_ref nor _to_sort_ref had a datatype case, so a term of a
datatype sort came back as a plain ExprRef and its sort as a plain
SortRef. Const('l', List) was therefore missing the DatatypeRef methods,
and the sort was missing num_constructors(), constructor(), recognizer()
and accessor() - even though Datatype.create() returns a proper
DatatypeSortRef.
Add the missing branch to each. Tuple sorts are datatypes as well, so
TupleSort terms and sorts are now properly wrapped too.
DatatypeRef.sort() no longer needs to build the sort itself and delegates
to _sort.
Fixes the first half of cvc5#100.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Neither
_to_expr_refnor_to_sort_refhad a datatype case, so a term of a datatype sort came back as a plainExprRefand its sort as a plainSortRef:Datatype.create()already returns a properDatatypeSortRef, so only the round-trip through these two constructors lost it.Changes
One branch added to each constructor.
isDatatype()is disjoint from every sort predicate already tested in both chains — I checked Int, Bool, Array, Set, String, Seq, BitVec, FP, RoundingMode, uninterpreted and function sorts all reportFalse— so the branches go at the end and cannot shadow an existing case.Tuple sorts are datatypes as well, so
TupleSortterms and sorts are now properly wrapped too:DatatypeRef.sort()no longer needs to build the sort itself and delegates to_sort, the same cleanup #118 made forFuncDeclRef.Relation to #100
This fixes the first of the two problems reported in #100 — the missing
DatatypeRefcast — and makes the reporter'sConstbackpatch unnecessary. The lambda-sort half was fixed by #118.Worth noting for whoever closes #100: neither PR unblocks the reporter's original
knuckledraggeruse case, which needs a function declaration whose range is a lambda's sort. cvc5 rejects a function sort as a codomain, and declaring the range as an array sort instead makesf(x) == lambda_bodyfail on theArray Real Boolvs(-> Real Bool)mismatch from the issue. Bridging function and array sorts is separate work.Testing
test_doc.py: 2094 doctests, 0 failures; 22 new examples covering the wrapping, the sort methods and the datatype constructor applications.test_unit.py: OK.black --check --required-version 24: clean.pyright: 620 errors, down from 621 on main — none new.🤖 Generated with Claude Code