[plt-scheme] MrEd and continuations

At Thu, 18 Jan 2007 12:19:26 -0500, "Henk Boom" wrote:
> A more usual behaviour would be something
> which provides the player with a sequence of levels, or sets up a
> menu, waits for input (done by returning right away except when it's
> time to do something), then shows a new menu. This could also be
> extended to providing AI for individual units on the playing field, as
> their behaviours could then be implemented in a linear fashion instead
> of manually managing a complicated state machine.

I suggest using threads and events (in the sense of `sync' and
Concurremt ML) rather than continuations and callbacks...

> In any case, a problem arises when I actually try and use this code.
> It seems that MrEd sets up a continuation barrier around its callbacks
> (I'm curious as to the reasons for this),

In general, MrEd cannot handle multiple returns from a callback. For
example, there's an `on-demand' callback on menu items that is called
when the user clicks on a menu; the continuation handles the menu
click, and MrEd would get confused if the `on-demand' callback returned
when the user isn't actually clicking on a menu. MrEd would be
similarly confused if the callback returned zero times, since MrEd
would never properly handle the click in progress.

By "get confused", I mean that MrEd would crash. We could implement
MrEd so that it's always ok for any callback to return zero or multiple
times, but it's more work.

> so the continuation I make
> one update can no longer be called in the next update. What should I
> do about this? Should I be looking for a different way to implement
> this?

I suggest putting the linear part in a thread that is separate from the
GUI event thread, and then communicate with it by events. Each callback
can send a message on some channel, and each linear part syncs on the
events that its interested in at each step in its work.

I haven't tried this myself for a program of any scale, and I have my
doubts that it's the right model for *all* GUI event handling (as in
eXene). But I think it's probably a good way to write many GUIs, and we
have Concurrent ML-style synchronization primitives to make the
implementation convenient.

Matthew