Semantics of Typed Lambda-Calculus with Constructors

Petit, Barbara

doi:10.2168/lmcs-7(1:2)2011

Cited by 9 publications

(6 citation statements)

References 14 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…On pure relational programming (without λ-abstractions), recently Rozhplokas et al [27] have studied the operational and denotational semantics of miniKanren. On λ-calculi with patterns (without full unification), there have been many different approaches to their formulation [16,2,17,25,3]. On λ-calculi with non-deterministic choice (without unification), we should mention works on the λ-calculus extended with erratic [28] as well as with probabilistic choice [26,9].…”

Section: Discussionmentioning

confidence: 99%

Semantics of a Relational λ-Calculus (Extended Version)

Barenbaum,

Lochbaum,

Milicich

2020

Preprint

View full text Add to dashboard Cite

We extend the λ-calculus with constructs suitable for relational and functional-logic programming: non-deterministic choice, fresh variable introduction, and unification of expressions. In order to be able to unify λ-expressions and still obtain a confluent theory, we depart from related approaches, such as λProlog, in that we do not attempt to solve higher-order unification. Instead, abstractions are decorated with a location, which intuitively may be understood as its memory address, and we impose a simple coherence invariant: abstractions in the same location must be equal. This allows us to formulate a confluent small-step operational semantics which only performs first-order unification and does not require strong evaluation (below lambdas). We study a simply typed version of the system. Moreover, a denotational semantics for the calculus is proposed and reduction is shown to be sound with respect to the denotational semantics.

show abstract

Section: Discussionmentioning

confidence: 99%

Semantics of a Relational λ-Calculus (Extended Version)

Barenbaum,

Lochbaum,

Milicich

2020

Preprint

View full text Add to dashboard Cite

show abstract

“…In the following contents, we represent other arguments by the wildcard " * " and by the symbol {| * ⟼ * |} . 𝐸 is the syntax of constructor pattern matching of the 𝜆-expression 𝐸 [23]. To avoid ambiguity in the following discussion of FEther, the functions represent the programs and functions written in Gallina, and RWprogram represents the real-world programs written in general-purpose programing languages.…”

Section: Lolisamentioning

confidence: 99%

FEther: An Extensible Definitional Interpreter for Smart-Contract Verifications in Coq

Yang

Lei

2019

IEEE Access

View full text Add to dashboard Cite

Recently, blockchain technology, which adds records to a list using cryptographic links, has been widely applied in the financial field. Therefore, the security of blockchain smart contracts is among the most popular contemporary research topics. To improve the theorem-proving technology in this field, we are developing an extensible hybrid verification tool chain, denoted as FSPVM-E, for Ethereum smart contract verification. This hybrid system extends the Coq proof assistant, a formal proof-management system. Combining symbolic execution with higher-order theorem-proving, it solves consistency, automation, and reusability problems by standard theorem-proving approaches. This article completes the FSPVM-E by developing its proof engine. FSPVM-E is an extensible definitional interpreter based on our previous work FEther, which is totally developed in the Coq proof assistant. It supports almost all semantics of the Solidity programing language, and simultaneously executes multiple types of symbols. FEther also contains a set of automatic strategies that execute and verify the smart contracts in Coq with a high level of automation. The functional correctness of FEther was verified in Coq. The execution efficiency of FEther far exceeded that of the interpreters which are developed in Coq in accordance with the standard tutorial. To our knowledge, FEther is the first definitional interpreter of the Solidity language in Coq.Blockchain technology [1], which adds records to a list using cryptographic links, is among the most popular contemporary technologies. Ethereum is a widely adopted blockchain system that implements a general-purpose, Turing-complete programing language called Solidity [2]. Ethereum enables the development of arbitrary smart contracts that can automate blockchain transactions in a virtual runtime environment, namely, the Ethereum Virtual Machine (EVM). Here smart contracts refer to the applications and scripts (i.e., programs) that execute the blockchain. The growing use of smart contracts has necessitated increased scrutiny of their security. Smart contracts can include particular properties (i.e., bugs) that expose them to deliberate attacks causing direct economic loss. Some of the largest attacks on smart contracts are well known, such as the attacks on decentralized autonomous organizations [3] and parity wallet contracts [4]. Many classes of subtle bugs, ranging from transaction-ordering dependencies to mishandled exceptions, exist in smart contracts [5]. Therefore, the security and reliability of smart-contract programs must be verified as rigorously as possible. The properties of programs can be rigorously verified by proving higher-order logic theorems. In the standard approach, a formal model for the target software system is manually abstracted using higher-order theorem-proving assistants. Such formal verification technology provides sufficient freedom and flexibility for designing formal models based on higher-order logic theories, and can abstract and express very complex systems. Howe...

show abstract

“…In the second case, x in the pattern is required to be Nat yet the type of the argument to vl in vl true is Bool. This is avoided by introducing type application [24] into types: vl x is assigned a type of the form vl @ Nat while vl true is assigned type vl @ Bool; these are then compared. Consider next the pattern x y of upd.…”

Section: Preliminaries On Typing Patterns Expressing Path Polymorphismmentioning

confidence: 99%

“…, c n → s n } · t in which certain occurrences of the constructors c i in t are replaced by their corresponding terms. [24] studies typing to ensure that these constructor substitutions never block on a constant not in their domain. Recursive types are not considered (nor is path polymorphism).…”

Section: Related Workmentioning

confidence: 99%

Type Soundness for Path Polymorphism

Viso

Bonelli

Ayala-Rincón

2016

Electronic Notes in Theoretical Computer Science

View full text Add to dashboard Cite

Path polymorphism is the ability to define functions that can operate uniformly over arbitrary recursively specified data structures. Its essence is captured by patterns of the form x y which decompose a compound data structure into its parts. Typing these kinds of patterns is challenging since the type of a compound should determine the type of its components. We propose a static type system (i.e. no run-time analysis) for a pattern calculus that captures this feature. Our solution combines type application, constants as types, union types and recursive types. We address the fundamental properties of Subject Reduction and Progress that guarantee a well-behaved dynamics. Both these results rely crucially on a notion of pattern compatibility and also on a coinductive characterisation of subtyping.

show abstract

Semantics of Typed Lambda-Calculus with Constructors

Cited by 9 publications

References 14 publications

Semantics of a Relational λ-Calculus (Extended Version)

Semantics of a Relational λ-Calculus (Extended Version)

FEther: An Extensible Definitional Interpreter for Smart-Contract Verifications in Coq

Type Soundness for Path Polymorphism

Contact Info

Product

Resources

About