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 6 months, now averaging around 390 users, with a record 436 users. It is one of the largest channels on freenode. The irc channel is home to hpaste and lambdabot (→6.14), two useful Haskell bots. Point your IRC client to irc.freenode.net and join the #haskell conversation!

For non-English conversations about Haskell there is 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 – Japenese 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 (→7.4.3)
• #haskell-books – Authors organizing the collaborative writing of the Haskell +wikibook
• #darcs – Darcs revision control channel (written in Haskell) (→6.13)
• #ghc – GHC developer discussion (→2.1)
• #happs – HAppS Haskell Application Server channel
• #xmonad – Xmonad a tiling window manager written in Haskell (→6.3)

Further reading

More details at the #haskell home page: http://haskell.org/haskellwiki/IRC_channel

Planet Haskell is an aggregator of Haskell people’s blogs and other Haskell-related news sites. As of mid-November 2007 content from 78 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/

The Haskell Weekly News (HWN) is a weekly 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.3), and via RSS. Headlines are published on haskell.org (→1.1).

Further reading

• Archives, and more information can be found at:

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

There are plenty of academic papers about Haskell and plenty of informative pages on the Haskell Wiki. Unfortunately, there’s not much between the two extremes. That’s 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 don’t warrant an academic publication – but that doesn’t mean these ideas aren’t worth writing about! Communicating ideas to a wide audience is much more important than concealing them in some esoteric journal. Even if its 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 don’t 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 there have been two new issues, including a special issue about this year’s Summer of Code. I’m always interested in new submissions, whether you’re an established researcher or fledgling Haskell programmer. Check out the Monad.Reader homepage for all the information to you need to start writing your article.

Further reading

All the recent issues and the information you need to start writing an article are available from: http://www.haskell.org/haskellwiki/The_Monad.Reader.

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’s 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, http://www.haskell.org/sitewiki/images/0/03/TMR-Issue7.pdf

Further information:

• 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 marvelous 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 progressing slowly but steadily. A chapter about Applicative Functors has been added, the module about Monads is being rewritten and comprehensive material about graph reduction and lazy evaluation is beginning to emerge. Thanks to the authors and to the many contributors that spot mistakes and ask those questions we’d never thought of!

Further reading

• http://en.wikibooks.org/wiki/Haskell
• Mailing list: <wikibook at haskell.org>

Lots has happened on the GHC front over the last few months. We released GHC 6.8.1 on 3 November 2007. GHC now has so many users, and such a large feature “surface area”, that simply getting to the point where we can make a release is becoming quite a challenge. Indeed, a good deal of our effort in the last six months has been in the form of consolidation: fixing bugs and solidifying what we have.

These graphs show “tickets” which include bugs, feature requests, and tasks. Of the “open tickets”, about half are bugs. Notice the big spike in “closed tickets” just before the 6.8.1 release!

The major new features of 6.8.1 were described in the last issue of the Haskell Communities Newsletter, so we won’t repeat them here. Instead, here are some of the highlights of what we are working on now.

Syntactic and front-end enhancements

Several people have developed syntactic innovations, which are (or will shortly be) in the HEAD:

Three improvements to records

• Wild-card patterns for records. If you have
    data T = MkT {x,y::Int, z::Bool}
  
  then you can say
    f :: T -> Int
    f (MkT {..}) = x+y
    g :: Int -> Int -> T
    g x y = MkT {..}
          where
            z = x>y
  
  The “..” in a pattern brings into scope all the fields of the record; while in a record construction it uses variables with those names to initialise the record fields. Here’s the user manual entry: http://www.haskell.org/ghc/dist/current/docs/users_guide/syntax-extns.html#record-wildcards.

• Record puns is a slightly less abbreviated approach. You can write f like this:
    f (MkT {x,y}) = x+y
  
  whereas Haskell 98 requires you to write x=x,y=y in the pattern. Similarly in record construction.

• Record field disambiguation is useful when there are several types in scope, all with the same field name. For example, suppose another data type S had an x field. Then if you write
    h (MkT {x=p,y=q}) = ...
  
  there is no doubt which x you mean, but Haskell 98 will complain that there are two xs in scope. Record field disambiguation just uses the constructor to decide which x you must mean.

None of these changes tackle the deeper issue of whether or not Haskell’s current approach to records is the Right Way; rather the changes just make the current approach work a bit better. Furthermore, they are all somewhat controversial, because they make it harder to see where something comes into scope. Let’s see what you think!

View patterns

View patterns are implemented, by Dan Licata. Here’s a simple example:

Generalised list comprehensions

