Welcome to the Seventh edition of the Haskell Communities and Activities report. I can proudly announce that the report has survived yet another change of editor, and chances are good that this won’t be the last report I edit, so you are going to have to live with me for a while.
First of all, I want to emphatically thank the two previous editors, Claus Reinke and Arthur van Leeuwen, not only for the visible results they have produced (the previous six reports), but also for providing an infrastructure (template files, contact lists, little tools etc.) with which the preparation of this report has been more entertaining than stressful. In this context, I also want to thank John Peterson, who helped out promptly and unbureaucratically when I happened not to be satisfied with the software installed on haskell.org.
Furthermore, I want to thank everyone in the rather impressive list of contributors. Without your work, these reports would not be possible, and I appreciate the many friendly replies I got to my calls and reminders, and I especially thank all first-time contributors! In my – rather subjective – impression, we have a significant increase in the number of Haskell-based applications. Successful applications are certainly a good way to help Haskell to more recognition outside the core community.
Still, I have the feeling that the report could be better and more complete. From time to time, I find myself reading a mail on the mailing list mentioning a project I have never heard of, or even announcing a new project. When I ask if a contribution to the HC&A Report is forthcoming, I usually get the answer “well …now that you asked, it is”. While such a reaction is of course positive, I cannot possibly catch all new or hidden projects this way. Therefore, I rely on you, the readers, to provide feedback, and to communicate with each other: please encourage yourself and others you know are working on Haskell projects to contribute, and please tell me <hcar@haskell.org> about things you are missing from the Report. And please, mark already the last weeks of April in your calendar, as the contributions to the May 2005 edition are due by then!
I couldn’t stop it and change a few TeXnical things: I sincerely hope that you like the new look of the report. The main functional modification is that you can detect changes more easily. Entries that are (nearly) unchanged with respect to the previous edition are listed normally (they will still contain current and interesting information, though). Entries that have been updated have a header with a blue background, and finally all-new entries (again, w.r.t. the previous edition) find themselves completely on a blue background.
I don’t particularly like the historically grown categorization of the Report. I apologize in advance for all the projects I placed wrongly or suboptimal (the commercial users are listed under “Applications”, for example, whereas research and user groups have their own chapter). For the next Report, I will think about modifying the overall structure a bit: suggestions are welcome.
Ok, I’ve said enough – read it while it’s hot!
Andres Löh, University of Utrecht, The Netherlands
haskell.org belongs to the entire Haskell community – we all have a stake in keeping it as useful and up-to-date as possible. Anyone willing to help out at haskell.org should contact John Peterson <peterson-john@cs.yale.edu> to get access to this machine. There is plenty of space and processing power for just about anything that people would want to do there.
Thanks to Fritz Ruehr for making the cafepress store on haskell.org a lot more exciting and to Jonathan Lingard for adding some nice style sheets to our pages.
What can haskell.org do for you?
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 IRC channel is a real-time text chat where anyone can join to discuss Haskell. Point your IRC client to irc.freenode.net and join the #haskell channel.
The #haskell.se channel is the same subject but discussion happens in Swedish. This channel tends to have a lot of members from Gothenburg.
The #darcs channel has been added since the last HC&A Report, if you want real-time discussion about darcs, drop by!
The Haskell wikiwiki is a freely editable website designed to allow unrestricted collaboration. The address is http://www.haskell.org/hawiki/. Some highlights are:
Feel free to add your own content!
I am currently in the final-stages of producing an introductory Haskell textbook. The book is a revised and extended version of my Haskell course at the University of Nottingham, which has been developed and class tested over many years. The first seven chapters (97 pages) are available for preview on the web: http://www.cs.nott.ac.uk/~gmh/book.html
I’d be pleased to make the full current draft (162 pages) available to anyone that is teaching Haskell and may be interested in using the book in their course; please contact me for further details.
While writing the manpages for Pesco.Cmdline, I assembled some guidelines to follow with respect to structure and formatting in their own manpage, hs-manpage-howto(7hs). It’s a rough document far from complete, and mainly meant as a reminder and guide for myself, but if anyone else would like to document his or her Haskell modules with roff (which I hope to encourage hereby), it might well prove useful.
Alas, if you write a Haskell manpage, and come up with a style guideline not covered, please let me know!
http://www.scannedinavian.org/~pesco/man/html7/hs-manpage-howto.7hs.html
Functional languages have been with us for a little over a generation now. Languages like Lisp, Scheme, ML, OCaml, Haskell, and Erlang have well engineered compilers and tools and large user and development communities. Not surprisingly, some of these users work in industry. While there are only a few companies where functional languages are used exclusively, there are many that use functional languages for design exploration, prototyping, modeling, specification and design, building compiler-like tools, and even for developing product.
In recognition of this the first Annual ACM SIGPLAN Workshop for Commercial Users of Functional Programming (CUFP) was held on September 18th, 2004, in Snowbird, Utah. It was co-located with the 2004 ACM SIGPLAN International Conference on Functional Programming (ICFP).
The goals of the workshop were to act as a voice for commercial users of functional programming languages and technology; to help functional programming become increasingly viable as a technology for use in the commercial, industrial, and government space, by providing a forum for functional programming professionals to share their experiences and ideas, whether business, management or engineering, and to enable the formation and cementing of relationships and alliances that further the commercial use of functional languages.
There were 25 attendees, and the workshop was based around 9 short presentations from a diverse cross-section of commercial users, representing Abstrax Inc., Microsoft, Linspire Inc., Beckman Coulter Inc., Cadence Research Systems, Galois Connections, Inc., and Bluespec Inc. Participants were encouraged to view the speakers as leading discussion, as opposed to giving academic presentations, and this led to spirited and fruitful discussions.
In short: the workshop was very successful, and we hope to make it a regular event. Throughout the day, a number themes emerged from talks and the discussions they engendered. An article describing those themes in more detail is available (http://www.galois.com/cufp/CUFP-Report.pdf).
The Succ Zeroth International Obfuscated Haskell Code Contest was a great success! Thanks to all those who entered, please enter again next year! See the results here: http://www.scannedinavian.org/iohcc/succzeroth-2004/.
Haskell did extremely well in this year’s seventh ICFP programming contest. The participate the contest, a given task has to be solved within 72 hours (with a special “lightning-division” prize available for the best solution received within 24 hours). There are no restrictions on team size, and any programming language can be used.
This year’s task was to design an ant colony that will bring the most food particles back to its anthill, while fending off ants of another species. To win the contest, one had to submit the neural wiring for the ants in your colony – a text file containing code for a simple, finite state machine that is run by all of the ants.
Each team was allowed to submit two programs, and in the final ranking the top four entries were written by teams who used Haskell. The winning team was “Dunkosmiloolump” (Ian Lynagh, Ganesh Sittampalam, Andres Löh, Duncan Coutts). The second place team was “The Frictionless Bananas” (Jeremy Sawicki and Mieszko Lis). In total, 230 teams participated, out of which 20 used Haskell (in comparison: 25 C++, 24 OCaml, 23 hand-coded, 21 Java, 16 Python, 15 C, 12 Lisp, 11 Pearl, 9 Scheme, …).
http://www.cis.upenn.edu/proj/plclub/contest/
http://urchin.earth.li/icfpcontest/2004/
This year in August, the 5th International Summer School on Advanced Functional Programming took place in Tartu, Estonia. About 70 people with different backgrounds gathered for a week to learn and teach several interesting topics related to functional programming. Naturally, the Haskell language had a prominent place among the lectures. The topics were:
One beneficial side effect of such a Summer School is that the lecturers produce lecture notes, which usually are excellent tutorials to the respective subjects. The lecture notes of this Summer School will be published as an LNCS volume. I wish to thank the local organizers Varmo Vene and Tarmo Uustalu for making this a wonderful and enlightening event.
You may want to participate in some of the following Haskell-related events:
Here are some development highlights from the last few months. They will all be incorporated in GHC 6.4, which we will release before Christmas.
As part of the Visual Studio work (→5.5.3), we now plan to make GHC itself into a proper Haskell library, with a well-defined interface. So you should be able to say “import GHC” and then call the parser, type-checker, and so on. It’ll have a pretty big interface, of course, and we’ll emit draft specifications in the next few months. If you’re a potential user of a GHC-as-a-library, do take a look at the drafts and let us know whether they’ll work for you.
Not much progress on the Template Haskell front, largely due to lack of interest. If there’s an active user community, you are keeping very quiet, and so TH has slipped down our priority list.
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 Simon M and I 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.
The most recent release of Hugs was in November 2003. The development version incorporates support for Unicode, thanks to Dimitry Golubovsky <dimitry@golubovsky.org>, increased support for the hierarchical libraries, and numerous bug fixes. It is high time for another release, and Hugs is mostly ready, except that more work is needed on Windows. It would be great if the next release could support the Graphics library (used in Paul Hudak’s book) on Windows, as it will on X11. If it works with Hugs it will probably work with GHC too, but there is no-one to do the necessary fixing.
The next release is planned to include more third party libraries than previous ones, though in such a way as to make separate upgrades of these libraries fairly painless. The idea is to provide a substantial Haskell system out of the box. Library authors who would like to participate should make their libraries work with Hugs and contact us. The Cabal project (→4.1.1) is also developing Hugs support.
The manpower available for Hugs development and maintenance remains very limited. Contributions from volunteers are welcome. Sven Panne has made a Windows binary available; test reports would be welcome. Even better would be people prepared to build, test and debug on Windows. (A full build requires one of the free Unix-like environments for Windows.)
Dimitry Golubovsky has also developed an introspection extension to Hugs (hugs-users, September), extending the limited experimental features already present to provide full access to Hugs’s compilation results. He has in mind applications like saving for use with an alternative runtime, precompilation and more, but would like to hear from anyone who is interested.
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.16, but a bug-fix refresh version 1.18 is imminent. Maintenance continues in CVS at haskell.org, and implementation hackers are invited to play with nhc98’s internals if they wish.
About our Haskell-Clean compiler found at http://aszt.inf.elte.hu/~fun_ver/#ToC11:
The primary aim of the project is to develop a tool, which we name Hacle, for translating Haskell programs to Clean programs, thereby allowing the Clean compiler to compile Haskell programs. The question is, can the Clean compiler, in combination with Hacle, produce faster executables than existing Haskell compilers?
The answer, perhaps rather predictably, is sometimes yes. We have noticed that, in some cases, the hybrid Hacle-then-Clean compilation system can produce executables which are up to a factor of four times faster than the corresponding GHC-compiled programs. However, we suspect that these cases are in a minority. Nevertheless, to be of any significance at all, we must also argue Hacle’s completeness.
Hacle can translate programs which conform to a slightly restricted Haskell 98 standard. It can translate itself, which is written in approximately fifteen thousand lines of code and makes use of many of the features provided by Haskell 98. This result positively demonstrates reasonable completeness.
The project is effectively finished; this is not to say that the tool cannot be improved, rather that we are content with its current state. Only the unlikely event of widespread use would motivate such improvements. However, the following question is unanswered: why do Clean and GHC sometimes outperform each other?
For more information including detailed technical documentation, my dissertation, more results, Hacle’s limitations, and a download link to Hacle, see the project’s web page.
http://www.cs.york.ac.uk/~mfn/hacle
Grateful acknowledgements to Malcolm Wallace and Olaf Chitil.
Work on our port of nhc98 (→2.3) to Palm OS is continuing but, unfortunately, is not ready for public release at this stage.
| Report by: | Daan Leijen |
| Participants: | Arjan van IJzendoorn, Bastiaan Heeren, Daan Leijen, Rijk-Jan van Haaften |
| 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.2) (see also “Scripting the type inference process”, Bastiaan Heeren, Jurriaan Hage and S. Doaitse Swierstra, ICFP 2003).
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. 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.
Currently, the Helium compiler has been used successfully for the third time during the functional programming course at Utrecht University. There is also initial support for type classes, but we are still investigating the quality of error messages in the presence of overloading.
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 programming makes it an ideal way to introduce programming language concepts and encourage a basic literacy in computational principles. Languages can also be used as part of a domain-centered learning experience, allowing functional programming to assist in the instruction of subjects such as mathematics or music.
Our languages are media oriented. They allow students to explore the basic principles of functional programming while creating artifacts such as images, animations, and 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#, runs all of the examples in Conal Elliott’s Fun of Programming chapter with only a few minor changes. It also runs many of the examples found in Jerzy Karczmarczuk’s Clastic system.
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 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. Version 1.0 of Pan# was released in March and the system finally has a type checker. Pan# is an excellent introduction to functional programming and can be used in conjunction with the Fun of Programming chapter as an excellent way to teach functional languages. 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 to simplify the language somewhat and add a few new capabilities, including support for randomized music. We are currently working on a tutorial for the system and should have a release ready in March, 2005.
| Report by: | Keith Hanna |
| Status: | active (latest release: May 2004) |
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, graphically (as linked data structures) or pictorially, and can be edited using conventional Copy/Paste mouse gestures. This gives end users an intuitive way of inputting or modifying complex literal data structures. For example, a value of type Tree can be displayed graphically and subtrees selected, copies and pasted between nodes.
Recent development in Vital include the ability for animated and interactive displays (a release of this system is planned for November).
The present implementation includes a collection of interactive tutorial documents (including examples illustrating approaches to Exact Real Arithmetic).
The Vital system can be run via the web: a single mouse-click is all that is needed!
Home page: http://www.cs.kent.ac.uk/projects/vital/
hOp is a micro-kernel based on the run-time system (RTS) of the Glasgow Haskell Compiler. It is meant to enable people to experiment with writing various components of an operating system in Haskell. This includes device drivers, data storage devices, communication protocols and tools required to make use of these components.
The February 2004 release of hOp consisted of a trimmed-down RTS that does not depend on features usually provided by an operating system. It also contains low-level support code for hardware initialization. This release made most functions from the base hierarchical library available (all but the System modules), including support for threads, communication primitives, and the foreign function interface (→3.1).
Building on the features of the initial release, we designed and implemented an interrupt handling model. Each interrupt handler is run in its own thread, and sends events to device drivers through a communication channel. We tested our design by implementing a simple PS/2 keyboard driver, and a “shell” that allows running a “date” command, which accesses the real time clock of the computer. A release of hOp containing these additional features was made in June 2004.
Iavor Diatchki, Thomas Hallgren, and Andrew Tolmach made some additions to hOp. The additions include a PS/2 mouse driver, using VBE 2.0 to setup a linear frame buffer for graphics, a window system implemented in Haskell (Gadgets, developed by Rob Noble and Colin Runciman at the University of York), new primitives for setting up demand paged virtual memory and executing arbitrary machine code in protected mode. The function to launch a user space executable is parameterized by a system call handler, a page fault handler and a timeout. The resulting system is in an experimental state and is preliminary called House.
Further information, source code, demos and screenshots are available here:
Agda is an interactive type-based editor for editing proofs and programs that has been developed at Chalmers and Göteborg University. It builds on previous work at Chalmers such as ALF and Cayenne. It implements a proof/type checker for a language that is based on Martin-Löf Type Theory. We are experimenting with how such a proof langauge could be extended with data-types, modules and records. The syntax of the language is rather close to Haskell. The language can also be seen as a start for a dependently typed programming language.
The program is written in Haskell and it consists of roughly 15 000 lines of code. It is connected with one graphical and one text-based interface. The graphical interface Alfa http://www.cs.chalmers.se/~hallgren/Alfa/ is written in Haskell using Fudgets. The is also a “simple” emacs-interface which doesn’t know the syntax of the language and communicates via a text-based protocol with Agda. This interface comes with the distribution of Agda.
Agda is running with a stable version that is slightly more than one year old. It is also possible to download newer unstable versions. In this new version experiments are done with hidden arguments as in Cayenne, addition of over-loading with a class system and built-in types such as characters, strings and integers.
We have recently started a collaboration with AIST (Advanced Industrial Science and Technology Institute in Japan) on development and applications of Agda. In particular on writing better documentation and integration with other automatic proof tools.
Agda source code can be browsed at http://cvs.coverproject.org/marcin/cgi/viewcvs/ and can be accessed by anonymous CVS from cvs.coverproject.org.
Short term goals are among many things:
For more details about the project, read about QuickCheck (→5.4.4) and Cover (→7.1.10) in this report or consult the homepage at http://www.cs.chalmers.se/~catarina/agda/.
Epigram is a prototype dependently typed functional programming language, equipped with an interactive editing and typechecking environment. High-level Epigram source code elaborates into a dependent type theory based on Zhaohui Luo’s UTT. The definition of Epigram, together with its elaboration rules, may be found in ‘The view from the left’ by Conor McBride and James McKinna (JFP 14 (1)). The former has implemented Epigram in Haskell, interfacing with the xemacs editor.
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. These provide a means to incorporate strong logical invariants which well typed programs are guaranteed to preserve. Examples include matrices indexed by their dimensions, expressions indexed by their types, search trees indexed by their bounds. Correspondingly, we can express matrix multiplication taking (Matrix i j) and (Matrix j k) to (Matrix i k), tagless evaluators, sorting algorithms which produce sorted output.
Dependent types enable us to express statically what is learned when a test is performed. In Epigram, this informative testing often takes the form of derived pattern matching principles or ‘views’: if you can prove that a set of expressions cover a type, then you may use those expressions as patterns. For example, any pair of natural numbers is either (x, x + y) or (y + 1 + z, y). This gives us a way to test if m <=n, observing and exploiting what this test tells us about m and n.
Whilst Epigram seeks to open new possibilities for the future of strongly typed functional programming, its implementation benefits considerably from the present state of the art. On the language side, considerable use is made of monad transformers, higher-kind polymorphism and type classes. Moreover, its denotational approach translates Epigram’s lambda-calculus directly into Haskell’s. On the tool side, Haskell’s profiler (in the capable hands of Paul Callaghan) has proved invaluable for detecting bottlenecks in the code.
Epigram can be found on the web at http://www.dur.ac.uk/CARG/epigram and its community of experimental users communicate via the mailing list <epigram@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. At time of writing, a new implementation is in design, incorporating a compiler based on Edwin Brady’s research. Recent successful funding bids have ensured that the development will continue.
Version 1.0 of the Haskell 98 FFI Addendum is available. The report has been through many revisions and is fully implemented by GHC and Hugs and mostly implemented by NHC98. As with Haskell 98, the FFI standard is meant to be a stable interface that Haskell developers can rely on in the midst of new extensions and language features. Details are available from http://www.cse.unsw.edu.au/~chak/haskell/ffi/.
What is missing, at the moment, is a good tutorial that serves as a companion to the standards document and explains FFI programming by way of a comprehensive set of examples. If anybody feels the urge to help out by contributing all or parts of such a tutorial, please let me know at <chak@cse.unsw.edu.au>.
| 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.
The first 3 items are linked by a British Council/DAAD collaborative project between Heriot-Watt University, St Andrews University, and Phillips Universität Marburg.
GpH is being used to parallelise the GAP mathematical library in an EPSRC project (GR/R91298).
The GUM implementation of GpH is available in two development branches, and work on a port of GUM to the latest GHC 6.xx branch has been started over summer.
Our main hardware platform are Intel-based Beowulf clusters. Work on ports to other architectures is also moving on (and available on request). Specifically a port to a Mosix cluster has been built in the Metis project at Brooklyn College, with a first version available on request from Murray Gross.
GpH Home Page: http://www.macs.hw.ac.uk/~dsg/gph/
| Report by: | Jan Henry Nyström |
| Participants: | Phil Trinder, Hans-Wolfgang Loidl, Jan Henry Nyström, Robert Pointon, Andre Rauber du Bois |
| Status: | Steaming ahead! |
An alpha-release of the GdH implementation is available on request <gph@macs.hw.ac.uk>. It shares substantial components of the GUM implementation of GpH (→3.2.1). A beta release of mHaskell will be available in December 2005.
http://www.macs.hw.ac.uk/~dsg/gdh/
Eden has been jointly developed by two groups at Philipps Universität Marburg, Germany and Universidad Complutense de Madrid, Spain. The project has been ongoing since 1996. Currently, the team consists of the following people:
Eden extends Haskell with a small set of syntactic constructs for explicit process specification and creation. While providing enough control to implement parallel algorithms efficiently, it frees the programmer from the tedious task of managing low-level details by introducing automatic communication (via head-strict lazy lists), synchronisation, and process handling.
Eden’s main constructs are process abstractions and process instantiations. The function process :: (a -> b) -> Process a b embeds a function of type (a -> b) into a process abstraction of type Process a b which, when instantiated, will be executed in parallel. Process instantiation is expressed by the predefined infix operator ( # ) :: Process a b -> a -> b. Higher-level coordination is achieved by defining skeletons, ranging from a simple parallel map to sophisticated replicated-worker schemes. They have been used to parallelise a set of non-trivial benchmark programs.
Eden has been implemented by modifying the parallel runtime system GUM of GpH (see above). Differences include stepping back from a global heap to a set of local heaps to reduce system message traffic and to avoid global garbage collection. The current (freely available) implementation is based on GHC 5.02.3. A source code version is available from the Eden web page. Installation support will be provided if required.
survey and new standard referenceRita Loogen, Yolanda Ortega-Mallén and Ricardo Peña: Parallel Functional Programming in Eden, accepted for the Journal of Functional Programming special issue on Functional Approaches to High-Performance Parallel Programming 2004, to appear.
semanticsM. Hidalgo-Herrero: Formal Semantics for a parallel functional language, Ph.D. Thesis, Universidad Complutense de Madrid, June 2004 (in Spanish).
compilationSteffen Priebe: A Framework for Enhancing Eden Code with Template Haskell, Proceedings of of the Workshop on Implementation of Functional Languages, IFL 2004, Lübeck, Germany, September 2004.
generalised runtime systemJost Berthold: Towards a Generalised Runtime Environment for Parallel Haskells, Workshop on Practical Aspects of High-level Parallel Programming (PAPP 2004), ICCS, Krakow, Poland, June 2004.
profilingPablo Roldan Gomez: Eden Trace Viewer: A Tool to Visualize Parallel Functional Program Executions, Diploma Thesis, Universidad Complutense de Madrid, July 2004 (in german).
skeleton performance analysisJost Berthold, Rita Loogen: Analysing Dynamic Channels for Topology Skeletons in Eden, Proceedings of the Workshop on the Implementation of Functional Languages, IFL 2004, Lübeck, Germany, September 2004.
http://www.mathematik.uni-marburg.de/~eden
Coloured Petri Nets are a high-level form of Petri Nets, in which anonymous tokens are replaced by data objects of some programming language (and transitions can operate on that data, in addition to moving it around). The combination of functional languages and Petri nets promises a rich design space – the two formalisms have little overlap and much to offer to each other.
Haskell-Coloured Petri Nets (HCPN) are an instance of this hybrid graphical/textual modelling formalism for Haskell. So far, we have a bare-bones graphical editor for HCPN, building on the portable wxHaskell GUI library (→4.5.2). From this, HCPN can be saved, loaded, and exported as Haskell code for graphical or textual simulation. 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.
The most important outstanding item, apart from minor improvements of the GUI, is support for hierarchical HCPN models. While that would allow HCPN to be used for modelling concurrent systems or for teaching concurrency concepts, my personal interest is in exploring the design space beyond the basic hybrid formalism. This is currently a personal hobby project, so progress will depend on demand and funding.
http://www.cs.kent.ac.uk/~cr3/HCPN/
| Report by: | Martin Sulzmann |
| Participants: | Gregory J. Duck, Simon Peyton Jones, Peter J. Stuckey, Martin Sulzmann, Jeremy Wazny |
| Status: | on-going |
Chameleon is an experimental version of Haskell which incorporates a user-programmable type system based on Constraint Handling Rules (CHRs). Chameleon programs are compiled to plain Haskell, i.e. can be executed by any standard Haskell system such as GHC etc.
Improved Inference for Checking Type Annotations We consider type inference in the Hindley/Milner system extended with type annotations and constraints with a particular focus on Haskell-style type classes. We observe that standard inference algorithms are incomplete in the presence of nested type annotations. To improve the situation we introduce a novel inference scheme for checking type annotations. Our inference scheme is also incomplete in general but improves over existing implementations as found e.g. in the Glasgow Haskell Compiler (GHC). For certain cases (e.g. Haskell 98) our inference scheme is complete.
Unifying GRDTS and type classes with existential types We present a formal framework for existential types and type classes. In contrast to Laeufer’s original proposal our system includes multi-parameter type classes and functional dependencies etc. Our system is powerful enough to express guarded recursive data types, a recent extension of algebraic data types. Type inference in our extension becomes a hard problem. For this purpose, we introduce a novel constraint solver. In general, we lose the principal types property. However, we consider several classes for which we infer a principal type if one exists.
Both extensions have been implemented as part of the Chameleon system.
| 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.2) 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
Project website:
http://www.cs.uu.nl/groups/ST/Center/Top
| Report by: | Atze Dijkstra |
| Participants: | Atze Dijkstra, Doaitse Swierstra |
| Status: | active development |
The purpose of the EHC project is to provide a description a Haskell compiler which is as understandable as possible so it can be used for education as well as research.
For its description an Attribute Grammer system is used as well as other formalisms allowing compact notation like parser combinators.
The EHC project also tackles other issues:
Currently EHC already incorporates more advanced features like higher-ranked polymorphism, partial type signatures, class system, explicit passing of implicit parameters (i.e. class instances), extensible records, kind polymorphism.
Part of these features has been described at the recent AFP summerschool (→1.5.1) (lecture notes yet to appear, handouts are available).
The compiler is used for small student projects as well as larger experiments such as the incorporation of an Attribute Grammar system.
Our plans for the near future are to complete the description of all steps.
We also hope to provide a Haskell frontend dealing with all Haskell syntactic sugar left out of EHC.
http://www.cs.uu.nl/groups/ST/Ehc/WebHome
http://www.cs.uu.nl/research/techreps/UU-CS-2004-037.html
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.2) to generate a framework for generic programming on terms. A new release has been announced in May 2004.
Light-weight generic programming Generic functions for data type traversals can (almost) be written in Haskell itself, as shown by Ralf Laemmel and Simon Peyton Jones in ‘Scrap your boilerplate’ (http://research.microsoft.com/Users/simonpj/papers/hmap/). The “Scrap your boilerplate” approach to generic programming in Haskell has been further elaborated, see the recently published (in ICFP ’04) paper “Scrap more boilerplate: reflection, zips, and generalised casts” available from http://www.cs.vu.nl/boilerplate/. This paper shows how to fill some of the gaps (such as generic zips) which previously were difficult to solve in this approach.
In “Generics for the masses”, ICFP ’04, Ralf Hinze shows how to write generic programs in Haskell98, without any fancy extensions. See http://www.informatik.uni-bonn.de/~ralf/.
Generic Haskell Andres Löh successfully defended his PhD thesis “Exploring Generic Haskell” on September 2, 2004. The thesis describes Dependency-style Generic Haskell, and introduces, amongst others, a new type system for Generic Haskell that at the same time simplifies the syntax and provides greater expressive power. Electronic copies are available at http://www.cs.uu.nl/~andres/ExploringGH.pdf.
Generic Haskell is used in “UUXML: A Type-Preserving XML Schema – Haskell Data Binding” by Frank Atanassow, Dave Clarke and Johan Jeuring, PADL ’04, to implement a Haskell-XML data binding from XML Schemas to Haskell. Furthermore, Atanassow and Jeuring show how to use this data binding together with legacy code in “Inferring Type Isomorphisms Generically”, in MPC ’04.
Ulf Norell and Patrik Jansson at Chalmers show how to prototype generic programming in Template Haskell in a paper with the same title in MPC 2004. Ulf Norell has won the Succ Zeroth IOHCC (→1.5.1) with an obfuscated generic program.
The code generated by Generic Haskell, PolyP, and Clean contains many conversions between structure types and data types, which slows down the generated code. To remove these conversions, a special-purpose partial evaluator has to be written. Alimarine and Smetsers show how to do this (for Clean) in Optimizing generic functions in MPC’04.
Generic Haskell: incorporating views on data types in the language; binding XPath to Haskell, using generic programming for validating XPath expressions against a Schema. Other: the relation between generic programming and dependently typed programming; the relation between coherence and generic programming; better partial evaluation of generic functions; methods for constructing generic programs.
Major Goals: Efficient generic traversal based on type-information for premature termination (see the Strafunski project (→4.3.2)). 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@generic-haskell.org>. See the homepage for how to join.
Arrow notation has been supported by GHC since release 6.2, and was used by John Hughes in the Advanced Functional Programming School this year (→1.5.1). Both the GHC implementation and the arrow preprocessor are actively maintained.
Several people have applications that are slightly more constrained than the Arrow class, but would still like to use arrow notation. Amr Sabry, Josef Svenningsson, Peter Gammie, Simon Peyton Jones and I are discussing possible extensions. It looks complicated.
Hackage (Haskell Package) is an effort to provide a framework for developers to more effectively contribute their software to the Haskell community. The Haskell Cabal (Common Architecture for Building Applications and Libraries) is one aspect of that effort.
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: there is currently no generic build system to abstract away differences between Haskell Implementations and operating systems
Hackage and The Haskell Cabal seek to provide some relief to this situation by building tools to assist developers, end users, and operating system distributers.
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 an alpha release of the first phase, Cabal, the common build system, and some prototype tools for managing package collections and for building OS packages (for Debian) have been implemented on top of this. There are a number of real libraries and tools included as examples (HUnit (→5.4.5) and WASH (→4.7.4), for instance).
The PreludeExts wiki page started with an oft-pasted email on the #haskell IRC channel, where at least once a week someone asked for a permutations function. That sparked a discussion of what code is missing from the Prelude, once the wiki page was started, submissions poured in, resulting in a useful and interesting collection of functions. Last year’s PreludeExts has become this year’s BSD LicensedPreludeExts since John Goerzen wanted to have explicit licensing for inclusion into debian packages. If you contributed code to PreludeExts and haven’t yet moved it to LicensedPreludeExts, please do so!
haskell-libs is slowly being migrated off of sourceforge and into various darcs repositories on ScannedInAvian.org. You can see how it’s going on http://www.ScannedInAvian.org/cgi-bin/darcs.cgi.
This is a useful module for handling command line options of the familiar (–hello) form. It has some nifty features and I think it’s more convenient for the quick every-day standard use than System.GetOpt.
The website above also contains some other things, but should be easy enough to navigate. Specifically, in the “Pesco.Cmdline” section, the distribution tarball is under the link named [dist] and [man] links to the hypertext reference documentation.
The module is a literate program and comes with a complete set of manpages (Yes, real Unix manpages!). See the [doc] link for a PDF rendition of the module itself, [man] for the hypertext manpages, and [ref] for the manpages in PDF (formatted for printing as an A5 booklet).
As of yet, Cmdline does not support explicitly reporting errors, it always calls error. I will add that shortly, however. Also, it is currently not possible to ignore unrecognized command line arguments (for chaining command line parsers) or errors in general. The next version will expose an additional lower-level interface on which such functionality can be built easily.
In the following, I quote a short comparision between System.GetOpt and Pesco.Cmdline which I wrote in reply to a request from the mailing list:
GetOpt’s basic idea, given a type alpha, is to parse each command line option into a value of type alpha. Options to be recognized are specified in “none”, “mandatory”, and “optional” argument variants. For the latter two, a function must be given for mapping the option argument (:: String) to the alpha value.
This means, in the typical use case, you would define that type alpha to represent your different command line options. Then you write suitable readers for the option arguments. If you want explicit reporting of errors in the arguments, you include values in alpha to represent them as well.
After you call the getOpt function, you need to go through the resulting list of alphas to react to your options.
In the Cmdline module, the type alpha is not needed. You again specify the options you want to recognize, stating whether they should take arguments or not. In contrast to GetOpt, each command line option is mapped to a “program parameter”, which is, conceptually, just a named value of some type that is made accessible by calling the get_args function. The parameter’s value is determined by the presence of a corresponding command line option. If the option is not there, a default value is assumed.
Instead of thinking about command line options I want my program to accept, I like to think about run-time parameters it should depend on. I specify those in a list to get_args , which determines their values. Here, boolean parameters correspond to command line flags (given or not given – default False). Options with mandatory arguments can represent parameters of pretty much any type. Those with optional arguments represent types of the form Maybe a – Nothing if not given, Just d if given without argument (d is a default value) and Just x if given with argument (x is the argument value).
To access the parameter values in the program, get_args returns a function mapping parameter names to their value, type forall a. (Typeable a) => String -> a. Each parameter can have several names which correspond directly to the names for the command line options. For instance, if I specify a boolean parameter to be recognized under the names “v” and “verbose”, get_args will accept the flags "-v" and "–verbose" as a consequence. If the function it returns is called parm, I can access that parameter as parm "v" or parm "verbose". Of course the type is checked to match. Parsing of the option arguments also happens automatically.
There has been much discussion about a replacement for the current Time library, because of certain problems with the existing library:
To get up to date on the discussion, be sure to read the threads which lead up to this. The majority of the discussion took place in June 2003: http://haskell.org/pipermail/libraries/2003-June/thread.html
Currently, the discussion has stalled again. The leap seconds issue is something of a sticking point, and there are some implementability question marks over other parts of the API. Contribution to (any aspect of) the discussion is welcomed.
| Report by: | Simon Marlow |
| Contributors: | Ben Rudiak-Gould, Simon Marlow and others |
Some time ago on the libraries mailing list there was a discussion about a replacement for Haskell’s IO library. The main aims are:
See the libraries archives for the discussion, e.g.
Since the previous report some progress has been made on a prototype, which is available here: http://haskell.org/~simonmar/new-io.tar.gz.
The prototype currently supports only basic I/O using files, but has some support for internationalization. I (Simon M.) am not actively working on this at the moment, so anyone that would like to pick this up is entirely welcome.
| Report by: | Simon Marlow |
The System.Process library is now complete, and will be available in the next release of GHC (6.4). In the meantime, the implementation can be found in CVS, in fptools/libraries/base/System/Process.hs.
The current release is 1.2.2. New, since the last report, is the addition of AES courtesy of Lukasz Anforowicz and the inclusion of a module to support large words (Word128, Word192 and Word256) for use as keys.
The library collects together existing Haskell cryptographic functions and augments them so that they:
The library follows the hierarchical standards and has Haddock (→5.5.5) style documentation. There are demo / test programs using published test vectors and instructions on how to use RSA in Haskell and inter-work with openssl. In particular, you can generate key pairs using your favorite method (openssl, for example) and then use them in Haskell. A big improvement on previous versions is the ability to read the private key into your Haskell program via PKCS#8 and use it to decrypt something encrypted with your public key.
There is still plenty of existing code that should be incorporated such as RC4 (courtesy of Doug Hoyte). Shawn Garbett is looking at suppporting X.509 certificates which should allow the use of RSA for encryption and also the use of signatures. With this and PKCS#12, the library should not need much more in the way of addition. Future work includes providing PKCS#12 support, re-writing the ASN.1 module and using Cabal to package the library.
| 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, 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 revisited 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.
Haskore is a set of Haskell modules by Paul Hudak that allow music composition within Haskell, i.e. without the need of a custom music programming language. In general this project aims at improving consistency throughout the package, revising design decisions, fixing bugs, and eventually extending Haskore. In particular some improvements are: The Music structure is based on a more general Media data structure as proposed by Paul Hudak. The core Music data structure is hidden by functions that work on it. The support for infinite Music objects is improved. It is possible to combine music composition with audio signal processing, i.e. it is possible to create audio streams of music entirely with Haskell code. There is a test suite for checking various functions of Haskore.
Introduce a more general notion of instruments which allows for more parameters that are specific to certain instruments. Allow modulation of music similar to the controllers in the MIDI system. Connect to other Haskore related projects. Adapt to the Cabal (→4.1.1) system.
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 version of Yampa 0.4 that contains:
This release adds a BSD style license to the system and fixes a few minor bugs.
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.
Thanks to Abraham Egnor for contributing cairo binding, which uses Yampa for reactive animation. Download instructions are at http://www.cairographics.org/hscairo.
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 existance of Andy’s library) and so i thought i should combine the two. The “new” monadic library is not really new, it is mostly reorganization and cleaning up of the old library. It has been separated from the “base” library so that it can be updated on its own.
The monad transformer library now has its first official release. I have put it on my web page: http://www.cse.ogi.edu/~diatchki/monadLib
It is in many ways similar to what’s distributed with GHC/Hugs/etc, but I think also simplified and better organized. The library intraface is documented with haddock (→5.5.5). The monads/transformers currently in the library are:
HBase is a large collection of library code, compiled “-fno-implicit-prelude”, intended as an experimental/alternative reorganized interface to the existing standard libraries making full use of GHC’s extensions. HBase development is driven by HScheme (→6.1.1) and my other Haskell projects, and sometimes by whatever interests occur to me. Right now it includes:
Very little work is currently being done on it, as the main developer’s free time has been shortened by gainful employment. Further work may resume, at a reduced pace, once left-over issues in the latest JVM-Bridge (→5.1.3) have been cleared up.
Pointless Haskell is a library for point-free programming with recursion patterns defined as hylomorphisms. It is part of the UMinho Haskell libraries that are being developed at the University of Minho (→7.1.8). The core of the library is described in “Point-free Programming with Hylomorphisms” by Alcino Cunha.
Pointless Haskell also allows the visualization of the intermediate data structure of the hylomorphisms with GHood. This feature together with the DrHylo (→5.2.7) tool allows us to easily visualize recursion trees of Haskell functions, as described in “Automatic Visualization of Recursion Trees: a Case Study on Generic Programming” (Alcino Cunha, In volume 86.3 of ENTCS: Selected papers of the 12th International Workshop on Functional and (Constraint) Logic Programming. 2003).
The Pointless Haskell library is available from http://wiki.di.uminho.pt/bin/view/Alcino/PointlessHaskell.
hs-plugins is a library for dynamic loading and runtime compilation of Haskell modules at runtime, into Haskell and foreign applications. It can be used to implement standard application plugins, hot swapping of modules in running applications, and enables the use of Haskell as an application extension language. The library has stabilised in the last six months, and we hope to release v1.0 around January 2005.
Source and documentation can be found at http://www.cse.unsw.edu.au/~dons/hs-plugins.
MissingH is a library designed to provide the little “missing” features that people often need and end up implementing on their own. Its focus is on list, string, and IO features, but extends into other areas as well. The library is 100%pure Haskell code and has no dependencies on anything other than the standard libraries distributed with current versions of GHC and Hugs.
In addition to the smaller utility functions, recent versions of MissingH have added a complete FTP client parser library, a MIME type guesser, 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.
MissingH is available from http://quux.org/devel/missingh.
Parsec is a practical parser combinator library for Haskell that is well documented, has extensive libraries, and good error messages. It is currently part of the standard Haskell libraries (in Text.ParserCombinators.Parsec) and has been stable for a while now. We plan to add a module that adds combinators to parse according to the (full) Haskell layout rule (available on request).
| Report by: | Joost Visser |
| Status: | active, maintained, new release in October 2004 |
| 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:
The Medina library is a Haskell library for GHC that provides tools and abstractions with which to build software metrics for Haskell programs.
The library includes a parser and several abstract representations of the parse trees and some visualization systems including pretty printers, HTML generation and callgraph browsing. The library has some integration with CVS to allow temporal operations such as measuring a metric value over time. This is linked with some simple visualization mechanisms to allow exploring such temporal data. These visualization systems will be expanded in the near future.
We have carried out case studies to provide some validation of metrics by looking at the change history of a program and how various metric values evolve in relation to those changes. In order to do this we implemented several metrics using the library, which has given some valuable ideas for improvements to the library.
Following on from the case studies we have improved and extended the visualization systems and implemented some of the ideas from the case studies. Demos and screenshots are available on the Medina webpage: http://www.cs.kent.ac.uk/~cr24/medina.
Currently there is no released version of the Medina library, but my PhD thesis has been submitted so I am now in the process of preparing a release. This should be available real-soon-now.
DData is a library of efficient data structures and algorithms for Haskell (Set, Bag, and Map). It is actively maintained and stable.
DData is currently under review for inclusion in the standard hierarchical module name space, and you are invited to join the discussion on the Haskell libraries mailing list.
The current proposal is maintained by J.P. Bernardy and can be found at: http://users.skynet.be/jyp/DData/doc and http://users.skynet.be/jyp/DData/ddata.tar.gz
| Report by: | Oleg Kiselyov |
| Developers: | Oleg Kiselyov, Ralf Lämmel, Keean Schupke |
| Maintainer: | Ralf Lämmel |
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. The HList library relies on common extensions of Haskell 98.
We are currently working on applications of HList to a powerful object-oriented system and to expressive type-level programming.
The HSQL is a simple library for database access from Haskell. It is relatively small and complete. bug fixes are always welcome and If someone is wishing to add a new backend I will be glad to help him.
Takusen is a library for accessing DBMS’s. It is a low-level library like HSQL (→4.4.3), in the sense that it is used to issue SQL statements. Takusen’s ‘unique-selling-point’ is a design for processing query results using a left-fold enumerator. For queries the user creates an iteratee function, which is fed rows one-at-a-time from the result-set. We also support processing query results using a cursor interface, if you require finer-grained control.
Takusen is under active development, although progress is slow. Since the last HC&A Report we have added support for Sqlite, re-organised the library modules, addressed some performance problems, and improved the Oracle connection code (OS-authenticated logon is possible now). We plan to continue adding implementations for other DBMS’s, and support for bind variables. We’re also reviewing the current design, with a view to doing everything in the IO monad, rather than using monad transformers. We expect this to make the code (both library and user) a bit simpler; users won’t have to use liftIO to perform IO actions inside database actions.
| Report by: | Anders Höckersten |
| Status: | active development and maintenance |
| Portability: | GHC, Hugs, multiple platforms |
HaskellDB is a library for accessing databases through Haskell in a type safe and declarative way. It completely hides the underlying implementation and can interface with several popular database engines through either HSQL (→4.4.3) or wxHaskell (→4.5.2). HaskellDB was originally developed by Daan Leijen. Development was restarted as part of a student project at Chalmers University of Technology. This project is now over, but several of the original project members are still actively developing and maintaining HaskellDB. We do welcome new developers and patches, as all of us are full-time students.
The current version supports:
Future possible developments include:
The usefulness of the Haskell language depends crucially on the provided libraries. In particular, efforts to write an application with a graphical user interface has long been complicated by the large number of mostly incomplete libraries (or research prototypes). In spring 2003 people tried to focus the development effort and came up with the idea of a Common GUI API (CGA for short) which should define an intersection of three major platform APIs (Win32, Gnome/Gtk and Mac OS X) and that addresses the requirements of the platform’s style guide (or human interface guidelines). At the Haskell Workshop 2003 a quick poll revealed that 1/3 of the people thought that this major undertaking is worthwhile, 2/3 thought that a new binding to a readily available cross-platform approach is adequate. Hence the CGA idea was not pursued and wxHaskell, a binding to wxWidgets, is recommended for new developments. Other libraries might of course continue to exist, in particular if they fill a niche for some applications.
wxHaskell is a portable GUI library for Haskell. The goal of the project is to provide an industrial strength portable GUI library, but without the burden of developing (and maintaining) one ourselves.
wxHaskell is therefore build on top of wxWidgets – a comprehensive C++ library that is portable across all major GUI platforms; including GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library (in development since 1992) that supports a wide range of widgets with native look-and-feel, and it has a very active community (ranked among the top 25 most active projects on sourceforge). Many other languages have chosen wxWidgets to write complex graphical user interfaces, including wxEiffel, wxPython, wxRuby, and wxPerl.
Since most of the interface is automatically generated from the wxEiffel binding, the latest release of wxHaskell already support