The future of Haskell discussion

[Manuel M. T. Chakravarty]

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