At 14.35 -0700 0-11-14, Alastair Reid wrote:
I tweaked the Hugs sources so that it is always responsive to AppleEvent's: When an AppleEvent is receive a Hugs primitive is called, and one has primitives to send AppleEvent's. The conversion goes over Hugs strings via the AEGizmo's package, plus some extensions I wrote using Flex/Bison. (Some AppleEvent's are hardwired and not sent to the Haskell interpreter, though.)
This is why I want a thread-safe Hugs version, because if Hugs is up and running while receiving an event, it may break.
On the other hand, even though experimental, this variation is the interesting one for everyone wanting to explore the limits of functional programming and events. :-)
The way we've dealt with Windows and X11 events elsewhere is that events are placed ina queue which Haskell code can read out of. For example, in my graphics library, events like mouse movement and key strokes are put into a channel (a threadsafe queue) for the window that receives the queue. One tends to run one thread per window whose job is to deal with incoming events - possibly by forking off another thread to deal with the problem.
The MacOS uses different types of events, low-level events for mouse clicks, GUI etc., and high-level events, called AppleEvent's, for communication between programs. The low-level events are put into a queue by the OS, but I have not made a way for the Haskell code to read them. It might be a good idea though. I figure you build your own queues will allow to store low-level events for a longer period of time (like seconds). Right? For the high-level events, the AppleEvent's, one really want the Haskell code to have a look at them as soon as they arrive. For one thing, they often expire fairly soon, making a later reply impossible.
Of course, we're limited a bit by the fact that Hugs only has cooperative multitasking but that works pretty well since most GUI's only deal with one event at a time anyway - the multi-threading is just a programming convenience. (Note that I'm not saying "all GUI's" - some would definitely benefit from preemptive multitasking.)
If I should do any graphics programming, that should be multi-threaded, under MacOS X, then. I have done some graphics programming under cooperative multitasking, and I think it is too time-consuming, and does not lead to the structures I am interested in. So would still want to see a version of Hugs, or another interpreter which is thread-safe at least in its simplest form, that one can interrupt the current computations, set forth with some other for a while, and then return to the original. Note that this is not even full multi-tasking, because the interrupts are here stacked: One returns to the old computations in the reverse order of the interrupts. -- In true multi-tasking, one should be able to compute and halt the different threads in any order. Hans Aberg * Email: Hans Aberg mailto:haberg@member.ams.org * Home Page: http://www.matematik.su.se/~haberg/ * AMS member listing: http://www.ams.org/cml/