Marko C. J. D. van Eekelen

Theorem Proving for Functional Programmers

SPARKLE is a new theorem prover written in and specialized for the functional programming language CLEAN. It is mainly intended to be used by programmers for proving properties of parts of programs, combining programming and reasoning into one process. It can also be used by logicians interested in proving properties of larger programs.Two features of SPARKLE are in particular helpful for programmers. Firstly, SPARKLE is integrated in CLEAN and has a semantics based on lazy graph-rewriting. This allows reasoning to take place on the program itself, rather than on a translation that uses different concepts. Secondly, Sparkle supports automated reasoning. Trivial goals will automatically be discarded and suggestions will be given on more difficult goals.This paper presents a small example proof built in SPARKLE. It will be shown that building this proof is easy and requires little effort.

Polynomial Size Analysis of First-Order Shapely Functions

We present a size-aware type system for first-order shapely function definitions. Here, a function definition is called shapely when the size of the result is determined exactly by a polynomial in the sizes of the arguments. Examples of shapely function definitions may be implementations of matrix multiplication and the Cartesian product of two lists. The type system is proved to be sound w.r.t. the operational semantics of the language. The type checking problem is shown to be undecidable in general. We define a natural syntactic restriction such that the type checking becomes decidable, even though size polynomials are not necessarily linear or monotonic. Furthermore, we have shown that the type-inference problem is at least semi-decidable (under this restriction). We have implemented a procedure that combines run-time testing and type-checking to automatically obtain size dependencies. It terminates on total typable function definitions.

Polynomial size analysis of first-order functions

We present a size-aware type system for first-order shapely function definitions. Here, a function definition is called shapely when the size of the result is determined exactly by a polynomial in the sizes of the arguments. Examples of shapely function definitions may be matrix multiplication and the Cartesian product of two lists. The type checking problem for the type system is shown to be undecidable in general. We define a natural syntactic restriction such that the type checking becomes decidable, even though size polynomials are not necessarily linear or monotonic. Furthermore, a method that infers polynomial size dependencies for a non-trivial class of function definitions is suggested.

There and back again: arrows for invertible programming

Invertible programming occurs in the area of data conversion where it is required that the conversion in one direction is the inverse of the other. For that purpose, we introduce bidirectional arrows (bi-arrows). The bi-arrow class is an extension of Haskells arrow class with an extra combinator that changes the direction of computation.The advantage of the use of bi-arrows for invertible programming is the preservation of invertibility properties using the bi-arrow combinators. Programming with bi-arrows in a polytypic or generic way exploits this the most. Besides bidirectional polytypic examples, including invertible serialization, we give the definition of a monadic bi-arrow transformer, which we use to construct a bidirectional parser/pretty printer.

Compositional Model-Views with Generic Graphical User Interfaces

Creating GUI programs is hard even for prototyping purposes. Using the model-view paradigm makes it somewhat simpler since the model-view paradigm dictates that the model contains no GUI programming, as this is done by the views. Still, a lot of GUI programming is needed to implement the views.

Implementing a functional spreadsheet in clean

It has been claimed that recent developments in the research on the efficiency of code generation and on graphical input/output interfacing have made it possible to use a functional language to write efficient programs that can compete with industrial applications written in a traditional imperative language. As one of the early steps in verifying this claim, this paper describes a first attempt to implement a spreadsheet in a lazy, purely functional language. An interesting aspect of the design is that the language with which the user specifies the relations between the cells of the spreadsheet is itself a lazy, purely functional and higher order language as well, and not some special dedicated spreadsheet language. Another interesting aspect of the design is that the spreadsheet incorporates symbolic reduction and normalisation of symbolic expressions (including equations). This introduces the possibility of asking the system to prove equality of symbolic cell expressions: a property which can greatly enhance the reliability of a particular user-defined spreadsheet. The resulting application is by no means a fully mature product. It is not intended as a competitor to commercially available spreadsheets. However, with its higher order lazy functional language and its symbolic capabilities it may serve as an interesting candidate to fill the gap between calculators with purely functional expressions and full-featured spreadsheets with dedicated non-functional spreadsheet languages. This paper describes the global design and important implementation issues in the development of the application. The experience gained and lessons learnt during this project are treated. Performance and use of the resulting application are compared with related work.

Proof tool support for explicit strictness

In programs written in lazy functional languages such as for example Clean and Haskell, the programmer can choose freely whether particular subexpressions will be evaluated lazily (the default) or strictly (must be specified explicitly). It is widely known that this choice affects resource consumption, termination and semantics in several ways. However, functional programmers tend to be less aware of the consequences for logical program properties and formal reasoning. This paper aims to give a better understanding of the concept of explicit strictness and its impact on properties and reasoning. It will be shown that explicit strictness may make reasoning more cumbersome, due to the introduction of additional definedness conditions. Fortunately, these definedness conditions can be handled quite effectively by proof assistants. This paper describes the specific support that is offered by Sparkle for expressing and proving definedness conditions. This support makes reasoning with explicit strictness almost appear like reasoning without explicit strictness. To our knowledge, Sparkle is currently the only proof assistant with such strictness specific support.

Graph Rewriting Semantics for Functional Programming Languages

The lambda calculus forms without any question *the* theoretical backbone of functional programming languages. For the design and implementation of the lazy functional language Concurrent Clean we have used a related computational model: Term Graph Rewriting Systems (TGRSs). This paper wraps up our main conclusions after 10 years of experience with graph rewriting semantics for functional programming languages. TGRSs are not a direct extension of the lambda calculus, so one sometimes has to re-establish known theoretical results. But TGRSs are that much closer to the world of functional programming that its use has been proven to be very worthwhile. In TGRSs functions have names, there are constants, pattern matching and one can choose to either share expressions or copy them.

Specification of reduction strategies in term rewriting systems

There is a growing interest in Term Rewriting Systems (TRSs), which are used as a conceptual basis for new programming languages such as functional languages and algebraic specification languages. TRSs serve as a computational model for (parallel) implementations of these languages. They also form the foundation for a calculus for Graph Rewriting Systems (GRSs). In Rewriting Systems reduction strategies play an important role because they control the actual rewriting process. Strategies determine the order of the rewriting and the rules to apply. Hence they have a great influence on the efficiency and the amount of parallelism in the computation. In ambiguous or non-deterministic TRSs, they even influence the outcome of the computation. Some of the reduction strategies used in TRSs are extremely complex algorithms. Unfortunately, there is no common formal specification method for reduction strategies yet.

Reasoning about deterministic concurrent functional i/o

This paper develops a language for reasoning about concurrent functional I/O. We assume that the API is specified as state-transformers on a single world state. We then prove that under certain conditions evaluation in this language is deterministic, and give some examples. All properties were machine-verified using the Sparkle proof-assistant and using Core-Clean as a meta-language.