GUI Library Task Force

[Peter Achten]

At 18:53 25-9-01 +1000, Manuel Chakravarty wrote:

>"Simon Peyton-Jones" <simonpj@microsoft.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.

This is not what it says in the paper. Clean doesn't have concurrency and 
rank-2 polymorphism. In the paper we explicitly state that we wanted to 
play with GHC features, but none of these are necessary to implement Object 
I/O in Haskell. The only exception to the rule are existential types. In 
this sense I agree with Alexander Jacobson, who wrote:

>I was opposing constraining it to H98 as it exists today rather than
>what we can reasonably expect it to be fairly shortly.
>
>To restate: If the GUI effort can get done either more quickly, more
>elegantly, or with a nicer API, using some features that we all expect
>Haskell to have very shortly (as addenda), it should use them.
>(Especially if the timeline for completion of the GUI basically matches
>the timeline for these features to be added to Haskell.)

Even existential types are not really needed. Existential types, in the way 
they are used in the Object I/O library, can be completely implemented via 
functions. Clean Object I/O also existed before we had existential types... 
. However, existential types are infinitely more elegant and easy and 
readable and efficient (etc...) to use than this programming technique.

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

As said, you don't need concurrency.


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

This occurs only on the outermost level. I am always in favor of better 
solutions. Simon and I have looked if we could use an 'automatic' approach 
using functional dependencies, but then this would use another extension.

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

You are right. This was not the point of this particular paper. More about 
this matter appeared in:

------------
Achten, P. and Plasmeijer, R. Interactive Functional Objects in Clean. In 
Clack, C., Hammond, K., Davie, T. eds. Proceedings of the 9th International 
Workshop Implementation of Functional Languages, IFL'97, St.Andrews, 
Scotland, UK, September 1997, Selected papers, LNCS 1467, Springer, pp. 
304-321.
------------


Regards,
Peter Achten