- AppleEvent handling on the Haskell level (i.e., Events.hs et. al.) could preferably be provided by Hans and Pablo as a standalone library that's only implemented on the Mac (just like the Win32 Graphics lib, although it has been ported to X-windows as well). However, I must strongly suggest that whoever undertakes this task will take the time to ensure proper integration with the Hugs' sequential execution machine. I think Alastair Reid can be a good source of information on how this is achieved.
One way of handling events would be to replace the Hugs evaluator with one that supports preemptive concurrency. This would be a fairly major undertaking and is perhaps best based on the STG-Hugs base. Since I'm not aware of any effort to do this and because it's not exactly a Sunday afternoon project, I'll ignore it in the following. In the absence of preemptive threads, the standard ways of handling events for X11 and Win32 are either: 1) Use an event queue to store events which have been delivered to the application. The application should be written so that it regularily processes events waiting in the queue. This can be done either using the usual inside-out event-loop structure found in most X and Windows apps or, if you use Hugs' cooperative threading can be given a more normal structure (as in the Hugs Graphics Library). This approach was popular in the early days (1993 or thereabouts) before ccall, greencard, the ffi, etc. made it easy to use the second option. The big problem with this approach is that you can't handle "synchronous events" which require an immediate response. For example, Win32 has a number of events for querying the application - things like asking for a preferred window size. OTOH, it works great with X11 which is based on an asynchronous event model. 2) Events cause direct calls into Haskell code. (It's pretty easy to do this nowadays using the foreign export dynamic feature of the ffi.) The only trick here is that, because Hugs doesn't support preemption, events must only be delivered at certain safe points. For example, the program might contain a main loop which queries for events, dispatches a call into Haskell code to handle the event and then returns the result of the event handler to the C world. Or, if events appear as asynchronous calls into a C thread, the Haskell program might run with events disabled in most of the code and only enable them by calling into a C function which enables events, waits for the program to complete (during which time it is handling events, of course), and then disables events again. Again, the library programmer has the choice of exposing this programming model to the user or of constructing a layer which hides the event dispatch mechanism from the programmer (as in the Hugs Graphics Library). This is the approach taken in the Win32 version of the Hugs graphics library, in my Budgets paper (an Openlook-based implementation of Fudgets) and in most other GUI's that I know of. I'm yet to hear of a reason why AppleEvents cannot be dealt with using one of these approaches (i.e., without requiring substantial internal changes to Hugs). -- Alastair Reid