Haskell Communities and Activities Report

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

The #haskell IRC channel is a real-time text chat where anyone can join to discuss Haskell. The channel has continued to grow in the last six months, now averaging around 420 users, with a record 479 users (up from 436 six months ago). It is one of the largest channels on freenode. The irc channel is home to hpaste and lambdabot (→6.8.1), 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
• #haskell.dut – Dutch speakers
• #haskell.es – Spanish speakers
• #haskell.fi – Finnish speakers
• #haskell.fr – French speakers
• #haskell.hr – Croatian speakers
• #haskell.it – Italian speakers
• #haskell.jp – Japanese speakers
• #haskell.no – Norwegian speakers
• #haskell_ru – Russian speakers
• #haskell.se – Swedish speakers

Related Haskell channels are now emerging, including:

• #haskell-overflow – Overflow conversations
• #haskell-blah – Haskell people talking about anything except Haskell itself
• #gentoo-haskell – Gentoo/Linux specific Haskell conversations (→2.6.1)
• #haskell-books – Authors organising the collaborative writing of the Haskell Wikibook (→1.6.3)
• #darcs – Darcs revision control channel (→6.1.1)
• #ghc – GHC developer discussion (→2.1)
• #happs – HAppS Haskell Application Server channel
• #xmonad – XMonad, a tiling window manager (→6.1.2)

Further reading

http://haskell.org/haskellwiki/IRC_channel

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 the last HCAR, 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

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 (→1.5), and via RSS. Headlines are published on haskell.org (→1.1).

Further reading

http://www.haskell.org/haskellwiki/Haskell_Weekly_News

Planet Haskell is an aggregator of Haskell people’s blogs and other Haskell-related news sites. As of April 2008 content from 92 blogs and other sites is being republished in a common format.

A common misunderstanding about Planet Haskell is that it republishes only Haskell content. That is not its mission. A Planet shows what is happening in the community, what people are thinking about or doing. Thus Planets tend to contain a fair bit of “off-topic” material. Think of it as a feature, not a bug.

For information on how to get added to Planet, please read http://planet.haskell.org/policy.html.

Further reading

http://planet.haskell.org/

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 fully compliant with the latest Haskell release.

Publication details:

• Published by Cambridge University Press, 2007. Paperback: ISBN 0521692695; Hardback: ISBN: 0521871727; eBook: ISBN 051129218X.

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 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 marvellous ideas of lazy functional programming can and thus should be accessible to everyone in a central place.

Since the last report, 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>

