GUI Library Task Force

[S. Alexander Jacobson]

Given that Haskell98 is not ready for libraries anyway, why are you so
concerned about it?  A GUI system without concurrency is still incomplete.
The haskell library interface story is still pretty weak because there is
no consensus about what monad they should expose (and whether they should
really expose arrows or something else).   Why not focus on rolling from
H98 into a production quality Haskell system and make the best GUI for
that system?

-Alex-

On Tue, 25 Sep 2001, Manuel M. T. 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.
>
> * 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.
>
> Cheers,
> Manuel
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>

___________________________________________________________________
S. Alexander Jacobson                   Shop.Com
1-646-638-2300 voice                    The Easiest Way To Shop (sm)