Make “constraints” be GAP objects (separate from refiners, and such that a refiner points to a constraint) #21
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.
This is the start of my work to address peal/vole#25 and peal/vole#26.
Anyway, this is roughly the direction that I'd like to go in:
Refiners are separate from constraints:
I'm not sure how much this will mess up how the Rust code in Vole handles GAP-level refiners...For now and maybe forever, refiners are the same as they were (i.e. records with various components), except that the members relating to the mathematical constraint (i.e. the property) are removed, and that information instead lives somewhere within the constraint object.
I want a user to be able to give a constraint object to a search functions without specifying a refiner for it. For some constraints, such as
IsEven
andIsOdd
, there is no sensible refining that can be done anyway so it feels silly to create a dummy refiner that doesn't do anything.This PR will break GraphBacktracking and Vole. So we don't want to merge this until we are ready to update GraphBacktracking and Vole accordingly.