Most of the original GTK+2.0 tutorial by Tony Gail and Ian Main has been adapted to Gtk2Hs (→5.8.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/

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

The collection of various Haskell mini tutorials and assorted small projects (http://okmij.org/ftp/Haskell/) has received three additions:

Binary type arithmetic

With Chung-chieh Shan we introduce a type-level Haskell library for arbitrary precision binary arithmetic over natural kinds. The numerals are specified in the familiar big-endian bit notation. The library supports addition/subtraction, predecessor/successor, multiplication/division, exp2, all comparisons, GCD, and the maximum. At the core of the library are multi-mode ternary relations Add and Mul where any two arguments determine the third. Such relations are especially suitable for specifying static arithmetic constraints on computations. The type-level numerals have no run-time representation; correspondingly, all arithmetic operations are done at compile time and have no effect on run-time.

Two applications of the library for safe system programming are described in the next item.

http://okmij.org/ftp/Haskell/types.html#binary-arithm

Typed memory areas and time-parameterised monads, for safe embedded and systems programming

We argue that Haskell as supported by GHC today can be used for safe system programming, statically assuring safe handling of raw memory pointers, device registers, and other low-level resources. Safety is assured by the type system and has no run-time overhead. We demonstrate two extensive examples: (i) one built around raw pointers, to track and arbitrate the size, alignment, write permission, and other properties of memory areas in the presence of indexing, casting, and iteration; (ii) the other built around a device register, to enforce protocol and timing requirements while reading from the register.

We also demonstrate custom kinds and predicates; type-level numbers, functions, and records; and mixed type- and term-level programming.

http://okmij.org/ftp/Haskell/types.html#ls-resources

Polymorphic variants: solving the expression problem

There have been several proposals for Haskell extensions to support open polymorphic variants, i.e., extensible recursive open sum datatypes similar to polymorphic variants of OCaml. We demonstrate that Haskell as it is — the HList library (→5.5.5) — already supports polymorphic variants, with automatic variant subtyping. HList thus solves the familiar (in OO, at least) “expression problem” — the ability to add new alternatives to a datatype and extend old processing functions to deal with the extended variant, maximally reusing old code without changing it.

Our polymorphic variants are literally open co-products: dual of, literally negated extensible polymorphic records of HList. Our encoding of sums is the straightforward Curry-Howard image of the DeMorgan law of the negation of disjunction.

Our implementation of polymorphic variants in terms of HList records uses no type classes, no type-level programming or any other type hacking. In fact, there are no type annotations, type declarations or any other mentioning of types, except in the comments. The code is included in the HList library.

http://okmij.org/ftp/Haskell/generics.html#PolyVariant

The last six months have been a time of consolidation for GHC. We have done many of the things described in the last HCAR, but there are few new headline items to report, so this status report is briefer than usual.

Highlights of the last six months

• Several simple language extensions are now solidly in the HEAD.
  • Record syntax: wild-card patterns, punning, and field disambiguation

  • View patterns
  • Generalised list comprehensions

  • Quasi-quoting

• Type-indexed families. We learned a lot by writing a paper about the question of type inference in the presence of type families (and existentials, and GADTs): http://research.microsoft.com/~simonpj/papers/assoc-types. The implementation has not quite caught up with the paper and is still incomplete in many ways, but it is a focus of active work and already usable. If you are interested in type families, now would be a good time to grab a development snapshot of GHC, write some programs or port your favourite program using functional dependencies, and then, let us know what does and what does not work for you.

• Parallel garbage collection. Much implementation work, and a paper for ISMM 2008: http://research.microsoft.com/~simonpj/papers/parallel-gc/index.htm.

• Impredicative polymorphism. We are not happy with GHC’s current implementation of impredicative polymorphism, which is rather complicated and ad hoc. Dimitrios (with Simon and Stephanie) wrote a paper about a new and better approach: http://research.microsoft.com/~simonpj/papers/boxy. At the same time, Daan Leijen has been working on his closely-related design: http://research.microsoft.com/users/daan/pubs.html. Daan’s design has a much simpler implementation, in exchange for an (arguably) less-predictable specification. Which of these two should we implement? Let us know!

• External Core. Tim Chevalier has updated the External Core format to incorporate type equality coercions and other recent GHC changes, as well as extending the stand-alone External Core tools (a parser, typechecker, and interpreter that can be built separately from GHC) to handle this new format. As of now, it is only possible to use GHC’s front-end to pipe External Core into other back-end tools — GHC still cannot read in External Core that was produced by other tools (or itself). But this is an improvement over the bit-rotted state into which External Core had fallen. Aaron Tomb contributed much to this effort as well.

Nested data parallelism

We have been working hard on Data Parallel Haskell, especially Roman Leshchinskiy and Gabriele Keller. It has turned out be be hard to get the entire transformation and optimisation stack to work smoothly, and we have not made progress announcements because we do not want to yell about it until it Actually Works. But it is the biggest single GHC focus: Roman works on it full time.

Large parts of the major pieces are in place. GHC contains a shiny new vectoriser that turns scalar into data-parallel functions. Moreover, the sequential and parallel array libraries targeted by the vectoriser have been steadily growing. We managed to successfully run small applications, such as an n-body simulator based on the Barnes-Hut algorithm, but the vectoriser and library are still awkward to use and need to be more robust before being useful to a wider audience. We also need to improve performance.

We expect to release a working version of Data Parallel Haskell as part of GHC 6.10 (see below).

Other current activities

• Max Bolingbroke resurrected the static argument transformation. It does not matter for most programs, but has a big effect on a few.

• Work on the back end has been stalled, but John Dias started a 6-month internship in April, so expect progress on this front.

• Thomas Schilling is doing a Google Summer of Code project to improve the GHC API.
• Max Bolingbroke is doing a Google Summer of Code project to make it easy to build a plug-in for GHC; for example, a new optimisation or analysis pass.

Release plans

We plan to release GHC 6.8.3 at the end of May 2008, with many bug-fixes but no new features.

We plan to release GHC 6.10 around the time of ICFP, with significant new features. The up-to-date list of new stuff is kept at http://hackage.haskell.org/trac/ghc/wiki/Status/Releases, but here’s a quick summary:

• Simple language extensions (mentioned above)

• Type-indexed families

• Data Parallel Haskell

• Parallel garbage collection

• Extensible exceptions

• External Core

• Shared libraries

• Improved back end

• Further library reorganisation

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.5) 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.

Since the last HCAR there have been a number of projects making use of the Yhc.Core library. Of particular interest is the Javascript backend, which has reached its first milestone. An experimental Yhc web service has been launched, to allow people to experiment with the Javascript 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 standardised, 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.2.7)).

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 optimise function unfolding. 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.

