Systematic Verification of the Modal Logic Cube in Isabelle/HOL

We present an automated verification of the well-known modal logic cube in Isabelle/HOL, in which we prove the inclusion relations between the cube's logics using automated reasoning tools. Prior work addresses this problem but without restriction to the modal logic cube, and using encodings in first-order logic in combination with first-order automated theorem provers. In contrast, our solution is more elegant, transparent and effective. It employs an embedding of quantified modal logic in classical higher-order logic. Automated reasoning tools, such as Sledgehammer with LEO-II, Satallax and CVC4, Metis and Nitpick, are employed to achieve full automation. Though successful, the experiments also motivate some technical improvements in the Isabelle/HOL tool.Comment: In Proceedings PxTP 2015, arXiv:1507.0837

The P4->NetFPGA Workflow for Line-Rate Packet Processing

P4 has emerged as the de facto standard language for describing how network packets should be processed, and is becoming widely used by network owners, systems developers, researchers and in the classroom. The goal of the work presented here is to make it easier for engineers, researchers and students to learn how to program using P4, and to build prototypes running on real hardware. Our target is the NetFPGA SUME platform, a 4x10 Gb/s PCIe card designed for use in universities for teaching and research. Until now, NetFPGA users have needed to learn an HDL such as Verilog or VHDL, making it off limits to many software developers and students. Therefore, we developed the P4->NetFPGA workflow, allowing developers to describe how packets are to be processed in the high-level P4 language, then compile their P4 programs to run at line rate on the NetFPGA SUME board. The P4->NetFPGA workflow is built upon the Xilinx P4-SDNet compiler and the NetFPGA SUME open source code base. In this tutorial paper, we provide an overview of the P4 programming language and describe the P4->NetFPGA workflow. We also describe how the workflow is being used by the P4 community to build research prototypes, and to teach how network systems are built by providing students with hands-on experience working with real hardware.Leverhulme Trust Isaac Newton Trust TBD other

The Higher-Order Prover Leo-II.

Leo-II is an automated theorem prover for classical higher-order logic. The prover has pioneered cooperative higher-order-first-order proof automation, it has influenced the development of the TPTP THF infrastructure for higher-order logic, and it has been applied in a wide array of problems. Leo-II may also be called in proof assistants as an external aid tool to save user effort. For this it is crucial that Leo-II returns proof information in a standardised syntax, so that these proofs can eventually be transformed and verified within proof assistants. Recent progress in this direction is reported for the Isabelle/HOL system.The Leo-II project has been supported by the following grants: EPSRC grant EP/D070511/1 and DFG grants BE/2501 6-1, 8-1 and 9-1.This is the final version of the article. It first appeared from Springer via http://dx.doi.org/10.1007/s10817-015-9348-y

Spectrum of mutational signatures in T-cell lymphoma reveals a key role for UV radiation in cutaneous T-cell lymphoma

Funder: Galderma; doi: http://dx.doi.org/10.13039/501100009754Funder: NIHR-BRC Cambridge core grantFunder: National Institute for Health Research; doi: http://dx.doi.org/10.13039/501100000272Funder: NHS EnglandAbstract: T-cell non-Hodgkin’s lymphomas develop following transformation of tissue resident T-cells. We performed a meta-analysis of whole exome sequencing data from 403 patients with eight subtypes of T-cell non-Hodgkin’s lymphoma to identify mutational signatures and associated recurrent gene mutations. Signature 1, indicative of age-related deamination, was prevalent across all T-cell lymphomas, reflecting the derivation of these malignancies from memory T-cells. Adult T-cell leukemia-lymphoma was specifically associated with signature 17, which was found to correlate with the IRF4 K59R mutation that is exclusive to Adult T-cell leukemia-lymphoma. Signature 7, implicating UV exposure was uniquely identified in cutaneous T-cell lymphoma (CTCL), contributing 52% of the mutational burden in mycosis fungoides and 23% in Sezary syndrome. Importantly this UV signature was observed in CD4 + T-cells isolated from the blood of Sezary syndrome patients suggesting extensive re-circulation of these T-cells through skin and blood. Analysis of non-Hodgkin’s T-cell lymphoma cases submitted to the national 100,000 WGS project confirmed that signature 7 was only identified in CTCL strongly implicating UV radiation in the pathogenesis of cutaneous T-cell lymphoma

Mechanical Verification of Refactorings

In this paper we describe the formal verification of refactorings for untyped and typed lambda-calculi. This verification is performed in the proof assistant Isabelle/HOL. Refactorings are program transformations applied to improve the design of source code. Well-structured source code is easier and cheaper to maintain, and this motivates the use of refactoring. These transformations have been implemented as programmer tools and, as with other metaprogramming tools, it is desirable that implementations of refactorings are correct. For a refactoring to be correct the refactored program must be identical in behaviour to the original program. Since refactorings are source-to-source transformations, concrete program information matters: for example, names (of variables, procedures, etc) and program layout should also be preserved by refactoring. This is a particular characteristic of refactorings since general program transformations operate over machine representations of programs, rather than readable source code. The paper describes the formalisation adopted, and the alternatives explored. It also reflects on some of the difficulties of performing such formalisations, the interaction between refactoring and phases such as type-checking and parsing, and the generation of correct implementations from mechanised proofs

A Certified Refactoring Engine

The paper surveys how software tools such as refactoring systems can be validated, and introduces a new mechanism, namely the extraction of a refactoring engine for a functional programming language from an Isabelle/HOL theory in which it is verified. This research is a first step in a programme to construct certified programming tools from verified theories. We also provide some empirical evidence of how refactoring can be of significant benefit in reshaping automatically-generated program code for use in larger systems

Verification of Refactorings in Isabelle/HOL

Refactorings are source-to-source behaviour-preserving program transformations that are used for improving program structure. Programmers refactor code to adapt it when new functionality is added or when the code is being repaired -- refactoring serves to keep the code ``clean'' and more maintainable. Refactoring can also be used as an exploratory technique for understanding source code. The process of refactoring has been automated through the implementation of tools; these tools assist programmers by handling the consistent application of behaviour-preserving changes to the code. It is desirable that the implementations of refactorings are correct: bugs might otherwise be introduced in refactored programs. The correctness, i.e. behaviour-preservation, of refactoring is traditionally probed by testing the refactored program and not the refactoring implementation directly. Recently, automated testing techniques have been used to test implementations of refactorings directly, but the coverage of testing is partial at best. The verification of refactorings is more challenging but determines whether a refactoring is behaviour-preserving for all possible programs. We study the verification of refactorings using the proof assistant Isabelle/HOL for untyped and typed lambda-calculi. Some of the issues encountered during verification are technical rather than purely theoretical: they relate to the embedding of the programming language in the proof environment. The reasons for our choice of techniques are discussed. We also discuss other practical considerations such as the readability of mechanised refactorings, and the avoidance of computationally expensive refactorings