Asynchronous Editing for Coq
Résumé
In this talk, I will demonstrate the integration of the jEdit editor with Coq, developed as part of the Paral-ITP project. jEdit is an editor with very little off-the-shelf functionality, designed to be extended by language-specific plugins. These plugins receive user changes asynchronously, and use these changes to produce feedback. Because the computation model is asynchronous, there is no way for the user to instruct where and when the proof assistant computes on the proof script, as in Proof General and CoqIDE. Instead, the proof assistant plugin is always active in the background, and automatically reacts to changes in the script, reporting states, errors and markup information. The main intent of the talk is to demonstrate the tool, and discuss the differences between asynchronous and synchronous interaction, as well as the future directions of the middleware used by jEdit to communicate with the prover. There are two main benefits to interacting asynchronously with Coq. The first is more freedom for the author in editing the proof, the second is that it allows the proof assistant to schedule the processing of a proof more sophisti-catedly. Interaction benefits The main benefit in interaction is that, in jEdit, the author can edit a proof script at any place, adding lemmas and modifying proofs, without advancing the computation of the prover. In fact, errors that the author introduces in a script do not always influence the state of future proofs, and the author is free to move between to proves to get the statement of a lemma just right before finishing a proof. Sophistication of Computation Scheduling In the ProofGeneral model, the proof structure is revealed to the proof assistant step by step, and the user always wants feedback for the last line executed. In an asynchronous model, the entire proof script is available to the proof assistant at once, and can be used to compute the structure of the proof. This structure can then be used to schedule computations, possibly in parallel, to provide the user with feedback immediately. For example, consider a proof with two lemmas. The first takes a long time to verify, but the user wants to edit the second. In ProofGeneral, when the user focuses on the second lemma, the proof assistant would first verify the first lemma, taking a long time and only then give the control back to the user.
Origine | Fichiers produits par l'(les) auteur(s) |
---|
Loading...