Scrap your boilerplate with XPath-like combinators

Programmable Rewriting Strategies in Haskell: — White Paper —

The last decade has seen a number of approaches to data-type-generic programming: PolyP, Functorial ML, 'Scrap Your Boiler-plate', Generic Haskell, 'Generics for the Masses', and so on. The approaches vary in sophistication and target audience: some propose full-blown programming languages, some suggest libraries, some can be seen as categorical programming methods. In these lecture notes we compare the various approaches to datatype-generic programming in Haskell. We introduce each approach by means of example, and we evaluate it along different dimensions (expressivity, ease of use, and so on).

A generic functional program is one which is parameterised by datatype. By installing specific choices, for example lists or trees, different programs are obtained that are, nevertheless, abstractly the same. The purpose of this paper is to explore the possibility of deriving generic programs. Part of the theory of lists that deals with segments is recast as a theory about ‘segments’ in a wide class of datatypes, and then used to pose and solve a generic version of a well-known problem.

Programming errors in traversal programs over structured data

Many important tasks and algorithms in computer science build on sorted trees. Typical examples are the translation of programs represented by syntax trees or the processing of (recursive) data structures following some XML schema. In purely functional programming, sorted trees are usually implemented by terms of recursive data types such that a term represents a tree node and the subterms represent its children. The drawback of this representation is that the context of a tree node is not accessible and has to be managed by different means, e.g., by additional arguments of the functions working on the tree.In this paper, we present a pattern for the realization of sorted trees that overcomes this drawback. The technique is fully declarative. In contrast to competing patterns for trees such as Zippers, it supports pattern matching on the tree data structure. Functions on tree nodes can be used to express the decoration of trees by attribute values in a flexible way. In particular, links between tree nodes can easily be defined and attributions can be modularized into phases with clear interfaces. Techniques adapted from the “Scrap your boilerplate” approach allow for the high-level specification of contextual constraints. We show how our approach can be realized in Haskell and discuss tool support.KeywordsType ClassTree NodeTree RepresentationFunctional ProgrammingSyntax TreeThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Datatype-generic programming is defining functions that depend on the structure, or shape, of datatypes. It has been around for more than 10 years, and a lot of progress has been made, in particular in the lazy functional programming language Haskell. There are morethan 10 proposals for generic programming libraries orlanguage extensions for Haskell. To compare and characterise the many generic programming libraries in atyped functional language, we introduce a set of criteria and develop a generic programming benchmark: a set of characteristic examples testing various facets of datatype-generic programming. We have implemented the benchmark for nine existing Haskell generic programming libraries and present the evaluation of the libraries. The comparison is useful for reaching a common standard for generic programming, but also for a programmer who has to choose a particular approach for datatype-generic programming.

The generic programming approach is popular in functional languages (for example, OCaml, Haskell). In essence, it is a compile-time generation of code that performs transformations of user-defined data types. The generated code can carry out various kinds of transformations of the values. Usually, transformations are represented as functions that implement algorithms of transformation. New transformations could be built from these transformation functions and user-defined ones. The representation based on functions has a downside: functions behave as final representations, and hence it is not possible to modify the behavior of the already built function. If the current set of transformations does not suit well, software developers are obliged to write a completely distinct transformation, even in the case when the new transformation is almost identical to the existing one. This work proposes to build transformations that are extensible after construction. The object-oriented programming paradigm will be followed, transformations will be represented not as functions but as objects. Instead of calling a transformation function, one of the object’s methods will be called. The transformation itself will be split into methods. The extensibility is supported by adding new methods and overriding existing ones. In this paper, the authors propose an approach to represent transformations as objects in the OCaml functional programming language. Every alternative in data type definition has a corresponding object method. This design allows the construction of many distinct transformations. The cases where too many methods are not desirable are also discussed. The method is applicable to represent extensible transformations for polymorphic variant data types in OCaml when other methods fail to do it. The method is not bound to any particular domain. It allows the creation of extensible transformations in OCaml. It could be ported to other functional languages supporting object-oriented programming.

Algebraic data types are the natural target of pattern-matching functions. When the type is parametric then the pattern-matching functions typically support parametric polymorphism. In addition, bondi supports generic functional programming by introducing a small family of primitive, or representing data types, which can be used to define generic functions such as map, with one case for each primitive constructor. Each resulting case has a different type, so type specialisation is involved, too. During a type declaration, additional cases can be added to existing functions.

A two-level data transformation consists of a type-level transformation of a data format coupled with value-level transformations of data instances corresponding to that format. Examples of two-level data transformations include XML schema evolution coupled with document migration, and data mappings used for interoperability and persistence. We provide a formal treatment of two-level data transformations that is type-safe in the sense that the well-formedness of the value-level transformations with respect to the type-level transformation is guarded by a strong type system. We rely on various techniques for generic functional programming to implement the formalization in Haskell. The formalization addresses various two-level transformation scenarios, covering fully automated as well as user-driven transformations, and allowing transformations that are information-preserving or not. In each case, two-level transformations are disciplined by one-step transformation rules and type-level transformations induce value-level transformations. We demonstrate an example hierarchical-relational mapping and subsequent migration of relational data induced by hierarchical format evolution.

In his 1977 ACM Turing Award Lecture, John Backus identified the word-at-a-time style of programming, inherited from the underlying hardware and dubbed the "von Neumann bottleneck", as a major obstacle to the advancement of programming. In this keynote, I argue that the functional programming he advocated introduced its own bottleneck: that everything produced by a computation (including nothing) must be encoded as a single value. This "obligation to singularity" is foreign to modelling, where single values sit collegially between no values and two values. Exploring diverse examples, I will argue that adopting a modelling (de facto: relational) style of programming eliminates the functional bottleneck, and with it many of the data-to-control flow escapes that Backus originally sought to avoid.

If you look at the examples and exercises presented so far in this book you can see that we fluctuate between two styles of programming: [statement1] // do something [statement2] // do something [statement3] // do something …

We address the tension between software generality and performance in the domain of simulations based on Monte-Carlo methods. We simultaneously achieve generality and high performance by a novel development methodology and software architecture centred around the concept of a specialising simulator generator. Our approach combines and extends methods from functional programming, generative programming, partial evaluation, and runtime code generation. We also show how to generate parallelised simulators. We evaluated our approach by implementing a simulator for advanced forms of polymerisation kinetics. We achieved unprecedented performance, making Monte-Carlo methods practically useful in an area that was previously dominated by deterministic PDE solvers. This is of high practical relevance, as Monte-Carlo simulations can provide detailed microscopic information that cannot be obtained with deterministic solvers.

A new declarative programming paradigm, constraint functional logic programming (CFLP) is presented, which unifies systematically all features of constraint, functional and logic programming. CFLP extends constraint functional programming (CFP), which supports equation solving over a functional program, to general constraint programming permitting the use of constraints for programming as well as for posing queries. It also generalises constraint logic programming (CLP), by admitting user-defined functions as a purely functional subsystem of a CLP language. This paper presents the motivation for designing CFLP and its semantics. Programming examples are given in the concrete CFLP language Falcon.KeywordsLogic ProgramLogic ProgrammingConstraint ProgrammingConstraint SystemFunctional ProgrammingThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

In these lecture notes we present the iTasks system: a set of combinators to specify work flows in a pure functional language at a very high level of abstraction. Work flow systems are automated systems in which tasks are coordinated that have to be executed by either humans or computers. The combinators that we propose support work flow patterns commonly found in commercial work flow systems. In addition, we introduce novel work flow patterns that capture real world requirements, but that can not be dealt with by current systems. Compared with most of these commercial systems, the iTasks system offers several further advantages: tasks are statically typed, tasks can be higher order, the combinators are fully compositional, dynamic and recursive work flows can be specified, and last but not least, the specification is used to generate an executable web-based multi-user work flow application. With the iTasks system, useful work flows can be defined which cannot be expressed in other systems: a work can be interrupted and subsequently directed to other workers for further processing. The iTasks system has been constructed in the programming language Clean, making use of its generic programming facilities, and its iData toolkit with which interactive, thin-client, form-based web applications can be created. In all, iTasks are an excellent case of the expressive power of functional and generic programming.

This research aims to fully integrate logic programming into the programming language Scheme. We use a minimalist approach, based on the observation that the fundamental aspects of logic programming, nondeterminism and unification, are separable both in concept and in implementation. We have found that only two new primitive functions and one new special form need to be added to Scheme to achieve this integration. Using these primitives, we can write programs in the style of Scheme, Icon, Prolog, or any mixture thereof. We have found that a style of programming that uses both logical and functional techniques can be more powerful than the use of either technique alone. Because Scheme has side effects and continuations, this research addresses different problems and choices than previous research [2, 16, 19] on merging functional and logical languages.