At 2001-09-24 05:44, Manuel M. T. Chakravarty wrote:

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

It's worth pointing out that I'm covering much of the same ground with my bridge to the Java VM. http://sourceforge.net/projects/jvm-bridge/ Of course there are differences:

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

Same.

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

Java has APIs for both, I believe.

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

This has already been done for the Java APIs.

* 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)

I admit I am using some non-H98 features... in fact right now I'm working solely with GHC.

* 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

I will be using Java's threading. This means the Haskell system needs to 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)

Inasmuch as the AWT/JFC/Swing counts as 'fully-fledged', I will have it.

* 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)

Same.

Non-goals ~~~~~~~~~ * We will not design a fully-fledged GUI library from scratch:

Hopefully, I will be simply picking up a fully-fledged GUI library.

* We will not design a "purely functional GUI":

Same.

The Plan ~~~~~~~~ * Handling of state altered by both the application and by GUI widgets:

I'm not sure what the issue is here.

* 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

Same for Java. I think.

- The API does not overly rely on object-oriented language features

This is the biggest sticking point for Java. The JVM-Bridge will allow you to create and load Java classes at run-time, even then, this may turn out to be complicated for the user.

- A large body of free documentation exists for the API, which can be adapted to our purpose

Same for Java. http://web2.java.sun.com/docs/books/tutorial/

- A working Haskell binding exists that can be extended to provide a first implementation of the Haskell GUI API

I don't have anything usable yet. The JVM-Bridge will have to be code-complete before it is usable.

- GTK+ itself is already reasonably platform independent

Same or better for Java.

* Ensure platform independence:

Same.

* 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

Same.

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

A straightforward addition, but not part of my core effort. -- Ashley Yakeley, Seattle WA