Parallel GHC project: new opportunity for an organisation to participate

Wednesday, 08 June 2011, by Duncan Coutts.
Filed under parallel, well-typed.

GHC HQ and Well-Typed are pleased to announce a new opportunity for an organisation to take part in the Parallel GHC Project.

The project started in November 2010 with four industrial partners, and consulting and engineering support from Well-Typed. Each organisation is working on its own particular project making use of parallel Haskell. The overall goal is to demonstrate successful use of parallel Haskell and along the way to apply engineering effort to any problems with the tools that the partner organisations might run into.

We have capacity to support another partner organisation for the remaining duration of the project (at least another 12 months). Organisations do not need to contribute financially but should be prepared to make a significant commitment of their own time. Familiarity with Haskell would be helpful, but Haskell expertise is not needed. Partner organisations' choice of projects is similarly open-ended and could be based on anything from pre-existing code bases to green field endeavours.

We would welcome organisations interested in pure parallelism, concurrency and/or distributed Haskell. Presently, two of our partner organisations are using mainly pure parallelism and two are using concurrency. What would be especially interesting for us is to diversify this mix further by working with an organisation interested in making use of of distributed Haskell, in particular the work highlighted in the recent paper "Haskell for the Cloud" (pdf).

To help give an idea what participating in the Parallel GHC Project is like, here is what some of what our current partner organisations have to say:

The Parallel GHC Project has enabled us to make steady progress towards our goals. Well-typed has provided support in the form of best practice recommendations, general engagement with the project, and directly coding up key components.

I have been getting lots of help from Well-Typed, and enjoy our weekly meetings.

― Finlay Thompson, Dragonfly

My organization is now trying to implement highly concurrent Web servers. After GHC 7 was released we faced several critical bugs in the new IO manager and one guy at Well-Typed kindly fixed all the bugs. This has been a big benefit for our organization.

Another benefit is feedback/suggestions from Well-Typed. Well-Typed and our organization have meetings every other week and we report progress to each other. During the discussions, we can set the right direction to go in.

― Kazu Yamamoto, IIJ Innovation Institute Inc.

Well-Typed is coordinating the project, working directly with the participating organisations and the Simons at GHC HQ. If you think your organisation may be interested then get in touch with me, Duncan Coutts, via

Parallel Haskell Digest 2

Wednesday, 11 May 2011, by Eric Kow.
Filed under parallel, ph-digest.

Welcome to the second edition of the Parallel Haskell Digest, bringing you news, discussions and tasters of parallelism and concurrency in Haskell.

The digest is made possible by the Parallel GHC project. More news about how we're doing below.


Word of the Month

This edition of the digest is brought to you by threads, threads and more threads. In the last digest, we took a look at Haskell sparks and particularly at how they differ from threads. Now let's delve a little bit deeper into threads.

A "thread of execution" is a programming abstraction that helps the programmer separate concerns within a program. Consider a web server serving many documents to many clients simultaneously. The programmer may wish to use threads, using one thread per client making it easier to manage concurrent action.

In the Haskell world, this programming abstraction is provided by Haskell threads. To implement Haskell threads, the GHC runtime system uses what is known as a M:N threading model, where many Haskell threads are scheduled across a much smaller number of operating system threads. This model has two key benefits:

Don Stewart illustrated this on StackOverflow with the following diagram, citing 2011 figures of about a handful of CPUs, a dozen or so OS threads and tens of thousands of Haskell threads (plus for those of us interested in pure parallelism, millions of sparks).

Thread illustration by Don Stewart

If you want to try generating some figures for yourself, have a look at this nofib benchmark utility. The benchmark tool creates a large "pipeline" of simultaneous Haskell threads, and tries to send a message through the pipeline, passing it from one thread to the next. On my laptop, I can create 10000 Haskell threads in 0.074 seconds and pump "Hello World" through them in 0.07 seconds. That works out to 7.4 microseconds per thread (0.7 microseconds for pumping). How about giving it a shot on your computer? Haskell threads are very lightweight.

For most concurrency needs, you can generally forget that operating system threads exist. Indeed, when the documentation for modules like Control.Concurrent refers to "threads", or when Haskell hackers discuss threads in Haskell code it's a good bet that they're referring to Haskell threads rather than OS threads.

