Book available: “All about Proofs, Proofs for All”

As a result of the APPA workshop at Vienna Summer of Logic 2014, there is now a book available with the collected contributions by the invited experts (including myself). It is edited by Bruno Woltzenlogel Paleo and David Delahaye, and is published by College Publications. Here is a copy of the abstract from it:

The development of new and improved proof systems, proof formats and proof search methods is one of the most essential goals of Logic. But what is a proof? What makes a proof better than another? How can a proof be found efficiently? How can a proof be used? Logicians from different communities usually provide radically different answers to such questions. Their principles may be folklore within their own communities but are often unknown to outsiders.

This book provides a snapshot of the current state of the art in proof search and proof production as implemented in contemporary automated reasoning tools such as SAT-solvers, SMT-solvers, first-order and higher-order automated theorem provers and proof assistants. Furthermore, various trends in proof theory, such as the calculus of inductive constructions, deduction modulo, deep inference, foundational proof certificates and cut-elimination, are surveyed; and applications of formal proofs are illustrated in the areas of cryptography, verification and mathematical proof mining.

Experts in these topics were invited to present tutorials about proofs during the Vienna Summer of Logic and the chapters in this book reflect their tutorials. Therefore, each chapter is intended to be accessible not only to experts but also to novice researchers from all fields of Logic.

My contribution to the book is a chapter on “Interactive Theorem Proving — from the perspective of Isabelle/Isar”, with the following abstract:

Interactive Theorem Proving (ITP) has a long tradition, going back to the 1970s when interaction was introduced as a concept in computing. The main provers in use today can be traced back over 20–30 years of development. As common traits there are usually strong logical systems at the bottom, with many layers of add-on tools around the logical core, and big applications of formalized mathematics or formal methods. There is a general attitude towards flexibility and open-endedness in the combination of logical tools: typical interactive provers use automated provers and disprovers routinely in their portfolio.

The subsequent exposition of ITP takes Isabelle/Isar as the focal point to explain concepts of the greater “LCF family”, which includes Coq and various HOL systems. Isabelle itself shares much of the relatively simple logical foundations of HOL, but follows Coq in the ambition to deliver a sophisticated system to end-users, without requiring self-assembly of individual parts. Isabelle today is probably the most advanced proof assistant concerning its architecture and extra-logical infrastructure.

The Isar aspect of Isabelle refers first to the structured language for human-readable and machine-checkable proof documents, but also to the Isabelle architecture that emerged around the logical framework in the past 10 years. Thus Isabelle/Isar provides extra structural integrity beyond the core logical framework, with native support for parallel proof processing and asynchronous interaction in its Prover IDE (PIDE).

Flattr this!

Proposal: remote prover connectivity for Isabelle/PIDE

(See also general notes on proposals.)

“Cloud computing” is one of these buzzwords without any particular meaning, but the idea to run heavy-duty computations remotely is rather old: some “big-iron” in the background provides the CPU and memory resources for substantial applications, while the user interacts with the system via some small local terminal. Already in the classic days of Proof General (around 1999) it was common-place to run Emacs locally on a workstation and the prover process remotely on a server (via rsh). Alternatively it was possible to run both the editor and the prover remotely and use X11 as display protocol, which was especially important for the rather heavy XEmacs of that time.

This normal mode of distributed computing was almost forgotten, when the performance of local laptops and remote servers were approaching the same order of magnitude (due to the demands of the gaming industry). This was only an episode over a single decade, though, and we are already back to the traditional situation where local and remote machines can differ significantly. In 2014, typical mobile devices were limited to 2–8 CPU cores and 2–8 GB RAM. This is very little compared to low-end workstations or high-end servers, with something like 8–36 CPU cores and 32–512 GB RAM, or more.

Note that some big Isabelle applications already go beyond the possibilities of small machines with only 4–8 GB RAM, but for more memory Poly/ML process needs to be switched from 32-bit to 64-bit mode, which also doubles the memory demands. Thus there is a discontinuity here: stepping out of the “small device” category means to go for 16–32 GB RAM minimum.

This motivates the demand for remote prover connectivity for Isabelle and its Prover IDE (PIDE). The most basic approach is to run the internal socket connection for the PIDE protocol between ML and Scala over ssh. This should be sufficient for fast and reliable local networks. For non-local networks, there are the usual questions about bandwidth, latency, and reliability of the connection. The PIDE protocol requires relatively high bandwidth (which is easily provided by common DSL connections), but can afford high latency due to its asynchronous nature. Lack of reliability might turn out a real problem, though: resetting a lost TCP/IP connection naively means to restart the prover process and recheck the whole session from start, which could take minutes or hours.

Thus a more advanced approach would keep both the ML and Scala side of PIDE together on the server. Remote access then works via a separate PIDE display protocol, which is postulated here and still needs to be defined and implemented. Depending on active buffers and open text areas in the editor, the remote side would provide continuous access to incoming PIDE document markup, without demanding persistent management of the whole PIDE state locally. Loosing the connection would merely mean to reconnect the IDE to the remote Isabelle/Scala/ML component, which keeps running indefinitely.

Thus the mode of operation becomes more like the re-connection facility of VNC or RDP (but not X11). Of course it is already possible today with Isabelle2014 to use VNC or RDP for a completely remote ML/Scala/IDE process, but remote ML/Scala and local IDE would make this more comfortable for the user, with better graphics performance and reactivity.

Taking this perspective of remote PIDE sessions one step further could mean to support low-bandwidth, high-latency, unreliable connections of mobile networks: sitting on a train with a laptop and local IDE, while re-connecting to a remote PIDE session on a big server, would really count as cloud computing. We should think here of editing whole libraries like AFP on the spot, with immediate feedback. A bit more efforts will be required to get there, though.

In summary, the following stages are possible, depending on the amount of resources spent on this subject:

  1. Simple remote PIDE socket connection via ssh, usable for fast and reliable local networks. (The jEdit text editor already provides some means to manage ssh, so this merely requires the usual study of sources with subsequent tinkering and polishing to make it work smoothly.)
  2. Separate PIDE display protocol where the editor is local and the Isabelle/Scala/ML session is remote. This should be usable for fast DSL network connections.
  3. Support for smooth disconnection and re-connection for mobile networks.
  4. Development of a completely different PIDE front-end that works on tablets or smart-phones (Android or iOS).

The last point is speculative: it merely sketches to horizon of what could eventually be targeted, if there were lots of resources and several enthusiastic people working on it.

Flattr this!

General notes on proposals

This section of the website is meant to improve the Isabelle platform for Interactive Theorem Proving, as far as I am personally involved. Beyond that there are many users, contributors, and developers of Isabelle applications and add-on components world-wide, e.g. see the collected outcomes in the Archive of Formal Proofs as the visible universe of formally published results.

The category proposals collects articles on particular topics as they emerge over time. This may serve informative purposes on important lines of further Isabelle development, or as a starting point for discussion and elaboration — depending on specific demands of big and important applications out there.

Moreover, this is an explicit invitation to support proposals actively. A variety of ways are possible to do that:

  • Donate small amounts, potentially dedicated to a particular area of work that you want to see raised in priority. This may be understood as a modest form of crowdfunding.
  • Procure some funding as part of a bigger research or development project, and get me involved as an external contractor or consultant.
  • Invite me to your research or development group (at your expenses), in order to support you, your co-workers, your students, your users in advanced Isabelle applications. For example, the format could be an internal workshop of a few days, or a stay over a few weeks, to instruct prospective experts of Isabelle tool development.
  • More ambitious plans according to your particular requirements and possibilities.

I am ready to provide such professional services around the Isabelle platform that fit into my areas of expertise, and can be fulfilled with the side-condition of myself being mainly located at the center of Europe: Bavaria / Swabia / Augsburg. 2000 years ago that was the capital of the Roman province of Raetia. 500 years ago it was the commercial and financial center of the Western World (the Empire of Charles V), due to the Fugger family. Today it is my own base for research and development projects, where I am both remote and connected to the world.

Please contact me via email as given on the main page. Further local address details are given in the impressum (together with some formal German legalese).

Flattr this!