GUI Library Task Force
Manuel M. T. Chakravarty
Tue, 25 Sep 2001 18:53:07 +1000
"Simon Peyton-Jones" <email@example.com> wrote,
> | * Start from the API of GTK+ as a base line:
> That's fine by me. But can I suggest that the task force be sure
> to read the details of the Clean GUI library design. Peter Aachten
> (while visiting Cambridge) rendered a good chunk of it into Haskell,
> using MVars exactly as you describe. (The type structure became
> a good deal simpler than the Clean library when using MVars instead
> of state-passing.)
> The reason I think its worth a careful look is that the Clean folk have
> developed their library interface over a long period, and have a lot
> of experience in its use. It is not specific to any one platform or
> toolkit, nor does it attempt to implement everything, so its general
> goals fit with the ones you describe.
I have looked at the Clean Object IO. While it is certainly
worthwhile to take from this approach whatever we can, I
have a number of reasons why I am not convinced that the
model itself should be adopted for the Haskell GUI:
* Non-standard extensions: It requires concurrency and
judging by Section 6 rank-2 polymorphism. I am not quite
sure how crucial the later is.
* It integrates facilities for concurrent and distributed
programming (asynchronous communication via channels). I
still think, we can keep the GUI API and concurrency as
two orthogonal features. If you take these features out
and use IORefs instead of MVars, you are already quite
close to the model that we currently aim at.
* I am not a big fan of introducing an extra monad (`GUI' in
this case). It can easily become a pain in programs that
do a lot of "normal" IO as you have to lift all IO
functions to GUI.
* After this, the main difference that remains is the
representation of GUI components as a vanilla data type
instead of opaque handles that do not make the structure
of the components explicit in the types (like the TupLS
does). From the paper, it wasn't clear to me how useful
that is for the application programmer.