-
Notifications
You must be signed in to change notification settings - Fork 108
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
produce _def and _val theorems in value_type #689
Conversation
9e71804
to
616345e
Compare
I haven't yet used the new |
I think this is a solid start (going via _val for now). Content looks good. For Commits:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@michaelmcinerney should possibly be aware this is in the queue
Let's not block anything on this one. I'm happy to do the rebase whenever it goes in and the aarch64 branch is ready for it.
Thanks, will go through these
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't used value_type
myself so can't comment on the practicalities of the change, but this looks good to me.
As another nitpick; in the first commit message - "The numeric value as 'a' term"
Produce a _def theorem for the value type that provides direct symbolic access to the right-hand side of the value_type definition. This avoids having to unfold those terms in subsequent proofs. The numeric value as as term is still available as <type-name>_val. This restricts value_type to nat/int inputs, i.e. word is no longer accepted on the rhs (so far unused). A manual cast to nat on the rhs will still work. Signed-off-by: Gerwin Klein <[email protected]>
Rename occurrences of _def to _val for value_type-generated names. Does not make full use of value_type _def theorems yet. Signed-off-by: Gerwin Klein <[email protected]>
Produce a
_def
theorem for the value type that provides direct symbolic access to the right-hand side of thevalue_type
definition. This avoids having to unfold those terms in subsequent proofs.The numeric value as as term is still available as
<type-name>_val
.value_type
is now restricted to typesnat
andint
on the right-hand side (int
being cast tonat
automatically). Other types can still be used, but have to be cast to nat manually. It turns out that so far we have only neededint
andnat
, so this works out without changes to any of thevalue_type
definitions.