See the URL below for details and results. Since the last HCAR, I have written a thesis chapter about it, with all the gory details unveiled! Further experiments are planned.

Further reading

http://www.cs.york.ac.uk/~mfn/reduceron2/

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.

Haskell support on OpenBSD is now taken over by Matthias Kilian, who has updated GHC and related tools for this platform. OpenBSD support for the GHC head branch continues.

Further reading

http://ports.openbsd.nu/lang/ghc/

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

• A major revision of the parallel runtime environment for GHC 6.8 is currently under development. The GpH and Eden (→3.1.3) parallel Haskells share much of the implementation technology and both are being used for parallel language research and in the SCIEnce project (see below).

• We are exploring the use of GpH on multicore architectures.

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

GpH Applications

• As part of the SCIEnce EU FP6 I3 project (026133) (→8.7) (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 (→8.6) at Brooklyn College, with a first version available on request from Murray Gross.

Further reading

• GpH homepage: 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>

Description

Eden has been jointly developed by two groups at Philipps-Universität Marburg, Germany, and Universidad Complutense de Madrid, Spain. The project has been ongoing since 1996. Currently, the team consists of the following people:

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), synchronisation, 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 parallelise 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 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.

Recent and Forthcoming Publications

• Jost Berthold: Implicit and Explicit Parallel Functional Programming: Concepts and Implementation, Dissertation (PhD thesis), Fachbereich Mathematik und Informatik, Philipps-Universitat Marburg, April 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, March 2008, in Spanish.

• Mischa Dieterle, Jost Berthold, and Rita Loogen: Functional Implementation of a Distributed Work Pool Skeleton, submitted.

• 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, to appear.

• Abdallah Al Zain, Phil Trinder, Jost Berthold, Rita Loogen, Kevin Hammond, and Hans-Wolfgang Loidl: Parallel Functional Middleware for Computational Algebra Systems, Draft Proceedings of the Symposium on Trends In Functional Programming (TFP), Radboud Universiteit Nijmegen, May 2008.

• Mercedes Hidalgo-Herrero and Yolanda Ortega-Mallen: Calculational Reasoning for Parallel Functional Programming, Draft Proceedings of the Symposium on Trends In Functional Programming (TFP), Radboud Universiteit Nijmegen, May 2008.

• Oleg Lobachev, Jost Berthold, Mischa Dieterle, and Rita Loogen: Parallel FFT Using Divide and Conquer Skeletons, Draft Proceedings of the Symposium on Trends In Functional Programming (TFP), Radboud Universiteit Nijmegen, May 2008.

• Jost Berthold, Mischa Dieterle, Rita Loogen, and Steffen Priebe: Hierarchical Master-Worker Skeletons, Practical Aspects of Declarative Languages (PADL) 08, LNCS 4902, Springer 2008.

• Jost Berthold, Abyd Al-Zain, and Hans-Wolfgang Loidl: Adaptive High-Level Scheduling in a Generic Parallel Runtime Environment, Practical Aspects of Declarative Languages (PADL) 08, LNCS 4902, Springer 2008.

• Jost Berthold and Rita Loogen: Visualising Parallel Functional Program Runs - Case Studies with the Eden Trace Viewer, Parallel Computing: Architectures, Algorithms and Applications, Proceedings of the International Conference ParCo 2007, IOS Press 2007.

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

We have fully implemented the system, which can be used in combination with the Glasgow Haskell Compiler. We have taken care to provide meaningful type error messages in case the static checking of programs fails. Our system also allows to defer some static checks until run-time.

