The future of Haskell discussion

S. Alexander Jacobson
Fri, 14 Sep 2001 18:44:16 -0400 (Eastern Daylight Time)

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?


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" <> 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