Hugh Perkins wrote:
On 8/8/07, *Brian Hulley* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
In contrast, all the pure functional GUIs that I've seen...
In defense of Haskell (wow!), note that imperative languages are not
without problems in GUIs. In a multithreaded environment,
If you're using multiple threads you'd need to be in the IO monad to
create/manipulate the MVars or TVars or whatever. (In contrast to eg
AliceML where you could easily use a synchronising logic variable
without having to leave all the familiar applicative coding comforts
behind to brave the fiercesome lonely toil of "Monadia" ;-))
typically only one thread is allowed to manage the GUI, and then you
typically need to set up some sort of message-passing system to
communicate between this thread and the others AFAIK? This is a total
PITA, so if someone has a solution for this that would rock :-)
Question: to what extent do the Haskell wrappers around gtk and
wxWidgets suffer from this problem? I mean, I havent tried them, so
it's a genuine question.
I don't know though I seem to recall some info on this on the website of
Gtk2Hs.
(Note: off the top of my head, in an imperative language, I guess one
could use some sort of generator to take an interface and generate the
message classes, and marshalling classes automatically)
(Disclaimer: I havent really searched very hard for ways to handle
threading in GUIs in imperative languages, since mostly I either use
web pages as the visual interface, which avoids around the problem, or
use a single thread, which also avoids the problem)
So far I've always managed to get away with just using a single threaded
GUI. I think you run into problems with XLib and OpenGL (on GNU/Linux at
least) if you try to call into those APIs from multiple threads and also
it seems better to separate concerns by having all rendering code,
including cacheing of geometry etc, in the same thread since it's easy
enough to spawn new threads to do calculations and set a flag in the
relevant widget when the result is complete...
Best regards, Brian.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
