scholarly journals Secure System Composition and Type Checking using Cryptographic Proofs

2021 ◽  
Author(s):  
Daniel Barrack
Keyword(s):  
Type Checking ◽  
System Composition

SHS in the Si–CO2 System: Composition/Structure of Combustion Products

2020 ◽  
Vol 29 (3) ◽  
pp. 138-142
Author(s):  
T. V. Barinova ◽  
V. Yu. Barinov ◽  
V. N. Semenova ◽  
I. D. Kovalev
Keyword(s):  
Combustion Products ◽  
System Composition ◽  
Composition Structure

scholarly journals Coq Coq correct! verification of type checking and erasure for Coq, in Coq

2020 ◽  
Vol 4 (POPL) ◽  
pp. 1-28 ◽  
Author(s):  
Matthieu Sozeau ◽  
Simon Boulier ◽  
Yannick Forster ◽  
Nicolas Tabareau ◽  
Théo Winterhalter
Keyword(s):  
Type Checking

A Lightweight Formalism for Reference Lifetimes and Borrowing in Rust

2021 ◽  
Vol 43 (1) ◽  
pp. 1-73
Author(s):  
David J. Pearce
Keyword(s):  
Memory Management ◽  
Programming Model ◽  
Type System ◽  
Control Flow ◽  
Two Phase ◽  
Type Checking ◽  
Strong Focus ◽  
Reference Implementation ◽  
Two Phases ◽  
Complex Features

Rust is a relatively new programming language that has gained significant traction since its v1.0 release in 2015. Rust aims to be a systems language that competes with C/C++. A claimed advantage of Rust is a strong focus on memory safety without garbage collection. This is primarily achieved through two concepts, namely, reference lifetimes and borrowing . Both of these are well-known ideas stemming from the literature on region-based memory management and linearity / uniqueness . Rust brings both of these ideas together to form a coherent programming model. Furthermore, Rust has a strong focus on stack-allocated data and, like C/C++ but unlike Java, permits references to local variables. Type checking in Rust can be viewed as a two-phase process: First, a traditional type checker operates in a flow-insensitive fashion; second, a borrow checker enforces an ownership invariant using a flow-sensitive analysis. In this article, we present a lightweight formalism that captures these two phases using a flow-sensitive type system that enforces “ type and borrow safety .” In particular, programs that are type and borrow safe will not attempt to dereference dangling pointers. Our calculus core captures many aspects of Rust, including copy- and move-semantics, mutable borrowing, reborrowing, partial moves, and lifetimes. In particular, it remains sufficiently lightweight to be easily digested and understood and, we argue, still captures the salient aspects of reference lifetimes and borrowing. Furthermore, extensions to the core can easily add more complex features (e.g., control-flow, tuples, method invocation). We provide a soundness proof to verify our key claims of the calculus. We also provide a reference implementation in Java with which we have model checked our calculus using over 500B input programs. We have also fuzz tested the Rust compiler using our calculus against 2B programs and, to date, found one confirmed compiler bug and several other possible issues.

scholarly journals Making legacy Fortran code type safe through automated program transformation

2021 ◽  
Author(s):  
Wim Vanderbauwhede
Keyword(s):  
Side Effect ◽  
Program Transformation ◽  
The Novel ◽  
Formal Approach ◽  
Type Checking ◽  
Type Safety ◽  
Fortran Code ◽  
Fortran 90 ◽  
Code Type ◽  
Fortran 77

AbstractFortran is still widely used in scientific computing, and a very large corpus of legacy as well as new code is written in FORTRAN 77. In general this code is not type safe, so that incorrect programs can compile without errors. In this paper, we present a formal approach to ensure type safety of legacy Fortran code through automated program transformation. The objective of this work is to reduce programming errors by guaranteeing type safety. We present the first rigorous analysis of the type safety of FORTRAN 77 and the novel program transformation and type checking algorithms required to convert FORTRAN 77 subroutines and functions into pure, side-effect free subroutines and functions in Fortran 90. We have implemented these algorithms in a source-to-source compiler which type checks and automatically transforms the legacy code. We show that the resulting code is type safe and that the pure, side-effect free and referentially transparent subroutines can readily be offloaded to accelerators.

Cubical Agda: A dependently typed programming language with univalence and higher inductive types

2021 ◽  
Vol 31 ◽  
Author(s):  
ANDREA VEZZOSI ◽  
ANDERS MÖRTBERG ◽  
ANDREAS ABEL
Keyword(s):  
Programming Language ◽  
Type Theory ◽  
Type Checking ◽  
Dependent Type Theory ◽  
Wide Range ◽  
General Schema ◽  
Direct Definition ◽  
Inductive Types ◽  
Definition Of ◽  
Cubical Type Theory

Abstract Proof assistants based on dependent type theory provide expressive languages for both programming and proving within the same system. However, all of the major implementations lack powerful extensionality principles for reasoning about equality, such as function and propositional extensionality. These principles are typically added axiomatically which disrupts the constructive properties of these systems. Cubical type theory provides a solution by giving computational meaning to Homotopy Type Theory and Univalent Foundations, in particular to the univalence axiom and higher inductive types (HITs). This paper describes an extension of the dependently typed functional programming language Agda with cubical primitives, making it into a full-blown proof assistant with native support for univalence and a general schema of HITs. These new primitives allow the direct definition of function and propositional extensionality as well as quotient types, all with computational content. Additionally, thanks also to copatterns, bisimilarity is equivalent to equality for coinductive types. The adoption of cubical type theory extends Agda with support for a wide range of extensionality principles, without sacrificing type checking and constructivity.

Sign in / Sign up

Export Citation Format

Share Document