We make use of GHC-as-a-library so that the XHaskell programmer can easily integrate her programs into existing applications and take advantage of the many libraries available in GHC. We also provide a convenient interface to the HaXML (→5.10.3) parser.

Kenny’s thesis will be available shortly, describing in detail the formal underpinnings behind XHaskell.

In this project, we extend Haskell with Erlang-style actors and Join-calculus style concurrency primitives. The HaskellJoin extension is described in an IFL’07 paper. See for details: http://taichi.ddns.comp.nus.edu.sg/taichiwiki/HaskellJoinRules.

The HaskellActor extension is described in a forthcoming COORDINATION’08 paper. The implementation can be downloaded via http://code.google.com/p/haskellactor/

Latest developments

We are currently working on revising the HaskellJoin implementation.

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 parameterised 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 (effects, 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:

• A simple foreign function interface, which allows use of Haskell functions in Agda code.
• The libraries are steadily increasing in size.

Further reading

The Agda Wiki: http://www.cs.chalmers.se/~ulfn/Agda/

Epigram is a prototype dependently typed functional programming language, equipped with an interactive editing and typechecking environment. High-level Epigram source code elaborates into a dependent type theory based on Zhaohui Luo’s UTT. The definition of Epigram, together with its elaboration rules, may be found in “The view from the left” by Conor McBride and James McKinna (JFP 14 (1)).

A new version, Epigram 2, based on Observational Type Theory (see “Observational Equality, Now!” by Thorsten Altenkirch, Conor McBride, and Wouter Swierstra) is in preparation.

Motivation

Simply typed languages have the property that any subexpression of a well typed program may be replaced by another of the same type. Such type systems may guarantee that your program will not crash your computer, but the simple fact that True and False are always interchangeable inhibits the expression of stronger guarantees. Epigram is an experiment in freedom from this compulsory ignorance.

Specifically, Epigram is designed to support programming with inductive datatype families indexed by data. Examples include matrices indexed by their dimensions, expressions indexed by their types, search trees indexed by their bounds. In many ways, these datatype families are the progenitors of Haskell’s GADTs, but indexing by data provides both a conceptual simplification — the dimensions of a matrix are numbers — and a new way to allow data to stand as evidence for the properties of other data. It is no good representing sorted lists if comparison does not produce evidence of ordering. It is no good writing a type-safe interpreter if one’s typechecking algorithm cannot produce well-typed terms.

Programming with evidence lies at the heart of Epigram’s design. Epigram generalises constructor pattern matching by allowing types resembling induction principles to express as how the inspection of data may affect both the flow of control at run time and the text and type of the program in the editor. Epigram extracts patterns from induction principles and induction principles from inductive datatype families.

History

James McKinna and Conor McBride designed Epigram in 2001, whilst based at Durham, working with Zhaohui Luo and Paul Callaghan. McBride’s prototype implementation of the language, “Epigram 1” emerged in 2004: it is implemented in Haskell, interfacing with the xemacs editor. This implementation effort involved inventing a number of new programming techniques which have found their way into the Haskell community at large: central components of Control.Applicative and Data.Traversable started life in the source code for Epigram.

Following the Durham diaspora, James McKinna and Edwin Brady went to St. Andrews, where they continued their work on phase analysis and efficient compilation of dependently typed programs. More recently, with Kevin Hammond, they have been studying applications of dependent types to resource-aware computation in general, and network protocols in particular.

Meanwhile, Conor McBride went to Nottingham to work with Thorsten Altenkirch. They set about redesigning Epigram’s underlying type theory, radically changing its treatment of logical propositions in general, and equality in particular, making significant progress on problems which have beset dependent type theories for decades.

The Nottingham duo grew into a strong team of enthusiastic researchers. Peter Morris successfully completed a PhD on generic programming in Epigram and is now a research assistant: his work has led to the redesign of Epigram’s datatype language. Nicolas Oury joined from Paris as a postdoctoral research fellow, and is now deeply involved in all aspects of design and implementation. PhD students James Chapman and Wouter Swierstra are working on Epigram-related topics, studying formalised metatheory and effectful programming, respectively. Meanwhile, Nottingham research on containers, involving Neil Ghani, Peter Hancock, and Rawle Prince, together with the Epigram team, continues to inform design choices as the language evolves.

Epigram 1 was used successfully by Thorsten Altenkirch, Conor McBride, and Peter Hancock in an undergraduate course on Computer Aided Formal Reasoning http://www.e-pig.org/darcs/g5bcfr/. It has also been used in a number of graduate-level courses.

James McKinna is now at Radboud University, Nijmegen; Edwin Brady is still at St. Andrews; Thorsten Altenkirch, Peter Morris, Nicolas Oury, James Chapman, and Wouter Swierstra are still in Nottingham; Conor McBride has left academia. All are still contributing to the Epigram project.

Current Status

Epigram 2 is based on a radical redesign of our underlying type theory. The main novelties are

• a bidirectional approach to typechecking, separating syntactically the terms whose types are inferred from those for which types are pushed in — with stronger guarantees of prior type information, we can reduce clutter in terms and support greater overloading;
• explicit separation of propositions and sets, ensuring that proofs never influence control-flow and can be erased at run-time;
• a type-directed approach to propositional equality, comparing functions extensionally, records componentwise, data by construction, and proofs trivially — we shall soon support equality for codata by bisimulation and for quotients by whatever you want;
• three closed universes of data structures, finite enumerations, record types, and inductive datatypes, each with its datatype of type descriptions — this supports generic programming over all of Epigram 2’s data structures and removes the need for any means of “making new stuff” other than definition.

Nicolas Oury, Peter Morris, and Conor McBride have implemented this theory, together with a system supporting interactive construction (and destruction) within it. This the engine which will drive Epigram 2: we plan to equip it with human-accessible controls and release it for the benefit of the curious, shortly. With this in place, we shall reconstruct the Epigram source language and its elaboration mechanism: constructs in source become constructions in the core.

There is still a great deal of work to do. We need to incorporate the work from Edwin Brady and James McKinna on type erasure and efficient compilation; we need to bring out and exploit the container structure of data; we need to support programming with effects (including non-termination); we need a declarative proof language, as well as a functional programming language.

The Epigram project relies on Haskell, its libraries, and tools such as Alex (→4.1.1), Happy (→4.1.2), bnfc, Cabal (→5.1), and Darcs (→6.1.1). We have recently developed tools for assembling the modules corresponding to each component of the Epigram system from files corresponding to each feature of the Epigram language: this may prove useful to others, so we hope to clean them up and release them. Meanwhile, as Haskell itself edges ever closer to dependent types, the Epigram project has ever more to contribute, in exploration of the design space, in the development of implementation technique, and in experimentation with the pragmatics of programming with such power and precision.

Epigram source code and related research papers can be found on the web at http://www.e-pig.org and its community of experimental users communicates via the mailing list <epigram at durham.ac.uk>. The current, rapidly evolving state of Epigram 2 can be found at http://www.e-pig.org/epilogue/.

An important feature of pure functional programming languages is referential transparency. A consequence of referential transparency is that functions cannot 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 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 generalised algebraic data types (GADTs) can easily be incorporated.

Although our type system is developed in the context of the language 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, Rinus Plasmeijer, and David Abrahamson, “Uniqueness Typing Simplified”, in Proceedings of IFL 2007 (to appear in the LNCS series).
• 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 behaviour derived from (polymorphic) types. Their origin is the polymorphic lambda-calculus, but they have also been applied to programs in more realistic languages like Haskell. Since there is a semantic gap between the original calculus and modern functional languages, the underlying theory (of relational parametricity) needs to be refined and extended. We aim to provide such new theoretical foundations, as well as to apply the theoretical results to practical problems. Recent papers concerning program transformations are “Semantics and Pragmatics of New Shortcut Fusion Rules” (FLOPS’08) and “Asymptotic Improvement of Computations over Free Monads” (MPC’08).

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 now available from Hackage (as free-theorems-0.2 and ftshell-0.2, 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 specialisations down to function level

• support for algebraic data types, type synonyms and renamings, type classes

Further reading

http://wwwtcs.inf.tu-dresden.de/~voigt/project/

Alex is a lexical analyser 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 analyser 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.2, released November 2007. Alex is in maintenance mode, we do not anticipate any major changes in the near future.

Changes in version 2.2:

• ByteString wrappers: use Alex to lex ByteStrings (→5.5.1) directly.

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.17, released 22 October 2007.

Changes in version 1.17:

• Works with GHC 6.8.x, and requires Cabal 1.2.
• Fix serious mistake in error handling (the “parE” bug)
• Some performance improvements to Happy itself

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/.

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.1.0, released May 1 2008.

Changes since the 0.9 release:

• As a result of a Google Summer of Code project, Haddock now uses the GHC API (→2.1) as its front end. This means that Haddock can process any GHC-compatible Haskell code.

Changes since the 0.8 release:

• Thanks to Neil Mitchell, the index page generated by Haddock now has a search box, and the list is dynamically updated as you type.

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.

Further reading

• There is a TODO list of outstanding bugs and missing features, which can be found here: http://code.haskell.org/haddock/TODO

• Haddock’s homepage is here: http://www.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 customisable 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.13 has been released. It is compatible with GHC 6.8 and Cabal 1.2, but not yet with development versions of Cabal. Maintenance will continue in the future, releases will appear as needed. No major development is planned at the moment, although I have some vague ideas for substantial improvement.

Further reading

• http://www.cs.uu.nl/~andres/lhs2tex
• https://svn.cs.uu.nl:12443/viewcvs/lhs2TeX/lhs2TeX/trunk/

Lazy SmallCheck is a library for testing program properties. Unlike QuickCheck and SmallCheck (→4.3.1), it 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.

A talk about Lazy SmallCheck was given at Fun in the Afternoon York, and the slides are available, along with an initial implementation, at the URL below. Since the last HCAR, we have made a simpler implementation, now supporting Fredrik’s parallel conjunction operator. The problem with a sequential conjunction is that, when applied to a partially-defined input, it will crash (i.e., demand more input than is given) if the first conjunct crashes, even if the second conjunct is falsified. A parallel conjunction, in contrast, is falsified if any conjunct is falsified, even if the other conjucts crash. This increases pruning opportunities, and “when used, one is not obliged to tweak the order of conjuncts in the property” (Fredrik Lindblad, TFP 2007).

Support for existential quantifiers and function generation a la SmallCheck is under consideration. A new release will hopefully be made sometime during the year.

Further reading

http://www.cs.york.ac.uk/~mfn/lazysmallcheck/

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 half 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

• Tracing and Debugging Functional Programs: http://www.cs.kent.ac.uk/~oc/tracing.html

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.8.1) plugin.

The development of Hoogle has been slow lately, due to the author writing a PhD thesis. However, this summer Hoogle will become a full-time project with funding from the Google Summer of Code. Expect to see Hoogle v4.0 before the summer is over.

Further reading

http://haskell.org/hoogle

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). The goal is to release a new version, EclipseFP 2, this summer.

