Abstract. We use a code generator—type-directed partial evaluation— to verify conversions between isomorphic types, or more precisely to verify that a composite function is the identity function at some complicated type. A typed functional language such as ML provides a natural support to express the functions and type-directed partial evaluation provides a convenient setting to obtain the normal form of their composition. However, off-the-shelf type-directed partial evaluation turns out to yield gigantic normal forms. We identify that this gigantism is due to redundancies, and that these redundancies originate in the handling of sums, which uses delimited continuations. We successfully eliminate these redundancies by extending type-directed partial evaluation with memoization capabilities. The result only works for pure functional programs, but it provides an unexpected use of code generation and it yields orders-of-magnitude improvements both in time and in space for type isomorphisms. 1

We extend normalization by evaluation ( rst presented in [5]) from the pure typed-calculus to general higher type term rewriting systems. We distinguish between computational rules and proper rewrite rules, and de ne a domain theoretic model intended to explain why normalization by evaluation for the former is much more e cient. Normalization by evaluation is proved to be correct w.r.t. this model. 1

We present a systematic construction of a reduction-free normalization function. Starting from

Abstract not found

A purely syntactic and untyped variant of Normalization by Evaluation for the -calculus is presented in the framework of a two-level -calculus with rewrite rules to model the inverse of the evaluation functional. Among its operational properties gures a standardization theorem that formally establishes adequacy of implementation in functional programming languages. An example implementation in Haskell is provided. The relation to usual type-directed Normalization by Evaluation is highlighted, using a short analysis of -expansion that leads to a perspicuous strong normalization and conuence proof for "-reduction as a byproduct.

Type-directed partial evaluation was originally implemented in Scheme, a dynamically typed language. It has also been implemented in ML, a statically Hindley-Milner typed language. This note shows how the latter implementation can be derived from the former through a functional representation of inductively dened types. 1 Introduction Type-directed partial evaluation is an approach to specializing a term written in a higher-order language. Such a higher-order term is specialized by normalizing it with respect to its type. Normalization is done by eta-expanding the term in a two-level lambda-calculus and statically betareducing the expanded term. The two stages | eta-expansion and beta-reduction | share an intermediate result: a two-level term. We consider two versions of the type-directed partial evaluation algorithm: (i) If the two-level term is represented as a value of an inductively dened data type then the algorithm can be implemented in any (Turing complete) language. In thi...

Abstract. In these lectures we will introduce an interactive system that supports writing simple functional programs. Using this system, students learning functional programming: – develop their programs incrementally, – receive feedback about whether or not they are on the right track, – can ask for a hint when they are stuck, – see how a complete program is stepwise constructed, – get suggestions about how to refactor their program. The system itself is implemented as a functional program, and uses fundamental concepts such as rewriting, parsing, strategies, program transformations and higher-order combinators such as the fold. We will introduce these concepts, and show how they are used in the implementation of the interactive functional programming tutor. 1

pport. Contents 1 Introduction and Overview 1 2 Types for Proofs 2 2.1 Formal Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1.1 What is a Formal System? . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1.2 The Origins of Formal Systems . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1.3 Formal Systems in Computer Science . . . . . . . . . . . . . . . . . . . . . 3 2.2 Theorem Proving: Making Formal Systems Usable . . . . . . . . . . . . . . . . . . 4 2.2.1 Objectives of Interactive Theorem Proving . . . . . . . . . . . . . . . . . . 4 2.2.2 How to Ensure Correctness . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.3 How to Facilitate Denitions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.4 How to Facilitate Reasoning . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Reasoning in Higher-Order Logic (HOL) . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.1 Church's Si

Abstract not found