"A Language Based Approach to Unifying Events and Threads"

I don't see that anyone has mentioned yet, but I expect a number of GHC users and developers will find this paper very interesting: http://www.cis.upenn.edu/~stevez/papers/LZ06a.pdf

Geoffrey Alan Washburn wrote:
I don't see that anyone has mentioned yet, but I expect a number of GHC users and developers will find this paper very interesting:
Thanks! I've been thinking alot about events/threads etc when trying to design an application framework so this paper looks very helpful. Also great to see an example of how Haskell's abstraction mechanisms are so vastly superior to C etc, where this kind of code would be impossible to write. One little point. I think that the definition of sys_fork in figure 10, page 7, which reads: sys_fork f = M(\c->SYS_FORK (build_trace mx) (c ()) should instead be: sys_fork f = M(\c->SYS_FORK (build_trace (return f)) (c ()) since there is no variable 'mx' in scope as far as I can see. Thanks again, Brian.

Alas---the variable mx should be f, instead of (return f). Thanks for
pointing it out!
Best regards,
Peng
On 4/27/06, Brian Hulley
One little point. I think that the definition of sys_fork in figure 10, page 7, which reads:
sys_fork f = M(\c->SYS_FORK (build_trace mx) (c ())
should instead be:
sys_fork f = M(\c->SYS_FORK (build_trace (return f)) (c ())
since there is no variable 'mx' in scope as far as I can see.
Thanks again, Brian.

On Thu, 2006-04-27 at 16:46 -0400, Geoffrey Alan Washburn wrote:
I don't see that anyone has mentioned yet, but I expect a number of GHC users and developers will find this paper very interesting:
Indeed it is an interesting read. Just the other day a colleague was explaining the CPS monad to me but couldn't think of any practical applications. I shall bear this in mind next time I think about abstractions for programming GUIs in Haskell. Of course at a low level GUIs are event systems and are thus a bit of a pain to code with. So if we can use techniques similar to those in the paper we might be able to get something nicer that allows us to use more sane control flow. One difference between a file/network IO event system and a GUI event system is that with IO you can make blocking calls (within the view of a thread) waiting for one kind of event, while with a GUI one has to be able to respond to many different events in the same context. For example with a server we can pretend we have many conversations with clients and each conversation consists of blocking sends & receives of messages. With a GUI a user may interact with a multitude of different graphical elements and yet we can't sensibly split that up into many threads (as we can with network clients) because they share so much common state. Duncan
participants (4)
-
Brian Hulley
-
Duncan Coutts
-
Geoffrey Alan Washburn
-
Li, Peng