Feb2001 hugs98 on MacOS

[Hans Aberg]

At 15:35 -0700 2001/02/28, Alastair Reid wrote:
>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.

Right. This is the way to do it. As for the AppleEvent's, it is simpler
still, because they are not completely asynchronous (asynchronously
independent threads), but stacked:

First, let's define what an AppleEvent is. It is a high level event, that
is, binary structures that programs use to communicate with each other.
(They are iterated typed binary structures, like that can be produced by a
C++ polymorphic hierarchy, except that they are largely passive, that is,
do not contain function pointers.)

If a program should be able receive an AppleEvent, it must make up its mind
which ones. So at startup-time, one registers which ones. When a registered
AppleEvent arrive, the OS looks up which registered function pointer to
call. This selected function pointer may or may not engage the Hugs kernel
when executed. So there are some standard AppleEvent's which do not engage
the Hugs kernel at all, as they are intercepted.

Now, the way I hooked it up, not handled AppleEvent's are translated into a
string. Hugs then looks for a primitive in a module Event. If the module is
not present, then the Hugs kernel is not engaged. (Thus, only those that
load this module Event may experience any problems with asynchronizity.)

If, on the other hand, the module Event is loaded, the suitable primitive
is activated. -- There are in fact two primitives, depending whether a
reply is expected or not (which gives rise to different Haskell typing).

Now, when the primitive is executed, it will, if no global data is used,
merely use some additional stack space, and after termination, the stack
will be restored to what it was before.

The only trick needed is to make sure execution does not start at an
unfortunate moment (middle of a stack maintenance function or something).

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

So there is some tweaking needed. The reason I did not do it, is that I am
not at all at home with the Hugs kernel and its workings. I was hoping
someone familiar with the Hugs kernel would do it in the future.

But it seems that with a little tweaking, one could produce something
reasonably safe.

-- In addition, I can remark that AppleEvent's are said to unique to the
MacOS, and some say that in some industries, like graphics, the use of
AppleEvent's has made the platform a preferred one.

The connection with Haskell is roughly this:

Functional languages translate code into "functional covers", that can
later execute. I built such a functional cover which understands lambda
calculus using a C++ polymorphic hierarchy. The AppleEvent's are similar to
such a hierarchy, except that they are passive data.

But this gives me the hunch that there ought to be a closer relation
between Haskell and AppleEvent's.

-- I do not, however, have the time, to explore this in detail myself.
(AppleEvent's are quite complicated. Each program can have its own
dictionary, and so there might be different ways to express the same thing,
depending which program should receive the event.)

But I think it is might be an interesting computing topic.

  Hans Aberg