leanprover-community / leanprover-community/iris-lean

`grind` annotations for OFE operations

Open
#129 0 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

experiment
Dominant language
Lean
Stars
218
Forks
63
Avg merge
1d 23h
Merged PRs (30d)
22

Description

In our development we have quite a few calc blocks such as:

theorem Agree.includedN {x y : Agree α} : x ≼{n} y ↔ y ≡{n}≡ y • x := by
  refine ⟨fun ⟨z, h⟩ => ?_, fun h => ⟨y, h.trans op_commN⟩⟩
  have hid := idemp (x := x) |>.symm
  calc
    y ≡{n}≡ x • z := h
    _ ≡{n}≡ (x • x) • z := .op_l (hid n)
    _ ≡{n}≡ x • (x • z) := CMRA.op_assocN.symm
    _ ≡{n}≡ x • y := h.symm.op_r
    _ ≡{n}≡ y • x := op_commN

In my opinion, this is a great way to structure these proofs! I even like it better than the the Rocq version which uses setoid rewriting, because you're able to actually read these proofs, without trying to mentally reconstruct what effect each step has on the goal.

I think they could be made even better if the proof terms were (mainly) inferred, and I think that grind might be the right tool to do that. Is it possible to add grind annotations to our codebase so that the bulk of the steps in these calc blocks are all resolved by grind?

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the calc block in the issue body and investigate whether Lean's grind can infer the proof terms for its equality steps. Identify representative OFE operations and determine what annotations are needed across the codebase; done means the bulk of these calc-block steps are resolved by grind without reducing proof readability.

Written by the indexing model from the issue text.

Assessment

Domain
tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.