Talks and Abstracts

When the number of talks I have given started to increase noticably, I set up this page. At first, it mainly served to refresh my memory about these talks, but more recently, I have also been asked whether I could make the slides for my talks available. Well, here they are!-)
Type-Directed Monadification
14.04.2005, Canterbury, UK, FP group meeting (no slides were used, prototype code available on request )

On a type-directed form of monadification (translating a Haskell program that does not use a monad into one that does), prompted by Martin Erwig's visit to the HaRe group not too long ago. The typical first thoughts are "yeah, I would use that often", and "translations are well known - think cps transform", but Martin Erwig and Deling Ren had a paper on their approach in SCP last year, elaborating on earlier work by Ralf Lämmel:

One outcome of the visit was our survey, in which we present the problem to the Haskell list, illustrate some example monadification styles for a simple interpreter, and ask for preferences as to which styles of monadification people would actually use (your input would be welcome!-): Another outcome was that I felt rather confused about the situation, as I don't like apparently completely unrelated algorithms delivering completely different solutions to what should be a single problem. Rather than trying to understand the details of Martin's algorithm, I tried to approach the problem from scratch, based on the idea of monadification as a type-coercion: you start with a program and the monadified types you would like the functions to have, and the algorithm is basically a standard type system augmented with rules that transform expressions locally to conform to the required types. So, where you'd usually have statements and rules like
       env |- e1 : t1 ...
       ------------------
       env |- exp : type
      
where we put in env and exp, and the system gives us type or an error, we now have
       env |- e1->e1' : t1 ...
       -----------------------
       env |- exp->exp' : type
      
where we put in env, exp and a monadified type, and the system gives us a monadified exp'. That's a lot easier to understand for me, and it seems to provide a common basis for the various known monadification algorithms, but the question is whether it works:-) So I have started to implement a prototype based on the idea. That prototype and my current successes and problems with it are going to be the core of the session. This is not going to be a standard talk with slides, but rather a discussion session, starting with a quick tour of the problem and a high-level view of some prototype code I have hacked up, running through some of the test cases from Martin and Deling's paper and our survey page. The message in a sentence: it works surprisingly well if the types are given (including all those examples), but there are situations where the types may have to be guessed, and that is where the whole thing explodes!-) I have the suspicion that we can limit the solution space without losing practically relevant solutions, but I may be wrong and the whole thing is as undecidable as polymorphic recursion without annotations. So any helpful suggestions or counter-examples will be welcome - calling all theoreticians and practitioners!-)

Tool Support for Haskell-Coloured Petri nets
10.09.2004, Lübeck, Germany, Implementation and Applications of Functional Languages (slides are available in Powerpoint )

Haskell-Coloured Petri nets
05.08.2004, Canterbury, UK, FP group meeting (slides are available in Powerpoint )


Tool Support for Refactoring Functional Programs
28.08.2003, Uppsala, Sweden, 2003 ACM Sigplan Haskell Workshop (slides are available in Powerpoint and in PDF)

Refactorings are program transformations that change the structure of code, but not its functionality. Refactoring is thus the representation-level implementation of design changes, Separating the two tasks of structural and functional modifications permits a systematic treatment of the former, with no bugs/features added or removed during program refactoring. Added safety in refactoring also helps to keep functional changes free from structural concerns and design mismatches. This talk gives a brief outline of refactoring and its relation to other uses of meaning-preserving program transformations in functional programming, followed by a mini-demo of our prototype Haskell Refactorer, and an overview of the issues and tool support needed to implement such a tool for full Haskell. [part of our Refactoring Functional Programs project]

Programming in π and Pict
03.02.2003, Canterbury, UK, TCS seminar (part of the TCS theme on the π-calculus) (slides are available in Powerpoint and PDF)

The π-calculus has been put forward as the concurrent counterpart to the λ-calculus, aiming to offer a formal foundation for concurrent languages. We'll take a brief look at the two calculi side by side, to see what the differences are, and some alternative routes that could be taken in that direction. Most of the talk will then focus on a series of examples introducing features of Pict, a concurrent language built on a variant of π at its core. The examples will showcase the abstractions layered on top of core Pict to facilitate programming with functions and concurrent objects.


FunWorlds/HOpenGL (or: the story continues..)
18.09.2002, Madrid, Spain, 14th International Workshop on the Implementation of Functional Languages (slides are available in Powerpoint)

The FunWorlds project aims to combine and integrate ideas from functional (reactive) programming and virtual worlds (a la VRML'97). In earlier work, reported at IFL'2001, we experimented with mapping Fran concepts into VRML'97, using a domain-specific embedded compilation approach to map high-level programs in a Haskell DSEL into standard VRML'97 + ECMAScript worlds, render- and navigable using any VRML'97 browser. This year, we introduce our new approach, based on a more direct integration using Sven Panne's HOpenGL Haskell binding to the industry standard for 2d and 3d graphics, OpenGL. A particular focus is on a redesign of the functional reactive programming parts of the DSEL to avoid some of the problem of earlier incarnations.

To enable a declarative approach, we first introduce a simple scene graph similar to the static aspects of VRML, which is translated into calls to the imperative HOpenGL API. To address dynamic aspects of our scenes, we build on ideas taken from Conal Elliott's Fran (functional reactive animation). However, Fran itself has gone through a series of implementations of increasing complexity and difficult-to-predict performance. We trace some of those problems to issues in the design of the Fran DSEL and choose to deviate from this original Fran design in several points. Without unduly restricting expressiveness, our more pragmatic design leads to a drastically simplified implementation offering competitive, and more importantly, predictable performance.

FunWorlds -- the story continues..
04.07.2002, Canterbury, UK, Computing Laboratory (informal talk in our fp group, some slides are available in Powerpoint)

A work-in-progress report on a reimplementation of the ideas on top of HOpenGL, Sven Panne's Haskell binding to the industry standard OpenGL. OpenGL is in itself an interesting platform for graphics programming in Haskell (it is portable, widely ported and used, and hardware-accelerated, offering a more suitable basis for *both* 2d *and* 3d graphics than other Haskell libraries), but it is thoroughly imperative. Moreover, while it isn't exactly low-level, it burdens programmers with lots of details and administration. Life can be made much easier by providing higher-level abstractions on top. I'll probably chat a little about HOpenGL, as that might be of wider interest, and then switch over to design differences between Fran and FunWorlds, which is what I'm working on at the moment (leaving the 3d details for later). I've just completed a FunWorlds version of Simon's n-level lift, so perhaps I'll just use that as a running example.

Design Patterns (?) for Control Abstractions
04.02.2002, Canterbury, UK, Computing Laboratory (slides are available as Powerpoint)

What do parsers, lambda-calculus reducers, and prolog-interpreters have in common?
Abstract: Perhaps surprisingly, a lot. Even more interestingly, modern functional languages, such as Haskell, enable us to capture the common pattern quite easily. This permits reuse of functionality across apparently so different projects, and simplyfies the code for each of them. These ideas are not really new, but do not seem to be as well known as they should be, so I'll try to present them in terms of the examples listed in the title. [if you wonder about the question mark: there are functional design patterns in the examples, but I don't present them as such]


