Finally, here is the 9th edition of the Haskell Communities and Activities Report (HCAR), almost three weeks after the submission deadline. This delay is entirely my own fault. In fact, I have to thank the many contributors to this report even more than usually: never before did I have to ask and push so little; several entries (and quite a few new entries) landed in my inbox before or on the deadline. Thank you very much!
As most of you have probably be waiting for the Report a long time already and are eager to get ahead to the actual contents, let me just enumerate a few technical points:
As always, feedback is very welcome <hcar at haskell.org>. Now, I wish you pleasant reading!
Andres Löh, University of Bonn, Germany
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 the maintainers 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.
What can haskell.org do for you?
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.
More and more projects are being hosted on haskell.org. Also, the Haskell Workshop now has a permanent homepage http://haskell.org/haskell-workshop/.
Just what can you do for haskell.org? Here are a few ideas:
The #haskell IRC channel is a real-time text chat where anyone can join to discuss Haskell. #haskell averages about one hundred eighty users. 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 (→6.6), 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:
Feel free to add your own content!Sadly, the Haskell wikiwiki has changed to login only editing, due to unmanageable amounts of spam. You can create a user account here: http://www.haskell.org/hawiki/UserPreferences.
Haskell Weekly News is a newsletter summarizing each week’s activity in the Haskell community, and primarily the Haskell mailing lists. Each week’s issue is published on the general Haskell list as well as on the Haskell Sequence. To read HWN online, please visit http://sequence.complete.org/hwn.
Submissions from the public are welcomed in HWN. Information on submitting content to HWN is available at http://sequence.complete.org/hwn-contrib.
The Haskell Sequence is a community-edited Haskell news and discussion site. Its main feature is a slashdot-like front page with stories and discussion about things going on in the Haskell community, polls, questions, or just observations. Submissions are voted on by the community before being posted on the front page, similar to Kuro5hin.
The Haskell Sequence also syndicates Haskell mailing list posts, Haskell-related blogs, and other RSS feeds in a single location. Free space for Haskell-related blogs, which require no voting before being posted, is also available to anyone.
The Haskell Sequence is available at http://sequence.complete.org.
There are plenty of academic papers about Haskell, and plenty of informative pages on the Haskell Wiki. But there’s not much between the two extremes. The Monad.Reader aims to fit in there; more formal than a Wiki page, but less formal than a journal article.
Want to write about a tool or application that deserves more attention? Have a cunning hack that makes coding more fun? Got that visionary idea people should know about? Write an article for The Monad.Reader!
See the TmrWiki for more information: http://www.haskell.org/tmrwiki/FrontPage.
After many years of work, Programming in Haskell is now finished! The date for publication isn’t yet known, but is anticipated to be around early to mid 2006. Further details, including a preview of the book and powerpoint lecture slides for each chapter, are available on the web from http://www.cs.nott.ac.uk/~gmh/book.html.
I became aware of a placeholder page for a Haskell Wiki textbook over at the WikiBooks project. The URL is http://en.wikibooks.org/wiki/Programming:Haskell.
Since this looks like a Good Thing to have I’ve made a start. Of course there is no way that little old me could write the entire thing, so I’d like to invite others to contribute.
I’m aware of all the other Haskell Tutorials out there, but they are limited by being single-person efforts with no long term maintenance. This is not meant to denigrate the efforts of their authors: producing even a simple tutorial is a lot of work. But Haskell lacks a complete on-line tutorial that can take a programmer from the basics up to advanced concepts like nested monads and arrows. Once you get past the basics you tend to have to depend on library reference pages and the original academic papers to figure things out.
So what is needed is:
A Wikibook offers both of these.
Contributions are welcome. This includes edits to the table of contents (which seems to have been written by someone who doesn’t know Haskell) and improvements to my existing text (which I’m happy to concede is not exactly brilliant).
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!
http://www.scannedinavian.org/~pesco/man/html7/hs-manpage-howto.7hs.html
The last six months has been largely a consolidation phase for GHC. With one big exception, there are few new features.
For the current version of the API, see http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/, and look in ghc/compiler/main/GHC.hs. Please take a look and give us feedback.
There is lots more in the works:
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.
A new major release of Hugs is planned within a few months. As well as the steady trickle of bug fixes, this will include support for the Cabal infrastructure (→4.1.1), Unicode support (contributed by Dmitry Golubovsky) and lots of up-to-date libraries.
It should also include a Windows distribution. Thanks to testing by Brian Smith, the interpreter and the full set of libraries now build under MinGW. Neil Mitchell has rewritten the Windows interface (WinHugs), and this will be in the next release. A prerelease is available for testing on Neil’s WinHugs page (http://www-users.cs.york.ac.uk/~ndm/projects/winhugs.php).
Now that Hugs uses Cabal to build its libraries, it will soon be possible to split off libraries as separate Cabal packages, making the core Hugs source distribution smaller. Distributors of binary packages can decide whether to include library packages in an omnibus distribution or distribute them separately.
Support for obsolete non-hierarchical libraries (hslibs and Hugs-specific libraries) will disappear soon.
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 is version 1.18. Maintenance continues in CVS at haskell.org.
We are pleased that a student project, starting with nhc98’s sources, is aiming for a complete replacement of most of its parts. The working title is Yhc (→2.4), and currently it has an entirely new portable bytecode backend and runtime system. This solves many of the trivial but annoying problems with nhc98, such as lack of support for 64-bit machines, lack of good support for Windows builds, the high-memory bug, and so on.
The other parts of the compiler may be replaced too. The most urgent needs are to:
The York Haskell Compiler (yhc) is a backend rewrite of the nhc98 (→2.3) compiler to support features such as a platform independent bytecode and runtime system.
It is currently work in progress, it compiles and correctly runs almost every standard Haskell 98 program but FFI support is on going. Contributions are welcome.
http://www.cs.york.ac.uk/~ndm/yhc/
jhc is a Haskell compiler which aims to produce the most efficient programs possible via whole program analysis and other optimizations.
Some features of jhc are:
Jhc’s ideas are mainly taken from promising research papers that have shown strong theoretical results but perhaps have not been extended to work in a full-scale compiler.
Although jhc is still in its infancy and has several issues to work through before it is ready for public consumption, it is being quickly developed and volunteers are welcome.
Discussion about jhc development currently occurs on gale (gale.org) in the category pub.comp.jhc@ofb.net. A simple web client can be used at yammer.net.
| Report by: | Bastiaan Heeren |
| Participants: | Arjan van IJzendoorn, Bastiaan Heeren, Daan Leijen |
| Status: | stable |
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.3.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.
Work on our port of nhc98 (→2.3) to Palm OS is continuing at a slower rate than we would like. A few different strategies have been tried, based on our literate reworking of the nhc98 runtime kernel. The current state is that simple programs can be run on modern Palm hardware. Debugging and broadening of access to the Palm OS library functions is continuing. We hope to have an alpha release for others to try out by the end of the southern hemisphere summer break (February).
| Report by: | Keith Hanna |
| Status: | active (latest release: April 2005) |
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!
| Report by: | Keith Hanna |
| Status: | active (first release: November 2005) |
Pivotal 0.025 is a very early prototype of a Vital-like environment (→3.1.2) for Haskell. Unlike Vital, however, Pivotal is implemented entirely in Haskell. The implementation is based on the use of the hs-plugins library (→4.2.12) to allow dynamic compilation and evaluation of Haskell expressions together with the gtk2hs library (→4.5.3) for implementing the GUI.
At present, the implementation is only in a skeletal state but, nevertheless, it provides some useful functionality. The Pivotal web site provides an overview of its principles of operation, a selection of screen shots (including a section illustrating image transforms in the complex plane), and a (very preliminary!) release of the Haskell code for the system.
House is a platform for exploring various ideas relating to low-level and system-level programming in a high-level functional language, or in short for building operating systems in Haskell. House is based on hOp by Sébastien Carlier and Jérémy Bobbio.
Recent work includes
The House demo system is now implemented on top of the H monad. There is also work in progress on implementing an L4 compatible micro-kernel on top of H.
Further information, papers, source code, demos and screenshots are available here: http://www.cse.ogi.edu/~hallgren/House/
The Camila project explores how concepts from the VDM specification language and the functional programming language Haskell can be combined. On the one hand, it includes experiments of expressing VDM’s data types (e.g. maps, sets, sequences), data type invariants, pre- and post-conditions, and such within the Haskell language. On the other hand, it includes the translation of VDM specifications into Haskell programs.
Currently, the project has produced first versions of the Camila Library and the Camila Interpreter, both distributed as part of the UMinho Haskell Libraries and Tools (→7.3.9). The library resorts to Haskell’s constructor class mechanism, and its support for monads and monad transformers to model VDM’s datatype invariants, and pre- and post-conditions. It allows switching between different modes of evaluation (e.g. with or without property checking) by simply coercing user defined functions and operations to different specific types. The interpreter is implemented with the use of hs-plugins (→4.2.12).
The web site of Camila (http://wiki.di.uminho.pt/wiki/bin/view/PURe/Camila) provides documentation. Both library and tool are distributed as part of the UMinho Haskell Libraries and Tools (→7.3.9).
| Report by: | Niklas Broberg |
| Status: | experimental |
| Portability: | currently posix-specific |
Haskell Server Pages is an extension of Haskell for the purpose of writing server-side dynamic webpages. It allows programmers to use syntactic XML fragments in Haskell code, and conversely allows embedded Haskell expressions inside XML fragments. Apart from the purely syntactic extensions, HSP also provides a programming model with datatypes, classes and functions that help with many common web programming tasks. Examples include:
HSP can also be seen as a framework that other libraries and systems for web programming could use as a backend.
The HSP implementation comes in the form of a server application intended to be used as a plugin to web servers such as Apache. There is also a one-shot evaluator that could be used to run HSP in CGI mode, however some functionality is lost then, in particular application state. Both the server and the one-shot evaluator rely heavily on hs-plugins (→4.2.12).
Currently we have no bindings to enable HSP as a plugin to a webserver. The server can be run in stand-alone mode, but can then only handle .hsp pages (i.e., no images or the like), or the mentioned one-shot evaluator can be used for CGI. The system is highly experimental, and bugs are likely to be frequent. You have been warned.
http://www.cs.chalmers.se/~d00nibro/hsp
HASP is a fork of Niklas Broberg’s Haskell Server Pages (→3.1.6). Changes includes:
Some of the features implemented in HASP will be ported back into the main HSP tree. However, experimental features like byte code generation via the GHC api will most likely stay in HASP.
http://scannedinavan.org/~lemmih/hasp/
| Report by: | Niklas Broberg |
| Status: | stable, currently not actively developed |
| Portability: | relies on pattern guards, so currently ghc only |
HaRP is a Haskell extension that extends the normal pattern matching facility with the power of regular expressions. This expressive power is highly useful in a wide range of areas, including text parsing and XML processing. Regular expression patterns in HaRP work over ordinary Haskell lists ([]) of arbitrary type. We have implemented HaRP as a pre-processor to ordinary Haskell.
| Report by: | Phil Trinder |
| Participants: | Phil Trinder, Abyd Al Zain, Andre Rauber du Bois, Kevin Hammond, Leonid Timochouk, Yang Yang, Jost Berthold, Murray Gross |
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.
The first two items are linked by a British Council/DAAD project.
The GUM implementation of GpH is available in two development branches.
Our main hardware platform are Intel-based Beowulf clusters. Work on ports to other architectures is also moving on (and available on request):
http://www.macs.hw.ac.uk/~dsg/gph/
ftp://ftp.macs.hw.ac.uk/pub/gph/gum-4.06-snap-i386-unknown-linux.tar
<gph at macs.hw.ac.uk>
| Report by: | Phil Trinder |
| Participants: | Phil Trinder, Hans-Wolfgang Loidl, Jan Henry Nyström, Robert Pointon, Andre Rauber du Bois |
GdH supports distributed stateful interactions on multiple locations. It is a conservative extension of both Concurrent Haskell and GpH (→3.2.1), enabling the distribution of the stateful IO threads of the former on the multiple locations of the latter. The programming model includes forking stateful threads on remote locations, explicit communication over channels, and distributed exception handling.
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.2.1).
| Report by: | Phil Trinder |
| Participants: | Andre Rauber du Bois, Hans-Wolfgang Loidl, Phil Trinder |
Mobile Haskell supports both strong and weak mobility of computations across open networks. The mobility primitives are higher-order polymorphic channels. Mid-level abstractions like remote evaluation, analogous to Java RMI, are readily constructed. High-level mobility skeletons like mobile map and mobile fold encapsulate common patterns of mobile computation.
An alpha-release release of mHaskell is available on request from the mHaskell homepage. A number of applications have been constructed in mHaskell, including a stateless webserver, a distributed meeting planner and a mobile agent system. Mobility skeletons are being implemented in mobile Javas.
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 (→3.2.1). 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.
Survey and new standard referenceRita Loogen, Yolanda Ortega-Mallén and Ricardo Peña: Parallel Functional Programming in Eden, Journal of Functional Programming 15(3), 2005, pages 431-475 (Special Issue on Functional Approaches to High-Performance Parallel Programming)
Skeletons
Compilation and Profiling
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.
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!
http://www.cs.kent.ac.uk/~cr3/HCPN/
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)).
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.
Whilst at Durham, Conor McBride developed the Epigram prototype in Haskell, interfacing with the xemacs editor. Nowadays, a team of willing workers at the University of Nottingham are developing a new version of Epigram, incorporating both significant improvements over the previous version and experimental features subject to active research.
Peter Morris is working on how to build the datatype system of Epigram from a universe of containers. This technology would enable datatype generic programming from the ground up. There are ongoing efforts to develop the ideas in Edwin Brady’s PhD thesis about efficiently compiling dependently typed programming languages.
The first steps have been made in collecting recurrent programs and examples in some sort of standard library. There’s still a great deal of cleaning up to do, but progress is being made.
The Epigram system has also been used succesfully by Thorsten Altenkirch in his undergraduate course on Computer Aided Formal Reasoning for two years http://www.cs.nott.ac.uk/~txa/g5bcfr/.
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. Our implementation makes considerable use of monad transformers, higher-kind polymorphism and type classes. Moreover, its denotational approach translates Epigram’s lambda-calculus directly into Haskell’s. On a more practical note, we are currently in the process of cabalizing (→4.1.1) our code and moving to the darcs version control system (→6.6).
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 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://www.e-pig.org/epilogue/ will be much less rudimentary.
| Report by: | Martin Sulzmann |
| Participants: | Gregory J. Duck, Simon Peyton Jones, Edmund Lam, Peter J. Stuckey, Martin Sulzmann, Peter Thiemann, Jeremy Wazny |
| Status: | on-going |
Latest developments:
Extended algebraic data types subsume generalized algebraic data types (GADTs) and type classes with existential types. They are implemented in Chameleon and allow to express sophisticated program properties.
We have already formalized and are currently implementing a significant extension of the dictionary-translation scheme for type classes where type class proofs may make use of co-induction. Our translation scheme extends to deal with type improvement as found in systems of functional dependencies and associated type synonyms.
XHaskell is an extension of Haskell with XDuce style regular expression types and regular expression pattern matching. A prototype implementation, examples and a number of papers can be found under the XHaskell home-page.
| Report by: | Jurriaan Hage |
| Participants: | Bastiaan Heeren, Jurriaan Hage, Doaitse Swierstra |
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:
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
| Report by: | Atze Dijkstra |
| Participants: | Atze Dijkstra, Doaitse Swierstra |
| Status: | active development |
The purpose of the EHC project is to provide a description of 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 (AG) is used as well as other formalisms allowing compact notation like parser combinators. For the description of type rules, and the generation of an AG implementation for those type rules, we recently started using the Ruler system (→5.5.3) (included in the EHC project).
The EHC project also tackles other issues:
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 the description of the series of EH compilers is available as a PhD thesis, which incorporates previously published material on the EHC project.
The compiler is used for small student projects as well as larger experiments such as the incorporation of an Attribute Grammar system.
We also hope to provide a Haskell frontend dealing with all Haskell syntactic sugar omitted from EHC.
http://www.cs.uu.nl/groups/ST/Ehc/WebHome
http://www.cs.uu.nl/groups/ST/twiki/bin/view/Center/AttributeGrammarSystem
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.
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.2 from September 2005.
Light-weight generic programming There are a number of approaches to light-weight generic programming.
Generic functions for data type traversals can (almost) be written in Haskell itself (using many of the extensions of Haskell provided by GHC), 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 ’05) Scrap your boilerplate with class: extensible generic functions. This paper shows how you can turn ‘closed’ definitions of generic functions (not extensible when new data types are defined) into ‘open’, extensible, definitions.
The SYB approach to generic programming is used by James Cheney in his ICFP ’05 paper Scrap your nameplate, in which he shows how to deal with names, name-binding, and fresh name generation generically.
Ralf Hinze has turned his ICFP 2004 paper Generics for the masses into a journal paper, which is to appear in the special issue of Journal of Functional Programming on ICFP 2004. The paper shows how you can do a lot of generic programming already in Haskell 98 (without extensions).
The paper TypeCase: A Design Pattern for Type-Indexed Functions (Bruno Oliveira and Jeremy Gibbons, Haskell Workshop 2005) explains some of the techniques behind the so-called “lightweight approaches to generic programming” of Cheney and Hinze, and shows their use in some other contexts.
Generic Haskell In Type Inference for Generic Haskell, Alexey Rodriguez et al. show how to infer the base type for a restricted class of generic functions.
Alimarine et al. show how to implement invertible arrows in Generic Haskell in There and Back Again – Arrows for Invertible Programming (HW 2005).
Other Artem Alimarine defended his PhD thesis Generic Functional Programming in Nijmegen, The Netherlands, in September 2005. In this thesis he shows how to extend Clean with a generic programming construct. The extension is similar to the Derivable Type Classes approach in Haskell, but has been worked out to a greater extent. Alimarine shows, amongst others, how to optimize the code generated for instances of generic functions. A similar approach to code optimization has been used in Generic Haskell as well. The generic extension in Clean has been used, amongst others, to develop generic editors, a generic testing framework, and generic web applications. See http://www.cs.ru.nl/st/Onderzoek/Publicaties/publicaties.html for some recent papers on these applications of generic programming.
In the Lazy Polytypic Grid project Colin Runciman and collaborators intend to investigate the combination of generic programming with staged computation to develop visualization algorithms and applications that can be adapted to specific data representations and computational resources, and how, coupled with the use of demand-driven evaluation, these technologies can provide new ways of managing the visualization of large datasets.
Jeremy Gibbons presented a tutorial Design Patterns as Higher-Order Datatype-Generic Programs at ECOOP (Glasgow, July 2005) and OOPSLA (San Diego, October 2005).
Justin Ward, Garrin Kimmell, Perry Alexander present a paper entitled Prufrock: A Framework for Constructing Polytypic Theorem Provers at the ASE 2005.
Generic Haskell: finding transformations between data types. Adding type inference and views to the compiler. Other: the relation between generic programming and dependently typed programming; the relation between coherence and generic programming; methods for constructing generic programs.
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).
There is a mailing list for Generic Haskell: <generic-haskell at generic-haskell.org>. See the homepage for how to join.
The Haskell Cabal is a Common Architecture for Building Applications and Libraries. It is an API distributed with GHC (→2.1), NHC98 (→2.3), and Hugs (→2.2) 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.
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 (→7.4.1), 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. Since the 1.0 release, many features have been added including support for profiling.
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.7) interface. The prototype client, cabal-get, can download and install a package and its dependencies.
I’ve spent some thought on module versioning, i.e. how to avoid module breakage when external dependencies change their interface in newer versions. I think I’ve come up with a nice and simple solution which has been published in an article for The Monad.Reader (→1.5). Here’s the short intro:
As a program module evolves, functions and other elements are added to, removed from, and changed in its interface. It is clear that programs importing the module (it’s dependants) will not be compatible with all versions. At least, each program is compatible with one version, the one the author originally used, and usually a few ones before and after that. But if a program is not continuously updated, with time, chances rise dramatically that one of it’s dependencies as installed on a given host system will be incompatible. Alas, the program cannot be used. This effect comprises a major source of bit rot. To avoid such a situation, I suggest, in short, to append version numbers to module names, retaining the original name as a short-hand for “latest version”.
For the complete description, please see the article linked to below. It describes the scheme which I have dubbed “ECT” in detail, as a protocol to be followed by the module implementor. For what it’s worth, I have already adapted my own module System.Console.Cmdline.Pesco (→4.2.7) to use it.
If you are a module author, please have a look, tell me what you think, and consider adopting the ECT scheme yourself.
The PreludeExts wiki page started with an oft-pasted email on the #haskell IRC channel (→1.2), 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!
Hacanon-light is a lightweight FFI library that uses the Data Interface Scheme (DIS) from Hacanon (http://haskell.org/hawiki/Hacanon) and Template Haskell to provide a high level interface to marshaling/un-marshaling. It differs from Hacanon taking a passive role in the binding process; it won’t use or validate itself from any foreign header files.
Hacanon-light is meant to be used together with Zeroth (→5.5.2).
HODE is a binding to the Open Dynamics Engine. ODE is an open source, high performance library for simulating rigid body dynamics.
HODE uses Hacanon-light (→4.2.2) to simplify the binding process and Zeroth (→5.5.2) to avoid linking with Template Haskell.
http://scannedinavian.org/~lemmih/hode
| Report by: | Martin Erwig |
| Status: | active development |
The PFP library is a collection of modules for Haskell that facilitates probabilistic functional programming, that is, programming with stochastic values. The probabilistic functional programming approach is based on a data type for representing distributions. A distribution represent the outcome of a probabilistic event as a collection of all possible values, tagged with their likelihood.
A nice aspect of this system is that simulations can be specified independently from their method of execution. That is, we can either fully simulate or randomize any simulation without altering the code which defines it.
The library was developed as part of a simulation project with biologists and genome researchers. We plan to apply the library to more examples in this area. Future versions will hopefully contain a more systematically documented list of examples.
| Report by: | Marnix Klooster |
| Status: | Hmm 0.1 released, slow-paced development |
Hmm is a small Haskell library to parse and verify Metamath databases.
Metamath (http://metamath.org) was conceived and almost completely implemented by Norman Megill. It a project for formalizing mathematics, a file format for specifying machine-checkable proofs, and a program for generating and verifying this file format. Already more than 6000 proofs have been verified from the axioms of set theory.
Version 0.1 of Hmm has been released on October 17th, 2005.
The development version can be found at http://www.solcon.nl/mklooster/repos/hmm/. This is a darcs repository (→6.6).
Hmm can’t currently do more than just read and verify a Metamath file. However, the longer-term goal is to generate calculational proofs from Metamath proofs. As an example, the Metamath proof that cross-product distributes over union (see http://us.metamath.org/mpegif/xpundi.html) could be visualized something like this:
I am working towards this goal, slowly and step by step.
Process is a fun library for easing decomposition algorithms to several processes, which transmit intermediate data via Unix-like pipes. You can write, for example:
This lead to situation when Process, while more a syntactic sugar for well-known forkOS/MVar/Chan ingredients, than a “real” library, has become a very useful tool for assembling complex algorithms from simple pieces, which somehow transform data. This is like the situation of Unix popularity because it provides the same instruments for assembling together separate simple programs, but in this case you don’t transmit plain byte streams, but typed data.
| Report by: | Sven Moritz Hallberg |
| Status: | active development |
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.
TimeLib is an attempt to redesign the current library for handling time (System.Time), balancing expressive functionality and intelligible simplicity. Now at version 0.2, TimeLib features representation of TAI, UTC and UT1, as well as Gregorian, ISO 8601 week, and “year and day” calendars, time-zones, and functions for strftime-style formatting.
The source is in a darcs (→6.6) repository, and the API is viewable in haddock (→5.5.9) format.
The current release (2.0.3) is reasonably stable with just some bugfixes to the build since the last report.
All contributions are welcome.
| Report by: | Henning Thielemann |
| Participants: | Dylan Thurston, Henning Thielemann |
| Status: | experimental, active development |
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.
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.
A problem which is still not solved satisfyingly arises e.g. for residue classes and linear algebra. 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.
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 library is still alive and I am using it for my projects. I am not aware of any other users. For changes and the most recent version one can visit its website (see below).
Soon there will be a new release (1.5), the main changes of which are:
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. Version 0.9.10 has been released.
http://www.cse.unsw.edu.au/~dons/hs-plugins/
darcs get
ldap-haskell is a Haskell binding to C-based LDAP libraries such as OpenLDAP. With ldap-haskell, you can interrogate an LDAP directory, update its entries, add data to it, etc. ldap-haskell provides an interface to all the most common operations you would need to perform with an LDAP server.
darcs get http://darcs.complete.org/ldap-haskell
magic-haskell is a binding to the libmagic library. With magic-haskell, you can determine the type of a file by looking at its contents rather than its name. This library also can yield the MIME type of a file by looking at its contents.
This is often a more useful method than looking at a file’s name since it can yield correct results even if a file’s extension is missing or misleading.
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.
MissingPy is really two libraries in one. At its lowest level, MissingPy is a library designed to make it easy to call into Python from Haskell. It provides full support for interpreting arbitrary Python code, interfacing with a good part of the Python/C API, and handling Python objects. It also provides tools for converting between Python objects and their Haskell equivalents. Memory management is handled for you, and Python exceptions get mapped to Haskell Dynamic exceptions.
At a higher level, MissingPy contains Haskell interfaces to some Python modules. These interfaces include support for the Python GZip and BZip2 modules (provided using the HVIO abstraction from MissingH), and support for Python DBM libraries (provided using AnyDBM from MissingH (→4.2.15)). These high-level interfaces look and feel just like any pure Haskell interface.
Future plans for MissingPy include an expansion of the higher-level interface to include such things as Python regexp libraries, SSL support, and LDAP support.
This library is licensed under the GNU GPL.
| Report by: | Doaitse Swierstra |
| Status: | Released as cabal packages |
The Utrecht parsing Library and the associated Attribute Grammar System have been made available as cabal packages (→4.1.1), and as such may be easier to install.
The systems have been succesfully used by Niels van der Velde, one of our Master students, as part of a toolchain to assist in the parallelisation of C code. It seems that the lazy evaluation used inside is requiring quite some memory footprint.
One of our other master students, Joost Verhoog, is about to complete the alternative path to code-generation for te AG system, in which we follow te more traditional multi-pass attribute grammar evaluation schemes, as explained in the thesis of Joao Saraiva http://www.cs.uu.nl/wiki/Swierstra/SupervisedTheses. Our hope is that this will alleviate the aforementioned problem.
HSX aims to be a replacement of the libraries in Language.Haskell of the standard haskell-src package. The contribution is that HSX supports a good deal of the various syntactic extensions available, such as
Apart from these standard extensions, it also handles regular patterns as per the HaRP (→3.1.8) extension as well as HSP-style embedded XML syntax (→3.1.6).
| Report by: | Joost Visser |
| Status: | active, maintained, new release in November 2005 |
| Portability: | Hugs, GHC, DrIFT |
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 Strafunski-style of generic programming can be seen as a lightweight variant of generic programming (→3.4) 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.4) 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:
| Report by: | Jean-Philippe Bernardy |
| Status: | stable, maintained |
The standard collections data structures have recently been replaced by (a modified version of) Daan Leijen’s DData library.
Yet, many people would like them futher improved. Maintenance continues, with the goal to reach greater quality standards.
FPS provides packed strings (byte arrays held by a ForeignPtr), along with a list interface to these strings. This library provides a faster and wider range of operations than that found in the standard PackedString library, and is a port of the packed string code found in darcs. Such strings typically reduce the time and space requirements of a similar program based on [Char]. It also lets you do extremely fast IO in Haskell using mmap; in some cases, even faster than typical C implementations.
http://www.cse.unsw.edu.au/~dons/fps.html
darcs get
An efficient implementation of ordered sequences, based on (external, node oriented) 2-3 finger search trees as described in a recent paper by Ralf Hinze (see below).
With regard to asymptotic complexity, 2-3 finger search trees seem to be the best known purely functional implementations of ordered sequences, with the following amortized time bounds:
The project started as an exercise to explore the intriguing possibilities of nested data types to statically check data-structural invariants. One of my interests was to find out how much this helps development in practice. The results are nothing less than impressive to me. I am sure I would never have been able to produce anything as complicated with such a (relatively) low effort, had not the type system constantly guided me in the right direction.
Meanwhile, I think this could evolve into a generally useful library. A lot of work remains to be done, though: currently the library provides only the basic functionality and I have just started to get into performance measurements. I suspect some optimizations are possible, but haven’t yet looked into it very deeply. The code is mostly tested (and specified, thanks to QuickCheck (→5.4.4)), but hasn’t been used in a real application.
The library is not yet released, mainly because (lacking a personal homepage) I don’t have a convenient place on the web to host it. However, I plan to release a first alpha version soon.
| Report by: | Oleg Kiselyov |
| Developers: | Oleg Kiselyov, Ralf Lämmel, Keean Schupke |
HList is a comprehensive, general purpose Haskell library for strongly typed heterogeneous collections including extensible records. 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 list, elements of HList 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 labels. We have also used HList for type-safe database access in Haskell. HList-based Records form the basis of OOHaskell. The HList library relies on common extensions of Haskell 98.
The HList library has been extended to enable all recent OOHaskell examples and improve their efficiency. We added more specialized but more efficient implementations of the following Record operations: extension, field lookup, projection. These operations now have simpler types (with fewer constraints), which notably simplifies the inferred types of OOHaskell programs.
We added a function to narrow two records to their automatically computed least-upper bound. We defined functions nilLub and consLub to construct a homogeneous list out of heterogenous record components. The component records are automatically narrowed to their least-upper bound.
We are working on Cabalizing (→4.1.1) HList, expanding on the work by Einar Karttunen.