Haskell Communities and Activities Report

http://www.haskell.org/communities/

Seventeenth Edition — November 2009

Janis Voigtländer (ed.)

Andy Adams-Moran Tiago Miguel Laureano Alves Krasimir Angelov
Heinrich Apfelmus Dmitry Astapov Justin Bailey
Jean-Philippe Bernardy Tobias Bexelius Joachim Breitner
Björn Buckwalter Andrew Butterfield Roman Cheplyaka
Adam Chlipala Olaf Chitil Jan Christiansen
Alberto Gómez Corona Duncan Coutts Jácome Cunha
Nils Anders Danielsson Atze Dijkstra Facundo Dominguez
Chris Eidhof Marc Fontaine Patai Gergely
Brett G. Giles Andy Gill George Giorgidze
Dmitry Golubovsky Jurriaan Hage Bastiaan Heeren
Claude Heiland-Allen Jan Martin Jansen Wolfgang Jeltsch
Florian Haftmann Christopher Lane Hinson Guillaume Hoffmann
Martin Hofmann Creighton Hogg Csaba Hruska
Liyang HU Paul Hudak Farid Karimipour
Oleg Kiselyov Lennart Kolmodin Michal Konečný
Lyle Kopnicky Eric Kow Bas Lijnse
Ben Lippmeier Andres Löh Rita Loogen
Ian Lynagh John MacFarlane Christian Maeder
José Pedro Magalhães Michael Marte Arie Middelkoop
Ivan Lazar Miljenovic Neil Mitchell Maarten de Mol
Dino Morelli Matthew Naylor Rishiyur Nikhil
Thomas van Noort Johan Nordlander Miguel Pagano
Jens Petersen Simon Peyton Jones Dan Popa
Jason Reich Claus Reinke Alberto Ruiz
David Sabel Ingo Sander Uwe Schmidt
Martijn Schrage Tom Schrijvers Paulo Silva
Axel Simon Ganesh Sittampalam Martijn van Steenbergen
Don Stewart Martin Sulzmann Doaitse Swierstra
Henning Thielemann Simon Thompson Wren Ng Thornton
Jared Updike Marcos Viera Miguel Vilaca
Sebastiaan Visser Janis Voigtländer Kim-Ee Yeoh
Brent Yorgey
Preface

This is the 17th edition of the Haskell Communities and Activities Report. As usual, fresh
entries are formatted using a blue background, while updated entries have a header with a blue
background.
The report is thinner/shorter this time, but has a good percentage of blue and semi-blue
entries. I have implemented the strategy, outlined in the May edition, of replacing with online
pointers to previous versions those entries for which I received a liveness ping, but which have
seen no essential update for a while. Entries on which no new activity has been reported for a
year or longer have been dropped completely. Please do revive such entries next time if you do
have news on them.
A call for new entries and updates to existing ones will be issued on the usual mailing lists
around April/May.
Finally, on special occasion, let me pose a prize question. It goes as follows:
How many entries in this report refer to the 2010 PEPM Workshop?
The first correct answer that reaches me wins a free copy of the ACM printed proceedings!

Janis Voigtländer, University of Bonn, Germany, hhcar@haskell.orgi

2
Contents