Generalised list comprehensions (see Comprehensive comprehensions: comprehensions with “Order by” and “Group by”, Phil Wadler and Simon Peyton Jones, Haskell Workshop 2007) have been implemented by Max Bolinbroke. Example:

Quasi-quoting

We are keen to get Geoff Mainland’s quasi-quoting mechanism into GHC (see “Why It’s Nice to be Quoted: Quasiquoting for Haskell”, Geoffrey Mainland. Haskell Workshop 2007). Geoff is working on polishing it up.

Type system stuff

The big innovation in GHC’s type system has been the gradual introduction of indexed type families in the surface syntax, and of type equalities in the internal machinery.

Indexed data families (called “associated data types” when declared in type classes) are fairly simple, and they work fine in GHC 6.8.1. Indexed type families (aka “associated type synonyms”) are a different kettle of fish, especially when combined with the ability to mention type equalities in overloaded types, thus:

Parallel GC

Since 6.6 GHC has had support for running parallel Haskell on a multi-processor out of the box. However, the main drawback has been that the garbage collector is still single-threaded and stop-the-world. Since GC can commonly account for 30%of runtime (depending on the GC settings), this can seriously put a crimp in your parallel speedup.

Roshan James did an internship at MSR in 2006 during which he and Simon M worked on parallelising the major collections in GHC’s generational garbage collector. We had a working algorithm, but didn’t observe much speedup on a multi-processor. Since then, Simon rewrote the implementation and spent a large amount of time with various profiling tools, which uncovered some cache-unfriendly behaviour. We are now seeing some speedup, but there is more tweaking and measuring still to be done.

This parallel GC is likely to be in GHC 6.10. Note that parallel GC is independent of whether the Haskell program itself is parallel – so even single-threaded Haskell programs (e.g. GHC itself) should benefit from it.

The other side of the coin is to parallelise the minor collections. These are normally too small and quick to apply the full-scale parallel GC to, and yet the whole system still has to stop to perform a minor GC. The solution is almost certainly to allow each CPU to GC its own nursery independently. There is existing research describing how to do this, and we plan to try applying it in context of GHC.

Data parallel Haskell

After many months of designing, re-designing, and finally implementing a vectorisation pass operating on GHC’s Core intermediate language, we finally have a complete path from nested data parallel array programs to the low-level, multi-threaded array library in package ndp. We are very excited about having reached this milestone, but the path is currently very thin, complete unoptimised, and requires a special Prelude mockup. More work is required before vectorisation is ready for end-users, but now that the core infrastructure is in place, we expect more rapid progress on user-visible features.

