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