Maarten de Mol

Modelling and analysis using GROOVE

In this paper we present case studies that describe how the graph transformation tool groove has been used to model problems from a wide variety of domains. These case studies highlight the wide applicability of groove in particular, and of graph transformation in general. They also give concrete templates for using groove in practice. Furthermore, we use the case studies to analyse the main strong and weak points of groove.

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.

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.

Proving Properties of Lazy Functional Programs with Sparkle

This tutorial paper aims to provide the necessary expertise for working with the proof assistant Sparkle , which is dedicated to the lazy functional programming language Clean . The purpose of a proof assistant is to use formal reasoning to verify the correctness of a computer program. Formal reasoning is very powerful, but is unfortunately also difficult to carry out. Due to their mathematical nature, functional programming languages are well suited for formal reasoning. Moreover, Sparkle offers specialized support for reasoning about Clean , and is integrated into its official development environment. These factors make Sparkle a proof assistant that is relatively easy to use. This paper provides both theoretical background for formal reasoning, and detailed information about using Sparkle in practice. Special attention will be given to specific aspects that arise due to lazy evaluation and due to the existence of strictness annotations. Several assignments are included in the text, which provide hands-on experience with Sparkle .

Graph transforming java data

This paper introduces an approach for adding graph transformation-based functionality to existing Java programs. The approach relies on a set of annotations to identify the intended graph structure, as well as on user methods to manipulate that structure, within the users own Java class declarations. Other ingredients are a custom transformation language, called Chart, and a compiler from Chart to Java. The generated Java code runs against the pre-existing, annotated code. The advantage of the approach is that it allows any Java program to be enhanced, non invasively, with declarative graph rules, improving clarity, conciseness and verifiability.

EditorArrow: An arrow-based model for editor-based programming

State-based interactive applications, whether they run on the desktop or as a web application, can be considered as collections of interconnected editors of structured values that allow users to manipulate data. This is the view that is advocated by the GEC and iData toolkits, which offer a high level of abstraction to programming desktop and web GUI applications respectively. Special features of these toolkits are that editors have shared, persistent state, and that they handle events individually. In this paper we cast these toolkits within the Arrow framework and present EditorArrow: a single, unified semantic model that defines shared state and event handling. We study the properties of EditorArrow, and of editors in particular. Furthermore, we present the definedness properties of the combinators. A reference implementation of the EditorArrow model is given with some small program examples. We discuss formal reasoning about the model using the proof assistant Sparkle. The availability of this tool has proved to be indispensable in this endeavor.

On A Graph Formalism for Ordered Edges

Though graphs are flexible enough to model any kind of data structure in principle, for some structures this results in a rather large overhead. This is for instance true for lists, i.e., edges that are meant to point to an ordered collection of nodes. Such structures are frequently encountered, for instance as ordered associations in UML diagrams. Several options exist to model lists using standard graphs, but all of them need auxiliary structure, and even so their manipulation in graph transformation rules is not trivial. In this paper we propose to enrich graphs with special ordered edges, which more naturally represent the intended structure, and define how lists can be manipulated. We show that the resulting category satisfies sufficient HLR properties to apply standard algebraic graph transformation. We believe that in a context where lists are common, the cost of a more complicated graph formalism is outweighed by the benefit of a smaller, more appropriate model and more straightforward manipulation.

A Single-Step Term-Graph Reduction System for Proof Assistants

In this paper, we will define a custom term-graph reduction system for a simplified lazy functional language. Our custom system is geared towards flexibility , which is accomplished by leaving the choice of redex free and by making use of single-step reduction. It is therefore more suited for formal reasoning than the well-established standard reduction systems, which usually fix a single redex and realize multi-step reduction only. We will show that our custom system is correct with respect to the standard systems, by proving that it is confluent and allows standard lazy functional evaluation as a possible reduction path. Our reduction system is used in the foundation of Sparkle . Sparkle is the dedicated proof assistant for Clean , a lazy functional programming language based on term-graph rewriting. An important reasoning step in Sparkle is the replacement of an expression with one of its reducts. The flexibility of our underlying reduction mechanism ensures that as many reduction options as possible are available for this reasoning step, which improves the ease of reasoning. Because our reduction system is based on a simplified lazy functional language, our results can be applied to any other functional language based on term-graph rewriting as well.

A Proof Tool Dedicated to Clean

Theorem proving for functional programming languages can be made much easier by the availability of a dedicated theorem prover. A theorem prover is dedicated to a specific programming language when it fully supports the syntax and semantics of the language and offers specialized proving support for it. Using a dedicated theorem prover is easy, because one can reason about a developed program without having to translate it. However, no suited dedicated theorem prover for a functional language exists yet. This paper describes a simple prototype of a dedicated theorem prover for the functional language Clean. A description of the possibilities of the prototype is given and an examination is made of the work that needs to be done to extend the prototype to a fully operational and truly useful programming tool. Also example proofs of some basic properties and of a graph transformation are given.

Beautiful Code, Beautiful Proof?

Functional programming languages are often praised for creating the capability of writing beautiful code. Furthermore, an often mentioned advantage is that it is easy to reason about properties of functional programs. Such reasoning can be either formal or informal. This might lead to the assumption that really beautiful code is also really easy to prove. One might even say that beautiful code can only be classified as really beautiful if the code also has a beautiful proof. This essay explores whether beautiful code written in a functional programming language also has a beautiful proof. Two small case studies discuss both the beauty of an informal mathematical proof and the beauty of a formal proof created in a dedicated theorem prover. General lessons are drawn from these studies and directions for future research directions are given. This essay is written on the occasion of the celebration of the 61 th anniversary of Rinus Plasmeijer, coinciding with the 25 th IFL conference, held in Nijmegen. Rinus was one of the supervisors of both the Ph.D. Thesis of Marko van Eekelen and the Thesis of Maarten de Mol. The authors of this essay co-authored many functional programming papers with him both on the design and application of the functional programming language Clean and on its dedicated theorem prover Sparkle. We are most grateful for his enthusiastic guidance and for the many hours of warm, creative and productive collaboration.