Further reading

• http://eclipsefp.sf.net
• http://leiffrenzel.de/eclipse/wiki/
• http://lists.sourceforge.net/lists/listinfo/eclipsefp-develop

Yi is a project to write a Haskell-extensible editor. Yi is structured around a purely functional editor core, such that most components of the editor can be overridden by the user, using configuration files written in Haskell.

Yi has been converted to the Cabal build system, which makes it easier to build and experiment with.

Yi features:

• Keybindings for emacs and vim, written as extensible parsers;
• Vty and Gtk2Hs frontends;
• Syntax highlighting for Haskell and other languages;
• XMonad-style static configuration;
• Support of Linux, MacOS, and Windows platforms.

• Integration with Cabal and GHC API;
• Syntax-aware support of Haskell;
• Pango, cocoa frontends

Further reading

• Documentation 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 organisation, but not program functionality. Documented in catalogues 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, generalisation, 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. An informal release of HaRe 0.4 that was recently released works with GHC 6.6.1 and GHC 6.8.2, but not GHC 6.4; earlier releases work with 6.4.*.

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.

There have been some recent developments for adding program slicing techniques to HaRe. These techniques include a refactoring to split functions returning tuples into separate definitions, and to also put them back together again. A number of new data-type based and structural refactorings have been added to HaRe. Some of these refactorings make use of the GHC type checker to make the refactorings type-aware. These new refactorings include: adding and removing a constructor; adding and removing a field; and introduction of pattern matches and case analysis. Structural refactorings include: Conversion between let and where, and folding and unfolding of as-patterns.

