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)