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" <firstname.lastname@example.org> 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.
> Haskell mailing list