FunWorlds -- Functional Programming and Virtual Worlds
19.11.2001, Canterbury, UK, Computing Laboratory ( more detailed version of my IFL'2001 presentation)

Domain-Specific Languages and Functional Programming
31.10.2001, Canterbury, UK, South Eastern Universities Joint Programme in the Foundations of Computing, Advanced Functional Programming course (slides are available as Powerpoint or PDF)

FunWorlds -- Functional Programming and Virtual Worlds
24.09.2001, Stockholm, Sweden, 13th International Workshop on the Implementation of Functional Languages
(slides are available as VRML files; you'll need a free VRML browser or plugin, e.g., ParallelGraphics' Cortona for Windows or Mac; there are browsers for most platforms, see vrml.org for alternatives); use the long arrow at the bottom to navigate, make sure that anti-aliasing is switched on in your VRML browser, otherwise the text will be hard to read;

The Virtual Reality Modeling Language (VRML) is a standard format for describing interactive 3d content, especially on the world-wide web. It combines declarative specifications of static scenes with imperative manipulations of scene graphs to realise dynamic scenes.

We set out to re-examine the design space for interactive 3d content, taking the current standard VRML'97 and Fran (Functional Reactive Animation) as yardsticks. We prototype our experiments as an embedded compiler in Haskell, generating standard VRML'97+ECMAScript code from concise declarative descriptions. The results are promising in two directions: first, they give the functional programming community access to a rich output medium for animated, interactive 3d content, employing standard technology, but avoiding low-level imperative specifications. Second, the mapping will help to compare Fran, which developed out of ActiveVRML, with VRML'97, which developed out of a competing proposal for VRML 2.0, hopefully helping the VRML community to re-assess the values of Fran's concepts.

This presentation --itself a VRML file generated by our prototype-- gives some examples using an embedding of VRML concepts in Haskell, combined with features of the host language and some first Fran concepts. The source code shown is the one used to generate the examples in our current experimental prototype - note that the details of syntax are likely to change. There is a draft paper as well (too much background, some of it will have to make room for technical details in the final version..).

GHood -- Visualising Observations of Haskell Program Runs
02.09.2001, Firenze, Italy, 2001 ACM SIGPLAN Haskell Workshop (slides are available as Powerpoint or PDF (b/w))

As a possible extension to his Haskell Object Observation Debugger Hood \cite{Gill2000}, Andy Gill has described the ``dynamic viewing of structures'', stepping through observations instead of accumulating them into a static view. Starting from this idea, we have implemented and released an animation back-end for Hood, called GHood. Instead of the dynamic textual visualisation based on pretty-printing proposed in \cite{Gill2000}, our back-end features a dynamic graphical visualisation, based on a simple tree layout algorithm. This paper reviews the main aspects of Hood, gives a brief introduction to GHood's features and summarises our experience so far.

The visualisation of program behaviour via animations of data structure observations has uses for program comprehension and exposition, in development, debugging and education. We find that the graphical structure facilitates orientation even when textual labels are no longer readable due to scaling, suggesting advantages over a purely textual visualisation. A novel application area is opened by the use of GHood as an applet on webpages -- discussions of Haskell program behaviour, e.g., in educational online material or in explanations of functional algorithms, can now easily be augmented with graphical animations of the issues being discussed.

GHood -- Visualising Observations of Haskell Program Runs (talk and demo)
19.03.2001, York, UK, Programming Languages and Systems Research Group (slides are available as Powerpoint or PDF)

As a functional language, Haskell supports a declarative approach to programming in which operational aspects are mostly left to language implementations. Once satisfied with the declarative aspects of their programs, however, functional programmers may well want to give consideration to their operational aspects. One of the various problems they face in this endeavour has been the lack of means to inspect the runtime behaviour of their programs (above implementation level).

Last year, Andy Gill published his Haskell Object Observation Debugger, Hood, which provides for the selective observations of intermediate structures occurring in functional computations. Building on this work, I have been developing a tool for the graphical visualisation and animation of these observations - GHood. As should become clear in the presentation, this approach differs from more direct animations of program behaviour and sets out from a more abstract, extensional view of the program under observation. Nevertheless, experience so far indicates that interesting insights into program behaviour can be gained by careful interpretation of graphically animated observations, making GHood a useful item in the toolboxes of Haskell programmers and educators.

Petri nets, concurrency and causality -- a guided tour
19/26.02.2001, Canterbury, UK, Computing Laboratory (slides are available as Powerpoint or PDF)

An introductory talk on selected topics in Petri nets. This is a complete research and application area, with several yearly events, and a history longer than that of UKC. So, even at an overview level, this tour will leave more interesting aspects of nets unmentioned than it will touch on briefly. The working hypothesis about the audience is that many of you are familiar with the basics of Petri nets, but only few have delved further into the topic, and less than a handful use nets in their daily work or research. One aim of the talk is to change this distribution, and no prior knowledge of Petri nets should be necessary.

The series topic of `modelling concurrency and time' forces me to go a bit into the philosophy and the physical background of Petri's nets - just enough to explain how nets, even without explicit extensions for "time", address many of the problems in modelling time that other approaches shy away from (variations of nets with extensions for explicit time exist as well, but will only be mentioned briefly). Similar to the treatment of time and concurrency, connections to logic are intrinsic to the model and will be another stop on the tour.

As I hope to convince you in the talk, Petri nets are more than just another formalism, they have evolved to a way of thinking about concurrent systems. Combining careful foundational work with an intuitive representation (sometimes called "pre-formal"), Petri nets give a successful example of a science of computing at the border between computer science, engineering, and physics. Petri nets are not perfect, but they offer well-balanced foundations for further work.


Reduction systems
02.11.2000, Canterbury, UK, Computing Laboratory

Originally planned as a short demo of the reduction systems developed in Kiel, this developed into a whole session. In spite of numerous publications and continuous implementation work for the some 25 years, surprisingly few functional programmers know about the work of Berkling, Kluge, et.al.. Did you know that there was a hardware implementation of the lambda-calculus around 1978? Or that high-level interactive implementations of functional languages can mean a lot more than what is currently associated with these terms, without being slow at all?

Reduction systems nicely illustrate -and have indeed inspired- many of the ideas I presented in the previous talk. In particular, the paradigm and language came first, the implementations in hard- and software came later, and the language is the high-level interface to a wide variety of implementations (string-, graph-, compiled graph-, distributed compiled graph-reduction,..).

Language Design - at the heart of computer science
30.10.2000, Canterbury, UK, Computing Laboratory (slides: PDF)

An introduction to my views on language design, and why I think it should be a core topic of computer science. The first part outlines and motivates the major role languages should play in computer science (in brief: languages are interfaces - between CS and other disciplines, and between users and the systems we offer them). The reasons why, so far, languages have not quite managed to take on that role, are largely historical and are discussed briefly. The discussion leads directly into the second part, which focuses on some of the changes that are necessary to remedy the current situation. This, in turn, sets the context for most of the things I hope to be working on over the next few years.

Comments: I was slightly surprised about the way the talk evolved during preparation, focussing more and more on one idea that I had been working up to in previous talks and discussions and that now seemed ripe for a more complete presentation. Thanks to the audience -not only TCS!- for the lively discussion and for pointing out some parts of the picture that need further refinement, and possibly some modifications. The slides here are the original -unrefined- ones, including some that had to be omitted for lack of time.

Language Design - In pursuit of ideas and means to express them
14.08.2000, Canterbury, UK, Computing Laboratory

A broad overview and rationale of my current research interests. Examples of what I've done in the past (functional programming + explicit interactions + modular programming), how those and earlier experiences (functional programming + logic programming) shaped my view of the subject (languages as interfaces to computer systems), and how past and present (functional programming + explicit concurrency) research fit together in a bigger picture (developing, collating and organizing foundations for my constructive view of language design).

Language Design - What Else?
17.07.2000, Edinburgh, UK, Division of Informatics

Same title slide as the previous talk, but completely different content. I was asked to address a general informatics audience and to focus on the relationships between my interests in language design and (the teaching of) software engineering. One of my worst talks - I found the relations so interesting that I didn't manage to cut down what I wanted to talk about. Sorry if you were in the audience.

Comments: The experience taught me that I need more than four days notice if you want me to make any interesting (and thus potentially substantial) modifications to my talks. Yes, I know, every experienced speaker would have told me that, but it seems I needed to experience it myself to believe it (the modification looked so innocent and interesting, and I didn't want to cancel the presentation..).

Language Design - What Else?
Jan 2000, Nottingham, UK, School of Computer Science

On the spot overview of my research interests..

Comments: Nothing survived but the title slide, showing my path from wanting to use computers as tools to writing programs to learning languages to implementing and designing languages to language design per se, especially its constructive aspects. As it should be possible to adapt and reorganize the foundations of analytic language design for a more constructive approach, I am now optimistic to get back out of the recursive descent that led me to research in language design .


Haskell-Coloured Petri Nets
04.10.1999, Nottingham, UK, LAP group meeting

Coloured Petri Nets are a high-level form of Petri nets, in which transition inscriptions in some programming language operate on tokens attributed with values of the inscription language. A brief review of functional Petri nets (CPNs with functional inscription languages) will focus on their success despite the high startup costs that have hampered their use so far.

The startup costs can be reduced by embedding functional Petri nets into their inscription language. As an example, I will introduce the variant of Haskell-Coloured Petri Nets (HCPNs) and show that they have a simple mapping to Haskell. HCPNs can thus be used for system modelling in preparation of system implementation in Haskell, following a process of stepwise refinement in which all intermediate specifications are executable Haskell programs.

Comments: An extended version of my IFL'99 presentation.

Haskell-Coloured Petri Nets
10.09.1999, Lochem, The Netherlands, IFL'99

Coloured Petri Nets are a high-level form of Petri Nets, in which transition inscriptions in some programming language operate on individual tokens, i.e., tokens attributed with values of the inscription language. We introduce the variant of Haskell-Coloured Petri Nets (HCPNs) and show that they have a simple mapping to Haskell. HCPNs can thus be used for system modelling in preparation of system implementation in Haskell, following a process of stepwise refinement in which all intermediate specifications are executable Haskell programs.


Haskell over Java
19.11.1998, Nottingham, UK, LAP group meeting

What if we want to have both functional programming and lots of fancy libraries? In theory, functional abstraction could be used over arbitrary domain-specific sets of data types and their operations. In practice, writing useful domain-specific libraries requires resources that are not usually available in functional language implementation projects. Most implementations provide at least a general mechanism for reusing existing libraries written in C. Indeed, the only reason for having built-in data types and primitive operations in a functional language is better integration (e.g., in terms of syntax and optimizations). By developing an interface between Haskell and Java, I hope to be able to write Haskell programs over functionality provided by software components written in Java. This interface, called Haskell/Java (pronounced: Haskell over Java), uses proposed standard native interfaces for Haskell and Java to connect the two languages. In the talk, I will give an overview of the implementation of Haskell/JNI (JNI is Java's native interface), focussing on general issues and on the relation to Haskell/Java.

Hello World?
22.09.1998, Pitlochry, Scotland, Glasgow FP group workshop'98

It took some time before the first purely functional programs could shout their proud "Hello!" into the world, but today this problem seems to be solved. Language designers can choose from a variety of different i/o-schemes, with monadic i/o and uniqueness typed environment passing being the most popular alternatives. I argue that the interaction of functional programs with their runtime environments raises problems that are far from solved. These problems range from the basic mechanism over high-level communication in homogeneous environments to interactions in heterogenous environments.

Scripting the Java platform? Towards a Haskell/Java connection.
10.09.1998, London, UK, IFL'98

One of the major problems of functional languages is that most research projects and their budgets do not support the man-power necessary for the development and maintenance of the large collection of libraries which make a language useful in practice. Connecting Haskell to the popular Java platform promises access not only to an increasing number of libraries, including graphical user interface components, but also to large scale components written in the Java language. The preliminary work described here can be seen as complementary to recent work on a Haskell/COM interface, but currently operates at a lower level of abstraction. Our prototype implementation uses Hugs and Sun's Java Development Kit, but employs proposed standards for the native interfaces to improve portability.

Reflections on a Christmas card.
26.01.1998, Nottingham, UK, LAP meeting

Reflection is the ability of a computational process to reason about itself. It can be seen as an extreme case of meta-programming as it allows programs in an object language to access their meta language. One idea of this talk is to introduce some basic concepts of reflection, and to motivate the need for reflective capabilities in functional languages, especially in the context of my current project.

Last December, these musings on reflection in functional languages led to a slightly unusual Christmas card being sent to the members of the Languages and Programming Group (involving a program that does not quite print itself). A major part of the talk will consist of an explanation of that program -- how it works, and how such (almost self-reproducing) programs can be developed. Particular emphasis will be put on problems of reflection in purely functional languages, some of which can be demonstrated using the Christmas card program as an example.


Functions as a foreign language -- Do we need new models of functional programming?
17.12.1997, Nottingham, UK, The 2nd Meeting of the Nottingham and York Programming Research Groups

Despite the `well-known' advantages of the functional programming paradigm, its success has so far been limited to the academical sector, whereas, e.g, the object-oriented paradigm seems to have made its way into the minds of commercial programmers. Looking only at the available languages, this difference in acceptance is hardly understandable, but if we consider how the two paradigms have been presented to programmers, it becomes clear that the current situation is neither a historical accident nor a result of marketing hype alone. Object-oriented programming has simply provided programmers with mental models of programming that made the object-oriented paradigm appear very natural to use, whereas a strong background in mathematics is needed to appreciate functional programming. As it is unreasonable to assume such a background outside of academia, new `models' of functional programming may have to be developed to make this paradigm accessible to a wider community.

Functions, Frames, and Interactions -- completing a -calculus-based purely functional language with respect to programming-in-the-large and interactions with runtime environments
26.11.1997, Kiel, Germany, PhD Thesis Defense

On functional programming, language design, and persistence.
20.10.1997, Nottingham, UK, LAP meeting

The principles of abstraction, correspondence, and data type completeness have been proposed to guide and evaluate the design of general purpose languages in the late 1970s. I argue that these semantic principles for language design can be particularly useful for the design of extensions to purely functional languages. After evaluating a simple functional core language with respect to the design principles, I focus on language extensions, using module systems and i/o-facilities as examples. Following the principles, we are led to a simple, yet expressive extended language. It turns out that the final language design demands support for orthogonal persistence.

Comments: The core of this talk has been given at IFL'97. It addresses a fairly general audience and presents some afterthoughts on my Ph.D. work. I will try to extend the parts describing my work and the context in which I have been working.

On functional programming, language design, and persistence.
10.09.1997, St. Andrews, Scotland, IFL'97

The principles of abstraction, correspondence, and data type completeness have been proposed to guide and evaluate the design of general purpose languages in the late 1970s. I argue that these semantic principles for language design can be particularly useful for the design of extensions to purely functional languages. After evaluating a simple functional core language with respect to the design principles, I focus on language extensions, using module systems and i/o-facilities as examples. Following the principles, we are led to a simple, yet expressive extended language. It turns out that the final language design demands support for orthogonal persistence.

Comments: One of my best talks so far, especially in terms of discussions it generated during the rest of the workshop.


Functions, Frames, and Interactions (advocating first class modules)
1995, Passau, Germany, Kolloquium Grundlagen der Programmierung

Combining modules as first class data structures with explicit input/output-operations for arbitrary expressions in a purely functional programming language brings the flexibility of integrated programming environments under control of the functional language.

Compared with conventional module systems, the proposed solution provides enhanced functionality in a simpler framework, using the functional language as an unrestricted module language and the extended input/output-facilities to make modules persistent.

Comments: This talk was an abridged version of the talk given in Bastad (see below), addressed to a more general audience.

Functions, Frames, and Interactions
1995, Bastad, Sweden, IFL'95

Combining modules as first class data structures with explicit input/output-operations for arbitrary expressions in a purely functional programming language brings the flexibility of integrated programming environments under control of the functional language.

Compared with conventional module systems, the proposed solution provides enhanced functionality in a simpler framework, using the functional language as an unrestricted module language and the extended input/output-facilities to make modules persistent.

Comments: My first external talk, straight onto an international audience.. An overview of what I thought I would be doing during my PhD time. Surprisingly, what I did mostly matched my plans, even though my understanding of what I did evolved considerably.