That said, there are a few occasions where you may want to be aware about OS threads, in order of importance, if you

Doing any of these things requires that you use GHC's multi-threaded runtime system. GHC currently uses a single-threaded runtime system by default, but until this changes, you will have to explicitly enable the multi-threaded one by linking your program with the flag -threaded. With the multi-threaded runtime system all Haskell threads are scheduled across multiple OS threads as opposed to being interleaved on a single one. This allows for parallelism in the first case, for concurrent foreign code in the second case.

For the first case, where you are specifically interested in parallelism, as well as enabling the multi-threaded RTS you also need to tell the runtime system how much parallelism to try to use. Specifically, you have to say how many OS threads will be used for scheduling your program's Haskell threads. You can do this by passing +RTS -N when you run your program (with GHC 6.12.1 and higher, the bare -N flag will cause the RTS to use a sensible default based on the number of CPU cores on your machine).

If you are only concerned about making foreign calls, just enabling the multi-threaded RTS is enough. The issue with the single-threaded runtime system is that Haskell threads that make foreign calls to the operating system or C libraries will block all other Haskell threads. This means that if a foreign call should take a long time, or worse, if it should block in its own right, all other Haskell threads will be stuck. With the multi-threaded runtime system, Haskell threads that make foreign calls do not block other Haskell threads, because they can be handed over to another OS thread while the one making the foreign call is churning away.

But be careful! Concurrency with foreign calls can be a tricky business. If you are only using one OS thread at a time, you are effectively shielded from having to worry about concurrency issues in foreign code (by not being able to run foreign code concurrently). Enabling multi-threaded mode comes with extra responsibility of making sure any foreign libraries you use are thread-safe, or that you have adequate mechanisms to deal with the ones that are not. Thread-safety isn't an issue with Haskell-only code because shared state is always managed with locks or atomicity. But when concurrency and foreign calls mix, you will need to take care.

There's another issue to watch out for when mixing foreign calls with multiple OS threads. The nice thing thing about the M:N threading model in Haskell is that the GHC RTS scheduler will automatically move Haskell threads between OS thread to achieve a good balance of work. But this introduces a new problem for foreign libraries that use thread-local state: the Haskell thread may calling the library from any number of OS threads, so if the foreign library uses OS-thread-local state then this state could be different from one call to the next... what a mess! To solve this problem we have to use a feature called "bound threads". Bound threads are Haskell threads that are bound to a single OS thread; they are not moved around by the scheduler. Bound threads are more expensive than unbound ones because they tie up a whole OS thread, but they are necessary for working with certain foreign libraries like OpenGL that make essential use of thread local state.

Summing up threads in Haskell:

Thanks to Paul Bone for the paragraph presenting threads as a programming abstraction and also to Andres Löh and Duncan Coutts from Well-Typed for extensive help revising this word of the month!

Parallel GHC project news

The Parallel GHC Project is an MSR-funded project to push the real-world use of parallel Haskell. Part of this project involves effort by Well-Typed to provide tools for use by the general community:

We have begun work on making the "Modified Additive Lagged Fibonacci" and perhaps other random number generators from the SPRNG library available in Haskell. As a first step to the Haskell SPRNG reimplementation, we have developed a binding to the existing C++ library. The binding will serve as a reference implementation to test against, but it also ready to be used now.

To complement our work on extending GHC eventlog and Threadscope to support multi-process or distributed Haskell systems, we have begun work on developing new visualisations for ThreadScope, including the rate of parallel spark creation, and the distribution of spark evaluation times.

Meanwhile, work continues on our project partners' side. We hope to be say more about it in the next edition of the digest :-)

For more information on the Parallel GHC project, see the Haskell wiki page


Blogs, papers and packages

Parallel-Haskell and Haskell Cafe

Stack Overflow

Help and feedback

Got something for the digest? Send me an email at I'm particularly interested in short parallelism/concurrency puzzles, cool projects for featured code. Other comments and feedback (criticism and corrections especially!) would be welcome too.

Parallel Haskell Digest 1

Thursday, 31 March 2011, by Eric Kow.
Filed under parallel, ph-digest.

