Skip to content
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

Merged
merged 3 commits into from
Apr 10, 2024
Merged

produce _def and _val theorems in value_type #689

merged 3 commits into from
Apr 10, 2024

Conversation

lsf37
Copy link
Member

@lsf37 lsf37 commented Oct 26, 2023

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.

value_type is now restricted to types nat and int on the right-hand side (int being cast to nat automatically). Other types can still be used, but have to be cast to nat manually. It turns out that so far we have only needed int and nat, so this works out without changes to any of the value_type definitions.

@lsf37 lsf37 added proof engineering nicer, shorter, more maintainable etc proofs proof tools convenience, automation, productivity tools labels Oct 26, 2023
@lsf37 lsf37 self-assigned this Oct 26, 2023
@lsf37 lsf37 marked this pull request as draft October 26, 2023 23:01
@lsf37 lsf37 force-pushed the value_type branch 3 times, most recently from 9e71804 to 616345e Compare October 30, 2023 22:49
@lsf37 lsf37 marked this pull request as ready for review October 31, 2023 06:12
@lsf37
Copy link
Member Author

lsf37 commented Oct 31, 2023

I haven't yet used the new _def theorems to eliminate previous manual instance of that, because my first search&replace attempt turned out to be too aggressive. I might add another commit to this PR for that, but the current state at least works and is worth looking at.

@Xaphiosis
Copy link
Member

I think this is a solid start (going via _val for now). Content looks good. For aarch64 branch, we'll have to do the update as well. Maybe after pre-VSpace_C, but before VSpace_C. Thoughts?

Commits:

  • lib: produce _def and _val thes in value_type : thms?
  • is it worth repeating that it's for nat/int in the commit message?
  • proof: proof updates for value_type _def -> _val - you can probably skip the second proof here
  • Rename _def into _val occurrences for value_type name. Does not make full use of value_type _def theorems yet. - this is hard to understand, perhaps the word "generated" could make an appearance to help? "Rename occurrences of _def to _val for value_type-generated names." ?

Copy link
Member

@Xaphiosis Xaphiosis left a 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

@lsf37
Copy link
Member Author

lsf37 commented Nov 3, 2023

I think this is a solid start (going via _val for now). Content looks good. For aarch64 branch, we'll have to do the update as well. Maybe after pre-VSpace_C, but before VSpace_C. Thoughts?

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.

Commits:

  • lib: produce _def and _val thes in value_type : thms?
  • is it worth repeating that it's for nat/int in the commit message?
  • proof: proof updates for value_type _def -> _val - you can probably skip the second proof here
  • Rename _def into _val occurrences for value_type name. Does not make full use of value_type _def theorems yet. - this is hard to understand, perhaps the word "generated" could make an appearance to help? "Rename occurrences of _def to _val for value_type-generated names." ?

Thanks, will go through these

  • lib: produce _def and _val thes in value_type : thms
  • repeat that it's for nat/int in the commit message
  • proof: proof updates for value_type _def -> _val - skip the second proof
  • Rename _def into _val occurrences for value_type name. Does not make full use of value_type _def theorems yet. - "Rename occurrences of _def to _val for value_type-generated names." ?

Copy link
Member

@corlewis corlewis left a 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"

lib/Value_Type.thy Outdated Show resolved Hide resolved
lib/Value_Type.thy Outdated Show resolved Hide resolved
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]>
@lsf37 lsf37 merged commit 8b6f7f3 into master Apr 10, 2024
9 of 14 checks passed
@lsf37 lsf37 deleted the value_type branch April 10, 2024 09:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proof engineering nicer, shorter, more maintainable etc proofs proof tools convenience, automation, productivity tools
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants