
<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div style="orphans: 2; widows: 2;">In the initial message, Joachim suggested “<span style="orphans: 2; white-space: pre-wrap; widows: 2;">One </span><span style="orphans: 2; white-space: pre-wrap; widows: 2;">could imagine adding a job to travis that translates container’s master </span><span style="orphans: 2; white-space: pre-wrap; widows: 2;">into Coq and checks if the proofs go through.</span><span style="white-space: pre-wrap;">”</span></div><div><div style="orphans: 2; widows: 2;"><span style="white-space: pre-wrap;"><br></span></div><div style="orphans: 2; widows: 2;"><span style="white-space: pre-wrap;">It would seem to me that an ideal situation would be if there were “proof-tests” similar to doctests. Essentially, portions of code that have corresponding Coq proofs about them have an annotation that indicates the proofs, and indicates to the automated job that they are to be tested against those proofs. When changes are made that do not have corresponding updates to the proofs, then the corresponding annotations would need to be commented-out (or perhaps, replaced with some other annotation that explicitly indicates a skipped or missing proof). </span></div><div><br></div></div><div>This would let the proper containers core be verified, with mechanically-checked annotations indicating where the verification hasd and has not been performaed. Some sort of re-exported subset of only the verified stuff could then be automatically extracted from this setup for users that wanted to restrict themselves to only this subset.</div><div><br></div><div>—g</div></body></html>