Feb2001 hugs98 on MacOS

[Alastair Reid]

> - 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