Besides working on optimisations and completing the backend library, we still need to implement Partial Vectorisation of Haskell Programs (http://www.cse.unsw.edu.au/~chak/papers/CLPK07.html) and the treatment of unboxed types, which is crucial to vectorise the standard Prelude. Most of the code was written by Roman Leshchinskiy.

Back end stuff

GHC’s back end code generator has long been known to generate poor code, particularly for tight loops of the kind that are cropping up more and more in highly optimised Haskell code. So in typical GHC style, rather than patch the immediate problem, we’re redesigning the entire back end.

What we want to do:

• Split the STG-to-C-- code generator (codeGen) into two: one pass generating C-- with functions and calls, and a second pass (“CPS”) to manifest the stack and calling/return conventions.

• Redesign the calling and return conventions, so that we can use more registers for parameter passing (this will entail decommissioning the via-C code generator, but the native code generator will outperform it).

• Give the back end more opportunity to do low-level transformation and optimisation, e.g. by exposing loops at the C-- level.

• Implement more optimisations over C--.

• Plug in a better register allocator.

What we’ve done so far:

• Michael Adams came for an internship and built a CPS converter for GHC’s internal C-- data type.

• He had barely left when Norman Ramsey arrived for a short sabbatical. Based on his experience of building back ends for the Quick C-- compiler, he worked on a new zipper-based data structure to represent C-- code, and a sophisticated dataflow framework so that you can write new dataflow analyses in 30 mins.

• Ben Lippmeir spent his internship building a graph-colouring, coalescing register allocator for GHC’s native code generator.

As a result, we now have lots of new code. Some of it is working; much of it is as yet un-integrated and un-tested. However, once we have it all glued back together, GHC will become a place where you can do Real Work on low-level optimisations, and code generation. Indeed John Dias (one of Norman’s graduate students) will spend six months here in 2008 to do work on code generation.

In short, GHC’s back end, which has long been a poor relation, is getting a lot of very sophisticated attention. Expect good things.

Libraries

GHC ships with a big bunch of libraries. That is good for users, but it has two bad consequences, both of which are getting worse with time. First, it make it much harder to get a release together, because we have to test more and more libraries too. Second, it’s harder (or perhaps impossible) to upgrade the libraries independently from GHC. There’s a meta-issue too: it forces us into a gate-keeper role in which a library gets a big boost by being in the “blessed set” shipped with GHC.

Increasingly, therefore, we are trying to decouple GHC from big libraries. We ship GHC with a set of “boot” libraries, without which GHC will not function at all, and “extra” libraries, which just happen to come with some binary distributions of GHC, and which can be upgraded separately at any time. To further that end, we’ve split the “base” package into a bunch of smaller packages, and expect to further split it up for GHC 6.10. This has led to lots of pain, because old programs that depended on ‘base’ now need to depend on other packages too; see upgrading packages (http://www.haskell.org/haskellwiki/Upgrading_packages) for details. But it’s good pain, and matters should improve too as Cabal matures. We have been exploring possibilities for lessening the pain in 6.10: http://hackage.haskell.org/trac/ghc/wiki/PackageCompatibility. We have also devised a package versioning policy which will help future library upgrades: http://www.haskell.org/haskellwiki/Package_versioning_policy.

The York Haskell Compiler (yhc) is a fork of the nhc98 compiler, with goals such as increased portability, platform independent bytecode, integrated Hat 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 that last HCAR we have continued to improve our Yhc.Core library, making use of it in a number of projects (optimisers, analysis tools) to be made available shortly. The Javascript back end has undergone lots of improvements with new libraries for writing dynamic web pages.

Further reading

• Homepage:

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

• Darcs repository:

  http://darcs.haskell.org/yhc

When Haskell consists of Haskell semantics plus Haskell syntax, then Liskell consists of Haskell semantics plus Lisp syntax. Liskell is Haskell on the inside but looks like Lisp on the outside, as in its source code it uses the typical Lisp syntax forms, namely symbol expressions, that are distinguished by their fully parenthesized prefix notation form. Liskell captures the most Haskell syntax forms in this prefix notation form, for instance: if x then y else z becomes (if x y z), while a + b becomes (+ a b).

Except for aesthetics, there is another argument for Lisp syntax: meta-programming becomes easy. Liskell features a different meta-programming facility than the one found in Haskell with Template Haskell. Before turning the stream of lexed tokens into an abstract Haskell syntax tree, Liskell adds an intermediate processing data structure: the parse tree. The parse tree is essentially is a string tree capturing the nesting of lists with their enclosed symbols stored as the string leaves. The programmer can implement arbitrary code expansion and transformation strategies before the parse tree is seen by the compilation stage.

After the meta-programming stage, Liskell turns the parse tree into a Haskell syntax tree before it sent to the compilation stage. Thereafter the compiler treats it as regular Haskell code and produces a Haskell calling convention compatible output. You can use Haskell libraries from Liskell code and vice versa.

Liskell is implemented as an extension to GHC and its darcs branch is freely available from the project’s website. The Liskell Prelude features a set of these parse tree transformations that enables traditional Lisp-styled meta-programming as with defmacro and backquoting. The project’s website demonstrates meta-programming application such as proof-of-concept versions of embedding Prolog inference, a minimalistic Scheme compiler and type-inference in meta-programming.

The future development roadmap includes stabilization of its design, improving the user experience for daily programming – especially error reporting – and improving interaction with Emacs.

Further reading

http://liskell.org

The project at Macquarie University (→7.3.6) to run Haskell on handheld devices based on Palm OS has a running implementation for small tests but, like most ports of languages to Palm OS, we are dealing with memory allocation issues. Also, other higher priority projects have now intervened so this project is going into the background for a while.

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 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 have developed an adaptive runtime environment (GRID-GUM) for GpH on computational grids. GRID-GUM incorporates new load management mechanisms that cheaply and effectively combine static and dynamic information to adapt to the heterogeneous and high-latency environment of a multi-cluster computational grid. We have made comparative measures of GRID-GUM’s performance on high/low latency grids and heterogeneous/homogeneous grids using clusters located in Edinburgh, Munich and Galashiels. Results are published in:

  Al Zain A. Implementing High-Level Parallelism on Computational Grids, PhD Thesis, Heriot-Watt University, 2006.

  Al Zain A. Trinder P.W. Loidl H.W. Michaelson G.J. Evaluating a High-Level Parallel Language (GpH) for Computational Grids, IEEE Transactions on Parallel and Distributed Systems (February 2008).

• SMP-GHC, an implementation of GpH for multi-core machines has been developed by Tim Harris, Satnam Singh, Simon Marlow and Simon Peyton Jones.

• We are teaching parallelism to undergraduates using GpH at Heriot-Watt and Phillips Universitat Marburg.

GpH Applications

• As part of the SCIEnce EU FP6 I3 project (026133) (→7.3.10) (April 2006 - April 2011) we use GpH and Eden to provide access to computational grids from Computer Algebra(CA) systems, including GAP, Maple MuPad and KANT. We have implemented an interface, GCA, which orchestrates computational algebra components into a high-performance parallel application. GCA is capable of exploiting a variety of modern parallel/multicore architectures without any change to the underlying code. GCA is also 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.

Our main hardware platform are Intel-based Beowulf clusters. 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>

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 (GpH) 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

• Mischa Dieterle: Parallel functional implementation of Master-Worker-Skeletons, Diploma Thesis, Philipps-University Marburg, October 2007 (in German).

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

• Jost Berthold, Mischa Dieterle, Rita Loogen, Steffen Priebe: Hierarchical Master-Worker Skeletons, Practical Aspects of Declarative Languages (PADL) 08, San Francisco, USA, January 2008, LNCS, Springer, to appear.

• 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, San Francisco, USA, January 2008, LNCS, Springer, to appear.

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

• Mercedes Hidalgo-Herrero and Yolanda Ortega-Mallen: To be or not to be &hellp;lazy, In Draft Proceedings of 19th Intl. Symposium on the Implementation of Functional Languages (IFL 2007), University of Kent, Canterbury (UK) 2007.

• A. de la Encina, L. Llana, F. Rubio, M. Hidalgo-Herrero: Observing Intermediate Structures in a Parallel Lazy Functional Language, 9th International ACM-SIGPLAN Symposium on Principles and Practice of Declarative Programming, PPDP’07, ACM Press 2007, pages 111-120.

• Mercedes Hidalgo-Herrero, Alberto Verdejo, Yolanda Ortega-Mallen: Using Maude and its strategies for defining a framework for analyzing Eden semantics, WRS 06 (6th International Workshop on Reduction Strategies in Rewriting and Programming), Electronic Notes in Theoretical Computer Science, Volume 174, Issue 10, Pages 119-137 (July 2007).

• A. de la Encina, I. Rodriguez, F. Rubio: Testing Speculative Work in a Lazy / Eager Parallel Functional Language., LCPC’05, LNCS 4339, Springer 2007.

Further reading

http://www.mathematik.uni-marburg.de/~eden

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 won’t 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 formalized 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 (→5.2.1), happy (→5.2.2), bnfc, cabal (→4.1.1), and darcs (→6.13). 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 communicate 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/.

Chameleon is a Haskell style language which integrates sophisticated reasoning capabilities into a programming language via its CHR programmable type system. Thus, we can program novel type system applications in terms of CHRs which previously required special-purpose systems.

Chameleon including examples and documentation is available via http://taichi.ddns.comp.nus.edu.sg/taichiwiki/ChameleonHomePage.

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://taichi.ddns.comp.nus.edu.sg/taichiwiki/XhaskellHomePage.

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

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, and the type language does not include constraints (types in Clean often involve implications between uniqueness attribute). This makes the type system sufficiently similar to standard Hindley/Milner type systems that (1) standard inference algorithms can be applied, and (2) that modern extensions such as arbitrary rank types and generalized 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 the Haskell’s core type system. Moreover, we are currently working on defining syntactic conventions, which programmers can use to write type annotations, and compilers can use to report types, without mentioning uniqueness at all.

Further reading

• Edsko de Vries, Rinus Plasmeijer and David Abrahamson, “Equality-Based Uniqueness Typing”. Presented at TFP 2007, submitted for post-proceedings.
• Edsko de Vries, Rinus Plasmeijer and David Abrahamson, “Uniqueness Typing Redefined”, in Z. Horvath, V. Zsok, and Andrew Butterfield (Eds.): IFL 2006, LNCS 4449 (to appear).

The Test.IOSpec library provides a pure specification of several functions in the IO monad. This may be of interest to anyone who wants to debug, reason about, analyse, or test impure code.

The Test.IOSpec library is essentially a drop-in replacement for several other modules, most notably Data.IORef and (most of) Control.Concurrent. Once you’re satisfied that your functions are reasonably well-behaved with respect to the pure specification, you can drop the Test.IOSpec import in favour of the “real” IO modules.

The current release is described by a recent Haskell Workshop paper. The development version in the darcs repository, however, supports several exciting new features, including a modular way to combine specifications and a specification of STM. I have used Test.IOSpec to test and debug several substantial programs, such as a distributed Sudoku solver. If you use Test.IOSpec for anything useful at all, I’d love to hear from you.

Further reading

http://www.cs.nott.ac.uk/~wss/repos/IOSpec/

GSLHaskell is a simple library for linear algebra and numerical computation, internally implemented using GSL, BLAS and LAPACK.

A new version with important changes has been recently released. The internal code has been rewritten, based on an improved matrix representation. The interface is now simpler and more generic. It works on Linux, Windows and Mac OS X.

The library is available from HackageDB (→4.1.1) with the new name “hmatrix” (because only a small part of GSL is currently available, and matrix computations are based on LAPACK).

Most linear algebra functions mentioned in GNU-Octave’s Quick Reference are already 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 minimization, polynomial root finding, and more than 200 GSL special functions. A brief manual is available at the URL below.

This library is used in the easyVision project (→6.21).

Further reading

http://alberrto.googlepages.com/gslhaskell

The index aware linear algebra library is a Haskell interface to a set of common vector and matrix operations. The interface exposes index types to the type system so that operand conformability can be statically guaranteed. For instance, an attempt to add or multiply two incompatibly sized matrices is a static error.

The library should still be considered alpha quality. A backend for sparse vector types is near completion, which allows low-overhead “views” of tensors as arbitrarily nested vectors. For instance, a matrix, which we represent as a tuple-indexed vector, could also be seen as a (rank 1) vector of (rank 1) vectors. These different views usually produce different behaviours under common vector operations, thus increasing the expressive power of the interface.

Further reading

• Original announcement:

  http://article.gmane.org/gmane.comp.lang.haskell.general/13561

• Library:

  http://ofb.net/~frederik/stla/

The InterpreterLib library is a collection of modules for constructing composable, monadic interpreters in Haskell. The library provides a collection of functions and type classes that implement semantic algebras in the style of Hutton and Duponcheel. Datatypes for related language constructs are defined as non-recursive functors and composed using a higher-order sum functor. The full AST for a language is the least fixed point of the sum of its constructs’ functors. To denote a term in the language, a sum algebra combinator composes algebras for each construct functor into a semantic algebra suitable for the full language and the catamorphism introduces recursion. Another piece of InterpreterLib is a novel suite of algebra combinators conducive to monadic encapsulation and semantic re-use. The Algebra Compiler, an ancillary preprocessor derived from polytypic programming principles, generates functorial boilerplate Haskell code from minimal specifications of language constructs. As a whole, the InterpreterLib library enables rapid prototyping and simplified maintenance of language processors.

InterpreterLib is available for download at the link provided below. Version 1.0 of InterpreterLib was released in April 2007.

Further reading

http://www.ittc.ku.edu/Projects/SLDG/projects/project-InterpreterLib.htm

Contact

<nfrisby at ittc.ku.edu>

HsColour is a small command-line tool (and Haskell library) that syntax-colorises Haskell source code for multiple output formats. It consists of a token lexer, classification engine, and multiple separate pretty-printers for the different formats. Current supported output formats are ANSI terminal codes, HTML (with or without CSS), and LaTeX. In all cases, the colours and highlight styles (bold, underline, etc) are configurable. It can additionally place HTML anchors in front of declarations, to be used as the target of links you generate in Haddock documentation.

HsColour is widely used to make source code in blog entries look more pretty, to generate library documentation on the web, and to improve the readability of ghc’s intermediate-code debugging output.

Further reading

• http://www.cs.york.ac.uk/fp/darcs/hscolour

The Utrecht attribute grammar system has been extended:

• the attribute flow analysis has been completely implemented by Joost Verhoog, and it is now possible to generate visit-function based evaluators, which are much faster and use less space. We assume that such functions are strict in all their arguments, and generate the appropriate `seq` calls to make the GHC aware of this. As a result also case’s are generated instead on let’s wherever possible.

  Several improvements were made: better error reporting of cyclic dependencies, and a large speed improvements in the overall flow analysis have been made. The first versions of the EHC now compile without circularities, nor direct nor induced by fixing the attribute evaluation orders

• we are adding better support for higher order attribute grammars and forwarding rules
• Tthe error correcting strategies of the parser combinators are now being used as a base for providing automatic feedback in systems for training strategies (Johan Jeuring, Arthur van Leeuwen)
• a start has been made with providing Haddock information with the code of the parser combinators
• we plan to enhance the parser combinators with a second basic parsing engine, in order to support monadic uses of the combinators while keeping the error correcting capabilities

The goal of the X-Saiga project is to create algorithms and implementations which enable language processors (recognizers, parsers, interpreters, translators, etc.) to be constructed as modular and efficient embedded eXecutable SpecificAtIons of GrAmmars.

To achieve modularity, we have chosen to base our algorithms on top-down parsing. To accommodate ambiguity, we implement inclusive choice through backtracking search. To achieve polynomial complexity, we use memoization. We have developed an algorithm which accommodates direct left-recursion using curtailment of search. Indirect left recursion is also accommodated using curtailment together with a test to determine whether previously computed and memoized results may be reused depending on the context in which they were created and the context in which they are being considered for reuse.

The algorithm is described more fully in Frost, R., Hafiz, R. and Callaghan, P. (2007) Modular and Efficient Top-Down Parsing for Ambiguous Left-Recursive Grammars. Proceedings of the 10th International Workshop on Parsing Technologies (IWPT), ACL-SIGPARSE. Pages: 109 - 120, June 2007, Prague.

http://cs.uwindsor.ca/~hafiz/iwpt-07.pdf

We have implemented our algorithms, at various stages of their development, in Miranda (up to 2006) and in Haskell (from 2006 onwards). A description of a Haskell implementation of our 2007 algorithm can be found in Frost, R., Hafiz, R. and Callaghan, P. (2008) Parser Combinators for Ambiguous Left-Recursive Grammars. Proceedings of the 10th International Symposium on Practical Aspects of Declarative Languages (PADL), to be published in LNCS. January 2008, San Francisco, USA.

http://cs.uwindsor.ca/~hafiz/PADL_PAPER_FINAL.pdf

The X-SAIGA website contains more information, links to other publications, proofs of termination and complxity, and Haskell code of the development version.

http://cs.uwindsor.ca/~hafiz/proHome.html

We are currently extending our algorithm and implmentation to accommodate executable specifications of full-general attribute grammars.

Harpy is a library for run-time code generation of IA-32 machine code. It provides not only a low level interface to code generation operations, but also a convenient domain specific language for machine code fragments, a collection of code generation combinators and a disassembler. We use it in two independent (unpublished) projects: On the one hand, we are implementing a just-in-time compiler for functional programs, on the other hand, we use it to implement an efficient type checker for a dependently typed language. It might be useful in other domains, where specialized code generated at run-time can improve performance.

Harpy’s implementation makes use of the foreign function interface, but only contains functions written in Haskell. Moreover, it has some uses of other interesting Haskell extensions as for example multi-parameter type classes to provide an in-line assembly language, and Template Haskell to generate stub functions to call run-time generated code. The disassembler uses Parsec to parse the instruction stream.

We intend to implement supporting operations for garbage collectors cooperating with run-time generated code.

A second release is forthcoming, featuring improvements in the memory management, better floating point instruction support, and named labels that are shown in the disassembler output.

Further reading

http://uebb.cs.tu-berlin.de/harpy/

hs-plugins is a library for dynamic loading and runtime compilation of Haskell modules, for Haskell and foreign language applications. It can be used to implement application plugins, hot swapping of modules in running applications, runtime evaluation of Haskell, and enables the use of Haskell as an application extension language.

hs-plugins has been ported to GHC 6.6.

Further reading

• Source and documentation can be found at:

  http://www.cse.unsw.edu.au/~dons/hs-plugins/

• The source repository is available:

  darcs get

  http://www.cse.unsw.edu.au/~dons/code/hs-plugins/

Nicholas Burlett has now created a cabalized version and made it available on hackage. However, beware that this doesn’t use autoconf to check your system supports sa_len and it doesn’t check which version of libpcap is installed. It will probably work but may not. If it doesn’t then try this:

• Install libpcap. I used 0.9.4.
• autoheader
• autoconf
• ./configure
• hsc2hs Pcap.hsc
• ghc -o test test.hs --make -lpcap -fglasgow-exts

All contributions are welcome especially if you know how to get cabal to run autoconf and check for versions of non-Haskell libraries.

Takusen is a library for accessing DBMS’s. Like HSQL, we support arbitrary SQL statements (currently strings, extensible to anything that can be converted to a string).

Takusen’s ‘unique-selling-point’ is safety and efficiency. We statically ensure all acquired database resources such as cursors, connection and statement handles are released, exactly once, at predictable times. Takusen can avoid loading the whole result set in memory and so can handle queries returning millions of rows, in constant space. Takusen also supports automatic marshalling and unmarshalling of results and query parameters. These benefits come from the design of query result processing around a left-fold enumerator.

Currently we fully support Oracle, Sqlite, and PostgreSQL, and ODBC support exists but is not fully tested.

Since the last report we have:

• added an ODBC backend

• improved the installation process so that we can build Haddock docs with Cabal

A new release to promote the ODBC code should be forthcoming; until then interested souls can get the latest from the darcs repo.

Future plans

• complete ODBC interface.

• Large object support.

• MS SQL Server and Sybase interfaces, via FreeTDS.

Further reading

• darcs get http://darcs.haskell.org/takusen/
• browse docs:

  http://darcs.haskell.org/takusen/doc/html

  (see Database.Enumerator for Usage instructions and examples)

Data.ByteString provides packed strings (byte arrays held by a ForeignPtr), along with a list interface to these strings. It lets you do extremely fast IO in Haskell; in some cases, even faster than typical C implementations, and much faster than [Char]. It uses a flexible “foreign pointer” representation, allowing the transparent use of Haskell or C code to manipulate the strings.

Data.ByteString is written in Haskell98 plus the foreign function interface and cpp. It has been tested successfully with GHC 6.4, 6.6, 6.8, Hugs 2005–2006, and the head version of nhc98.

Work on Data.ByteString continues. In particular, a new fusion mechanism, stream fusion, has been developed, which should further improve performance of ByteStrings. This work is described in the recent “Stream Fusion: From Lists to Streams to Nothing at All” paper. Data.ByteString has recently been ported to nhc98.

Further reading

• Source and documentation can be found at

  http://www.cse.unsw.edu.au/~dons/fps.html

• The source repository is available:

  darcs get

  http://darcs.haskell.org/bytestring

Data.List.Stream provides the standard Haskell list data type and api, with an improved fusion system, as described in the papers “Stream Fusion” and “Rewriting Haskell Strings”. Code written to use the Data.List.Stream library should run faster (or at worst, as fast) as existing list code. A precise, correct reimplementation is a major goal of this project, and Data.List.Stream comes bundled with around 1000 QuickCheck properties, testing against the Haskell98 specification, and the standard library.

This library is under active development, and we expect to port the ndp and bytestring libraries to use it.

Further reading

• Source and documentation can be found at:

  http://www.cse.unsw.edu.au/~dons/streams.html

Dimensional is a library providing data types for performing arithmetic with physical quantities and units. Information about the physical dimensions of the quantities/units is embedded in their types and the validity of operations is verified by the type checker at compile time. The boxing and unboxing of numerical values as quantities is done by multiplication and division with units. The library is designed to, as far as is practical, enforce/encourage best practices of unit usage.

Following a reorganization of the module hierarchy the core of dimensional is now mostly stable while additional units are being added on an as-needed basis. In addition to the si system of units dimensional has experimental support for user-defined dimensions and a proof-of-concept implementation of the cgs system of units.

The most recent release is compatible with ghc 6.6.x and above and can be downloaded from hackage or the project web site. The primary documentation is the literate haskell source code but the wiki on the project web site has a few usage examples to help with getting started.

Further reading

http://dimensional.googlecode.com

The hierarchy of numerical type classes is revised and oriented at algebraic structures. Axiomatics for fundamental operations are given as QuickCheck properties, superfluous super-classes like Show are removed, semantic and representation-specific operations are separated, the hierarchy of type classes is more fine grained, and identifiers are adapted to mathematical terms.

There are both certain new type classes representing algebraic structures and new types of mathematical objects.

Currently supported algebraic structures are

• group (additive),
• ring,
• principal ideal domain,
• field,
• algebraic closures,
• transcendental closures,
• module and vector space,
• normed space,
• lattice,
• differential algebra,
• monoid.

There is also a collection of mathematical object types, which is useful both for applications and testing the class hierarchy. The types are

• lazy Peano number
• complex number, quaternion,
• residue class,
• fraction,
• partial fraction,
• numbers equipped with physical units (dynamic checks only),
• fixed point arithmetic with respect to arbitrary bases and numbers of fraction digits,
• infinite precision number in an arbitrary positional system as lazy lists of digits supporting also numbers with terminating representations,
• polynomial, power series, Laurent series
• root set of a polynomial,
• matrix (basics only),
• algebra, e.g. multi-variate polynomial (basics only),
• permutation group.

Using the revised system requires hiding some of the standard functions provided by Prelude, which is fortunately supported by GHC (→2.1). The library has basic Cabal support and a growing test-suite of QuickCheck tests for the implemented mathematical objects.

Future plans

Collect more Haskell code related to mathematics, e.g. for linear algebra. Study of alternative numeric type class proposals and common computer algebra systems. Ideally each data type resides in a separate module. However this leads to mutual recursive dependencies, which cannot be resolved if type classes are mutually recursive. We start to resolve this by fixing the types of some parameters of type class methods. E.g. power exponents become simply Integer instead of Integral, which has also the advantage of reduced type defaulting.

A still unsolved problem arises for residue classes, matrix computations, infinite precision numbers, fixed point numbers and others. It should be possible to assert statically that the arguments of a function are residue classes with respect to the same divisor, or that they are vectors of the same size. Possible ways out are encoding values in types or local type class instances. The latter one is still neither proposed nor implemented in any Haskell compiler. The modules are implemented in a way to keep all options open. That is, for each number type there is one module implementing the necessary operations which expect the context as a parameter. Then there are several modules which provide different interfaces through type class instances to these operations.

Further reading

http://darcs.haskell.org/numericprelude/

HList is a comprehensive, general purpose Haskell library for typed heterogeneous collections including extensible polymorphic records and variants. HList is analogous of the standard list library, providing a host of various construction, look-up, filtering, and iteration primitives. In contrast to the regular lists, elements of heterogeneous lists do not have to have the same type. HList lets the user formulate statically checkable constraints: for example, no two elements of a collection may have the same type (so the elements can be unambiguously indexed by their type).

An immediate application of HLists is the implementation of open, extensible records with first-class, reusable, and compiled-time only labels. The dual application is extensible polymorphic variants (open unions). HList contains several implementations of open records, including records as sequences of field values, where the type of each field is annotated with its phantom label. We and now others (Alexandra Silva, Joost Visser: PURe.CoddFish project) have also used HList for type-safe database access in Haskell. HList-based Records form the basis of OOHaskell http://darcs.haskell.org/OOHaskell. The HList library relies on common extensions of Haskell 98.

The HList repository is available via Darcs (→6.13): http://darcs.haskell.org/HList

The library is being optimized and extended. Since the last report, we have added ConsUnion.hs to build homogeneous lists of heterogeneous components by constructing the union on-the-fly. We added Template Haskell code to eliminate the annoying boilerplate when defining record ‘labels’. We optimized record projection, which should be especially noticeable for record narrowing. We added equivR, record equivalence modulo field order, with witnessing conversions. ConsUnion.hs checks for record types and treat the latter equivalent modulo the order of fields. This gives optimized, shallower unions.

Further reading

• HList:

  http://homepages.cwi.nl/~ralf/HList/

• OOHaskell:

  http://homepages.cwi.nl/~ralf/OOHaskell/

The Binary Strike Team is pleased to announce the release of a new, pure, efficient binary serialisation library.

The ‘binary’ package provides efficient serialisation of Haskell values to and from lazy ByteStrings. ByteStrings constructed this way may then be written to disk, written to the network, or further processed (e.g. stored in memory directly, or compressed in memory with zlib or bzlib).

The binary library has been heavily tuned for performance, particularly for writing speed. Throughput of up to 160M/s has been achieved in practice, and in general speed is on par or better than NewBinary, with the advantage of a pure interface. Efforts are underway to improve performance still further. Plans are also taking shape for a parser combinator library on top of binary, for bit parsing and foreign structure parsing (e.g. network protocols).

Data.Derive (→5.3.1) has support for automatically generating Binary instances, allowing to read and write your data structures with little fuzz.

Binary was developed by a team of 8 during the Haskell Hackathon, and since then has in total 15 people contributed code and many more given feedback and cheerleading on #haskell.

The underlying code is currently being rewritten to give even better performance – both reading and writing – still exposing the same API.

The package is is available through Hackage (→4.1.1).

Further reading

• Homepage

  http://www.cse.unsw.edu.au/~dons/binary.html

• Hackage

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

• Development version

  darcs get –partial

  http://darcs.haskell.org/binary

The Binary Defer library provides a framework for doing binary serialisation, with support for deferred loading. Deferred loading is for when a large data structure exists, but typically only a small fraction of this data structure will be required. By using deferred loading, some of the data structure can be read quickly, and the rest can be read on demand, in a pure manner.

This library is at the heart of Hoogle 4 (→5.5.6), but has already found uses outside that application, including to do offline sorts etc.

Further reading

• Homepage:

  http://www-users.cs.york.ac.uk/~ndm/binarydefer

The current version is still 4.0.3.

This means no dependency on NewBinary which had been requested by several people.

The interface to SHA-1 is still different from MD5 and the whole library needs a rethink. Unfortunately, I don’t have the time to undertake much work on it at the moment and it is not clear when I will have more time. I’m therefore looking for someone to help keeping the repository up-to-date with contributions, re-structuring the library and managing releases.

I have restructured SHA-1 to be more Haskell-like and it’s now obvious how it mirrors the specification. However, this has led to rather poor performance and it’s not obvious (to me at least) what can be done without sacrificing clarity.

Several people have posted more efficient versions of SHA-1 but not as patches. Given my limited time, I haven’t been able to do anything with these.

This release contains:

• DES
• Blowfish
• AES
• Cipher Block Chaining (CBC)
• PKCS#5 and nulls padding
• SHA-1
• MD5
• RSA
• OAEP-based encryption (Bellare-Rogaway)

Further reading

http://www.haskell.org/crypto http://hackage.haskell.org/trac/crypto.

The current release is 0.0.11 which con