[Haskell-cafe] Language support for imperative code. Was: Re: monad subexpressions

Brian Hulley brianh at metamilk.com
Wed Aug 8 14:14:34 EDT 2007


Hugh Perkins wrote:
> On 8/8/07, *Brian Hulley* <brianh at metamilk.com 
> <mailto:brianh at metamilk.com>> 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.


More information about the Haskell-Cafe mailing list