A snapshot of HaRe is available from our webpage, as are recent presentations from the group (including LDTA 05, TFP05, SCAM06), and an overview of recent work from staff, students, and interns. Among this is an evaluation of what is required to port the HaRe system to the GHC API (→2.1), and a comparative study of refactoring Haskell and Erlang programs.

The final report for the project appears there, too, together with an updated refactoring catalogue and the latest snapshot of the system. Huiqing’s PhD thesis on refactoring Haskell programs is now available online from our project webpage.

Further reading

http://www.cs.kent.ac.uk/projects/refactor-fp/

My Haskell mode plugins for Vim seem to have become quite popular. They collect several scripts that offer functionality based on GHCi, on Haddock-generated documentation (→4.2.1), and on Vim’s own configurable program editing support. This includes several insert mode completions (based on identifiers available via currently imported modules, on identifiers appearing in the central Haddock indices, on tag files, or on words appearing in current and imported sources), quickfix mode (call compiler, list errors, jump to error locations), inferred type tooltips, 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 Haddocks for the id under cursor.

A very incomplete screenshot tour of Vim’s IDE functions, as instantiated for Haskell, provides an overview of what is available (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; for more and current details of Haskell mode features, see the haskellmode.txt help file at the project site).

Both alternative and complementary Haskell-related plugins for Vim exist — please add links to your own tricks and tips at haskell.org (syntax-colouring works out of the box, other scripts deal with indentation, …). I hope these plugins might be useful to some of you (please let me know if anything does not work as advertised!), and might even motivate some of you to give Vim a try. It is really not as if Vim (or Emacs, for that matter) did not have more IDE functionality than most of us ever use, it is more that there is so much of it to learn and to fine-tune to your personal preferences.