I'd like to introduce the first Parallel Haskell Digest, a newsletter aiming to show off all the work that's going on using parallelism and concurrency in the Haskell community.

The digest is a bit of an experiment. For the community in general, I hope to help you catch up with a monthly recap of news, interesting blog posts and discussions about parallelism in Haskell. For people (like me) who are new to parallelism and concurrency in Haskell, or maybe just have a passing interest, I hope to give you little nibbles, with regular features like the Word of Month, Featured Code and Parallel Puzzlers.

Finally, as a bit of disclosure, I'm writing this digest as part of my work to promote the Parallel GHC Project. So don't be surprised if I give it a little special emphasis :-)

Word of the Month

This very first edition of the PH digest is brought to you by the word spark. You may have heard of sparks and threads in the same sentence. What's the difference?

A Haskell thread is a thread of execution for IO code. Multiple Haskell threads can execute IO code concurrently and they can communicate using shared mutable variables and channels.

Sparks are specific to parallel Haskell. Abstractly, a spark is a pure computation which may be evaluated in parallel. Sparks are introduced with the par combinator; the expression (x par y) "sparks off" x, telling the runtime that it may evaluate the value of x in parallel to other work. Whether or not a spark is evaluated in parallel with other computations, or other Haskell IO threads, depends on what your hardware supports and on how your program is written. Sparks are put in a work queue and when a CPU core is idle, it can execute a spark by taking one from the work queue and evaluating it.

On a multi-core machine, both threads and sparks can be used to achieve parallelism. Threads give you concurrent, non-deterministic parallelism, while sparks give you pure deterministic parallelism.

Haskell threads are ideal for applications like network servers where you need to do lots of I/O and using concurrency fits the nature of the problem. Sparks are ideal for speeding up pure calculations where adding non-deterministic concurrency would just make things more complicated.

Parallel GHC project news

The Parallel GHC Project is an MSR-funded project to push the real-world use of parallel Haskell. Part of this project involves effort by Well-Typed to provide tools for use by the general community:

Work shall soon begin working on making the "Modified Additive Lagged Fibonacci" and perhaps other random number generators from the SPRNG library available in Haskell. Current plans are to implement the algorithms directly in Haskell, and to expose them as instances of System.Random.RandomGen. These generators are attractive for use in Monte Carlo simulations because they are splittable and have good statistical quality, while providing high performance.

Work is underway on extending the GHC EventLog and associated tools (ghc-events, ThreadScope). The aim is to support profiling of multi-process or distributed Haskell systems such as client/server or MPI programs. This involves incorporate some changes made in related projects (Eden, EdenTV). This work may have some benefits even for profiling single-process programs. It should also allow comparative profiling where multiple runs of the same program (e.g. different inputs or slightly different code) are viewed on the same timeline.

For more information on the Parallel GHC project, see the Haskell wiki page.

Featured Code

The feature code for this month is hulk, an IRC server in 1250 lines of code. Hulk was coded up by Chris Done in one evening, and it was used the next morning. (Chris has done a bit of cleaning up since).

Here's what Chris had to say about his experience writing Hulk:

Haskell's lightweight threads make it natural (and guilt-free!) to choose the design of one-thread-per-client. With a single MVar containing a pure value for the whole server-state, and the help of a monad stack of ReaderT(connection information), WriterT (replies) and StateT (user details), it was trivial to make the bulk of the code completely pure. LineBuffering on the (Handle-wrapped) sockets tripped me up; as opposed to NoBuffering, this did not behave as expected: many threads would block when only one should have. Overall, it was textbook Haskell; keep the main code pure, and only the truly impure in the outer shell.

It's up on hackage so you can install it with a quick

cabal install hulk

You can also fork his code on GitHub.

Got a cool use of Parallel Haskell or an interesting problem? Nominate it for the PH digest featured code/parallel puzzler!

Blog Posts

Parallel-Haskell and Haskell Cafe

Stack Overflow

Help and feedback

Got something for the digest? Send me an email at I'm particularly interested in short parallelism or concurrency puzzles, cool projects for featured code. Other comments and feedback (criticism and corrections especially!) would be welcome too.

More help with the Parallel GHC Project

Wednesday, 02 March 2011, by Duncan Coutts.
Filed under well-typed.

In addition to the full-time job we advertised recently, Eric Kow will be helping us out one day a week with the Parallel GHC Project.

Eric has become well known for the excellent work he's done organising the darcs project in recent years. He will be applying his talents to help us manage and promote the Parallel GHC Project. The Parallel GHC Project is not just about "getting useful stuff done" and helping the four partner organisations. We also aim to promote practical parallel Haskell tools and techniques to the wider industry.

So, welcome Eric! And if you start seeing Eric going on about parallelism then don't be surprised.

Well-Typed are hiring: Haskell consultant

Tuesday, 15 February 2011, by Ian Lynagh.
Filed under well-typed.

In order to keep up with customer demand, we are looking to hire a Haskell expert to work with us at Well-Typed as a Haskell consultant.

This is an exciting opportunity for someone who is passionate about Haskell and who is keen to improve and promote Haskell in a professional context.

The role is quite general and could cover any of the projects and activities that we are involved in as a company. The tasks may involve:

Well-Typed has a variety of clients. For some we do proprietary Haskell development and consulting. For others, much of the work involves open-source development and cooperating with the rest of the Haskell community: the commercial, open-source and academic users.

Our ideal candidate has excellent knowledge of Haskell, whether from industry, academia, or personal interest. Familiarity with other languages, low-level programming, and good software engineering practices are also useful. Good organisation and ablity to manage your own time, and reliably meet deadlines, is important. You are likely to have a batchelor's degree or higher in computer science or a related field, although this isn't a requirement. Experience of consulting, or running a business, is also a bonus.

The position is initially as a contractor for one year with a salary of 150 GBP per day, plus a bonus if profits are high. We offer flexible hours and work from home. Living in England is not required.

In the longer term there is the opportunity to become a member of the partnership with a full stake in the business: being involved in business decisions, and fully sharing the risks and rewards.

If you are interested, please apply via Tell us why you are interested and why you would be a good fit for the job, and attach your CV. We are more than happy to answer informal enquiries. Contact Duncan Coutts, Ian Lynagh or Andres Löh for further information, either by email or IRC.

The deadline for applications is Tuesday 1st March 2011.

About Well-Typed

Well-Typed LLP is a Haskell services company, providing consultancy services, writing bespoke applications, and offering commercial training in Haskell and related topics.

How much tea

Friday, 14 January 2011, by Duncan Coutts.
Filed under well-typed.

Have you ever wondered how much tea an Englishman needs to drink to write a PhD thesis? After expending considerable time and effort I have discovered that the answer is approximately this much...

