11.07.2015 Views

Untitled - TRS-80 Color Computer Archive

Untitled - TRS-80 Color Computer Archive

Untitled - TRS-80 Color Computer Archive

SHOW MORE
SHOW LESS
  • No tags were found...

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

<strong>Computer</strong>s and SocietyDavid D. Thornburg, Associate EditorDemons And Events, Part 1The feature of the Macintosh thathas attracted the most attention isits user interface—menus, mice,windows, dialog boxes, and all theother distinguishing features of thiscomputer have now taken theirplace in the lexicon of most computer users.Features that were introducedto the public on the Macintosh havenow appeared on numerous othercomputers as well. One can hardlywalk past a display of Atari, Commodore, Apple II, or IBM computers without seeing some aspects ofa highly visual user interface.Apple's commitment to this interface is so complete that the AppleIlGS contains ToolBox routines tofacilitate the creation of Mac-likeprograms.But just as the Macintosh looks"different" from the user's perspective, it also looks different from theprogrammer's perspective. Programming for computers like theMacintosh is very different fromprogramming for other computers.If the user interface of this computer is changing the way we usecomputers, it may well change howwe program them as well.ComputationalMetaphorsEvery programming language supports a computational metaphor.For example, LISP programs aresets of functions to be evaluated,PROLOG programs are sets oftheorems to be proved, Pascal programs are sets of commands to becarried out, and so on. The reasonwe have so many different kinds ofprogramming languages is becausedifferent programming tasks arebetter expressed in one metaphorthananother.But metaphoric differencesaside, programs in most languagesconsist of strings of text containingsequences of instructions to be carried out by the computer. In manylanguages the order of program execution is the same as the order of theinstructions in the program. Whenthe user wants to change the order(by calling a subroutine, for example) a special branching instruction is explicitly invoked to causethe program to jump from one set ofinstructions to another set.Event-Driven ProgramsThere is another model of programconstruction that works differently:It breaks a program into two parts.The first part is a traditional program that is executed unconditionally. The program also includes thedefinition of other parts of the program (collected subroutines) thatare executed whenever certaineventsoccur.In other words, if you wantedto have a subroutine executedwhenever a joystick button washeld down, you would include aline somewhere in your programindicating that, whenever the button is pressed, the program is tostop whatever it is doing at thattime and execute another routineinstead. This command lets the program know that, in addition to itsother tasks, it is to check for a "button" event. Let's pretend that, lateron, the program starts to draw acomplex picture on the screen.While it is drawing this picture, youdecide to press the joystick button.As soon as you do, the programautomatically detects this "event"(without being "told" to by a special instruction) and execution isautomatically transferred to a subroutine. Once this routine is finished, control is returned to theoriginal picture-drawing task.This is the programming modelthat is used in creating programs forthe Macintosh, although I first encountered it with Atari Logo.Atari Logo (for the Atari <strong>80</strong>0and 400 computers) has a specialfeature called a WHEN demon. AWHEN demon is a special objectthat continuously monitors thecomputer, looking for any of 21special events to occur. Wheneverone of these events takes place, thedemon associated with the eventexecutes its own set of Logo instructions, no matter what other instructions or procedures are being usedat the time. When these demon instructions are finished and theWHEN condition is no longer satisfied, Logo goes back to doing whatever it was doing before the WHENdemon was activated.Demon programs can bethought of as sets of code that arejust lying asleep in the computerwaiting for a certain condition tobecome true. Whenever the condition is satisfied, the appropriateroutine wakes up, does its task, andthen goes to sleep again. Each demon procedure is independent ofthe others and is executed onlywhen its chosen condition or eventoccurs.Notice how different this isfrom our traditional method of programming. Normally, if we wantedto test for a certain number ofevents, we would write a programthat spent the bulk of its time in aloop checking for each event on acase-by-case basis.'Next month we'll explore thistopic some more by taking apart aMacintosh program—"peering under the hood," so to speak—to seejust what it is that makes programsfor this computer appear to be soresponsive to the whims of theuser.Dr. Thornburg's most recent productis Calliope, a nonlinear idea processor for the Apple lie, c,GS, Macintosh, and MS-DOS computers. Hewelcomes letters from readers and canbe reached in care of this magazine.®February 1987 COMPUTEI 79

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!