[Haskell-cafe] The future of purely functional user interfaces? (was "Why binding to existing widget toolkits doesn't make any sense")

Haskell desperately needs something like Windows Presentation Foundation or http://www.piccolo2d.org... (so no GUIs but ZUIs :) but then purely functional. I'm pretty sure when a good framework is made, the community would contribute all kinds of widgets. IMO currently no Haskell framework has made it into something of production quality for creating purely functional user interfaces. Some research papers have been written (Fudgets, Gadgets, Fruit, Yampa, Reactive, ...), and some attempts have been made, but I guess nobody has written a large UI application with any of these toolkits (maybe House [1] - on OS written in Haskell that uses an updated Gadgets library - is the exception, but I haven't looked at the details of it yet) Maybe Yampa could be usable for building UIs - but I believe it has scalability issues because it is fully pull based, although it seems work is being done here [2] Reactive should be more scalable, and maybe one day it will be stable enough to build large interactive UIs (maybe together with Fieldtrip), but it seems it will need some redesign [3] Grapefruit also looks promising, as it combines arrows with push based techniques. Other work [4] seems to indicate that arrows are too general for the dataflow programming and co-monads are more suitable and hence might be usable for interactive interfaces. It would be nice to hear opinions about "purely functional user interfaces" and its future. Isn't it a bit of a lost battle if people can't create *real* and complex user interfaces in Haskell without completely switching to an imperative style of programming (GTK2HS, wxHaskell, etc) Cheers, Peter Verswyvelen [1] http://web.cecs.pdx.edu/~kennyg/house/ [2] http://www.citeulike.org/user/msakai/article/3813058 [3] http://conal.net/blog/posts/why-classic-frp-does-not-fit-interactive-behavio... [4] http://lambda-the-ultimate.org/node/988 On Wed, Jan 28, 2009 at 10:01 PM, Achim Schneider wrote:

John Lato wrote:

...

Achim Schneider wrote:

...

So what's left of those TK's if we don't use their abstractions and replace them with Haskell? Drawing and layouting, that's what's left[3]. Both, IMNSHO, do not justify carrying around bloaty external dependencies, they're too trivial. They certainly don't justify using unsafePerformIO to hide foreign side effects and the headaches associated with it.

So, if you don't mind, I'm going to stop trying to fit cubes into round holes and gonna use reactive and fieldtrip[4] to do things.

Does this mean you're volunteering to create a fieldtrip-based toolkit with widgets and layout?

Most likely, no. fieldtrip uses glut, which only supports one os-level window and is therefore borked for a considerable amount of stuff one wants a TK be able to do. It (currently) also doesn't support orthographic projection, which you need to properly position 2d. In the end, it's a small and great library for stuff you don't need for a TK, and is thus quite unsuited as a platform for one. Fieldtrip widgets are another thing, of course.

I'm not volunteering for anything. I'm just hacking away on stuff and following some inspiration I had while I implemented a simplistic widget UI under J2ME, limited to what the game needed.

-- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe