Fun at Credit Suisse, February 2008

Ganesh said

The next Fun will be at Credit Suisse, in Canary Wharf
in London, on 12th February, organised by myself and Lennart
Augustsson. Slightly inconveniently, we'll need to pre-register all
attendees. Therefore, if you plan to come, and didn't sign up in York,
please email me with your name and affiliation (if any). Nearer the
time, I'll publish a list of attendees so you can check your name is
on it.

Please do sign up even if you're not certain of
attending; we do have a maximum capacity of 100 people, but if it
seems like we are in danger of hitting that then I will ask for
confirmation later on.

[Editorial remark.
You can reach Ganesh by decoding the following clue:
ganesh dot sittampalam at credit hyphen suisse dot com.]

Local Information

We'll be meeting from 12 noon for lunch, and from 1:30 at Credit
Suisse for talks starting at 2pm. Curry will be at 6pm.

Unfortunately we couldn't find any private area for lunch, so we'll be
meeting up at Jubilee Place, an underground shopping centre just next
to the Jubilee Line tube station. There are a variety of eateries here
next to each other, as well as sandwich shops.

A full map of the underground shopping areas at Canary Wharf can be
found here:
http://www.mycanarywharf.com/stores/Canary_Wharf_map.pdf.
We'll be meeting in the area of Jubilee Place surrounded by "Gourmet Burger
Kitchen", "Tiffinbites", "Nandos", "Itsu", "Crussh" and "Caffe
Nero".

Travel Information

Canary Wharf is best accessed by public transport. I have no idea
of if or where you can sensibly park if you drive all the way here,
but if anyone wants to do this let me know and I can try to find out.

The main access is via either the Jubilee Line from all over
central London to Canary Wharf, or the Docklands Light Railway (DLR),
most probably from Bank. Coming from Tower Gateway, the other central
London terminus, will involve changing at Westferry (or Shadwell or
Limehouse). If you are coming from appropriate locations, you might
want to enter the DLR network at Stratford or Lewisham.

You should allow 30-60 minutes to reach the area from London mainline
railway stations, depending on how far north-west they are. For
example I normally allow 45 minutes from Kings Cross/St Pancras
(Northern Line -> Bank, then DLR).

If you are first coming to the lunch meetup: The Jubilee
line station (Canary Wharf) is very convenient for Jubilee
Place. Avoid the escalators to "Upper Bank Street" and "Montgomery
Street"; the other sets should get you to the main ticket hall. After
the ticket barriers turn left and you'll get straight into Jubilee
Place without having to go outside at all.

The best DLR
station is Heron Quays. Follow the signs to the Jubilee Place shopping
mall.

If you are coming straight to the talks: The best DLR
station is West India Quay. Walk away from the station along the edge
of the dock and go over the pedestrian bridge on your left. At the
other end of the bridge, turn right and continue walking along the
edge of the dock to the opposite corner of the dock to the DLR
station. Go up the steps there (under a bridge between two
buildings). You are now in Columbus Courtyard; turn left and the
Credit Suisse building is on the left (where it says "20" on the map
above).

From the Jubilee line station, come out of the main exit to the
station (avoiding the "Upper Bank Street"/"Montgomery Street"
escalators as before). There'll be a dock facing you. Turn right, go
up the steps onto the main road (Canary Wharf DLR station will be
right in front of you), turn left and walk along the road until you
reach a square (Cabot Square). The Credit Suisse building is in the
far corner of that square, but you need to walk around the building to
the left to reach the Columbus Courtyard entrance to it.

Abstracts

The “free lunch” of exponentially increasing sequential software performance is said to be over: all major processor manufacturers are chasing increasing degrees of hardware parallelism instead of ever-higher clock speeds. We need software to make good use of these processors, but parallel programming has a notoriously steep learning curve. What can the computer science research community do to make things easier?

One tempting approach is to automatically build parallel implementations from sequential programs. This led to a lot of work in the 1980s in the functional programming community, and the exploration of data-flow processor architectures that could exploit the very fine grained parallelism that was achieved. In this talk I'll describe some work we've been doing returning to this question and investigating whether we can achieve automatic parallelisation of software when using today's multi-core processors.

