Polymorphic Aβ42 fibrils adopt similar secondary structure but differ in cross-strand side chain stacking interactions within the same β-sheet.

Formation of polymorphic amyloid fibrils is a common feature in neurodegenerative diseases involving protein aggregation. In Alzheimer's disease, different fibril structures may be associated with different clinical sub-types. Structural basis of fibril polymorphism is thus important for understanding the role of amyloid fibrils in the pathogenesis and progression of these diseases. Here we studied two types of Aβ42 fibrils prepared under quiescent and agitated conditions. Quiescent Aβ42 fibrils adopt a long and twisted morphology, while agitated fibrils are short and straight, forming large bundles via lateral association. EPR studies of these two types of Aβ42 fibrils show that the secondary structure is similar in both fibril polymorphs. At the same time, agitated Aβ42 fibrils show stronger interactions between spin labels across the full range of the Aβ42 sequence, suggesting a more tightly packed structure. Our data suggest that cross-strand side chain packing interactions within the same β-sheet may play a critical role in the formation of polymorphic fibrils

Data Definitions in the ACL2 Sedan

We present a data definition framework that enables the convenient specification of data types in ACL2s, the ACL2 Sedan. Our primary motivation for developing the data definition framework was pedagogical. We were teaching undergraduate students how to reason about programs using ACL2s and wanted to provide them with an effective method for defining, testing, and reasoning about data types in the context of an untyped theorem prover. Our framework is now routinely used not only for pedagogical purposes, but also by advanced users. Our framework concisely supports common data definition patterns, e.g. list types, map types, and record types. It also provides support for polymorphic functions. A distinguishing feature of our approach is that we maintain both a predicative and an enumerative characterization of data definitions. In this paper we present our data definition framework via a sequence of examples. We give a complete characterization in terms of tau rules of the inclusion/exclusion relations a data definition induces, under suitable restrictions. The data definition framework is a key component of counterexample generation support in ACL2s, but can be independently used in ACL2, and is available as a community book.Comment: In Proceedings ACL2 2014, arXiv:1406.123

Why Just Boogie? Translating Between Intermediate Verification Languages

The verification systems Boogie and Why3 use their respective intermediate languages to generate verification conditions from high-level programs. Since the two systems support different back-end provers (such as Z3 and Alt-Ergo) and are used to encode different high-level languages (such as C# and Java), being able to translate between their intermediate languages would provide a way to reuse one system's features to verify programs meant for the other. This paper describes a translation of Boogie into WhyML (Why3's intermediate language) that preserves semantics, verifiability, and program structure to a large degree. We implemented the translation as a tool and applied it to 194 Boogie-verified programs of various sources and sizes; Why3 verified 83% of the translated programs with the same outcome as Boogie. These results indicate that the translation is often effective and practically applicable

Set-Theoretic Types for Polymorphic Variants

Polymorphic variants are a useful feature of the OCaml language whose current definition and implementation rely on kinding constraints to simulate a subtyping relation via unification. This yields an awkward formalization and results in a type system whose behaviour is in some cases unintuitive and/or unduly restrictive. In this work, we present an alternative formalization of poly-morphic variants, based on set-theoretic types and subtyping, that yields a cleaner and more streamlined system. Our formalization is more expressive than the current one (it types more programs while preserving type safety), it can internalize some meta-theoretic properties, and it removes some pathological cases of the current implementation resulting in a more intuitive and, thus, predictable type system. More generally, this work shows how to add full-fledged union types to functional languages of the ML family that usually rely on the Hindley-Milner type system. As an aside, our system also improves the theory of semantic subtyping, notably by proving completeness for the type reconstruction algorithm.Comment: ACM SIGPLAN International Conference on Functional Programming, Sep 2016, Nara, Japan. ICFP 16, 21st ACM SIGPLAN International Conference on Functional Programming, 201

Practical Theory Extension in Event-B

Abstract. The Rodin tool for Event-B supports formal modelling and proof using a mathematical language that is based on predicate logic and set theory. Although Rodin has in-built support for a rich set of operators and proof rules, for some application areas there may be a need to extend the set of operators and proof rules supported by the tool. This paper outlines a new feature of the Rodin tool, the theory component, that allows users to extend the mathematical language supported by the tool. Using theories, Rodin users may define new data types and polymorphic operators in a systematic and practical way. Theories also allow users to extend the proof capabilities of Rodin by defining new proof rules that get incorporated into the proof mechanisms. Soundness of new definitions and rules is provided through validity proof obligations.

Lecture Notes on Formal Program Development

This document was originally produced as lecture notes for the MSc and PG course ``Formal Program Development'' early in 1997. After some initial general considerations on this subject the paper focusses on the way one can use Extended ML (EML) for formal program development, which features EML contains and why, and which pitfalls one has to avoid when formally developing ML programs. Usage, features, and pitfalls are all presented through examples