Arjen van Weelden

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.

On-the-Fly Formal Testing of a Smart Card Applet

This paper presents a case study on the use of formal methods in specification-based, black-box testing of a smart card applet. The system under test is a simple electronic purse application running on a Java Card platform. The specification of the applet is given as a Statechart model, and transformed into a functional form to serve as the input for the on-the-fly test generation, -execution, and -analysis tool GAST. We show that automated, formal, specification-based testing of smart card applets is of high value, and that errors can be detected using this model-based testing.

Automatic Generation of Editors for Higher-Order Data Structures

With generic functional programming techniques, we have eased GUI programming by constructing a programming toolkit with which one can create GUIs in an abstract and compositional way, using type-directed Graphical Editor Components (GECs). In this toolkit, the programmer specifies a GUI by means of a data model instead of low-level GUI programming. In earlier versions of this toolkit, the data model must have a first-order type. In this paper we show that the programming toolkit can be extended in two ways, such that the data model can contain higher-order data structures. We added support for dynamic polymorphic higher-order editors using the functional shell Esther. By combining the earlier developed techniques of generic GECs, abstract editors, we also added statically typed higher-order editors. In principle this solution extends our GUI programming toolkit with the full expressive power of functional programming languages.

Towards a strongly typed functional operating system

In this paper, we present Famke. It is a prototype implementation of a strongly typed operating system written in Clean. Famke enables the creation and management of independent distributed Clean processes on a network of workstations. It uses Cleans dynamic type system and its dynamic linker to communicate values of any type, e.g. data, closures, and functions (i.e. compiled code), between running applications in a type safe way. Mobile processes can be implemented using Famkes ability to communicate functions. We have built an interactive shell on top of Famke that enables user interaction. The shell uses a functional-style command language that allows construction of new processes, and it type checks the command line before executing it. Famkes type safe run-time extensibility makes it a strongly typed operating system that can be tailored to a given situation.

A functional shell that operates on typed and compiled applications

Esther is the interactive shell of Famke, a prototype implementation of a strongly typed operating system written in the functional programming language Clean. As usual, the shell can be used for manipulating files, applications, data and processes at the command line. A special feature of Esther is that the shell language provides the basic functionality of a strongly typed lazy functional language, at the command line. The shell type checks each command line and only executes well-typed expressions. Files are typed as well, and applications are simply files with a function type. The type checking/inferencing performed by the shell is actually performed by the hybrid static/dynamic type system of Clean. The shell behaves like an interpreter, but it actually executes a command line by combining existing compiled code of functions/programs on disk. Clean’s dynamic linker is used to store (and retrieve) any expression (both data and code) with its type on disk. This linker is also used to communicate values of any type, e.g., data, closures, and functions (i.e., compiled code), between running applications in a type safe way. The shell combines the advantages of interpreters (direct response) and compilers (statically typed, fast code). Applications (compiled functions) can be used, in a type safe way, in the shell, and functions defined in the shell can be used by any compiled application.

A functional shell that dynamically combines compiled code

We present a new shell that provides the full basic functionality of a strongly typed lazy functional language, including overloading. The shell can be used for manipulating files, applications, data and processes at the command line. The shell does type checking and only executes well-typed expressions. Files are typed, and applications are simply files with a function type. The shell executes a command line by combining existing code of functions on disk. We use the hybrid static/dynamic type system of Clean to do type checking/inference. Its dynamic linker is used to store and retrieve any expression (both data and code) with its type on disk. Our shell combines the advantages of interpreters (direct response) and compilers (statically typed, fast code). Applications (compiled functions) can be used, in a type safe way, in the shell, and functions defined in the shell can be used by any compiled application.

Efficient and Type-Safe Generic Data Storage

In this paper we present an elegant method for sequentializing arbitrary data using the generic language extension of the functional programming language Clean. We show how the proposed operations can be used to store values of any concrete data type in several kinds of IO containers (such as files or arrays of characters), and how to manipulate stored data efficiently. Moreover, by extending stored data with encoded type information, data manipulation will be type-safe. Defining these operations generically has the advantage that specific instances for user defined data types can be generated fully automatically. Compared to traditional sequentialization methods (or to common data manipulation, using relational data bases) our operations are an order of magnitude faster.

Polytypic syntax tree operations

Polytypic functional programming has the advantage that it can derive code for generic functions automatically. However, it is not clear whether it is useful for anything other than the textbook examples, and the generated polytypic code is usually too slow for real-life programs. As a real-life test, we derive a polytypic parser for the Haskell 98 syntax and look into other front-end compiler syntax tree operations. We present a types–as–grammar approach, which uses polytypic programming (in both Generic Haskell and Clean) to automatically derive the code for a parser based on the syntax tree type, without using external tools. Moreover, we show that using polytypic programming can even be useful for data–specific syntax tree operations in a (functional) compiler, such as scope checking and type inference. Simple speed tests show that the performance of polytypic parsers can be abominable for real-life inputs. However, we show that much performance can be recovered by applying (extended) fusion optimization on the generated code. We actually have a derived parser whose speed is close to one generated by a specialized Haskell parser generator.

GEC: a toolkit for generic rapid prototyping of type safe interactive applications

Programming GUIs with conventional GUI APIs is notoriously tedious. In these notes we present the GEC toolkit in which the programmer can create user interfaces without any knowledge of low-level I/O handling. Instead, he works with Graphical Editor Components (GEC). A GEC is an interactive component that is automatically derived from an arbitrary monomorphic data type, including higher order types. It contains a value of that data type, visualizes it, and allows the user to manipulate it in a type-safe way. The toolkit has a library of data types that represent standard GUI elements such as buttons, text fields, and so on. As a consequence, the programmer works with data types that model the interactive system that he is interested in. Programs are constructed as a collection of communicating GECs. This communication can be arranged in an ad-hoc way, or in a disciplined way, using a combinator library based on arrows. GECs are suitable for rapid prototyping of real world applications, for teaching and for debugging. These notes focus on the use of the GEC toolkit for functional programmers, only briefly explaining its inner workings and underlying principles.