Our approach is to (i) profile the execution of a program, (ii) from this to identify pieces of work which are promising sources of parallelism, (iii) use spare processor cores to speculatively perform this work, (iv) detect at run-time any attempt to perform operations that would reveal the presence of speculation. Our results show 10-80% speed-ups on several programs. This is clearly not a replacement for careful manual parallelisation, but may provide a way of squeezing out a little extra performance without much effort: free coffee, if not a free lunch.

Foundations for the Debugging of Functional ProgramsOlaf Chitil, University of Kent

Several debugging methods take advantage of the specific properties of functional programs, for example algorithmic debugging, following redex trails and observing expressions (a la Hood). The Haskell tracer Hat combines these methods. It records a single detailed but compact trace for the computation of a program and each method is realised in a tool that reads the trace. In this talk I will describe the structure of this trace. The trace structure is independent of any evaluation strategy.
Although the trace is a graph, it is inductively defined, thus enabling inductive proofs. I will show how we can easily and efficiently perform algorithmic debugging with this trace and prove its soundness. Finally I will modify standard algorithmic debugging by representing functional values as finite maps and show how this modifies our definition of algorithmic debugging and the soundness proof.

Very recently, Richard Bird sent me the following problem, which
he was unable to solve.

“Consider a natural transformation tr :: L → FL.
Suppose tr has the property that it returns an F-structure of
L-structures all of the same shape. Consider the instance trG :: LG
→ FLG. I want to show that if trG is applied to an L-structure of
G-structures all of the same shape, then it returns a result that is
an F-structure of LG-structures all of the same shape.”

The generic theory of “fan”s and “zip”s
pioneered by Backhouse, Doornbos and Hoogendijk in 1992, and which
eventually formed Hoogendijk's 1997 PhD thesis, is the appropriate
vehicle for tackling such problems. A “fan” of F is a
relation between values and F-structures of arbitrary shape. A
“zip” is a relation between F-structures of (G-structures
of the same shape) and G-structures of (F-structures of the same
shape).

In this talk, we introduce a collection of fans inspired by
Richard's problem (hence “Richard Bird's fan club”) and we
explore the relation between them. In particular, we show how
Richard's problem is resolved (in fact, a later formulation since the
one above turned out to be wrong). The final proof was discovered by
Richard himself.

The talk will begin with a short introduction for the benefit of
non-fanatics.

Objects to unify type classes and GADTsBruno
Oliveira, University of Oxford

In this presentation we propose H+-: a Haskell-like language with
a generalized class system that unifies type classes and GADTs. In H+-
class instances are replaced by the more general concept of
objects. Using objects we can construct `dictionary' values explicitly
using a value constructor-like syntax.

From a different perspective, we can understand our classes and
objects as a form of open datatypes. However, unlike Haskell's
(closed) datatypes, we cannot add new functions by pattern matching on
an open datatype. This motivates the introduction of the sealed
classes, which are just like classes but have a closed-world
perspective: all objects that construct values of a certain class are
defined in the same module of that class. With sealed classes we get a
notion of closed datatypes that, like Haskell datatypes, allow new
functions to be defined by pattern matching. We show the usefulness of
the combination of the strengths of type classes and datatypes by
illustrating how in H+- we can have some straightforward solutions for
some problems that would require somehow roundabout solutions in
Haskell. The best thing is that the technology behind objects is
basically just a mild generalization of the dictionary translation.

The worker/wrapper transformation is a technique for changing the
type of a computation, usually with the aim of improving its
performance. It has been used by compiler writers for many years, but
the technique is little-known in the wider functional programming
community, and has never been formalised. In this talk we explain,
formalise, and explore the generality of the worker/wrapper
transformation. We provide a systematic recipe for its use, and
illustrate the power of this recipe using a range of examples.

this page uses parts of the Kubrick wordpress style,
as knocked about a bit by Peter Morris, then travestied by Conor