-- fourth edition --
Welcome to the fourth edition of our Haskell Communities and Activities
Reports! As always, the idea is to give regular snapshots of all things
Haskell, including a brief overview of the last 6 months and an outlook
of plans for the next 6 months, confirmation of maintainance for
existing software, and invitations to contribute to new and ongoing
discussions and developments in the numerous communities working on,
with or inspired by Haskell.
Editing these reports can be a trying experience at times, so pardon me
if I start with some frequently questioned answers that might help to
improve the process and ultimately the result:
Also, these reports have a wider distribution than the Haskell mailing
list where the calls for contributions are posted, and there are many
Haskell projects out there from which we have yet to receive summaries
of their work. So if you read this, and would like your work to be
represented in the next edition, please take out your diary:
Okay, enough of that, let's look at the contents. The trend towards
catering more and more for practical needs is unbroken, and is reflected
not only in tools, libraries, and applications. More and more emphasis
is also placed on how to organise delivery of Haskell software, how to
ensure compatibility, portability, documentation and other aspects of a
good user experience, and how to ease maintenance, to make sure that all
those goodies are there to stay.
Apart from the ongoing convergence of language and extensions supported
by Haskell implementations (2), the hierarchical
libraries are being fleshed out and ported, and there is an ongoing
discussion about streamlining the processes of contributing and
distributing "standard" libraries (4.1). Authors and users
of the currently so numerous GUI libraries are not only exchanging views
and tips, but have also resumed work towards a common API (4.3.1).
Again, it is no longer seen as sufficient to provide any kind of GUI,
but it has to be easily portable and maintable, and while platform
independence is one way to get there, user expectations about look&feel
are of increasing importance.
If one had to pick one area of particular success for Haskell, my bet
would be on domain-specific languages, and while most of these come in
the form of embeddings in Haskell, there is also a continuous flow of
stand-alone implementations (2.5 and 6). And of
course, there is steady and encouraging progress in support for
parallel, concurrent and distributed programming (3.2).
But now sit back and enjoy the read, then follow the pointers and try
things out, give the authors feedback on their work, discuss, contribute,
collaborate, or start your own little projects and excursions into
Haskell land. And, please, remember to come back in 6 months and
As always, this edition is the result of your work and contributions,
and so I'd like to close with a big thanks to all contributors!
University of Kent, UK
Editing these reports can be a trying experience at times, so pardon me if I start with some frequently questioned answers that might help to improve the process and ultimately the result:yes, we are interested in what you are doing with Haskell, especially so if it seems an unusual or new application area. Even to those not working in your particular area, such reports may suggest new inspirations. Yes, we do want to hear from maintainers of Haskell software even if there have been no new developments over the last 6 months. A brief confirmation that your software is still actively maintained helps potential users in their choice of tools. Yes, it would be much appreciated if everyone could submit their contributions by the end of April (for the May editions) and October (for the November editions). If you leave it late, you're holding up the distribution of information from those who contributed on time.
Also, these reports have a wider distribution than the Haskell mailing list where the calls for contributions are posted, and there are many Haskell projects out there from which we have yet to receive summaries of their work. So if you read this, and would like your work to be represented in the next edition, please take out your diary:submissions to the November edition are due by the end of October. If you you do not have the time follow the Haskell mailing list closely anymore and would like a personal reminder in mid October, just let me know now and I'll add you to the list!-)
Okay, enough of that, let's look at the contents. The trend towards catering more and more for practical needs is unbroken, and is reflected not only in tools, libraries, and applications. More and more emphasis is also placed on how to organise delivery of Haskell software, how to ensure compatibility, portability, documentation and other aspects of a good user experience, and how to ease maintenance, to make sure that all those goodies are there to stay.
Apart from the ongoing convergence of language and extensions supported by Haskell implementations (2), the hierarchical libraries are being fleshed out and ported, and there is an ongoing discussion about streamlining the processes of contributing and distributing "standard" libraries (4.1). Authors and users of the currently so numerous GUI libraries are not only exchanging views and tips, but have also resumed work towards a common API (4.3.1). Again, it is no longer seen as sufficient to provide any kind of GUI, but it has to be easily portable and maintable, and while platform independence is one way to get there, user expectations about look&feel are of increasing importance.
If one had to pick one area of particular success for Haskell, my bet would be on domain-specific languages, and while most of these come in the form of embeddings in Haskell, there is also a continuous flow of stand-alone implementations (2.5 and 6). And of course, there is steady and encouraging progress in support for parallel, concurrent and distributed programming (3.2).
But now sit back and enjoy the read, then follow the pointers and try things out, give the authors feedback on their work, discuss, contribute, collaborate, or start your own little projects and excursions into Haskell land. And, please, remember to come back in 6 months and report!-)
As always, this edition is the result of your work and contributions, and so I'd like to close with a big thanks to all contributors!
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 (<email@example.com>) 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? There are a lot of things we can do that are of use to members of the haskell community:
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:
Some of these ideas would be good student projects. Be lazy - get students to do your work for you.
The Haskell 98 Report (Revised) is now finally published, in electronic form at http://haskell.org/definition, as Vol 13(1) (Jan 2003) of the Journal of Functional Programming, and as a book published by Cambridge University Press.
The copyright issue was resolved by CUP granting unlimited copying rights, exactly as the previous version of the Report had. This is most unusual for a printed book, and is extremely generous of CUP. I hope you all go out and buy a copy!
I do not propose to make further changes to the Report, but I will continue to accumulate an errata list, so you can send me further bug reports! I have a few already (see the above URL).
Thank you to everyone who contributed. The result is something for us all to be proud of. I gave a "Retrospective on Haskell" talk at POPL'03, which you can find at http://research.microsoft.com/~simonpj/papers/haskell-retrospective
The last few months have been mainly consolidation for GHC. We made a couple more releases on the 5.04 branch, which is now very stable, and we are about ready to release GHC 6.0. The main new features in 6.0 will be
There are several other projects on the go:
We will almost certainly fold this into the main GHC development trunk sometime in the next few months.
Hugs is a very portable, easily installed Haskell-98 compliant interpreter that supports a wide range of type-system and runtime-system extensions including typed record extensions, implicit parameters, the foreign function interface extension and the hierarchical module namespace extension.
The Hugs98 interpreter is now maintained by Sigbjorn Finne and Jeffrey Lewis, both of Galois Connections, with help from Alastair Reid of Reid Consulting and Ross Paterson of City University London and others.
The last major release (November 2002) greatly improved compatibility between Hugs and GHC by providing a significant subset of GHC's hierarchical libraries and adding the standard FFI interface extension.
Since the last release, Hugs has undergone an internal cleanup to aid future development: long-dead features are being removed and internals are being reorganized. As promised in the previous report, future releases will not have as much backwards compatability as the last release. Ross Paterson is adding many of the hierarchical libraries omitted from the last release. We are also making moves to create a new users guide which documents all of Hugs' extensions and recent additions.
nhc98 is a small, easy to install, standards-compliant compiler for Haskell 98, the lazy functional programming language. It is very portable, and aims to produce small executables that run in small amounts of memory. It produces medium-fast code, and compilation is itself quite fast. It also comes with extensive tool support for automatic compilation, foreign language interfacing, heap and time profiling, tracing, and debugging.
The latest release of nhc98 is 1.16, available since early March, and its features of note are:
The nhc98 compiler is pretty stable and reliable and we don't have any particular plans for new features. Bugfixes will appear as and when necessary. However, you users may have ideas for exciting things to add into the compiler, and you are encouraged to get your hands dirty, implement them, and submit them for distribution.
Hmake is an intelligent compilation management tool for Haskell programs. It automatically extracts dependencies between source modules, and issues the appropriate compiler commands to rebuild only those that have changed, given just the name of the program or module that you want to build.
The latest release of hmake is 3.07, available since early March. This fresh version has the following improved configuration features over previous releases:
It has been suggested that hmake should allow the external configuration of different source code preprocessors in a similar manner to the way it currently supports different compilers. This sounds like a useful idea, which we will probably introduce sometime soon.
In addition to the well known major Haskell implementations, there are now several domain-specific implementations, where suitability for the intended application domain is deemed more important than full support for Haskell 98, or where indeed the language subset and design modifications have been explicitly tailored to the domain..
In 2002 one of our honours students, Matthew Tarnawsky, completed an initial port of the nhc98 runtime to Palm OS. The port is only really of alpha status, but simple programs can be compiled and linked on a desktop machine, installed on a Palm and executed. Limited support for interfacing with the Palm OS GUI libraries is included.
Our current work (cf. section 6.4.4) involves redoing the implementation to bring it up to the latest release of nhc98, reconsidering some of the design decisions made during Matthew's project, and improving the integration with Palm OS. We hope to have a beta version and a report ready for submission to this year's Haskell workshop.
(Arjan van IJzendoorn, Bastiaan Heeren, Daan Leijen, Rijk-Jan van Haaften)
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. We try to give useful feedback for often occurring mistakes. To reach this goal, Helium uses a sophisticated type checker described in section 3.3.2. Helium now 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 (section 6.4.5). One of the aspects of the compiler is that it also logs errors, so we can track the kind of problems students are having, and improve the error messages and hints. The compiler uses Daan Leijen's LVM (Lazy Virtual Machine) as back-end. The LVM uses a portable instruction set and file format that is specifically designed to execute lazy higher-order languages.
The goal of this project is to bring functional programming to users that are not trained computer scientists or programmers. We feel that the simplicity of functional programmiung makes it an ideal way to introduce programming language concepts to students of all ages. We also believe that domain specific languages based on Haskell can enhance learning in other domains such as mathematics.
Our languages are media oriented. They allow students to explore the basic principles of functional programming while creating images, animations, or music.
These languages have been used for high school mathematics education, an introduction to functional programming for students in high school programming classes, and as a gentle way to present functional programming in a programming language survey class. The graphics language (Pan#) is capable of handling all of the examples in Conal Elliott's Fun of Programming chapter.
There are two languages under development. The first is Pan#, a port of Conal Elliott's Pan compiler to the C#language. This runs on Windows using .NET and is very easy to install and use. This probably would run on Linux using Mono (.NET for other platforms) but we have not attempted this yet. The front end of this system is a mini-Haskell interpreter which is currently somewhat unsophisticated - we plan to customize Helium (section 2.5.2) for this purpose in a future release. Our website contains a number of examples produced by this language and some instructional materials.
Our second language describes music using Paul Hudak's Haskore system. We are currently re-packaging Haskore using Helium to make the system more student friendly.
Vital is a Haskell-based, visual environment intended for the interactive, exploratory development of programs by non computer-specialist end-users (engineers, analysts, etc.).
In the environment, each Haskell module is associated with a worksheet on which its declarations and expressions may be located and their values graphically displayed (in a form determined by a type-indexed stylesheet).
The environment embodies the principles of direct manipulation. In particular, it allows the graphical displays to be edited by mouse gesture (for example, the values in an array or the shape of a tree might be changed) with such changes being reflected in the Haskell source code.
A release of a fairly comprehensive implementation of Vital is planned for this summer.
Project Status: Version 1.0 (RC8)
The Haskell 98 FFI Addendum is meanwhile up to Release Candidate 8, which resolves the issues surrounding finalizers for foreign objects that was mentioned in the previous HC&A Report. The current interface definition is available from
Concurrent Haskell is a set of extensions to Haskell to support concurrent programming. The concurrency API (Concurrent) has been stable for some time, and is supported in two forms: with a preemptive implementation in GHC, and a non-preemptive implementation in Hugs. The Concurrent API is described here:
There is an ongoing discussion to decide how Concurrent Haskell should work in a system with OS-level threading; in particular what minimal support is required to give the programmer enough control over the correspondence between OS-level threads and Haskell threads in order to use some existing foreign-language libraries that make use of OS thread-local state. The discussion is taking place on the FFI list; see http://www.haskell.org/pipermail/ffi/
Wolfgang Thaller summarizes: All current implementations of Concurrent Haskell do their own scheduling; none currently use the thread functionality provided by the OS; instead, they execute all Concurrent Haskell threads in one OS thread. This has some advantages (much better performance, for example), but it also causes problems. Some foreign libraries (most notably OpenGL) rely on using thread-local state for their interface. Using these libraries from multiple Haskell threads leads to major confusion. These libraries can currently only be used from a single thread by Haskell programs, or sometimes even not at all. Over the past months, I've been "annoying" people on the FFI mailing list by posting various proposals on how to deal with this problem. The general idea is to "bind" some Haskell threads to specific OS threads; all foreign calls from those threads are guaranteed to be executed in a dedicated OS thread, so that thread-local state causes no problems anymore. I'm also planning to implement the proposal that we'll finally agree on for GHC, hopefully before the next major release.
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:
|Madrid:||Ricardo Peña, Yolanda Ortega-Mallén,|
|Mercedes Hidalgo, Rafael Martinez, Clara Segura|
|Marburg:||Rita Loogen, Jost Berthold, Steffen Priebe|
Eden extends Haskell by 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 expression process x -> e of a predefined polymorphic type Process a b defines a process abstraction mapping an argument x::a to a result expression e::b. Process abstractions of type Process a b can be compared to functions of type a -> b, the main difference being that the former, when instantiated, are executed in parallel. Process instantiation is achieved by using the predefined infix operator (#) :: Process a b -> a -> b.
Higher-level coordination is achieved by defining higher-order functions over these basic constructs. Such skeletons, ranging from a simple parallel map to sophisticated replicated-worker schemes, 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 (section 3.2.2). 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 Eden runtime system has recently been restructured to exhibit a layered structure. The main idea has been to specify the process control in Haskell and to restrict the extensions of the low-level runtime system to a few selected primitive operations. Details can be found in the forthcoming Euro-Par paper "High-level Process Control in Eden". The current (freely available) implementation is based on GHC 5.02.3. A source code version is available via the ghc CVS repository with tag eden-5-02-3. We are eager to catch up to the current ghc version.
We use Constraint Handling Rules (CHRs) to describe various type class extensions. Under sufficient conditions on the set of CHRs, we have decidable operational checks which enable type inference and ambiguity checking for type class systems.
We have incorporated the ideas of the CHR-based overloading approach into an actual programming language called Chameleon. The syntax of Chameleon follows mostly Haskell. We plan to use Chameleon as an experimental test-bed for possible type system extensions. Recent developments:
With the generation of understandable Haskell error messages in mind we have devised a constraint based type inference method which is currently being used in the Helium (section 2.5.2) compiler developed at Universiteit Utrecht.
The main characteristics of the inferencer are the following.
At this point, the Helium compiler does not include type classes, records and a few other elements of Haskell. Type classes shall be included in one form or another on short notice. Our type inferencer shall be extended accordingly.
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.
The Generic Haskell release of last summer supports type-indexed data types, dependencies between generic functions, and special cases for constructors (besides the `standard' type-indexed functions and kind-indexed types). These extensions are described in the "Type-indexed data types" paper presented at MPC'02, and the "Generic Haskell, Specifically" paper at WCGP'02. The new Generic Haskell release was used in the Summer School in Generic Programming in Oxford last August, at which Ralf Hinze and Johan Jeuring presented two tutorials: Generic Haskell - theory and practice, and Generic Haskell - applications. The former tutorial introduces Generic Haskell, and gives some small examples, the latter tutorial discusses larger applications such as an XML compressor. The tutorials will appear in LNCS.
A small group at Chalmers is working under the slogan "Functional Generic Programming - where type theory meets functional programming" (http://www.cs.chalmers.se/~patrikj/poly/), and has written a paper on different universes of codes for types (avaliable upon request). PolyP is not really actively developed anymore, but a new version using a class-based translation is available upon request.
Roland Backhouse and Jeremy Gibbons will start a project on datatype-generic programming in August 2003. The goal of this project is, amongst others, to develop a methodology for constructing generic programs.
There is a mailing list for Generic Haskell: <firstname.lastname@example.org>. See the homepage for how to join.
The recursive do-notation (a.k.a. the mdo-notation) is supported by all Hugs releases since February'01. For GHC (as of 5.04.3), only the latest CVS version supports mdo. (The next major release for GHC will include direct support.) Both implementations are stable and actively supported.
Portability of the hierarchical libraries is improving: Hugs has shipped a new version with a substantial subset of the hierarchical libraries, and the NHC is rumoured to work with some of these libraries too.
The hierarchical replacement for the old Posix library is about 95% complete, and will ship with the next release of GHC.
An important issue that remains to be addressed satisfactorily is the means by which implementations of libraries are contributed to the community. A discussion on this subject was recently started on the Haskell mailing list: http://www.haskell.org/pipermail/haskell/2003-April/011624.html If you have opinions or ideas, please contribute to the discussion.
Contributions of documentation for libraries are still needed: many of the implementations of "standard" libraries that originated in the Haskell 98 language &library reports are poorly documented, and in many cases not documented at all beyond the basic documentation that Haddock extracts from the source.
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.
Recent papers on Strafunski cover application domains such as Cobol reverse engineering, Java software metrics, and Haskell reengineering:
The current Strafunski release followed closely the previous edition of this HC&A report (November 2002). Strafunski bundles now the following components:
The Strafunski-style of generic programming can be seen as a lightweight variant of generic programming (section 3.4) because no language extension is involved, but generic functionality simply relies on a few overloaded combinators that are derived per datatype.
The Haskell DSP library has grown by leaps and bounds since I resurrected the project a few months ago. The webpage hasn't been updated in a few weeks, but represents what functions are available.
In particular, there is an FFT library that works for real and complex data, and for all sizes sizes of N. It is also designed to make it easy for users to experiment with gluing together the algorithms in their own way. There are functions for basic DSP functions such as correlation, convolution, FIR filtering, and IIR filtering. Work has begun on adding functions for both FIR and IIR filter design. There are also algorithms for frequency and spectral estimation.
Some of the modules have broader applications than just DSP. I will be soliciting comments and opinions on this on the libraries list in a few weeks.
There are some bits and pieces that rely on GHC extensions, otherwise, it should work with all Haskell98 implementations.
While still experimental, it is currently usable. The library was used to verify methods and generate data for an article submitted to the IEEE Signal Processing Magazine.
Work is underway to migrate everything to a hierarchical library, add Haddock style documentation, and provide more demo applications. Be warned, though, that the API is experimental and will likely change.
If anyone uses the library, please let me know what you think.
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 and, fortunately, no new bugs have been reported for a while now. We plan to update Parsec this summer by fixing some naming issues within the new hierarchical namespace, bringing the standalone version in sync with the GHC version, and by adding a module that adds combinators to parse according to the (full) Haskell layout rule.
DData is a library of efficient data structures and algorithms for Haskell (Set, Bag, and Map). I noticed that I used these data structures (and algorithms) a lot, but surprisingly, there are not many "off the shelf" libraries available. The modules are extensively documented and are not dependent on each other or other support modules. The modules are implemented to be easy to use (just import it), efficient (use the best known implementation techniques), and fairly complete (lots of operations).
Yampa is the culmination of the Yale Haskell Group's efforts to provide domain-specific embedded languages for the programming of hybrid systems. Yampa differs from previous FRP based system in that it makes a strict distinction between signals (time-varying values) and functions on signals. This greatly reduces the chance of introducing space and time leaks into reactive, time-varying systems. Another difference is that Yampa is structured using the arrow combinators. Among other benefits, this allows Yampa code to be written employing the syntactic sugar for arrows.
We have released a preliminary version of Yampa that contains:
With the Base Library and HGL (or any other graphics library), it is easy to write reactive animation programs in the style of Fran. Thus there is no need for a special library to support graphics and animation.
Haskell continues to attract new approaches to GUI library provision. If all past Haskell GUI libraries were still in existence, and still maintained, and available on all platforms, one could easily use a different one for each window. Unfortunately most of them aren't, aren't, and never were.
Currently, we seem to have entered a new era of GUI diversity, and it is encouraging that so many Haskellers are able to create new GUI bindings from scratch when the existing ones do not suit their needs (in addition to those listed here, see also Mike Thomas' entry on Japi in section 6.5).
Even more encouraging, however, is that todays GUI developers are very much concerned with practical issues (how easy is it to create and maintain a GUI library, how easy is it to port to the major platforms, what GUI library users want). Difficulties encountered during attempts to port the otherwise very promising ObjectIO to Gtk have also restarted the discussions and activities towards a common, platform independent GUI API on the gui mailing list.
Haskell suffers from too many half-baked GUI libraries. This task force set out to define a common GUI API (CGA for short) that defines a portable interface for all major platforms. A discussion early this year resulted in the following requirements:
The discussion is open to everyone. We discuss on the <email@example.com> mailing list. Documents we create are available in the Haskell CVS repository at http://cvs.haskell.org/cgi-bin/cvsweb.cgi/haskell-report/gui/.
HTk is an encapsulation of the graphical user interface toolkit and library Tcl/Tk for the functional programming language Haskell. It allows the creation of high-quality graphical user interfaces within Haskell in a typed, abstract, portable manner. HTk is known to run under Linux, Solaris, Windows 98, Windows 2k, and will probably run under many other POSIX systems as well. It works with GHC, versions 5.02.3 and later.
The Object I/O is a flexible library for building rich user interfaces. It is a port of the popular Clean Object I/O to Haskell (http://www.cs.kun.nl/~clean/). The current implementation for Clean and Haskell supports only the Windows platform. Attempts to port the Haskell version to Gtk turned out to be difficult, highlighting platform-specific assumptions in the design, and prompting a renewed discussion on portable GUI APIs on the gui mailing list.
While the implementation is still available, it is no longer developed or maintained (Krasimir is now working on a successor, HToolKit, see below).
The main objectives are:
wxHaskell is a Haskell binding to the wxWindows GUI library. The wxWindows library is a large C++ library that is portable to all major GUI platforms - Windows, GTK, Motif, X11, MacOS 9, and MacOS X. Furthermore, it is a mature library (in development since 1992) that supports a wide range of widgets with a native look-and-feel.
We hope that this "industrial strength" library can serve as the standard low-level GUI library for Haskell. By using a standard library like wxWindows we will be able to support a wide range of platforms and widgets with almost no effort on our side -- we just have to keep in sync with the library. Note that the languages Eiffel, Perl, and Python have also chosen this library for writing complex graphical user interfaces (wxEiffel, wxPerl, and wxPython respectively).
The "core" Haskell binding to wxWindows is generated automatically from the wxEiffel binding and contains about 2500 methods in 500 classes with 1000 constant definitions. As such, most of the wxWindows functionality is supported, just excluding more exotic widgets like dockable windows and the OpenGL canvas. On top of the core binding, we are writing a small library that offers a somewhat more friendly interface to the raw wxWindows interface. This library is closely structured after GIO and Yahu.
The project is in its startup phase - no binary releases have been made and only development is supported. The library has currently only been tested on win32 and GTK (Linux) platforms with GHC 5.03+ and only small examples have been written. We plan to release the initial alpha release in May 2003.
Project Status: beta release
Gtk+HS is a Haskell binding to the GTK+ GUI toolkit http://www.gtk.org/, which is currently at version 0.15.2. Since the last HC&A Report, it has acquired a range of new widgets as well as significantly extended support of the iHaskell layer, which enables GUI programming without mutable variables.
Gtk2hs is a wrapper around the latest Gtk release (Version 2.2 or Gtk 2 for short). Although it provides a similar low level veneer like Gtk+HS, it is completely rewritten from scratch, reflecting the new object hierarchy of Gtk 2. The binding works on Unix, MacOS X and Windows (mingw32). A thin wrapper called MOGUL (MOnadic GUi Library) provides some convenience functions and will be extended to exhibit the Common GUI API once it is defined. All widgets are bound, although a couple of functions are still missing. Future additions will include the OpenGL widget GtkGLExt and the Pixbuf image manipulation library.
Our current work is done in a CVS repository which can be found on http://sourceforge.net/projects/gtk2hs/.
The HGL provides an easy to use, portable interface to Win32 and X11 which supports simple 2-dimensional graphics, keyboard, mouse and timer input events and multiple windows. The library is distributed as open source and is suitable for use in teaching and in applications.
Status: The library works on both Win32 and X11 under Hugs and GHC. The API is stable and the library is used throughout Paul Hudak's `School of Expression' textbook. The last release was 2.0.4 in December 2001. A release that works better with the new release of Hugs (notably the support for hierarchical module namespace) and current releases of GHC will be available soon.
School of Expression web page:http://haskell.org/soe/
Author's web page:
The Win32 library is a set of bindings to over 450 functions in the standard Windows C libraries.
Portability: GHC, Hugs, Windows
The Xlib library is a set of bindings to over 300 functions in the standard Xlib C library.
Portability: GHC, Hugs, Linux, FreeBSD, Solaris, MacOS X
Status: These libraries have been distributed for Hugs for some years and have worked with GHC for almost as long but they have suffered from second class status since they have always been treated as just one of the prerequisites for installing the HGL. We have recently moved them over into the hierarchical namespace and are almost ready to make a proper release.
The goal of this project is to provide a binding for the OpenGL rendering library which utilizes the special features of Haskell, like strong typing, type classes, modules, etc., but is still in the spirit of the official API specification. This enables the easy use of the vast amount of existing literature and rendering techniques for OpenGL while retaining the advantages of Haskell over lower-level languages like C. Portability in spite of the diversity of Haskell systems and OpenGL versions is another goal.
HOpenGL includes the simple GLUT UI, which is good to get you started and for some small to medium-sized projects, but HOpenGL doesn't rival the GUI task force efforts in any way. Smooth interoperation with GUIs like gtk+hs on the other hand is a goal.
The latest release (version 1.04 on 21/01/03) marks the beginning of API transition: The GLUT binding has been rewritten completely, using only Haskell-98 features plus FFI and hierarchical modules, both widely available extensions. Furthermore, using quadrics and tessellators has been vastly simplified, offering a much more Haskell-like interface. The rest of HOpenGL is currently being rewritten, too, people interested in the latest development can check out the libraries part of GHC's fptools repository. A new release is planned for Q3 2003, offering:
The objective of the FunGEn project is to create a high-level game engine in and for Haskell. A game engine, roughly speaking, is a tool intended to help game programmers to develop games in a faster and automated way, avoiding them to worry about low-level implementation details. The main advantage of using a game engine is that, if it is built in a general and modular architecture, it can be used to develop many different (types of) games.
The first release of FunGEn (April/2002) consisted of a 2D platform-independent game engine, which implementation was based in HOpenGL (Haskell Open Graphics Library). It supported:
Some feedback indicated that the first version of FunGEn was not as "functional" as it was desired: some game issues were still being dealt through an imperative fashion. This way, the authors of this project decided to change the game engine philosophy: programmers should describe a game as a set of "specifications" rather than defining its behavior imperatively. The chosen alternative for accomplishing this task was to port the Clean Game Library (CGL) to Haskell, adding some FunGEn/(H)OpenGL specific features, such as mouse handling. Hence, the main idea is to rebuild FunGEn, in order to provide game programming mechanisms following the CGL concepts.
This rebuilding task, however, is taking much more time than initially planned. Some very complex (and still unexplained) environment setup problems froze the engine development for months. The authors of the FunGEn project concluded that the heterogeneous environment in which the software was being produced had become impracticable: Windows98 and Cygwin presented many compatibility problems regarding HOpenGL, GHC and FunGEn setup.
As the development environment has changed (WindowsXP is being used instead of Windows98), FunGEn finally had a chance to evolve again. Unfortunately, new problems are still challenging the project: some compatibility issues arising from the use of the most recent version of HOpenGL had to be solved and some difficulties regarding Haddock compatibility with Cygwin is demanding special attention.
Besides all problems, the authors of the project expect a new version to be released as soon as possible.
The final objective of FunGEn is to support both 2D and 3D environments, some game programming tools (such as map editors) and advanced game functionalities (such as multiplayer networking), although it is actually far away from that.
FunGEn is being maintained at the Informatics Center (Centro de Informatica) of Universidade Federal de Pernambuco (UFPE), by Andre W B Furtado (assisted by lecturer Andre Santos), and it's wide open for any implementation contributions. We would like to thank Mike Wiering, the creator of Clean Game Library.
http://cleangl.sourceforge.net/ (Clean Game Library)
FunWorlds is an ongoing experiment to investigate language design issues at the borderlines between concurrent systems, animated reactive 2&3d graphics, and functional programming. One of the aims is to get a suitable platform for expressing such things visually, preferably from Haskell, continuing from the start that functional reactive programming and especially Conal Elliott's Fran made in that direction.
With the reimplementation of FunWorlds on top of HOpenGL (earlier versions were based on VRML), the focus has shifted towards a redesign of some fundamental FRP concepts, towards a simpler operational semantics as a basis for uncomplicated implementations with more predictable performance characteristics. At the same time, I still want to be able to use Fran's high-level modeling approach.
The initial release has been delayed, simply because I haven't been able to allocate much time for this project. The stopping stone is not so much functionality (the first release will not have substantially more functionality than the snapshot presented at IFL'2002, so it will be pretty basic), but the need to write some form of introductory tutorial on the new DSEL design and how one might use it. Once we've got some more experience with the language basics, graphics functionality will be added on demand.
The good news is that trying to write the tutorial and examples has forced me to simplify the language still further (whenever something seems to require complicated explanations, I go back and try to simplify the design and implementation instead, maintaining expressiveness). If I don't manage to get back to this project soon to prepare a proper release, I'll probably just make snapshots available to interested parties.
Instead of developing fixed tools, it is sometimes possible to generalize the code implementing the tool functionality into a library, so that the code can be reused for a family of tools.
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 visualisation 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 visualisation mechanisms to allow exploring such temporal data. These visualisation systems will be expanded in the near future.
Currently we are working on some 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 have implemented several metrics using the library, which has given some valuable ideas for improvements.
HaXml provides many facilities for using XML from Haskell.
The latest release of the HaXml suite of libraries and tools is 1.09, just about to be published.
HaXml is in stable (bugfixes only) mode at the moment. Users regularly contribute improvements, which are usually adopted strightforwardly.
HXML is a non-validating XML parser written in Haskell. It is designed for space-efficiency, taking advantage of lazy evaluation to reduce memory requirements. HXML may be used as a drop-in replacement for the HaXml (section 4.6.1) parser in existing programs. HXML includes a module with functionality similar to HaXml's `Combinator' module, but recast in an Arrow-based framework.
HXML also provides multiple representations for XML documents: a simple algebraic data type containing only the essentials (elements, attributes, and text), a tree representation which exposes most of the full XML Information Set, and a navigable tree representation supporting all of the principal XPath axes (ancestors, following-siblings, etc).
HXML has been tested with GHC 5.02, GHC 5.04, NHC 1.12, and most recent versions of Hugs. NHC 1.10 requires a patch. HXML is basically in maintenance mode right now until I can find some spare time; support for XML Namespaces is next on the TODO list.
The Haskell XML Toolbox is a collection of tools for processing XML with Haskell. It is itself purely written in Haskell. The core component of the Haskell XML Toolbox is a validating XML-Parser that supports almost fully the Extensible Markup Language (XML) 1.0 (Second Edition).
The Haskell XML Toolbox bases on the ideas of HaXml and HXML, but introduces a more general approach for processing XML with Haskell. The Haskell XML Toolbox uses a generic data model for representing XML documents, including the DTD subset and the document subset, in Haskell. This data model makes it possible to use filter functions as a uniform design of XML processing applications. The whole XML parser including the validator parts was implemented using this design. Libraries with filters and combinators are provided for processing the generic data model.
WASH/CGI is an embedded DSL (read: a Haskell library) for server-side Web scripting based on the purely functional programming language Haskell. Its implementation is based on the portable common gateway interface (CGI) supported by virtually all Web servers. WASH/CGI offers a unique and fully-typed approach to Web scripting. It offers the following features
New/completed Items are:
Current work includes
Items still on the to do list
C-->Haskell is an interface generator that simplifies the development of Haskell bindings to C libraries. It has recently acquired support for conditional compilation, which facilitates supporting multiple versions of a C library within a single Haskell binding. Moreover, inline C declaration can be included into the binding, which is convenient if custom C code is needed for impedance matching between C and Haskell. The tool is currently at version 0.11.3 and it now has its own mailing list at <firstname.lastname@example.org>. It has been stress tested in the development of the Gtk+HS GUI library.
GreenCard is a foreign function interface preprocessor for Haskell and has been used (amongst other things) for the Win32 and X11 bindings used by Hugs and GHC. Source and binary releases (Win32 and Linux) are available. The last release was 2.0.4 (August 2002). A release that provides access to and takes advantage of the new Foreign Function Interface libraries will be available soon.
Java VM Bridge is a GHC package intended to allow full access to the Java Virtual Machine from Haskell, as a simple way of providing a wide range of imperative functionality. Its big advantage over earlier attempts at this is that it includes a straightforward way of creating Java classes at run-time that have Haskell methods (using DefineClass and the Java Class File Format). It also features reconciliation of thread models without requiring GPH.
It is intended to make writing "Java in Haskell" as straightforward as possible. To this end, each Java class is a separate type, and the argument lists of methods of automatically-generated interfaces to Java classes make use of subtype class relations to minimise explicit upward casting. Java exceptions are represented as Haskell monadic exceptions, and may be caught or thrown accordingly. Also, the two garbage collectors are integrated in such a way that cross-collector reference loops won't happen.
As a point of cleanliness and principle, it makes no use of "unsafe" Haskell calls (or pure function FFI). The layered design allows access to either lifted monads that keep track of context data (specifically, the JNIEnv pointer) and do all the work of preloading for you, or "IO"-based functions if you want to do all that yourself.
"Why write a program when you can write a program to write a program?" (author unknown).
See also constraint-based program analysis (section 3.3), the Parsec parser-combinator library (section 4.2.3) and the group of tools developed in Utrecht (section 6.4.5).
Alex is a lexical analyser generator for Haskell, similar to the tool lex for C. Alex takes a specification of a lexical syntax written in terms of regular expressions, and emits code in Haskell to parse that syntax. A lexical analyser generator is often used in conjunction with a parser generator (such as Happy) to build a complete parser.
Alex homepage (temporary):
I've recently been developing a new version of Alex based on Chris Dornan's original code. The current status can be seen by browsing the "simonm-hackery-branch" branch of the CVS repository in fptools/happy/alex. The main aims are:
The current status is that (1) is partly done (the syntax changes), (2) is partly done and (4) is done (but further table compaction could be done if it turns out to be necessary). (3) I have some ideas about.
Isaac Jones <email@example.com> has been writing the documentation for the next version of Alex.
There have been no new releases of Happy since June of last year. Happy is still in constant use by GHC and other projects, and remains in maintenance mode.
There aren't any major developments on the horizon, although I have been putting some work into a new version of Alex which might have an impact on Happy; no details yet, but the aim is to make it easier to construct a complete parser using Alex and Happy together.
Also see Strafunski's StrategyLib (section 4.2.1) for transformation support, and the Haskell Refactorer (section 5.3.2) for an application of transformations in program development.
MAG is a transformation tool for a small Haskell-like language which tries to make it easy to mechanise some complex program transformations with the help of user-supplied rewrite rules. Examples this has been tried with include cat-elimination and alpha-beta pruning.
Although not much time is being spent on it, it is still actively maintained and some work is being done on improving the higher-order matching algorithms that underpin its operation. We would of course be very happy to hear from anyone who is interested in using it (for example for teaching), or improving it. It was recently the basis for a chapter in "The Fun of Programming" (produced in honour of Richard Bird's 60th birthday).
HsOpt is an optimizer for the Helium compiler implemented in the transformation language Stratego. Helium (section 2.5.2) is a subset of Haskell developed at Utrecht University (section 6.4.5). The optimizer works on the code produced by the Helium front-end, which is code for Daan Leijen's Lazy Virtual Machine (LVM). The goal of this project is to validate the paradigm of transformation strategies for the implementation of an optimizing compiler.
Alan van Dam has written the first version of the optimizer consisting of a basic simplifier in the style of the GHC. The main target of this simplifier has been the optimization of pattern matching code. The naive translation of pattern matching by the Helium front-end keeps it simple, but produces rather ugly code. Using a small set of transformation rules and an appropriate strategy the code can be reduced to more sane code, often similar to code that would be written by hand. This first simplification step produces an optimization of about 10%.
Plans for the near future are to include an inliner (currently only local let bindings are inlined, not global function definitions), and to incorporate the earlier work on deforestation.
By now there exist a number of tools with rather different approaches to tracing Haskell programs for the purpose of debugging and program comprehension.
Hood and its variant GHood, for graphical display and animation, enable the user to observe data structures at given program points. Hood and GHood are easy to use, because they are based on a small portable library. They have remained unchanged for over a year.
The Haskell tracing system Hat is based on the idea that a specially compiled Haskell program generates a trace file alongside its computation. This trace can be viewed with several tools in various ways: Hood-style observation of top-level functions; backwards exploration of a computation, starting from (part of) a faulty output or an error message. All tools inter-operate and use a similar command syntax. A tutorial explains how to generate traces, how to explore them, and how they help to debug Haskell programs. Hat can be used both with nhc98 and ghc. Hat can be used for Haskell 98 programs that use some language extensions.
On 26 March 2003 Hat 2.02 was released. That release added --- besides numerous bugfixes and minor improvements --- support for multi-parameter type classes and functional dependencies, provided your underlying compiler supports them, the hierarchical module namespaces, and includes a tracing version of (a subset of) the base package of standard hierarchical libraries.
For the future we plan to add a number of new tools for viewing the trace; in particular we want to resurrect a tool for algorithmic debugging of Haskell programs, which had been part of previous releases of Hat.
Buddha is a declarative debugger for Haskell 98. It is based on program transformation. Each module in the program undergoes a transformation to produce a new module (as Haskell source). The transformed modules are compiled and linked with a library for the interface, and the resulting program is executed. The transformation is crafted such that execution of the transformed program constitutes evaluation of the original (untransformed) program, plus construction of a semantics for that evaluation. The semantics that it produces is a tree with nodes that correspond to function applications.
Currently buddha works with GHC version 5.04 or greater. No changes to the compiler are needed. There are no plans to port it to other Haskell implementations, though there are no significant reasons why this could not be done.
Version 0.5 is freely available as source. This version supports most of Haskell 98, however there are a few small items that are not supported. These are listed in the documentation. Future releases will include support for the missing features, and a much improved user interface. Version 0.6 should be available "real soon now" which has an automated front end.
Team: Huiqing Li, Claus Reinke, Simon Thompson
Refactorings are source-to-source program transformations which change program structure and organisation, but not program functionality. Documented in catalogues and supported by tools, refactoring provides the means to adapt and improve the design of existing code, and has thus enabled the trend towards modern agile software development processes. Refactoring has taken a prominent place in software development and maintenance, but most of this recent success has taken place in the OO and XP communities.
In our project `Refactoring Functional Programs', we explore the prospects for refactoring functional programs, taking Haskell as a concrete case-study. Following the experiments we reported on last time, we have now established the meta-programming infrastructure we need by building on the Programatica (http://www.cse.ogi.edu/PacSoft/projects/programatica/) project's Haskell-in-Haskell frontend (providing parsing, static analysis and type analysis) and the Strafunski project's support for generic and strategic programming (see section 4.2.1). We are also acquiring the necessary expertise for integrating our prototype refactorer into Vim and Emacs, according to our survey the main Haskell program development environments.
Programatica's frontend supports nearly all of Haskell 98, and would be our frontend of choice, but it still hasn't been released, and there are still some question marks on its license and whether that would impede our own project. Strafunski has proven invaluable in avoiding unmanageable amounts of boilerplate code, enabling us to focus on the essence of program transformations when implementing refactorings over the complex Haskell grammar.
Built on top of all that infrastructure, work on our prototype refactoring tool is now progressing well, and the Haskell Refactorer already supports a handful of smaller-scale refactorings, like renaming, moving definitions, extracting and inlining definitions, and the like. A paper ("Tool Support for Refactoring Functional Programs") describing some of the challenges in implementing such a tool is in preparation and the draft should be available from our project page within a couple of weeks. A first release of our Haskell Refactorer later this year should accompany the publication of that paper.
Hunit is a unit testing framework for Haskell similar to JUnit for Java. With HUnit, a Haskell programmer can easily create tests, name them, group them into suites, and execute them, with the framework checking the results automatically. Test specification is concise, flexible, and convenient.
HUnit is free software that is written in Haskell 98 and runs on Haskell 98 systems. While written in Haskell 98, HUnit 1.0 is sensitive to the format of exception strings, which it inspects to judge the outcome of tests. The planned minor revision (HUnit 1.1), to adapt to recent GHC (5.04) and Hugs (Oct. 2002) versions, should get rid of this sensitivity, but has been delayed and will have to wait until after someone's Master's degree is finished.
The root cause for this problem seems to be the lack of extensibility in Haskell's exception mechanism. A tool such as HUnit shouldn't have to resort to tricks like the one involved here. It should be possible to cleanly define and use an "HUnit" kind of exception.
There have been no new releases of Haddock since July last year. A few bugfixes have been applied to the main source tree, along with a couple of minor improvements, so another release will be forthcoming soon.
Haddock is relatively stable, and I intend to keep maintaining it for the forseeable future. I don't have much time for wholesale improvements, although contributions are of course always welcome. There is a TODO list of outstanding bugs and missing features, which can be found here:
This section lists applications developed in Haskell, be it in academia, in industry, or just for fun, which achieve some non-Haskell-related end.
HScheme will be a Scheme interpreter written in Haskell. There should be stand-alone interpreter program, or you can attach the library to your program to provide "Scheme services". It's very flexible and general with types, and you can pick the "monad" and "location" types to provide such things as a purely functional Scheme, or a continuation-passing Scheme (that allows call-with-current-continuation), or a fixed-point Scheme (that allows call-with-result), etc.
I'm currently rewriting it to resolve programs' symbols before running them. I don't expect any releases in the next few months.
Knit is a component definition and linking language for systems programming based on the Unit component programming model. Knit lets you turn ordinary C code (e.g., bits of the Linux kernel) into components and link them together to build new programs. Since the freedom to do new things brings with it the freedom to make new errors, Knit provides a simple constraint system to catch component configuration errors. Knit also provides a cross-component inliner and schedules initialization and finalization of components.
Knit is released under a BSD-style license, is written in Haskell (and a little C) and includes a C parser and pretty-printer. A useful little utility included in the distribution is a tool for renaming symbols in ELF-format object files.
The current Knit release acts post-compilation: we compile C code as normal and then rename symbols in object files before linking. We are rewriting Knit to act pre-compilation: manipulating the source code before compilation. This will bring the much needed ability to import and export types from modules.
Flatten can make existing, profiled, tuned and optimized C programs go 5-20%faster by performing performing inlining across module boundaries. More usefully, flatten lets you write C without making compromises to performance such as confusing interface with implementation (putting functions in header files) or writing overly large files.
Flatten works by parsing your C files, merging all the files into one, discards dead code, discards the user's guesses as to what functions should be inlined (this feature can be turned off), marking functions to be inlined, sorting function definitions to put definitions before uses and generating a single, giant C file for gcc to chew on. Flatten can cope with systems that contain assembly language, link with binary libraries, and other things that real code does. Flatten is an outgrowth from the Knit/Alchemy project which aims to bring some of the strengths of Haskell and Haskell tools to programmers on the street.
We are currently in the "release engineering" phase: more testing, add documentation, think of cooler name, commit to a license and package and aim to have a release out this summer.
The Systems Level Design Group at the University of Kansas Information and Telecommunication Technology Center is using Haskell to develop analysis tools for the Rosetta (http://www.sldl.org) requirements modeling language. We have been building upon work on modular interpreters to provide an ability to compose simulators for Rosetta domains, with the goal of performing dynamic analysis of heterogeneous models. While the work is in its early stages, we have been encouraged by preliminary results. Haskell is also being used extensively in the development of a toolset for the static analysis of Rosetta models.
I have recently been working on an IRC client which I'm calling "Hircules" written in Haskell using gtk2hs for the GUI. It already works reasonably well and I expect to make an initial public release within the next week or so, and will then of course welcome contributions, bug reports, rfe's, etc. I took the code from lambdabot as the starting point, though it is already starting to diverge a bit. Currently it features tabs for channels and private conversions and retains lambdabot's bot features too. There is also an all channels tab and a raw IRC message tab for debugging and irc fanatics. I hope to add more features, like coloured nicks, utf-8 support, message alerting, etc, to follow.
Many companies are starting to allow their programmers to develop small prototypes in Haskell but few are willing to take a chance on using Haskell on a large project. The risks to these companies include lack of support for tools, lack of tutorials and training courses, gaps in the set of available libraries, and lack of `gurus' to call on when things go wrong.
Reid Consulting can meet those needs. Our background and continuing involvement in the development of Haskell tools and compilers (GreenCard, Hugs, GHC, etc.) and the Haskell language and library design (the Haskell report, the Standard libraries, the Hugs-GHC libraries, the Foreign Function Interface and the HGL Graphics Library) and our use of Haskell to develop large systems, provide the experience and the contacts needed for effective support of real projects.
Where acceptable to clients, we have a policy of releasing any fixes or developed code as OpenSource for use by the wider Haskell community.
Aetion Technologies LLC, a small defense contractor based in Columbus, Ohio, USA, is using Haskell in-house for most of its software development. Our software is largely a set of small- to medium-sized programs that are written to demonstrate a range of new capabilities to the Department of Defense.
Where helping the Haskell community coincides with our commercial aims, we manage to spare some time to do that. Activities, mainly led by Isaac Jones, include packaging for Debian GNU/Linux, writing documentation, working on the Wiki, answering people's Haskell questions, and reporting bugs.
Features that draw us to Haskell are: reusability; program correctness (supported by high-level features, a lack of side effects, and strong, static typing); cleanliness; and, multiple liberally-licensed compilers. We make use of multi-parameter typeclasses, and we have been using Haddock to help with our documentation. Probably, we see Haskell's main (fixable) weakness as being a shortage of dependable libraries that are well-maintained and that offer introductory and reference documentation for the working programmer.
Although the Haskell community may seem small and mostly academic, we believe that there is real potential for Haskell in industry, and that Haskell's future is sure enough to warrant the strategic decision of using it commercially. Hiring Haskell programmers, or people capable of quickly becoming such, does not seem to be a problem.
It is probable that, at some stage, a customer will require that a product be delivered in an "industry standard" language; it remains to be seen if it is then practical to continue research and development in Haskell, and to do ports to other languages when necessary.
Sengan Baring-Gould <Sengan.Baring-Gould@nsc.com> at National Semiconductor is developing a binary parser which given a grammar is able to extract fields from values. This is used as part of an internal ICE (hardware debugger).
Binary parser provides the ability to reference by name values which may be composed of other values. It goes one step further in that the client program does not need to know where particular value is buried, only what its value is. Binary parser grammars are intended to enable non-programmers to access fields of their registers, without requiring the ICE-developer to write explicit code to do so. For instance a technical writer could write a binary parser grammar for a device of which the ICE developer has never heard. Stress has been put on generality and simplicity, rather than efficiency. For instance binary parser allows multiple definitions, cyclic definitions, etc.
Binary Parser is implemented in Haskell whereas the current ICE is not (C++) -- but the next generation will be. Currently communication is achieved using pipes so as to be compatible with both windows and unix (binary parser is used by 2 internal tools, one is unix one is windows).
Binary parser simplifies the porting of the ICE from chip to chip where the location of register-fields may change but their functionality does not.
Studying connections between programming effectiveness and practice in reasoning about software.
Lecture notes comprise over 350 animated slides (all both PowerPoint and PDF formats). About two-thirds of the material centers around mathematical logic. After the introduction of predicates, all of the examples in the logic portion of the course involve reasoning about properties of software, most of which is expressed in Haskell (a few are conventional looping functions).
Software examples include sum, sequence concatenation, logical operations on sequences, the Russian peasant algorithm, insertion and lookup in AVL trees, and other computations. Most of the properties verified relate to aspects of program correctness, but resource utilization properties are also verified in some cases. Several semesters worth of exams (finals and exams given during the term) are provided. The slides have matured through several offerings of the course.
The remaining third of the course discusses other standard topics in discrete mathematics, such as sets, functions, relations, trees, and counting. The web page provides access to a preview of the material. Exams and solutions are protected by a login procedure (to increase the comfort level of instructors wishing to use them in courses). The web page provides a link through which instructors may gain access to the full website.
A statistical study of grades earned in a course for which discrete mathematics is a prerequisite shows a statistically significant difference between the grades of students who studied the Beseme materials and those of students who studied discrete mathematics in the traditional way. Beseme students earned higher programming grades, on the average, compared with students of comparable ability from the traditional group. Details of are available on the Beseme website.
Many research groups have already been covered by their larger projects in other parts of this report, especially if they work almost exclusively on Haskell-related projects, but there are more groups out there who count some Haskell-related work among their interests. Unfortunately, we don't seem to reach some of them yet, so if you're reading this, please make sure that your group is represented in the next edition!
The activities of our group are centered on the UniForM workbench and the Common Algebraic Specification Language (CASL).
The UniForM workbench is an integration framework mainly geared towards tools for formal methods. It uses a simple, powerful and flexible notion of events to model all interactions between tools and users. In particular, the workbench provides HTk, an encapsulation of Tcl/Tk based on our event model (see section 4.3.2).
The workbench is actively used in the MMiSS project that aims to set up a multimedia internet-based adaptive educational system covering the whole subject of safe systems. The workbench currently contains over 80k lines of Haskell code (plus a few hundred lines of C), and compiles with the Glasgow Haskell Compiler, making use of many of its extensions, in particular concurrency.
We are also using GHC to develop tools, like parsers and static analysers, for languages from the CASL family, in particular CASL itself, HasCASL, and HetCASL.
Several parsers have been written using the combinator library Parsec (section 4.2.3). (Annotated) terms (from the ATerm Library) are used as a data exchange format and we use DrIFT (section 3.4) to derive instances for conversions. Documentation is generated using Haddock (section 5.3.4). (for ATerm see http://haskell.org/libraries/)
The CASL extension HasCASL combines specification and functional programming. The executable parts of a HasCASL specification are to be translated into Haskell (using the haskell-src package).
The language HetCASL is a combination of several specification languages used in formal methods, such as CSP, CASL, HasCASL, and Modal and Temporal Logic. We exploit Glasgow Haskell's multiparameter type classes, hierarchical name spaces, functional dependencies, existential and dynamic types.
HTk Graphical User Interfaces for Haskell Programs
MMiSS Multimedia instruction in safe systems
CASL specification language
The members of our group are Paul Hudak, John Peterson, Henrik Nilsson, Antony Courtney, and Liwen Huang.
The functional programming group at Yale is using Haskell and general functional language principals to design and implement domain-specific languages. We are particularly interested in domains that incorporate time flow. Examples of the domains that we have addressed include robotics, user interfaces, computer vision, and music. FRP was originally developed by Conal Elliott as part of the Fran animation system. It has three basic ideas: continuous- and discrete-time signals, functions from signals to signals, and switching. FRP is particularly useful in hybrid systems: applications that have both continuous time and discrete time aspects.
Yampa is the culmination of our efforts to support domain-specific embedded languages using FRP. Yampa, packaged with a robot simulator, is currently in release (see section 4.2.5)
John Peterson is working on DSL's for educational use (see section 2.5.3). Antony Courtney is working on yet another graphics library for Haskell to provide capabilities similar to the Java 2-D graphics library. This is in support of functional GUIs constructed using FRP. Henrik Nilsson is using FRP principles in a hybrid modelling language. He is interested in non-causal modelling in which a system is described by a system of signal relations rather than functions.
Liwen Huang is working on a language which describes the motion of humanoid robots. Paul Hudak works a little bit on each of the above topics, and also on the Haskore computer music library. Most recently he's developed an algebraic theory of polymorphic temporal media.
One prong of the Metis Project at Brooklyn College, City University of New York, is research on and with Parallel Haskell (section 3.2.2) in a Mosix-Cluster environment. At this time, after correcting some small bugs in the run time system, we have the current version of the GUM run-time system for parallel Haskell operating, and, in order to make the system more compatible with Mosix, we are currently removing the PVM dependency. A preliminary version of PVM-free GUM is currently being tested.
In coming months we expect to apply parallel Haskell to research on pseudorandom number generation (the shuffled nested Weyl generator of Holian, Percus, Warnock and Whitlock, Phys. Rev. E., <50>, 1607 (1994)) and image processing for extremely-high resolution medical-image visualization.
Within our Programming Language Research Group we are working on a number of projects with a Haskell focus.
We are well on our way to make all our Haskell modules mutually consistent and to make them available through a CVS server at cvs.cs.uu.nl, in the directory uust. Currently included are our parser combinators, pretty printers and attribute grammar system. Further software will be added in the near future.
The current version of the parser combinators constructs an online result, in the sense that parts of the result can be accessed even when parsing has not yet finished. This is especially useful when parsing and processing large files of similar information. Furthermore error messages are displayed while parsing (using unsafePerformIO). The underlying mechanism for achieving this is relatively costly, although parsing speed is not much slower than that of parsers generated off line using Frown or Happy (section 5.2.1).
Furthermore we added combinators that construct parsers that reorder the recognized elements (merging or permutation parsing) and keep track of this reordering by returning a function that can be used to reconstruct the original order. Inspiration for this came from the wish to retain the original input in such a way that error messages can be easily added to it. We also added a combinator that can be used to construct parsers for languages that follow the Haskell off side rule when parsing. This turned out to be quite complicated since the precise parsing rules have been defined in terms of parse errors.
See the description of Helium in section 2.5.2.
See the description of the constraint based type inferencer in section 3.3.2.
See the description in section 3.4.
The AG system offers Haskell programmers a seamless way to integrate the "attribute grammar" programming style with Haskell. This allows you to separate aspects of a program in more powerfull way than laziness and functions alone offer. The AG system has for example been used extensively in the implementation of Helium compiler to specify aspects like pretty printing, static analysis, and other tranformations.
The system has been bootstrapped, and now provides extensive error messages in case the attribute grammar contains errors. Only the type checking of the semantic functions is postponed to the Haskell compiler that is processing the output of the system. In a newer version we have added the conventional data flow analyses, so we may point at circularities, and can do experiments with generating more strict evaluators, that may run faster. The system is used in the course on Implementation of Programming Languages.
We are now investigating how to make language definitions more compositional, and how to capture recurring patterns of analysis and data flow in compilers. Ideally we should like to have so-called first class aspects. It is a matter of research however how to integrate type checking and aspect oriented programming. Attempts using extendible records almost seem to do the job, but unfortuantely incorrect use leads to pages of error messages. We hope that following the techniques explained in http://www.cs.uu.nl/people/arthurb/dynamic.html may help to solve the problem.
As a companion to Mark Jones' "Typing Haskell in Haskell" we are constructing a type inferencer for full (extended) Haskell. Some of its features are a consistent way of handling existential and polymorphic types, and the use of polymorphic kinds (if you want to know what they are good for read the "Typing Dynamic Typing" paper presented at the ICFP2002, http://www.cs.uu.nl/people/arthurb/dynamic.html). We are currently rounding of this construction with the less interesting, but more laborious parts of full Haskell. We plan to use this material later this year in a course on "Type Systems".
Our pretty printing combinators have been silently doing their work over the years. Currently we are updating them, so they can be generated by the new version of the AG system. They too will have a more flexible interface allowing naming of subformats by using a monadic top layer.
Proxima is a generic graphical structure editor with support for free editing (ie. normal typing instead of selecting transformations from menus) and computations over the data structure. The system has a layered architecture, which is described and implemented using a library of architecture combinators. For the presentation of the document data structure, the graphical presentation combinator library Xprez has been developed. The user interface will be implemented using the upcoming wxHaskell GUI library (section 4.3.5).
One of the intended applications of Proxima is an editor/IDE for the language Helium. It will support editable pretty printed code in which types and error messages can be shown. Sources can be edited by normal typing (also for changing layout) as well as by performing structural edit commands.
A prototype of Proxima is expected to be ready in the second half of 2003.
The syntax macros are now in a state that one gets a macro mechanism for free when using our attribute grammar system and parser combinators in constructing a front end of a compiler. Most of the necessary glueing code is automatically generated. The syntax macros make it possible to extend the context free grammar of a language on a per program basis. Examples of constructs that no longer have to be part of the standard language, but could have been defined using our macro mechanism are the do-notation, and the notation for list comprehensions. An open question, on which we work, is how to provide feedback to the user in terms of his original program. The current version is available at: http://www.cs.uu.nl/people/arthurb/macros.html
Here at what is now called the University of Kent, the functional programming interest group currently includes about a dozen people pursuing research interests in functional programming. Haskell is a major focus of teaching and research, although we also look at other languages (such as Erlang http://www.erlang.org).
Our members pursue a variety of Haskell-related projects, many of which are reported in other sections of this report. Keith Hanna is continuing his work on visual interactive programming with Vital (see section 2.5.4). Axel Simon develops the Gtk2hs binding to version 2.2 of the Gtk GUI library (section 4.3.7). Chris Ryder is now evaluating his Metrics and Visualization library Medina (section 4.5.1) through some case studies.
Huiqing Li, Simon Thompson and Claus Reinke are making good progress building a prototype Haskell Refactorer (section 5.3.2), and Claus Reinke is also making slow progress and would like to be able to spend much more time (...) on his project combining functional programming and virtual worlds (section 4.4.5).
Stefan Kahrs works on the expressiveness of programming languages, e.g. what one can do with certain language features in Haskell. In this vein is his work on red black trees http://www.cs.kent.ac.uk/~smk/redblack/rb.html and showing, via a Haskell implementation, the relative completeness of PCF http://www.cs.kent.ac.uk/~smk/PCF/Untyped_PCF.html .
Refactoring Functional Programs:
PLS is a young research group at the University of New South Wales whose Haskell-related activities comprise high-performance arrays for Haskell, whole program optimisation of Haskell programs, optimisation of Embedded Domain Specific Languages (EDSLs) in Haskell, Haskell to Java translation, and a Haskell to ObjectiveC bridge. Moreover, we work on the use of l-calculus as an intermediate language for optimising compilers of conventional languages, the safe execution of untrusted code, Python for the Single Address Space Operating System (SASOS) Mungi, and cluster computing.
The Parallel and Distributed Functional Languages (PDF) research group is part of the Dependable Systems Group in Computer Science at the School of Mathematics and Computer Science at Heriot-Watt University.
The group investigates the design, implementation and evaluation of high-level programming languages for high-performance, distributed and mobile computation. The group aims to produce notations with powerful yet high-level coordination abstractions, supported by effective implementations that enable the construction of large high-performance, distributed and mobile systems. The notations must have simple semantics and formalisms at an appropriate level of abstraction to facilitate reasoning about the coordination in real distributed/mobile systems i.e. to transform, demonstrate equivalence, or analyse the coordination properties. In summary, the challenge is to bridge the gap between distributed/mobile theories, like the pi and ambient calculi, and practice, like CORBA and the OGSA.
The group has designed, implemented, evaluated and used several high performance/distributed functional languages, and continues to do so. High performance languages include Glasgow parallel Haskell (section 3.2.2) and Parallel ML with skeletons (PMLS). Distributed/mobile languages include Glasgow distributed Haskell (section 3.2.3) Erlang (http://www.erlang.org/), Hume (http://www-fp.dcs.st-and.ac.uk/hume/) and Camelot.
Primary industrial collaborators include groups in Microsoft Research Labs (Cambridge), Motorola UK Research labs (Basingstoke), Ericsson, Agilent Technologies (South Queensferry).
Primary academic collaborators include groups in Complutense Madrid, JAIST, LMU Munich, Phillips Universität Marburg, and St Andrews.
"What are you using Haskell for?" -- the implementation mailing lists are full of people sending in bug reports and feature suggestions, stretching the implementations to their limits. Judging from the "reduced" examples sent in to demonstrate problems, there must be quite a few Haskell applications out there that haven't been announced anywhere (probably because Haskell is "just" the tool, not the focus of those projects).
If you're one of those serious Haskell users, why not write a sentence or two about your application? We'd be particularly interested in your experience with the existing tools (e.g., that all-time-favourite: how difficult was it to tune the resource usage to your needs, after you got your application working? Which tools/libraries where useful to you? What is missing?).
Tom Pledger <Tom.Pledger@peace.com> writes:
Since 2001 my work has mainly been the design and implementation a business data processing language. It is lazy, functional, and has a lot in common with discrete Functional Reactive Programming. I tried and failed to implement it as a Haskell library, before committing to a separate language.
A prototype of the runtime virtual machine, implemented in Haskell, passed some initial tests in April 2002. We expect to get a text based prototype working in May 2003, complete with its database interface and interpreter front end. We have plans for a graphical user interface, comprising an Integrated Development Environment and a runtime debugger.
I take care not to ask for related free advice on the Haskell mailing lists, because my employer expects to own and profit from what I produce.
Graham Klyne (http://www.ninebynine.org/, http://www.ninebynine.net/) writes:
My primary interest is in Semantic Web (http://www.w3.org/2001/sw/) and RDF technologies, and I am a participant in the W3C RDFcore working group (http://www.w3.org/2001/sw/RDFCore/). I'm a developer rather than a researcher, and am currently working toward using RDF in network configuration applications. I aim to develop inference rules to map general network policy descriptions (in RDF) to device-specific configuration files and/or instructions. I see the Web in general, and the Semantic Web in particular, as a natural territory for application of functional programming techniques. The availability of open, high quality language implementations, and a vibrant user community are important considerations in choosing Haskell.
I aim to use Haskell to explore simple inference techniques for RDF data, motivated in part by limitations I have encountered when using simple off-the-shelf RDF inference tools. I find it particularly appealing that Haskell has the full power of a general purpose programming language, but supports programming styles that can be matched very closely to formal specifications, thus providing extra validation for Internet/Web protocol specifications. So far, in Haskell, I have released a URI processing package and test cases (http://www.ninebynine.org/Software/Intro.html#URIsInHaskell) with a URI parser based closely on a proposed revision of the URI specification, and am currently working on an RDF graph API, graph-isomorphism tester, Notation3 parser (http://www.w3.org/DesignIssues/Notation3.html) and Notation3 formatter (mostly working, but not yet released). With the recent availability of XML parsers with namespace support, I'd also like to tackle a full RDF/XML parser based on the new proposed RDF syntax specification (http://www.w3.org/TR/rdf-syntax-grammar/).
Once I have some basic RDF processing tools in place, I plan to apply them to network access control and configuration applications.
Dean Herington <firstname.lastname@example.org> writes:
I'm presently completing a Master's thesis for which I built a small domain-specific language (embedded in Haskell, of course) to coordinate the execution of cooperating but independent application programs. Participating programs and data files are described formally. A compound execution--termed a federation--is expressed in Haskell, extended with operations for large-grain program description and coordination. The declarative expression of a federation in terms of data flow among the component programs captures synchronization requirements implicitly and can exploit the inherent concurrency automatically. Haskell compilation, notably its rigorous type checking, ensures the consistency of the federation. I applied the coordination framework to one large problem, the federation of several existing Fortran programs that simulate environmental processes in the Neuse River estuary of North Carolina.
Oleg Kiselyov <email@example.com> continues to extend his collection of Haskell programming miscellanea, exploring algorithms and programming techniques, with extensively commented example code http://pobox.com/~oleg/ftp/Haskell/index.html: One recent addition is a page that discusses several approaches to number-parameterized types, i.e., datatypes that depend on unary or decimal numbers. http://pobox.com/~oleg/ftp/Haskell/number-parameterized-types.html
Examples include arrays parameterized by their length (like an array type in Pascal), bitfields of a statically known size and Zn types for modular groups or rings with a statically known modulus. An attempt to add, for example, two bitvectors (arrays, modular integers) of different sizes results in a compiler error with a clear error message. Often the numerical parameter is an unary (Church) numeral. We will also show an implementation of number parameterized types with decimal numerals. The latter are far easier to use. We also demonstrate arithmetic on (decimal) number parameterized types, which lets us statically typecheck operations such as array concatenation.
We should stress that the basic number-parameterized types can be implemented entirely in Haskell98. Advanced operations such as type arithmetic require Haskell extension to multi-parameter classes with functional dependencies.
The pure-functional l-calculator project has been developed further and has a new web page:
The project implements a domain-specific language of the pure untyped l-calculus embedded into Haskell. The new project page describes several applications of the calculator:
Mike Thomas <firstname.lastname@example.org> writes:
I'm working on Haskell bindings to the Japi (C wrapped Java GUI), Grass (geographic information system), MPICH (parallel processing by message passing) and Proj (map projection) libraries to allow me to read, write, display and process GRASS mapsets and to do some geochemical modelling, hopefully with the ability to distribute large map computations with MPICH.
Windows GHC is my compiler of choice and until recently I relied heavily on the Parsec and ObjectIO libraries, each of which is an excellent development tool.
However, the demise of the GTK ObjectIO library port led me to drop it as the GUI component of the project. Instead, I released a Haskell binding to a substantial subset of the Japi GUI library. Although that library is not as slick as ObjectIO, the Haskell binding is easily ported to other platforms and compilers and is also easily maintained by myself without depending on the trials and tribulations of third party libraries or on other programmers' coding assistance. To add practical weight to this aspect of the binding I recently commenced work make the binding work with NHC98. (On the side, I also made a complete binding for GNU Common Lisp which is available from the Savannah CVS repository.)
I have also changed direction on my interface to GRASS, preferring now to port libgis to the MinGW32 Windows C compiler rather to rewrite substantial chunks of functionality in Haskell. Although the Haskellisation process was an interesting experience, there is now little left for me to gain by that duplication, and much to lose in terms of extra work as GRASS itself evolves through time. In general I think that unnecessary duplication in the open source community can lead to dissipation of part time programmer-years which might otherwise be better spent.
The Japi Haskell binding is publicly available in the libraries subdirectory of the GHC fptools CVS tree. The remainder of this work is not available on the web as it is relatively incomplete and I have not decided on a release model.
on MPICH: http://www-unix.mcs.anl.gov/mpi/mpich/
and Japi: http://www.japi.de/