The haskellmode plugins for Vim are currently in maintenance mode, with infrequent updates and bug fixes, and the occasional new feature (CamelCase-based abbreviations for insert-mode completion the most recent example).

Further reading

• Haskell Mode Plugins for Vim: http://www.cs.kent.ac.uk/~cr3/toolbox/haskell/Vim/

• A short tour of some Vim support for Haskell editing (screenshots): http://www.cs.kent.ac.uk/~cr3/toolbox/haskell/Vim/vim.html

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

No matter how fast GHCi keeps improving, users still keep suggesting new commands for it, and with the increasing amounts of information available in GHCi, it can sometimes be difficult to find the interesting bits, either in the documentation, or indeed in command outputs. The usual approach is to add feature requests to the ticket tracker and hope that someone will get round to implementing them, or to get the GHC sources and start contributing code.

Quite often, however, users ask for GHCi features that they could (relatively) easily define themselves, using some of the less well known features of GHCi.

In an email to the haskell-cafe last September, I gave one demonstration of this approach in the form of a mini-tutorial, starting with simple things like platform-independent :pwd/:ls, then laying the groundwork for more complex commands by defining :redir <var> <cmd>, a command that redirects the output of <cmd>, binding it to variable <var>. Based on :redir, we can then define :grep <pat> <cmd>, to filter the output of <cmd> for a pattern <pat> (think of finding the help entries related to breakpoints, or the variants of fold appearing in :browse Prelude). Taking some examples from the GHCi ticket tracker and from Hugs’ commands, there is also :find <id> (open the source for the definition of <id>), :b (:browse first module listed in :show modules), and :le <mod> (load module <mod>, edit location of first error, if any).

The commands are self-documenting, can be listed and removed as a group, and should give a good starting point for your own experiments with GHCi’s :def. Since the email, which targeted GHC 6.6 and later, a version for GHC 6.4.1 was added for those who needed to work with an old installation (the commands in that version differ slightly, to account for 6.4.1’s limitations). Please let me know if you find this useful, and remember to share your own GHCi tricks and tips!

You can find (and contribute!) other suggestions for .ghci files on this Haskell wiki page: http://haskell.org/haskellwiki/GHC/GHCi.

Further reading

• http://www.haskell.org/pipermail/haskell-cafe/2007-September/032260.html
• http://www.cs.kent.ac.uk/~cr3/toolbox/haskell/#dot.ghci

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 in Hugs 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.

Current release is 1.4: there have been no changes in the last six months, indicating (one hopes) that it is now relatively bug-free.

Further reading

http://haskell.org/cpphs

Background

