Revision as of 21:04, 18 March 2010

If you've found this page, you use Haskell, and live in Australia (or at the very least able and willing to travel here), then you're in the right place! We're looking into organising a Haskell Hackathon some time during the middle of 2010, and this where it shall be organised.

If you're interested in coming, please put your name down on the list below, along with your IRC nickname if you're on #haskell, and possibly your email (We'll use this to let you know of any progress we've made, but it's not mandatory). Also, if you've got something to discuss, feel free to add it to the bottom of the page in the Discussion section (just to keep the rest of the page clean and helpful).

1 What we've got so far

1.1 Why

Because we miss out on all the fun they have up north, and we've got something to offer. It's also a great chance to meet all these people you talk to on IRC, or read their blogs, and just have a good time, while getting some (potentially) useful work done!

1.2 When

A few dates have been discussed, mainly taking into account when the university holidays are for various universities:

ANU: 7 June -> 18 July

UNSW: 29 June -> 18 July

So so far we need a weekend between the 28th of June and the 18th of July.

We're looking at organising it over a weekend, and I (Axman6) would quite like to have it start on a Friday, ending on Sunday. This does not at all mean that those who can’t make the Friday will miss out, the more people we have, the better. But I think that having more time will mean that we can get more done (which is the point right?).

1.3 Where

Manuel Chakravarty and Ben Lippmeier have said there should be no problem finding a room at UNSW, with the only possible problem being Internet access for everyone, but hopefully something can be arranged by that time.

1.4 Who

If you're interested in coming, please show your interest by adding your details to the list below (if you don't have an account, please email me (Axman6) your details and I'll add you).

2 Discussion

2.1 Possible Projects

2.1.1 Generic graph class

What: I (Ivan) last year floated the idea of replacing the current default array-based Graph data type with an extensible set of classes with default instances. There's various interest about this around and I've done some work on it, but if there's anyone else coming it'd be better to bounce ideas together about how to define such classes.

Who: Ivan M

2.1.2 Gloss-based plots

What: Either an alternative graphing back end to Criterion that only relies on OpenGL (through the use of Gloss), or a library for plotting. At the moment Gloss looks like it may only be suitable for bar type graphs, but we'll see. (We may look into writing some other library that's better suited than Gloss, as Gloss is aimed at students learning haskell, and wanting to just get something drawn)

Who: Ivan M, Alex M

2.1.3 GHC LLVM backend

What: The recent work dome by David Terei on an LLVM backend for GHC has shown some fantastic results, and getting it to a point where it could become the default GHC backend is something a lot of people would really like to see.

Who: Alex M, Manuel, Erik

2.1.4 Accelerate

What:Accelerate is a Haskell EDSL for regular array computations. The aim is to make it generate so blindingly fast code that the C folks start to cry. An LLVM backend is in very early stages of development and a CUDA GPU backend is good enough to run some first small Accelerate programs.

Who: Manuel, Alex M

2.1.5 Hubris

What:Hubris is a bridge between Ruby and Haskell. There are two main options - working on Hubris itself (adding instances for more data types, making it easier to install, chasing the 64-bit linking bug...) or actually building something cool with it. Open to either. (Oh, one other idea - using Hubris to export QuickCheck to Ruby directly. RushCheck looks a bit moribund these days...)

Who: Mark

2.1.6 Leksah

What:Leksah is a Haskell IDE written in Haskell. Goal for 1.0 is mainly to fix issues in 0.8 rather than add new features, but it would also be nice to make some more progress on replacing GtkSourceView with Yi. Support for running QuickCheck and HUnit may be something we could slip into 1.0.