[plt-scheme] streams; event-handling

The key invariant to preserve is that the call to on-event must not
return until the event has been processed. That will make sure that
things don't get out of sync (like closing windows).

I think you should be able to override on-event, create a channel (see
also async-channel.ss) and put pairs of events and new return channels
into the channel. Then, wait on the return channel. Then, some stream
processor outside decides it is done with the event and puts something
into the return channel to indicate that, letting on-event return and
new events go thru the system. 

You might also want to have a look at eXene. It did something similar,
but with more concurrency. I think more concurrency by default is
probably a bad idea, but there are lessons to learn there.

hth. It's just a bunch of unformed ideas, tho.

Robby

At Wed, 12 Apr 2006 13:34:31 -0400 (EDT), Nicholas Chubrich wrote:
> I presume you are talking about cml.ss in the library?  I also found a 
> paper from 2003 on Matthew Flatt's website.
> 	I'd thought of implementing streams myself, but from skimming the 
> paper I gather a naive implementation would possibly break when the window 
> is closed, because the stream processing (or the dequeue) might be behind 
> what is actually happening.
> 	On the other hand, I don't see why you couldn't have a streams
> system that works exactly like on-event: every object that has an on-event
> method has an event stream, and everything that happens between one (cdr
> stream) and the next (cdr stream) somehow becomes the body of on-event.  
> But I can't quite think how to implement that.  A macro of some sort,
> maybe?
> 
> On Tue, 11 Apr 2006, Robby Findler wrote:
> 
> > The closest you'd come to that is CML (or cmz), I believe. I'm not sure
> > if there is any PLT-specific tutorial introduction to that or if you'd
> > have to dig thru the manuals and John Reppy's writings.
> > 
> > (It does use threads, but I don't consider them overkill.)
> > 
> > Robby
> > 
> > At Tue, 11 Apr 2006 22:55:03 -0400 (EDT), Nicholas Chubrich wrote:
> > > I've recently been playing with the drawing canvas as a way of getting
> > > aquainted with MrEd.  My canvas class draws freehand lines when the
> > > left-mouse button is down, and a straight line between two right-clicks.  
> > > What bothers me is that the basic control structure is set.  There is a
> > > single function on-event that simply runs at the next event, so I have to
> > > set a flag in the canvas object to record state; I also have to record
> > > previous points, and in a different way depending on what state I am in.  
> > > It brings back bad memories of C programming.  My natural instinct is to
> > > use an "event stream"; something like this (with a bit of fantasy syntax):
> > > 
> > > (define (dispatch stream)
> > >   (cond ((send (car stream) button-down? 'left)
> > >          (draw-free (send (car stream) get-point) (cdr stream)))
> > >         ((send (car stream) button-down? 'right)
> > >          (draw-straight (send (car stream) get-point) (cdr stream)))
> > >         (else (dispatch (cdr stream)))))
> > > 
> > > (define (draw-straight point stream)
> > >   (cond ((send (car stream) button-down? 'right)
> > >          (line point (send (car stream) get-point)))
> > >         ((or (send (car stream) moving?) (send (car stream) button-up? 'right))
> > >          (draw-straight point (cdr stream)))
> > >         (else (dispatch stream))))
> > > 
> > > draw-free would be defined similarly; the key difference is that the
> > > recursive call passes (send (car stream) get-point) instead of just point.
> > > 	What is the 'PLT way' of structuring an event-driven program in 
> > > this spirit?  Is there any way to do it without overkill (threads, for 
> > > instance)?  Am I better off just using state changes?  Or am I completely  
> > > missing something? 
> > > 
> > > ---Nick Chubrich.
> > > _________________________________________________
> > >   For list-related administrative tasks:
> > >   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> > 
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme