-
Notifications
You must be signed in to change notification settings - Fork 3
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
Sharing in properties produces unprovable Coq propositions #211
Labels
Milestone
Comments
MajaRet
added
enhancement
New feature or request
Coq
Related to Coq back end or base library
labels
Sep 24, 2020
MajaRet
changed the title
Allow impure properties
Sharing in properties produces unprovable Coq propositions
Sep 24, 2020
MajaRet
added
bug
Something isn't working
pipeline
Related to the compiler pipeline (e.g. compiler passes or the command line interface)
and removed
enhancement
New feature or request
bug
Something isn't working
labels
Sep 24, 2020
MajaRet
pushed a commit
that referenced
this issue
Sep 28, 2020
MajaRet
pushed a commit
that referenced
this issue
Sep 28, 2020
MajaRet
pushed a commit
that referenced
this issue
Sep 28, 2020
MajaRet
pushed a commit
that referenced
this issue
Sep 28, 2020
MajaRet
pushed a commit
that referenced
this issue
Sep 29, 2020
MajaRet
pushed a commit
that referenced
this issue
Sep 29, 2020
MajaRet
pushed a commit
that referenced
this issue
Sep 30, 2020
MajaRet
pushed a commit
that referenced
this issue
Sep 30, 2020
MajaRet
pushed a commit
that referenced
this issue
Sep 30, 2020
MajaRet
pushed a commit
that referenced
this issue
Sep 30, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
An impure
Property
is converted toFalse
when converting it to a CoqProp
. This makes properties with more than one occurrence of a variable on their right-hand side unprovable.Steps to Reproduce
Translate the following QuickCheck property on the
issue-76
branch.Then compute
quickCheck (fun Shape Pos I => @prop_refl Shape Pos I Cbneed)
.Expected behavior
The property should be provable via the
reflexivity
tactic.Actual behavior
Because x occurs twice, sharing analysis will transform this property as follows.
This will then be translated to
share x >>= (fun (x0 : Free Shape Pos (Integer Shape Pos)) => @eqProp Shape Pos (Integer Shape Pos) _ x0 x0).
Now, when we try to prove this property using call-by-need evaluation,
share x
will be animpure
value, which means the wholeProperty
will beimpure
. However, an impureProperty
is currently translated to the CoqProp
False
, meaning the property becomes unprovable.More specifically, the result of
quickCheck (fun Shape Pos I => @prop_refl Shape Pos I Cbneed)
is nowWe should not simply prevent the generation of
share
/call
operators in properties. Instead, we should try to allowimpure
properties and find an appropriate way to translate them into CoqProp
s.Additional Notes
This behavior is not technically a bug and rather a consequence of the existing design, which does not allow impure properties. But since it causes call-by-need evaluation to be essentially unusable, I will keep it labeled as a bug.
The
main
branch does not currently behave like this unlesslet
bindings are explicitly introduced in properties. However, the behavior will appear if the sharing analysis (#169) is merged, so we should find a solution before then.The text was updated successfully, but these errors were encountered: