Index

Haskell Communities and Activities Report

Fifteenth edition – November 2008

Janis Voigtländer (ed.)

Peter Achten

Alfonso Acosta

Andy Adams-Moran

Lloyd Allison

Tiago Miguel Laureano Alves

Krasimir Angelov

Apfelmus

Emil Axelsson

Arthur Baars

Sengan Baring-Gould

Justin Bailey

Alistair Bayley

Jean-Philippe Bernardy

Clifford Beshers

Gwern Branwen

Joachim Breitner

Niklas Broberg

Bjorn Buckwalter

Denis Bueno

Andrew Butterfield

Roman Cheplyaka

Olaf Chitil

Jan Christiansen

Sterling Clover

Duncan Coutts

Jacome Cunha

Nils Anders Danielsson

Atze Dijkstra

Robert Dockins

Chris Eidhof

Conal Elliott

Henrique Ferreiro Garcia

Sebastian Fischer

Leif Frenzel

Nicolas Frisby

Richard A. Frost

Peter Gavin

Andy Gill

George Giorgidze

Dimitry Golubovsky

Daniel Gorin

Jurriaan Hage

Bastiaan Heeren

Aycan Irican

Judah Jacobson

Wolfgang Jeltsch

Kevin Hammond

Enzo Haussecker

Christopher Lane Hinson

Guillaume Hoffmann

Martin Hofmann

Liyang HU

Paul Hudak

Graham Hutton

Wolfram Kahl

Garrin Kimmell

Oleg Kiselyov

Farid Karimipour

Edward Kmett

Lennart Kolmodin

Slawomir Kolodynski

Michal Konecny

Eric Kow

Stephen Lavelle

Sean Leather

Huiqing Li

Bas Lijnse

Ben Lippmeier

Andres Löh

Rita Loogen

Ian Lynagh

John MacFarlane

Christian Maeder

Jose Pedro Magalhães

Ketil Malde

Blazevic Mario

Simon Marlow

Michael Marte

Bart Massey

Simon Michael

Arie Middelkoop

Ivan Lazar Miljenovic

Neil Mitchell

Maarten de Mol

Dino Morelli

Matthew Naylor

Jürgen Nicklisch-Franken

Rishiyur Nikhil

Thomas van Noort

Jeremy O’Donoghue

Bryan O’Sullivan

Patrick O. Perry

Jens Petersen

Simon Peyton Jones

Dan Popa

Fabian Reck

Claus Reinke

Alexey Rodriguez

Alberto Ruiz

David Sabel

Matthew Sackman

Uwe Schmidt

Tom Schrijvers

Paulo Silva

Ben Sinclair

Ganesh Sittampalam

Jim Snow

Dominic Steinitz

Don Stewart

Jon Strait

Martin Sulzmann

Doaitse Swierstra

Wouter Swierstra

Hans van Thiel

Henning Thielemann

Phil Trinder

Jared Updike

Marcos Viera

Miguel Vilaca

Janis Voigtländer

Edsko de Vries

David Waern

Jinjing Wang

Malcolm Wallace

Eelis van der Weegen

Ashley Yakeley

Brent Yorgey

Preface

This is the 15th edition of the Haskell Communities and Activities Report. There are interesting news on the implementation front, new analysis and transformation tools, many fresh projects, and new developments in established ones. Generic programming is one field that has seen a lot of activity, and you will no doubt identify other recent trends as you go through the report.

As usual, entries that are completely new (or have been revived after having disappeared temporarily) are formatted using a blue background. Updated entries have a header with a blue background. In most cases of entries that have not been changed for a year or longer, these have been dropped. Please do revive them if you have news on them for the next report.

The next report will be compiled in half a year. More details around May — watch the mailing lists for announcements. But now enjoy the report and see what other Haskellers have been up to lately. Any kind of feedback is of course very welcome <hcar at haskell.org>.

Janis Voigtländer, Technische Universität Dresden, Germany

1 General

1.1 HaskellWiki and haskell.org Report by: Ashley Yakeley Participants: John Peterson, Olaf Chitil HaskellWiki is a MediaWiki installation running on haskell.org, including the haskell.org “front page”. Anyone can create an account and edit and create pages. Examples of content include: Documentation of the language and libraries

Explanation of common idioms

Suggestions and proposals for improvement of the language and libraries

Description of Haskell-related projects

News and notices of upcoming events We encourage people to create pages to describe and advertise their own Haskell projects, as well as add to and improve the existing content. All content is submitted and available under a “simple permissive” license (except for a few legacy pages). In addition to HaskellWiki, the haskell.org website hosts some ordinary HTTP directories. The machine also hosts mailing lists. There is plenty of space and processing power for just about anything that people would want to do there: if you have an idea for which HaskellWiki is insufficient, contact the maintainers, John Peterson and Olaf Chitil, to get access to this machine. Further reading http://haskell.org/

http://haskell.org/haskellwiki/Mailing_Lists

1.2 #haskell Report by: Don Stewart The #haskell IRC channel is a real-time text chat where anyone can join to discuss Haskell. It is one of the largest channels on freenode. The irc channel is home to hpaste and lambdabot (→6.12.2), two useful Haskell bots. Point your IRC client to irc.freenode.net and join the #haskell conversation! For non-English conversations about Haskell there are now: #haskell.de — German speakers

— German speakers #haskell.dut — Dutch speakers

— Dutch speakers #haskell.es — Spanish speakers

— Spanish speakers #haskell.fi — Finnish speakers

— Finnish speakers #haskell.fr — French speakers

— French speakers #haskell.hr — Croatian speakers

— Croatian speakers #haskell.it — Italian speakers

— Italian speakers #haskell.jp — Japanese speakers

— Japanese speakers #haskell.no — Norwegian speakers

— Norwegian speakers #haskell_ru — Russian speakers

— Russian speakers #haskell.se — Swedish speakers Related Haskell channels are now emerging, including: #haskell-overflow — Overflow conversations

— Overflow conversations #haskell-blah — Haskell people talking about anything except Haskell itself

— Haskell people talking about anything except Haskell itself #gentoo-haskell — Gentoo/Linux specific Haskell conversations (→2.9.1)

— Gentoo/Linux specific Haskell conversations (→2.9.1) #haskell-books — Authors organizing the collaborative writing of the Haskell Wikibook (→1.5.3)

— Authors organizing the collaborative writing of the Haskell Wikibook (→1.5.3) #darcs — Darcs revision control channel (→6.1.1)

— Darcs revision control channel (→6.1.1) #ghc — GHC developer discussion (→2.1)

— GHC developer discussion (→2.1) #happs — HAppS Haskell Application Server channel

— HAppS Haskell Application Server channel #xmonad — XMonad, a tiling window manager (→6.1.2) Related Haskell channels are now emerging, including: Further reading http://haskell.org/haskellwiki/IRC_channel

1.3 The Monad.Reader Report by: Wouter Swierstra There are plenty of academic papers about Haskell and plenty of informative pages on the HaskellWiki (→1.1). Unfortunately, there is not much between the two extremes. That is where The Monad.Reader tries to fit in: more formal than a Wiki page, but more casual than a journal article. There are plenty of interesting ideas that maybe do not warrant an academic publication — but that does not mean these ideas are not worth writing about! Communicating ideas to a wide audience is much more important than concealing them in some esoteric journal. Even if it has all been done before in the Journal of Impossibly Complicated Theoretical Stuff, explaining a neat idea about “warm fuzzy things” to the rest of us can still be plain fun. The Monad.Reader is also a great place to write about a tool or application that deserves more attention. Most programmers do not enjoy writing manuals; writing a tutorial for The Monad.Reader, however, is an excellent way to put your code in the limelight and reach hundreds of potential users. Since last year, I have moved a lot of old articles from the old MoinMoin wiki to the new MediaWiki wiki. Unfortunately, I do not have the time to reformat all the old articles. If you fancy a go at tidying an article or two, I would really appreciate your help! I am always interested in new submissions, whether you are an established researcher or fledgling Haskell programmer. Check out the Monad.Reader homepage for all the information you need to start writing your article. Further reading http://www.haskell.org/haskellwiki/The_Monad.Reader

1.4 Haskell Weekly News Report by: Don Stewart The Haskell Weekly News (HWN) is an irregular newsletter covering developments in Haskell. Content includes announcements of new projects, jobs, discussions from the various Haskell communities, notable project commit messages, Haskell in the blogspace, and more. The Haskell Weekly News also publishes latest releases uploaded to Hackage. It is published in html form on The Haskell Sequence, via mail on the Haskell mailing list, on Planet Haskell, and via RSS. Headlines are published on haskell.org (→1.1). Further reading http://www.haskell.org/haskellwiki/Haskell_Weekly_News

1.5 Books and tutorials

1.5.1 Programming in Haskell Report by: Graham Hutton Haskell is one of the leading languages for teaching functional programming, enabling students to write simpler and cleaner code, and to learn how to structure and reason about programs. This introduction is ideal for beginners: it requires no previous programming experience and all concepts are explained from first principles via carefully chosen examples. Each chapter includes exercises that range from the straightforward to extended projects, plus suggestions for further reading on more advanced topics. The presentation is clear and simple, and benefits from having been refined and class-tested over several years. Features include: freely accessible powerpoint slides for each chapter; solutions to exercises, and examination questions (with solutions) available to instructors; downloadable code that is compliant with the latest Haskell release. Publication details: Published by Cambridge University Press, 2007. Paperback: ISBN 0521692695; Hardback: ISBN: 0521871727; eBook: ISBN 051129218X; Kindle: ASIN B001FSKE6Q. In-depth review: Duncan Coutts, The Monad.Reader (→1.3), http://www.haskell.org/sitewiki/images/0/03/TMR-Issue7.pdf Further reading http://www.cs.nott.ac.uk/~gmh/book.html

The book “Real World Haskell” about the practical application of Haskell to everyday programming problems has been published in November 2008 by O’Reilly. Our intended audience is programmers with no background in functional languages. We explore a diverse set of topics, among which are the following. Basics of Haskell and functional programming

Developing software using standard tools like GHC and the Cabal packaging system

Code coverage, quality assurance, and performance analysis

Putting theory to work: working with and creating monoids, normal and applicative functors, monads, and monad transformers

Applied topics: databases, filesystems, GUI programming, web and other network clients, web servers

Concurrent, parallel, and transactional programming

Error handling in pure and impure code

Interfacing to C libraries

Many case studies and runnable code examples We are excited to be publishing the book under a Creative Commons License. We are excited to be publishing the book under a Creative Commons License. Further reading http://book.realworldhaskell.org/

1.5.3 Haskell Wikibook Report by: Apfelmus Participants: Eric Kow, David House, Joeri van Eekelen, and other contributors Status: active development The goal of the Haskell wikibook project is to build a community textbook about Haskell that is at once free (as in freedom and in beer), gentle, and comprehensive. We think that the many marvelous ideas of lazy functional programming can and thus should be accessible to everyone in a central place. Recently, the wikibook has been advancing rather slowly. The rewrite of the Monad chapters is still in progress and material about lazy evaluation is still being written. Of course, additional authors and contributors that help writing new contents or simply spot mistakes and ask those questions we had never thought of are more than welcome! Further reading http://en.wikibooks.org/wiki/Haskell

Mailing list: <wikibook at haskell.org>

1.5.4 Gtk2Hs tutorial Report by: Hans van Thiel Most of the original GTK+2.0 tutorial by Tony Gail and Ian Main has been adapted to Gtk2Hs (→5.11.1), which is the Haskell binding to the GTK GUI library. The Gtk2Hs tutorial also builds on “Programming with gtkmm” by Murray Cumming et al. and the Inti (Integrated Foundation Classes) tutorial by the Inti team. The Gtk2Hs tutorial assumes intermediate level Haskell programming skills, but no prior GUI programming experience. It has been translated into Spanish, by Laszlo Keuschnig, and both versions are available on Haskell darcs. See: http://darcs.haskell.org/gtk2hs/docs/tutorial/Tutorial_Port/ 1. Introduction 2. Getting Started 3. Packing 3.1 Packing Widgets 3.2 Packing Demonstration Program 3.3 Packing Using Tables 4. Miscellaneous Widgets 4.1 The Button Widget 4.2 Adjustments, Scale, and Range 4.3 Labels 4.4 Arrows and Tooltips 4.5 Dialogs, Stock Items, and Progress Bars 4.6 Text Entries and Status Bars 4.7 Spin Buttons 5. Aggregated Widgets 5.1 Calendar 5.2 File Selection 5.3 Font and Colour Selection 5.4 Notebook 6. Supporting Widgets 6.1 Scrolled Windows 6.2 EventBoxes and ButtonBoxes 6.3 The Layout Container 6.4 Paned Windows and Aspect Frames 7. Action Based Widgets 7.1 Menus and Toolbars 7.2 Popup Menus, Radio Actions, and Toggle Actions Appendix: Drawing with Cairo: Getting Started The Glade tutorial, an introduction to visual Gtk2Hs programming, has been updated to Glade 3 by Alex Tarkovsky. It is available on: http://haskell.org/gtk2hs/docs/tutorial/glade/ This tutorial has also been translated into Spanish, by Laszlo Keuschnig, but it is currently only available on: http://home.telfort.nl/sp969709/glade/es-index.html

1.5.5 Monad Tutorial Report by: Hans van Thiel Status: stable, might be expanded later The “Greenhorn’s Guide to becoming a Monad Cowboy” is yet another monad tutorial. It covers the basics and some examples, including a monad transformer, in a style which is a variation on the “for dummies” style. Estimated learning time is 1–2 days. It is available at http://www.muitovar.com/monad/moncow.xhtml Further reading http://www.muitovar.com/

