Olaf Chitil <olaf@cs.york.ac.uk> wrote,
Here a short summary by Malcolm and me of the final discussion at the Haskell workshop:
I also took a couple of notes which I like to add.
John Launchbury and many further people made a plea that the single biggest hindrance to the further spread of Haskell is the lack of a standard cross-platform GUI. Alas, no answer to the problem was found. There is no agreement which (existing) library could be the basis of a standard one and nobody wanted to commit himself to developing and supporting such a library. Well, Manuel Chakravarty promised to continue developing the GTK+ binding and would be happy about people helping him. (The GUI library presented at the workshop is not intended to solve the standard GUI problem.)
In fact, the recent release of binary packages for Gtk+HS and an example applications that demonstrates how to use the GTK+ API in Haskell have been a reaction to the discussions at HW & ICFP. Let me reiterate: Gtk+HS as it is today is sufficient for applications requiring a GUI of medium complexity. As far as I see, despite not covering all of GTK+ yet, Gtk+HS already has a wider variety of widgets and functionality than Tcl/Tk provides in its whole API. So, at least on Unix, the statement that there is no GUI for Haskell is just not valid anymore. For Win32, somebody would have to set up the binding for use with the Win32 port of GTK+. I am happy to include any patches coming out of this into the main distribution. You can see how programs coded against the GTK+ API in Haskell look like at the following example: http://www.cse.unsw.edu.au/~chak/haskell/gtk/BoolEd.html (As for Unix/Win32 portability of GUI code, that's not great for C or C++ either.)
Rather than starting work on a successor to Haskell, people generally want to see `blessed addendums' to the Report, for common agreed extensions, e.g. FFI, exceptions, concurrency, MPTC, fundeps, etc. The FFI addendum is almost ready, but any others need volunteers, not to mention agreement between designers and implementations. The idea is that a solid reference definition/documentation of each extension should exist independent of any particular compiler (but there is a lack of volunteers).
It was noted that the future job of designing Haskell-2 will be made much easier by many small steps rather than one large effort.
Generally, as last year, there seemed to be not much interest to look into Haskell 2. Meanwhile, addenda to H98 seem to be a feasible alternative. In fact, one aim with the FFI Addendum was to create a precedent that can be repeated for other extensions. The nature of an addendum brings with it that the extension should be rather non-invasive. For example, in the case of the FFI, one new keyword (`foreign') is added, taking it from the pool of available variable identifiers. The rest of the functionality should not invalidate any existing H98 programs. As a consequence, the kind of extensions that can be realised in this way are limited. For example, extensions of the type system are much more likely to have a severe effect on existing H98 programs. So, they will be less easy to add in this form. It was also pointed out that we should go for an addendum only where - the design is clear and tested (example implementations exist and have been used in applications) and - where there is considerable demand. The first point is surely self-explanatory. As for the second, defining an addendum is a lot of work, which can be used better otherwise unless the extension is really important. Possible further addenda (in addition to the FFI), which have been mentioned, are the following: - The core library (in fact, there is already exists a task force to look into this extension) - Concurrency support (there just are applications that are virtually impossible to implement well without concurrency) - Exceptions (again a really elementary feature of modern languages) - Graphics library (obviously there is a lot of demand, but it is also a rather involved task) In my opinion, all the above functionality falls into the catergory embarrassing not to have. The lack therefore, in fact, promotes the image of Haskell being an academic toy language. The only exception is to a degree the graphics library (again my opinion, which obviouly is not shared by everybody, most notably John Launchbury). My reason is that, while access to GUI toolkits is a must, few languages standardise them. Type extensions (multi-parameter type classes, existential types, rank-2 polymorphism, etc.) have been mentioned, but it seemed that there isn't really a consus as to how they should exactly be implemented and whether they are really so urgently needed. Moreover, they tend to be more invasive. Personally, I would believe that multi-parameter type classes may maybe be the most likely candidate for an addendum. There was the feeling that there is not frequent enough feedback from the "Task Forces" (eg, FFI Task Force, Library Task Force) to the Haskell community as a whole. Clause Reinke kindly volunteered to collect status reports of Task Forces on a 6-monthly basis and post them to the Haskell mailing list. Claus, maybe you should give the Task Forces an idea of when you expect the first status report.
Manuel Chakravarty: A standard Foreign Function Interface for Haskell98 Basically finished (general part and C, not for Java). Solicits last comments from the general community.
The plan is to have one last round of edits on the FFI list, and, then post the draft on the main Haskell list. (Should happen soon, but I am still trying to recover from jet lag and a huge pile of emails and todos that waited for me upon return from ICFP). Cheers, Manuel