Lambda the Ultimate

Haven't seen this paper by Tim Sheard mentioned on Ltu before. As in previous papers Sheard tries to put Howard Curry to work in terms that are understandable for those that don't have a Phd in type theory.

Abstract:
Omega is an experimental system that combines features of both a programming language and a logical reasoning system. Omega is a language with an infinite hierarchy of computational levels. Terms at one level are classified (or typed) by terms at the next higher level. In this paper we report on using two different computational mechanisms. At the value level, computation is performed by reduction, and is largely unconstrained. At all higher levels, computation is performed by narrowing.

Ralf Hinze and Andres Löh. Generic Programming, Now!. In Roland Backhouse, Jeremy Gibbons, Ralf Hinze and Johan Jeuring, editors, Spring School on Generic Programming, Lecture Notes in Computer Science. Springer-Verlag, 2006.

Tired of writing boilerplate code? Tired of repeating essentially the same function definition for lots of different data types? Datatype-generic programming promises to end these coding nightmares. In these lecture notes, we present the key abstractions of datatype-generic programming, give several applications, and provide an elegant embedding of generic programming into Haskell. The embedding builds on recent advances in type theory: generalised algebraic data types and open data types. We hope to convince you that generic programming is useful and that you can use generic programming techniques today!

Yes, more functional generic programming...

Open data types and open functions are discussed here, but I think this paper wasn't featured on the homepage before.

Pivotal is a document-centered presentation of Haskell. It aims to provide a user-friendly environment in which Haskell documents can be interactively developed and manipulated. A Haskell document is essentially an ordinary Haskell module that may also include free-standing Haskell expressions. When a document is displayed, the values of any such expressions are evaluated and displayed in-place.

Think of a document containing code, comments, and examples, all presented in an aesthetically pleasing manner. The document is live, so you can make changes and see them immediately. This reminds me somewhat of the Lab system in J: interactive tutorials that allow the user to experiment after each new point is presented.

Beauty in the Beast by Wouter Swierstra, Thorsten Altenkirch. 2006.

We provide a functional specification of three central components of Simon Peyton Jones’s awkward squad: teletype I/O, mutable state and concurrency. By constructing an internal model of such concepts within our programming language, we can reason about programs that perform I/O as if they were pure functions. One important application of our approach is accommodating I/O in a dependently typed programming language.

I am writing a chapter for a book called "Beautiful code", edited by Greg Wilson. My draft chapter is about Software Transactional Memory in Haskell.

I would welcome any comments or questions you have on the paper, or constructive suggestions for improving it; the more concrete the better.

The book is aimed at a general audience of programmers, not Haskell geeks, so I have tried to explain everything necessary as I go along. So if you are not a Haskell expert, your input would be particularly valuable to me.

You can post your comments on the Haskell wiki.

STM was discussed here many time before, of course. For me the original papers were easier to follow, but some may prefer the style of presentation used here.

The Derivative of a Regular Type is its Type of One-Hole Contexts by Conor McBride was mentioned on LtU several times.

If you enjoyed it, try a new paper by the same author:
Clowns to the left of me, jokers to the right (Dissecting Data Structures).

More generic programming, more parallels between data types and calculus, more fun.

As usual for Conor's paper, it's short and full of (sometimes obscure) humor. Beware of typos, though.

Data Parallel Haskell: a status report. Manuel M. T. Chakravarty, Roman Leshchinskiy, Simon Peyton Jones, Gabriele Keller, and Simon Marlow.

We describe the design and current status of our effort to implement the programming model of nested data parallelism into the Glasgow Haskell Compiler. We extended the programming model and its implementation, both of which were first popularised by the NESL language, in terms of expressiveness as well as efficiency of its implementation. Our current aim is to provide a convenient programming environment for SMP parallelism, and especially multicore architectures. Preliminary benchmarks show that we are, at least for some programs, able to achieve good absolute performance and excellent speedups.

NESL was mentioned here in the past a few times, as was data parallelism in general.

Comparing Approaches to Generic Programming in Haskell by Ralf Hinze, Johan Jeuring, and Andres Löh. 2006.

You just started implementing your third web shop in Haskell, and you realize that a lot of the code you have to write is similar to the code for the previous web shops. Only the data types have changed. Unfortunately, this implies that all reporting, editing, storing and loading in the database functionality, and probably a lot more, has to be changed. You’ve heard about generic programming, a technique which can be used to automatically generate programs depending on types. But searching on the web gives you almost ten approaches to solve your problem: DrIFT, PolyP, Generic Haskell, Derivable Type Classes, Template Haskell, Scrap Your Boilerplate, Generics for the Masses, Strafunski, etc. How do you choose? And these are only the approaches to generic programming in Haskell. If you are also flexible in the programming language you use, there is a much larger variety of different approaches to generic programming to choose from.

[on edit: updated link to point to a more complete version of the paper]

Since 2001, the functional language Erlang comes with a byte-oriented datatype (called binary) and with constructs to do pattern matching on a binary. We have been heavily involved in this work and implemented a scheme for native code compilation of binaries and designed efficient algorithms for constructing deterministic pattern matching automata for byte-based binaries. In last year's Erlang workshop we put forward a proposal for lifting the restriction that Erlang binaries are sequences of bytes rather than bits and described the semantics of bit-level pattern matching on a bit-level binary (called bit stream). We have subsequently realized this proposal and describe its applications and implementation in this paper.

Be sure to see the benchmarks on page 13 comparing Erlang, Haskell, Objective Caml, C, and Java for processing binary data. Having used the existing binary pattern matching support in Erlang, I'm looking forward to the official language support for bit streams.

This paper by Donald McIntyre is a classic in the J language world. It ranks up there with "Why Functional Programming Matters" in terms of concise, impressive examples. Most of the examples have a geometric bent, like finding the area of a polygon. Note that this paper was written using an early version of J, so some of the syntax has unfortunately changed.