The future of Haskell discussion

[S. Alexander Jacobson]

If the GUI is based on the IO monad, then it doesn't seem like there is
a lot of advantage  to doing it in Haskell.  It seems like a better
idea to use a more natural language for IO and make RPC/interproc calls
to a haskell server to get stuff done.

In other words, what is the value of the GTK+ haskell interface?
Shouldn't more effort be put into getting Fruit production quality and/or
figuring out how to use arrows to manage textual and network IO?

-Alex-

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



On Fri, 14 Sep 2001, Manuel M. T. Chakravarty wrote:

> "S. Alexander Jacobson" <alex@shop.com> wrote,
>
> > Out of curiosity, how does GTK+ compare with Fruit?
>
> GTK+ has a C API heavily based on call backs and mutable
> state.  Thus, the Haskell transcription of that API heavily
> relies on the use of the IO monad - as does H98 textual IO.
>
> > It seems like it would make sense for the standard Haskell GUI also to be
> > functional.
>
> A functional GUI would be nice, but standard Haskell text
> and file I/O is not functional either.  Functional GUIs like
> Fruit are from a research perspective very interesting, but
> their design is rather far from being a solved problem,
> which makes them a not very likely candidate for a standard
> that people seem to like to have sooner rather than later.
>
> Cheers,
> Manuel
>
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>