The collection of various Haskell mini tutorials and assorted small projects (http://okmij.org/ftp/Haskell/) has received two additions: Data-Generic and Data-Extensible Programming in Haskell This web page describes the generic programming library “Smash” and a couple of its applications. Smash is a generic programming approach based on a type-level typecase, best understood as a static dual of “Scrap your boilerplate I” (SYB1). The Smash approach is powerful to express traversals where the type of the result is computed from the type of the transformer and the type/structure of the original term. An example is replacing all Floats with Doubles in an arbitrary term, e.g., made of Maybes, tuples, lists; the result type is computed and need not be specified. One application explained on the web page is generic de-serialization: reconstructing a term from a flat list of its fields and a proto-type term specifying the desired structure. The Smash library is part of the extensive generic programming comparison benchmark by Alexey Rodriguez Yakushev, Alex Gerdes, and Johan Jeuring. The implementation of benchmark tests in Smash can be found at http://darcs.haskell.org/generics/comparison/SmashA/ The web page also describes a variation of the SYB3 type-class-based generic programming library that avoids both higher-rank types and mutually recursive instances. Because of the latter our code, unlike SYB3, works even in Hugs. http://okmij.org/ftp/Haskell/generics.html State Monad as a term algebra We show the implementation of the state monad as a term algebra: a monadic action is a term built from sub-terms Bind , Return , Get , and Put . The constructors of the action are neither variants nor GADTs. The function runst (a method of the type class RunState ) takes the initial state and the action data type, and interprets the action manipulating the state accordingly. The only non-trivial part is the interpretation of Bind , due to the polymorphism of the monadic bind operation. Although our implementation uses no GADTs, we nevertheless statically ensure that the interpretation of an action never gets stuck. http://okmij.org/ftp/Haskell/types.html#state-algebra

1.5.7 Haskell Cheat Sheet Report by: Justin Bailey I have created a “cheat sheet” for Haskell. It is a PDF that tries to summarize Haskell 98’s syntax, keywords, and other language elements. It is built from a literate source file, so all the examples in the cheat sheet are executable. The cheatsheet is on Hackage. Once downloaded, unpack the archive and you will see the PDF and literate source. I will be hosting the PDF directly, but for now I wanted a “limited” release. Posting to Hackage limits the audience somewhat. I will send an additional announcement when feedback has been incorporated and the PDF is available generally. Further reading http://hackage.haskell.org/cgi-bin/hackage-scripts/package/CheatSheet

2 Implementations

For the last six months we have been primarily focused on the 6.10.1 release, which should be out by the time you read this. We are extremely grateful for the increasing support we get from the community in putting GHC releases together; more people than ever before are now helping maintain subcomponents, implementing features, fixing bugs, testing release candidates, and much more besides. We could not have made this release without your help! The GHC 6.10 branch GHC 6.10.1 is the first release in the 6.10 branch, and features many improvements over the 6.8 branch. The release notes have fully details, but the highlights are: Some new language features have been implemented: Record syntax: wild-card patterns, punning, and field disambiguation Generalized quasi-quotes (Geoff Mainland), from the paper Why it’s nice to be quoted: quasi-quoting in Haskell (Haskell workshop 2007) Generalized list comprehensions (Max Bolingbroke), from the paper Comprehensive comprehensions: comprehensions with “Order by” and “Group by” (Haskell workshop 2007) View patterns (Dan Licata); see view patterns wiki page

Type families have been completely re-implemented, by Manuel Chakravarty, along the lines of our ICFP 2008 paper Type checking with open type functions — only simpler. As a result, we believe that type families work reliably in GHC 6.10. There is one missing feature, however, namely the ability to have equalities in the superclass context of a class. We will add that to the HEAD in the next few months. An up-to-date wiki page tracks design issues and current status.

GHC now comes with Haddock 2, which supports all GHC extensions, thanks to David Waern.

Parallel garbage collection has been implemented by Simon Marlow. This speeds up even purely-sequential programs, by using the extra processors during garbage collection. Our ISMM’08 paper gives the details Parallel generational-copying garbage collection with a block-structured heap.

The base library now provides, and uses, extensible exceptions, as described in Simon Marlow’s paper An Extensible Dynamically-Typed Hierarchy of Exceptions (Haskell workshop 2006).

Thomas Schilling has made the GHC API easier to use, by using a Ghc monad to carry the session state. Furthermore, the API now has Haddock documentation.

monad to carry the session state. Furthermore, the API now has Haddock documentation. External core (output only) now works again, thanks to Tim Chevalier.

Data Parallel Haskell (DPH) comes as part of GHC, as a result of Roman Leshchinskiy’s efforts. In 6.10, for the first time, DPH includes a full vectorizer, so the system is much more usable than before. It is still really an alpha release, though; we very much welcome friendly guinea pigs, but it is not ready for your 3 gigabyte genome search program. We have a lot of performance tuning to do. We have written a new paper Harnessing the multicores: nested data parallelism in Haskell (FSTTCS’08), which gives a tutorial overview of the system, focusing especially on vectorization. The GHC 6.12 branch Meanwhile, development goes on in the HEAD: John Dias has been working hard on rewriting GHC’s backend, and his changes should be landing in the HEAD during October. You can find an overview of the new architecture on the wiki.

Data Parallel Haskell remains under very active development.

We hope that Max Bolingbroke’s Dynamically Loaded Plugins summer of code project will be merged in time for 6.12. Part of this is a new, modular system for user-defined annotations, rather like Java or C#attributes. These attributes are persisted into interface files, can be examined and created by plugins, or by GHC API clients.

Likewise, Donnie Jones’ project for profiling parallel programs should be merged in time for 6.12.

Simon Marlow is working on improving parallel performance, incorporating the work done by Jost Berthold during his internship at Microsoft in the summer of 2008. The plan is to make writing performant parallel programs less of a trial-and-error process, by whacking as many bottlenecks as we can find in the runtime system. We are already making significant improvements, and there is plenty more low-hanging fruit to pick. One large project that we hope to tackle is the issue of doing independent per-CPU garbage collection.

Shared Libraries are inching ever closer to being completed. Clemens Fruhwirth has been working on polishing the support for shared libraries on Unix systems in particular, and when the remaining issues are ironed out we should be able to roll them out in a release.

Finally, unicode text I/O and dynamic libraries were slated for 6.10 but were not quite ready in time, so we certainly expect those to make it for in 6.12. From a development point of view, there are a couple of changes on the horizon: We plan to change how GHC’s build system works, to decouple it from Cabal’s internals. Our current plans are here.

We plan to change from darcs to git for the version control system used by GHC; our plans are described here. We plan to make the build-system changes first, and only then tackle the version control system. From a development point of view, there are a couple of changes on the horizon:We plan to make the build-system changes first, and only then tackle the version control system. Summary Keeping GHC functioning for an increasingly-diverse user base is quite a challenge, especially as we keep changing the wheels while the bus is driving along. Please do consider joining in; there are plenty of things that need doing, and do not require intimate knowledge of the internals. We could particularly do with more help on supporting the Windows, Sparc, and BSD ports of GHC.

nhc98 is a small, easy to install, compiler for Haskell’98. nhc98 is still very much alive and working, although it does not see many new features these days. We expect a new public release (1.22) soon, to coincide with the release of ghc-6.10.x, in particular to ensure that the included libraries are compatible across compilers. Further reading http://haskell.org/nhc98

darcs get http://darcs.haskell.org/nhc98

The York Haskell Compiler (yhc) is a fork of the nhc98 compiler (→2.2), with goals such as increased portability, platform independent bytecode, integrated Hat (→4.3.6) support, and generally being a cleaner code base to work with. Yhc now compiles and runs almost all Haskell 98 programs, has basic FFI support — the main thing missing is haskell.org base libraries, which is being worked on. There are a number of projects that make use of the Yhc.Core library, in particular a Javascript and Erlang backend. Further reading Homepage: http://www.haskell.org/haskellwiki/Yhc

Darcs repository: http://darcs.haskell.org/yhc

Yhc Javascript Web Service http://www.haskell.org/haskellwiki/Yhc_web_service

Helium is a compiler that supports a substantial subset of Haskell 98 (but, e.g., n+k patterns are missing). Type classes are restricted to a number of built-in type classes and all instances are derived. The advantage of Helium is that it generates novice friendly error feedback. The latest versions of the Helium compiler are available for download from the new website located at http://www.cs.uu.nl/wiki/Helium. This website also explains in detail what Helium is about, what it offers, and what we plan to do in the near and far future. We are still working on making version 1.7 available, mainly a matter of updating the documentation and testing the system. Internally little has changed, but the interface to the system has been standardized, and the functionality of the interpreters has been improved and made consistent. We have made new options available (such as those that govern where programs are logged to). The use of Helium from the interpreters is now governed by a configuration file, which makes the use of Helium from the interpreters quite transparent for the programmer. It is also possible to use different versions of Helium side by side (motivated by the development of Neon (→5.3.6)). A student is currently in the process of adding type class and instance definitions to the language. The work on the documentation has progressed quite a bit, but there has been little testing thus far, especially on a platform such as Windows.

2.5 EHC, “Essential Haskell” Compiler Report by: Atze Dijkstra Participants: Jeroen Fokker, Doaitse S. Swierstra, Arie Middelkoop, Lucilia Camarãao de Figueiredo, Carlos Camarãao de Figueiredo Status: active development What is EHC? The EHC project provides a Haskell compiler as well as a description of the compiler which is as understandable as possible so it can be used for education as well as research. For its description an Attribute Grammar system (AG) is used as well as other formalisms allowing compact notation like parser combinators. For the description of type rules, and the generation of an AG implementation for those type rules, we use the Ruler system. For source code management we use Shuffle, which allows partitioning the system into a sequence of steps and aspects. (Both Ruler and Shuffle are included in the EHC project). The EHC project also tackles other issues: In order to avoid overwhelming the innocent reader, the description of the compiler is organized as a series of increasingly complex steps. Each step corresponds to a Haskell subset which itself is an extension of the previous step. The first step starts with the essentials, namely typed lambda calculus; the last step corresponds to full Haskell.

Independent of each step the implementation is organized into a set of aspects. Currently the type system and code generation are defined as aspects, which can then be left out so the remaining part can be used as a barebones starting point.

Each combination of step + aspects corresponds to an actual, that is, an executable compiler. Each of these compilers is a compiler in its own right.

The description of the compiler uses code fragments which are retrieved from the source code of the compilers. In this way the description and source code are kept synchronized. Currently EHC offers experimental implementation of more advanced features like higher-ranked polymorphism, partial type signatures, and kind polymorphism. Part of the description of the series of EH compilers is available as a PhD thesis. What is EHC’s status, what is new? A Haskell frontend plus Prelude has been made, compiled code runs with an interpreter. The compiler has an acceptable memory + resource footprint (done by Atze Dijkstra).

A GRIN (Graph Reduction Intermediate Notation) based backend is available, offering global program optimization and code generation to C (done by Jeroen Fokker) as well as LLVM (done by John van Schie).

Work has started on formalizing EHC’s type system; extending our Ruler system will be part of this effort (by Lucilia Camarãao de Figueiredo, Carlos Camarãao de Figueiredo, Arie Middelkoop, Atze Dijkstra).

The organization of EHC into aspects, allowing better partial reuse of EHC.

Though not a direct part of EHC, its supporting tools (AG, Shuffle) are regularly adapted to allow a cleaner EHC code base. Is EHC used, can I use EHC? Yes, but the answer also depends for what purpose. Although it compiles a Prelude, we have yet to prepare a release of EHC as a Haskell compiler. Also, the first release will definitively be a alpha release, meant for play and experimentation, not for compiling real world programs. EHC is used as a platform for experimentation, see EHC’s webpage for various projects related to EHC. EHC can be downloaded from our svn repository. What will happen with EHC in the near future? We plan to do the following: Make the variant for full Haskell available as a Haskell compiler. For this we will stabilize the implementation and add proper documentation.

Rework the type system to have a more formal underpinning. Our intent is to use and extend our Ruler system for this. Further reading Homepage: http://www.cs.uu.nl/wiki/Ehc/WebHome

Attribute grammar system: http://www.cs.uu.nl/wiki/HUT/AttributeGrammarSystem

Parser combinators: http://www.cs.uu.nl/wiki/HUT/ParserCombinators

Shuffle: http://www.cs.uu.nl/wiki/Ehc/Shuffle

Ruler: http://www.cs.uu.nl/wiki/Ehc/Ruler

2.6 Hugs as Yhc Core Producer Report by: Dimitry Golubovsky Status: Experimental Background Hugs is one of the oldest implementations of Haskell known, an interactive compiler and bytecode interpreter. Yhc (→2.3) is a fork of nhc98 (→2.2). Yhc Core is an intermediate form Yhc uses to represent a compiled Haskell program. Yhc converts each Haskell module to a binary Yhc Core file. Core modules are linked together, and all redundant (unreachable) code is removed. The Linked Core is ready for further conversions by backends. Hugs loads Haskell modules into memory and stores them in a way to some degree similar to Yhc Core. Hugs is capable to dump its internal storage structure in textual form (let us call it Hugs Core). The output looks similar to Yhc Core, pretty-printed. This was initially intended for debugging purposes, however several Hugs CVS (now darcs) log records related such output to some “Snowball Haskell compiler” ca. 2001. The experiment The goal of the experiment described here was to convert Hugs Core into Yhc Core, so Hugs might become a frontend for existing and future Yhc Core optimizers and backends. At least one benefit is clear: Hugs is well maintained to be compatible with recent versions of Haskell libraries and supports many of Haskell language extensions that Yhc does not yet support. The necessary patches were pushed to the main Hugs repository in June 2008, thanks to Ross Paterson for reviewing them. The following changes were made: A configuration option was added to enable the generation of Hugs Core. The toplevel Makefile was modified to build an additional executable, corehugs . Consistency of Hugs Core output in terms of naming of modules and functions was improved. The corehugs program converts Haskell source files into Hugs Core files, one for one. All functions and data constructors are preserved in the output, whether reachable or not. Unreachable items will be removed later using Yhc Core tools. The conversion of Hugs Core to Yhc Core is performed outside of Hugs using the hugs2yc package. The package provides a parser for the syntax of Hugs Core and an interface to the Yhc Core Linker. All Hugs Core files written by corehugs are read in and parsed, resulting in the set of Yhc Core modules in memory. The modules are linked together using the Yhc Core Linker, and all unreachable items are removed at this point. A “driver” program that uses the package may save the linked Yhc Core in a file, or pass it on to a backend. The code of the hugs2yc package is compatible to both Hugs and GHC. Availability In order to use the new Hugs functionality, obtain Hugs from the “HEAD” darcs repo, see http://hackage.haskell.org/trac/hugs/wiki/GettingTheSource. However, Hugs obtained in such a way may not always compile. This Google Code project: http://code.google.com/p/corehugs/ hosts specialized snapshots of Hugs that are more likely to build on a random computer and also include additional packages necessary to work with Yhc Core. Future plans Further effort will be taken to standardize various aspects of Yhc Core, especially the specification of primitives, because all backends must implement them uniformly. This Google spreadsheet: http://tinyurl.com/prim-normal-set contains the proposal for an unified set of Yhc Core primitives. Work is in progress on various backends for Yhc Core, including Javascript, Erlang, Python, JVM, .NET, and others. This Wiki page: http://tinyurl.com/ycore-conv-infra summarizes their development status. Further reading Yhc Core conversion infrastructure

http://tinyurl.com/ycore-conv-infra

http://tinyurl.com/ycore-conv-infra Download Hugs specialized snapshots

http://code.google.com/p/corehugs/

http://code.google.com/p/corehugs/ Proposed specification of the Normal Set of primitives

http://tinyurl.com/prim-normal-set

http://tinyurl.com/prim-normal-set A brief example of using corehugs

http://code.google.com/p/corehugs/wiki/Demonstration

2.7 Haskell frontend for the Clean compiler Report by: Thomas van Noort Participants: John van Groningen, Rinus Plasmeijer Status: active development We are currently working on a frontend for the Clean compiler (→3.2.3) that supports a subset of Haskell 98. This will allow Clean modules to import Haskell modules, and vice versa. Furthermore, we will be able to use some of Clean’s features in Haskell code, and vice versa. For example, we could define a Haskell module which uses Clean’s uniqueness typing, or a Clean module which uses Haskell’s newtypes. The possibilities are endless! Future plans We hope to release a beta version of the new Clean compiler, solely to the institution in Nijmegen, by the end of this year. But 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 promises regarding the release date. Keep an eye on the Clean mailing lists for any important announcements! Further reading http://wiki.clean.cs.ru.nl/Mailing_lists

The Reduceron is a prototype of a special-purpose graph reduction machine, built using an FPGA. It can access up to eight graph nodes in parallel on each of its stack, heap, and combinator memories. The goal so far has been to optimize function application. Eight combinator nodes can be instantiated with eight stack elements and placed on the heap, all in a single cycle. The Reduceron is a simple machine, containing just four instructions and a garbage collector, and executes core Haskell almost directly. The translator to bytecode and the FPGA machine are both implemented in Haskell, the latter using Lava (→6.9.2). See the URL below for details and results. Since the last HCAR, I have written a thesis in which chapter 2 is dedicated to the Reduceron. I am now working on a new Reduceron which I hope will exploit wide, parallel memories further. I am also working on a new variant of Lava, to support the demands of the Reduceron. Further reading http://www.cs.york.ac.uk/~mfn/reduceron2/

2.9 Platforms

2.9.1 Haskell in Gentoo Linux Report by: Lennart Kolmodin GHC version 6.8.2 has been in Gentoo since late last year, and is about to go stable. All of the 60+ Haskell libraries and tools work with it, too. There are also GHC binaries 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 tracker at bugs.gentoo.org. There is also a Haskell overlay providing another 200 packages. Thanks to the recent progress of Cabal and Hackage (→5.1), we have written a tool called “hackport” (initiated by Henning Günther) to generate Gentoo packages that rarely need much tweaking. The overlay is available 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 “layman”. If you choose to use the overlay, then problems should be reported on IRC ( #gentoo-haskell on freenode), where we coordinate development, or via email <haskell at gentoo.org>. Lately a few of our developers have shifted focus, and only a few developers remain. If you would like to help, which would include working on the Gentoo Haskell framework, hacking on hackport, writing ebuilds, and supporting users, please contact us on IRC or email as noted above.

2.9.2 Fedora Haskell SIG Report by: Jens Petersen Participants: Bryan Sullivan, Yaakov Nemoy, Fedora Haskell SIG Status: on-going The Fedora Haskell SIG is an effort to provide good support for Haskell in Fedora. We now have a set of rpm macros and Packaging Guidelines for packaging Cabal-based packages in Fedora: so it is now fairly easy to get Haskell packages reviewed and approved by package reviewers in Fedora. Fedora 10 will ship with ghc-6.8.3 and the new rpm macros at the end of this month. For Fedora 11 we are planning to move to ghc-6.10 and add plenty of Haskell libraries using the new Fedora Haskell Packaging Guidelines, and hopefully also experiment with shared libraries and cabal-install. Further reading http://fedoraproject.org/wiki/SIGs/Haskell

3 Language

3.1 Extensions of Haskell

Haskell Server Pages (HSP) is an extension of Haskell targeted at writing dynamic web pages. Key features and selling points include: Use literal XML syntax in your Haskell code for creating values of appropriate datatypes. (Note though that writing literal XML is quite optional, if you, like me, do not really enjoy that language.)

Guarantees that XML output is well-formed (and an HTML output mode if that is what you need).

A model that gives easy access to necessary environment variables.

Simple programming model that is easy to use even for non-experienced Haskell programmers, in particular with a very simple transition from static XML pages to dynamic HSP pages.

Easy integration with a DSL called HJScript that makes it easy to write client-side (JavaScript) scripts.

An extension of HAppS that can serve HSP pages on the fly, making deployment of pages really simple. HSP is continuously released onto Hackage. It consists of a series of interdependent packages with package hsp as the main top-level starting point, and package happs-hsp for integration with HAppS. The best way to keep up with development is to grab the darcs repositories, all located under Further reading HSP is continuously released onto Hackage. It consists of a series of interdependent packages with package hsp as the main top-level starting point, and package happs-hsp for integration with HAppS. The best way to keep up with development is to grab the darcs repositories, all located under http://code.haskell.org/HSP http://haskell.org/haskellwiki/HSP

Status A complete, GHC-based implementation of the parallel Haskell extension GpH and of evaluation strategies is available. Extensions of the runtime-system and language to improve performance and support new platforms are under development. System Evaluation and Enhancement Both GpH and Eden parallel Haskells are being used for parallel language research and in the SCIEnce project (see below).

We are making comparative evaluations of a range of GpH implementations and other parallel functional languages (Eden and Feedback Directed Implicit Parallelism (FDIP)) on multicore architectures.

We are teaching parallelism to undergraduates using GpH at Heriot-Watt and Phillips Universität Marburg.

We are developing a big step operational semantics for seq and using it to prove identities. GpH Applications As part of the SCIEnce EU FP6 I3 project (026133) (→8.6) (April 2006 – April 2011) we use GpH and Eden as middleware to provide access to computational grids from Computer Algebra(CA) systems, including GAP, Maple MuPad and KANT. We have designed, implemented and are evaluating the SymGrid-Par interface that facilitates the orchestration of computational algebra components into high-performance parallel applications. In recent work we have demonstrated that SymGrid-Par is capable of exploiting a variety of modern parallel/multicore architectures without any change to the underlying CA components; and that SymGrid-Par is capable of orchestrating heterogeneous computations across a high-performance computational Grid. Implementations The GUM implementation of GpH is available in two main development branches. The focus of the development has switched to versions tracking GHC releases, currently GHC 6.8, and the development version is available upon request to the GpH mailing list (see the GpH web site).

The stable branch (GUM-4.06, based on GHC-4.06) is available for RedHat-based Linux machines. The stable branch is available from the GHC CVS repository via tag gum-4-06. We are exploring new, prescient scheduling mechanisms for GpH. Our main hardware platforms are Intel-based Beowulf clusters and multicores. Work on ports to other architectures is also moving on (and available on request): A port to a Mosix cluster has been built in the Metis project at Brooklyn College, with a first version available on request from Murray Gross. Further reading GpH Home Page: http://www.macs.hw.ac.uk/~dsg/gph/

Stable branch binary snapshot: ftp://ftp.macs.hw.ac.uk/pub/gph/gum-4.06-snap-i386-unknown-linux.tar

Stable branch installation instructions: ftp://ftp.macs.hw.ac.uk/pub/gph/README.GUM Contact <gph at macs.hw.ac.uk>, <mgross at dorsai.org>

Eden extends Haskell with a small set of syntactic constructs for explicit process specification and creation. While providing enough control to implement parallel algorithms efficiently, it frees the programmer from the tedious task of managing low-level details by introducing automatic communication (via head-strict lazy lists), synchronization, and process handling. Eden’s main constructs are process abstractions and process instantiations. The function process :: (a -> b) -> Process a b embeds a function of type (a -> b) into a process abstraction of type Process a b which, when instantiated, will be executed in parallel. Process instantiation is expressed by the predefined infix operator ( # ) :: Process a b -> a -> b . Higher-level coordination is achieved by defining skeletons, ranging from a simple parallel map to sophisticated replicated-worker schemes. They have been used to parallelize a set of non-trivial benchmark programs. Survey and standard reference Rita Loogen, Yolanda Ortega-Mallén, and Ricardo Peña: Parallel Functional Programming in Eden, Journal of Functional Programming 15(3), 2005, pages 431–475. Implementation A major revision of the parallel Eden runtime environment for GHC 6.8.1 is available from the Marburg group on request. Support for Glasgow parallel Haskell (→3.1.2) is currently being added to this version of the runtime environment. It is planned for the future to maintain a common parallel runtime environment for Eden, GpH, and other parallel Haskells. Program executions can be visualized using the Eden trace viewer tool EdenTV. Recent results show that the system behaves equally well on workstation clusters and on multi-core machines. Recent Theses Jost Berthold: Implicit and Explicit Parallel Functional Programming: Concepts and Implementation , Dissertation (PhD thesis), Fachbereich Mathematik und Informatik, Philipps-Universitat Marburg, June 2008.

, Dissertation (PhD thesis), Fachbereich Mathematik und Informatik, Philipps-Universitat Marburg, June 2008. Alberto de la Encina: Formalizando el proceso de depuracion en programacion funcional paralela y perezosa , Tesis Doctoral (PhD thesis), Facultad de Ciencias Matematicas, Universidad Complutense de Madrid, June 2008, in Spanish.

, Tesis Doctoral (PhD thesis), Facultad de Ciencias Matematicas, Universidad Complutense de Madrid, June 2008, in Spanish. Lidia Lidia Sanchez-Gil: Sobre la equivalencia entre semanticas operacionales y denotacionales para lenguajes funcionales paralelos, Master Thesis, Universidad Complutense de Madrid, September 2008 (in Spanish). Recent and Forthcoming Publications Jost Berthold, Simon Marlow, Kevin Hammond, and Abyd Al Zain: Comparing and Optimising Parallel Haskell Implementations on Multicore , Draft Proceedings of the 20th International Symposium on the Implementation and Application of Functional Languages (IFL), September 2008

, Draft Proceedings of the 20th International Symposium on the Implementation and Application of Functional Languages (IFL), September 2008 Mischa Dieterle, Jost Berthold, and Rita Loogen: Functional Skeleton Implementations for Parallel Map-and-Reduce , Draft Proceedings of the 20th International Symposium on the Implementation and Application of Functional Languages (IFL), September 2008.

, Draft Proceedings of the 20th International Symposium on the Implementation and Application of Functional Languages (IFL), September 2008. Jost Berthold, Mischa Dieterle, and Rita Loogen: A Distributed Work Pool Skeleton in Eden , submitted.

, submitted. Oleg Lobachev, Jost Berthold, Mischa Dieterle, and Rita Loogen: Parallel FFT With Eden Skeletons , in preparation.

, in preparation. Oleg Lobachev and Rita Loogen: Towards an Implementation of a Computer Algebra System in a Functional Language , 9th International Conference on Artificial Intelligence and Symbolic Computation (AISC), Birmingham, July 2008, Springer LNAI 5144, 141–154.

, 9th International Conference on Artificial Intelligence and Symbolic Computation (AISC), Birmingham, July 2008, Springer LNAI 5144, 141–154. Alberto de la Encina, Ismael Rodriguez, and Fernando Rubio: A Debugger for Parallel Haskell Dialects, LNCS 5022, Springer 2008, 282-293. Further reading http://www.mathematik.uni-marburg.de/~eden

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 Kenny’s thesis will be available by the end of the year, describing in detail the formal underpinnings behind XHaskell. One of the things we will be looking into in the future is to turn XHaskell into a library (rather than stand-alone compiler).

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 Latest developments The HaskellActor implementation (as a library extension to Haskell) is available via http://hackage.haskell.org/cgi-bin/hackage-scripts/package/actor

3.2 Related Languages

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, declarative concurrency, and the search for solutions. Although Haskell and Curry share the same syntax, there is one main difference with respect to how function declarations 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 induce 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 implementations 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 conflict with the logic extensions. Recent research aims at simplifying the compilation scheme of KiCS which allows for using optimizations when compiling the generated Haskell code. First tests show that this significantly improves the performance of Curry programs. 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 interesting research topics regarding more efficient compilation techniques and even semantic questions in the area of language extensions like encapsulation and function patterns. Besides activities regarding the language itself, there is also an active development of tools concerning Curry (e.g., the documentation tool CurryDoc, the analysis environment CurryBrowser, the observation debuggers COOSy and iCODE, the debugger B.I.O. (http://www-ps.informatik.uni-kiel.de/currywiki/tools/oracle_debugger), EasyCheck (→4.3.2), and CyCoTest (→4.3.4)). Because Curry has a functional subset, these tools can canonically be transferred to the functional world. Further reading http://www.curry-language.org/

http://wiki.curry-language.org/

Do you crave for highly expressive types, but do not want to resort to type-class hackery? Then Agda might provide a view of what the future has in store for you. Agda is a dependently typed functional programming language (developed using Haskell). The language has inductive families, i.e. GADTs which can be indexed by values and not just types. Other goodies include parameterized modules, mixfix operators, and an interactive Emacs interface (the type checker can assist you in the development of your code). A lot of work remains in order for Agda to become a full-fledged programming language (good libraries, mature compilers, documentation, etc.), but already in its current state it can provide lots of fun as a platform for experiments in dependently typed programming. New since last time: Coinductive types (types with possibly infinite values).

Case-split: The user interface can replace a pattern variable with the corresponding constructor patterns. You get one new left-hand side for every possible constructor.

The foreign function interface now ensures that the foreign (Haskell) code has types matching the Agda code.

Sized types, which can make it easier to explain why your code is terminating, are currently being implemented by Ulf Norell and Andreas Abel.

Agda packages for Debian/Ubuntu have been prepared by Liyang HU, and Kuragaki-san has constructed a new Agda installer for Windows.

A new Emacs input method, which contains bindings for many Unicode symbols, has been implemented by Nils Anders Danielsson. Further reading The Agda Wiki: http://www.cs.chalmers.se/~ulfn/Agda/

3.2.3 Clean Participants: Software Technology Research Group at Radboud University Nijmegen Clean is a general purpose, state-of-the-art, pure and lazy functional programming language designed for making real-world applications. Clean is the only functional language in the world which offers uniqueness typing. This type system makes it possible in a pure functional language to incorporate destructive updates of arbitrary data structures (including arrays) and to make direct interfaces to the outside imperative world. Here is a short list with notable features: Clean is a lazy, pure, higher-order functional programming language with explicit graph rewriting semantics.

Although Clean is by default a lazy language one can smoothly turn it into a strict language to obtain optimal time/space behavior: functions can be defined lazy as well as (partially) strict in their arguments; any (recursive) data structure can be defined lazy as well as (partially) strict in any of its arguments.

Clean is a strongly typed language based on an extension of the well-known Milner/Hindley/Mycroft type inferencing/checking scheme including the common higher-order types, polymorphic types, abstract types, algebraic types, synonym types, and existentially quantified types.

Type classes and type constructor classes are provided to make overloaded use of functions and operators possible.

Clean offers records and (destructively updateable) arrays and files.

Clean has pattern matching, guards, list comprehensions and array comprehensions and a lay-out sensitive mode.

The uniqueness type system makes it possible to develop efficient applications. In particular, it allows a refined control over the single threaded use of objects. Thus can influence the time and space behavior of programs. The uniqueness type system can be also used to incorporate destructive updates of objects within a pure functional framework. It allows destructive transformation of state information and enables efficient interfacing to the non-functional world (to C but also to I/O systems like X-Windows) offering direct access to file systems and operating systems.

Clean offers a sophisticated I/O library with which window based interactive applications (and the handling of menus, dialogs, windows, mouse, keyboard, timers, and events raised by sub-applications) can be specified compactly and elegantly on a very high level of abstraction.

GUI-based programs written in Clean using the 0.8 I/O library can be ported without modification of source code to any one of the many platforms we support.

There are many libraries available offering additional functionality. Further reading http://clean.cs.ru.nl/

3.3 Type System / Program Analysis

An important feature of pure functional programming languages is definiteness: if the same expression is used in multiple places, it must have the same value every time. A consequence of definiteness (sometimes also referred to as referential transparency) is that functions must not be allowed to modify their arguments, unless it can be guaranteed that they have the sole reference to that argument. This is the basis of uniqueness typing. We have been developing a uniqueness type system based on that of the language Clean (→3.2.3) but with various improvements: no subtyping is required, the type language does not include inequality constraints (types in Clean often involve implications between uniqueness attributes), and types and uniqueness attributes are both considered types (albeit of different kinds). This makes the type system sufficiently similar to standard Hindley/Milner type systems that (1) standard inference algorithms can be applied, and (2) modern extensions such as arbitrary rank types and generalized algebraic data types (GADTs) can easily be incorporated. Although our type system is inspired by Clean, it is also relevant to Haskell, because the core uniqueness type system we propose is very similar to Haskell’s core type system. Further reading Edsko de Vries, “Making Uniqueness Typing Less Unique”, PhD thesis, forthcoming .

. Edsko de Vries, Rinus Plasmeijer, and David Abrahamson, “Uniqueness Typing Simplified”, in Olaf Chitil, Zoltan Horvath and Viktoria Zsok (Eds.): IFL 2007, LNCS 5083 .

. Edsko de Vries, Rinus Plasmeijer, and David Abrahamson, “Uniqueness Typing Redefined”, in Z. Horvath, V. Zsok, and Andrew Butterfield (Eds.): IFL 2006, LNCS 4449.

Free theorems are statements about program behavior 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. A recent application paper is “Bidirectionalization for Free!” (POPL’09). Also on the practical side, we maintain a library and tools for generating free theorems from Haskell types, originally implemented by Sascha Böhme. 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 involving those. A distinctive feature of the web-based tool is to export the generated theorems in PDF format. Joachim Breitner visited us in Dresden for two very productive weeks. Among other things, he implemented new post-simplifications for the free theorems generator, hopefully to be included in the web-based tool in the near future. He also wrote a web-based interface to the library from the POPL’09 paper, accessible at http://linux.tcs.inf.tu-dresden.de/~bff/cgi-bin/bff.cgi. Further reading http://wwwtcs.inf.tu-dresden.de/~voigt/project/

3.3.3 The Disciplined Disciple Compiler (DDC) Report by: Ben Lippmeier Status: alpha, active Disciple is an explicitly lazy dialect of Haskell which is being developed as part of my PhD project into effect typing, optimization, and methods for combining strict and lazy evaluation in the same language. Effect typing is offered as a practical alternative to state monads, and we suggest that state and destructive update are useful enough to deserve direct attention by the language and type system. Disciple’s type system is similar to that used in Haskell 98, with the addition of region, effect and closure information which is used to model the aliasing, side effect and data sharing properties of functions. This extra information is present in the source types, but can be fully reconstructed and does not usually place a burden on the programmer. The information is also present in DDC’s core language, and is used to guide code transformation style optimizations in the presence of side effects. When the type system proves that a particular expression is visibly pure, the full gamut of optimizations can be applied. The system also supports region, effect and closure class constraints which are modeled after the (value) type constraints of Haskell. A function’s type signature can use these constraints to require certain objects to be mutable, or certain function arguments to be pure. Disciple also supports type directed field projections (i.e., record syntax), and lazy code can be seamlessly integrated with strict code without changing the shape of types, or requiring explicit forcing by the programmer. DDC is in alpha release and comes with some cute example programs including a graphical n-body simulation, a collision detection demo, a ray-tracer, and some animated fractals. As I am currently writing up my PhD thesis, due end of December 2008, work on DDC has stalled for now. Development is likely to resume in 2nd quarter 2009. Although DDC is a full working system, it has been primarily a research vehicle so far and contains lots of cosmetic bugs. It is not yet “industrial strength”. DDC is open source and available from http://www.haskell.org/haskellwiki/DDC. If you would like to help out, then a detailed bug list is at http://code.google.com/p/disciple. There are many interesting lines of research in effect typing, the language is default strict, and if you squint it looks just like Haskell code.

4 Tools

4.1 Scanning, Parsing, Transformations

Alex is a lexical analyzer generator for Haskell, similar to the tool lex for C. Alex takes a specification of a lexical syntax written in terms of regular expressions, and emits code in Haskell to parse that syntax. A lexical analyzer generator is often used in conjunction with a parser generator, such as Happy (→4.1.2), to build a complete parser. The latest release is version 2.3, released October 2008. Alex is in maintenance mode, we do not anticipate any major changes in the near future. Changes in version 2.3 vs. 2.2: Works with GHC 6.10.1 and Cabal 1.6.

Support for efficient lexing of strict bytestrings, by Don Stewart.

The monadUserState wrapper type was added by Alain Cremieux. Further reading http://www.haskell.org/alex/

Happy is a tool for generating Haskell parser code from a BNF specification, similar to the tool Yacc for C. Happy also includes the ability to generate a GLR parser (arbitrary LR for ambiguous grammars). The latest release is 1.18.2, released 5 November 2008. Changes in version 1.18.2 vs. 1.17: Macro-like parameterized rules were added by Iavor Diatchki.

Works with GHC 6.10.1 and Cabal 1.6.

A couple of minor bugfixes: Happy does not get confused by Template Haskell quoted names in code, and a multi-word token type is allowed. Further reading Happy’s web page is at http://www.haskell.org/happy/. Further information on the GLR extension can be found at http://www.dur.ac.uk/p.c.callaghan/happy-glr/.

4.1.3 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 inherited and synthesized attributes, while keeping the full expressive power of Haskell. The generated tree walks are efficient in both space and time. New features are support for polymorphic abstract syntax and higher-order attributes. With polymorphic abstract syntax, the type of certain terminals can be parameterized. Higher-order attributes are useful to incorporate computed values as subtrees in the AST. The system is in use by a variety of large and small projects, such as the Haskell compiler EHC, the editor Proxima for structured documents, the Helium compiler (→2.4), the Generic Haskell compiler, and UUAG itself. The current version is 0.9.6 (April 2008), is extensively tested, and is available on Hackage. We are currently improving the documentation, and plan to introduce an alternative syntax that is closer to the Haskell syntax. Further reading http://www.cs.uu.nl/wiki/bin/view/HUT/AttributeGrammarSystem

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/uuagc-0.9.6

4.2 Documentation

Haddock is a widely used documentation-generation tool for Haskell library code. Haddock generates documentation by parsing the Haskell source code directly and including documentation supplied by the programmer in the form of specially-formatted comments in the source code itself. Haddock has direct support in Cabal (→5.1), and is used to generate the documentation for the hierarchical libraries that come with GHC, Hugs, and nhc98 (http://www.haskell.org/ghc/docs/latest/html/libraries). The latest release is version 2.2.2, released August 5 2008. Recent changes: Support for GHC 6.8.3

The Hoogle backend is back, thanks to Neil Mitchell.

Show associated types in the documentation for class declarations

Show associated types in the documentation for class declarations

Show type family declarations

Show type equality predicates

Major bug fixes (#1 and #44)

It is no longer required to specify the path to GHC’s lib dir

Remove unnecessary parenthesis in type signatures Future plans Currently, Haddock ignores comments on some language constructs like GADTs and Associated Type synonyms. Of course, the plan is to support comments for these constructs in the future. Haddock is also slightly more picky on where to put comments compared to the 0.x series. We want to fix this as well. Both of these plans require changes to the GHC parser. We want to investigate to what degree it is possible to decouple comment parsing from GHC and move it into Haddock, to not be bound by GHC releases. Other things we plan to add in future releases: Support for GHC 6.10.1

HTML frames (a la Javadoc)

Support for documenting re-exports from other packages Further reading Haddock’s homepage: http://www.haskell.org/haddock/

Haddock’s developer WiKi and Trac: http://trac.haskell.org/haddock

This tool by Ralf Hinze and Andres Löh is a preprocessor 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 inclusion 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 liberal 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 documents. Since the last report, version 1.14 has been released. This version is compatible with (and requires) Cabal 1.6. Apart from minor bugfixes, experimental support for typesetting Agda (→3.2.2) programs has been added. Further reading http://www.cs.uu.nl/~andres/lhs2tex

4.3 Testing, Debugging, and Analysis

SmallCheck is a one-module lightweight testing library. It adapts QuickCheck’s ideas of type-based generators for test data and a class of testable properties. But instead of testing a sample of randomly generated values, it tests properties for all the finitely many values up to some depth, progressively increasing the depth used. Among other advantages, existential quantification is supported, and generators for user-defined types can follow a simple pattern and are automatically derivable. Lazy SmallCheck is like SmallCheck, but generates partially-defined inputs that are progressively refined as demanded by the property under test. The key observation is that if a property evaluates to True or False for a partially-defined input then it would also do so for all refinements of that input. By not generating such refinements, Lazy SmallCheck may test the same input-space as SmallCheck using significantly fewer tests. Lazy SmallCheck’s interface is a subset of SmallCheck’s, often allowing the two to be used interchangeably. Since the last HCAR, we have written a paper about SmallCheck and Lazy SmallCheck and we have released versions 0.4 and 0.3 respectively on Hackage. We have also squashed a bug in the Hugs implementation of exception-handling which made Lazy SmallCheck sometimes report “Control stack overflow” (Hugs bug #84 ). And we have found a simple way to do demand-driven generation of (first-order) functions in Lazy SmallCheck, re-using the existing machinery for demand-driven generation of data. The next release of Lazy SmallCheck will incorporate this idea, and will hopefully support existential quantification too. We are still interested in improving and harmonizing the two libraries and welcome comments and suggestions from users. Further reading http://www.cs.york.ac.uk/fp/smallcheck/

4.3.2 EasyCheck Report by: Jan Christiansen Participants: Sebastian Fischer Status: experimental EasyCheck is an automatic test tool like QuickCheck or SmallCheck (→4.3.1). It is implemented in the functional logic programming language Curry (→3.2.1). Although simple test cases can be generated from nothing but type information in all mentioned test tools, users have the possibility to define custom test-case generators — and make frequent use of this possibility. Nondeterminism — the main extension of functional-logic programming over Haskell — is an elegant concept to describe such generators. Therefore it is easier to define custom test-case generators in EasyCheck than in other test tools. If no custom generator is provided, test cases are generated by a free variable which non-deterministically yields all values of a type. Moreover, in EasyCheck, the enumeration strategy is independent of the definition of test-case generators. Unlike QuickCheck’s strategy, it is complete, i.e., every specified value is eventually enumerated if enough test cases are processed, and no value is enumerated twice. SmallCheck also uses a complete strategy (breadth-first search) which EasyCheck improves w.r.t. the size of the generated test data. EasyCheck is distributed with the Kiel Curry System (KiCS). Further reading http://www-ps.informatik.uni-kiel.de/currywiki/tools/easycheck

4.3.3 checkers Report by: Conal Elliott Status: active development Checkers is a library for reusable QuickCheck properties, particularly for standard type classes (class laws and class morphisms). For instance, much of Reactive (→6.5.2) can be specified and tested using just these properties. Checkers also lots of support for randomly generating data values. For the past few months, this work has been graciously supported by Anygma. Further reading http://haskell.org/haskellwiki/checkers

4.3.4 CyCoTest Report by: Sebastian Fischer Participants: Herbert Kuchen Status: experimental The Curry Coverage Tester CyCoTest (pronounced like psycho test) aims at testing declarative programs to the bone. Unlike black-box test tools like QuickCheck, it does not generate test cases from type information or additional specifications. It rather uses the demand of the program under test to narrow test cases lazily. Narrowing is a generalization of reduction that allows to compute with partial information. Evaluating a program with narrowing and initially uninstantiated input binds the input as much as demanded by the computation and non-deterministically computes a corresponding result for each binding. The generated pairs of in- and output form a set of test cases that reflects the demand of the tested program. The generated set of test cases can either be checked by hand or using properties, i.e., functions with a Boolean result. Using properties is convenient, but sometimes it is hard to come up with a complete formal specification of the tested program. Hence, errors might remain undetected if an incomplete property is used to evaluate the test cases. In order to lower the burden of manual checking, we employ control- and data-flow coverage information to minimize the set of generated test cases. Test cases that do not cause new code coverage are considered redundant and need not be shown to the user. Although this bears the risk of eliminating test cases that expose a bug, experiments indicate that the employed coverage criteria suffice to expose bugs in practice. CyCoTest is implemented in and for the functional logic programming language Curry (→3.2.1), which provides narrowing for free. A Haskell implementation would be possible using ideas from the Kiel Curry System (KiCS), which translates Curry programs into Haskell programs. Further reading http://www-ps.informatik.uni-kiel.de/currywiki/tools/cycotest

4.3.5 Gforall st Report by: Peter Achten Participants: Pieter Koopman Status: stable, maintained Gforall st is a fully automatic test system, written in Clean (→3.2.3). Given a logical property, stated as a function, it is able to generate appropriate test values, to execute tests with these values, and to evaluate the results of these tests. In this respect Gforall st is similar to Haskell’s QuickCheck. Apart from testing logical properties, Gforall st is able to test state based systems. In such tests, an extended state machine (esm) is used instead of logical properties. This gives Gforall st the possibility to test properties in a way that is somewhat similar to model checking and allows you to test interactive systems, such as web pages or GUI programs. In order to validate and test the quality of the specifying extended state machine, the esmViz tool simulates the state machine and tests properties of this esm on the fly. Gforall st is based on the generic programming techniques of Clean which are very similar to Generic Haskell. Gforall st is distributed as a library in the standard Clean distribution. This version is somewhat older than the version described in recent papers. Future plans We would like to determine the quality of the tests for instance by determining the coverage of tests. As a next step we would like to use techniques from model checking to direct the testing based on esms in Gforall st. Further reading http://www.cs.ru.nl/~pieter/gentest/gentest.html

Papers on Gforall st: http://www.st.cs.ru.nl/Onderzoek/Publicaties/publicaties.html

4.3.6 Hat Report by: Olaf Chitil Participants: Malcolm Wallace Status: maintenance The Haskell tracing system Hat is based on the idea that a specially compiled Haskell program generates a trace file alongside its computation. This trace can be viewed in various ways with several tools. Some views are similar to classical debuggers for imperative languages, some are specific to lazy functional language features or particular types of bugs. All tools inter-operate and use a similar command syntax. Hat can be used both with nhc98 (→2.2) and GHC (→2.1). Hat was built for tracing Haskell 98 programs, but it also supports some language extensions (FFI, MPTC, fundeps, hierarchical libs). A tutorial explains how to generate traces, how to explore them, and how they help to debug Haskell programs. During the last year only small bug fixes were committed to the Darcs repository, but several other updates are also planned for the near future, including new and improved trace-browsers. A recent student project completed a Java-GUI viewer for traces, based on the idea of timelines and search. We hope this can be added to the repository soon. Further reading http://www.haskell.org/hat

darcs get http://darcs.haskell.org/hat

http://darcs.haskell.org/hat Tracing and Debugging Functional Programs: http://www.cs.kent.ac.uk/~oc/tracing.html

4.3.7 Concurrent Haskell Debugger Report by: Fabian Reck Participants: Frank Huch, Jan Christiansen Status: experimental Programming concurrent systems is difficult and error prone. The Concurrent Haskell Debugger is a tool for debugging and visualizing Concurrent Haskell and STM programs. By simply importing CHD.Control.Concurrent instead of Control.Concurrent and CHD.Control.Concurrent.STM instead of Control.Concurrent.STM the forked threads and their concurrent actions are visualized by a GUI. Furthermore, when a thread performs a concurrent action like writing an MVar or committing a transaction, it is stopped until the user grants permission. This way the user is able to determine the order of execution of concurrent actions. Apart from that, the program behaves exactly like the original program. An extension of the debugger can automatically search for deadlocks and uncaught exceptions in the background. The user is interactively led to a program state where a deadlock or an exception was encountered. To use this feature, it is necessary to use a simple preprocessor that comes with the package that is available at http://www.informatik.uni-kiel.de/~fre/chd/. Another purpose of the preprocessor is to enrich the source code with information for highlighting the next concurrent action in a source code view. Future plans provide a more powerful preprocessor that is able to process imported modules

add new views, like a visualization as a message sequence chart

allow to undo concurrent actions Further reading http://www.informatik.uni-kiel.de/~fre/docs/thesis.pdf (German diploma thesis)

http://www.informatik.uni-kiel.de/~jac/data/ICFP2004.pdf

4.3.8 Hpc Report by: Andy Gill Participants: Colin Runciman Status: released and used Haskell Program Coverage (HPC) is a set of tools for understanding program coverage. It consists of a source-to-source translator, an option ( -fhpc ) in ghc, a stand alone post-processor ( hpc ), a post-processor for reporting coverage, and an AJAX based interactive coverage viewer. Hpc has been remarkably stable over the lifetime of ghc-6.8, with only a couple of minor bug fixes, including better support for .hsc files. The source-to-source translator is not under active development, and is looking for a new home. The interactive coverage viewer, which was under active development in 2007 at Galois, has now been resurrected at Hpc’s new home in Kansas. Thank you Galois, for letting this work be released. The plan is to take the interactive viewer, and merge it with GHCi’s debugging API, giving an AJAX based debugging tool. Contact <andygill at ku.edu>

4.3.9 SourceGraph Report by: Ivan Lazar Miljenovic Status: Version 0.4 SourceGraph is a utility program aimed at helping Haskell programmers visualize their code and perform simple graph-based analysis (representing functions as nodes in the graphs and function calls as directed edges). To do so, it utilizes the Graphalyze library (→5.8.4), which is designed as a general-purpose graph-theoretic analysis library. These two pieces of software are the focus of Ivan’s mathematical honors thesis, “Graph-Theoretic Analysis of the Relationships Within Discrete Data”, and are both available from Hackage. Whilst fully usable, SourceGraph is currently limited in terms of input and output. It takes in the Cabal file of the project, and then analyzes all .hs and .lhs files recursively found in that directory. It utilizes Haskell-Src with Extensions, and should thus parse all extensions (with the current exception of Template Haskell, HaRP and HSX); files requiring C Pre-Processing are as yet unparseable, though this should be fixed in a future release. However, all functions defined in Class declarations and records are ignored due to difficulty in determining which actual instance is meant. The final report is then created in Html format in a “SourceGraph” subdirectory of the project’s root directory. Current analysis algorithms utilized include: alternative 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 example, it might recommend that you split up a module, because there are several distinct groupings of functions, when that module contains common utility functions that are placed together to form a library module (e.g., the Prelude). Further reading http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SourceGraph

http://code.haskell.org/SourceGraph

4.4 Development

Hoogle is an online Haskell API search engine. It searches the functions in the various libraries, both by name and by type signature. When searching by name, the search just finds functions which contain that name as a substring. However, when searching by types it attempts to find any functions that might be appropriate, including argument reordering and missing arguments. The tool is written in Haskell, and the source code is available online. Hoogle is available as a web interface, a command line tool, and a lambdabot (→6.12.2) plugin. Development of Hoogle was sponsored as part of the Google Summer of Code this year. As a result, a new version of Hoogle has been released with substantial speed and accuracy improvements. The next task is to generate Hoogle search information for all the libraries on Hackage. Further reading http://haskell.org/hoogle

4.4.2 Leksah, Haskell IDE Report by: Jürgen Nicklisch-Franken Status: in development Leksah is a Haskell IDE written in Haskell based on Gtk+ and gtk2hs (→5.11.1). Leksah is a practical tool to support the Haskell development process. It is platform independent and should run on any platform where GTK+, gtk2hs, and GHC can be installed. (It is currently being tested on Windows and Linux but it should work on the Mac. It only works with GHC.) There are compelling reasons for a Haskell IDE written in Haskell. First and most importantly, Haskell is different from mainstream imperative and object oriented languages and a dedicated IDE may exploit this specialness. Second the integration with an existing tool written in a different language has to solve the problem of integration of different programming languages/paradigms. Currently Leksah offers features like jumping to definition for a name, integration of Cabal (→5.1) for building, Haskell source editor with “source candy”, configurable keymaps, … This list will (hopefully) expand quickly. The development of Leksah started in June 2007 and the first alpha version was released February 2008. Contributions of all kind are welcome. Further reading http://leksah.org/

4.4.3 EclipseFP — Haskell support for the Eclipse IDE Report by: Leif Frenzel Status: alpha The Eclipse platform is an extremely extensible framework for IDEs, developed by an Open Source Project. Our project extends it with tools to support Haskell development. The aim is to develop an IDE for Haskell that provides the set of features and the user experience known from the Eclipse Java IDE (the flagship of the Eclipse project), and integrates a broad range of Haskell development tools. Long-term goals include support for language-aware IDE features, like refactoring and structural search. Over the past year, a new subproject called Cohatoe has developed a framework that allows us to implement Eclipse Plugins partly in Haskell. We are currently re-implementing and extending EclipseFP functionality in Haskell, using libraries such as Cabal (→5.1) and the GHC API (→2.1). Further reading http://eclipsefp.sf.net

http://leiffrenzel.de/eclipse/wiki/

http://lists.sourceforge.net/lists/listinfo/eclipsefp-develop

4.4.4 HEAT: The Haskell Educational Advancement Tool Report by: Olaf Chitil Heat is an interactive development environment (IDE) for learning and teaching Haskell. Using a separate editor and interpreter provides many distracting obstacles for inexperienced students learning a programming language; for example, they have to keep the versions in editor, interpreter, and in the file system in sync. Professional interactive development environments, however, confuse and distract with their excessive features. Hence Heat was designed for novice students learning the functional programming language Haskell. Based on teaching experience, Heat provides a small number of supporting features and is easy to use. Heat is portable, small, and works on top of the Haskell interpreter Hugs. Heat provides the following features: Editor for a single module with syntax-highlighting and matching brackets.

Shows the status of compilation: non-compiled; compiled with or without error.

Interpreter console that highlights the prompt and error messages.

If compilation yields an error, then the source line is highlighted and additional error explanations are provided.

Shows a program summary in a tree structure, giving definitions of types and types of functions …

Automatic checking of all (Boolean) properties of a program; results shown in summary. Heat is implemented in Java. The older version 1.1 which has been used in teaching functional programming at the University of Kent since 2006 is available from the webpage. Version 3.0 will be published very soon. Heat is implemented in Java. The older version 1.1 which has been used in teaching functional programming at the University of Kent since 2006 is available from the webpage. Version 3.0 will be published very soon. Further reading http://www.cs.kent.ac.uk/projects/heat/

The Haskell mode plugins for Vim offer some IDE-style functionality for editing Haskell code in Vim, including several insert mode completions (based on identifiers currently in scope, on identifiers documented in the central Haddock indices, on tag files, or on words appearing in current and imported sources), quickfix mode (call compiler, list errors in quickfix window, jump to error locations in source window), inferred type tooltips (persisted from last successful :make , so you can still see some types after introducing errors, or use types to guide editing, e.g., function parameter order), various editing helpers (insert import statement, type declaration or module qualifier for id under cursor, expand implicit into explicit import statement, add option and language pragmas, …), and direct access to the Haddock documentation for the id under cursor. The plugins are distributed as a simple vimball archive, including help file (after installation, try :help haskellmode ). They derive their functionality and semantic information from GHC/GHCi, from Haddock-generated documentation and indices (→4.2.1), and from Vim’s own configurable program editing support. For details of Haskell mode features, see the haskellmode.txt help file, for change log, see haskellmode-files.txt (for more general information, see Vim’s excellent built-in :help , or browse the help files online at http://vimdoc.sourceforge.net/htmldoc/usr_toc.html). These are not the only Haskell-related plugins for Vim — please add your own tricks and tips at haskell.org (syntax-coloring works out of the box, other scripts deal with indentation, …). The haskellmode plugins for Vim are currently in maintenance mode, with infrequent updates and bug fixes, and the occasional new feature or improvement of older code (please let me know if anything does not work as advertised!). Further reading Haskell Mode Plugins for Vim: http://www.cs.kent.ac.uk/~cr3/toolbox/haskell/Vim/

haskell.org section listing these and other Vim files: http://www.haskell.org/haskellwiki/Libraries_and_tools/Program_development#Vim

Yi is an editor written in Haskell and extensible in Haskell. We leverage the expressiveness of Haskell to provide an editor which is powerful and easy to extend. We have recently made Yi much more accessible. On Unix systems, it can be deployed using a single cabal install command. We also polished the user interface and behavior to facilitate the transition from emacs or vim. Yi features: Key-bindings for emacs and vim, written as extensible parsers;

Vty, Gtk2Hs frontends;

Syntax highlighting for Haskell and other languages;

XMonad-style static configuration;

Support of Linux, MacOS, and Windows platforms.

Special support for Haskell: layout-aware edition, paren-matching, GHCi interface, Cabal build interface, … We are currently working on the following fronts: Integration with Cabal and GHC API;

Pango and Cocoa frontends;

CUA key-bindings We are currently working on the following fronts: Further reading More information can be found at: http://haskell.org/haskellwiki/Yi

The source repository is available: darcs get http://code.haskell.org/yi/

Refactorings are source-to-source program transformations which change program structure and organization, but not program functionality. Documented in catalogs and supported by tools, refactoring provides the means to adapt and improve the design of existing code, and has thus enabled the trend towards modern agile software development processes. Our project, Refactoring Functional Programs, has as its major goal to build a tool to support refactorings in Haskell. The HaRe tool is now in its fourth major release. HaRe supports full Haskell 98, and is integrated with Emacs (and XEmacs) and Vim. All the refactorings that HaRe supports, including renaming, scope change, generalization and a number of others, are module aware, so that a change will be reflected in all the modules in a project, rather than just in the module where the change is initiated. The system also contains a set of data-oriented refactorings which together transform a concrete data type and associated uses of pattern matching into an abstract type and calls to assorted functions. The latest snapshots support the hierarchical modules extension, but only small parts of the hierarchical libraries, unfortunately. In order to allow users to extend HaRe themselves, HaRe includes an API for users to define their own program transformations, together with Haddock (→4.2.1) documentation. Please let us know if you are using the API. HaRe 0.4, which was released earlier this year, only compiles with GHC 6.6.1 and GHC 6.8.2. New refactorings in HaRe 0.4 include a suite of slicing utilities, adding/removing a data constructor, converting a data type into a newtype, adding/removing a field, etc. Snapshots of HaRe are available from our webpage, as are related presentations and publications from the group (including LDTA’05, TFP’05, SCAM’06, PEPM’08, and Huiqing’s PhD thesis). The final report for the project appears there, too. Recent developments More structural and datatype-based refactorings have been studied by Chris Brown, including transformation between let and where , generative folding, introducing pattern matching, and introducing case expressions;

and , generative folding, introducing pattern matching, and introducing case expressions; Chris has also been looking into duplicated code detection and elimination support for Haskell programs as part of his PhD research;

Chaddai Fouche started to work on the porting of HaRe to GHC API (→2.1) during the summer; this work is ongoing. Further reading http://www.cs.kent.ac.uk/projects/refactor-fp/

DarcsWatch is a tool to track the state of Darcs (→6.1.1) patches that have been submitted to some 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. During the last six months, development activity has been low, but DarcsWatch has been successfully used in the xmonad project (→6.1.2) to review unapplied and possibly forgotten patches before a release. Still, a good way to easily mark patches as obsolete or retracted has to be found. Further reading http://darcswatch.nomeata.de/

http://darcs.nomeata.de/darcswatch/documentation.html

Cpphs is a robust drop-in Haskell replacement for the C pre-processor. It has a couple of benefits over the traditional cpp — you can run it when no C compiler is available (e.g., on Windows); and it understands the lexical syntax of Haskell, so you do not get tripped up by C-comments, line-continuation characters, primed identifiers, and so on. (There is also a pure text mode which assumes neither Haskell nor C syntax, for even greater flexibility.) Cpphs can also unliterate .lhs files during preprocessing, and you can install it as a library to call from your own code, in addition to the stand-alone utility. The current release is 1.6: recent bugfixes have been small — the major changes are to add new command-line options –include and –strip-eol . Further reading http://haskell.org/cpphs

5 Libraries

Background Cabal is the Common Architecture for Building Applications and Libraries. It defines a common interface for defining and building Haskell packages. It is implemented as a Haskell library and associated tools which allow developers to easily build and distribute packages. Hackage is an online database of Cabal packages which can be interactively queried via the website and client-side software such as cabal-install. Hackage enables end-users to download and install Cabal packages. cabal-install is the command line interface for the Cabal and Hackage system. It provides a command line program cabal which has sub-commands for installing and managing Haskell packages. Recent progress Since the last HCAR we have released Cabal-1.4 and 1.6. There have also been releases of cabal-install which is now at version 0.6. The Cabal-1.4 and 1.6 releases contained a number of incremental improvements but nothing earth-shattering. Cabal-1.4 contained the bulk of the improvements but remained compatible with Cabal-1.2. The 1.6 release comes with GHC 6.10 and contains some new features that are not backwards compatible. The cabal-install tool has matured significantly since the last report and is now mostly usable for many users. It replaces runhaskell Setup.hs which had been the primary interface for most users previously. The major advantage is that it simplifies the process of downloading and installing collections of inter-dependent packages from Hackage. Hackage is getting near to its second birthday. At the time of writing, 234 users have uploaded 2306 versions of 820 packages. This represents a substantial amount of Haskell code and indeed a substantial amount of code re-use. In the next few months we expect to upgrade Hackage with a new implementation. There should be no disruption for users or package maintainers. The new implementation uses HAppS rather than Apache+CGI. The main reason for the change is to make it easier to add the new features that users have been asking for. We also expect it will have a new layout and appearance thanks to the talented people from Tupil (→7.8). We are also hoping to use Hoogle (→4.4.1) as the primary search interface. Google Summer of Code projects Andrea Vezzosi completed his project to build a “make-like” dependency framework for the Cabal library. Part of this can now be integrated to make Cabal work better with pre-processors. To make development easier, Andrea started on an external hbuild tool. The aim is to improve it, demonstrate it on real projects, and eventually replace much of the Cabal internals. One remaining challenge is to develop some high level combinators for the dependency infrastructure. Neil Mitchell completed his project on Hoogle 4 (→4.4.1). As mentioned above, the next step is to use it in the new Hackage server. Looking forward There is huge potential for Hackage to help us manage and improve the community’s package collection. cabal-install is now able to report build results and the new Hackage server implementation can accept them. This should provide us with a huge amount of data on which packages work in which environments and configurations. More generally there is the opportunity to collect all sorts of useful metrics on the quality of packages. As for Cabal, it now has the feature-set that enables it to support the vast majority of simple packages. The next challenge is large existing projects which have more complex requirements for a configuration and build system. Now may be the time to take a step back and discuss a new design document for Cabal 2.0. People We would like to thank the people who contributed to the last round of development work. Thanks also to the people who have followed development and reported bugs and feature requests. We have ambitious plans and there is plenty of work to do, but not quite enough volunteer time to do it all. Now would be an excellent time to get involved in this central piece of the Haskell infrastructure. Further reading Cabal homepage: http://www.haskell.org/cabal

Hackage package collection: http://hackage.haskell.org/

Bug tracker: http://hackage.haskell.org/trac/hackage/

5.2 Haskell Platform Report by: Duncan Coutts Background The Haskell Platform (HP) is the name of a new “blessed” set of libraries and tools on which to build further Haskell libraries and applications. It takes the best packages from the over 800 on Hackage (→5.1). It is intended to provide a comprehensive, stable, and quality tested base for Haskell projects to work from. Historically, GHC has shipped with a collection of packages under the name extralibs . The intention in future is for GHC to get out of the business of shipping an entire platform and for this role to be transferred to the Haskell Platform. Looking forward We expect the first release of the platform to come out a few weeks after the release of GHC-6.10.1 (→2.1). Subsequent releases will be on a 6 month schedule. The first release will contain just the packages from the old extralibs collection, plus cabal-install (→5.1). We are looking for involvement from the community to decide what procedures we should use and what level of quality we should demand for new additions to the platform. The discussion will take place on the libraries@haskell.org mailing list. Further reading http://haskell.org/haskellwiki/Haskell_Platform

5.3 Auxiliary Libraries

libmpd is a client implementation of the MPD music playing daemon’s network protocol. The interface has mostly stabilized and is usable. In version 0.3.1 some bugs have been addressed to fix the automatic reconnection feature and to be more permissive with data from the server. Further reading The development web page is at http://turing.une.edu.au/~bsinclai/code/libmpd-haskell/ and MPD can be found at http://www.musicpd.org/.

5.3.2 gravatar Report by: Don Stewart Status: active development Gravatars (http://gravatar.com) are globally unique images associated with an email address, widely used in social networking sites. This library lets you find the URL of a gravatar image associated with an email address. Further reading Source and documentation can be found on Hackage.

The source repository is available: darcs get http://code.haskell.org/~dons/code/gravatar/

5.3.3 mersenne-random Report by: Don Stewart Status: active development The Mersenne twister is a pseudorandom number generator developed by Makoto Matsumoto and Takuji Nishimura that is based on a matrix linear recurrence over a finite binary field. It provides for fast generation of very high quality pseudorandom numbers. This library uses SFMT, the SIMD-oriented Fast Mersenne Twister, a variant of Mersenne Twister that is much faster than the original. It is designed to be fast when it runs on 128-bit SIMD. It can be compiled with either SSE2 OR PowerPC AltiVec support, to take advantage of these instructions. By default the period of the function is 219937-1, however, you can compile in other defaults. Note that this algorithm on its own is not cryptographically secure. Further reading Source and documentation can be found on Hackage.

The source repository is available: darcs get http://code.haskell.org/~dons/code/mersenne-random/

5.3.4 cmath Report by: Don Stewart Status: active development cmath is a complete, efficient binding to the standard C math.h library, for Haskell. Further reading Source and documentation can be found on Hackage.

The source repository is available: darcs get http://code.haskell.org/~dons/code/cmath/

This library provides a purely functional interface to linear algebra and other numerical computations, internally implemented using GSL, BLAS, and LAPACK. The most common matrix computations are already available: eig, svd, chol, qr, hess, schur, lu, pinv, expm, etc. There are also functions for numeric integration and differentiation, nonlinear minimization, polynomial root finding, and many GSL special functions. The latest stable version can be found on Hackage. Recent developments include low level optimizations contributed by Don Stewart and safe in-place updates using the ST monad. Further reading http://www.hmatrix.googlepages.com

As part of his master thesis work, Peter van Keeken implemented a library to data mine logged Helium (→2.4) programs to investigate aspects of how students program Haskell, how they learn to program, and how good Helium is in generating understandable feedback and hints. The software can be downloaded from http://www.cs.uu.nl/wiki/bin/view/Hage/Neon, which also gives some examples of output generated by the system. The downloads only contain a small sample of