RFC: GUI Library Task Force

[Manuel M. T. Chakravarty]

The following is a summary of a discussion about a strategy
to develop a standard GUI library for Haskell.  The
discussion was initiated by Simon Peyton Jones and involved
Koen Claessen, George Russell, and me.

The next step in our plan is the creation of a public
mailing list (we propose, "gui@haskell.org") that can be
used to develop an API definition according to the outlined
strategy.  Anybody who is interested in participating in
this discussion is very welcome to join this mailing list,
once it is set up.

I expect that there will be feedback here on the main list
to the appended proposal.  As soon as this becomes
technical, I propose to take it off the main list to the new
GUI mailing list.

Cheers,
Manuel

-=-

 *** The GUI Library Task Force Strategy Proposal ***

Goals
~~~~~
* Development of a GUI library API for Haskell that is
  portable across Haskell systems and operating/windowing
  systems

* The library focuses on graphical *user interfaces* (ie,
  buttons, menus, scrollbars, selection lists, etc) as
  opposed to drawing and animation routines.

* Verification of the design by at least one implementation
  of a library that exports the GUI API

* Minimal use of features that are not included in Haskell
  98 (in fact, we currently believe that we can keep the API
  completely free of any non-H98 features; however,
  application programs that use the API will need some
  non-H98 functionality)

* While we do not require support of concurrency by Haskell
  systems implementing the API, the use and behaviour of the
  API must be well-defined on systems that do support
  concurrency

* Core library:
  - Due to the complexity of modern GUIs, we cannot hope to
    cover a fully-fledged GUI library in reasonable time and
    with reasonably effort; thus, we concentrate on a core
    library (what exactly constitutes the core remains to be
    defined)
  - The core library needs to provide a migration path to at
    least one fully-fledged GUI library

* Openness for tools support; for example, it should be
  possible to support graphical interface builders (such
  tools are not part of the API, but we need to ensure that
  we do not seriously complicate the construction of such
  tools)


Non-goals
~~~~~~~~~
* We will not design a fully-fledged GUI library from
  scratch: Just as a reference point, GTK+ has 93 different
  widgets (and that's just the base set) and probably over
  1000 functions.  Moreover, there are surely 100-200
  different types of callbacks.  I am pretty sure that Qt,
  the Win32 GUI API, and the MacOS are of similar size.

  This is well beyond the scope of what we can achieve with
  our resources.

* We will not design a "purely functional GUI":
  - The pragmatic reason: H98 textual I/O works via the IO
    monad; so what's the problem with having graphical I/O
    in the IO monad?
  - The state-of-the-art reason: There doesn't seem to be a
    clear favourite in the proposals for purely functional
    GUIs.  Moreover, it has yet to be shown that any of the
    proposals scales to real-life GUI applications.

  We do not intend to solve sophisticated research problems
  here.  We want to get a workable solution quickly.  Always
  remember: Worse is Better 
  <http://www.jwz.org/doc/worse-is-better.html>.


The Plan
~~~~~~~~
* Handling of state altered by both the application and by
  GUI widgets:
  - The GUI API will be kept free of any commitment as to
    which mechanism to use here.
  - The simplest solution, for a single-threaded application,
    is to use `IORef's and, for a multi-threaded application,
    is to use `MVar's (or primitives that are defined in
    terms of these).
  - Advantages of this design:
    + Doesn't require Haskell systems that want to provide
      the GUI library to also support concurrency
    + Doesn't preclude the use concurrency (where it is
      available)
    + `IORef's are very easy to implement if any system
      doesn't have them yet
    + More sophisticated approaches (that often require
      language extensions or are still experimental) can be
      implemented on top of this basic API - eg, FranTk,
      Yahu, Fruit, iHaskell, etc.
  - It is possible to write reasonably nice Haskell programs
    in this approach; for an example, see

      http://www.cse.unsw.edu.au/~chak/haskell/gtk/BoolEd.html

    (Note how many of the functions need to be in the IO
    monad anyway, because they need to perform file I/O.)

* Start from the API of GTK+ as a base line:
  - This is an API that has a proven track record of being
    suitable for small, medium, and large-scale applications
  - The API does not overly rely on object-oriented language
    features
  - A large body of free documentation exists for the API,
    which can be adapted to our purpose
  - A working Haskell binding exists that can be extended to
    provide a first implementation of the Haskell GUI API
  - A clear migration path exists for applications that need
    more sophisticated features than the core API provided
    by the Haskell GUI
  - GTK+ itself is already reasonably platform independent

* Ensure platform independence:
  - The Haskell GUI will be restricted to GTK+ features that
    can be implemented on other major platforms with
    reasonable effort

* Haskell-ise the API:
  - C-ish functionality will be cut out
  - Full use will be made of Haskell's type system and, in
    particular, type classes

* Convenience libraries
- The API will include a set of convenience libraries on top
  of the basic API (eg, by providing layout combinators)