(

Parallel Haskell project underway

Monday, 15 November 2010, by Dmitry Astapov.
Filed under well-typed, parallel.

GHC HQ and Well-Typed are pleased to report that work has started on the MSR-funded project to push the real-world use of parallel Haskell.

We will be working with four industrial partners over the next two years, with the aim of demonstrating that parallel Haskell can be employed successfully in industrial projects.

The participating organizations are:

Each group is working on their own project, applying parallel Haskell and their domain-specific expertise. In addition to providing advice on Haskell tools and techniques, we will work with these partners to identify and resolve any issues that are hindering progress. We are prepared to handle issues covering anything from the compiler and runtime system, through to platform, tool and library problems.

All the participants are working on complex, real-world problems. Three projects involve scientific problems, and the fourth involves network servers. Three of the projects are targeting single-node SMP systems, while the fourth is targeting clusters. In two cases, Haskell will be directly pitted against existing code written in C or C++.

Project progress reports will be posted to the Well-Typed blog and to Parallel Haskell mailing list.


Participants: Finlay Thompson, Edward Abraham

Cloudy Bayes: Hierarchical Bayesian modeling in Haskell

The Cloudy Bayes project aims to develop a fast Bayesian model fitter that takes advantage of modern multiprocessor machines. It will support model descriptions in the BUGS model description language (WinBUGS, OpenBUGS, and JAGS). It will be implemented as an embedded domain specific language (EDSL) within Haskell. A wide range of model hierarchical Bayesian model structures will be possible, including many of the models used in medical, ecological, and biological sciences.

Cloudy Bayes will provide an easy to use interface for describing models, running Monte Carlo Markov chain (MCMC) fitters, diagnosing performance and convergence criteria as it runs, and collecting output for post-processing. Haskell's strong type system will be used to ensure that model descriptions make sense, providing a fast, safe development cycle.

IIJ Innovation Institute Inc.

Participants: Kazu Yamamoto

Haskell is suitable for many kinds of domain, and GHC's support for lightweight threads makes it attractive for concurrency applications. An exception has been network server programming because GHC 6.12 and earlier have an IO manager that is limited to 1024 network sockets. The upcoming GHC 7 has a new IO manager implementation that gets rid of this limitation.

This project will implement several network servers to demonstrate that Haskell is suitable for network servers that handle a massive number of concurrent connections.

Los Alamos National Laboratory

Participants: Michael Buksas, Timothy M. Kelley

This project will use parallel Haskell to implement high-performance Monte Carlo algorithms, a class of algorithms which use randomness to sample large or otherwise intractable solution spaces. The initial goal is a particle-based MC algorithm suitable for modeling the flow of radiation, with application to problems in astrophysics. From this, the project is expected to move to identification of suitable abstractions for expressing a wider variety of Monte Carlo algorithms, and using models for different physical phenomena.

Willow Garage

Participants: Ryan Grant

Distributed Rigid Body Dynamics in ROS

Willow Garage seeks a high-level representation for a distributed rigid body dynamics simulation, capable of excellent parallel speedup on current and foreseeable hardware, yet linking to existing optimized libraries for low-level message passing and matrix math.

This project will drive API, performance, and profiling tool requirements for Haskell's interface to the Message Passing Interface (MPI) specification, an industry-standard in High Performance Computing (HPC), as used on clusters of many nodes.

Competing internal initiatives use C++/MPI and CUDA directly.

Willow Garage aims to lay the groundwork for personal robotics applications in everyday life. ROS (Robot Operating System - is an open source, meta-operating system for your robot.

Post-ICFP summary

Friday, 15 October 2010, by Duncan Coutts.
Filed under community.

It's been a bit over a week since we all got back from ICFP in Baltimore. I thought I'd write up a little report with my perspective.

As usual it was great fun. I basically count it as a holiday, though not a very restful one, with a packed programme of talks and every other waking moment spent jabbering to friends and colleagues.

ICFP and its associated workshops

This year the conferences seemed to be arranged in a progression from most highly academic and mathematical towards the more practical and commercial. I don't know if it was deliberate, but it seemed to work fairly well. People could arrive or leave at the point suiting their interest. It was quite interesting to see how the mix of people changed through the week. I missed the metatheory, mathematically structured FP and generic programming, but arrived in time for the main 3-day ICFP conference and stayed through to the end.

Well-Typed was pretty well represented at the conferences this year. Andres was on the ICFP programme committee and had a paper accepted for the Haskell Symposium. I was on the Haskell Symposium programme committee (but didn't review Andres et al's paper of course!) and along with Simon Marlow, I co-organised the Haskell Implementors' Workshop.

In theory I co-authored a presentation with Don Stewart on Hackage, Cabal and the Haskell Platform though in practice he did it all and I just reviewed the slides and made a few suggestions. I had a slight feeling beforehand that there was not really that much to talk about, partly because I'm feeling a little frustrated that I have not been able to spend more time on Cabal. On reflection however there was plenty to say, we have made quite a bit of progress during the year, especially in establishing the platform as the way most people get their Haskelly goodness.

Colin Runciman, Don and I spent a good couple hours plotting for a paper, perhaps for ICFP or the Haskell Symposium next year. I'm looking forward to working with Colin and Don on that. It's a nice bit of classic lazy functional programming I think.

Simon Marlow and I declared that we would hand over the organisation of the Haskell Implementors' Workshop to a new team and we've already got a couple volunteers from this year's programme committee. So I had thought that I would not be organising anything for next year's ICFP in Japan. That was until Michael Sperber asked if I would like to help him organise the CUFP tutorials next year. If you were at ICFP in the last couple years you may remember DEFUN, the functional programming developer tracks. This year they were rebranded as being part of CUFP. The idea is to appeal more to programmers using (or wanting to use) FP at work and to help persuade managers that it is worthwhile training.

Paper highlights

A couple papers from the Haskell Symposium that I particularly liked, or thought significant:

STG in Coq or to give the proper paper name A Systematic Derivation of the STG Machine Verified in Coq, by Maciej Piróg and Dariusz Biernacki from the University of Wrocław in Poland. They presented a fragment of a bigger project to build a verified Haskell compiler, perhaps similar to Xavier Leroy's work on a verified C compiler. To verify that a compiler faithfully translates a program in a high level language to a program with the same meaning but in a low level language, what you need is a proper formal connection between the high and low level languages. And of course it is not just a high and low level but a whole series of intermediate languages. Xavier's "compcert" uses about a dozen intermediate languages. Real compilers also use several intermediate languages. GHC goes from Haskell, to Core (System Fc) to STG to C-- and finally into either C, LLVM or assembly. This paper focuses on STG which is the language on the boundary between the functional world and the imperative world. From the functional side it is just a stylised subset of Core, but the same language also has an imperative semantics using an abstract machine that explains how to efficiently execute it. The paper makes the formal connection between the functional and imperative semantics of the language. I'm looking forward to more work from this team.

J. Garrett Morris presented an experience report on Using Hackage to Inform Language Design. I thought this was great, but not just because he cites one of my old blog posts as inspiration! The basic idea is really simple: take advantage of the fact that we have a large amount of publicly available code in a standardised form to get empirical data to inform questions about language design. Getting lots of real data has not generally been the tradition in the programming language community, partly because it is so hard to get (but also because we have ideas about what programmers ought to do). He gave an example to do with the design of the type class system, and did a survey to see how overlapping instances are used in practice. The tools at this stage are a bit hacky but with a little work it could be improved and automated much more. I hope we will see more people taking this approach in future, especially to help the Haskell prime process.

"The Future of Haskell" discussion

Traditionally, the Haskell Symposium ends with a long discussion entitled "The Future of Haskell". For the past few years this session has become less and less about the future direction of the language or about uncomfortable home truths and more about incremental changes and infrastructure (like Hackage and the Haskell Platform). Recognising this, the programme committee this year decided to scrap the future of Haskell discussion and just have short reports on the progress of the language standard i.e. Haskell 2010 and the future 2011/2012 revision.

For the implementors' workshop we decided to pick up the baton from the symposium and run a "Beyond Haskell" discussion. The idea was to be a bit less self-congratulatory, more forward looking and to pose uncomfortable questions. To kick things off we had Ben Lippmeier give a short intro. I didn't know beforehand what direction he would take, but we expected he'd do something interesting and we were not disappointed.

Ben talked about the problem of performance, that we often know what ugly fast low level program we want to write, but we have difficulty in expressing it in a high level way that we can reliably translate into the ugly fast version. So it's not that we cannot write fast programs but we want to have our cake and eat it, we want to write nice programs and reliably generate fast programs. People who work on this often end up writing Haskell but constantly studying the generated core to see why the transformation they wanted didn't quite work out. Reliability can be crucial: if it is a transformation that makes a 10x or 100x difference then you need to be sure that it is going to work. Perhaps not everyone worries about performance like this but it struck a chord with me because it was more or less exactly the issue I had in mind when I started my PhD. I was working on partial evaluation with the notion that the programmer would be able to control the compile-time transformations that generate the fast program from the nice program. I still think it's an approach worth investigating.

All the HIW slides and videos are on the HIW wiki page. Thanks to all the presenters for making their slides available and to Malcolm Wallace for videoing the whole event.

The Haskell "BoF" session

One of the things that CUFP started doing this year is "birds of a feather" (BoF) sessions. The idea is to get groups together for a couple hours to discuss some topic of interest in the community. Bryan and Johan organised a session on "Haskell in the real world". It was a pretty interesting and useful discussion I thought, particularly in relation to how we make improvements in infrastructure and attract volunteers to do that. We also talked quite a bit about what needs doing to keep up Haskell adoption, like coherence of the web presence, IDEs etc. Don did a good job as secretary and posted his notes afterwards.

Google Summer of Code

I was very pleased this summer to be involved with two GSoC projects and two excellent students. I was not technically the mentor in either case but since they were both related to Cabal/Hackage then I could hardly not be involved!

What I was especially pleased about is that both of them came to the Haskell Implementors' Workshop to give presentations about their GSoC projects. The HIW programme committee were very supportive of their talk proposals. The talks were on topic (being about infrastructure), they were useful for disseminating news to the community, and having GSoC students attend is great for integrating them into the community.

The new hackage

Matt Gruen has been working on the new hackage server implementation which will give us a decent extensible platform for adding the new haskage features that everyone has been clamouring for.

Matt has the new hackage server code running on sparky and has recently been working on the process of how we will transition from the old to the new server. If anyone wants to help him with that, I'm sure he would appreciate it. There are quite a few things to do. He's got a plan up on the wiki. You can find him by email or in the #hackage IRC channel on freenode.

Cabal test

Thomas Tuegel was working on "cabal test" which is a new Cabal feature to let packages define test suites and have other tools run them and collect results.

As anyone following the cabal-devel mailing list will have noticed from the deluge of patches, I finally finished reviewing and applying all of Thomas's cabal test patches. The plan is that this will be in Cabal-1.10.x which will come with GHC 7. If you watch Thomas's presentation you'll understand that one of the important features of the design is that we can have different protocols that test suites can support. So far we have two protocols, a basic one and a more detailed one. For the Cabal-1.10 release however we will enable just the basic "exitcode-stdio" test interface. We will continue to work on the more detailed interface in the development version of Cabal. In particular we are working with Max Bolingbroke, author of the popular test-framework package, to refine the interface for describing sets of tests.

Taken together, these two projects are an important step in our long term plan to make it easier to work out which are the high quality packages on hackage and to improve package quality overall.

Come to the Ghent Hackathon!

Tuesday, 07 September 2010, by Duncan Coutts.
Filed under community.

I'm pleased to announce that Well-Typed is sponsoring the next Haskell Hackathon, which is now just two months away. BelHac will be in Ghent, Belgium, November 5th-7th.

We would like to encourage people to come along. It's a great opportunity to learn about exciting projects and to meet interesting people. The entire Well-Typed team will be there!

If you're planning to come along then please help out the organisers by registering now.

Well-Typed Hires Two Additional Consultants

Monday, 06 September 2010, by Ian Lynagh.
Filed under well-typed.

We are please to announce that, following our recent hiring process, we have taken on two additional consultants in order to meet our upcoming commitments.

Andres Löh

Andres started using Haskell in 1997. Since then, he has used Haskell for most of his programming projects. He has participated in the ICFP programming contest multiple times, and won it in a team together with Duncan Coutts, Ian Lynagh and Ganesh Sittampalam in 2004, with an all-Haskell entry.

Andres is a well-known member of the Haskell community. He maintains several tools and libraries on Hackage. He has also packaged Haskell compilers and libraries for the Gentoo and NixOS Linux distributions.

Andres obtained a PhD in Computer Science from Utrecht University in 2004. Since 2004, he has worked as a lecturer and researcher at the Institute of Cybernetics in Tallin, and at the universities of Freiburg, Bonn, and Utrecht. Andres' research is focused on improving abstraction and reuse in functional programs, by using or enhancing the underlying type system. His interests also include embedded domain specific languages, version control and typesetting.

Andres was the program chair of the 2006 ACM SIGPLAN Workshop on Haskell. He has served as a program committee member for several other academic conferences and has published regularly at conferences and journals. He also has extensive experience in teaching Haskell to undergraduate and graduate students, as well as people with an industrial background.

Andres will begin working for Well-Typed in November.

Dmitry Astapov

Dmitry has ten years of experience using Haskell for solving practical problems. He has used Haskell as a day-to-day scripting language, for large and small projects, at full-time jobs and in consulting projects. He has created several hackage packages and contributed to various Haskell projects including darcs, xmonad, bytestring, happs, HaXml and lambdabot. He has written several tutorials, written content for the Haskell wiki, and is currently editor of a Russian-language magazine on functional programming for which he writes articles on a regular basis. He has supported Haskell newcomers and mentored students as part of the Google Summer of Code programme.

He holds a bachelors degree in applied math and a specialists degree in computer science from the Taras Shevchenko National University of Kiev, Ukraine.

Dmitry has already started working for Well-Typed.

Previous entries

Next entries