Hugs and Mac and GUI

[Hans Aberg]

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