RFC: GUI Library Task Force
Mon, 24 Sep 2001 17:08:34 -0700
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.
Of course there are differences:
>* Development of a GUI library API for Haskell that is
> portable across Haskell systems and operating/windowing
>* 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
I will be using Java's threading. This means the Haskell system needs to
>* 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
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
>* We will not design a fully-fledged GUI library from
Hopefully, I will be simply picking up a fully-fledged GUI library.
>* We will not design a "purely functional GUI":
>* 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
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.
> - 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:
>* 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)
A straightforward addition, but not part of my core effort.
Ashley Yakeley, Seattle WA