1 Information Sources 7
1.1 The Monad.Reader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Haskell Wikibook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Oleg’s Mini tutorials and assorted small projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Haskell Cheat Sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 The Happstack Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6 Practice of Functional Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.7 Cartesian Closed Comic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Implementations 10
2.1 The Glasgow Haskell Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 The Helium compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 UHC, Utrecht Haskell Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Haskell frontend for the Clean compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 SAPL, Simple Application Programming Language . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6 The Reduceron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.7 Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.7.1 Haskell in Gentoo Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.7.2 Fedora Haskell SIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.7.3 GHC on OpenSPARC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Language 17
3.1 Extensions of Haskell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.1 Eden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.2 XHaskell project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.3 HaskellActor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.4 HaskellJoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Related Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.1 Curry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2 Agda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.3 Clean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.4 Timber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.5 Ur/Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Type System / Program Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.1 Free Theorems for Haskell (and Curry) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.2 The Disciplined Disciple Compiler (DDC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Tools 22
4.1 Transforming and Generating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.1 UUAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.2 AspectAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.3 HFusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.4 Optimus Prime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.5 Derive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.6 lhs2TEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Analysis and Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.1 SourceGraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.2 HLint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.3 hp2any . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.1 Hoogle — Haskell API Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.2 HEAT: The Haskell Educational Advancement Tool . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3
4.3.3 HaRe — The Haskell Refactorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.4 DarcsWatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.5 HSFFIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5 Libraries 27
5.1 Cabal and Hackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2 Haskell Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3 Auxiliary Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3.1 hmatrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3.2 hTensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3.3 The Neon Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3.4 leapseconds-announced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4 Parsing and Transforming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4.1 ChristmasTree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4.2 Utrecht Parser Combinator Library: New version . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.5 Mathematical Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.5.1 dimensional: Statically checked physical dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.5.2 Halculon: units and physical constants database . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.5.3 Numeric prelude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.5.4 AERN-Real and friends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.5.5 logfloat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.5.6 fad: Forward Automatic Differentiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.6 Data types and data structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.6.1 HList — a library for typed heterogeneous collections . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.6.2 bytestring-trie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.7 Data processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.7.1 MultiSetRewrite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.7.2 Graphalyze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.8 Generic and Type-Level Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.8.1 uniplate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.8.2 Generic Programming at Utrecht University . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.8.3 Extensible and Modular Generics for the Masses (EMGM) . . . . . . . . . . . . . . . . . . . . . . . 33
5.8.4 Optimizing generic functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.8.5 2LT: Two-Level Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.8.6 Data.Label — “atoms” for type-level programming . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.9 User interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.9.1 Gtk2Hs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.9.2 HQK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.10 Graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.10.1 diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.10.2 LambdaCube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.10.3 GPipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.10.4 ChalkBoard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.10.5 graphviz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.11 Music . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.11.1 Haskore revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.11.2 Euterpea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.12 Web and XML programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.12.1 Haskell XML Toolbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.12.2 tagsoup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6 Applications and Projects 40

6.1 For the Masses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.1.1 Darcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.1.2 xmonad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.2 Education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.2.1 Exercise Assistants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.2.2 Holmes, plagiarism detection for Haskell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4
6.2.3 INblobs — Interaction Nets interpreter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.2.4 Yahc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.2.5 grolprep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.3 Web Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.3.1 Holumbus Search Engine Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.3.2 HCluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.3.3 JavaScript Monadic Writer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.3.4 Haskell DOM Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.3.5 gitit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.4 Data Management and Visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.4.1 Pandoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.4.2 HaExcel — From Spreadsheets to Relational Databases and Back . . . . . . . . . . . . . . . . . . . 45
6.4.3 SdfMetz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.4.4 The Proxima 2.0 generic editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.5 Functional Reactive Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.5.1 Functional Hybrid Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.5.2 Elerea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.6 Audio and Graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.6.1 Audio signal processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.6.2 easyVision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.6.3 photoname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.6.4 n-Dimensional Convex Decomposition of Polytops . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.6.5 DVD2473 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.6.6 Fl4m6e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.6.7 GULCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.6.8 Reflex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.7 Proof Assistants and Reasoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.7.1 Galculator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.7.2 Saoithín: a 2nd-order proof assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.7.3 Inference Services for Hybrid Logics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.7.4 HTab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.7.5 Sparkle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.7.6 Haskabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.8 Modeling and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.8.1 iTasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.8.2 CSP-M animator and model checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.9 Hardware Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.9.1 ForSyDe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.9.2 Kansas Lava . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.10 Natural Language Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.10.1 NLP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.10.2 GenI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.10.3 Grammatical Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.11 Others . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.11.1 IgorII . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.11.2 Roguestar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.11.3 LQPL — A quantum programming language compiler and emulator . . . . . . . . . . . . . . . . . 55
6.11.4 Yogurt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.11.5 Dyna 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.11.6 Vintage BASIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.11.7 Bullet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.11.8 arbtt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.11.9 uacpid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7 Commercial Users 58
7.1 Well-Typed LLP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.2 Credit Suisse Global Modeling and Analytics Group . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.3 Bluespec tools for design of complex chips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5
7.4 Galois, Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.5 IVU Traffic Technologies AG Rostering Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.6 Tupil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.7 Aflexi Content Delivery Network (CDN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.8 Industrial Haskell Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.9 typLAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

8 Research and User Groups 62

8.1 Functional Programming Lab at the University of Nottingham . . . . . . . . . . . . . . . . . . . . 62
8.2 Artificial Intelligence and Software Technology at Goethe-University Frankfurt . . . . . . . . . . . 63
8.3 Functional Programming at the University of Kent . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
8.4 Foundations and Methods Group at Trinity College Dublin . . . . . . . . . . . . . . . . . . . . . . 64
8.5 Formal Methods at DFKI Bremen and University of Bremen . . . . . . . . . . . . . . . . . . . . . 64
8.6 Haskell at K.U.Leuven, Belgium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
8.7 Haskell in Romania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.8 fp-syd: Functional Programming in Sydney, Australia. . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.9 Functional Programming at Chalmers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6
1 Information Sources
clarifications or by ruthlessly rewriting existing mate-
rial and penning new chapters.
1.1 The Monad.Reader
Thanks to the bold action of user Orzetta, the chap-
ter “Understanding monads” finally came to live. It is
Report by: Brent Yorgey
very useable now, though more work is needed to prop-
erly record the current lore about the zoo of standard
There are plenty of academic papers about Haskell and monads.
plenty of informative pages on the HaskellWiki. Unfor-
tunately, there is not much between the two extremes. Further reading
That is where The Monad.Reader tries to fit in: more
formal than a Wiki page, but more casual than a jour- ◦ http://en.wikibooks.org/wiki/Haskell
nal article. ◦ Mailing list: hwikibook@haskell.orgi
There are plenty of interesting ideas that maybe do
not warrant an academic publication—but that does 1.3 Oleg’s Mini tutorials and
not mean these ideas are not worth writing about! assorted small projects
Communicating ideas to a wide audience is much more
important than concealing them in some esoteric jour- Report by: Oleg Kiselyov
nal. Even if it has all been done before in the Journal
of Impossibly Complicated Theoretical Stuff, explain-
ing a neat idea about “warm fuzzy things” to the rest The collection of various Haskell mini tutorials and
of us can still be plain fun. assorted small projects (http://okmij.org/ftp/Haskell/)
The Monad.Reader is also a great place to write has received three additions:
about a tool or application that deserves more atten-
tion. Most programmers do not enjoy writing manuals; Typed Tagless Interpretations and Typed
writing a tutorial for The Monad.Reader, however, is Compilation
an excellent way to put your code in the limelight and
reach hundreds of potential users. This web page describes embeddings of typed domain-
Since the last HCAR there has been one new issue specific languages in Haskell, stressing type preserva-
and a change of editors, with Brent Yorgey taking over tion, typed compilation, and multiple interpretations.
editorial duties from Wouter Swierstra. The next issue Type preservation statically and patently assures that
will be published in January. interpreters never get stuck and hence run more effi-
ciently. By ‘typed compilation’ we mean a transforma-
tion from an untyped to typed tagless representations.
Further reading
The untyped form is an AST (represented as a regular
http://themonadreader.wordpress.com/ data type), which is usually the result of parsing a file
or similar plain data. The typed tagless representation
takes the form of either generalized algebraic data types
1.2 Haskell Wikibook
GADT (the initial approach), or alternatively, type-
Report by: Heinrich Apfelmus constructor-polymorphic terms (the final approach).
Participants: Orzetto, David House, Eric Kow, and Either type representation can be interpreted in var-
other contributors ious ways (e.g., evaluated, CPS-transformed, partially
Status: active development evaluated, etc). All these interpretations are assuredly
type-preserving and patently free of any ‘type errors’
such as failure to pattern-match type tags or derefer-
The goal of the Haskell wikibook project is to build a encing an unbound variable.
community textbook about Haskell that is at once free We show three examples of typed compilation:
(as in freedom and in beer), gentle, and comprehen-
sive. We think that the many marvelous ideas of lazy Staged Typed Compilation into GADT using typeclasses
functional programming can and thus should be acces- A typed compiler is the function of the signature
sible to everyone in a central place. In particular, the Expr -> Term t, where Expr is an ordinary alge-
wikibook aims to answer all those conceptual questions braic data type of untyped first-order source terms
that are frequently asked on the Haskell mailing lists. and Term t is a GADT. The result type t is a
Everyone including you, dear reader, are invited to function of the value of Expr. Thus we demonstrate
contribute, be it by spotting mistakes and asking for the Haskell solution of the truly dependent-type

7
 problem. We use template Haskell to implement the bit strings. Furthermore, for so-called sparse predi-
compiler, so that we get the Haskell type checker cates, Martín Escardó’s technique is very fast.
itself to type check the embedded DSL. We re-formulate the problem in terms of streams and
depth-limited depth-first search, and thus cast off the
Typed compilation to tagless-final HOAS The embed- mystery of deciding the satisfiability of a total com-
ded DSL is now higher-order: it is simply-typed putable predicate over the set of all Cantor numerals.
lambda-calculus with the fixpoint and constants — As an additional contribution, we show how to write
essentially, PCF. We no longer use staging. Rather, functions over Cantor numerals in a ‘natural’ monadic
we compile to tagless-final representation, which can style so that those functions become self-partially eval-
be interpreted by different interpreters. Regardless uating. The instantiation of the functions in an appro-
of the number of interpretations of a term, the type priate pure monad gives us transparent memoization,
checking happens only once. We build our own Dy- without any changes to the functions themselves. The
namics to encapsulate typed terms and represent monad in question is pure and involves no reference
their types. cells. The code is in Haskell 98.
Typed compilation via GADTs This time, we compile http://okmij.org/ftp/Algorithms.html#total-sp
the same higher-order DSL to the HOAS tagless-
initial representation: GADT. The compiler itself is
implemented via GADTs.
1.4 Haskell Cheat Sheet

The web page also relates Final and Initial typed Report by: Justin Bailey
tagless representations: they are related by bijection.
http://okmij.org/ftp/Computation/tagless-typed.html
The “Haskell Cheat Sheet” covers the syntax, key-
words, and other language elements of Haskell 98. It
Delimited continuations with effect typing, full is intended for beginning to intermediate Haskell pro-
soundness, answer-type modification and grammers and can even serve as a memory aid to ex-
polymorphism perts. The cheat sheet is distributed as a PDF and lit-
erate source file. A Spanish translation is also available.
We describe the implementations of Asai and
Kameyama’s calculus of polymorphic delimited con-
tinuations with effect typing, answer-type modification Further reading
and polymorphism. The calculus has greatly desirable
properties of strong soundness (well-typed terms do not http://cheatsheet.codeslower.com
give any run-time exceptions), principal types, type
inference, preservation of types and equality through
CPS translation, confluence, and strong normalization 1.5 The Happstack Tutorial
for the subcalculus without fix.
Our Haskell 98 code is the first implementation of Report by: Creighton Hogg
delimited continuations with answer-type modification,
The Happstack Tutorial aims to be a definitive, up-to-
polymorphism, effect typing, and type inference in
date, resource for how to use the Happstack libraries.
a widely available language. Thanks to parameter-
I have recently taken over the project from Thomas
ized (generalized) monads the implementation is the
Hartman. An instance of the Happstack Tutorial is
straightforward translation of the rules of the calculus.
running as a stand-alone website, but in order to truly
Matthieu Sozeau has defined a generalized monad type-
dig into writing Happstack applications you can cabal
class in the recent version of Coq and so implemented
install it from Hackage and experiment with it locally.
the calculus along with the type-safe sprintf in Coq.
Happstack Tutorial is updated along with the Happ-
http://okmij.org/ftp/Continuations.html#genuine-shift stack Hackage releases, but the darcs head is generally
compatible with the darcs head of Happstack.
Total stream processors and their applications to all I am adding a few small tutorials to the package with
infinite streams every release and am always looking for more feedback
from beginning Happstack users.
In the article on seemingly impossible functional pro-
grams, Martín Escardó wrote about decidable checking
of satisfaction of a total computable predicate on Can- Further reading
tor numerals. The latter represent infinite bit strings,
or all real numbers within [0,1]. Martín Escardó’s tech- ◦ http://tutorial.happstack.com
nique can tell, in finite time, if a given total com- ◦ http://patch-tag.com/repo/happstack-tutorial
putable predicate is satisfied over all possible infinite

8
1.6 Practice of Functional Programming

Report by: Dmitry Astapov

Participants: Lev Walkin, Roman Dushkin, Eugene
Kirpichov, Alex Ott, Alex Samoylovich,
Kirill Zaborski, Serguey Zefirov, Dmitry
Zuikov
Status: collecting materials for issue #3
Further reading
http://ro-che.info/ccc/

“Practice of Functional Programing” is a Russian elec-

tronic magazine promoting functional programming,
with articles that cover both theoretical and practical
aspects of the craft. Most of the material of the already
published issues is directly related to Haskell.
The magazine aims to have a bi-monthly release
schedule, with Issue #3 slated for release at the end
of November 2009.
Full contents of current and past issues are available
in PDF from the official site of the magazine free of
charge.
Articles are in Russian, with English annotations.

Further reading
http://fprog.ru for issues #1 and #2

1.7 Cartesian Closed Comic

Report by: Roman Cheplyaka
Participants: Maria Kovalyova
Cartesian Closed Comic, or CCC, is a webcomic about
Haskell, the Haskell community, and anything else re-
lated to Haskell. It is published irregularly. The comic
is often inspired by “Quotes of the week” published in
Haskell Weekly News. New strips are posted to the
Haskell reddit and Planet Haskell. The archives are
also available.
Here goes a special edition of the CCC devoted to
the Haskell Communities and Activities Report.

9
2 Implementations

◦ The I/O libraries are now Unicode-aware, so your

Haskell programs should now handle text files con-
2.1 The Glasgow Haskell Compiler
taining non-ascii characters, without special effort.
Report by: Simon Peyton Jones ◦ The package system has been made more robust,
Participants: many others by associating each installed package with a unique
identifier based on its exposed ABI. Now, cases where
We are just about to make our annual major release, of the user re-installs a package without recompiling
GHC 6.12.1 (in the following we will say “GHC 6.12” packages that depend on it will be detected, and the
to refer to GHC 6.12.1 and future patch-level releases packages with broken dependencies will be disabled.
along the 6.12 branch). Previously, this would lead to obscure compilation
GHC continues to be very active, with many oppor- errors, or worse, segfaulting programs.
tunities for others to get involved. We are particularly This change involved a lot of internal restructuring,
eager to find partners who are willing to take respon- but it paves the way for future improvements to the
sibility for a particular platform (e.g. Sparc/Solaris, way packages are handled. For instance, in the future
currently maintained by Ben Lippmeier); see http: we expect to track profiled packages independently
//hackage.haskell.org/trac/ghc/wiki/Platforms. of non-profiled ones, and we hope to make it possi-
ble to upgrade a package in an ABI-compatible way,
The GHC 6.12 release without recompiling the packages that depend on it.
This latter facility will be especially important as we
We usually try to make a major release of GHC im-
move towards using more shared libraries.
mediately after ICFP. It has been somewhat delayed
this year, but we expect to release GHC 6.12 during ◦ There are a variety of small language changes, in-
November or December 2009. Apart from the myriad cluding
of new bug fixes and minor enhancements, the big new
– Some improvements to data types: record pun-
things in 6.12 are:
ning, declaring constructors with class con-
◦ Considerably improved support for parallel execu- straints, GADT syntax for type families etc.
tion. GHC 6.10 would execute parallel Haskell pro- – You can omit the “$” in a top-level Template
grams, but performance was often not very good. Si- Haskell splice, which makes the TH call look
mon Marlow has done lots of performance tuning in more like an ordinary top-level declaration with
6.12, removing many of the accidental (and largely a new keyword.
invisible) gotchas that made parallel programs run – We are are deprecating mdo for recursive do-
slowly. notation, in favour of the more expressive rec
◦ As part of this parallel-performance tuning, Satnam statement.
Singh and Simon Marlow have developed Thread- – We have concluded that the implementation
Scope, a GUI that lets you see what is going on inside of impredicative polymorphism is unsustainably
your parallel program. It is a huge step forward from complicated, so we are re-trenching. It will be
“It takes 4 seconds with 1 processor, and 3 seconds deprecated in 6.12 (but will still work), and will
with 8 processors; now what?”. ThreadScope will be be either removed or replaced with something
released separately from GHC, but at more or less simpler in 6.14.
the same time as GHC 6.12.
For more detail, see the release notes in the 6.12
◦ Dynamic linking is now supported on Linux, and User manual (http://www.haskell.org/ghc/dist/current/
support for other platforms will follow. Thanks for docs/html/users_guide/index.html), which mention
this most recently go to the Industrial Haskell Group many things skipped over here.
(→ 7.8) who pushed it into a fully-working state; dy- Internally, GHC 6.12 has a totally re-engineered
namic linking is the culmination of the work of sev- build system, with much-improved dependency
eral people over recent years. One effect of dynamic tracking (http://hackage.haskell.org/trac/ghc/wiki/
linking is that binaries shrink dramatically, because Building). While there have been lots of teething
the run-time system and libraries are shared. Per- problems, things are settling down and the new system
haps more importantly, it is possible to make dy- is a huge improvement over the old one. The main
namic plugins from Haskell code that can be used improvement is that you can usually just say make,
from other applications. and everything will be brought up to date (before it

10
was often necessary to make clean first). Another and the newtype-deriving can persuade GHC to gener-
improvement is that the new system exposes much ate type-unsound code. It has remained un-fixed be-
more parallelism in the build, so GHC builds faster on cause the obvious approaches seem to be hacks, so the
multicores. cure was as bad as the disease. We think we are on to
something; stay tuned.
GHC and the Haskell platform
Intermediate language and optimisation
Another big change with GHC 6.12 is that Hackage
and the Haskell Platform are allowing GHC HQ to get Although it is, by design, invisible to users, GHC’s in-
out of the libraries business. So the plan is: termediate language and optimisation passes have been
receiving quite a bit of attention. Some highlights:
◦ We release GHC 6.12 with very few libraries.
◦ Read Max Bolingbroke’s paper on Strict Core
◦ Bill Library Author downloads GHC 6.12 and tests [MaxB], a possible new intermediate language for
his libraries. GHC. Adopting Strict Core would be a Big Change,
◦ The next Haskell Platform release packages GHC however, and we have not decided to do so (yet).
6.12 with these tested libraries. ◦ Simon PJ totally re-engineered the way that
◦ Joe User downloads the Haskell Platform. INLINE pragmas are implemented, with the
goal of making them more robust and pre-
◦ Four months later there is a new HP release, still dictable (http://www.haskell.org/pipermail/cvs-ghc/
with GHC 6.12, but with more or better libraries. 2009-October/050881.html). There is a new CON-
The HP release cycle is decoupled from GHC. LIKE pragma which affects rule matching.
So if you are Joe User, you want to wait for the HP re- ◦ Peter Jonsson did an internship in which he made
lease. Do not grab the GHC 6.12 release. It will be per- a start on turning GHC into a supercompiler. Neil
fectly usable, but only if you use (an up to date) cabal- Mitchell’s terrific PhD thesis suggested that super-
install to download libraries, and accept that they may compliation works well for Haskell [NeilM], and Pe-
not be tested with GHC 6.12. ter has been working on supercompilation for Tim-
ber (→ 3.2.4) as part of his own PhD [PeterJ]. The
What is hot for the next year GHC version is not ready for prime time yet, but
Simon PJ (now educated by Peter and Neil) is keen
GHC continues to be a great substrate for research. to pursue it.
Here are the main things we are working on at the
moment. ◦ An internal change in GHC 6.12 is the addition
of “annotations”, a general-purpose way for a pro-
Type systems grammer to add annotations to top-level definitions
that can be consulted by a core-to-core pass, and
Type families have proved a great success. From the for a core-to-core pass to pass information to its
outside it might seem that they are done — after all, successors (http://hackage.haskell.org/trac/ghc/wiki/
they are in GHC 6.10 — but the internals are quite frag- Annotations). We expect to use these annotations in-
ile and it is amazing that it all works as well as it does. creasingly in GHC itself.
(Thanks to Manuel’s work.) Tom Schrijvers, Dimitrios
Vytiniotis, Martin Sulzmann, and Manuel Chakravarty
Parallelism
have been working with Simon PJ to understand the
fundamentals and, in the light of that insight, to re- Most of the changes in this area in GHC 6.12.1 were
engineer the implementation into something more ro- described in our ICFP’09 paper “Runtime Support for
bust. We have developed the “OutsideIn” algorithm, Multicore Haskell” [ICFP09b]. The highlights:
which gives a much nicer account of type inference than
our previous story of type inference. The new approach ◦ Load-balancing of sparks is now based on lock-free
is described in “Complete and Decidable Type Infer- work-stealing queues.
ence for GADTs” [ICFP09a]. More controversially, we ◦ The overhead for running a spark is significantly less,
now believe that local let/where bindings should not be so GHC can take advantage of finer-grained paral-
generalised — see “Let should not be generalised” [Let- lelism
Gen]. Dimitrios is building a prototype that embodies
these ideas, which we will then transfer into GHC. ◦ The parallel GC is now much more locality-aware.
Meanwhile, Dimitrios, Simon, and Stephanie Weirich We now do parallel GC in young-generation collec-
are also working on fixing one of GHC’s more em- tions by default, mainly to avoid destroying locality
barrassing bugs (http://hackage.haskell.org/trac/ghc/ by moving data out of the CPU cache on which it
ticket/1496), whereby an interaction of type families is needed. Young-generation collections are parallel

11
 but not load-balanced. There are new RTS flags to
control parallel GC behaviour.
◦ Various other minor performance tweaks.
In the future we plan to focus on the GC, with the main
goal being to implement independent per-CPU collec-
tion. The other area we plan to look at is changing the
GC policy for sparks, as described in our ICFP’09 pa-
per; this will need a corresponding change to the Strate-
gies library to avoid relying on the current “sparks are
roots” GC policy, which causes difficulties for writing
parallel code that exploits speculation.
Data Parallelism
Data Parallel Haskell has seen few user-visible changes
since the last report. Nevertheless, Roman Leshchin-
skiy has been busy improving many of the fundamen-
tal building blocks behind the scenes. These changes
were necessary as DPH was able to generate very fast
parallel code for simple examples, but the optimisa-
tion infrastructure was too fragile — i.e., small changes
to other parts of GHC (most notably, the Simplifier)
or to the DPH libraries could lead to dramatic per-
formance regressions. Over the last few months, Ro-
man has been working on making the system more
robust, while Simon PJ improved and extended parts
of GHC’s existing optimisation infrastructure (such as
the Inliner and other aspects of the Simplifier) to sup-
port Roman’s efforts. As a first consequence of this
recent work, the divide-and-conquer quickhull bench-
mark (computing a convex hull) is now significantly
faster than the corresponding list-based implementa-
tion (http://darcs.haskell.org/packages/dph/examples/
quickhull/QuickHullVect.hs). This is an important mile-
stone as quickhull uses dynamically nested parallelism
whose depth is not statically bound.
Gabriele Keller implemented a first prototype of a
new library API for regular multi-dimensional arrays
to complement the existing irregular, nested arrays.
For regular computations on dense matrices, relax-
ation methods and similar, regular arrays (as opposed
to nested arrays) are more convenient and expose ad-
ditional opportunities for optimisation. Gabriele ob-
tained very encouraging first results with a sequential
version that uses a new fusion technique, which we are
calling delayed arrays [RegLibBench].
In parallel with the implementation of regular,
multi-dimensional arrays as part of DPH, Sean
Lee and Manuel Chakravarty are implementing al-
most the same regular-array API as an EDSL in
Data.Array.Accelerate. The EDSL implementation re-
stricts the expressiveness of the array language, but at
the same time enables us to experiment with more am-
bitious backends — especially with GPU code genera-
tion via CUDA and related technologies. More details
are in the video of Manuel’s talk from the Haskell Im-
plementors Workshop in Edinburgh [AccelerateTalk].
12
Code generation
For the last two years we have been advertising a major
upheaval in GHC’s back end. Currently a monolithic
“code generator” converts lambda code (the STG lan-
guage) into flat C–; “flat” in the sense that the stack
is manifested, and there are no function calls. The
upheaval splits this into a pipeline of passes, with a
relatively-simple conversion of lambda code into C–
(with function calls), followed by a succession of passes
that optimise this code, and flatten it (by manifesting
the stack and removing calls).
John Dias is the principal architect of this new path,
and it is in GHC already; you can switch it on by say-
ing -fnew-codegen. What remains is (a) to make it
work 100% (currently 99%, which is not good enough);
(b) commit to it, which will allow us to remove gar-
gantuan quantities of cruft; (c) exploit it, by imple-
menting cool new optimisations at the C– level; (d)
take it further by integrating the native code gen-
erators into the same pipeline. You can read more
on the wiki (http://hackage.haskell.org/trac/ghc/wiki/
Commentary/Compiler/NewCodeGenPipeline).
Several passes of the new code generation pipeline
are supported by Hoopl, a Haskell library that makes
it easy to write dataflow analyses and optimisations
over C– code [Hoopl]. We think Hoopl is pretty cool,
and have well-advanced ideas for how to improve it a
lot more.
All of this has taken longer than we hoped. Once
the new pipeline is in place we hope that others will
join in. For example, David Terei did an interesting
undergraduate project on using LLVM as a back end
for GHC [Terei], and Krzysztof Wos is just beginning
an undergraduate project on optimisation in the new
pipeline. We are particularly grateful to Ben Lippmeier
for his work on the SPARC native code generator.
Bibliography
ICFP09a Complete and Decidable Type Inference for
GADTs. Tom Schrijvers, Simon Peyton Jones, Mar-
tin Sulzmann, and Dimitrios Vytiniotis. ICFP’09.
http://research.microsoft.com/~simonpj/papers/gadt
ICFP09b Runtime Support for Multicore Haskell. Si-
mon Marlow, Satnam Singh, and Simon Peyton
Jones. ICFP’09. http://www.haskell.org/~simonmar/
bib/multicore-ghc-09_abstract.html
LetGen Let should not be generalized. Dimitrios Vy-
tiniotis, Simon Peyton Jones, and Tom Schrijvers.
TLDI’10. http://research.microsoft.com/~simonpj/
papers/constraints/index.htm
Hoopl Hoopl: dataflow optimisation made simple.
Norman Ramsey, John Dias, and Simon Peyton
Jones. Rejected by POPL’10. http://research.
microsoft.com/~simonpj/papers/c--
Terei Low Level Virtual Machine for Glasgow Haskell type inferencing and code generating still need to be
Compiler. David A. Terei, BSc Thesis. http://www. added. The work on the documentation has progressed
cse.unsw.edu.au/~pls/thesis/davidt-thesis.pdf quite a bit, but there has been little testing thus far,
especially on a platform such as Windows.
MaxB Types are calling conventions. Max Boling-
broke and Simon Peyton Jones. Haskell Sym-
posium 2009. http://www.cl.cam.ac.uk/~mb566/ 2.3 UHC, Utrecht Haskell Compiler
papers/tacc-hs09.pdf
Report by: Atze Dijkstra
NeilM Transformation and Analysis of Functional Pro- Participants: Jeroen Fokker, Doaitse Swierstra, Arie
grams. Neil Mitchell, PhD thesis, University of York, Middelkoop, Lucília Camarão de
2009. http://community.haskell.org/~ndm/thesis/ Figueiredo, Carlos Camarão de Figueiredo,
Vincent van Oostrum, Clemens
PeterJ Positive supercompliation for a higher order Grabmayer, Tom Lokhorst, Jeroen
call-by-value language. Peter Jonsson and Johan Leeuwestein, Atze van der Ploeg, Paul van
Nordlander. POPL’09. http://www.csee.ltu.se/~pj/ der Ende
papers/scp/index.html Status: active development

RegLibBench Dense matrix-matrix multiplica-

tion benchmark with delayed, regular ar- UHC, what is new? UHC is the Utrecht Haskell
rays. http://www.scribd.com/doc/22091707/ Compiler, supporting almost all Haskell 98 features
Delayed-Regular-Arrays-Sep09 plus experimental extensions. The first release of UHC
was announced on April 18, 2009, at the 5th Haskell
AccelerateTalk Haskell Array, Accelerated (Using Hackathon, held in Utrecht.
GPUs). Manuel M T Chakravarty, presented Since then we have been working on:
at the Haskell Implementors Workshop 2009,
Edinburgh. http://justtesting.posterous.com/ ◦ A new garbage collector (GC) to replace the Boehm
running-haskell-array-computations-on-a-gpu GC we have been using. The new GC is constructed
relatively independent of the UHC runtime system,
so as to allow multiple backends to plugin backend
specific info, e.g., about the memory layout of mem-
2.2 The Helium compiler ory cells. The new GC is used by the bytecode in-
terpreter backend (Atze Dijkstra).
Report by: Jurriaan Hage
Participants: Bastiaan Heeren, Arie Middelkoop ◦ Making nofib testsuite examples run. This also has
Helium is a compiler that supports a substantial sub- been the driving force and testbed for the new GC
set of Haskell 98 (but, e.g., n+k patterns are missing). (Jeroen Fokker).
Type classes are restricted to a number of built-in type ◦ Typed core, which combines GHC’s core language
classes and all instances are derived. The advantage of with Henk and recent work on types as calling con-
Helium is that it generates novice friendly error feed- ventions (Atze Dijkstra).
back. The latest versions of the Helium compiler are
available for download from the new website located
UHC, what do we plan? Soon we start working on
at http://www.cs.uu.nl/wiki/Helium. This website also
the research grant for “Realising Optimal Sharing”,
explains in detail what Helium is about, what it offers,
based on work by Vincent van Oostrum and Clemens
and what we plan to do in the near and far future.
Grabmayer.
We are still working on making version 1.7 available,
We plan a next release of UHC with the new garbage
mainly a matter of updating the documentation and
collector and various bugfixes. We had hoped to offer
testing the system. Internally little has changed, but
a complete Haskell 98 library and Cabal support, but
the interface to the system has been standardized, and
likely this will have to wait for a subsequent release.
the functionality of the interpreters has been improved
Furthermore, the following student projects are un-
and made consistent. We have made new options avail-
derway or soon start:
able (such as those that govern where programs are
logged to). The use of Helium from the interpreters is ◦ Various static analyses on typed core (Tom
now governed by a configuration file, which makes the Lokhorst).
use of Helium from the interpreters quite transparent
for the programmer. It is also possible to use differ- ◦ Incrementalization of whole program analysis
ent versions of Helium side by side (motivated by the (Jeroen Leeuwestein).
development of Neon (→ 5.3.3)). ◦ Lazy closures (Atze van der Ploeg).
A student has added parsing and static checking for
type class and instance definitions to the language, but ◦ GC & LLVM (Paul van der Ende).

13
 Finally, still going on are the following: ◦ Shuffle: http://www.cs.uu.nl/wiki/Ehc/Shuffle
◦ Ruler: http://www.cs.uu.nl/wiki/Ehc/Ruler
◦ GRIN backend, whole program analysis (Jeroen
Fokker).
2.4 Haskell frontend for the Clean
◦ Type system formalization and automatic generation compiler
from type rules (Lucília Camarão de Figueiredo, Arie
Middelkoop). Report by: Thomas van Noort
Participants: John van Groningen, Rinus Plasmeijer
Background info UHC actually is a series of com- Status: active development
pilers of which the last is UHC, plus an aspectwise We are currently working on a frontend for the Clean
organized infrastructure for facilitating experimenta- compiler (→ 3.2.3) that supports a subset of Haskell 98.
tion and extension. The end-user will probably only be This will allow Clean modules to import Haskell mod-
aware of UHC as a Haskell compiler, whereas compiler ules, and vice versa. Furthermore, we will be able to
writers will be more aware of the internals of UHC. use some of Clean’s features in Haskell code, and vice
For the description of UHC an Attribute Grammar versa. For example, we could define a Haskell module
system (→ 4.1.1) is used as well as other formalisms al- which uses Clean’s uniqueness typing, or a Clean mod-
lowing compact notation like parser combinators. For ule which uses Haskell’s newtypes. The possibilities are
the description of type rules, and the generation of an endless!
AG implementation for those type rules, we use the
Ruler system. For source code management we use Future plans
Shuffle, which allows partitioning the system into a se-
quence of steps and aspects. (Both Ruler and Shuffle Although a beta version of the new Clean compiler is
are included in UHC). released early this year to the institution in Nijmegen,
The implementation of UHC also tackles other issues: there is still a lot of work to do before we are able to
release it to the outside world. So we cannot make any
◦ To deal with the inherent complexity of a compiler, promises regarding the release date. Just keep an eye
the implementation of UHC is organized as a series on the Clean mailing lists for any important announce-
of increasingly complex steps. Each step corresponds ments!
to a Haskell subset which itself is an extension of the
previous step. The first step starts with the essen- Further reading
tials, namely typed lambda calculus; the last step
corresponds to UHC. http://wiki.clean.cs.ru.nl/Mailing_lists

◦ Independent of each step the implementation is or-

ganized into a set of aspects. Currently the type 2.5 SAPL, Simple Application
system and code generation are defined as aspects, Programming Language
which can then be left out so the remaining part can
be used as a barebones starting point. Report by: Jan Martin Jansen
Status: experimental, active development
◦ Each combination of step + aspects corresponds to SAPL is an experimental interpreter for a lazy func-
an actual, that is, an executable compiler. Each of tional intermediate language. The language is more or
these compilers is a compiler in its own right. less equivalent to the core language of Clean (→ 3.2.3).
◦ The description of the compiler uses code fragments SAPL implementations in C and Java exist. It is possi-
which are retrieved from the source code of the com- ble the write SAPL programs directly, but the preferred
pilers. In this way the description and source code use is to generate SAPL. We already implemented an
are kept synchronized. experimental version of the Clean compiler that gen-
erates SAPL as well. The Java version of the SAPL
Part of the description of the series of EH compilers interpreter can be loaded as a PlugIn in web applica-
is available as a PhD thesis. tions. Currently we use it to evaluate tasks from the
iTask system (→ 6.8.1) at the client side and to handle
Further reading (mouse) events generated by a drawing canvas PlugIn.

◦ UHC Homepage: http://www.cs.uu.nl/wiki/UHC/

WebHome
◦ Attribute grammar system: http://www.cs.uu.nl/
wiki/HUT/AttributeGrammarSystem
◦ Parser combinators: http://www.cs.uu.nl/wiki/HUT/
ParserCombinators
Future plans
For the near future we have planned to make the Clean
to SAPL compiler available in the standard Clean dis-
tribution. Also some further performance improve-
ments of SAPL are planned.

14
Further reading
◦ http://home.hetnet.nl/~janmartinjansen/saplinter
◦ http://home.hetnet.nl/~janmartinjansen/lambda
◦ http://www.st.cs.ru.nl/Onderzoek/Publicaties/
publicaties.html
2.6 The Reduceron
Report by: Matthew Naylor
Participants: Colin Runciman, Jason Reich
Status: experimental
Over the past year, work on the Reduceron has contin-
ued, and we have reached our goal of improving runtime
performance by a factor of six! This has been achieved
through many small improvements, spanning architec-
tural, runtime, and compiler-level advances.
Two main by-products have emerged from the work.
First, York Lava, now available from Hackage, is the
HDL we use. It is very similar to Chalmers Lava,
but supports a greater variety of primitive components,
behavioural description, number-parameterised types,
and a first attempt at a Lava prelude. Second, F-lite is
our subset of Haskell, with its own lightweight toolset. 2.7.2 Fedora Haskell SIG
There remain some avenues for exploration. We have
taken a step towards parallel reduction in the form of
speculative evaluation of primitive redexes, but have
not yet attempted the Reducera — multiple Reducerons
running in parallel. And recently, Jason has been con-
tinuing his work on the F-lite supercompiler (→ 4.1.4),
which is now producing some really nice results.
Alas, the time to take stock and publish a full ac- The Fedora Haskell SIG is an effort to provide good
count of what we have already done is rapidly ap- support for Haskell in Fedora.
proaching!
Further reading
◦ http://www.cs.york.ac.uk/fp/reduceron/
◦ http://hackage.haskell.org/package/york-lava/
2.7 Platforms
2.7.1 Haskell in Gentoo Linux
Report by: Lennart Kolmodin
Gentoo Linux currently supports GHC 6.10.4, includ-
ing the latest Haskell Platform (→ 5.2) for x86 and
amd64. For previous GHC versions we have binaries 2.7.3 GHC on OpenSPARC
available for alpha, amd64, hppa, ia64, sparc, and x86.
Browse the packages in portage at http://packages.
gentoo.org/category/dev-haskell?full_cat.
The GHC architecture/version matrix is available at
http://packages.gentoo.org/package/dev-lang/ghc.
Please report problems in the normal Gentoo bug Through January–April this year I repaired GHC’s
tracker at bugs.gentoo.org.
There is also a Haskell overlay providing another 300
packages. Thanks to the haskell developers using Cabal
and Hackage (→ 5.1), we have been able to write a
tool called “hackport” (initiated by Henning Günther)
to generate Gentoo packages that rarely need much
tweaking.
Read about the Gentoo Haskell Overlay at http://
haskell.org/haskellwiki/Gentoo. Using Darcs (→ 6.1.1),
it is easy to keep updated and send patches. It is
also available via the Gentoo overlay manager “lay-
man”. If you choose to use the overlay, then problems
should be reported on IRC (#gentoo-haskell on freen-
ode), where we coordinate development, or via email
hhaskell@gentoo.orgi.
Through recent efforts we have devoped a tool called
“haskell-updater” http://www.haskell.org/haskellwiki/
Gentoo#haskell-updater. It helps the user when up-
grading GHC versions, fixes breakages from library up-
grades, etc.
As always we are happy to get help hacking on the
Gentoo Haskell framework, hackport, writing ebuilds,
and supporting users. Please contact us on IRC or
email if you are interested!
Report by: Jens Petersen
Participants: Bryan Sullivan, Yaakov Nemoy, Zach
Oglesby, Conrad Meyer, Fedora Haskell
SIG
Status: on-going
Fedora 12 has just shipped with ghc-6.10.4, haskell-
platform-2009.2.0.2, xmonad, and various new libraries
(cgi, editline, fgl, GLUT, network, OpenGL, tar, time,
utf8-string, X11-xft, xmonad-contrib).
Fedora 13 is expected to ship with ghc-6.12 with
shared libraries, and more new packages in about 6
months.
Contributions to Fedora Haskell are welcome: join
us on #fedora-haskell on Freenode IRC.
Further reading
◦ http://fedoraproject.org/wiki/SIGs/Haskell
◦ http://fedoraproject.org/wiki/Documentation_
Development_Tools_Beat#Haskell
Report by: Ben Lippmeier
Participants: Duncan Coutts, Darryl Gove, Roman
Leshchinskiy
Status: winding down
back end support for the SPARC architecture, and
15
benchmarked its performance on haskell.org’s shiny
new SPARC T2 server. I also spent time refactoring
GHC’s native code generator to make it easier to un-
derstand and maintain, and thus less likely for pieces
to suffer bit-rot in the future.
The T2 architecture is interesting to functional pro-
grammers because of its highly multi-threaded nature.
The T2 has eight cores with eight hardware threads
each, for a total of 64 threads per processor. When one
of the threads suffers a cache miss, another can continue
on with little context switching overhead. All threads
on a particular core also share the same L1 cache, which
supports fast thread synchronization. This is a perfect
fit for parallel lazy functional programs, where mem-
ory traffic is high, but new threads are only a par
away. The following graph shows the performance of
the sumeuler benchmark from the nofib suite when run-
ning on the T2. Note that the performance scales al-
most linearly (perfectly) right up to the point where it
runs out of hardware threads.

The project is nearing completion, pending tying up

some loose ends, but the port is fully functional and
available in the current head branch. More informa-
tion, including benchmarking is obtainable form the
link below. The GHC on OpenSPARC project was gen-
erously funded by Sun Microsystems.

Further reading
http://ghcsparc.blogspot.com

16
3 Language

3.1 Extensions of Haskell various activities and develop the common parallel run-
time environment further.
3.1.1 Eden Parallel program executions can be visualized using
the Eden trace viewer tool EdenTV. Recent results
Report by: Rita Loogen show that the Eden system behaves equally well on
Participants: in Madrid: Ricardo Peña, Yolanda workstation clusters and on multi-core machines.
Ortega-Mallén, Mercedes Hidalgo,
Fernando Rubio, Alberto de la Encina,
Lidia Sánchez-Gil Recent and Forthcoming Publications
in Marburg: Jost Berthold, Mischa
◦ Mischa Dieterle, Thomas Horstmeyer, Rita Loogen:
Dieterle, Thomas Horstmeyer, Oleg
Skeleton Composition Using Remote Data, in: Prac-
Lobachev, Rita Loogen
Status: ongoing tical Aspects of Declarative Programming 2010
(PADL’10), Madrid, Spain, January 2010, Springer
LNCS, to appear.
Eden extends Haskell with a small set of syntactic con- ◦ Alberto de la Encina, I. Rodríguez, Fernando Ru-
structs for explicit process specification and creation. bio: pHood: A Tool to Analyze Parallel Func-
While providing enough control to implement paral- tional Programs, in: Symposium on the Implementa-
lel algorithms efficiently, it frees the programmer from tion and Application of Functional Languages (IFL)
the tedious task of managing low-level details by intro- 2009, Technical Report, SHU-TR-CS-2009-09-1, Se-
ducing automatic communication (via head-strict lazy ton Hall University, New York, USA, September
lists), synchronization, and process handling. 2009, 85–99.
Eden’s main constructs are process abstractions and ◦ Jost Berthold, Mischa Dieterle, and Rita Loogen:
process instantiations. The function process :: (a Implementing Parallel Google Map-Reduce in Eden,
-> b) -> Process a b embeds a function of type (a in: EuroPar 2009, Delft, NL, Springer LNCS 5704,
-> b) into a process abstraction of type Process a b 990–1002.
which, when instantiated, will be executed in paral- ◦ Jost Berthold, Mischa Dieterle, Oleg Lobachev, Rita
lel. Process instantiation is expressed by the prede- Loogen: Parallel FFT With Eden Skeletons, in
fined infix operator ( # ) :: Process a b -> a -> PaCT 2009, Novosibirsk, Russia, Springer LNCS
b. Higher-level coordination is achieved by defining 5698, 73–83.
skeletons, ranging from a simple parallel map to so- ◦ Jost Berthold, Simon Marlow, Abyd Al Zain, and
phisticated replicated-worker schemes. They have been Kevin Hammond: Comparing and optimising par-
used to parallelize a set of non-trivial benchmark pro- allel Haskell implementations on multicore, In To-
grams. moya Enokido et al.,editors, 3rd Int. Workshop on
Advanced Distributed and Parallel Network Applica-
tions (ADPNA-2009) IEEE Computer Society, 2009.
Survey and standard reference ◦ Lidia Sánchez-Gil, Mercedes Hidalgo-Herrero,
Rita Loogen, Yolanda Ortega-Mallén, and Ri- Yolanda Ortega-Mallén: An Operational Semantics
cardo Peña: Parallel Functional Programming in Eden, for Distributed Lazy Evaluation, Trends in Func-
Journal of Functional Programming 15(3), 2005, pages tional Programming, Volume 10, Intellect 2009, to
431–475. appear.
◦ Thomas Horstmeyer, Rita Loogen: Grace — Graph-
based Communication in Eden, Trends in Functional
Implementation Programming, Volume 10, Intellect 2009, to appear.
A major revision of the parallel Eden runtime envi-
ronment for GHC 6.8.1 is available from the Mar- Further reading
burg group on request. Support for Glasgow parallel http://www.mathematik.uni-marburg.de/~eden
Haskell (http://haskell.org/communities/05-2009/html/
report.html#sect3.1.2) is currently being added to this
version of the runtime environment. It is planned for 3.1.2 XHaskell project
the future to maintain a common parallel runtime en-
Report by: Martin Sulzmann
vironment for Eden, GpH, and other parallel Haskells. Participants: Kenny Zhuo Ming Lu
A parallel Haskell Hackathon will take place in St An- Status: stable
drews from December 10th till 12th, 2009 to join the

17
XHaskell is an extension of Haskell which combines
parametric polymorphism, algebraic data types, and
type classes with XDuce style regular expression types,
subtyping, and regular expression pattern matching.
The latest version can be downloaded via http://code.
google.com/p/xhaskell/
Latest developments
The latest version of the library-based regular expres-
sion pattern matching component is available via the
google code web site. We are currently working on a
paper describing the key ideas of the approach.
3.1.3 HaskellActor
Report by: Martin Sulzmann
Status: stable
The focus of the HaskellActor project is on
Erlang-style concurrency abstractions. See for
details: http://sulzmann.blogspot.com/2008/10/
actors-with-multi-headed-receive.html.
Novel features of HaskellActor include
◦ Multi-headed receive clauses, with support for
◦ guards, and
◦ propagation
The HaskellActor implementation (as a library ex-
tension to Haskell) is available via http://hackage.
haskell.org/cgi-bin/hackage-scripts/package/actor.
The implementation is stable, but there is plenty of
room for optimizations and extensions (e.g. regular
expressions in patterns). If this sounds interesting to
anybody (students!), please contact me.
Latest developments
We are currently working towards a distributed ver-
sion of Haskell actor following the approach of Frank
Huch, Ulrich Norbisrath: Distributed Programming in
Haskell with Ports, IFL’00.
3.1.4 HaskellJoin
Report by: Martin Sulzmann
Status: stable
HaskellJoin is a (library) extension of Haskell to sup-
port join patterns. Novelties are
◦ guards and propagation in join patterns,
◦ efficient parallel execution model which exploits mul-
tiple processor cores.
18
Latest developments
In this honors thesis, Olivier Pernet (a student of Susan
Eisenbach) provides a nicer monadic interface to the
HaskellJoin library.
Further reading
http://sulzmann.blogspot.com/2008/12/
parallel-join-patterns-with-guards-and.html
3.2 Related Languages
3.2.1 Curry
Report by: Jan Christiansen
Participants: Bernd Braßel, Michael Hanus, Wolfgang
Lux, Sebastian Fischer, and others
Status: active development
Curry is a functional logic programming language with
Haskell syntax. In addition to the standard features of
functional programming like higher-order functions and
lazy evaluation, Curry supports features known from
logic programming. This includes programming with
non-determinism, free variables, constraints, declara-
tive concurrency, and the search for solutions. Al-
though Haskell and Curry share the same syntax, there
is one main difference with respect to how function dec-
larations are interpreted. In Haskell the order in which
different rules are given in the source program has an
effect on their meaning. In Curry, in contrast, the rules
are interpreted as equations, and overlapping rules in-
duce a non-deterministic choice and a search over the
resulting alternatives. Furthermore, Curry allows to
call functions with free variables as arguments so that
they are bound to those values that are demanded for
evaluation, thus providing for function inversion.
There are three major implementations of Curry.
While the original implementation PAKCS (Portland
Aachen Kiel Curry System) compiles to Prolog, MCC
(Münster Curry Compiler) generates native code via a
standard C compiler. The Kiel Curry System (KiCS)
compiles Curry to Haskell aiming to provide nearly
as good performance for the purely functional part as
modern compilers for Haskell do. From these imple-
mentations only MCC will provide type classes in the
near future. Type classes are not part of the current
definition of Curry, though there is no conceptual con-
flict with the logic extensions.
Recently, new compilation schemes for translating
Curry to Haskell have been developed that promise sig-
nificant speedups compared to both the former KiCS
implementation and other existing implementations of
Curry.
There have been research activities in the area of
functional logic programming languages for more than
a decade. Nevertheless, there are still a lot of inter-
esting research topics regarding more efficient compila-
tion techniques and even semantic questions in the area making real-world applications. Clean is the only func-
of language extensions like encapsulation and function tional language in the world which offers uniqueness
patterns. Besides activities regarding the language it- typing. This type system makes it possible in a pure
self, there is also an active development of tools con- functional language to incorporate destructive updates
cerning Curry (e.g., the documentation tool Curry- of arbitrary data structures (including arrays) and to
Doc, the analysis environment CurryBrowser, the ob- make direct interfaces to the outside imperative world.
servation debuggers COOSy and iCODE, the debugger Here is a short list with notable features:
B.I.O. (http://www-ps.informatik.uni-kiel.de/currywiki/
tools/oracle_debugger), EasyCheck (http://haskell.org/ ◦ Clean is a lazy, pure, and higher-order functional pro-
communities/05-2009/html/report.html#sect4.3.2), and gramming language with explicit graph rewriting se-
CyCoTest). Because Curry has a functional subset, mantics.
these tools can canonically be transferred to the func-
◦ Although Clean is by default a lazy language, one can
tional world.
smoothly turn it into a strict language to obtain op-
timal time/space behavior: functions can be defined
Further reading lazy as well as (partially) strict in their arguments;
any (recursive) data structure can be defined lazy as
◦ http://www.curry-language.org/
well as (partially) strict in any of its arguments.
◦ http://wiki.curry-language.org/
◦ Clean is a strongly typed language based on an ex-
3.2.2 Agda tension of the well-known Milner/Hindley/Mycroft
type inferencing/checking scheme including the com-
Report by: Nils Anders Danielsson mon higher-order types, polymorphic types, abstract
Participants: Ulf Norell and many others types, algebraic types, type synonyms, and existen-
Status: actively developed tially quantified types.
◦ The uniqueness type system in Clean makes it possi-
Agda is a dependently typed functional programming ble to develop efficient applications. In particular, it
language (developed using Haskell). A central feature allows a refined control over the single threaded use
of Agda is inductive families, i.e. GADTs which can be of objects which can influence the time and space
indexed by values and not just types. The language behavior of programs. The uniqueness type system
also supports coinductive types, parameterized mod- can be also used to incorporate destructive updates
ules, and mixfix operators, and comes with an interac- of objects within a pure functional framework. It al-
tive interface—the type checker can assist you in the lows destructive transformation of state information
development of your code. and enables efficient interfacing to the non-functional
A lot of work remains in order for Agda to become a world (to C but also to I/O systems like X-Windows)
full-fledged programming language (good libraries, ma- offering direct access to file systems and operating
ture compilers, documentation, etc.), but already in its systems.
current state it can provide lots of fun as a platform
for experiments in dependently typed programming. ◦ The Clean type system supports dynamic types, al-
New since last time: lowing values of arbitrary types to be wrapped in a
uniform package and unwrapped via a type anno-
◦ Version 2.2.4 has been released. tation at run-time. Using dynamics, code and data
can be exchanged between Clean applications in a
◦ Agda is now available in Ubuntu. flexible and type-safe way.
◦ Darin Morrison is currently extending Cabal to sup- ◦ Clean supports type classes and type constructor
port Agda code. classes to make overloaded use of functions and op-
erators possible.
Further reading
◦ Clean offers records and (destructively updateable)
The Agda Wiki: http://wiki.portal.chalmers.se/agda/ arrays and files.
◦ Clean has pattern matching, guards, list comprehen-
3.2.3 Clean sions, array comprehensions and a lay-out sensitive
Report by: Thomas van Noort
mode.
Participants: Rinus Plasmeijer, John van Groningen◦ Clean offers a sophisticated I/O library with which
Status: active development
window based interactive applications (and the han-
Clean is a general purpose, state-of-the-art, pure and dling of menus, dialogs, windows, mouse, keyboard,
lazy functional programming language designed for timers, and events raised by sub-applications) can

19
 be specified compactly and elegantly on a very high timber-lang.org. A bug-fix release (v 1.0.3) was made
level of abstraction. available in May 2009.
The current source code repository (also available
◦ There is a Clean IDE and there are many libraries on-line) includes a new way of organizing external in-
available offering additional functionality. terfaces, which separates access to OS, hardware or li-
brary services from the definition of a particular run-
Future plans time system. This move greatly simplifies the construc-
tion of both external bindings and cross-compilation
Please see the entry on a Haskell frontend for the Clean targets, which is utilized in on-going development of
compiler (→ 2.4) for the future plans. Xlib, OpenGL, iPhone as well as ARM7 support.
Other active projects include interfacing the compiler
Further reading to memory and execution-time analysis tools, extend-
ing it with a supercompilation pass, and taking a fun-
◦ http://clean.cs.ru.nl/
damental grip on the generation of type error messages.
◦ http://wiki.clean.cs.ru.nl/
The latter work will be based on principles developed
for the Helium compiler (→ 2.2).
3.2.4 Timber
Report by: Johan Nordlander Further reading
Participants: Björn von Sydow, Andy Gill, Magnus
Carlsson, Per Lindgren, Thomas Hallgren, http:://timber-lang.org
and others
Status: actively developed 3.2.5 Ur/Web

Report by: Adam Chlipala

Timber is a general programming language derived
from Haskell, with the specific aim of supporting devel-
opment of complex event-driven systems. It allows pro-
grams to be conveniently structured in terms of objects
and reactions, and the real-time behavior of reactions
can furthermore be precisely controlled via platform-
independent timing constraints. This property makes
Timber particularly suited to both the specification and
the implementation of real-time embedded systems.
Timber shares most of Haskell’s syntax but intro-
duces new primitive constructs for defining classes of re-
active objects and their methods. These constructs live
in the Cmd monad, which is a replacement of Haskell’s
top-level monad offering mutable encapsulated state,
implicit concurrency with automatic mutual exclusion,
synchronous as well as asynchronous communication,
and deadline-based scheduling. In addition, the Tim-
ber type system supports nominal subtyping between
records as well as datatypes, in the style of its precursor
O’Haskell.
A particularly notable difference between Haskell
and Timber is that Timber uses a strict evaluation or-
der. This choice has primarily been motivated by a
desire to facilitate more predictable execution times,
but it also brings Timber closer to the efficiency of tra-
ditional execution models. Still, Timber retains the
purely functional characteristic of Haskell, and also
supports construction of recursive structures of arbi-
trary type in a declarative way.
The first public release of the Timber compiler was
announced in December 2008. It uses the Gnu C
compiler as its back-end and targets POSIX-based
operating systems. Binary installers for Linux and
MacOS X can be downloaded from the Timber web site
Status: beta release
Ur/Web is a domain-specific language for building
modern web applications. It is built on top of the
Ur language as a custom standard library with special
compiler support. Ur draws inspiration from a num-
ber of sources in the world of statically-typed func-
tional programming. From Haskell, Ur takes purity,
type classes, and monadic IO. From ML, Ur takes ea-
gerness and a module system with functors and type
abstraction. From the world of dependently-typed pro-
gramming, Ur takes a rich notion of type-level compu-
tation.
The Ur/Web extensions support the core features
of today’s web applications: “Web 1.0” programming
with links and forms, “Web 2.0” programming with
non-trivial client-side code, and interaction with SQL
database backends. Considering programmer produc-
tivity, security, and scalability, Ur/Web has signifi-
cant advantages over the mainstream web frameworks.
Novel facilities for statically-typed metaprogramming
enable new styles of abstraction and modularity. The
type system guarantees that all kinds of code inter-
pretable by browsers or database servers are treated as
richly-typed syntax trees (along the lines of familiar ex-
amples of GADTs), rather than as “strings”, thwarting
code injection attacks. The whole-program optimizing
compiler generates fast native code which does not need
garbage collection.
The open source toolset is in beta release now and
should be usable for real projects. I expect the core
feature set to change little in the near future, and the
next few releases will probably focus on bug fixes and
browser compatibility.

20
Further reading 3.3.2 The Disciplined Disciple Compiler (DDC)

http://www.impredicative.com/ur/ Report by: Ben Lippmeier

Status: alpha, active
See: http://haskell.org/communities/05-2009/html/
3.3 Type System / Program Analysis report.html#sect3.3.2.

3.3.1 Free Theorems for Haskell (and Curry)

Report by: Janis Voigtländer

Participants: Daniel Seidel, Jan Christiansen

Free theorems are statements about program behav-

ior derived from (polymorphic) types. Their origin is
the polymorphic lambda-calculus, but they have also
been applied to programs in more realistic languages
like Haskell. Since there is a semantic gap between the
original calculus and modern functional languages, the
underlying theory (of relational parametricity) needs
to be refined and extended. We aim to provide such
new theoretical foundations, as well as to apply the
theoretical results to practical problems. Recent pub-
lications are “Taming Selective Strictness” (ATPS’09)
and “Free Theorems for Functional Logic Programs”
(PLPV’10). The latter, joint work with Jan Chris-
tiansen, considers the situation when moving from
Haskell to Curry (→ 3.2.1).
On the practical side, we maintain a library and tools
for generating free theorems from Haskell types, origi-
nally implemented by Sascha Böhme and with contri-
butions from Joachim Breitner. Both the library and
a shell-based tool are available from Hackage (as free-
theorems and ftshell, respectively). There is also a web-
based tool at http://linux.tcs.inf.tu-dresden.de/~voigt/
ft. General features include:

◦ three different language subsets to choose from

◦ equational as well as inequational free theorems

◦ relational free theorems as well as specializations

down to function level

◦ support for algebraic data types, type synonyms and

renamings, type classes

While the web-based tool is restricted to algebraic data

types, type synonyms, and type classes from Haskell
standard libraries, the shell-based tool also enables the
user to declare their own algebraic data types and so
on, and then to derive free theorems from types involv-
ing those. A distinctive feature of the web-based tool
is to export the generated theorems in PDF format.
By popular demand (≥ 1 person), now also the LATEX
source for that PDF can be obtained as output.

Further reading
http://www.iai.uni-bonn.de/~jv/project/

21
4 Tools
4.1 Transforming and Generating
4.1.1 UUAG
Report by: Arie Middelkoop
Participants: ST Group of Utrecht University
Status: stable, maintained
UUAG is the Utrecht University Attribute Grammar
system. It is a preprocessor for Haskell which makes
it easy to write catamorphisms (that is, functions that
do to any datatype what foldr does to lists). You can
define tree walks using the intuitive concepts of inher-
ited and synthesized attributes, while keeping the full
expressive power of Haskell. The generated tree walks
are efficient in both space and time.
Idiomatic tree computations are neatly expressed in
terms of copy, default, and collection rules. Computed
results can masquerade as subtrees and be analyzed
accordingly. The order in which to visit the tree is
derived automatically from the attribute computations;
the tree walk is a single traversal from the perspective
of the programmer.
The system is in use by a variety of large and small
projects, such as the Utrecht Haskell Compiler UHC,
the editor Proxima for structured documents, the He-
lium compiler (→ 2.2), the Generic Haskell compiler,
and UUAG itself. The current version is 0.9.12 (Oc-
tober 2010), is extensively tested, and is available on
Hackage.
We recently added support for building AG files
through Cabal. A small Cabal plugin is installed upon
installation of UUAG, which provides a userhook that
deals with AG files and their dependencies.
types, avoid the trade-off which arises when building
software incrementally: should it be easy to add new
data types and data type alternatives or to add new
operations on existing data types? However, AGs are
usually implemented as a pre-processor, leaving e.g.
type checking to later processing phases and making
interactive development, proper error reporting and
debugging difficult. Embedding AG into Haskell as
a combinator library solves these problems. Previ-
ous attempts at embedding AGs as a domain-specific
language were based on extensible records and thus
exploiting Haskell’s type system to check the well-
formedness of the AG, but fell short in compactness
and the possibility to abstract over oft occurring AG
patterns. Other attempts used a very generic map-
ping for which the AG well-formedness could not be
statically checked. We present a typed embedding of
AG in Haskell satisfying all these requirements. The
key lies in using HList-like typed heterogeneous collec-
tions (extensible polymorphic records) and expressing
AG well-formedness conditions as type-level predicates
(i.e., typeclass constraints). By further type-level pro-
gramming we can also express common programming
patterns, corresponding to the typical use cases of mon-
ads such as Reader, Writer, and State. The paper
presents a realistic example of type-class-based type-
level programming in Haskell.
Background
The approach taken in AspectAG was proposed by
Marcos Viera, Doaitse Swierstra, and Wouter Swier-
stra in the ICFP 2009 paper “Attribute Grammars Fly
First-Class: How to do aspect oriented programming
in Haskell”.

Further reading
Further reading
◦ http://www.cs.uu.nl/wiki/bin/view/HUT/
http://www.cs.uu.nl/wiki/bin/view/Center/AspectAG
AttributeGrammarSystem
◦ http://hackage.haskell.org/package/uuagc-0.9.12
4.1.3 HFusion
4.1.2 AspectAG Report by: Facundo Dominguez
Participants: Alberto Pardo
Report by: Marcos Viera
Status: experimental
Participants: Doaitse Swierstra, Wouter Swierstra
Status: experimental
HFusion is an experimental tool for optimizing Haskell
AspectAG is a library of strongly typed Attribute programs. It is based on an algebraic approach where
Grammars implemented using type-level programming. functions are internally represented in terms of a recur-
sive program scheme known as hylomorphism. The tool
performs source to source transformations by the ap-
Introduction
plication of a program transformation technique called
Attribute Grammars (AGs), a general-purpose formal- fusion. The aim of fusion is to reduce memory manage-
ism for describing recursive computations over data ment effort by eliminating the intermediate data struc-

22
tures produced in function compositions.
We offer a web interface to test the technique on user-
supplied recursive definitions. The user can ask HFu-
sion to transform a composition of two functions into
an equivalent program which does not build the inter-
mediate data structure involved in the composition. In
future developments of the tool we plan to find fusable
compositions within programs automatically.
In its current state, HFusion is able to fuse composi-
tions of general recursive functions, including primitive
recursive functions like dropWhile or factorial, func-
tions that make recursion over multiple arguments like
zip, zipWith or equality predicates, mutually recursive
functions, and (with some limitations) functions with
accumulators like foldl. In general, HFusion is able to
eliminate intermediate data structures of regular data
types (sum-of-product types plus different forms of gen-
eralized trees).
Further reading
◦ Documentation about the tool can be found in HFu-
sion home
◦ HFusion web interface is available from this URL
4.1.4 Optimus Prime
Report by: Jason Reich
Participants: Colin Runciman, Matthew Naylor
Status: experimental
Optimus Prime is project developing a supercompiler
for programs written in F-lite, the subset of Haskell
used by the Reduceron (→ 2.6). It draws heavily on
Neil Mitchell’s work on the Supero supercompiler for
YHC Core.
The project is still at the highly experimental stage
but preliminary results are very encouraging. The pro-
cess appears to produce largely deforested programs
where higher-order functions have been specialised.
This, as a consequence, appears to enable further
23
gains from mechanisms such as speculative evaluation
of primitive redexes on the Reduceron architecture.
Optimus Prime supercompilation has led to a 74%
reduction in the number of Reduceron clock-cycles re-
quired to execute some micro-examples.
Work continues on improving the execution time
of the supercompilation transformation and improving
the performance of the supercompiled programs.
Contact
http://www.cs.york.ac.uk/people/?username=jason
Further reading
http://optimusprime.posterous.com/
4.1.5 Derive
Report by: Neil Mitchell
Status: v2.0
The Derive tool is used to generate formulaic instances
for data types. For example given a data type, the De-
rive tool can generate over 25 instances, including the
standard ones (Eq, Ord, Enum etc.) and others such
as Binary and Functor. Derive can be used with SYB,
Template Haskell or as a standalone preprocessor. This
tool serves a similar role to DrIFT, but with additional
features.
Further reading
http://community.haskell.org/~ndm/derive/
4.1.6 lhs2TEX
Report by: Andres Löh
Status: stable, maintained
This tool by Ralf Hinze and Andres Löh is a pre-
processor that transforms literate Haskell code into
LATEX documents. The output is highly customizable
by means of formatting directives that are interpreted
by lhs2TEX. Other directives allow the selective inclu-
sion of program fragments, so that multiple versions
of a program and/or document can be produced from
a common source. The input is parsed using a lib-
eral parser that can interpret many languages with a
Haskell-like syntax, and does not restrict the user to
Haskell 98.
The program is stable and can take on large docu-
ments.
The current version is 1.14 and is soon going to be
replaced with 1.15, a maintenance release that fixes
some problems mainly with the Windows version, but
will not introduce any new features.
 Since version 1.14, lhs2TEX has an experimental
mode for typesetting Agda code.
Further reading
http://www.cs.uu.nl/~andres/lhs2tex
4.2 Analysis and Profiling
4.2.1 SourceGraph
Report by: Ivan Lazar Miljenovic
Status: version 0.5.5.0
SourceGraph is a utility program aimed at helping
Haskell programmers visualize their code and perform
simple graph-based analysis (representing entities as
nodes in the graphs and function calls as directed
edges). It is a sample usage of the Graphalyze li-
brary (→ 5.7.2), which is designed as a general-purpose
graph-theoretic analysis library. These two pieces of
software were originally developed as the focus of my
mathematical honors thesis, “Graph-Theoretic Analy-
sis of the Relationships Within Discrete Data”.
Whilst fully usable, SourceGraph is currently lim-
ited in terms of input and output. It analyses all .hs
and .lhs files recursively found in the provided di-
rectory, parsing most aspects of Haskell code (cannot
parse Haskell code using CPP, HaRP, TH, FFI and
XML-based Haskell code; difficulty parsing Data Fam-
ily instances, unknown modules and record puns and
wildcards). The results of the analysis are created in
an Html file in a “SourceGraph” subdirectory of the
project’s root directory.
Changes since the previous release of HCAR include:
◦ Can now analyse a project from the Cabal file or an
overall base module.
◦ Now parses data definitions and class/instance dec- have used a map or fold, gives many more hints, warns
larations.
◦ Usage of colour and shapes to indicate different types cations on Hackage.
of entities and entity relationships with a legend to
explain the differences.
◦ Removal of the Relative Neighbourhood clustering
algorithm (as it didn’t provide much useful informa-
tion).
Current analysis algorithms utilized include: alter-
native module groupings, whether a module should be
split up, root analysis, clique and cycle detection as well
as finding functions which can safely be compressed
down to a single function. Please note however that
SourceGraph is not a refactoring utility, and that its
analyses should be taken with a grain of salt: for exam-
ple, it might recommend that you split up a module,
because there are several distinct groupings of func-
tions, when that module contains common utility func-
tions that are placed together to form a library module
(e.g., the Prelude).
Sample SourceGraph analysis reports can be
found at http://code.haskell.org/~ivanm/Sample_
SourceGraph/SampleReports.html. A tool paper on
SourceGraph has been accepted for the ACM SIG-
PLAN 2010 Workshop on Partial Evaluation and
Program Manipulation.
Further reading
◦ http://hackage.haskell.org/package/SourceGraph
◦ http://ivanmiljenovic.files.wordpress.com/2008/11/
honoursthesis.pdf
4.2.2 HLint
Report by: Neil Mitchell
Status: v1.6
HLint is a tool that reads Haskell code and suggests
changes to make it simpler. For example, if you call
maybe foo id it will suggest using fromMaybe foo in-
stead. HLint is compatible with almost all Haskell ex-
tensions, and can be easily extended with additional
hints.
There have been numerous feature improvements
since the last HCAR. HLint can now spot where you
about redundant extensions etc. HLint is now used by
the Darcs team and is one of the most popular appli-
Further reading
http://community.haskell.org/~ndm/hlint/
4.2.3 hp2any
Report by: Patai Gergely
Status: experimental, on hold
This project was born during the 2009 Google Summer
of Code under the name “Improving space profiling ex-
perience”. The name hp2any covers a set of tools and
libraries to deal with heap profiles of Haskell programs.
24
At the present moment, the project consists of three ◦ If compilation yields an error, then the source line
packages: is highlighted and additional error explanations are
provided.
◦ hp2any-core: a library offering functions to read
heap profiles during and after run, and to perform ◦ Shows a program summary in a tree structure, giving
queries on them. definitions of types and types of functions . . .
◦ hp2any-graph: an OpenGL-based live grapher that ◦ Automatic checking of all (Boolean) properties of a
can show the memory usage of local and remote pro- program; results shown in summary.
cesses (the latter using a relay server included in the
package), and a library exposing the graphing func- Over the summer 2009 Heat was completely re-
tionality to other applications. engineered to provide a simple and clean internal struc-
ture for future development. This new version still
◦ hp2any-manager: a GTK application that can dis- misses a few features compared to the current 3.1 ver-
play graphs of several heap profiles from earlier runs. sion and hence a new release will only appear in 2010.

The project also aims at replacing hp2ps by reimple-

menting it in Haskell and possibly adding new output Further reading
formats. The manager application shall be extended
http://www.cs.kent.ac.uk/projects/heat/
to display and compare the graphs in more ways, to
export them in other formats and also to support live
profiling right away instead of delegating that task to 4.3.3 HaRe — The Haskell Refactorer
hp2any-graph.
Report by: Simon Thompson
Participants: Huiqing Li, Chris Brown, Chaddaï Fouché,
Further reading Claus Reinke
http://www.haskell.org/haskellwiki/Hp2any
Refactorings are source-to-source program transforma-
4.3 Development tions which change program structure and organiza-
tion, but not program functionality. Documented in
4.3.1 Hoogle — Haskell API Search catalogs and supported by tools, refactoring provides
the means to adapt and improve the design of existing
Report by: Neil Mitchell
code, and has thus enabled the trend towards modern
Status: v4.0
agile software development processes.
See: http://haskell.org/communities/05-2009/html/ Our project, Refactoring Functional Programs, has
report.html#sect4.4.1. as its major goal to build a tool to support refactor-
ings in Haskell. The HaRe tool is now in its fifth major
4.3.2 HEAT: The Haskell Educational release. HaRe supports full Haskell 98, and is inte-
Advancement Tool grated with Emacs (and XEmacs) and Vim. All the
refactorings that HaRe supports, including renaming,
Report by: Olaf Chitil scope change, generalization and a number of others,
Status: active
are module aware, so that a change will be reflected in
all the modules in a project, rather than just in the
Heat is an interactive development environment (IDE) module where the change is initiated. The system also
for learning and teaching Haskell. Heat was designed contains a set of data-oriented refactorings which to-
for novice students learning the functional program- gether transform a concrete data type and associated
ming language Haskell. Heat provides a small num- uses of pattern matching into an abstract type and calls
ber of supporting features and is easy to use. Heat is to assorted functions. The latest snapshots support the
portable, small and works on top of the Haskell inter- hierarchical modules extension, but only small parts of
preter Hugs. the hierarchical libraries, unfortunately.
Heat provides the following features: In order to allow users to extend HaRe themselves,
HaRe includes an API for users to define their own
◦ Editor for a single module with syntax-highlighting program transformations, together with Haddock doc-
and matching brackets. umentation. Please let us know if you are using the
◦ Shows the status of compilation: non-compiled; com- API.
piled with or without error. Snapshots of HaRe are available from our webpage,
as are related presentations and publications from
◦ Interpreter console that highlights the prompt and the group (including LDTA’05, TFP’05, SCAM’06,
error messages. PEPM’08, PEPM’10, Huiqing’s PhD thesis and Chris’s

25
PhD thesis). The final report for the project appears Preprocessor are used. Auto-generated Haskell mod-
there, too. ules may be imported into applications to access the
Chris Brown has precently passed his PhD; his PhD foreign library’s functions and variables.
thesis entitled “Tool Support for Refactoring Haskell HSFFIG has been in development since 2005, and
Programs” is available from our webpage. was recently released on Hackage. The current version
is 1.1.2 which is mainly a bug-fix release for the version
Recent developments 1.1.
The package provides a small library to link with
◦ More structural and datatype-based refactorings programs using auto-generated imports, and two exe-
have been studied by Chris Brown, including trans- cutable programs:
formation between let and where, generative fold-
ing, introducing pattern matching, and introducing ◦ hsffig: a filter program which reads pre-processed
case expressions; include files from standard input, and produces one
◦ Clone detection and elimination support has been large .hsc file;
added, to allow the automatic detection and semi-
automatic elimination of duplicated code in Haskell. ◦ ffipkg: a program which automates the process of
building a Cabal package out of C include files by the
means of automated running hsffig and other tools
Further reading necessary to build a Haskell package.
http://www.cs.kent.ac.uk/projects/refactor-fp/
Further reading
4.3.4 DarcsWatch ◦ The HSFFIG package on Hackage
http://hackage.haskell.org/package/HSFFIG
Report by: Joachim Breitner
◦ The HSFFIG Tutorial
Status: working
http://www.haskell.org/haskellwiki/HSFFIG/Tutorial
◦ The FFI Imports Packaging Utility
DarcsWatch is a tool to track the state of Darcs (→ http://www.haskell.org/haskellwiki/FFI_imports_
6.1.1) patches that have been submitted to some packaging_utility
project, usually by using the darcs send command.
It allows both submitters and project maintainers to
get an overview of patches that have been submitted
but not yet applied.
The DarcsWatch internals were changed during the
Darcs hacking sprint in Vienna, to allow for a deeper in-
tegration into the roundup bug tracking instance used
by the Darcs projects. Also, other extensions of darc-
swatch are easier now. DarcsWatch continues to be
used by the xmonad project (→ 6.1.2) and a few de-
velopers. At the time of writing, it was tracking 41
repositories and 2627 patches submitted by 162 users.

Further reading
◦ http://darcswatch.nomeata.de/
◦ http://darcs.nomeata.de/darcswatch/documentation.
html

4.3.5 HSFFIG
Report by: Dmitry Golubovsky
Status: release
Haskell FFI Binding Modules Generator (HSFFIG) is
a tool which parses C include files (.h) and generates
Haskell Foreign Functions Interface import declarations
for all functions, #define’d constants (where possible),
enumerations, and structures/unions (to access their
members). It is assumed that the GNU C Compiler and

26
5 Libraries
quests. Many of these would require relatively little
time for any competent Haskell hacker.
5.1 Cabal and Hackage
The other important project that people should con-
Report by: Duncan Coutts
sider helping out with is the new Hackage server im-
plementation, based on Happstack. The current Hack-
age server has several widely acknowledged limitations.
Background The new design should enable us to add many of the
new features that users so frequently request. There
Cabal is the Common Architecture for Building Appli- has been some progress on this in the last few months
cations and Libraries. It defines a common interface but it needs some more work before we can consider a
for defining and building Haskell packages. It is imple- transition.
mented as a Haskell library and associated tools which
allow developers to easily build and distribute pack- Further reading
ages.
Hackage is a distribution point for Cabal packages. ◦ Cabal homepage: http://www.haskell.org/cabal
It is an online database of Cabal packages which can be ◦ Hackage package collection: http://hackage.haskell.
queried via the website and client-side software such as org/
cabal-install. Hackage enables end-users to download ◦ Bug tracker: http://hackage.haskell.org/trac/
and install Cabal packages. hackage/
cabal-install is the command line interface for the
Cabal and Hackage system. It provides a command line 5.2 Haskell Platform
program cabal which has sub-commands for installing
and managing Haskell packages. Report by: Duncan Coutts

Recent progress
Background
There have been no new releases since the last HCAR, The Haskell Platform (HP) is the name of a new
however there will soon be a release of Cabal-1.8 and “blessed” set of libraries and tools on which to build fur-
a corresponding release of cabal-install. The primary ther Haskell libraries and applications. It takes the best
change is that these releases will work with GHC 6.12. packages from the more than 1500 on Hackage (→ 5.1).
There is also a new “cabal init” command to help users It is intended to provide a comprehensive, stable, and
create an initial “.cabal” file and a feature to maintain quality tested base for Haskell projects to work from.
an HTML contents page for the Haddock documenta- Historically, GHC has shipped with a collection of
tion for all installed packages. packages under the name extralibs. As of GHC 6.12
In addition there will be a minor release of cabal- the task of shipping an entire platform is being trans-
install-0.6.x for users of GHC-6.10; the main change ferred to the Haskell Platform.
being a slight tweak in behaviour that should help with
the general push to get packages to transition from base
3 to base 4. Recent progress
Since the last report, cabal-install is now in wider use
We had the first major release of the platform earlier
thanks to being included in the Haskell Platform (→ this year and followed that up with 2 further minor re-
5.2) and being packaged by various Linux distributions.
leases. The last of these uses GHC 6.10.4 and is avail-
Hackage growth continues to be strong. For the sec-
able on Windows, OS X, as a generic Unix tarball and
ond 6-month period in a row there has been 50% growthis included in several Linux distributions.
in the number of packages. There are now well over We established a steering committee to guide the dis-
1,500 different packages. cussions on the libraries mailing list to ensure that the
necessary decisions do actually get made, recorded and
Looking forward communicated to the release engineering team.
The steering committee drafted a new procedure for
As ever, there are many improvements we want to make adding packages to the Haskell Platform and this has
to Cabal, cabal-install and Hackage but our limiting now been ratified by the libraries mailing list. The
factor is the amount of volunteer development time. new procedure involves writing a package proposal and
We have over 100 open bugs and 150 open feature re- discussing it on the libraries mailing list with the aim

27
of reaching a consensus. Details of the procedure are (indices) are selected by name in expressions and Ein-
on the development wiki. stein’s summation convention for repeated indices is au-
tomatically applied. We provide two main data types:
Looking forward simple arrays in which contractions only require equal
dimension size, and tensors, whose indices are labeled
There had been a plan for a second major release of the as covariant or contravariant (subindex or superindex),
platform using GHC 6.10, however that has now been and contractions can only be done on pairs of comple-
shelved and the next major release will be in January mentary indices. Arguments are automatically made
and will use GHC 6.12. In the meantime, for people conformant by replicating them along extra dimensions
testing their packages with the GHC 6.12 release can- appearing in an operation. There is also preliminary
didates, there will be a source-only beta version avail- support for geometric algebra and tensor decomposi-
able. tions.
Future major releases will be on a 6 month schedule. The library has a purely functional interface: ar-
Major releases may include new and updated packages rays are immutable, and operations typically work on
while minor releases will only contain bug fixes and whole structures which can be assembled and decom-
fixes for packaging problems. posed using simple primitives. It is built on top of
We would like to invite package authors to pro- hmatrix (→ 5.3.1), so coordinates are internally stored
pose new packages for the upcoming major releases. in C arrays and tensor products are implemented using
We also invite the rest of the community to take BLAS. Therefore, big arrays can in principle be effi-
part in the review process on the libraries mailing list ciently processed, although some functions are naively
libraries@haskell.org. defined and not optimized. Consistency of dimension
sizes is currently checked at run time. Future work in-
Further reading cludes static checking of conformability and a GUI for
tensor diagrams.
http://haskell.org/haskellwiki/Haskell_Platform A tutorial can be found in the project’s web page.
◦ Download: http://hackage.haskell.org/platform/
◦ Wiki: http://trac.haskell.org/haskell-platform/ Further reading
◦ Adding packages: http://trac.haskell.org/
haskell-platform/wiki/AddingPackages http://perception.inf.um.es/tensor

5.3 Auxiliary Libraries 5.3.3 The Neon Library

Report by: Jurriaan Hage

5.3.1 hmatrix
As part of his master thesis work, Peter van Keeken im-
Report by: Alberto Ruiz plemented a library to data mine logged Helium (→ 2.2)
Status: stable, maintained programs to investigate aspects of how students pro-
gram Haskell, how they learn to program, and how
good Helium is in generating understandable feedback
The hmatrix library is a purely functional interface to
and hints. The software can be downloaded from http:
numerical linear algebra, internally implemented using
//www.cs.uu.nl/wiki/bin/view/Hage/Neon, which also
GSL, BLAS, and LAPACK. The latest stable version
gives some examples of output generated by the sys-
is available from Hackage.
tem. The downloads only contain a small sample of
Recent work includes the experimental library hTen- loggings, but it will allow programmers to play with it.
sor (→ 5.3.2) for multidimensional arrays and simple The recent news is that a paper about Neon will
tensor computations. be published at SLE (1st Conference on Software Lan-
guage Engineering), where it came under the heading
Further reading of Tools for Language Usage.
On that note, there has been a posting by Simon
http://www.hmatrix.googlepages.com Thompson, Sally Fincher and myself for a PhD stu-
dent to work on understanding how students learn to
5.3.2 hTensor program (in Haskell), in Kent. Also, recently I acquired
Report by: Alberto Ruiz a new master student to continue to the work of Pe-
Status: experimental, active development ter van Keeken. One of this tasks will be to investigate
the kind of parse errors students make, and continue to
hTensor is an experimental library for multidimen- make. In the process, he shall add context properties
sional arrays, oriented to support simple tensor com- (did the student pass or fail, what kind of programming
putations and multilinear algebra. Array dimensions background can we expect him or her to have) to our

28
database so that they can be employed by queries to
increase external validity.
5.3.4 leapseconds-announced
Report by: Björn Buckwalter
Status: stable, maintained
The leapseconds-announced library provides an easy to
use static LeapSecondTable with the leap seconds an-
nounced at library release time. It is intended as a
quick-and-dirty leap second solution for one-off anal-
yses concerned only with the past and present (i.e.
up until the next as of yet unannounced leap second),
or for applications which can afford to be recompiled
against an updated library as often as every six months.
Version 2009 of leapseconds-announced contains all
leap seconds up to 2009-01-01. A new version will be
uploaded if/when the iers announces a new leap sec-
ond.
Further reading
◦ http://hackage.haskell.org/cgi-bin/hackage-scripts/
package/leapseconds-announced
◦ http://github.com/bjornbm/leapseconds-announced
5.4 Parsing and Transforming
5.4.1 ChristmasTree
Report by: Marcos Viera
Participants: Doaitse Swierstra, Eelco Lempsink
Status: experimental
See: http://haskell.org/communities/05-2009/html/
report.html#sect5.5.7.
5.4.2 Utrecht Parser Combinator Library: New
version
Report by: Doaitse Swierstra
Status: actively developed
The Utrecht Parser Combinator library has remained
largely unmodified for the last five years, and has served Report by:
us well. Over the years, however, new insights have
grown, and with the advent of GADTs some internals See:
could be simplified considerably. The Lernet summer report.html#sect5.6.1.
school in February 2008 (http://www.fing.edu.uy/inco/
eventos/lernet2008/) provided an incentive to start a
5.5.2 Halculon: units and physical constants
rewrite of the library; a newly written tutorial will ap-
pear in the lecture notes, which will be published by
Springer in the LNCS series. The text is also available
as a technical report at http://www.cs.uu.nl/research/
techreps/UU-CS-2008-044.html
Features
◦ Much simpler internals than the old li-
brary (http://haskell.org/communities/05-2009/
html/report.html#sect5.5.8).
◦ Online result production, error recovery, combina-
tors for parsing ambiguous grammars, an applicative
interface, a monadic interface.
◦ Scanners can be switched dynamically, so several dif-
ferent languages can occur intertwined in a single in-
put file.
◦ Fixes a potential black hole which went unnoticed for
years in the code for the monadic bind as presented
by Swierstra and Hughes in the ICFP 2003 paper:
Polish Parsers: Step by Step.
A first version of the new library was recently re-
leased as the uu-parsinglib library, which has found its
place in the Text.ParserCombinators category on Hack-
age.
Future plans
The final library, with an abstract interpretation part
in order to get the parsing speed we got used to, will
be release on Hackage again. We plan to extend the
short tutorial which will appear in the LNCS series (45
pages) into a long tutorial.
Since many aspects of the old library, such as its
applicative interface and the possibility to build e.g.
parser for permutation phrases, have now come avail-
able elsewhere in other packages, we will also try to
make the new library to conform as much as possible
with these new developments.
Contact
If you are interested in using the current version of the
library in order to provide feedback on the provided
interface, contact hdoaitse@swierstra.neti.
5.5 Mathematical Objects
5.5.1 dimensional: Statically checked physical
dimensions
Björn Buckwalter
Status: active, mostly stable
http://haskell.org/communities/11-2008/html/
database
Report by: Jared Updike
Status: web application in beta, database stable
A number of Haskell libraries can represent numeri-
cal values with physical dimensions that are checked
at runtime or compile time (including dimensional and
the Numeric Prelude), but neither provide an exhaus-
tive, searchable, annotated database of units, measures,
29
and physical constants. Halculon is an interactive unit
database of 4,250 units, with a sample Haskell AJAX
web application, based on the units database created by
Alan Eliasen for the wonderful physical units program-
ming language Frink. (Because each unit in Frink’s
unit.txt database is defined in terms of more basic
unit definitions — an elegant approach in general —
units.txt is inconvenient for looking up a single random
unit; the entire file might need to be parsed to repre-
sent any given constant solely in terms of the base SI
units, which is precisely what the Halculon database
provides.)
Halculon also provides a carefully tuned, user- and
developer-friendly search string database that aims to
make interactive use pleasant. The database tables are
available online and downloadable as UTF-8 text.
The example web application now has a mobile ver-
sion available (tested in iPhone OS 3.1, Safari 3.0, and
Firefox 2.0). For best results on the iPhone or iPod
touch, Add to Home Screen to use the application in
full screen. The calculator works offline, too.
Further reading
◦ http://www.updike.org/articles/Units
◦ http://www.updike.org/halculon/
◦ http://www.updike.org/halcmobile/
5.5.3 Numeric prelude
Report by: Henning Thielemann
Participants: Dylan Thurston, Mikael Johansson
Status: experimental, active development
See: http://haskell.org/communities/05-2009/html/
report.html#sect5.6.2.
5.5.4 AERN-Real and friends
Report by: Michal Konečný
Participants: Amin Farjudian, Jan Duracz
Status: experimental, actively developed
30
AERN stands for Approximating Exact Real Numbers.
We are developing a family of the following libraries for
fast exact real number arithmetic:
◦ AERN-Real: arbitrary precision safely rounded
interval arithmetic with multiple backends (pure
Haskell floating point numbers, MPFR, machine
doubles) and with support for inner rounding, anti-
consistent intervals and Kaucher arithmetic
◦ AERN-RnToRm: arbitrary precision safely-rounded
arithmetic of piece-wise polynomial function en-
closures (PFEs) for functions over n-dimensional
real intervals with support for inner rounding,
anti-consistent intervals and approximated Kaucher
arithmetic
◦ AERN-RnToRm-Plot: GTK window for inspecting
the graphs of PFEs in one variable (see figure below,
showing a screenshot of an AERN-RnToRm-Plot
window exploring an enclosure of cos(10x) (blue) and
an enclosure of its primitive function (red))
◦ AERN-Net: an implementation of distributed query-
based (i.e., lazy) computation over analytical and ge-
ometrical objects
The development is driven mainly by the needs of our
two research projects. We use the libraries extensively
to:
◦ prototype algorithms for reliable and ultimately con-
verging methods for solving differential equations in
many variables (AERN-RnToRm, AERN-Net)
◦ solve numerical constraint satisfaction problems, es-
pecially those arising from verification of programs
that use floating point numbers (AERN-RnToRm)
For our purposes AERN-Real has been stable for al-
most two years. It needs to be tested for a wider variety
of applications before we can label it as stable. AERN-
RnToRm is now also fairly stable thanks to a period
of debugging and a comprehensive test suite. Never-
theless, it is rather slow as it has not been optimised
and there are occasional gaps in its functionality. The 5.5.6 fad: Forward Automatic Differentiation
other libraries are even more experimental and incom-
Report by: Björn Buckwalter
plete. We recently added a useful mouse-driven zoom
Participants: Barak A. Pearlmutter, Jeffrey Mark
and pan feature to the function plot window. Siskind
The API of all the libraries is still occasionally chang- Status: active
ing but they provide a fairly extensive set of features
Fad is an attempt to make as comprehensive and us-
and are reasonably well documented. The libraries are
able a forward automatic differentiation (AD) library
under active development and new features and bug
as is possible in Haskell. Fad (a) attempts to be cor-
fixes are expected to be submitted to Hackage in the
rect, by making it difficult to accidentally get a nu-
coming 12 months. Notable planned additions in this
merically incorrect derivative; (b) provides not only
period include:
first-derivatives, but also a lazy tower of higher-order
derivatives; (c) allows nested use of derivative operators
◦ optimisations to the function enclosure arithmetic while using the type system to reject incorrect nesting
(perturbation confusion); (d) attempts to be complete,
◦ lazy communication of approximations of higher- in the sense of allowing calculation of derivatives of
order real functions using role switching functions defined using a large variety of Haskell con-
structs; and (e) tries to be efficient, in the sense of both
◦ infinite trees of enclosures for interval partial deriva- the defining properties of forward automatic differen-
tives computed using automatic differentiation tiation and in keeping the constant factor overhead as
low as possible.
Version 1.0 of fad was uploaded to Hackage on
Further reading April 3. Recent changes can be found via git clone
git://github.com/bjornbm/fad.git
See Haddock documentation via Hackage — has links
to research papers. Further reading
◦ http://github.com/bjornbm/fad
5.5.5 logfloat ◦ http://flygdynamikern.blogspot.com/2009/04/
announce-fad-10-forward-automatic.html
Report by: Wren Ng Thornton
Status: stable? 5.6 Data types and data structures
Current release: 0.12.0.1
Portability: GHC 6.8, GHC 6.10, Hugs Sept2006
5.6.1 HList — a library for typed heterogeneous
The logfloat library provides a type for storing numbers collections
in the log-domain. This is primarily useful for avoid- Report by: Oleg Kiselyov
ing underflow when multiplying many small numbers Participants: Ralf Lämmel, Keean Schupke, Gwern
in probabilistic models. Branwen
It also includes support for dealing with IEEE-754
floating point numbers (more) correctly, including: a
HList is a comprehensive, general purpose Haskell li-
class for types with representations for transfinite val-
ues, a class for partially ordered types, efficient andbrary for typed heterogeneous collections including
correct conversion from Real to Fractional, and bug extensible polymorphic records and variants (→ 1.3).
fixes for Hugs’ Prelude. HList is analogous to the standard list library, pro-
viding a host of various construction, look-up, filter-
ing, and iteration primitives. In contrast to the reg-
Future plans ular lists, elements of heterogeneous lists do not have
to have the same type. HList lets the user formulate
Add a signed variant so negative numbers can also be statically checkable constraints: for example, no two
projected into the log-domain. elements of a collection may have the same type (so
the elements can be unambiguously indexed by their
type).
Further reading An immediate application of HLists is the imple-
mentation of open, extensible records with first-class,
◦ Official source and documentation available on Hack- reusable, and compile-time only labels. The dual
age application is extensible polymorphic variants (open
◦ The development branch is available from http:// unions). HList contains several implementations of
community.haskell.org/~wren/ open records, including records as sequences of field

31
values, where the type of each field is annotated with
its phantom label. We, and now others (Alexandra
Silva, Joost Visser: PURe.CoddFish project), have also
used HList for type-safe database access in Haskell.
HList-based Records form the basis of OOHaskell (http:
//darcs.haskell.org/OOHaskell). The HList library relies
on common extensions of Haskell 98.
HList is being used in AspectAG, typed EDSL of at-
tribute grammars, and in HaskellDB. There has been
many miscellaneous changes related to the names of ex-
posed modules, fixity declarations, making hMap and
similar functions maximally lazy, improving error mes-
sages and documentation. A new, 0.2, release of HList
incorporates the patches from HaskellDB developers
Justin Bailey and Brian Bloniarz. The new release has
a working regression test suite.
We are investigating the use of type functions pro-
vided in the new versions of GHC.
Further reading
◦ HList: http://homepages.cwi.nl/~ralf/HList/
◦ OOHaskell: http://homepages.cwi.nl/~ralf/
OOHaskell/
5.6.2 bytestring-trie
Report by: Wren Ng Thornton
Status: active development
Current release: 0.1.4
Portability: Haskell 98 + CPP
The bytestring-trie library provides an efficient imple-
mentation of “dictionaries” mapping strings to values,
Further reading
using big-endian patricia tries (like Data.IntMap). In
general Trie is more efficient than Map ByteString ◦ http://hackage.haskell.org/package/Graphalyze
because memory and work is shared between strings ◦ http://ivanmiljenovic.files.wordpress.com/2008/11/
with common prefixes, though the specifics will vary
depending on the distribution of keys.
Future plans
◦ Min- and max-views for treating tries as priority
queues.
◦ Efficient intersection and difference functions.
Further reading
◦ Official source and documentation available on Hack-
age.
◦ The development branch is available from http://
community.haskell.org/~wren/.
5.7 Data processing
5.7.1 MultiSetRewrite
Report by: Martin Sulzmann
Status: stable
See: http://haskell.org/communities/05-2009/html/
report.html#sect5.8.3.
5.7.2 Graphalyze
Report by: Ivan Lazar Miljenovic
Status: version 0.8.0.0
The Graphalyze library is a general-purpose, fully ex-
tensible graph-theoretic analysis library, which includes
functions to assist with graph creation and visualiza-
tion, as well as many graph-related algorithms. Also
included is a small abstract document representation,
with a sample document generator utilizing Pandoc (→
6.4.1). Users of this library are able to mix and match
Graphalyze’s algorithms with their own. Changes since
previous versions have focused on refining the contents
of the library and inclusion of new analysis algorithms,
with future plans to re-write the document generation
modules to use pretty-printing functions.
Graphalyze is used in SourceGraph (→ 4.2.1) (which
is the driving force behind improvements to Grapha-
lyze), and was initially developed as part of my Math-
ematics Honours’ thesis, Graph Theoretic Analysis of
Relationships Within Discrete Data. The focus on this
thesis was to develop computational tools to allow peo-
ple to analyze discrete data sets.
honoursthesis.pdf
5.8 Generic and Type-Level Programming
5.8.1 uniplate
Report by: Neil Mitchell
See: http://haskell.org/communities/05-2009/html/
report.html#sect5.9.1.
5.8.2 Generic Programming at Utrecht University
Report by: José Pedro Magalhães
Participants: Stefan Holdermans, Johan Jeuring, Sean
Leather, Andres Löh, Thomas van Noort
Status: actively developed
One of the research themes investigated within the
Software Technology Center in the Department of In-
32
formation and Computing Sciences at Utrecht Univer- with GHC on the base package, and the syb pack-
sity is generic programming. Over the last 10 years, we age, which is available on Hackage. This allows the
have played a central role in the development of generic development of the library independently of compiler
programming techniques, languages, and libraries. releases. With GHC version 6.12 it will be possible
Currently, we are maintaining four generic program- to update the syb package, and we plan to release a
ming libraries: emgm, multirec, regular, and syb. We new version with more functions and efficiency im-
report on the latter three in this entry; emgm has its own provements.
entry (→ 5.8.3).
We are also working on a new version of our library
multirec This library represents datatypes uniformly for generic rewriting. We have previously described the
and grants access to sums (the choice between con- rewriting library in a paper and released it on Hackage
structors), products (the sequence of constructor ar- as the rewriting package. Currently we are imple-
guments), and recursive positions. Families of mu- menting support for families of (possibly mutually) re-
tually recursive datatypes are supported. Functions cursive datatypes and preconditions.
such as map, fold, show, and equality are provided as Finally, we have been looking at benchmarking and
examples within the library. Using the library func- improving the performance of different libraries for
tions on your own families of datatypes requires some generic programming (→ 5.8.4).
boilerplate code in order to instantiate the frame-
work, but is facilitated by the fact that multirec Further reading
contains Template Haskell code that generates these
instantiations automatically. http://www.cs.uu.nl/wiki/GenericProgramming

The multirec library can also be used for type-
indexed datatypes. As a demonstration, the zipper
library is available on Hackage. With this datatype-
generic zipper, you can navigate values of several
types.
The current versions are 0.4 for multirec and 0.3
for zipper. There is ongoing development for
multirec, and new releases are expected soon: we
will likely add more functions and perhaps add
a multirec-extras package as we just did for
regular (see below). We are also working on support
for datatypes with parameters and datatype compo-
sitions.
regular While multirec focuses on support for mu-
tually recursive regular datatypes, regular supports
only single regular datatypes. The approach used is
similar to that of multirec, namely using type fam-
ilies to represent the pattern functor of the datatype
to represent generically. We have recently released
version 0.2 on Hackage, and also an extra package
with more generic functions. Together they pro-
vide a number of typical generic programming exam-
ples, but also a number of less well-known but useful
generic functions: deep seq, QuickCheck’s arbitrary
and coarbitrary, and binary’s get and put.
syb Scrap Your Boilerplate (syb) has been supported
by GHC since the 6.0 release. The library is based
on combinators and a few primitives for type-safe
casting and processing constructor applications. It
was originally developed by Ralf Lämmel and Si-
mon Peyton Jones. Since then, many people have ◦ Collect for collecting values of a certain type con-
contributed with research relating to syb or its ap-
plications. Recent work has allowed the separation
of syb into a core module, Data.Data, which comes ◦ ZipWith, a generic version of the standard zipWith
5.8.3 Extensible and Modular Generics for the
Masses (EMGM)
Report by: Sean Leather
Participants: José Pedro Magalhães, Alexey Rodriguez,
Andres Löh
Status: actively developed
Extensible and Modular Generics for the Masses
(EMGM) is a general-purpose library for generic pro-
gramming with type classes.
Introduction
EMGM is a library for of datatype-generic pro-
gramming using type classes. We represent Haskell
datatypes as values using a sum-of-products structure
representation. The foundation of EMGM allows pro-
grammers to write generic functions by induction on
the structure of datatypes. The use of type classes
in EMGM allows generic functions to support ad-hoc
cases for arbitrary datatypes.
The library provides a sizable (and constantly grow-
ing) collection of ready-to-use generic functions. Here
are some examples of these functions:
◦ Crush, a useful generalization of fold-like opera-
tions that supports flattening, integer operations,
and logic operations on all values of an arbitrary
datatype
◦ Extensible Read and Show functions to which one
might add special cases for certain types
tained within a value of a different type

33
 EMGM also comes with support for standard
datatypes such as lists, Either, Maybe, and tuples.
Adding support for your own datatype is straightfor-
ward using the deriving API.
Background
The ideas for EMGM come from research by Ralf
Hinze, Bruno Oliveira, and Andres Löh. It was fur-
ther explored in a comparison of generic programming
libraries by Alexey Rodriguez, et al. Our particular im-
plementation was developed simultaneously along with
lecture notes for the 2008 Advanced Functional Pro-
gramming Summer School. The article from these lec-
tures has been extended and published as a technical
report.
Recent Development
No changes have been made since the previous report.
Future plans
We plan to continue developing EMGM and to explore
the use of this library in many domains. There should
be a major release before the next report. We welcome
ideas or contributions from the community.
Contact
Let us know if you use EMGM, how you use it, and
where it can be improved. Contact us on the Generics
mailing list.
Further reading
More information can be found on the EMGM web-
site. Download the package and browse the API at the
Hackage page.
programs, when compiled with the standard optimiza-
tion flags of the Glasgow Haskell Compiler (GHC), are
substantially slower than their hand-written counter-
parts. However, we have also found that more advanced
optimization capabilities of GHC can be used to fur-
ther optimize generic functions, sometimes achieving
the same efficiency as hand-written code.
We have benchmarked four generic programming li-
braries: emgm, syb, multirec, and regular. We com-
pare different generic functions in each of these libraries
to a hand-written version. We have concluded that in-
lining plays a crucial role in the optimization of gener-
ics. In some cases, the inliner of GHC can already op-
timize a generic function up to the same performance
of the hand-written version. However, this does not
happen with simple -O1 or -O2 optimization levels: we
need to tweak the unfolding flags to stimulate inlining.
As an example, we show the results of our bench-
mark for the generic show function below. We
present how the libraries perform across different
compiler optimizations: UT60 stands for setting the
-funfolding-use-threshold flag to 60 and CT450
for setting -funfolding-creation-threshold to 450.
We have benchmarked the function on two different
datatypes: a simple binary tree (Tree) and a repre-
sentation of logic expressions (Logic). The results are
plotted relative to the hand-written version compiled
with -O1, on a logarithmic scale of base 2. We can see
that syb and multirec perform much worse than emgm
and regular. More interestingly, though, is that by
tweaking the inlining thresholds we can make regular
as efficient as the hand-written version, and emgm al-
most as efficient.

5.8.4 Optimizing generic functions

Report by: José Pedro Magalhães

Participants: Stefan Holdermans, Johan Jeuring, Andres
Löh
Status: actively developed Our benchmark provides many more interesting re-
sults, which can be seen in our PEPM’10 paper. In
Datatype-generic programming increases program re-
the near future we plan to extend our benchmark and
liability by reducing code duplication and enhancing
investigate the cases where simple tweaking of inlining
reusability and modularity. Several generic program-
flags is not sufficient to provide adequate performance.
ming libraries for Haskell have been developed in the
past few years. These libraries have been compared in
detail with respect to expressiveness, extensibility, typ- Further reading
ing issues, etc., but performance comparisons have been http://dreixel.net/research/pdf/ogie.pdf
brief, limited, and preliminary. It is widely believed
that generic programs run slower than hand-written
code.
At Utrecht University we are looking into the perfor-
mance of different generic programming libraries and
how to optimize them. We have confirmed that generic

34
5.8.5 2LT: Two-Level Transformation Further reading
Report by: Tiago Miguel Laureano Alves ◦ Example code: http://community.haskell.org/~claus/
Participants: Joost Visser, Pablo Berdaguer, Alcino misc/labels.hs
Cunha, José Nuno Oliveira, Hugo Pacheco http://community.haskell.org/~claus/misc/Data/Label/
Status: active TH.hs
See: http://haskell.org/communities/05-2009/html/ http://community.haskell.org/~claus/misc/Data/Label.hs
report.html#sect5.9.6. ◦ Discussion: http://www.haskell.org/pipermail/
haskell-cafe/2009-April/059819.html
5.8.6 Data.Label — “atoms” for type-level
programming 5.9 User interfaces
Report by: Claus Reinke
Status: experimental 5.9.1 Gtk2Hs
A common problem for type-level programming (ex- Report by: Axel Simon
tensible record libraries, type-level numbers, . . . ) in Participants: Peter Gavin and many others
Haskell is where to define shared atomic types (record Status: beta, actively developed
field labels, type tags, type numerals):
◦ identical types defined in separate modules are not Gtk2Hs is a set of Haskell bindings to many of the
compatible libraries included in the Gtk+/Gnome platform. Gtk+
is an extensive and mature multi-platform toolkit for
◦ common imports defining common types for several
creating graphical user interfaces.
projects hurt modularity
GUIs written using Gtk2Hs use themes to resemble
◦ SML-style parameterized modules and type-sharing the native look on Windows and, of course, various
are not directly available desktops on Linux, Solaris, FreeBSD, and Mac OS X
using X11.
Using Template Haskell, and QuasiQuotes in partic-
ular, we can now at least work around this issue, by Gtk2Hs features:
splitting the atoms:-) Data.Label provides type let-
◦ Automatic memory management (unlike some other
ters and combinators for constructing typed “atoms”
C/C++ GUI libraries, Gtk+ provides proper sup-
from these letters, as well as quasiquoting and Show
port for garbage-collected languages)
instances to hide some of this internal structure.
*Main> [$l|label|] ◦ Unicode support
label
*Main> :t [$l|label|] ◦ High quality vector graphics using Cairo
[$l|label|] :: Ll :< (La :< (Lb :< (Le :< Ll)))
◦ Cross-platform, multi-format multimedia playback
This workaround lets users choose between shared or with GStreamer
locally defined labels:
◦ Extensive reference documentation
module A where module B where
import Data.Label import Data.Label ◦ An implementation of the “Haskell School of Expres-
data MyLabel data MyLabel sion” graphics API
x = [$l|label|] x = [$l|label|]
y = undefined::MyLabel y = undefined::MyLabel ◦ Support for the Glade visual GUI builder

module C where ◦ Bindings to some Gnome extensions: gio, GConf,

import Data.Label GtkSourceView 1.0 and 2.0
import A
import B ◦ An easy-to-use installer for Windows
ok = [A.x,B.x]
fails = [A.y,B.y] ◦ Packages for Fedora, Gentoo (→ 2.7.1), Debian, and
FreeBSD
It does so by offering a meta-level commonality: A
and B do not have to agree on a common module to ◦ New features added during the last months:
declare all their common types (Data.Label is unaf-
– The terminal widget VTE
fected by the specific labels its importers might use),
they only need to agree on a common way of declaring – A binding the webkit to display web pages
all their sharable “atomic” types. – More demos and more functions bound

35
 The Gtk2HS library is continually being improved is for diagrams to become a viable alternative to DSLs
with new bindings, documentation, and bug fixes. like MetaPost or Asymptote, but with the advantages
Outside contributions are always welcome! We have of being purely functional and embedded.
recently re-surrected our code generator tool which For example, consider the following diagram to illus-
means that new functions from Gtk+ 2.18.3 can be trate the 24 permutations of four objects:
bound by copy-and-paste followed by a quick edit of the
C documentation to reflect the Haskell version. This
significantly lowers the burden to help us out, so please
get in touch if you are interested.
Besides cabalizing Gtk2Hs, we are working on concur-
rency support which turns out to be non-trivial in the
face of GHC’s concurrent garbage collector. We plan
to release a new version of Gtk2Hs before Christmas.

Further reading
The diagrams library was used to create this dia-
◦ News, downloads, and documentation: http://
gram with very little effort (about ten lines of Haskell,
haskell.org/gtk2hs/
including the code to actually generate permutations).
◦ Development version: darcs get http://code.
The source code for this diagram, as well as other ex-
haskell.org/gtk2hs/
amples and further resources, can be found at http:
/code.haskell.org/diagrams/.
5.9.2 HQK The library is currently undergoing a major rewrite,
Report by: Wolfgang Jeltsch in order to use a more flexible constraint-solving lay-
Participants: Thomas Mönicke out engine and abstract out the rendering backend (the
Status: provisional current version depends solely on the Cairo library for
rendering). Other planned features include animation
HQK is an effort to provide Haskell bindings to large
support, more sophisticated paths and path operations,
parts of the Qt and KDE libraries. We have devel-
and an xmonad-like core/contrib model for incorporat-
oped a generator which can produce binding code au-
ing user-submitted extension modules.
tomatically. In addition, we have developed a small
Haskell module for accessing object-oriented libraries
in a convenient way. This module also supports parts Further reading
of Qt’s signal-slot mechanism. In contrast to the origi- ◦ http://code.haskell.org/diagrams/
nal C++-based solution, type correctness of signal-slot ◦ http://byorgey.wordpress.com/2009/09/24/
connections is checked at compile time with our library. diagrams-0-2-1-and-future-plans/
We plan to develop a HQK-based UI backend ◦ http://www.tug.org/metapost.html
for the Functional Reactive Programming library ◦ http://asymptote.sourceforge.net/
Grapefruit (http://haskell.org/communities/05-2009/
html/report.html#sect6.5.1).
5.10.2 LambdaCube
Further reading Report by: Csaba Hruska
Status: experimental, active development
http://haskell.org/haskellwiki/HQK

LambdaCube is a 3D rendering engine entirely written

5.10 Graphics
5.10.1 diagrams
Report by: Brent Yorgey
Status: active development
The diagrams library provides an embedded domain-
specific language for creating simple pictures and dia-
grams. Values of type Diagram are built up in a compo-
sitional style from various primitives and combinators,
and can be rendered to a physical medium, such as a file
in PNG, PS, PDF, or SVG format. The overall vision
in Haskell.
The main goal of this project is to provide a modern
and feature rich graphical backend for various Haskell
projects, and in the long run it is intended to be a
practical solution even for serious purposes. The en-
gine uses Ogre3D’s (http://www.ogre3d.org) mesh and
material file format, therefore it should be easy to find
or create new content for it. The code sits between the
low-level C API (raw OpenGL, DirectX or anything
equivalent; the engine core is graphics backend agnos-
tic) and the application, and gives the user a high-level
API to work with.
The most important features are the following:

36
◦ loading and displaying Ogre3D models
◦ resource management
◦ modular architecture
If your system has OpenGL and GLUT installed,
the lambdacube-examples package should work out of
the box. The engine is also integrated with the Bullet
physics engine (→ 6.11.7), and you can find a running
example in the lambdacube-bullet package.
Everyone is invited to contribute! You can help well as processing streaming videos.
the project by playing around with the code, thinking
about API design, finding bugs (well, there are a lot of
them anyway), creating more content to display, and
generally stress testing the library as much as possible
by using it in your own projects.
Further reading
http://www.haskell.org/haskellwiki/LambdaCubeEngine
5.10.3 GPipe
Report by: Tobias Bexelius
Status: active development
GPipe models the entire graphics pipeline in a purely
functional, immutable and type-safe way. It is built
on top of the programmable pipeline (i.e., non-fixed
function) of OpenGL 2.1 and uses features such as ver-
tex buffer objects (VBO’s), texture objects, and GLSL
shader code synthetisation to create fast graphics pro-
grams. Buffers, textures, and shaders are cached in-
ternally to ensure fast framerate, and GPipe is also
capable of managing multiple windows and contexts.
GPipe’s aim is to be as close to the conceptual graph-
ics pipeline as possible, and not to add any more levels
of abstraction.
In GPipe, you work with four main data types: Prim-
itiveStreams, FragmentStreams, FrameBuffers, and
textures. They are all immutable, and all parameter-
ized on the type of data they contain to ensure type
safety between pipeline stages. By creating your own Further reading
instances of GPipes type classes, it is possible to use
additional data types on the GPU.
Version 1.0.1 with documentation is released on
Hackage. Work continues on improving performance of
GPipe, including adding support for mutable resources
in some way. I will also expand the wiki with more ex-
amples and tutorials. Any help would be appreciated!
Further reading
http://www.haskell.org/haskellwiki/GPipe
5.10.4 ChalkBoard
Report by: Andy Gill
Participants: Kevin Matlage, Andy Gill
Status: ongoing
ChalkBoard is a domain specific language for describing
images. The language is uncompromisingly functional
and encourages the use of modern functional idioms.
The novel contribution of ChalkBoard is that it uses
off-the-shelf graphics cards to speed up rendering of
our functional description. The intention is that we
will use ChalkBoard to animate educational videos, as
Here is the basic architecture of ChalkBoard.
ChalkBoard DSL Capture
Image / ChalkBoard
Specification & Compile IR
Deep Back End ChalkBoard
DSL 
OpenGL
GPU
The image specification language is a deeply embed-
ded Domain Specific Language (DSL). We capture and
compile our DSL, rather than interpret it directly. In
order to do this, and allow use of a polygon-based back-
end, we have needed to make some interesting compro-
mises, but the language captured remains pure, has
a variant of functors as a control structure, and has
first-class images. We compile this language into an
imperative intermediate representation that has first
class buffers — regular arrays of colors or other entities.
This language is then interpreted by macro-expanding
each intermediate representation command into a set of
OpenGL commands. In this way, we leverage modern
graphics boards to do the heavy lifting of the language.
A release is planned for early November, and will be
available on Hackage.
The new video processing technology will be pre-
miered at PEPM’10.
http://www.ittc.ku.edu/csdl/ChalkBoard
37
5.10.5 graphviz MIDI, but also using a high-performance back-end for
real-time audio.
Report by: Ivan Lazar Miljenovic Euterpea is being developed at Yale in Paul Hudak’s
Status: version 2999.6.0.0 research group, where it has become a key component
The graphviz library provides Haskell bindings to the of Yale’s new Computing and the Arts major. Hudak is
GraphViz suite of tools for visualising graphs. This teaching a two-term sequence in computer music using
library was originally written by Matthew Sackman, Euterpea, and is developing considerable pedagogical
but has been maintained (and almost completely re- material, including a new textbook tentatively titled
written) by myself since the 2009.5.1 release. “The Haskell School of Music”. The name “Euterpea”
The library supports almost all GraphViz attributes, is derived from “Euterpe”, who was one of the nine
and can produce and parse graphs represented in Greek Muses (goddesses of the arts), specifically the
GraphViz’s Dot language (albeit with the limitation Muse of Music.
of strict ordering of Dot statements). Clusters are also
supported, and strings used for labels and identifiers History
are automatically quoted appropriately.
Currently supported are conversions from FGL Haskore is a Haskell library developed almost 15
graphs as well as annotating nodes and edges in FGL years ago by Paul Hudak at Yale for high-level com-
graphs with their positions, etc. Support for other puter music applications. HasSound is a more recent
graph types is planned for a future release. Haskell library developed at Yale that serves as a func-
For a sample graph visualised using the graphviz li- tional front-end to csound’s sound synthesis capabili-
brary, see SourceGraph (→ 4.2.1). ties. Haskore and HasSound have evolved in a number
of different ways over the years, most notably through
Further reading Henning Thielemann’s darcs library for Haskore, to
which many people have contributed. There are many
◦ http://hackage.haskell.org/package/graphviz good ideas in that library, but it has become overly
◦ http://www.graphviz.org/ complex and lacks a coherent design concept.

5.11 Music
5.11.1 Haskore revision
Report by: Henning Thielemann
Participants: Paul Hudak
Status: experimental, active development
See: http://haskell.org/communities/05-2009/html/
report.html#sect5.12.1.
5.11.2 Euterpea
Report by: Paul Hudak
Participants: Eric Cheng, Paul Liu, Donya Quick
Status: experimental, active development
Euterpea is a new Haskell library for computer music
applications. It is a descendent of Haskore and Has-
Sound, and is intended for both educational purposes as
well as serious computer music development. Euterpea
is a “wide-spectrum” library, suitable for high-level mu-
sic representation, algorithmic composition, and anal-
ysis; mid-level concepts such as MIDI; and low-level
audio processing, sound synthesis, and instrument de-
sign. It also includes a “musical user interface”, a set
of computer-music specific GUI widgets such as key-
boards, guitar frets, knobs, sliders, and so on. The
performance of Euterpea is intended to be as good or
better than any existing computer music language – it
can be used for real-time applications, not just using
Future plans
The Euterpea developers’ plan is to shamelessly steal
good ideas from these previous efforts, integrate them
into a coherent new framework, remove dependencies
from as many non-Haskell libraries as possible, add new
features such as musical GUI widgets, and incorporate
new methods for high-performance stream processing
recently developed at Yale, to make Euterpea the li-
brary of choice for discriminating computer music hack-
ers.
Further reading
◦ http://plucky.cs.yale.edu/cs431
◦ http://plucky.cs.yale.edu/cs431/HaskoreSoeV-0.12.
pdf
5.12 Web and XML programming
5.12.1 Haskell XML Toolbox
Report by: Uwe Schmidt
Status: seventh major release (current release: 8.3.2)
Description
The Haskell XML Toolbox (HXT) is a collection of
tools for processing XML with Haskell. It is itself
purely written in Haskell 98. The core component of
the Haskell XML Toolbox is a validating XML-Parser

38
that supports almost fully the Extensible Markup Lan- describing the design of the toolbox, the DTD val-
guage (XML) 1.0 (Second Edition). There is a valida- idator, the arrow based Relax NG validator, and the
tor based on DTDs and a new more powerful one for XSLT system.
Relax NG schemas. A getting started tutorial about HXT is avail-
The Haskell XML Toolbox is based on the ideas of able in the Haskell Wiki (http://www.haskell.org/
HaXml (http://haskell.org/communities/05-2009/html/ haskellwiki/HXT ). The conversion between XML
report.html#sect5.13.2) and HXML, but introduces and native Haskell datatypes is described in an-
a more general approach for processing XML with other Wiki page (http://www.haskell.org/haskellwiki/
Haskell. The processing model is based on arrows. The HXT/Conversion_of_Haskell_data_from/to_XML).
arrow interface is more flexible than the filter approach
taken in the earlier HXT versions and in HaXml. It is 5.12.2 tagsoup
also safer; type checking of combinators becomes pos-
sible with the arrow approach. Report by: Neil Mitchell
HXT consists of two packages, the old first approach
(hxt-filter) based on filters and the newer and more
TagSoup is a library for extracting information out of
flexible and safe approach using arrows (hxt). The old
unstructured HTML code, sometimes known as tag-
package hxt-filter, will further be maintained to work
soup. The HTML does not have to be well formed,
with the latest ghc version, but new development will
or render properly within any particular framework.
only be done with the arrow based hxt package.
This library is for situations where the author of the
HTML is not cooperating with the person trying to
Features extract the information, but is also not trying to hide
the information.
◦ Validating XML parser The library provides a basic data type for a list of un-
◦ Very liberal HTML parser structured tags, a parser to convert HTML into this tag
◦ Lightweight lazy parser for XML/HTML based on type, and useful functions and combinators for finding
Tagsoup (→ 5.12.2) and extracting information. The library has seen real
◦ Easy de-/serialization between native Haskell data use in an application to give Hackage (→ 5.1) listings,
and XML by pickler and pickler combinators and is used in the next version of Hoogle (→ 4.3.1).
◦ XPath support Work continues on the API of tagsoup, and the im-
◦ Full Unicode support plementation. In particular the development version is
◦ Support for XML namespaces based around the HTML 5 specification, and supports
◦ Cabal package support for GHC many flavours of ByteString in addition to String.
◦ HTTP access via Haskell bindings to libcurl
◦ Tested with W3C XML validation suite
Further reading
◦ Example programs
◦ Relax NG schema validator http://community.haskell.org/~ndm/tagsoup
◦ An HXT Cookbook for using the toolbox and the
arrow interface
◦ Basic XSLT support
◦ Darcs repository with current development version
(8.3.1) under http://darcs2.fh-wedel.de/hxt

Current Work

Currently mainly maintenance work is done. This in-

cludes space and runtime optimizations.
The HXT library is extensively used in the Holumbus
project (→ 6.3.1), there it forms the basis for the index
generation.

Further reading

The Haskell XML Toolbox Web page (http:

//www.fh-wedel.de/~si/HXmlToolbox/index.html)
includes downloads, online API documentation, a
cookbook with nontrivial examples of XML processing
using arrows and RDF documents, and master theses

39
6 Applications and Projects

6.1 For the Masses 6.1.2 xmonad

6.1.1 Darcs Report by: Don Stewart

Status: active development
Report by: Eric Kow
Participants: Reinier Lamers, Ganesh Sittampalam xmonad is a tiling window manager for X. Windows are
Status: active development arranged automatically to tile the screen without gaps
or overlap, maximizing screen use. Window manager
features are accessible from the keyboard: a mouse is
Darcs is a distributed revision control system written
optional. xmonad is written, configured, and extensi-
in Haskell. In Darcs, every copy of your source code
ble in Haskell. Custom layout algorithms, key bindings,
is a full repository, which allows for full operation in a
and other extensions may be written by the user in con-
disconnected environment, and also allows anyone with
fig files. Layouts are applied dynamically, and different
read access to a Darcs repository to easily create their
layouts may be used on each workspace. Xinerama is
own branch and modify it with the full power of Darcs’
fully supported, allowing windows to be tiled on several
revision control. Darcs is based on an underlying the-
physical screens.
ory of patches, which allows for safe reordering and
merging of patches even in complex scenarios. For all The new release 0.7 of xmonad added full support for
its power, Darcs remains a very easy to use tool for ev- the GNOME and KDE desktops, and adoption contin-
ery day use because it follows the principle of keeping ues to grow, with binary packages of xmonad available
simple things simple. for all major distributions.
Our most recent major release, Darcs 2.3, was in July
2009. This release provides better performance and
Further reading
easier installation. The next release promises to be a
particularly exciting one: ◦ Homepage: http://xmonad.org/
1. Faster repository-local operations: Darcs devel- ◦ Darcs source:
oper Petr Rockai has succesfully completed his 2009 darcs get http://code.haskell.org/xmonad
Google Summer of Code program. This work opti- ◦ IRC channel: #xmonad @ irc.freenode.org
mizes Darcs’ use of hashed storage repositories, mak- ◦ Mailing list: hxmonad@haskell.orgi
ing Darcs faster and more scalable in repository-local
operations. We are extremely grateful for generous
support of the Haskell.org mentoring organization, 6.2 Education
which has provided us with one of their Google Sum-
mer of Code slots. 6.2.1 Exercise Assistants
2. Hunk-splitting: Ganesh Sittampalam has imple- Report by: Bastiaan Heeren
mented an improvement that gives users much Participants: Alex Gerdes, Johan Jeuring, Josje Lodder,
greater control over patches created by Darcs. In José Pedro Magalhães
the interactive darcs record interface, users can opt Status: experimental, active development
to split hunk patches into smaller pieces, allowing for
more granular patches where appropriate and mak-
ing cherry picking more useful in practice. At the Open Universiteit Nederland and Universiteit
These changes and more will appear in the upcoming Utrecht we are continuing our work on tools that
Darcs 2.4 release, scheduled for January 2010. We still support students in solving exercises incrementally by
have a lot progress to make and are always open to checking intermediate steps. The distinguishing feature
contributions. Haskell hackers, we need your help! of our tools is the detailed feedback that they provide,
Darcs is free software licensed under the GNU GPL. on several levels. For example, we have an online exer-
Darcs is a proud member of the Software Freedom Con- cise assistant that helps to rewrite logical expressions
servancy, a US tax-exempt 501(c)(3) organization. We into disjunctive normal form. Students get instant feed-
accept donations at http://darcs.net/donations.html. back when solving an exercise, and can ask for a hint
at any point in the derivation. Other areas covered
by our tools are solving equations, reducing matrices
Further reading
to echelon normal form, and simplifying expressions in
http://darcs.net relation algebra.

40
 ◦ Alex Gerdes, Johan Jeuring, and Bastiaan Heeren.
Using Strategies for Assessment of Programming Ex-
ercises. To appear in the Technical Symposium on
Computer Science Education (SIGCSE 2010).

6.2.2 Holmes, plagiarism detection for Haskell

Report by: Jurriaan Hage
Participants: Brian Vermeer
Years ago, Jurriaan Hage developed Marble to detect
plagiarism among Java programs. Marble was written
in Perl, takes just 660 lines of code and comments, and
does the job well. The techniques used there, however,
do not work well for Haskell, which is why a master
thesis project was started, starring Brian Vermeer as
We have just started to explore exercise assistants the master student, to see if we can come up with a
for learning how to program in Haskell. A case study working system to discover plagiarism among Haskell
was performed to use programming strategies for auto- programs. We are fortunate to have a large group of
matically assessing student programs submitted for a students each year that try their hand at our functional
first-year course on functional programming in Utrecht. programming course (120-130 per year), and we have
For each exercise domain, we need the same function- all the loggings of Helium that we hope can help us tell
ality, such as unifying and rewriting terms, generating whether the system finds enough plagiarism cases. The
exercises, traversing terms, and testing for (top-level) basic idea is to implement as many metrics as possible,
equality of two terms. For these parts we are currently and to see, empirically, which combination of metrics
using the generic programming libraries Uniplate and scores well enough for our purposes. The implementa-
Multirec, which help us to reduce code size and im- tion will be made in Haskell. One of the things that
prove the reliability of our code. We have reported we are particularly keen about, is to make sure that for
our experiences with generic programming for domain assignments in which students are given a large part of
reasoners, and identified some missing features in the the solution and they only need to fill in the missing
libraries. Fully exploiting generic programming tech- parts, we still obtain good results.
niques is ongoing work. We are currently at the stage that metrics can be
We have recently integrated our tools with the Digi- implemented on top of the Helium front-end. Many of
tal Mathematics Environment (DWO) of the Freuden- these metrics will be defined on an auxiliary structure,
thal Institute. This environment contains a collection the function-call flow graph. Dead-code removal has
of applets for practicing exercises in mathematics. A taken place, fully qualified names are used throughout,
selected number of applets has been extended with our and template removal is now easily possible.
facility to automatically generate hints and worked-out
examples, and the first results are promising. To offer 6.2.3 INblobs — Interaction Nets interpreter
this service, we have introduced views for mathematical
expressions (based on the views proposed by Wadler), Report by: Miguel Vilaca
and combined these with our rewriting technology. A Participants: Daniel Mendes
Status: active
view specifies a canonical form, and abstracts over a set
Portability: portable (depends on wxHaskell)
of algebraic laws. Our feedback services have recently
been released as a Cabal source package. See: http://haskell.org/communities/05-2009/html/
report.html#sect6.2.4.
Further reading
6.2.4 Yahc
◦ Online exercise assistant, accessible from our project
Report by: Miguel Pagano
page.
Participants: Renato Cherini
◦ Bastiaan Heeren and Johan Jeuring. Canonical Status: experimental, maintained
Forms in Interactive Exercise Assistants. Pro- The first course on algorithms in CS at Universidad Na-
ceedings of Mathematical Knowledge Management cional de Córdoba is centered on the derivations of al-
(MKM 2009). gorithms from specifications, as proposed by R.S. Bird
(Introduction to functional programming using Haskell,
◦ Johan Jeuring, José Pedro Magalhães, and Bastiaan
Prentice Hall Series in Computer Science, 1998), E.W.
Heeren. Generic Programming for Domain Reason-
Dijkstra (A Discipline of Programming, Prentice Hall,
ers. To appear in the Symposium on Trends in Func-
1976), and R.R. Hoogerwoord (The design of functional
tional Programming (TFP 2009).

41
programs: a calculational approach, Technische Uni-
versiteit Eindhoven, 1989). To achieve this goal, stu-
dents should acquire the ability to manipulate complex
predicate formulae; thus the students first learn how
to prove theorems in a propositional calculus similar
to the equational propositional logic of D. Gries and
F.B. Schneier (A Logical Approach to Discrete Math,
Springer-Verlag, 1993).
During the semester students make many derivations
as exercises and it is helpful for them to have a tool
for checking the correctness of their solutions. Yahc
checks the correctness of a sequence of applications of
some axioms and theorems to the formulae students
are trying to prove. The student starts a derivation by
entering an initial formula and a goal and then pro-
ceeds by telling Yahc which axiom will be used and the
expected outcome of applying the axiom as a rewrite
rule; if that rewriting step is correct then the process
continues until the student reaches the goal.
At this moment the tool is in an early stage and we
only consider propositional connectives (some of them
associative-commutative). We expect to extend Yahc
for allowing the resolution of logical puzzles. In the
long term we are planning to consider an equational
calculus with functions defined by induction over lists
and natural numbers.
Further reading
http://www.cs.famaf.unc.edu.ar/~mpagano/yahc/
6.2.5 grolprep
Report by: Dino Morelli
Participants: Betty Diegel
Status: experimental, actively developed
grolprep is a web application for studying the FCC
GROL questions in preparation of taking the exams.
The study of this multiple-choice data is in the flash-
card style. Students can choose from Elements 1, 3
and 8 and can specify any subelement of those three for
specific study. Questions and answers can be randomly
presented.
Additionally, simulations of the randomly-chosen ex-
ams can be practiced with this software.
grolprep will shortly be used by students of Avionics
program at the Burlington Aviation Technology School.
Further reading
◦ Live website: http://ui3.info/grolprep/bin/ ◦ Highly configurable crawler module for flexible in-
fcc-grol-prep.cgi
◦ Project page: http://ui3.info/d/proj/grolprep.html
◦ Source repository: darcs get http://ui3.info/darcs/
grolprep
6.3 Web Development
6.3.1 Holumbus Search Engine Framework
Report by: Uwe Schmidt
Participants: Timo B. Hübel, Sebastian Reese,
Sebastian Schlatt, Stefan Schmidt, Björn
Peemöller, Stefan Roggensack, Alexander
Treptow
Status: first release
Description
The Holumbus framework consists of a set of modules
and tools for creating fast, flexible, and highly cus-
tomizable search engines with Haskell. The framework
consists of two main parts. The first part is the indexer
for extracting the data of a given type of documents,
e.g., documents of a web site, and store it in an appro-
priate index. The second part is the search engine for
querying the index.
An instance of the Holumbus framework is the
Haskell API search engine Hayoo! (http://holumbus.
fh-wedel.de/hayoo/). The web interface for Hayoo! is
implemented with the Janus web server, written in
Haskell and based on HXT (→ 5.12.1).
The framework supports distributed computations
for building indexes and searching indexes. This is done
with a MapReduce like framework. The MapReduce
framework is independent of the index- and search-
components, so it can be used to develop distributed
systems with Haskell.
The framework is now separated into four packages,
all available on Hackage.
◦ The Holumbus Search Engine
◦ The Holumbus Distribution Library
◦ The Holumbus Storage System
◦ The Holumbus MapReduce Framework
The search engine package includes the indexer and
search modules, the MapReduce package bundles the
distributed MapReduce system. This is based on two
other packages, which may be useful for their on: The
Distributed Library with a message passing communi-
cation layer and a distributed storage system.
Features
dexing of structured data
◦ Customizable index structure for an effective search
◦ find as you type search
◦ Suggestions
42
◦ Fuzzy queries thesis-searching.pdf. Sebastian Schlatt’s thesis deal-
ing with the crawler component is available at http://
◦ Customizable result ranking holumbus.fh-wedel.de/src/doc/thesis-indexing.pdf. The
thesis of Stefan Schmidt describing the Holumbus
◦ Index structure designed for distributed search
MapReduce is available via http://holumbus.fh-wedel.
◦ Darcs repository with current development version de/src/doc/thesis-mapreduce.pdf.
under http://darcs2.fh-wedel.de/holumbus
6.3.2 HCluster
◦ Distributed building of search indexes
Report by: Alberto Gómez Corona
Current Work
HCluster (provisional name) is a remote clustering mid-
The indexer and search module will be used and
dleware aimed initially at verifying online and offline
extended to support the Hayoo! engine for search-
computations in distributed electoral processes. Ex-
ing the hackage package library (http://holumbus.fh-
tended to permit clustering with distributed transac-
wedel.de/hayoo/hayoo.html).
tions and cloud computing.
In a follow-up project of Stefan Schmidt’s system, Se-
basian Reese is working on a cookbook for programming ◦ distributed transactions between connected nodes in
with the MapReduce framework and for giving tuning the Internet
and configuration hints. Benchmarks for various small
◦ work with online nodes as well as offline + synchro-
problems and for generating search indexes have shown
nization
that the architecture scales very well. The thesis with
the final results will be finished end of March 2010. ◦ hot plug-in of nodes
In a further subproject, the so called Hawk system,
◦ no single point of failure/control
Björn Peemöller and Stefan Roggensack developped a
web framework for Haskell. The results of this master ◦ theoretical massive scalability, reliability, availability
thesis will be published soon on the Holumbus web site.
Any node can initiate a process (that may involve a
The Hawk system is comparable in functionality and
transaction, a query, a calculation etc.). The design of
architecture with Ruby on Rail and other web frame-
synchronization permits nodes to work in online as well
works. Its architecture follows the MVC pattern. It
as offline mode with periodic synchronization with cer-
consists of a simple relational database mapper for per-
tain restrictions. The restrictions depend on algebraic
sistent storage of data and a template system for the
properties of the transactions.
view component. This template system has two inter-
Distribution of data and distributed transactions are
esting features: First the templates are valid XHTML
possible. The distribution is transparent to the pro-
documents. The parts where data has to be filled in
grammer, so re-locations of data can be done among
are marked with Hawk specific elements and attributes.
the nodes.
These parts are in a different namespace, so they do not
Finished basic services: HTTP protocol, reconnec-
destroy the XHTML structure. The second interesting
tion, synchronization. Testing synchronization and on-
feature is that the templates contain type descriptions
line clustering now defined and coded the model for
for the values to be filled in. This type information en-
distributed transactions.
ables a static check whether the models and views fit
together.
The Hawk framework is independent of the Holum- Future plans
bus search engine. It will be applicable for the devel- ◦ test distributed transactions
opment of arbitrary web applications, but one of the ◦ create internet documentation
first applications is the reimplementation of the web
interface for the Hayoo! search engine. This project Contact
will be done by Alexander Treptow within the next six
months. hagocorona@gmail.comi

Further reading 6.3.3 JavaScript Monadic Writer

The Holumbus web page (http://holumbus.fh-wedel. Report by: Dmitry Golubovsky

de/) includes downloads, Darcs web interface, cur-
rent status, requirements, and documentation. Timo
Hübel’s master thesis describing the Holumbus in-
dex structure and the search engine is available
at http://holumbus.fh-wedel.de/branches/develop/doc/
Status: active development
JavaScript Monadic Writer (JSMW) is an extensible
monadic framework on top of the Haskell DOM bind-
ings. It provides an EDSL to encode JavaScript state-
ments and expressions in typesafe manner. It borrows

43
some ideas from HJScript, but uses slightly different Haskell converter is based on H/Direct IDL parser. Au-
EDSL notation. tomatic IDL conversion is expected to simplify Haskell
The idea behind JSWM is to provide an intermedi- Web development because of the large number of
ate form that could be used as an end-point for con- methods and attributes defined in contemporary DOM
version from Haskell Core. The EDSL however may be whose type signatures are hard and time-consuming to
considered as a programming tool on its own. While derive manually.
the EDSL alone is not sufficient for translation of an
arbitrary Haskell program to JavaScript, Haskell type
Further reading
system is still available to help produce correct code.
◦ Document Object Model (DOM) Technical Reports
Further reading http://www.w3.org/DOM/DOMTR
◦ The DOM package on Hackage
The jsmw package on Hackage: http://hackage.haskell. http://hackage.haskell.org/cgi-bin/hackage-scripts/
org/cgi-bin/hackage-scripts/package/jsmw package/DOM

6.3.4 Haskell DOM Bindings 6.3.5 gitit

Report by: Dmitry Golubovsky
Status: active development
Haskell DOM bindings is a set of monadic smart
constructors on top of the WebBits representation of
JavaScript syntax to generate JavaScript code that
calls DOM methods and accesses DOM objects’ at-
tributes.
In order to represent the hierarchy of DOM inter-
faces, Haskell type classes are used. For example, for
the interfaces Node and Document (the latter inher-
its from the former) there are two classes: CNode and
CDocument. Also, for each DOM interface, a phantom
data type is defined: TNode, and TDocument in this
case. Phantom types represent concrete values (refer-
ences to DOM objects) while type classes are used for
type constraints in functions working with DOM ob-
jects. The CDocument class is defined as:
Report by: John MacFarlane
Participants: Gwern Branwen, Simon Michael, Henry
Laxen, Anton van Straaten, Robin Green,
Thomas Hartman, Justin Bogner, Kohei
Ozaki, Dmitry Golubovsky, Anton
Tayanovskyy, Dan Cook
Status: active development
Gitit is a wiki built on Happstack and backed by a git
or darcs filestore. Pages and uploaded files can be mod-
ified either directly via the VCS’s command-line tools
or through the wiki’s web interface. Pandoc (→ 6.4.1)
is used for markup processing, so pages may be written
in (extended) markdown, reStructuredText, LaTeX,
HTML, or literate Haskell, and exported in ten dif-
ferent formats, including LaTeX, ConTeXt, DocBook,
RTF, OpenOffice ODT, and MediaWiki markup.
Notable features of gitit include:

class CNode a => CDocument a ◦ Plugins: users can write their own dynamically
data TNode loaded page transformations, which operate directly
data TDocument on the abstract syntax tree.
instance CNode TNode ◦ Math support: LaTeX inline and display math
instance CDocument TDocument is automatically converted to MathML, using the
instance CNode TDocument texmath library.
Type constraints are used to define methods of each ◦ Highlighting: Any git or darcs repository can be
class, e. g. made a gitit wiki. Directories can be browsed,
and source code files are automatically syntax-
hasChildNodes :: (Monad mn, CNode this) highlighted. Code snippets in wiki pages can also
=> Expression this -> mn (Expression Bool) be highlighted.
so, hasChildNodes can be called on both Node and ◦ Library: Gitit now exports a library,
Document, but Network.Gitit, that makes it easy to include
a gitit wiki (or wikis) in any Happstack application.
createElement :: (Monad mn, CDocument this,
CElement zz) ◦ Literate Haskell: Pages can be written directly in
=> Expression String -> Expression this literate Haskell.
-> mn (Expression zz)
Further reading
only on nodes representing documents.
The bindings were auto-generated from OMG IDL http://gitit.net (itself a running demo of gitit)
files provided by the Web Consortium. The IDL to

44
6.4 Data Management and Visualization The tool also contains a front-end to read spread-
sheets in the Excel and Gnumeric formats: the front-
6.4.1 Pandoc end reads spreadsheets in portable XML documents us-
ing the UMinho Haskell Libraries. We reuse the spatial
Report by: John MacFarlane logic algorithms from the UCheck project to discover
Participants: Andrea Rossato, Peter Wang, Paulo
the tables stored in the spreadsheet.
Tanimoto
Finally, two spreadsheet tools are available: a batch
Status: active development
and an online tool that allows the users to read, trans-
form and refactor spreadsheets.
Pandoc aspires to be the swiss army knife of text Using part of HaExcel, we developed an OpenOffice
markup formats: it can read markdown and (with some Calc (http://www.openoffice.org/product/calc.html) ad-
limitations) HTML, LaTeX, and reStructuredText, and don. Its back-end reuses part of HaExcel and its front-
it can write markdown, reStructuredText, HTML, Doc- end is written in OpenOffice Basic. This addon allows
Book XML, OpenDocument XML, ODT, RTF, groff the integration of a relational model into the spread-
man, MediaWiki markup, GNU Texinfo, LaTeX, Con- sheet. Using this model the user gets three new fea-
TeXt, and S5. Pandoc’s markdown syntax includes ex- tures in the spreadsheet environment: auto-completion
tensions for LaTeX math, tables, definition lists, foot- of columns, that is, choosing values of some columns,
notes, and more. other columns become automatically completed; safe
Since the last report, there has been one release deletion of rows where the user is warned when delet-
(1.2.1). ing important information; and no edition of columns
that could compromise the data integrity. All the fea-
◦ Users may notice a significant speedup in read- tures can be enabled and disabled by the user at any
ing markdown in --smart mode; the abbreviations time. A snapshot of a spreadsheet with the addon can
parser has been made much more efficient. be seen below.
◦ Default HTML output now wraps sections in divs
with unique identifiers. This should aid manipula-
tion using javascript and other tools.
◦ We have made some progress in replacing the old
POSIX shell script wrappers with more portable More about this can be read in the paper “Discovery-
Haskell wrappers. based Edit Assistance for Spreadsheets”.
The sources, the online tool and the addon are avail-
Further reading able from the project home page.
http://johnmacfarlane.net/pandoc/ We are currently exploring foreign key constraints
from their detection to their migration to the generated
spreadsheet.
6.4.2 HaExcel — From Spreadsheets to Relational
Databases and Back
Further reading
Report by: Jácome Cunha
http://www.di.uminho.pt/~jacome
Participants: João Saraiva, Joost Visser
Status: unstable, work in progress
6.4.3 SdfMetz
Report by: Tiago Miguel Laureano Alves
HaExcel is a framework to manipulate and transform
Participants: Joost Visser
spreadsheets. It is composed by a generic/reusable
Status: stable, maintained
library to map spreadsheets into relational database
models and back: this library contains an algebraic See: http://haskell.org/communities/05-2009/html/
data type to model a (generic) spreadsheet and func- report.html#sect6.4.5.
tions to transform it into a relational model and vice
versa. Such functions implement the refinement rules 6.4.4 The Proxima 2.0 generic editor
introduced in paper “From Spreadsheets to Relational
Databases and Back”. The library includes two code Report by: Martijn Schrage
generator functions: one that produces the SQL code to Participants: Lambert Meertens, Doaitse Swierstra
create and populate the database, and a function that Status: actively developed
generates Excel/Gnumeric code to map the database
back into a spreadsheet. A MySQL database can also Proxima 2.0 is an open-source web-based version of the
be created and manipulated using this library under Proxima generic presentation-oriented editor for struc-
HaskellDB. tured documents.

45
◦ Proxima is a generic editor. This means that the edi- Further reading
tor can be instantiated for arbitrary document types,
supplemented by parser and presentation sheets.
The content of a Proxima document can be mixed
text, images and diagrams.
◦ Proxima is a presentation-oriented editor. This 6.5.1 Functional Hybrid Modelling
means that the user performs the edit operations on
the WYSIWYG screen presentation of the document. Report by:
◦ Proxima is aware of the structure of the document.
Even while editing the presentation of the document,
the edit operations can be structural. For example,
a section can be changed into a subsection.
Another feature of Proxima is that it offers generic
support for specifying content-dependent computa-
tions. For example, it is possible to create a table of
contents of a document that is automatically updated
as chapters or sections are added or modified.
Proxima 2.0
Proxima 2.0 provides a web-interface for Proxima. In-
stead of rendering the edited document onto an appli-
cation window, Proxima 2.0 is a web-server that sends
an HTML rendering of the document to a client. The
client catches mouse and keyboard events, and sends
these back to the server, after which the server sends
incremental rendering updates back to the client. As a
result, advanced editors can be created, which run in
any browser.
In the past half year, the system has been extended
with drag and drop, improved navigation, session han-
dling, and a number of techniques for handling net-
work latency. Furthermore, a number of example edi-
tors have been implemented. The screenshot shows an
editor for documenting Bayesian networks. It is run-
ning in a Firefox browser.
Future plans
Proxima 2.0 is an open source project. We are looking
for people who would like to participate in the project.
http://www.oblomov.biz/proxima2.0.html
6.5 Functional Reactive Programming
George Giorgidze
Participants: Joey Capper, Henrik Nilsson
Status: active research and development
The goal of the FHM project is to gain a better foun-
dational understanding of non-causal, hybrid modelling
and simulation languages for physical systems and ul-
timately to improve on their capabilities. At present,
our central research vehicle to this end is the design and
implementation a new such language centred around a
small set of core notions that capture the essence of the
domain.
Causal modelling languages are closely related to
synchronous data-flow languages. They model system
behaviour using ordinary differential equations (ODEs)
in explicit form. That is, cause-effect relationship be-
tween variables must be explicitly specified by the mod-
eller. In contrast, non-causal languages model system
behaviour using differential algebraic equations (DAEs)
in implicit form, without specifying their causality. In-
ferring causality from usage context for simulation pur-
poses is left to the compiler. The fact that the causal-
ity can be left implicit makes modelling in a non-causal
language more declarative (the focus is on expressing
the equations in a natural way, not on how to express
them to enable simulation) and also makes the models
much more reusable.
FHM is an approach to modelling which combines
functional programming and non-causal modelling. In
particular, the FHM approach proposes modelling with
first class models (defined by continuous DAEs) using
combinators for their composition and discrete switch-
ing. The discrete switching combinators enable mod-
elling of hybrid systems (i.e. systems that exhibit both
continuous and discrete dynamic behaviour). The key
concepts of FHM originate from work on Functional
Reactive Programming (FRP).
We are implementing Hydra, an FHM language, as
a domain-specific language embedded in Haskell. The
method of embedding employs quasiquoting and en-
ables modellers to use the domain specific syntax in
their models. The present prototype implementation
of Hydra enables modelling with first class models and
supports combinators for their composition and dis-
crete switching.
Recently, we have implemented support for dynamic
switching among models that are computed at the
point when they are being “switched in”. Models that
are computed at run-time are just-in-time (JIT) com-
piled to efficient machine code. This allows efficient
46
simulation of highly structurally dynamic systems (i.e.,
systems where the number of structural configurations
is large, unbounded or impossible to determine in ad-
vance). This goes beyond to what current state-of-the-
art non-causal modelling languages can model. The
implementation techniques that we developed should
benefit other modelling and simulation languages as
well.
We are also exploring ways of utilising the type sys-
tem to provide stronger correctness guarantees and to
provide more compile time reassurances that our sys-
tem of equations is not unsolvable. Properties such as
equational balance (ensuring that the number of equa-
tions and unknowns are balance) and ensuring the solv-
ability of locally scoped variables are among our goals.
Dependent types have been adopted as the tool for ex-
pressing these static guarantees. However, we believe
that more practical type systems (such as system F)
could be conservatively extended to make FHM safer
without compromising their usability.
to any imperative framework, although it is probably
not a good choice to program primarily event-driven
systems, because it is pull-based.
The code is readily available via cabal-install in
the elerea package. You are advised to install
elerea-examples as well to get an idea how to build
non-trivial systems with it. The examples are sepa-
rated in order to minimize the dependencies of the core
library.
Further reading
◦ http://hackage.haskell.org/cgi-bin/hackage-scripts/
package/elerea
◦ http://hackage.haskell.org/cgi-bin/hackage-scripts/
package/elerea-examples
6.6 Audio and Graphics
6.6.1 Audio signal processing

Further reading Report by: Henning Thielemann

Status: experimental, active development
The implementation of Hydra is available from http:
//www.cs.nott.ac.uk/~ggg/ under the open source BSD
license. In this project, audio signals are processed using pure
Haskell code and the Numeric Prelude framework (→
5.5.3). The highlights are:
6.5.2 Elerea
◦ a basic signal synthesis backend for Haskore (→
Report by: Patai Gergely
5.11.1),
Status: experimental, active
◦ support for physical units while maintaining effi-
Elerea (Eventless reactivity) is a tiny continuous-time ciency,
FRP implementation without the notion of event-based ◦ frameworks for abstraction from sample rate, that
switching and sampling, with first-class signals (time- is, the sampling rate can be omitted in most parts
varying values). Reactivity is provided through various of a signal processing expression. We tried hard to
higher-order constructs that also allow the user to work preserve the functional style of programming and do
with arbitrary time-varying structures containing live not need Arrows and according notation.
signals.
Stateful signals can be safely generated at any time ◦ We checked several low-level implementations in or-
through a specialised monad, while stateless combina- der to achieve reasonable speed. We complement
tors can be used in a purely applicative style. Elerea the standard list type with a lazy StorableVector
signals can be defined recursively, and external input structure and a StateT s Maybe a generator, like in
is trivial to attach. A unique feature of the library is stream-fusion. Now, both our custom signal genera-
that cyclic dependencies are detected on the fly and re- tor type and the Stream type from stream-fusion can
solved by inserting delays dynamically, unless the user be fused to work directly on storable vectors.
does it explicitly.
As an example, the following code snippet is a possi- ◦ support for causal processes. Causal signal processes
ble way to define an approximation of our beloved trig only depend on current and past data and thus are
functions: suitable for real-time processing (in contrast to a
function like time reversal). These processes are
(sine,cosine) <- mdo modeled as mapAccumL like functions. Many impor-
s <- integral 0 c tant operations like function composition maintain
c <- integral 1 (-s) the causality property. They are important for shar-
return (s,c) ing on a per sample basis and in feedback loops where
they statically warrant that no future data is ac-
The library is minimal by design, and it provides
cessed.
low-level primitives one can build a cleaner set of com-
binators upon. Also, it is relatively easy to adapt it Recent advances are:

47
◦ Lazy time values to be used for gate signals, n-dimensional convex hull computation were demon-
strated through a graphical user interface written with
◦ enhanced type class framework for unifying lazy time wxHaskell functions. In this report, we have applied
values and signals expressed by lists, storable vectors the same approach to a more complicated spatial anal-
or signal generators. ysis, i.e., convex decomposition of polytops. Convexity
◦ Connection to alsa bindings, in order to provide real- is a simple but useful concept. Convex objects are much
time sound synthesis controlled by MIDI events from easier to deal with in terms of storage and operations:
keyboards or sequencers, the intersection of two convex objects is a convex ob-
ject, the calculation of areas/volumes is straightforward
◦ Stand-alone binding to Sox for audio format conver- and so is the “point-in-polygon” problem, etc.
sion and playback,
There are several approaches to decompose a poly-
◦ A pyramid filter for efficient computation of moving top to convex components, some of which may be
average and moving maximum for baseline detection adapted for different dimensions. However, they still
of mass spectra, require separate implementations for each dimension.
The main reason is lack of suitable data structures in
Further reading the current programming languages. We use the n-
simplexes to implement an n-dimensional algorithm for
◦ http://www.haskell.org/haskellwiki/Synthesizer convex decomposition of polytops. It builds a tree of
◦ http://dafx04.na.infn.it/WebProc/Proc/P_201.pdf signed convex components: components in even lev-
els are additive, whereas components in odd levels are
6.6.2 easyVision subtractive. An example figure:

Report by: Alberto Ruiz

Status: experimental, active development

The easyVision project is a collection of experimental

libraries for computer vision and image processing. The
low level computations are internally implemented by
optimized libraries (IPP, HOpenGL, hmatrix (→ 5.3.1),
etc.). Once appropriate geometric primitives have been
extracted by the image processing wrappers we can de-
fine interesting computations using elegant functional
constructions. Future work includes cabalization of the
main modules.

Further reading
http://www.easyVision.googlepages.com

6.6.3 photoname The algorithm starts with placing the convex hull of
the input polytop as the root of the tree. Subtraction
Report by: Dino Morelli
of the computed convex hull from the input polytop
Status: stable, maintained
yields a set of split polytops, which are the elements of
See: http://haskell.org/communities/05-2009/html/ the next level of the tree. The procedure applies to the
report.html#sect6.6.4. non-convex elements and it repeats until all of the ele-
ments are convex. The list data structures and list op-
6.6.4 n-Dimensional Convex Decomposition of erations are used for implementation of the algorithm.
Polytops Polytops are represented as a list of n-simplexes, which
are described as a list of points, per se. It allows us
Report by: Farid Karimipour to describe the operations for convex decomposition of
Participants: Rizwan Bulbul, Andrew U. Frank polytops as a combination of operations of n-simplexes,
Status: active development
which turns to be operations on lists. Since the repre-
This is the continuation of the work on “Simplex-based sentation and operations are defined independent of di-
Spatial Operations” (http://haskell.org/communities/ mension, the decomposition algorithm can be used for
05-2009/html/report.html#sect6.6.5), where we showed polytops of any dimension. The following figure shows
how to implement dimension independent spatial oper- a 2D example polytop which is decomposed to convex
ations using the concept of n-simplexes. The results for components as the above figure.

48
 6.6.6 Fl4m6e
Report by: Claude Heiland-Allen
Status: unstable
Fl4m6e is a fast fractal flame renderer, currently un-
der active development. Inspired by flam3 and electric
sheep, Fl4m6e performs all the rendering calculations
on the GPU, using OpenGL shaders. The features so
far include runtime generation of low level GLSL source
code from abstract scene descriptions, smooth transi-
tions between scenes using rigid transformations, and
interactive control of animation and quality settings.
Further reading Contrasting to flam3, the aim is not exact image re-
producibility, but to get fast enough that pre-rendering
http://haskell.org/communities/05-2009/html/report. videos is not necessary — then a peer-to-peer network
html#sect6.6.5 exchanging small scene descriptions would supercede
a centralized file server and corresponding large band-
6.6.5 DVD2473 width requirements. However, there is a long way to go
before the electric sheep have anything to worry about.
Report by: Claude Heiland-Allen
Status: complete
DVD2473 is a generative DVD video artwork.
The somewhat abstract title is a semi-literal descrip-
tion with all the descriptive elements taken out - it is
a DVD of a perfect coloring in 24 colors of a 7,3 hy-
perbolic tiling. It uses the DVD virtual machine to
navigate around the space at pseudo-random.
The mathematics (permutations and Moebius trans-
forms) of the space were implemented in Haskell, with
rendering with Gtk2Hs/Cairo including a little C code
to copy and convert pixels from Cairo to ByteString.
The video encoding used HSH to pipe ByteString to
external tools. The XML control file for DVD author- Further reading
ing was generated with a separate Haskell program. A
bash script automates building an iso from the source ◦ http://claudiusmaximus.goto10.org/cm/2009-08-28_
code directory. fl4m6e_proof_of_concept.html
There are no plans for further development, the art- ◦ http://claudiusmaximus.goto10.org/cm/2009-09-24_
work is finished. fl4m6e_in_haskell.html
◦ http://claudiusmaximus.goto10.org/g/fl4m6e/
examples/
◦ http://flam3.com/
◦ http://electricsheep.org/

6.6.7 GULCI
Report by: Claude Heiland-Allen
Status: unstable
GULCI is a graphical untyped lambda calculus inter-
preter. Programs are written with mouse clicks and
drags, and executed with a keypress. During execution
the graph reduction is visualized. GULCI also dumps
data on its standard output stream, suitable for soni-
fication. The eventual intent is to use it for a short
abstract code performance sometime in the future.
Further reading GULCI is the interactive descendant of the non-
http://claudiusmaximus.goto10.org/cm/2009-01-07_ interactive (but also graphical) ULCIv1, which took
dvd2473.html the form of audiovisualisations of some simple arith-

49
metical computations in untyped lambda calculus.
Further reading
http://claudiusmaximus.goto10.org/cm/2009-06-19_
untyped_lambda_calculus_interpretations_v1.html
6.6.8 Reflex
Report by: Claude Heiland-Allen
Status: experimental
Reflex is a program to interactively experience vari-
ously truncated regular 4D polytopes. The name is in-
spired by reflection symmetry groups and the eventual
intent of using it as an interactive live audiovisual per-
formance environment with quick reactions required,
the idea for the software itself is inspired by The Sym-
metriad.
Starting from the Shlaefli symbol p, q, r, Reflex con-
structs a 4D symmetry group, from which a wide va-
riety of different forms can be visualized. The pro-
jection method results in aesthetically pleasing curves,
enhanced by the animation. Currently Reflex accepts
commands on its standard input, but the goal is to use
a game controller to navigate through the world.
Further reading
◦ http://claudiusmaximus.goto10.org/cm/2009-10-15_
reflex_preview.html
◦ http://web.mit.edu/~axch/www/Symmetriad/index.
html
◦ http://en.wikipedia.org/wiki/SchlÃďfli_symbol
50
6.7 Proof Assistants and Reasoning
6.7.1 Galculator
Report by: Paulo Silva
Status: unstable, work in progress
See: http://haskell.org/communities/05-2009/html/
report.html#sect6.7.1.
6.7.2 Saoithín: a 2nd-order proof assistant
Report by: Andrew Butterfield
Status: ongoing
Saoithín (pronounced “Swee-heen”) is a GUI-based
2nd-order predicate logic proof assistant. The motiva-
tion for its development is the author’s need for support
in doing proofs within the so-called “Unifying Theo-
ries of Programming” paradigm (UTP). This requires
support for 2nd-order logic, equational reasoning, and
meets a desire to avoid re-encoding the theorems into
some different logical form. It also provides proof tran-
scripts whose style makes it easier to check their cor-
rectness.
Saothín is implemented in GHC 6.4 and wxHaskell
0.9.4, with elements of Mark Utting’s jaza tool for
Z, and has been tested on a range of Windows plat-
forms (98/XP/Vista), and should work in principle on
Linux/Mac OS X.
A version of the software has been trialled out
on 3rd-year students taking a Formal Methods elec-
tive course (https://www.cs.tcd.ie/Andrew.Butterfield/
Teaching/3BA31/#Software) A first public release of
the software under GPL will now happen during Sum-
mer 2009 — For now, Windows executables can be
downloaded from the above link.
Further reading
https://www.cs.tcd.ie/Andrew.Butterfield/Saoithin
6.7.3 Inference Services for Hybrid Logics
Report by: Guillaume Hoffmann
Participants: Carlos Areces, Daniel Gorin
“Hybrid Logic” is a loose term covering a number of
logical systems living somewhere between modal and
classical logic. For more information on this languages,
see http://hylo.loria.fr
The Talaris group at Loria, Nancy, France (http:
//talaris.loria.fr) and the GLyC group at the Com-
puter Science Department of the University of Buenos
Aires, Argentina (http://www.glyc.dc.uba.ar/) are de-
veloping a suite of tools for automated reasoning for
hybrid logics, available at http://code.google.com/p/
intohylo/. Most of them are (successfully) written in
Haskell. See HyLoRes (http://haskell.org/communities/
05-2009/html/report.html#sect6.7.5), HTab (→ 6.7.4),
and HGen (http://haskell.org/communities/05-2009/ of Isabelle has a more restrictive type system than
html/report.html#sect6.7.7). Haskell. A simple adaption mechanisms allows to tailor
the conversion process to specific needs.
6.7.4 HTab So far, Haskabelle is working, but there is little expe-
rience for its application in practice. Suggestions and
Report by: Guillaume Hoffmann feedback welcome. A tool demo is given at PEPM’10.
Participants: Carlos Areces, Daniel Gorin
Status: active development
Further reading
Current release: 1.5.1
http://isabelle.in.tum.de/haskabelle.html and http://
isabelle.in.tum.de/
HTab is an automated theorem prover for hybrid log-
ics (→ 6.7.3) based on a tableau calculus. It handles
hybrid logic with nominals, satisfaction operators, con- 6.8 Modeling and Analysis
verse modalities, universal and difference modalities,
the down-arrow binder and role inclusion. 6.8.1 iTasks
The source code is distributed under the terms of the
Report by: Bas Lijnse
GNU GPL. Participants: Rinus Plasmeijer, Peter Achten, Pieter
Koopman, Thomas van Noort, Jan Martin
Further reading Jansen, Erik Crombag
Status: active development
◦ Hoffmann, G. and Areces, C. HTab: a terminat-
ing tableaux system for hybrid logic. In Methods for
Modalities 5, Cachan, France, 2007. The iTask system provides a set of combinators to
◦ Site and source: specify workflow in the pure and functional language
http://code.google.com/p/intohylo/ Clean (→ 3.2.3) at a very high level of abstraction.
Workflow systems are automated systems in which
6.7.5 Sparkle tasks are coordinated that have to be executed by ei-
ther humans or computers. Workflow specifications are
Report by: Maarten de Mol supplemented with a generic foundation to generate
Participants: Marko van Eekelen, Rinus Plasmeijer executable multi-user workflow support systems that
Status: stable, maintained consist of a webservice-based server and a user-friendly
See: http://haskell.org/communities/05-2009/html/ Ajax client.
report.html#sect6.7.8. Compared to contemporary workflow systems, that
often use simple graphical specification languages, the
iTask system offers several advantages:
6.7.6 Haskabelle
◦ Tasks are statically typed and can be higher-order.
Report by: Florian Haftmann
Status: working ◦ Combinators are fully compositional.

◦ Dynamic and recursive workflow is supported.

Since Haskell is a pure language, reasoning about
equational semantics of Haskell programs is conceptu- ◦ Workflow instances can be modified during execu-
ally simple. To facilitate machine-aided verification of tion.
Haskell programs further, we have developed a con-
verter from Haskell source files to Isabelle theory files:
Haskabelle.
Isabelle itself is a generic proof assistant. It allows
mathematical formulas to be expressed in a formal lan-
guage and provides tools for proving those formulas in
a logical calculus. One such formal language is higher-
order logic, a typed logic close to functional program-
ming languages. This is used as translation target of
Haskabelle.
Both Haskabelle and Isabelle in combination allow to
formally reason about Haskell programs, particularly
verifying partial correctness.
The conversion employed by Haskabelle covers only
a subset of Haskell, mainly since the higher-order logic

51
 The iTask system makes extensive use of Clean’s The ForSyDe (Formal System Design) methodology
generic programming facilities for generating dynamic has been developed with the objective to move system-
user-interfaces and data encoding/decoding. on-chip design to a higher level of abstraction. ForSyDe
is implemented as a Haskell-embedded behavioral DSL.
The current released is ForSyDe 3.0, which includes a
Future plans
new deep-embedded DSL and embedded compiler with
Currently, we are working on extending and stabilizing different backends (Simulation, Synthesizable VHDL
the iTask base system to a level where it can be used and GraphML), as well as a new user-friendly tutorial.
for serious applications. We are also exploring how The source code, together with example system mod-
even more dynamic and unpredictable workflows can els, is available from HackageDB under the BSD3 li-
be supported. cense.

Further reading Features

◦ http://itasks.cs.ru.nl/
◦ http://www.st.cs.ru.nl/Onderzoek/Publicaties/
publicaties.html
6.8.2 CSP-M animator and model checker
Report by: Marc Fontaine
Status: active development, download available
We develop an Haskell based, integrated CSP-M an-
imator and model checker. CSP (Communicating-
Sequential-Processes) is a formalism for concurrent sys-
tems, invented by Tony Hoare. CSP-M is the concrete
syntax used by several CSP-tools.
Our Haskell-CSP-Tool features:
◦ FDR compatibility
◦ Fast computation of state spaces
◦ GTK+ based graphical user interface
◦ Support for shared-memory-parallelism / multicore
CPUs
Binary releases are available for download via http:
//www.stups.uni-duesseldorf.de/~fontaine/csp.
The Parsec-based CSP-M parser of our project is also
on Hackage. This is also the parser used by the ProB
model-checker.
Further reading
http://www.stups.uni-duesseldorf.de/~fontaine/csp
6.9 Hardware Design
6.9.1 ForSyDe
Report by: Ingo Sander
Participants: Alfonso Acosta, Axel Jantsch, Jun Zhu
Status: experimental
ForSyDe includes two DSL flavors which offer different
features:
1. Deep-embedded DSL
Deep-embedded signals (ForSyDe.Signal), based on
the same concepts as Lava (→ 8.9), are aware of the
system structure. Based on that structural infor-
mation ForSyDe’s embedded compiler can perform
different analysis and transformations.
◦ Thanks to Template Haskell, computations are
expressed in Haskell, not needing to specifically
design a DSL for that purpose
◦ Embedded compiler backends:
– Simulation
– VHDL (with support for Modelsim and
Quartus II)
– GraphML (with yFiles graphical markup
support)
◦ Synchronous model of computation
◦ Support for components
◦ Support for fixed-sized vectors
2. Shallow-embedded DSL
Shallow-embedded signals
(ForSyDe.Shallow.Signal) are modeled as streams
of data isomorphic to lists. Systems built with them
are restricted to simulation. However, shallow-
embedded signals provide a rapid-prototyping
framework which allows to simulate heterogeneous
systems based on different models of computation
(MoCs).
◦ Synchronous MoC
◦ Untimed MoC
◦ Continuous Time MoC
◦ Domain Interfaces allow connecting various
subsystems with different timing (domains) re-
gardless of their MoC
ForSyDe allows to integrate deep-embedded models
into shallow-embedded ones. This makes it possible

52
to simulate a synthesizable deep-embedded model to- sized types, built using type functions. This library,
gether with its environment, which may consist of ana- developed specifically for use with Kansas Lava, in-
log, digital, and software parts. Once the functional- cludes sized 1 and 2 dimensional matrixes, and sized
ity of the deep-embedded model is validated, it can be signed and unsigned bit vectors.
synthesized to hardware using the VHDL-backend of
ForSyDe’s embedded compiler. We are writing Kansas Lava to address one problem
(generate good hardware designs for communication
Further reading circuits) and help facilitate a second (explore and un-
derstand correctness preserving optimizations of non-
http://www.ict.kth.se/forsyde/ trivial hardware components). With telemetry circuits,
the encodings and decoding mechanisms are typically
6.9.2 Kansas Lava expressed using matrix operations, so we pay careful at-
tention to allowing clear encoding of such operations.
Report by: Andy Gill
Participants: Tristan Bull, Andy Gill, Garrin Kimmell,
In particular, we use type functions to clean up sized
Erik Perrins, Ed Komp, Brett Werling types, making for a cohesive addition to our Lava. A
Status: ongoing release is planned for early November, and will be avail-
able on Hackage.
Kansas Lava is an attempt to use the Lava design pat-
tern with modern functional programing technology. In
Further reading
particular we scale up the ideas in Lava to operate on
larger circuits and with large basic components. http://www.ittc.ku.edu/csdl/Kansas_Lava
◦ Kansas Lava uses a single principal Signal type for
all types of signals. Some versions of Lava have over-
loaded signal to interpret signal in either a synthesis 6.10 Natural Language Processing
or simulation mode. Our experience is that a sin-
gle concrete type is easier to work with in practice, 6.10.1 NLP
and we have baked the two main interpretations into Report by: Eric Kow
our Signal type. Ultimately this allows a closer fit
between the specifications of behavior and synthesiz- The Haskell Natural Language Processing community
able code. aims to make Haskell a more useful and more popular
language for NLP. The community provides a mailing
◦ Like other Lava implementations before it, Kansas list, Wiki and hosting for source code repositories via
Lava supports both synthesis and simulation. The the Haskell community server.
use case would typically be development of an exe- The Haskell NLP community was founded in March
cutable model, refinement into a synthesizable vari- 2009. We are in the process of recruiting NLP re-
ant, then further refinement for efficiency, and other searchers and users from the Haskell community. In
considerations. the future, we hope to use the community to discuss
libraries and bindings that would be most useful to us
◦ Kansas Lava uses a modern FP style of Haskell. We and ways of spreading awareness about Haskell in the
allow Signal to be an applicative functor. Arith- NLP world.
metic is overloaded over Signal, so we can represent
addition using +, multiplication using *, etc. Con- Further reading
stant literals can also be Signals. This leads to a
cleaner looking specifications. http://projects.haskell.org/nlp

◦ Kansas Lava has direct support for importing exist-

ing VHDL libraries as new, well typed primitives. 6.10.2 GenI
This allows Kansas Lava to be used as a high-level Report by: Eric Kow
glue between existing solutions.
◦ Kansas Lava includes a simple type checking over GenI is a surface realizer for Tree Adjoining Grammars.
binary representations. Polymorphic specifications Surface realization can be seen a subtask of natural lan-
inside Lava will be instantiated to their specific, guage generation (producing natural language utter-
monomorphically sized implementation in VDHL, ances, eg. English texts, out of abstract inputs). GenI
depending on the propagation of actual usage. in particular takes an FB-LTAG grammar and an in-
put semantics (a conjunction of first order terms), and
◦ In Haskell, requiring a 14-bit value is unusual, but in produces the set of sentences associated to the input
hardware, we often know and want to enforce a spe- semantics by the grammar. It features a surface real-
cific width. Kansas Lava uses an implementation of ization library, several optimizations, batch generation

53
mode, and a graphical debugger written in wxHaskell. users. It is a dependently typed functional language
It was developed within the TALARIS project and is based on Per Martin-Löf’s type theory.
free software licensed under the GNU GPL.
GenI is available on Hackage, and can be installed
via cabal-install. Our most recent release of GenI was
version 0.20.1 (2009-10-01), which offers cleaner inter-
actions with the third-party tools (using JSON), sim-
pler installation on MacOS X and a user manual. For
more information, please contact us on the geni-users
mailing list.
Further reading
◦ http://projects.haskell.org/GenI
◦ Paper from Haskell Workshop 2006:
http://hal.inria.fr/inria-00088787/en
◦ http://websympa.loria.fr/wwsympa/info/geni-users
6.10.3 Grammatical Framework
Report by: Krasimir Angelov
Participants: Krasimir Angelov, Håkan Burden, Aarne
Ranta
Grammatical Framework (GF) is a programming lan- ◦ Building wide coverage Swedish grammar based on
guage for multilingual grammar applications. It can
be used as a more powerful alternative to Happy but
in fact its main usage is to describe natural language
Further reading
grammars instead of programming languages. The lan-
guage itself will look familiar for most Haskell or ML www.digitalgrammars.com/gf
An important objective in the language development
was to make it possible to develop modular gram-
mars. The language provides modular system inspired
from ML but adapted to the specific requirements in
GF. The modules system was exploited to a large ex-
tent in the Resource Libraries project. The library
provides large linguistically motivated grammars for a
number of languages. When the languages are closely
related the common parts in the grammar could be
shared using the modules system. Currently there
are complete grammars for Bulgarian, Danish, English,
Finnish, French, German, Interlingua, Italian, Norwe-
gian, Russian, Spanish, and Swedish. There are work
in progress grammars for Arabic, Catalan, Latin, Thai,
and Hindi/Urdu. On top of these grammars a user
with limited linguistic background can build applica-
tion grammars for a particular domain.
On 24 June 2009 after one year of hard work the
previous beta version of GF 3.0 is turned into stable
release. This is a major refactoring of the existing sys-
tem. The code base is about half in size and makes a
clear separation between compiler and runtime system.
A Haskell library is provided that allows GF grammars
to be easily embedded in user applications. There is a
translator that generates JavaScript code which allows
the grammar to be used in web applications as well.
The new release also provides new parser algorithm
which works faster and is incremental. The incremen-
tality allows the parser to be used for word prediction,
i.e., someone could imagine a development environment
where the programming language is natural language
and the user still can press some key to see the list of
words allowed in this position just like it is possible in
Eclipse, JBuilder, etc.
We are continuing to work hard. Some of the projects
that keeps us busy:
◦ Type checker for dependent types in the interpreter.
Currently only the compiler has type checker.
◦ Semantic parsing — i.e., parser which considers not
only the syntax but also the semantics of the lan-
guage. The semantics is encoded using dependent
types.
◦ New resource grammars for Romanian and Polish
◦ Visualisation of parse trees and dependency trees in
addition to syntax trees
◦ Experiments with natural languages and big ontolo-
gies
the resource grammar.
54
6.11 Others Current Status and Future Plans
The original version of IgorII is implemented in the
6.11.1 IgorII reflective rewriting based programming and specifica-
tion language Maude. However, a Haskell implemen-
Report by: Martin Hofmann
Participants: Emanuel Kitzelmann, Ute Schmid tation of the algorithm is the current research proto-
Status: experimental, active development type. Both can be obtained from the project page.
A tool demo and a research paper about the use of
catamorphisms as higher-order templates are presented
IgorII is a new method and an implemented prototype at PEPM 2010.
for constructing recursive functional programs from a For the future, we plan to extend the higher-order
few non-recursive, possibly non-ground, example equa- context to use the catamorphism template for arbi-
tions describing a subset of the input/output behavior trary algebraic data types. Furthermore, it is worth
of a target function to be implemented. to investigate to which extent other morphisms can be
For a simple target function like reverse the sole incorporated.
input would be the following, the k smallest w.r.t. the
input data type, examples: Further reading

reverse [] = [] ◦ http://www.cogsys.wiai.uni-bamberg.de/effalip/
reverse [a] = [a] ◦ http://www.inductive-programming.org/
reverse [a,b] = [b,a]
reverse [a,b,c] = [c,b,a] 6.11.2 Roguestar

The result, shown below, computed by IgorII is a Report by: Christopher Lane Hinson
recursive definition of reverse, where the subfunctions Status: early development
last and init have been automatically invented by the See: http://haskell.org/communities/05-2009/html/
program. report.html#sect6.12.2.
reverse [] = []
reverse (x:xs) = (last (x:xs)):(reverse (init (x:xs)) 6.11.3 LQPL — A quantum programming language
compiler and emulator
last [x] = x
last (x:y:ys) = last (y:ys) Report by: Brett G. Giles
init [x] = []
Participants: Dr. J.R.B. Cockett
init (x:y:ys) = x:(init (y:ys))
Status: v 0.8.3 experimental released
Recently, IgorII has been extended to use catamor-
phisms on lists as higher-order templates. After en- LQPL (Linear Quantum Programming Language) con-
abling the higher-order mode, given the previous ex- sists of a compiler for a functional quantum program-
amples of reverse, the system outputs the following ming language and an associated assembler and emu-
solution: lator.
This programming language was inspired by Peter
reverse xs = foldr snoc [] xs Selinger’s paper “Toward a Quantum Programming
Language”. LQPL incorporates a simplified module /
snoc x xs = foldr cons [x] xs
include system (more like C’s include than Haskell’s im-
cons x (y:ys) = x:(y:ys)
port), predefined unitary transforms, quantum control
and classical control, algebraic data types, and opera-
Features tions on purely classical data. The compiler translates
LQPL programs into an assembler language targeted to
◦ termination by construction
a quantum stack machine. The emulator, written using
◦ handling arbitrary user-defined data types
Gtk2Hs, translates the assembler to machine code and
◦ utilization of arbitrary background knowledge
provides visualization of the program as it executes.
◦ automatic invention of auxiliary functions as subpro-
For example, the following procedure implements
grams
quantum teleportation:
◦ learning complex calling relationships (tree- and
nested recursion) teleport::(n:Qubit,a:Qubit,b:Qubit;b:Qubit) {
◦ allowing for variables in the example equations Not a <= n ; Had n;
◦ simultaneous induction of mutually recursive target measure a of
functions |0> => {} |1> => {Not b};
◦ using list-catamorphisms as higher-order templates measure n of

55
 |0> => {} |1> => {RhoZ b}
} these values to get the value of an item. This extends
The emulator allows one to step through a program
at the assembly level, displaying the quantum values as
a tree. The figure below is a screen shot showing the
results after the first measure in teleport.
Recent changes include a public release (available at
the URL below), UI improvements and the ability load
and compile LQPL source programs from the emulator.
Further reading
http://pll.cpsc.ucalgary.ca/lqpl/index.html
6.11.4 Yogurt
Report by: Martijn van Steenbergen
Yogurt is a MUD client embedded in Haskell. The
API allows users to define variables of arbitrary types
and hooks that trigger on output from the MUD or
input from the user. Other features include timers,
multithreading, and logging. Most MUD clients rely
on their own custom language; Yogurt, however, re-
lies on Haskell. Even though Yogurt programs are full
Haskell programs, Yogurt is able to dynamically load Further reading
and reload them using the GHC API, effectively mak-
ing Yogurt a scripting language.
Ideas for the future include compatibility with
Tintin++ scripts to make migration to Yogurt even
more tempting and an expect-like interface for easier
interaction with processes.
Further reading
http://code.google.com/p/yogurt-mud/
6.11.5 Dyna 2
Report by: Wren Ng Thornton
Participants: Nathaniel W. Filardo, Jason Eisner
Status: active research
Dyna is a valued-logic programming language with
first-class support for dynamic programming. A ma-
jor goal of the language is to automate many of the
common algorithms and optimizations used in natu-
ral language parsers and machine translation decoders, ◦ In association with Dyna there is work on a graphical
making them available for general logic programs.
Starting from Prolog we extend Horn clauses to
“Horn equations” by associating each grounding of a
rule with a value (not just provability) and aggregating
logic programming with some elements of functional
programming, including weighted-logic systems where
the form of Horn equations is restricted to a semiring.
My master thesis work was developing a powerful
type system which expresses algebraic data types with
non-linearity constraints, refinement subtyping, and
some aspects of dependent typing. This type system
is further enhanced to allow heterogeneous storage of
the same semantic type, so that different representa-
tions of “the same value” can be used simultaneously
in different parts of a program.
Unlike most logic languages, Dyna will have a mod-
ule system for separating proof universes, which allows
multiple programs to share the same RTS instance and
allows presenting programs, data sets, and deductive
databases with the same API. Dyna will also support
agenda-based mixed forward-/backward-chaining infer-
ence with memoization and declarative truth mainte-
nance.
Previous work implemented a prototype compiler
that generated C++ classes for a restricted form of
the language. Currently we are implementing an in-
terpreter in Haskell that covers a broader portion of
the language, and are working on the formal under-
pinnings of these extensions. We intend to use this in
the long term as a reference implementation for test-
ing improved algorithms for a next generation Dyna
compiler.
◦ Work on the type system and unification algorithms
for Dyna 2 can be found in the following papers.
These are currently not available online, though re-
fined versions should be available soon.
– W. Thornton (2008). “Typed Unification in
Dyna: An Exploration of the Design Space.”
Masters Project Report, Johns Hopkins Univer-
sity.
– W. Thornton (2008). “Heterogeneous Strate-
gies for Unification: Variable–Value Ordering
and Optimized Structures.” Masters Paper,
Johns Hopkins University.
◦ This paper discusses program transformations for
Dyna and gives an early view of the semantics
for mixed inference: http://www.cs.jhu.edu/~jason/
papers/#fg06.
◦ This paper introduces Dyna 1 where Horn equa-
tions are restricted to a semiring: http://cs.jhu.edu/
~jason/papers/#emnlp05-dyna.
debugger, called Dynasty, which allows lazy explo-
ration of hypergraphs (representing proof forests).
– http://cs.jhu.edu/~jason/papers/#infovis06
56
6.11.6 Vintage BASIC shapes and step the simulation. More advanced Bullet
features (constraints, soft body simulation etc.) will be
Report by: Lyle Kopnicky added later.
Current release: 1.0.1
Portability: GHC 6.10
Further reading
Vintage BASIC is an interpreter for microcomputer-
era BASIC, written in Haskell. It is fully unit-tested, http://www.haskell.org/haskellwiki/Bullet
and implements all common features of the language.
The web site includes games from Creative Comput- 6.11.8 arbtt
ing’s BASIC Computer Games, all of which can be run
under the interpreter. Report by: Joachim Breitner
Status: working
The program arbtt, the automatic rule-based time
tracker, allows you to investigate how you spend your
time, without having to manually specify what you are
doing. arbtt records what windows are open and active,
and provides you with a powerful rule-based language
to afterwards categorize your work. And it comes with
documentation!
The program is very new and has found only a few
users yet. The author is still looking for feedback, es-
pecially to rate its usefulness to decide whether it will
be uploaded to Debian.

Further reading
◦ http://www.joachim-breitner.de/projects#arbtt
http://www.joachim-breitner.de/blog/archives/
336-The-Automatic-Rule-Based-Time-Tracker.html
The interpreter makes use of a novel technique for ◦ http://darcs.nomeata.de/arbtt/doc/users_guide/
implementing BASIC’s dynamic control structures: re-
sumable exceptions. For example, in BASIC loops, the
FOR keyword becomes an exception handler, and the 6.11.9 uacpid
NEXT keyword throws an exception. Furthermore, Report by: Dino Morelli
the exceptions are caught in the continuation, rather Status: experimental, actively developed
than the containing expression. The handlers can also
be selectively persisted after handling exceptions. Be- uacpid is a daemon designed to be run in userspace
cause of these two features, I refer to them as “durable that will monitor the local system’s acpid socket for
traps”. The DurableTraps library is fully abstracted hardware events. These events can then be acted upon
using monad transformers, and can be used in any pro- by handlers with access to the user’s environment.
gram. uacpid is available in binary form for Arch Linux
through the AUR and can be acquired using darcs or
other methods.
Further reading
http://www.vintage-basic.net Further reading
◦ Project page: http://ui3.info/d/proj/uacpid.html
6.11.7 Bullet
◦ Source repository: darcs get http://ui3.info/darcs/
Report by: Csaba Hruska uacpid
Status: experimental, active development
Bullet is a professional open source multi-threaded 3D
Collision Detection and Rigid Body Dynamics Library
written in C++. It is free for commercial use under
the zlib license. The Haskell bindings ship their own C
compatibility layer, so the library can be used without
modifications.
At the current state of the project only basic services
are accessible from Haskell, i.e., you can load collision

57
7 Commercial Users
7.1 Well-Typed LLP
Report by: Ian Lynagh
Participants: Duncan Coutts
Well-Typed is a Haskell services company. We pro-
vide commercial support for Haskell as a develop-
ment platform. We also offer consulting services, con-
tracting, and training. For more information, please
take a look at our website or drop us an e-mail at
hinfo@well-typed.comi.
This has been a busy 6 months for us. As well as
proprietary work, we have been pleased to have again
been able to work on the GHC 6.12 release, as well as
other core parts of the community infrastructure, such
as Cabal and the Haskell Platform.
We have also been involved with the setting up and
running of the Industrial Haskell Group (→ 7.8). We
are pleased with the work the IHG have done in its first
6 months, and have high hopes for the future.
Overall, it has been a good 6 months for us, and we
are looking forward to the challenges of the next 6. We
have some exciting stuff coming up, and will be looking
into expansion.
Further reading
◦ http://www.well-typed.com/
◦ Blog: http://blog.well-typed.com/
7.2 Credit Suisse Global Modeling and
Analytics Group
Report by: Ganesh Sittampalam
GMAG, the quantitative modeling group at Credit Su-
isse, has been using Haskell for various projects since ◦ ICFP 2008 experience report about Paradise:
the beginning of 2006, with the twin aims of improving
the productivity of modelers and making it easier for
other people within the bank to use GMAG models.
Many of GMAG’s models use Excel combined with
C++ addin code to carry out complex numerical com-
putations and to manipulate data structures. This
combination allows modelers to combine the flexibility
of Excel with the performance of compiled code, but
there are significant drawbacks: Excel does not sup-
port higher-order functions and has a rather limited
and idiosyncratic type system. It is also extremely dif-
ficult to make reusable components out of spreadsheets Bluespec, Inc. provides a language, BSV, which is be-
or subject them to meaningful version control.
Because Excel is (in the main) a side-effect free en- sign — specification, synthesis, modeling, and verifica-
vironment, functional programming is in many ways a tion. All hardware behavior is expressed using rewrite
58
natural fit, and we have been using Haskell in various
ways to replace or augment the spreadsheet environ-
ment.
Our past projects include:
◦ Adding higher-order functions to Excel, implemented
via (Haskell) addin code.
◦ Tools to transform spreadsheets into directly exe-
cutable code.
◦ A “lint” tool to check for common errors in spread-
sheets.
Our main project for the last couple of years has
been Paradise, a domain-specific language embedded
in Haskell for implementing reusable components that
can be compiled into multiple target forms. Current
backends are Excel spreadsheets and .NET components
based on either Winforms or WPF.
A number of modelers have been exposed directly
to Haskell by using Paradise, and they have generally
picked it up fairly quickly. All new recruits are intro-
duced to Haskell as part of our internal training pro-
gram.
Our main focus at the moment is the automatic
generation of Paradise models for a particular finan-
cial product, starting from an algebraic datatype that
defines the product. Modelers can override parts of
the automatically generated model with a hand-crafted
Paradise component if they choose to, providing a good
trade-off between speed of development and “beautiful”
results.
Further reading
◦ CUFP 2006 talk about Credit Suisse:
http://cufp.galois.com/slides/2006/HowardMansell.
pdf
http://www.earth.li/~ganesh/research/
paradise-icfp08/paper.pdf
http://www.earth.li/~ganesh/research/
paradise-icfp08/talk.pdf
7.3 Bluespec tools for design of complex
chips
Report by: Rishiyur Nikhil
Status: commercial product
ing used for all aspects of ASIC and FPGA system de-
rules (Guarded Atomic Actions). BSV borrows many
ideas from Haskell — algebraic types, polymorphism,
type classes (overloading), and higher-order functions.
Strong static checking extends into correct expression
of multiple clock domains, and to gated clocks for power
management. BSV is universal, accommodating the di-
verse range of blocks found in SoCs, from algorithmic
“datapath” blocks to complex control blocks such as
processors, DMAs, interconnects and caches.
Bluespec’s core tool synthesizes (compiles) BSV into
high-quality RTL (Verilog), which can be further syn-
thesized into netlists for ASICs and FPGAs using other
commercial tools. Automatic synthesis from atomic
transactions enables design-by-refinement, where an
initial executable approximate design is systematically
transformed into a quality implementation by succes-
sively adding functionality and architectural detail.
Other products include fast BSV simulation and devel-
opment tools. Bluespec also uses Haskell to implement
its tools (well over 100K lines of Haskell).
This industrial strength tool has enabled some large
designs (over a million gates) and significant architec-
ture research projects in academia and industry. This
kind of research was previously feasible only in soft-
ware simulation. BSV permits the same convenience
of expression as SW languages, and its synthesizability
further allows execution on FPGA platforms at three
orders of magnitude greater speeds, making it possible
now to study realistic scenarios.
Status and availability
BSV tools, available since 2004, are in use by several
major semiconductor companies and universities. The
tools are free for academic teaching and research.
Recent news (last 6 months): (1) Much new infras-
tructure and libraries to move computation kernels eas-
ily onto commodity FPGA boards, for greater speed
and/or lower energy; (2) a strange loop, where one cus-
tomer is applying the capability 1 to a computation ker-
nel written in Haskell; and (3) development of PAClib
(Pipeline Architecture Combinators) that make exten-
sive use of higher-order functions to describe DSP algo-
rithms succinctly and with powerful architectural pa-
rameterization, exceeding the capabilities of tools that
synthesize hardware from C codes.
Further reading
◦ R.S.Nikhil, Bluespec, a General-Purpose Approach
to High-Level Synthesis Based on Parallel Atomic
Transactions, in High Level Synthesis: from Algo-
rithm to Digital Circuit, Philippe Coussy and Adam
Morawiec (editors), Springer, 2008, pp. 129-146.
◦ Small illustrative examples: http://www.bluespec.
com/wiki/SmallExamples
◦ Winning entry in MEMOCODE 2008 design contest:
http://rijndael.ece.vt.edu/memocontest08/
59
◦ MIT courseware, “Complex Digital Systems”: http:
//csg.csail.mit.edu/6.375
◦ A fun example with many functional-programming
features — BluDACu, a parameterized Bluespec
hardware implementation of Sudoku: http://www.
bluespec.com/products/BluDACu.htm
7.4 Galois, Inc.
Report by: Andy Adams-Moran
Galois is an employee-owned software development
company based in Beaverton, Oregon, U.S.A. Ga-
lois started in late 1999 with the stated purpose of
using functional languages to solve industrial prob-
lems. These days, we emphasize the needs of our
clients and their problem domains over the tech-
niques, and the slogan of the Commercial Users of
Functional Programming Workshop (see http://cufp.
functionalprogramming.com/) exemplifies our approach:
Functional programming as a means, not an end.
Galois develops software under contract, and every
project (bar three) that we have ever done has used
Haskell. The exceptions used ACL2, Poly-ML, SML-
NJ, and OCaml, respectively, so functional program-
ming languages and formal methods are clearly our “se-
cret sauce”. We deliver applications and tools to clients
in industry and the U.S. government. Some diverse ex-
amples: Cryptol, a domain-specific language for cryp-
tography (with an interpreter and a compiler, with mul-
tiple targets, including FPGAs); a GUI debugger for a
specialized microprocessor; a specialized, high assur-
ance, cross-domain web and file server, and Wiki for
use in secure environments, and numerous smaller re-
search projects that focus on taking cutting-edge ideas
from the programming language and formal methods
community and applying them to real world problems.
Web-based technologies are increasingly important
to our clients, and we believe Haskell has a key role
to play in the production of reliable, secure web soft-
ware. The culture of correctness Haskell encourages
is ideally suited to web programming, where issues of
security, authentication, privacy, and protection of re-
sources abound. In particular, Haskell’s type system
makes possible strong static guarantees about access
to resources, critical to building reliable web applica-
tions.
To help push further the adoption of Haskell in the
domain of web programming, Galois released a suite of
Haskell libraries, including:
◦ json: Support for JavaScript Object Notation
◦ xml: A simple, lightweight XML parser/generator.
◦ utf8-string: A UTF8 layer for IO and Strings.
◦ selenium: Communicate with a Selenium Remote
Control server.
◦ curl: libcurl is a rich client-side URL transfer library.
◦ sqlite: Haskell binding to sqlite3 databases.
◦ feed: Interfacing with RSS and Atom feeds
◦ mime: Haskell support for working with MIME
types.
Continuing our deep involvement in the Haskell com-
munity, Galois was happy to sponsor the two Haskell
hackathons held in the past year, Hac 07 II, in Freiburg,
Germany, and Hac4 in Gothenburg, Sweden. Galois
also sponsored the second BarCamp Portland, held in
early May 2008.
Further reading
http://www.galois.com/.
7.5 IVU Traffic Technologies AG Rostering
Group
Report by: Michael Marte
Status: released
The rostering group at IVU Traffic Technologies AG
has been using Haskell to check rosters for compliance
with the “EC Regulation No 561/2006 on the harmo-
nization of certain social legislation relating to road
transport” which “lays down rules on driving times,
breaks and rest periods for drivers engaged in the car-
riage of goods and passengers by road”. Due to com-
binatorial rest-time compensation rules, EC 561/2006
instances are search problems and at times pretty hard
to solve.
Our implementation is based on an embedded DSL
to combine the regulation’s single rules into a solver
that not only decides on instances but, in the case of a
faulty roster, finds an interpretation of the roster that
is “favorable” in the sense that the error messages it
entails are “helpful” in leading the dispatcher to the
resolution of the issue at hand.
Our EC 561/2006 solver comprises about 1700 lines
of Haskell code (including about 250 lines for the C
API), is compiled to a DLL with ghc, and linked dy-
namically into C++ and Java applications. The solver
is both reliable (due to strong static typing and referen-
tial transparency — we have not experienced a failure
in three years) and efficient (due to constraint propa-
gation, a custom search strategy, and lazy evaluation).
Our EC 561/2006 component is part of the IVU.crew
software suite and as such is in wide-spread use all over
Europe, both in planning and dispatch. So the next
time you enter a regional bus, chances are that the
driver’s roster was checked by Haskell.
Further reading
◦ EC 561/2006 at EurLex
◦ The IVU.suite for public transport
60
7.6 Tupil
Report by: Chris Eidhof
Participants: Eelco Lempsink
Tupil builds reliable web software with Haskell. Us-
ing Haskell’s powerful ways of abstraction, we feel we
can develop even faster than with dynamic scripting
languages but with the safety and performance of a
language that is statically checked and compiled.
In the last year we were able to successfully use
Haskell for different projects: high score web services,
music mashups, a payment system for a client and
more. It would not have been possible without the
vast amount of packages that are available for Haskell
these days.
Further reading
◦ http://tupil.com
◦ http://blog.tupil.com
7.7 Aflexi Content Delivery Network
(CDN)
Report by: Kim-Ee Yeoh
The Aflexi Content Delivery Network (CDN) is a con-
federated solution to cost-effective content delivery for
publishers, value-added capacity right-sizing for web-
hosting providers, and a more responsive Internet ex-
perience for end-users.
Key elements of the Aflexi CDN comprise a server-
side software package that webhosting providers can
license to CDN-enable their servers and hosted web-
sites, and a marketplace where a provider can federate
with other providers to expand its CDN footprint. Our
motto is “Unifying Capacity.”
At the heart of the platform is the ability for publish-
ers to transparently combine Aflexi-enabled providers
and migrate among a publisher-selected subset. Com-
petition between providers ensures that publishers get
a market-efficient rate for delivery bandwidth by mak-
ing informed decisions based on platform metrics of
providers’ Quality of Service. By trading excess capac-
ity with other providers, they in turn benefit from the
disruptive innovation in capacity recalibration and ad-
ditional revenue streams afforded by the Aflexi CDN
platform.
Aflexi uses Haskell for critical components of its
back-end infrastructure. Haskell allows us to rapidly
prototype our software efforts via its rich store of
open-source libraries on Hackage. Supported by a set
of composable concurrency abstractions built on fast
lightweight threads, our Haskell code sports more re-
7.9 typLAB
silient fail-safe features and higher performance while
at the same time employing fewer lines of code that
Report by: Sebastiaan Visser
ultimately translate to fewer bugs. Participants: Lon Boonen, Erik Hesselink, Salar al
Other Haskell projects in development include a Khafaji
domain-specific language (DSL) with termination guar-
antees (à la Total Functional Programming). The DSL
furnishes a framework for describing the policies gov-
erning content redirection.

Status and availability TypLAB is a startup company located in the city center
of Amsterdam. We investigate and develop new ways of
The Aflexi CDN platform pre-launched at the start of creating and consuming online content. Our current fo-
2009. cus is in building an online environment in which users
can manage content in unconventional ways.
The Happstack powered server application, the au-
tomated deployment scripts, the JavaScript preproces-
Further reading sors; all code running at the server is written entirely
in Haskell. The vast amount of Haskell packages, espe-
http://aflexi.net/ cially for XML manipulation and generic programming,
allow us to easily interface with our Berkeley XML
database back-end. A large part of our application is
7.8 Industrial Haskell Group
written in JavaScript and runs in the client. Most of the
Report by: Ian Lynagh
JavaScript code is heavily inspired by functional (reac-
tive) programming and enables us to achieve a very
high level of abstraction, even in the web browser.
TypLAB is showing that combining the theoretical
The Industrial Haskell Group (IHG) is an organization foundations of computer science with the day-to-day
to support the needs of commercial users of Haskell. practice of the web allows for building high-quality
It was formed in early 2009, and has already made a web-applications. Still a lot of work has to be done
significant contribution to the up-coming GHC 6.12 re- before our first beta will see the light. Please keep in
lease: In the first 6 months collaborative development touch with our progress by checking out our weblog.
scheme, the IHG has funded work on dynamic libraries,
more flexible Integer library support for GHC, and Ca- Further reading
bal development work. The details of these projects are
on the website. ◦ http://typlab.com
◦ http://blog.typlab.com
Following the success of this scheme, we will be run-
ning another 6 month scheme, with the work beginning
in January. Interested companies should check out the
website for details.
We have also added “associate membership” and
“academic membership” options, for companies and
academic groups that wish to support Haskell devel-
opment without the larger commitment necessary for
the collaborative development scheme. Again, details
are on the website.
If you are interested in joining the IHG, or if you
just have any comments, please drop us an e-mail at
hinfo@industry.haskell.orgi.

Further reading

http://industry.haskell.org/

61
8 Research and User Groups

8.1 Functional Programming Lab at the
University of Nottingham
Report by: Liyang HU
The School of Computer Science at the University of
Nottingham has recently formed the Functional Pro-
gramming Laboratory, a new research group focused on
all theoretical and practical aspects of functional pro-
gramming, together with related topics such as type
theory, category theory, and quantum programming.
The laboratory is led jointly by Thorsten Altenkirch
and Graham Hutton, with Henrik Nilsson and Venanzio
Capretta as academic staff. With 4 more research staff
and some 10 PhD students in our group, we have a
wide spectrum of interests:
Containers
A theme that permeates our work is implementation
through embedding in typed functional languages such
as Haskell or Agda (→ 3.2.2). The team also main-
tains Yampa, the latest Haskell-based implementation
of FRP.
Quantum Programming
Thorsten Altenkirch and Alexander S Green have been
working on the Quantum IO Monad (QIO), an inter-
face from Haskell to Quantum Programming. Tak-
ing advantage of abstractions available in Haskell we
can provide QIO implementations of many well-known
quantum algorithms, including Shor’s factorization al-
gorithm. The implementation also provides a construc-
tive semantics of quantum programming in the form of
a simulator for such QIO computations.

Nottingham has been home to the EPSRC grant on

containers, a semantic model of functional data struc- Reasoning About Effects
tures. Thorsten Altenkirch, Peter Hancock, Peter Mor-
ris, and Rawle Prince are working with containers to Graham Hutton and Andy Gill recently formalized
both write and reason about programs. Peter Morris the worker/wrapper transformation for improving the
has recently finished his PhD, which used containers as performance of functional programs. Wouter Swier-
a basis for generic programming with dependent types. stra and Thorsten Altenkirch have produced func-
tional specifications of the IO monad, as described in
Wouter’s forthcoming PhD thesis. Mauro Jaskelioff de-
Dependently Typed Programming (DTP) veloped a new monad transformer library for Haskell,
Peter Morris and Nicolas Oury are working on Epi- which provides a uniform approach to lifting opera-
gram, while Nils Anders Danielsson is involved in the tions. Diana Fulger and Graham Hutton are inves-
development of Agda (→ 3.2.2). Our interests lie both tigating equational reasoning about various forms of
in the pragmatics of using DTP, as witnessed by work effectful programs. Liyang HU and Graham Hutton
on libraries and tools, and in foundational theory, are working on verifying the correctness of compilers
including the Observational Type Theory underlying for concurrent functional languages, including a model
Epigram 2 and James Chapman’s work on normaliza- implementation of software transactional memory.
tion. DTP is also used to control and reason about
effects, and a number of us are using Agda as a proof
Teaching
assistant to verify programs or programming language
theory. Haskell plays an important role in the undergradu-
ate program at Nottingham, as well as our China
Functional Reactive Programming (FRP) and Malaysia campuses. Modules on offer include
Functional Programming, Advanced FP, Mathematics
The FRP team are working on FRP-like and FRP-
for CS, Foundations of Programming, Compilers, and
inspired declarative, domain-specific languages. Under
Computer-Aided Formal Verification, among others.
Henrik Nilsson’s supervision, Neil Sculthorpe is work-
ing on a new, scalable FRP language based on reactive
components with multiple inputs and outputs, while Events
George Giorgidze is applying the advantages of FRP
to non-causal modeling with the aim of designing a The FP Lab plays a leading role in the Midlands Grad-
new, more expressive and flexible language for non- uate School in the Foundations of Computing Science,
causal, hybrid modeling and simulation (→ 6.5.1). Tom the British Colloquium for Theoretical Computer Sci-
Nielsen is implementing a declarative language for ex- ence, and the Fun in the Afternoon seminar series on
periments, simulations, and analysis in neuroscience. functional programming.

62
FP Lunch
Every Friday, we gather for lunch with helpings of in-
formal, impromptu-style whiteboard discussions on re-
cent developments, problems, or projects. Summaries
of our weekly meetings can be found on the frequently
cited FP Lunch blog, giving a lively picture of ongoing
research at Nottingham.
Later in the afternoon, there is usually a formal hour-
long seminar. We are always keen on speakers in any
related areas: do get in touch with Thorsten Altenkirch
htxa@cs.nott.ac.uki if you would like to visit. See you
there!
8.2 Artificial Intelligence and Software
Technology at Goethe-University
Frankfurt
Report by: David Sabel
Participants: Manfred Schmidt-Schauß
8.3 Functional Programming at the
Deterministic calculi. We proved correctness of
University of Kent
strictness analysis using abstract reduction. Our proof
is based on the operational semantics of an extended
call-by-need lambda calculus which models a core lan-
guage of Haskell. Furthermore, we proved equivalence
of the call-by-name and call-by-need semantics of an
extended lambda calculus with letrec, case, and con-
structors. Recently, we extended the investigation of
call-by-need letrec calculi to polymorphic typing and
showed correctness of type dependent program trans-
formations.
Nondeterministic calculi. We explored several
nondeterministic extensions of call-by-need lambda cal-
culi and their applications where an emphasis of our
research lies in proving program equivalences w.r.t.
contextual equivalence. In particular, we analyzed
a model for a lazy functional language with direct-
call I/O providing a semantics for unsafePerformIO
in Haskell. We investigated a call-by-need lambda-
calculus extended by parallel-or and its applications as
a hardware description language. We analyzed a call-
by-need lambda calculus extended with McCarthy’s
amb and an abstract machine for lazy evaluation of con-
current computations.
Simulation-based proof techniques. We have
shown that mutual similarity is a sound proof method
w.r.t. contexutal equivalence in a class of untyped
higher-order non-deterministic call-by-need lambda
calculi. For call-by-need calculi with letrec we ob-
tained two results: Most recently, we have shown that
applicative bisimulation is correct in deterministic call-
by-need lambda calculi with recursive let. For non-
deterministic call-by-need calculi with letrec usual
definitions of mutual similarity are unsound. In collab-
oration with Elena Machkasova we obtained correct-
ness of a variation of finite simulation for proving con-
63
textual equivalence in an extended non-deterministic
call-by-need lambda-calculus with letrec.
Concurrency primitives. We analyzed the ex-
pressivity of concurrency primitives in various func-
tional languages. In collaboration with Jan Schwing-
hammer and Joachim Niehren, we showed how to en-
code Haskell’s MVars into a lambda calculus with stor-
age and futures which is an idealized core language of
Alice ML. We proved correctness of the encoding using
operational semantics and the notions of adequacy and
full-abstractness of translations. In her final year thesis
Martina Willig analyzed the encoding of other concur-
rency abstractions and implemented them in Concur-
rent Haskell.
Further reading
http://www.ki.informatik.uni-frankfurt.de/research/
HCAR.html
Report by: Olaf Chitil
The Functional Programming group at Kent is a sub-
group of the newly formed Programming Languages
and Systems Group of the School of Computing. We
are a group of staff and students with shared interests
in functional programming. While our work is not lim-
ited to Haskell — in particular our interest in Erlang
has been growing — Haskell provides a major focus and
common language for teaching and research.
Our members pursue a variety of Haskell-related
projects, some of which are reported in other sections of
this report. Recently Olaf Chitil and Doaitse Swierstra
published a paper on simple and efficient implementa-
tions of pretty printing combinators. The development
of Heat (→ 4.3.2), a deliberately simple IDE for teach-
ing Haskell, made further progress over the summer.
Neil Brown and Adam Sampson are developing an oc-
cam compiler in Haskell (Tock). They recently devel-
oped Alloy, a library for fast traversals and manipula-
tions of tree-structured data.
Further reading
◦ FP group: http://www.cs.kent.ac.uk/research/
groups/tcs/fp/
◦ Refactoring Functional Programs: http://www.cs.
kent.ac.uk/projects/refactor-fp/
◦ Pretty Printing Combinators: S. Doaitse Swier-
stra and Olaf Chitil. Linear, bounded, functional
pretty-printing. Journal of Functional Programming,
19(01):1-16, January 2009.
◦ Tracing and debugging with Hat: http://www.
haskell.org/hat
◦ Heat: http://www.cs.kent.ac.uk/projects/heat/ We are a two-man unit of functional programming re-
◦ Tock: http://projects.cs.kent.ac.uk/projects/tock/ search within the Declarative Languages and Artificial
◦ Alloy: Brown, N. C. and Sampson, A. T. 2009. Al- Intelligence group at the Katholieke Universiteit Leu-
loy: fast generic transformations for Haskell. In Pro-ven, Belgium.
ceedings of the 2nd ACM SIGPLAN Symposium on Our main project centers around the Monadic Con-
Haskell, Haskell ’09 pages 105–116. straint Programming (MCP) framework. An initial ar-
ticle on the MCP framework by Tom Schrijvers, Pe-
8.4 Foundations and Methods Group at ter Stuckey and Phil Wadler is available. It explains
how the framework captures the generic aspects of Con-
Trinity College Dublin straint Programming in Haskell. Of particular interest
is the solver-independent framework for compositional
Report by: Andrew Butterfield search strategies.
Participants: Glenn Strong, Hugh Gibbons, Edsko de
Vries Currently we are extending the framework to act
as a finite domain modeling language for both the
The Foundations and Methods Group focuses on formal problem description and the search component. The
methods, category theory, and functional programming model in Haskell serves as a high-level front-end for a
as the obvious implementation method. A sub-group state-of-the-art Constraint Programming system such
focuses on the use, semantics, and development of func- as Gecode (C++). Models can be compiled to C++
tional languages, covering such areas as: code, can be solved by calling Gecode from Haskell at
runtime, or can be solved purely in Haskell itself.
◦ Supporting OO-Design technique for functional pro-
grammers Our other Haskell-related projects are:

◦ Using functional programs as invariants in impera- ◦ EffectiveAdvice: EffectiveAdvice is a disciplined

tive programming model of (AOP-style) advice, inspired by Aldrich’s
Open Modules, that has full support for effects in
◦ Developing a GUI-based 2nd-order equational theo- both base components and advice. EffectiveAdvice
rem prover (http://haskell.org/communities/05-2009/ is implemented as a Haskell library. Advice is mod-
html/report.html#sect6.7.3) eled by mixin inheritance and effects are modeled
by monads. Interference patterns previously identi-
◦ New approaches to uniqueness typing, applicable to
fied in the literature are expressed as combinators.
Hindley-Milner style type-inferencing
Equivalence of advice, as well as base components,
◦ Equational reasoning for Concurrent Haskell (new) can be checked by equational reasoning. Parametric-
ity, together with the combinators, is used to prove
We have also managed to introduce a new elective two harmless advice theorems. The result is an ef-
course in functional programming at TCD which will fective model of advice that supports effects in both
be based on the “Real World Haskell” textbook. advice and base components, and allows these effects
to be separated with strong non-interference guaran-
tees, or merged as needed. This is joint work with
Further reading
Bruno Oliveira and William Cook.
https://www.cs.tcd.ie/research_groups/fmg/
◦ Type Checking: Recent results are on type inference
8.5 Formal Methods at DFKI Bremen and for GADTs, type invariants, and type checking for
type families. Ongoing work concerns the simplifica-
University of Bremen
tion of type checking for Haskell extensive type sys-
tem, and adding new extensions. This is joint work
Report by: Christian Maeder
with Martin Sulzmann, Simon Peyton Jones, Manuel
Participants: Mihai Codescu, Dominik Lücke, Christoph
Lüth, Christian Maeder, Till Mossakowski,
Chakravarty, Dimitrios Vytiniotis, Stefan Monnier,
Lutz Schröder Louis-Julien Guillemette and Dominic Orchard.

See: http://haskell.org/communities/05-2009/html/
report.html#sect8.5. Further reading

◦ http://hackage.haskell.org/cgi-bin/hackage-scripts/
8.6 Haskell at K.U.Leuven, Belgium package/monadiccp
◦ http://www.cs.kuleuven.be/~toms/Haskell/
Report by: Tom Schrijvers
◦ https://www.cs.kuleuven.be/~pieterw/site/Research/
Participants: Pieter Wuille
Papers/

64
8.7 Haskell in Romania
Report by: Dan Popa
This is to report some activities of the Ro/Haskell
group. The Ro/Haskell page becomes more and more
known. We hope to pass the barrier of the 20000th
click on the main page this mounth. The numbers of
students and teachers interested in Haskell is increas-
ing. Students begin to have projects using Haskell in
order to pass the License Exams. But it is just a begin-
ning. Interests in Data Base Programing with Haskell
are growing. (A surprise!).
A book previously published by Mihai Gontineac was
released as a free resource. A new book, “The Prac-
tice Of Monadic Interpretation” by Dan Popa has been
published in November 2008.
The book has a nice foreword written by Simon P.J. and
is sharing the experience of a year of interpreter build-
ing (2006). It is intended as a student’s and teacher’s
guide to the practical approach of monadic interpre-
tation. The book will probably be used during this
academic year in 2–4 universities across Romania (in
Iasi, Bacau, Cluj-Napoca).
Haskell products like Rodin (a small DSL a bit like
C but written in Romanian) begin to spread, proving
the power of the Haskell language. The Pseudocode
Language Rodin is used as a tool for teaching basics
of computer science in some high-schools from various
cities. Some teachers from a high school have requested
training concerning Rodin. Rodin was asked to become
a FOSS (Free & Open Source Software).
A group of researchers from the field of linguis-
tics located at the State Univ. from Bacau (The LO-
GOS Group) is declaring the intention of bridging the
gap between semiotics, high level linguistics, struc-
turalism, nonverbal communication, dance semiotics
(and some other intercultural subjects) AND Compu-
tational Linguistics (meaning Pragmatics, Semantics,
Syntax, Lexicology, etc.) using Haskell as a tool for
real projects. Probably the situation from Romania
is not well known: Romania is probably one of those
65
countries where computational linguistics is studied by
computer scientists less than linguists.
At Bacau State University, we have teaching Haskell
on both Faculties: Sciences (The Computers Science
being included) and we hope we will work with Haskell
with the TI students from the Fac. Of Engineering,
where a course on Formal Languages was requested.
“An Introduction to Haskell by Examples” had traveled
to The Transilvania Univ. (Brasov) and we are expect-
ing Haskell to be used there, too, during this academic
year. Other libraries had received manuals and even
donations (in books, of course). Editors seem to be
interested by the Ro/Haskell movement, and some of
them have already declared the intention of helping us
by investing capital in the Haskell books production.
A well known Publishing House (MatrixRom) asked us
to be the Official Publishing House of the Ro/haskell
Group.
Dan Popa is reporting a new technology in order to
build the Modular Abstract Syntax Tree of a language
processor without Maybe, without Catamorphisms and
without Haskell extensions. A paper is available.
There are some unsolved problems, too: PhD. Ad-
visors (specialized in monads, languages engineering,
and Haskell) are almost impossible to find. This fact
seems to block somehow the hiring of good specialists
in Haskell. There was even a funny case when some-
body hired to teach Haskell was tested and interviewed
by a LISP teacher. Of course, the exam was more or
less about lists.
Further reading
◦ Ro/Haskell: http://www.haskell.org/haskellwiki/Ro/
Haskell
◦ Rodin: http://www.haskell.org/haskellwiki/Rodin
8.8 fp-syd: Functional Programming in
Sydney, Australia.
Report by: Ben Lippmeier
Participants: Erik de Castro Lopo
We are a seminar and social group for people in Syd-
ney, Australia interested in Functional Programming
and related fields. We meet on the third Thursday of
each month and regularly get 25–30 attendees, with a
70/30 industry/research split. Talks this year have in-
cluded “Intro to PLT Scheme”, “A Haskell library for
chart plotting”, and “Program extraction in a theorem
prover like Coq (or Isabelle)”. We usually have about
90 mins of talks, starting at 6:30pm, then go for drinks
afterwards. All welcome.
Further reading
http://groups.google.com/group/fp-syd
8.9 Functional Programming at Chalmers and maintenance happens at Chalmers. For ex-
ample, enhancing Yi was the goal of two master’s
Report by: Jean-Philippe Bernardy theses, and motivated research about incremental
parsing: http://publications.lib.chalmers.se/cpl/record/
Functional Programming is an important component of
index.xsql?pubid=94979.
the Department of Computer Science and Engineering
at Chalmers. In particular, Haskell has a very impor-
tant place, as it is used as the vehicle for teaching and Language-based security SecLib is a light-weight li-
numerous projects. Besides functional programming, brary to provide security policies for Haskell programs.
language technology, and in particular domain specific The library provides means to preserve confidentiality
languages is a common aspect in our projects. of data (i.e., secret information is not leaked) as well
The Functional Programming research group has 5 as the ability to express intended releases of informa-
faculty members and 9 postdoc and doctoral students. tion known as declassification. Besides confidentiality
Research is going on in various exciting topics: policies, the library also supports another important
aspect of security: integrity of data. SecLib provides
an attractive, intuitive, and simple setting to explore
Property-based testing QuickCheck is the basis for the security policies needed by real programs.
a European Union project on Property Based Test-
ing (www.protest-project.eu). We are applying the
Type theory Type theory is strongly connected to
QuickCheck approach to Erlang software, together
functional programming research. Many dependently-
with Ericsson, Quviq, and others. Much recent work
typed programming languages and type-based proof as-
has focused on PULSE, the ProTest User-Level Sched-
sistants have been developed at Chalmers. The Agda
uler for Erlang, which has been used to find race con-
system (→ 3.2.2) is the latest in this line, and is of par-
ditions in industrial software — see our ICFP 2009
ticular interest to Haskell programmers. We encourage
paper for details. A new tool, QuickSpec, gener-
you to experiment with programs and proofs in Agda
ates algebraic specifications for an API automatically,
as a “dependently typed Haskell”.
in the form of equations verified by random testing.
A draft paper can be found here: http://www.cse.
chalmers.se/~nicsma/quickspec.pdf. Lastly, we have de- DSP programming Feldspar is a domain-specific lan-
vised a technique to speed up testing of polymor- guage for digital signal processing (DSP), developed
phic properties: http://publications.lib.chalmers.se/cpl/ in co-operation by Ericsson, Chalmers FP group and
record/index.xsql?pubid=99387. Eötvös Loránd (ELTE) University in Budapest. The
motivating application is telecom processing, but the
language is intended to be more general. As a first
Natural language technology Grammatical Frame- stage, we focus on the data-intensive numeric algo-
work (→ 6.10.3) is a declarative language for describ- rithms which are at the core of any DSP application,
ing natural language grammars. It is useful in various but in the future, we also plan to extend the language to
applications ranging from natural language generation, deal with more system-level aspects. The data process-
parsing and translation to software localization. The ing language is purely functional and highly inspired by
framework provides a library of large coverage gram- Haskell. Currently the language is implemented as an
mars for currently fifteen languages from which the de- embedded language in Haskell.
velopers could derive smaller grammars specific for the The implementation (including a code generator de-
semantics of a particular application. veloped by ELTE University) will be publicly released
within the coming weeks. Keep an eye on the project
Generic Programming Starting with Polytypic Pro- page: http://sourceforge.net/projects/feldspar/.
gramming in 1995 there is a long history of generic
programming research at Chalmers. Recent develop- Hardware design/verification The functional pro-
ments include work on dependent types (a JFP pa- gramming group has developed three different hard-
per + library around “Algebra of Programming us- ware description languages — Lava, Wired and Chalk
ing Agda”), two survey papers “C++ Concepts =? (chronological order) — implemented in Haskell. Each
Haskell Type Classes” and “Comparing GP Libs in language targets a different abstraction level. The basic
Haskell” and applications to sustainable development idea behind all three is to model circuits as functions
with the Potsdam Institute for Climate Impact Re- from inputs to outputs. This allows structural hard-
search (http://www.pik-potsdam.de/. Patrik Jansson ware description in standard functional programming
(with Sibylle Schupp) chaired the recent Workshop on style.
Generic Programming. Chalk is a new language for architecture design.
Once you have defined a Chalk circuit, you can sim-
Text editors Yi is a text editor in and for Haskell. ulate it, or explore it further using non-standard in-
It is a community project, but much development terpretations. This is particularly useful if you want

66
to perform high-level power and performance analysis project will also include a showcase player using the
early on in the design process. decoder.
In Lava, circuits are described at the gate level
(with some RTL support). The version developed
at Chalmers (http://www.cs.chalmers.se/~koen/Lava/)
has a particular aim to support formal verification in a
convenient way. The version developed at Xilinx Inc.
(http://raintown.org/lava/) focuses on FPGA core gen-
eration, and has been successfully used in real indus-
trial design projects.
Wired is an extension to Lava, targeting (not exclu-
sively) semi-custom VLSI design. A particular aim of
Wired is to give the designer more control over on-chip
wires’ effects on performance. Some features of Wired
are:
◦ Initial description can be purely functional (a la
Lava).
◦ Incremental specification of physical aspects.
◦ Accurate, wire-aware timing/power analysis within
the system.
◦ Support for an academic 45nm cell library.
Unfortunately, Wired is not actively developed at the
moment, but the system has recently been used to ex-
plore the layout of multipliers (http://publications.lib.
chalmers.se/cpl/record/index.xsql?pubid=93674).
Home page: http://www.cs.chalmers.se/~emax/
wired/

Automated reasoning Equinox is an automated the-

orem prover for pure first-order logic with equality.
Equinox actually implements a hierarchy of logics, re-
alized as a stack of theorem provers that use abstrac-
tion refinement to talk with each other. In the bottom
sits an efficient SAT solver. Paradox is a finite-domain
model finder for pure first-order logic with equality.
Paradox is a MACE-style model finder, which means
that it translates a first-order problem into a sequence
of SAT problems, which are solved by a SAT solver.
Infinox is an automated tool for analyzing first-order
logic problems, aimed at showing finite unsatisfiability,
i.e. the absence of models with finite domains. All three
tools are developed in Haskell.

Teaching Haskell is present in the curriculum as early

as the first year of the Bachelors program. We have
three courses solely dedicated to functional program-
ming (of which two are Masters-level courses), but
we also provide courses which use Haskell for teach-
ing other aspects of computer science, such as pro-
gramming languages, compiler construction, hardware
description and verification, data structures and pro-
gramming paradigms.

Student Projects Masters students Anders Karlsson

and Tobias Olausson are currently developing a (fast)
mp3 decoder in Haskell. More info about this project
can be found at http://trac.haskell.org/HQmpd. The

67