Marcel Weiher <marcel at system.de> wrote:
> > From: "Lex Spoon" <lex at cc.gatech.edu>
> > In Morphic, they're actually already gone.  That's why you can  
> scroll a text pane
> > and have your BouncingAtomsMorph keep bouncing around while you do  
> it.  Of
> > course, the logic for menus and for text highlighting and things  
> like that, which
> > take a long time to execute, are made more complicated because  
> they have to store
> > intermediate states in instance variables--the extra interactivity  
> is not for
> > free.
> 
> Wouldn't that added complexity go away if an asynchronous  
> message/event delivery model were used so that these tasks could be  
> coded as plain methods that wait for messages to arrive?
> 

If I understand what you mean, they are actually already coded that way: Morphic is based on events, it's just that it normally creates its events by polling the mouse state instead of waiting for OS events to arrive.  Morphs deal with input by implementing methods like mouseDown: and keyStroke:.

The main problem is that when an event happens, a new method has to run from scratch.  Thus event handlers can't just pause in the middle of a loop and wait for the next event, because the loop has to exit before it can get the next event.  Event-based analoguse to control loops end up simulating the loops in the original control loop, but without the convenience of the language-provided looping constructs.

Further problems with the events approach are that the events might come in any order (unlike the case of MVC where you can just ask for only the kinds of input you are currently interested in), and that the outside world might change between two events (wherease in MVC, no code runs except your own, until you exit the loop).

To give a specific example, consider text highlighting code.  In MVC there is a loop something like this:

	[ Sensor redButtonPressed ] whileTrue: [ "...update the highlight..." ]

The Morphic text highlighter, on the other hand, must hook mouseDown: to start highlighting and store the fact that a highlight is in progress, and mouseMove: to extend the highlight.  mouseMove: does the work in the body of the above whileTrue: loop, except that mouseMove: must also check each time it starts up that there is indeed a highlight in progress.  

Furthermore, you have to be careful that the selection-updating code, doesn't interfere with the text-updating code (I just checked, and in fact Morphic isn't as smooth as it could be if you hold down the mouse button doing a highlight and then type a few keys.)

Of course, the event-handling paradigm fits Morphics goals extremely well.  The question is how to deal with its effects?

Maybe continuations would help.  An event handler *could* be allowed to stop at any arbitrary point to wait for another event.  (This could be implemented using suspended Processes).  It would certainly make the event handlers simpler, because they could go back to using regular old loops.  But then, how do you arrange for the suspended handlers to be given the events they need?  And how do you keep from having all these suspended handlers around that might never in fact get woken back up (eg, their window closed)?  

Has anyone here ever worked in such a system?  (And, is Squeak bound to touch on every single OS and programming language issue that has come up in the last 20+ years, as it goes along?  :))



Lex