Haskell Communities and Activities Report

haskell.org belongs to the entire Haskell community – we all have a stake in keeping it as useful and up-to-date as possible. Anyone willing to help out at haskell.org should contact John Peterson <peterson-john at cs.yale.edu> to get access to this machine. There is plenty of space and processing power for just about anything that people would want to do there.

Thanks to Fritz Ruehr for making the cafepress store on haskell.org a lot more exciting and to Jonathan Lingard for adding some nice style sheets to our pages.

What can haskell.org do for you?

• advertise your work: whether you’re developing a new application, a library, or have written some really good slides for your class you should make sure haskell.org has a pointer to your work.
• hosting: if you don’t have a stable site to store your work, just ask and you’ll own haskell.org/yourproject.
• mailing lists: we can set up a mailman-based list for you if you need to email your user community.
• sell merchandise: give us some new art for the cafepress store. publicize your system with a t-shirt.

The biggest problem with haskell.org is that it is difficult to keep the information on the site current. At the moment, we make small changes when asked but don’t have time for any big projects. Perhaps the biggest problem is that most parts (except the wiki) cannot be updated interactively by the community. There’s no easy way to add a new library or project or group or class to haskell.org without bothering the maintainers. the most successful sites are those in which the community can easily keep the content fresh. We would like to do something similar for haskell.org.

Just what can you do for haskell.org? Here are a few ideas:

• make the site more interactive; allow people to add new libraries, links, papers, or whatever without bothering the maintainers; allow people to attach comments to projects or libraries so others can benefit from your experience; help tell everyone which one of the graphics packages or GUIs or whatever is really useful.
• develop a system where the pages for haskell.org live in a cvs repository so that we can more easily share out maintenance.
• add searching capability to haskell.org.

Some of these ideas would be good student projects. Be lazy – get students to do your work for you.

Further reading

• http://www.haskell.org
• http://www.haskell.org/mailinglist.html

The #haskell IRC channel is a real-time text chat where anyone can join to discuss Haskell. Point your IRC client to irc.freenode.net and join the #haskell channel.

The #haskell.se channel is the same subject but discussion happens in Swedish. This channel tends to have a lot of members from Gothenburg.

There is also a #darcs channel – if you want real-time discussion about darcs, drop by!

The Haskell wikiwiki is a freely editable website designed to allow unrestricted collaboration. The address is http://www.haskell.org/hawiki/. Some highlights are:

• http://www.haskell.org/hawiki/CommonHaskellIdioms
• http://www.haskell.org/hawiki/FundamentalConcepts

I am currently in the final-stages of producing an introductory Haskell textbook. The book is a revised and extended version of my Haskell course at the University of Nottingham, which has been developed and class tested over many years. The first seven chapters (97 pages) are available for preview on the web: http://www.cs.nott.ac.uk/~gmh/book.html

I’d be pleased to make the full current draft (162 pages) available to anyone that is teaching Haskell and may be interested in using the book in their course; please contact me for further details.

The hs-manpage-howto(7hs) is a manpage for documenting Haskell modules with roff manpages. I announced it in the November issue and it has been expanded with some small additions and clarifications since then. Most notable are the guidelines for HISTORY sections in the context of ECT (→4.1.2).

So as before, the hs-manpage-howto(7hs) is a rough document far from complete, meant mainly as a reminder and guide for myself. But if you happen to be writing a Haskell manpage yourself, you should still find it useful.

And if you come up with a guideline not covered, please let me know!

Further reading

http://www.scannedinavian.org/~pesco/man/html7/hs-manpage-howto.7hs.html

Despite being “full”, GHC continues to develop at an alarming rate. Here are some highlights from the last few months.

• We finally released GHC 6.4, over a year after the last major release, in March 2005. The long gap between releases is partly because doing a full release is a lot of work. But a bigger reason is that a lot is still happening to GHC, and it can be hard to find a moment when all the dust has settled at once.

• With major input from Tim Harris, we implemented Software Transactional Memory in the autumn, a new synchronisation and communication for Concurrent Haskell that completely replaces MVars. (MVars are still available, but they become library.) We think STM is a major leap forward, and are eager to hear your experiences when you try it out. Anyone who uses Concurrent Haskell should give it a whirl. Paper at http://research.microsoft.com/~simonpj/papers/stm.
• Much better support for mutually-recursive modules. Mutual recursion used to be handled by hand-written, but completely unchecked,interface files. Now you still need to write a loop-breaking module interface by hand, but it’s regarded as a source file, in Haskell syntax; it is fully typechecked; it is understood by ghc --make; it is checked against its parent source file when the latter is compiled; and so on. All vastly superior. Further improvements (e.g. ability to include instance declarations) are in the works.

• Much improved support for Cabal (→4.1.1).

• A declaration type signature now binds lexically-scoped type variables. For example
    tail :: forall a. [a] -> [a]
    tail (x:xs) = xs :: [a]
  
  Here, the a bound by the forall scopes over the body of tail. I fought against this for ages, but it’s just so convenient. It only happens if you give an explicit forall, though.

• Improvements in Template Haskell support; notably the of an abstract type Name for the names of TH variables, rather than String, and ramifications thereof (http://www.haskell.org/ghc/docs/papers/th2.ps).
• Modest improvements to the implementation of Generalised Algebraic Data Types (GADTs). The big shortcoming is that GADTs do not interact nicely with type classes and functional dependencies yet. That turned out to be a more complex task than we’d anticipated.
• Rebindable syntax now works properly for do-notation. The idea is that, with -fno-implicit-prelude, do-notation type-checks and desugars just as if you had written the program with explicit (>>=) and (>>) etc, using whatever (>>=) operator is in scope in this module. There’s no longer a requirement that the type looks exactly like that for the built-in (>>=) operator.

• Support for the amd64 (x86-64) platform is improving. The 6.4 release had basic registerised support for this processor; we have now added a fully-working native code generator and completed support for the FFI. GHCi support should be forthcoming shortly. We aim for this to be a fully-supported platform in future GHC releases.

• John Goerzen is experimenting with converting the CVS repository to darcs (→6.3). We hope to set up a two-way sychronisation between the two repositories, so that people working on GHC can use whichever source control system they prefer (though we hope the general trend will be in the direction of darcs, so that eventually we can drop CVS support).

• We are working on adding an API to GHC, so that you can use GHC itself as a Haskell library (by saying “import GHC”). This will let you typecheck, compile, and execute all of GHC-supported Haskell from your own application. GHC’s own front-ends are implemented on top of this API: GHCi, --make and the command-line interface. The new Visual Studio mode is also using this API to support interactive type checking of source code as it is edited (amongst many other things).

  For the current version of the API, see http://cvs.haskell.org/cgi-bin/cvsweb.cgi/~checkout~/fptools/ghc/compiler/main/GHC.hs?rev=1.22.

  We plan to provide the GHC API via a package (-package ghc) in the next major release of GHC (6.6).

The Big New Thing over the next few months will be multi-processor GHC. Now that multi-core processors are on the near horizon, and STM has given us a nice way to coordinate them, we are building a multi-processor GHC that uses multiple processors running Haskell on a single shared heap. That involves fine-grain locking on thunks, but we have a way to make that quite cheap. This is quite complementary to the long-standing work on GUM, aimed at more distributed-memory architectures with disjoint heaps.

On the type system front, we plan to extend GHC’s higher-rank type system to incorporate impredicative types too: http://research.microsoft.com/~simonpj/papers/boxy.

Thank you to everyone who completed the GHC survey. If you use GHC and have not completed the survey, please do so – we are keen to get an unbiased sample of our actual users, rather than one skewed towards hard-core Haskell devotees. Here it is: http://www.haskell.org/ghc/survey/start.cgi. We’ll publish the results once we’ve digested them.

As ever, we are grateful to the many people who submit polite and well-characterised bug reports. We’re even more grateful to folk actually help develop and maintain GHC. The more widely-used GHC becomes, the more we rely on you to help solve people’s problems, and to maintain and develop the code. We won’t be around for ever, so the more people who are involved the better. If you’d like to join in, please let us know.

An interim release of Hugs appeared in March 2005, on the same day as releases of GHC and nhc98. This release was mainly targeted at Unix users (see below). It featured Unicode support (contributed by Dmitry Golubovsky) and lots of up-to-date libraries. Additions include the graphics library used in the “School of Expression” textbook.

A major new feature is support for the Cabal infrastructure (→4.1.1), which is now the recommended way to install third-party packages with Hugs. Indeed the Hugs build system uses Cabal to prepare all the libraries included with Hugs (after a little bootstrapping).

Sadly no-one is packaging Hugs for Windows. It will probably build under MinGW or Cygwin with little or no work, but no-one has tried it recently. The new Cabal-based library build system holds out the promise of independence from the Unix-like environments, but Cabal itself needs more work under Windows. As ever, volunteers are welcome.

nhc98 is a small, easy to install, standards-compliant compiler for Haskell’98. It is in stable maintenance-only mode – the current public release was recently refreshed to version 1.18. Maintenance continues in CVS at haskell.org.

Tony Sloane has recently added a literate version of nhc98’s runtime system kernel to CVS. We hope this will enable more people to understand the internals, and more easily contribute to the compiler. Some individual projects of potential interest to many users would be:

• overhaul the type inference subsystem, towards the goal of implementing multi-parameter classes;
• add pattern-guards to the source language;
• remove any 32-bit platform assumptions;
• add concurrent threads using a co-operative scheduler;
• implement exceptions.

Further reading

http://haskell.org/nhc98

The primary aim of the project is to develop a tool, which we name Hacle, for translating Haskell programs to Clean programs, thereby allowing the Clean compiler to compile Haskell programs. The question is, can the Clean compiler, in combination with Hacle, produce faster executables than existing Haskell compilers?

The answer, perhaps rather predictably, is sometimes yes. We have noticed that, in some cases, the hybrid Hacle-then-Clean compilation system can produce executables which are up to a factor of four times faster than the corresponding GHC-compiled programs. However, we suspect that these cases are in a minority. Nevertheless, to be of any significance at all, we must also argue Hacle’s completeness.

Hacle can translate programs which conform to a slightly restricted Haskell 98 standard. It can translate itself, which is written in approximately fifteen thousand lines of code and makes use of many of the features provided by Haskell 98. This result positively demonstrates reasonable completeness.

The project is effectively finished; this is not to say that the tool cannot be improved, rather that we are content with its current state. Only the unlikely event of widespread use would motivate such improvements. However, the following question is unanswered: why do Clean and GHC sometimes outperform each other?

For more information including detailed technical documentation, my dissertation, more results, Hacle’s limitations, and a download link to Hacle, see the project’s web page.

Further reading

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

Grateful acknowledgements to Malcolm Wallace and Olaf Chitil.

The purpose of the Helium project is to construct a light-weight compiler for a subset of Haskell that is especially directed to beginning programmers (see “Helium, for learning Haskell”, Bastiaan Heeren, Daan Leijen, Arjan van IJzendoorn, Haskell Workshop 2003). We try to give useful feedback for often occurring mistakes. To reach this goal, Helium uses a sophisticated type checker (→3.4.4) (see also “Scripting the type inference process”, Bastiaan Heeren, Jurriaan Hage and S. Doaitse Swierstra, ICFP 2003).

Helium has a simple graphical user interface that provides online help. We plan to extend this interface to a full fledged learning environment for Haskell. The complete type checker and code generator has been constructed with the attribute grammar (AG) system developed at Utrecht University. One of the aspects of the compiler is that can log errors to a central repository, so we can track the kind of problems students are having, and improve the error messages and hints.

There is now support for type classes, but this has not been officially released yet. A new graphical interpreter is being developed using wxHaskell (→4.5.1), which will replace the Java-based interpreter. The Helium compiler has been used successfully four times during the functional programming course at Utrecht University.

Further reading

http://www.cs.uu.nl/research/projects/helium/

Work on our port of nhc98 (→2.3) to Palm OS is continuing. We are focussing our current attention on reworking the nhc98 runtime kernel by writing a literate version to make it easier to understand and port. We hope to use this work as the basis of a new Palm OS port that is more reliable and maintainable than our previous version.

Vital is a highly interactive, visual environment that aims to present Haskell in a form suitable for use by engineers, mathematicians, analysts and other end users who often need a combination of the expressiveness and robustness that Haskell provides together with the ease of use of a ‘live’ graphical environment in which programs can be incrementally developed.

In Vital, Haskell modules are presented as ‘documents’ having a free-form layout and with expressions and their values displayed together. These values can be displayed either textually, or pictorially and can be manipulated by an end user by point-and-click mouse operations. The way that values of a given type are displayed and the set of editing operations defined on them (i.e., the ‘look and feel’ of the type) are defined using type classes. For example, an ADT representing directed graphs could be introduced, with its values displayed pictorially as actual directed graphs and with the end user provided with a menu of operations allowing edges to be added or removed, transitive closures to be computed, etc. (In fact, although an end user appears to be operating directly on values, it is actually the Haskell program itself that is updated by the system, using a specialised form of reflection.)

The present implementation includes a collection of interactive tutorial documents (including examples illustrating approaches to exact real arithmetic, pictorial manipulation of DNA and the genetic code, animated diagrams of mechanisms, and the composition and synthesis of MIDI music).

The Vital system can be run via the web: a single mouse-click is all that is needed!

Further reading

Home page: http://www.cs.kent.ac.uk/projects/vital/

hOp is a micro-kernel based on the run-time system (RTS) of the Glasgow Haskell Compiler. It is meant to enable people to experiment with writing various components of an operating system in Haskell. This includes device drivers, data storage devices, communication protocols and tools required to make use of these components.

The February 2004 release of hOp consisted of a trimmed-down RTS that does not depend on features usually provided by an operating system. It also contains low-level support code for hardware initialization. This release made most functions from the base hierarchical library available (all but the System modules), including support for threads, communication primitives, and the foreign function interface (→3.2).

Building on the features of the initial release, we designed and implemented an interrupt handling model. Each interrupt handler is run in its own thread, and sends events to device drivers through a communication channel. We tested our design by implementing a simple PS/2 keyboard driver, and a “shell” that allows running a “date” command, which accesses the real time clock of the computer. A release of hOp containing these additional features was made in June 2004.

Iavor Diatchki, Thomas Hallgren, and Andrew Tolmach made some additions to hOp. The resulting system is in an experimental state and is preliminary called House. The additions include a PS/2 mouse driver, using VBE 2.0 to setup a linear frame buffer for graphics, a window system implemented in Haskell (Gadgets, developed by Rob Noble and Colin Runciman at the University of York), new primitives for setting up demand paged virtual memory and executing arbitrary machine code in protected mode. The function that executes code in user mode returns when normal execution is interrupted for some reason (e.g., by a hardware interrupt, a system call or a page fault), allowing Haskell code can handle the situation in an appropriate way, and then resume user mode execution, if that is appropriate.

A recent addition to the system is a driver for NE2000 compatible network cards (as emulated by QEMU) and a simple protocol stack. We have used this to add shell commands for downloading files via TFTP, and then display them on the screen or execute them as user mode binaries.

Further reading

Further information, source code, demos and screenshots are available here:

• http://www.macs.hw.ac.uk/~sebc/hOp/
• http://www.cse.ogi.edu/~hallgren/House/

The specification of the Haskell 98 Foreign Function Interface 1.0 is now also available in HTML. To download or browse online, please visit http://www.cse.unsw.edu.au/~chak/haskell/ffi/.

Status

A complete, GHC-based implementation of the parallel Haskell extension GpH and of evaluation strategies is available.

System Evaluation and Enhancement

The first 3 items are linked by a British Council/DAAD collaborative project between Heriot-Watt University, St Andrews University, and Phillips Universität Marburg.

• We are adapting GpH to run on computational GRIDs. The current implementation performs well on single clusters, and multiple clusters with a low-latency interconnect. A distribution is available on request from <ceeatia at macs.hw.ac.uk>.
• We are designing a generic parallel runtime environment encompassing both the Eden (→3.3.3) and GpH runtime environments
• In separate work GpH is being used as a vehicle for investigating scheduling on the GRID.
• We are teaching parallelism to undergraduates using GpH at Heriot-Watt and Phillips Universität Marburg.

GpH Applications

GpH is being used to parallelise the GAP mathematical library in an EPSRC project (GR/R91298).

Implementations

The GUM implementation of GpH is available in two development branches, and work on a port of GUM to the latest GHC 6.xx branch has been started over summer.

• The stable branch (GUM-4.06, based on GHC-4.06) is available for RedHat-based Linux machines: binary snapshot (see installation instructions). The stable branch is available from the GHC CVS repository via tag gum-4-06.
• The unstable branch (GUM-5.02, based on GHC-5.02) is working and has been used on a Beowulf cluster. It is available on request as a source bundle.

Our main hardware platform are Intel-based Beowulf clusters. Work on ports to other architectures is also moving on (and available on request). Specifically 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/

Implementation:

An alpha-release of the GdH implementation is available on request <gph at macs.hw.ac.uk>. It shares substantial components of the GUM implementation of GpH (→3.3.1). A beta release of mHaskell will be available in December 2005.

GdH Applications and Evaluation

• An EPSRC project High Level Techniques for Distributed Telecommunications Software (http://www.macs.hw.ac.uk/~dsg/telecoms/, GR/R88137) is now underway and is entering its first GdH phase. The project evaluates GdH and Erlang in a telecommunications context, the work is a collaboration between Heriot-Watt University and Motorola UK Research Labs.
• There is a forthcoming Ph.D. thesis on the design, implementation and use of GdH by Robert Pointon (http://www.macs.hw.ac.uk/~rpointon/).

Further reading

• The GdH homepage:

  http://www.macs.hw.ac.uk/~dsg/gdh/

• The mHaskell homepage:

  http://www.macs.hw.ac.uk/~dubois/mhaskell

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.

Eden has been implemented by modifying the parallel runtime system GUM of GpH (see above). Differences include stepping back from a global heap to a set of local heaps to reduce system message traffic and to avoid global garbage collection. The current (freely available) implementation is based on GHC 5.02.3. A source code version is available from the Eden web page. Installation support will be provided if required.

Recent and Forthcoming Publications

survey and new standard referenceRita Loogen, Yolanda Ortega-Mallén and Ricardo Peña: Parallel Functional Programming in Eden, Journal of Functional Programming 15(4), 2005, to appear.

semanticsMercedes Hidalgo-Herrero, Alberto Verdejo, Yolanda Ortega-Mallén: Looking for Eden through Maude and its strategies, submitted, 2005.

analyses

Clara Segura, Ricardo Peãa: Nondeterminism analyses in a parallel-functional language, Journal of Functional Programming 15(1), pp. 67–100. January 2005.

compilationSteffen Priebe: Preprocessing Eden with Template Haskell, April 2005, submitted.

profilingPablo Roldan Gomez, J. Berthold: Eden Trace Viewer: A Tool to Visualize Parallel Functional Program Executions, March 2005, submitted.

skeleton performance analysisJost Berthold, Rita Loogen: Improving Functional Topology Skeletons with Dynamic Channels, March 2005, submitted.

Current Activities

• Yolanda and Mercedes are working on an implementation of Eden’s operational semantics in Maude.

• Jost is working on a more general implementation of parallel Haskell dialects in a shared runtime system.

• Steffen continues his work on the polytypic skeleton library for Eden making use of the new meta-programming facilities in GHC.

• Pablo is working on extensions of the Eden trace viewer tool.

• Jost and Rita continue working on the skeleton library.

• Claudia and Rita investigate parallel functional graph algorithms.

Further reading

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

Haskell-Coloured Petri Nets (HCPN) are an instance of high-level Petri Nets, in which anonymous tokens are replaced by Haskell data objects (and transitions can operate on that data, in addition to moving it around).

This gives us a hybrid graphical/textual modelling formalism for Haskell, especially suited for modelling concurrent and distributed systems. So far, we have a simple embedding of HCPN in Haskell, as well as a bare-bones graphical editor (HCPN NetEdit) and simulator (HCPN NetSim) for HCPN, building on the portable wxHaskell GUI library (→4.5.1). The tools allow to create and modify HCPN, save and load models, or generate Haskell code for graphical or textual simulation of HCPN models. HCPN NetEdit and NetSim are not quite ready for prime time yet, but functional; as long as you promise not to look at the ugly code, you can find occasionally updated snapshots at the project home page, together with examples, screenshots, introductory papers and slides.

I have just returned to this project, working on several items: first, the embedding of HCPN in Haskell has changed slightly. Apart from making the generated transition code even simpler, the idea is to abstract from the precise representation of places, in order to prepare the necessary move towards hierarchical HCPN (the original embedding mapped places directly to record fields, making composition of nets somewhat difficult without extensible records). Second, I am moving the drawing code from wxHaskell to HOpenGL (→4.6.1) – if HOpenGL’s support is somewhat “basic” (you want higher-level abstractions on top), wxHaskell’s drawing can only be described as “primitive” (encouraging bad habits, unless you avoid some of its features).

Due to all these ongoing rewrites, the current sources are not in a releasable state, but until this settles down, the old snapshots are still available from the project web page. This is still a personal hobby project, so further progress will depend on demand and funding. In other words, please let me know if you are interested in this!

Further reading

• Project home:

  http://www.cs.kent.ac.uk/~cr3/HCPN/

• Petri Nets home:

  http://www.informatik.uni-hamburg.de/TGI/PetriNets/

Agda is an interactive type-based editor for editing proofs and programs that has been developed at Chalmers and Göteborg University. It builds on previous work at Chalmers such as ALF and Cayenne. It implements a proof/type checker for a language that is based on Martin-Löf Type Theory. We are experimenting with how such a proof language could be extended with data-types, modules and records. The syntax of the language is rather close to Haskell. The language can also be seen as a start for a dependently typed programming language.

The program is written in Haskell and it consists of roughly 15 000 lines of code. It is connected with one graphical and one text-based interface. The graphical interface Alfa http://www.cs.chalmers.se/~hallgren/Alfa/ is written in Haskell using Fudgets. The is also a “simple” emacs-interface which doesn’t know the syntax of the language and communicates via a text-based protocol with Agda. This interface comes with the distribution of Agda.

Agda is running with a stable version that is slightly more than one year old. It is also possible to download newer unstable versions. In this new version experiments are done with hidden arguments as in Cayenne, addition of over-loading with a class system and built-in types such as characters, strings and integers.

We have recently started a collaboration with AIST (Advanced Industrial Science and Technology Institute in Japan) on development and applications of Agda. In particular on writing better documentation and integration with other automatic proof tools.

Agda source code can be browsed at http://cvs.coverproject.org/marcin/cgi/viewcvs/ and can be accessed by anonymous CVS from cvs.coverproject.org.

Short term goals are among many things:

• Write a better documentation of the code and the system.
• Examples of classes and built-in types
• Building on the libraries
• Revision of the type-checking algorithm
• Connecting Agsy with the emacs-interface – Agsy is an automatic proof search plugin for Alfa for the moment.

Further reading

For more details about the project, read about QuickCheck (→5.4.4) and Cover (→7.3.10) in this report or consult the homepage at http://www.cs.chalmers.se/~catarina/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)). Whilst at Durham, Conor McBride developed the Epigram prototype in Haskell, interfacing with the xemacs editor. Now, thanks to Thorsten Altenkirch, Epigram has a team of willing workers in Nottingham. A new implementation (also in Haskell) is in progress, incorporating a compiler based on Edwin Brady’s doctoral research.

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.

Implementation

Whilst Epigram seeks to open new possibilities for the future of strongly typed functional programming, its implementation benefits considerably from the present state of the art. On the language side, considerable use is made of monad transformers, higher-kind polymorphism and type classes. Moreover, its denotational approach translates Epigram’s lambda-calculus directly into Haskell’s. On the tool side, Haskell’s profiler (in the capable hands of Paul Callaghan) has proved invaluable for detecting bottlenecks in the code.

Current Status

Epigram can be found on the web at http://sneezy.cs.nott.ac.uk/epigram/ and its community of experimental users communicate via the mailing list <epigram at durham.ac.uk>. The current implementation is naive in design and slow in practice, but it is adequate to exhibit small examples of Epigram’s possibilities. The new implementation, whose progress can be observed at http://sneezy.cs.nott.ac.uk/epilogue/ will be much less rudimentary.

Latest developments:

Chameleon implementation

We are working on a completely new implementation of the Chameleon compiler. Chameleon is a Haskell-like language which supports almost all of Haskell 98, as well as the following extensions (and more):

• Multi-parameter type classes, with functional dependencies
• Type-level constraint programming (using CHR)
• Lexically scoped type annotations (see below)
• Generalized guarded recursive data types (see below)

The new implementation incorporates a significantly faster constraint solver, and has been designed to be easily extended. In particular, language extensions which make use of the underlying solver can straightforwardly take advantage of the system’s advanced error reporting features. We are currently working on a backend for the compiler, as well as the integration of many commonly available Haskell libraries.

Type system extensions

More general algebraic data types:We formalize an extension of Hindley/Milner with a user-programmable constraint domain and a general form of algebraic data types (GRDT) which unifies common forms such as existential types, the combination of type classes and existential types and the more recent extension of guarded recursive data types. We also support advanced type class extensions such as functional dependencies. Thus, we can express novel variants which allow for a GRDT-style behavior of type classes with existential types

Lexically scoped type annotations:We generalize the two common forms of type-sharing (found in GHC) and type-lambda annotations (found in ML) leading to an expressive system of lexically scoped annotation. We show that such an extension is highly useful in case of advanced typing features such as polymorphic recursion, type classes and guarded recursive data types.

A fresh look at kind inference and kind checking:We present an improved error reporting scheme for kind inference and checking based on our earlier work on type error reporting. We consider a monomorphic kind system. Hence, polymorphic kinds resulting from kind inference will be replaced by monomorphic kinds. This is known as defaulting of inferred kinds. The standard approach is to default such polymorphic kinds to * (the kind of types). The problem is that failure of kind checking may be due to kind defaulting. Hence, we introduce a novel kind validation system that first performs kind checking to determine the most general kind environment. Then, we test that the actual inferred kinds agree with this kind environment. Our approach represents a nice application of the principal kinding property of monomorphic kind languages.

Language extensions

XHaskell – adding regular expression types and pattern matching to Haskell:Our overall goal is to add XDuce-style features to full Haskell.

In a first step we consider a type-driven translation from XDuce to Haskell (standard Hindley/Milner fragment) based on a structured representation of XDuce values. XDuce type inference guides the insertion of appropriate coercion functions such that the resulting Haskell program is type correct and reflects the meaning of the original XDuce program.

In an actual implementation, we plan to make use of the regular expression library mentioned below.

Regular expression library

We introduce a novel implementation of subtyping among regular expression types in terms of Haskell-style type classes by making use of two type class extensions. We require overlapping and co-inductive instances to encode a proof system to decide subtyping among regular expressions. We assume that each regular expression type has some underlying structured runtime representation. Hence, we not only check for the containment problem among regular expressions, but also automatically derive some appropriate casting functions among the underlying structured values.

Further reading

http://www.comp.nus.edu.sg/~sulzmann/chameleon/

With the generation of understandable type error messages in mind we have devised a constraint based type inference method in the form of the Top library. This library is used in the Helium compiler (for learning Haskell) (→2.6) developed at Universiteit Utrecht. Our philopsophy is that no single type inferencer works best for everybody all the time. Hence, we want a type inferencer adaptable to the programmer’s needs without the need for him to delve into the compiler. Our goal is to devise a library which helps compiler builders add this kind of technology to their compiler.

The main outcome of our work is the Top library which has the following characteristics:

• It uses constraints to build a constraint tree which follows the shape of the abstract syntax tree.

• These constraints can be ordered in various ways into a list of constraints

• Various solvers (specifically a fast greedy one, a slower global one, and the chunky solver which combines the two) exist to solve the resulting list of constraints.
• The library is easily extended with new constraints, and the type graph implementation includes various heuristics to find out what is the most likely source of an inconsistency. Some of these heuristics are very general, others are more tailored towards Haskell. Some the heuristics are fixed, like a majority heuristics which takes into account that there is ‘more’ evidence that a certain constraint is the root of an inconsistency. In addition, there are also heuristics specified from the outside. By means of a siblings directive, a programmer may specify that his experiences are that certain functions are often mixed up. As a result, a compiler may give the hint that (++) should be used instead of (:), because (++) happens to fit in the context.

• It preserves type synonyms as much as possible,

• We have support for type class directives. It allows programmers to for instance specify that certain instances will never occur. The type inferencer can use this information to give better error messages. Other directives can be used to specify additional invariants on type classes. For instance, that two type classes do not share a common type (Fractional vs. Integral). A paper about this subject will find its way into PADL 2005. Although we have implemented this into Helium, the infrastructure applies as well to other systems of qualified types.

• The various phases in type inferencing have now been integrated by a slightly different, more general choice of constraints.

An older version of the underlying machinery for the type inferencer has been published in the Proceedings of the Workshop of Immediate Applications of Constraint Programming held in October 2003 in Kinsale, Ireland.

The entire library is parameterized in the sense that for a given compiler we can choose which information we want to drag around.

The library has been used extensively in the Helium compiler, so that Helium can be seen as a case study in applying Top in a real compiler. In addition to the above, Helium also

• has a logging facility for building collections of correct and incorrect Haskell programs (including time line information),

• has a run-time parameters for experimenting with various solvers and constraint orderings.

• gives precise error location information,

• supports specialized type rules, which are a means to override the order in which certain expressions are inferenced and how the type error messages are formulated (see our paper presented at ICFP ’03). These type rules are especially useful for making the type error messages for domain specific extensions to Haskell correspond more closely to the domain, instead of the underlying Haskell language structures. The specialized type rules are automatically checked for soundness and completeness with respect to the original type system.

Since the report of November 2004

• Bastiaan Heeren has finished his PhD thesis, which has been accepted by the promotion committee. It can be downloaded from http://www.cs.uu.nl/people/bastiaan/phdthesis/.

• A paper was published in PADL 2005, discussing type inference directives for Haskell 98 type classes.

• A student is working on analyzing the loggings of Helium to obtain information about how students program, how ‘effective’ our hints are, and so on.

• A CD with the clean logged programs for two functional programming courses is available. If you have a need for such a CD, contact us, and we can discuss this.

• A second student is working on improving the hint facility for Helium, which generalizes the siblings and permutation facility.

• Other current work involves generating type inferencers.

Further reading

• Project website:

  http://www.cs.uu.nl/wiki/Top/WebHome

The purpose of the EHC project is to provide a description a Haskell compiler which is as understandable as possible so it can be used for education as well as research.

For its description an Attribute Grammer system is used as well as other formalisms allowing compact notation like parser combinators.

The EHC project also tackles other issues:

• In order to avoid overwhelming the innocent reader, the description of the compiler is organised as a series of increasingly complex steps. Each step corresponds to a Haskell subset which itself is an extension of the previous step. The first step starts with the essentials, namely typed lambda calculus.

• Each step corresponds to an actual, that is, an executable compiler. Each of these compilers is a compiler in its own right so experimenting can be done in isolation of additional complexity introduced in later steps.

• The description of the compiler uses code fragments which are retrieved from the source code of the compilers. In this way the description and source code are kept synchronized.

Currently EHC already incorporates more advanced features like higher-ranked polymorphism, partial type signatures, class system, explicit passing of implicit parameters (i.e. class instances), extensible records, kind polymorphism.

Part of these features has been described at the AFP 2004 summerschool (lecture notes yet to appear, handouts are available).

The compiler is used for small student projects as well as larger experiments such as the incorporation of an Attribute Grammar system.

Our plans for the near future are to complete the description of all steps.

We also hope to provide a Haskell frontend dealing with all Haskell syntactic sugar omitted from EHC.

Further reading

• Homepage:

  http://www.cs.uu.nl/groups/ST/Ehc/WebHome

• AFP handouts:

  http://www.cs.uu.nl/research/techreps/UU-CS-2004-037.html

• Attribute grammar system:

  http://www.cs.uu.nl/groups/ST/twiki/bin/view/Center/AttributeGrammarSystem

• Parser combinators:

  http://www.cs.uu.nl/groups/ST/Software/UU_Parsing/

Software development often consists of designing a (set of mutually recursive) datatype(s), to which functionality is added. Some functionality is datatype specific, other functionality is defined on almost all datatypes, and only depends on the type structure of the datatype.

Examples of generic (or polytypic) functionality defined on almost all datatypes are the functions that can be derived in Haskell using the deriving construct, storing a value in a database, editing a value, comparing two values for equality, pretty-printing a value, etc. Another kind of generic function is a function that traverses its argument, and only performs an action at a small part of its argument. A function that works on many datatypes is called a generic function.

There are at least two approaches to generic programming: use a preprocessor to generate instances of generic functions on some given datatypes, or extend a programming language with the possibility to define generic functions.

Preprocessors

DrIFT is a preprocessor which generates instances of generic functions. It is used in Strafunski (→4.3.3) to generate a framework for generic programming on terms. New releases appear regularly, the latest is 2.1.1 from April 2005.

Languages

Light-weight generic programming There are a number of approaches to light-weight generic programming. The latest contributions are from the ‘Scrap your boilerplate’ approach.

Generic functions for data type traversals can (almost) be written in Haskell itself, as shown by Ralf Lämmel and Simon Peyton Jones in the ‘Scrap your boilerplate’ (SYB) approach (http://www.cs.vu.nl/boilerplate/). The SYB approach to generic programming in Haskell has been further elaborated in the recently published (in ICFP ’04) paper “Scrap more boilerplate: reflection, zips, and generalised casts” and an unpublished paper “Scrap your boilerplate with class: extensible generic functions”. The former paper shows how to fill some of the gaps (such as generic zips) which previously were difficult to solve in this approach. The latter paper shows how you can turn ‘closed’ definitions of generic functions (not extensible when new data types are defined) into ‘open’, extensible, definitions.

Until now, there have been applications for which Hinze and Peyton Jones’s “Derivable type classes” would work, but SYB-style generic programming would not. The latest SYB paper shows how SYB-style programming can handle this class of applications too, so Simon is planning to remove derivable type classes from GHC (Section 7.11 of the GHC 6.4 user manual). Please let him know if that would be a problematic for you.

In “Generic proofs for combinator-based generic programs” (TFP 2004), Fermin Reig shows how to write generic proofs for generic programs that use the SYB library. The idea is that generic functions implemented using type classes can also be expressed in Generic Haskell, and this allows us to write more concise proofs.

Generic Haskell Andres Löh successfully defended his PhD thesis “Exploring Generic Haskell” on September 2, 2004. The thesis describes Dependency-style Generic Haskell, and introduces, amongst others, a new type system for Generic Haskell that at the same time simplifies the syntax and provides greater expressive power. Electronic copies are available at http://www.cs.uu.nl/~andres/ExploringGH.pdf.

The Coral release of the Generic Haskell compiler (January 2005) implements Dependency-Style Generic Haskell.

Generic Haskell is used in “Generic validation in an XPath-Haskell data binding” by Rui Guerra, Johan Jeuring, and Doaitse Swierstra, Plan-X 2005, to implement a typed Haskell-XPath data binding. Furthermore, Stefan Holdermans, Johan Jeuring and Andres Löh show how to add ‘views’ to Generic Haskell in “Generic views on data types” (http://www.cs.uu.nl/research/techreps/UU-CS-2005-012.html).

Current Hot Topics

Generic Haskell: inferring types of generic functions; finding transformations between data types. Other: the relation between generic programming and dependently typed programming; the relation between coherence and generic programming; better partial evaluation of generic functions; methods for constructing generic programs.

Major Goals

Major Goals: Efficient generic traversal based on type-information for premature termination (see the Strafunski project (→4.3.3)). Exploring the differences in expressive power between the lightweight approaches and the language extension(s).

Further reading

• http://repetae.net/john/computer/haskell/DrIFT/
• http://www.cs.chalmers.se/~patrikj/poly/
• http://www.generic-haskell.org/
• http://www.cs.vu.nl/Strafunski/
• http://www.cs.vu.nl/boilerplate/

There is a mailing list for Generic Haskell: <generic-haskell at generic-haskell.org>. See the homepage for how to join.

Background

The Haskell Cabal is a Common Architecture for Building Applications and Libraries. It is an API distributed with GHC, NHC98, and Hugs which allows a developer to easily group together a set of modules into a package.

HackageDB (Haskell Package Database) is an online database of packages which can be interactively queried by client-side software such as the prototype cabal-get. From HackageDB, an end-user can download and install packages which conform to the Cabal interface.

The Haskell Implementations come with a good set of standard libraries included, but this set is constantly growing and is maintained centrally. This model does not scale up well, and as Haskell grows in acceptance, the quality and quantity of available libraries is becoming a major issue.

It can be very difficult for an end user to manage a wide variety of dependencies between various libraries, tools, and Haskell implementations, and to build all the necessary software at the correct version numbers on their platform: previously, there was no generic build system to abstract away differences between Haskell Implementations and operating systems.

HackageDB and The Haskell Cabal seek to provide some relief to this situation by building tools to assist developers, end users, and operating system distributors.

Such tools include a common build system, a packaging system which is understood by all of the Haskell Implementations, an API for querying the packaging system, and miscellaneous utilities, both for programmers and end users, for managing Haskell software.

Status

We have made a 1.0 release of the first phase, Cabal, the common build system. Cabal is now distributed with GHC 6.4, Hugs March 2005, and nhc98 1.18. Layered tools have been implemented, including cabal2rpm and dh_haskell, for building Redhat and Debian packages out of Cabal packages. All of the fptools tree has been converted to using Cabal, as well as many other tools released over the last few months.

HackageDB, authored by Lemmih, is in a prototype phase. Users can upload tarred-and-gzipped packages to the database, and HackageDB will unpack them and make them available for clients via the XML-RPC (→4.7.5) interface. The prototype client, cabal-get, can download and install a package and its dependencies.

Further reading

• http://www.haskell.org/cabal
• http://www.haskell.org/cabal/proposal/

The PreludeExts wiki page started with an oft-pasted email on the #haskell IRC channel, where at least once a week someone asked for a permutations function. That sparked a discussion of what code is missing from the Prelude, once the wiki page was started, submissions poured in, resulting in a useful and interesting collection of functions. Last year’s PreludeExts has become this year’s BSD LicensedPreludeExts since John Goerzen wanted to have explicit licensing for inclusion into debian packages. If you contributed code to PreludeExts and haven’t yet moved it to LicensedPreludeExts, please do so!

http://www.haskell.org/hawiki/LicensedPreludeExts

My command line parsing module first reported in the November issue has just been updated to version 2. This is mainly a restructuring release. I’ve changed the module name from Pesco.Cmdline to System.Console.Cmdline.Pesco, to better fit into the overall hierarchical module namespace. Also the release now comes as a nice Cabal package (→4.1.1).

The code itself has been adapted it to use the ECT versioning scheme (→4.1.2) and has seen the addition of a minor but very convenient feature. In particular, the standard off-the-mill command line tool can now be written in a form like the following.

The module is available as a Cabal package named pesco-cmdline. It, and all associated documentation can be found on the website below, under the heading “System.Console.Cmdline.Pesco”.

As of yet, the module still does not support explicitly reporting errors, it always calls error. Also, it is still not possible to ignore unrecognized command line arguments (for chaining command line parsers) or errors in general. These points will be addressed in the next major revision.

Further reading

http://www.scannedinavian.org/~pesco/

Some time ago on the libraries mailing list there was a discussion about a replacement for Haskell’s IO library. The main aims are:

• To separate underlying IO objects (files, pipes, sockets etc.), from a general notion of Streams, providing improved
  1. Type Safety: certain operations only make sense for certain kinds of IO objects. For example hFileSize only makes sense on files, not sockets. Also, input streams would be separate from output streams.

  2. Generality: Under this scheme, programmers would be able to implement their own Streams (something which cannot be done with Handles).

• To allow translations to be layered on top of Streams in a general way. The most common type of translation is a text encoding, which translates between the external encoded form of text (say, UTF-8) and Haskell’s Unicode Char type. This addresses a serious deficiency in Haskell’s current IO library, namely the lack of support for specifying a character translation.

• More features: e.g. mapped file support.

See the libraries archives for the discussion, e.g.

• http://haskell.org/pipermail/libraries/2003-July/001298.html
• http://haskell.org/pipermail/libraries/2003-July/001299.html
• http://haskell.org/pipermail/libraries/2003-August/001313.html

Since the previous report some progress has been made on a prototype, which is available here: http://haskell.org/~simonmar/new-io.tar.gz.

The prototype currently supports only basic I/O using files, but has some support for internationalization. I (Simon M.) am not actively working on this at the moment, so anyone that would like to pick this up is entirely welcome.

The current release is 2.0.1. New, since the last report, is a complete re-write of the ASN.1 handling modules, the ability to handle keys stored X.509 certificates, the inclusion of Codec.Binary.Base64, lots of tests using HUnit and QuickCheck (→5.4.4) and the use of a darcs (→6.3) repository all packaged using Cabal (→4.1.1).

The library now supports: DES, Blowfish, AES, Cipher Block Chaining (CBC) mode, PKCS5 and nulls padding, MD5, SHA-1, Base64, RSA, OAEP, ASN.1, PKCS#8 and X.509.

The library follows the hierarchical standards and has Haddock (→5.5.6) style documentation. There are demo / test programs using published test vectors and instructions on how to use RSA in Haskell and inter-work with openssl. In particular, you can generate key pairs using your favorite method (openssl, for example) and then use them in Haskell. Not only can you now read a private key into your Haskell program via PKCS#8 and use it to decrypt something encrypted with your public key but you can also read a public key into your Haskell program via X.509 and use it to encrypt something for decryption using your private key.

There is still plenty of existing code that should be incorporated such as RC4 (courtesy of Doug Hoyte). With the new ASN.1 handling it should be straightforward to add a PKCS#12 module. The next piece of work is likely to be support for digital signatures.

All contributions are welcome.

Further reading

http://www.haskell.org/crypto

The hierarchy of numerical type classes is revised and oriented at algebraic structures. Axiomatics for fundamental operations are given as QuickCheck (→5.4.4) properties, superfluous superclasses 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. Both new types (like power series and values with physical units) and type classes (like the VectorSpace multi type class) are introduced. Using the revised system requires hiding some of the standard functions provided by Prelude, which is fortunately supported by GHC.

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, which will probably lead to mutual recursive dependencies.

Further reading

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

Haskore is a set of Haskell modules by Paul Hudak that allow music composition within Haskell, i.e. without the need of a custom music programming language. In general this project aims at improving consistency throughout the package, revising design decisions, fixing bugs, and eventually extending Haskore. In particular some improvements are: The Music structure is based on a more general temporal media data structure as proposed by Paul Hudak. The core Music data structure is hidden by functions that work on it. The support for infinite Music objects is improved. You can feed CSound with infinite music data through a pipe and you can feed an audio file player like Sox with an audio stream entirely rendered in Haskell (see Audio Signal Processing project (→6.16)) The test suite is now based on QuickCheck (→5.4.4) and HUnit. The AutoTrack project is adapted and included now.

Future plans

Introduce a more general notion of instruments which allows for more parameters that are specific to certain instruments. Allow modulation of music similar to the controllers in the MIDI system. Connect to other Haskore related projects. Adapt to the Cabal (→4.1.1) system.

Further reading

• http://www.haskell.org/hawiki/Haskore
• http://cvs.haskell.org/darcs/haskore/

Monads are very common in Haskell programs and yet every time one needs a monad, it has to be defined from scratch. This is boring, error prone and unnecessary. Many people have their own libraries of monads, and it would be nice to have a common one that can be shared by everyone. Some time ago, Andy Gill wrote the monad transformer library that has been distributed with most Haskell implementations, but he has moved on to other jobs, so the library was left on its own. I wrote a similar library (before I knew of the existence of Andy’s library) and so i thought i should combine the two. The “new” monadic library is not really new, it is mostly reorganization and cleaning up of the old library. It has been separated from the “base” library so that it can be updated on its own.

The monad transformer library now has its first official release. I have put it on my web page: http://www.cse.ogi.edu/~diatchki/monadLib

It is in many ways similar to what’s distributed with GHC/Hugs/etc, but I think also simplified and better organized. The library interface is documented with haddock (→5.5.6). The monads/transformers currently in the library are:

• ReaderT (environment)
• WriterT (output)
• StateT
• ExceptT
• BackT
• ContT

• Multiparameter classes (important).
• Rank-2 polymorphism (for the CPS implementations, could be removed).
• Functional dependencies (could be removed, but is likely to require more type annotations).

Further reading

http://www.cse.ogi.edu/~diatchki/monadLib

HBase is a large collection of library code, compiled “-fno-implicit-prelude”, intended as an experimental/alternative reorganized interface to the existing standard libraries making full use of GHC’s extensions. HBase development is driven by HScheme (→6.2) and my other Haskell projects, and sometimes by whatever interests occur to me. Right now it includes:

• a library of various classes of Functors and Monads,
• transformation, encoding and property functions for Unicode,
• types and classes for parsing,
• functions for parsing XML and RDF,
• code for constructing SQL queries,

Very little work is currently being done on it.

Further reading

http://sourceforge.net/projects/hbase/

Pointless Haskell is a library for point-free programming with recursion patterns defined as hylomorphisms. It is part of the UMinho Haskell libraries that are being developed at the University of Minho (→7.3.8). The core of the library is described in “Point-free Programming with Hylomorphisms” by Alcino Cunha.

Pointless Haskell also allows the visualization of the intermediate data structure of the hylomorphisms with GHood. This feature together with the DrHylo (→5.2.8) tool allows us to easily visualize recursion trees of Haskell functions, as described in “Automatic Visualization of Recursion Trees: a Case Study on Generic Programming” (Alcino Cunha, In volume 86.3 of ENTCS: Selected papers of the 12th International Workshop on Functional and (Constraint) Logic Programming. 2003).

Further reading

The Pointless Haskell library is available from http://wiki.di.uminho.pt/bin/view/Alcino/PointlessHaskell.

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 standard application plugins, hot swapping of modules in running applications, runtime evaluation of Haskell, and enables the use of Haskell as an application extension language. Version 0.9.8 has been released.

Further reading

Source and documentation can be found at http://www.cse.unsw.edu.au/~dons/hs-plugins.

MissingH is a library designed to provide the little “missing” features that people often need and end up implementing on their own. Its focus is on list, string, and IO features, but extends into other areas as well. The library is 100%pure Haskell code and has no dependencies on anything other than the standard libraries distributed with current versions of GHC and Hugs.

In addition to the smaller utility functions, recent versions of MissingH have added a complete FTP client and server system, a virtualized I/O infrastructure similar to Python’s file-like objects, a virtualized filesystem infrastructure, a MIME type guesser, a configuration file parser, GZip decompression support in pure Haskell, a DBM-style database virtualization layer, and a modular logging infrastructure, complete with support for Syslog.

Future plans for MissingH include adding more network client and server libraries, support for a generalized URL downloading scheme that will work across all these client libraries, and enhancing the logging system.

This library is licensed under the GNU GPL.

Further reading

http://quux.org/devel/missingh

Parsec is a practical parser combinator library for Haskell that is well documented, has extensive libraries, and good error messages. It is currently part of the standard Haskell libraries (in Text.ParserCombinators.Parsec) and has been stable for years now. We plan to add a module that adds combinators to parse according to the (full) Haskell layout rule (available on request).

Further reading

http://www.cs.uu.nl/~daan/parsec.html

Strafunski is a Haskell-based bundle for generic programming with functional strategies, that is, generic functions that can traverse into terms of any type while mixing type-specific and uniform behaviour. This style is particularly useful in the implementation of program analyses and transformations.

Strafunski bundles the following components:

• the library StrategyLib for generic traversal and others;
• precompilation support for user datatypes based on DrIFT (→3.5);
• the library ATermLib for data exchange;
• the tool Sdf2Haskell (→5.2.5) for external parser and pretty-print integration.

The Strafunski-style of generic programming can be seen as a lightweight variant of generic programming (→3.5) because no language extension is involved, but generic functionality simply relies on a few overloaded combinators that are derived per datatype. By default, Strafunski relies on DrIFT to derive the appropriate class instances, but a simple switch is offered to rely on the “Scrap your boilerplate” (→3.5) model as available in the Data.Generics library.

The Sdf2Haskell component of Strafunski has recently been extended to offer not only parsing support via the external “sglr” parser, but also:

• parsing support via HaGLR (→5.2.7), an experimental 100%Haskell implementation of Generalized LR parsing
• pretty-printing support, based on the pretty-print combinators as available in the Text.PrettyPrint.HughesPJ library. The generated pretty-printers are functional strategies that offer uniform behaviour which can be customized with type-specific behaviour.

Further reading

http://www.cs.vu.nl/Strafunski/

The Medina library is a Haskell library for GHC that provides tools and abstractions with which to build software metrics for Haskell programs.

The library includes a parser and several abstract representations of the parse trees and some visualization systems including pretty printers, HTML generation and callgraph browsing. The library has some integration with CVS to allow temporal operations such as measuring a metric value over time. This is linked with some simple visualization mechanisms to allow exploring such temporal data. These visualization systems will be expanded in the near future.

We have carried out case studies to provide some validation of metrics by looking at the change history of a program and how various metric values evolve in relation to those changes. In order to do this we implemented several metrics using the library, which has given some valuable ideas for improvements to the library.

Following on from the case studies we have improved and extended the visualization systems and implemented some of the ideas from the case studies. Demos and screenshots are available on the Medina webpage: http:/