The Haskell Cabal is a Common Architecture for Building Applications and Libraries. It is an API distributed with GHC (→2.1), nhc98 (→2.2), and Hugs which allows a developer to easily build and distribute packages.

Hackage (Haskell Package Database) is an online database of packages which can be interactively queried via the website and client-side software such as cabal-install. From Hackage, an end-user can download and install Cabal packages.

Recent progress

We are preparing for a release of Cabal-1.4 and the cabal-install tool. It is expected that all packages that worked with Cabal-1.2 will work with Cabal-1.4. The Cabal-1.4 release will include a large number of incremental improvements and bug fixes. The major feature for the cabal-install release is that it can serve as the primary command line front end to the Cabal/Hackage system. There will be no need to use the runhaskell Setup.hs interface any more.

The last year has seen Hackage take off. It has grown from a handful of packages to nearly 600 (with over 1200 releases). The Hackage website has seen a number of improvements including reporting which versions of ghc each package builds with, who uploaded each package, and proper support for Unicode in package meta-data.

Hackage also now applies somewhat stricter rules about package uploads. Uploading the same version of a package more than once is no longer allowed because we expect package content to be stable. It also checks for some common problems in package descriptions and will warn or reject as appropriate. You can run the same checks locally using cabal check.

Google Summer of Code projects

We are very lucky to have got two Google Summer of Code projects related to Cabal and Hackage. Andrea Vezzosi is doing a project to build a “make-like” dependency framework for the Cabal library. This will enable Cabal to do proper dependency based rebuilds and support pre-processors like c2hs correctly. It also leads the way towards not depending on ghc –make for building Haskell code and to do parallel builds.

Neil Mitchell is working on Hoogle 4 (→4.4.1), which we aim to use as the primary search interface on the Hackage website. The aim is to be able to search the content of every package; not just the API but also the documentation and package meta-data.

Looking forward

There is huge potential for Hackage to help us manage and improve the community’s package collection. We are nearing the point where cabal-install will be able to report build results to the Hackage server. 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 information on the quality of packages. Hopefully we can evolve Hackage and associated clients into the kind of infrastructure we need to assemble collections of packages into high quality “batteries included”-style Haskell platform releases.

To help us in the next round of development work it would be enormously helpful to know from our users what their most pressing problems are with Cabal and Hackage. You probably have a favourite Cabal bug or limitation. Take a look at our bug tracker. Make sure the problem is reported there and properly described. Comment on the ticket to tell us how much of a problem the bug is for you. Add yourself to the ticket’s cc list so we can discuss requirements and keep you informed on progress. For feature requests it is very helpful if there is a description of how you would expect to interact with the new feature.

People

We would like to thank the large number of people who contributed to the last round of development work. I hope that attests to the fact that it is not too hard to get involved. Thanks also to the people who have followed development and reported bugs and feature requests.

Further reading

• Cabal homepage: http://www.haskell.org/cabal
• Hackage package collection: http://hackage.haskell.org/
• Bug tracker: http://hackage.haskell.org/trac/hackage/

hmatrix is a simple library for linear algebra and numerical computations, internally implemented using GSL, BLAS, and LAPACK. It is available from Hackage.

Most linear algebra functions mentioned in GNU-Octave’s Quick Reference are available both for real and complex matrices: eig, svd, chol, qr, hess, schur, inv, pinv, expm, norm, and det. There are also functions for numeric integration and differentiation, nonlinear minimisation, polynomial root finding, and more than 200 GSL special functions. A brief manual is available at the URL below.

Recent developments include support for 64bit machines, improved testing, and support for Intel’s MKL implementation of BLAS and LAPACK.

Further reading

http://alberrto.googlepages.com/gslhaskell

HPDF is an Haskell library allowing to generate PDF documents. HPDF is supporting several features of the PDF standard like outlines, multi-pages, annotations, actions, image embedding, shapes, patterns, text.

In addition to the standard PDF features, HPDF is providing some typesetting features built on top of the PDF core. With HPDF, it is possible to define complex styles for sentences and paragraphs. HPDF is implementing an optimum-fit line breaking algorithm a bit like the TeX one and HPDF is using the standard Liang hyphenation algorithm.

HPDF is at version 1.3. It is progressing continuously. HPDF is available on Hackage.

There are