[Indigo]<Loops>loopsmoviescript.bravo!12

Edited: MJS May 3, 1983 10:06 AM
File: {indigo}<loops>loopsmoviescript.bravo

Loops Movie Script

The Loops Design Team

Special effects: Title slide white on blue background. Music and increasing crescendo of sound from Knowledge competition in Background.

Knowledge Programming in Loops:
Highlights from an Experimental Course

Mark Stefik

Daniel G. Bobrow

Sanjay Mittal

Special effects: Fade To A white title on a blue background.

Knowledge Systems Area

Xerox Palo Alto Research Center

Sound: Music fades. Crowd noise remains low. Stefik speaks over the crowd noise.

Script for Stefik:

View: Display of game board.

Film Clip: xx-xx-xx to xx-xx-xx Fade to closeup of the gameboard showing a truck going to a stop where it is robbed by Bonnie or Clyde. Remark in crowd about being robbed. Pull back, getting a brief view of full game board on the screen.

This may appear to be a typical a video game.

Actually, something much more unusual is happening.

You are watching a knowledge competition.

What looks like a competition between people is actually a competition between knowledge systems -- knowledge-based computer programs.

View: Crowd shot.

Film Clip: xx-xx-xx to xx-xx-xx Fade to view of crowd gathered around screen. Watch for 5-10 seconds. Sound fade though view remains.

These people have just spent three days taking a course about Loops -- a knowledge programming system.

The final problem in the course was to program a knowledge based player.

Instead of playing the game with a joystick, each team created a computer program -- a sort of independent trucker -- to play the game for them.

They had to write rules to guide their players in the situations that arise in the simulation world.

View: of Stefik in his office. The following slide appears momentarily underneath Stefik.

Mark Stefik
Knowledge Systems Area
Xerox PARC
Loops Logo

Knowledge programming is part of Artificial Intelligence.

It is concerned with the techniques for representing knowledge in computer programs.

Knowledge programming is important in many applications of AI -- where the problems are messy.

Like many things in real life -- pat solutions, or simple mathematical solutions just aren’t good enough.

Things break. Information is missing. Assumptions fail.

To cope with messiness, AI researchers have found that large amounts of problem-specific knowledge are usually needed.

This places a premium on advanced techniques for representing and testing such knowledge in computer programs.

Very few people have been trained to build knowledge systems.

"Training" today usually requires several years of study at one of a handful of universities.

A group of us in the Knowledge Systems Area at Xerox PARC are trying to shorten this training time.

We are developing new tools and methods.

Our goal is to increase the impact and scale of Artificial Intelligence by simplifying methods of Knowledge Programming -- and making those methods more widely accessible.

View: Move to Closeup of Loops Logo. MJS pointing to it with a pointer.

In doing this, we have created a knowledge programming system called Loops.

We use this icon as an aid in explaining Loops.

Loops is a a programming system that integrates several programming paradigms.

(point) The first paradigm is procedure-oriented programming of Interlisp. In this paradigm, big programs are built up from little ones by making subroutines. Data and programs are kept separate. Most computer languages in the world are like this.

(point) The second paradigm is object-oriented programming. In this paradigm, the world is made up of objects -- combining both procedures and data. Objects communicate via by sending messages to each other. Standardized protocols enable different kinds of objects to respond to the same kinds of messages. Big objects are built out of smaller objects.

(point) A third paradigm is data-oriented programming -- used for programs that monitor other programs. You can think of this as a way of connecting probes into the variables of a program. The probes can trigger additional computations when they sense changes in the data. In this paradigm, as in the others, Loops provides appropriate methods of composition.

Loops currently provides one other paradigm -- called rule-oriented programming. This paradigm is specialized for representing decision-making knowledge in the form of rules.

In Loops integrates (point at ring) these paradigms are all integrated -- to be used together in building a complete program.

View: Fade Back to Mark Talking

To test the effectiveness of the our methods for building knowledge systems, we taught an experimental course. In the two versions of the 3-day course that have been run so far, the results have been very encouraging.

Everyone in the course was able to learn enough of the Loops programming environment to formulate the knowledge for their system, and interact with Loops to modify and debug their systems.

The problem setting used in the course is a simulated economic model called Truckin -- brought to life in the video display that you saw.

The knowledge systems built by the students had to plan routes for buying and selling commodities, and avoiding hazards of the simulation world.

At the end of the course, we had a knowledge competition, in which all of the programs competed with each other.

This is the story of the experimental course, told from the viewpoint of one of the participants.

Time 02:10

View: Course participant in hallway outside the Loops class room (AH).

Special Effects: Austin’s name overlays near bottom of screen for a few seconds.

Austin Henderson
Cognitive and Instructional Sciences Area
Xerox PARC

Script for Austin:

In February, I took the Loops course offered by my colleagues. I was curious about how the ideas in Loops would apply to both the art of programming, and to Trillium. Trillium is an internal Xerox project for designers who are not programmers. It helps them to develop interactive interfaces to copiers.

Twenty two people were in my course. Since I am from Xerox, I was a somewhat atypical participant. -- Most of the people came from research laboratories such as SRI International or Lawrence Livermore or Stanford University, or startup AI companies like Applied Expert Systems and Teknowledge.

Also -- I already had experience with the exploratory programming languages Interlisp and Smalltalk, and with knowledge representation languages like Klone. Loops integrates several different programming paradigms -- that is, styles for organizing information. It was being touted as combining the best features of many of the systems that I already knew about. I wanted to see this for myself.

View: Camera follows Austin walking towards the classroom door. Focuses momentarily on the wall sign, and then back to Austin.

The Loops Course

The course was a combination of lectures and exercises using Loops on Xerox computers. The first lecture was about object-oriented programming in Loops.

Time 03:10

Special Effects: Fade to Loops Color Saturn Logo with subtitle as follows:

Lecture 1

Object-oriented Programming

Film Clip: 01-03-24 to 01-04-16. DGB. "Good Morning. please ask questions."

Special Effects: Subtitle appears for a few seconds.

Daniel G. Bobrow

Knowledge Systems Area

Xerox PARC

Film Clip: 01-06-00 to 01-07-31. DGB. Outline of talk.

Film Clip: 01-25-23 to 01-25-59. DGB. Bob Blum question and answer.

Film Clip: 02-17-47 to 02-18-27. MJS. "Pick partners for exercises."

Time 07:00

View: Fade to Austin sitting at a workstation. A course notebook is at hand, open to the pages of the first set of exercises. Interlisp-D manuals are also at hand.

The workstation screen shows the standard set-up for the Loops Demo. Second camera is on the screen (or a slave screen).

Script for Austin.

After the first lecture, we were grouped into teams of 2-3 people to do the exercises on the computer. Our first set of exercises was about the Loops programming environment and object-oriented programming.

The Loops user interface makes extensive use of interactive graphics. One of the standard ways of accessing objects in Loops is to use a browser. A browser is a program that enables a user to "browse" through information in a knowledge base. A particular kind of browser -- a class browser -- shows the inheritance relationships between classes.

View. Fade to second camera on a slave screen. The workstation screen shows the standard set-up for the Loops Demo. Perhaps a split-screen with one camera on the mouse and keyboard and another on the screen.

For example, here is a class browser for a set of everyday commodities. From the lattice drawn in the Browser window, we can see that (point at each item with the cursor using the small hand browser) a Tomato is a Vegetable, and also a FragileCommodity. A Vegetable is a Grocery, and also a PerishableCommodity. Similarly, Apple can be seen to be a Fruit which is also a Grocery.

By pointing at a class in the browser, we can ask Loops to print out more information about a class. For example, (click Apple holding down Leftshift) here is a printout of the class Apple. The information in bold font shows information that is defined locally in the class Apple itself. We see that Apple has Fruit as a super class. This corresponds to the visual display in the browser window. Going back to the printout, we can look at the class variables for the class Apple, the descriptions of the instance variables, and the methods.

Apple also inherits information through the class lattice. The nonbold information about Apple shows variables and methods that are inherited from Apples’s super classes. (point at pieces of information which is inherited). For example, we see that the variable lifeTime must be inherited.

(camera shifts back to browser lattice)

Going back to the browser, we find out where the pieces come from using the WHEREIS option. Here we see that the instance variable lifetime comes from PerishableCommodity, and quantity (qty) comes from Commodity, and price is defined locally. We also see that the methods SetPrice and Display are defined locally in the class Apple itself. The method TransferOwner comes from Commodity, and SetPrice is defined locally.

View: Fade back to Austin sitting at a workstation.

Message sending is a central idea in object-oriented programming. This is the way that objects communicate; it corresponds roughly to procedure call in more traditional languages -- one object causes another object to do something by sending it a message. An important difference from procedure call is that the sender of a message need not know the name of the procedure used by the receiver of the message -- the sender only needs to know a selector for the method. This is a key feature behind the idea of protocols. Two different objects can obey the same set of protocols, that is, carry out the same kinds of operations even though their implementations are completely different. For example, an object for displaying text and an object for displaying pictures may both use a display protocol, but have completely different ways of carrying it out. This makes it possible to define uniform interfaces to different classes of objects.

View: Fade back display at workstation.

In Loops, a $ comes before Loops names. A left arrow is used for sending a message to an object. (start typing (← $Apple New ’App1)) For example, to create an instance of a the class Apple, and name it "App1", we send a New message to the class Apple like this:

(← $Apple New ’App1).

By sending a Display message to App1, (camera moves out to where it can see typing and mouse postion -- which should be on clear area of screen)

(← $App1 Display)

we cause a picture of an apple to appear on the display. (move App1 to position and click down) using the specialized display method of Apples.

To see the variables of App1 send an Inspect message.

(← $App1 Inspect)

This creates an inspector window which shows the instance variables and their values. From this window we can inspect and change these variables directly by selecting them with the mouse. (click mouse Local in title area of inspect window) We have just moved from showing the values for all of the instance variables of App1, including the ones that are inherited to showing only those which are local. The question marks indicate where no values have been set locally yet. (click mouse Local in title area of inspect window) So far, all of the values in the instance App1 are being inherited from the class Apple.

We can set a value in App1 using the syntax

@(app1 price)←90

Then if we redisplay the inspector, we see that new price, and also the indication that it has been set locally in the instance, although the values of the other variables are still being inherited.

The next part of the exercise anticipates the data-oriented paradigm of the afternoon lecture. We were told to create a gauge and attach it to the price of App1. This can be done in a single step as follows (click mouse in demo Menu on Monitoring ...):

(←New $VerticalScale Attach $App1 ’price)

and placing the gauge on the screen. Now if we change the price of $App1, as

(←@ $App1 price 45)

the gauge immediate shows the change on the display. This also works if we use a program -- say a method to change the price -- as in

(← $App1 SetPrice 85)

View. Fade back to Austin at the terminal.

In most programming systems, one would have to incorporate both functions -- price calculation and display updating -- into the same program. In Loops, the active value mechanism separates these functions -- making it possible to attach gauges to variables without changing the programs at all. This makes it easy to "gauge" up a program.

Gauges are an interesting tool for monitoring the behavior of a program. They are much better than trace statements, which disappear as they scroll off a "glass teletype". Loops comes with a collection of gauges, and new ones are being invented all the time. Part of our afternoon exercises was to implement a new kind of gauge.

The rest of the first set of exercises was about facilities for editing and debugging programs. These facilities in Loops make extensive use of the Interlisp-D environment on which Loops stands. An example of this is the integration with the Loops Break Package -- an interactive facility for debugging programs. Loops extends the Break Package to work with objects.

For example, suppose that I am working on a large program, possibly with parts of it written by other people. Suppose also that some unidentified part of the program is clobbering the value of some variable -- such as the price of App1. Using the Loops extension of the Break Package, we can ask the system to Break -- that is, stop -- whenever any program tries to change that variable. Like this: ...

View. Fade back to the display terminal.

I can ask the system to Break when the price of Apple1 is changed as follows

(BreakIt $App1 ’price)

Now if we invoke the SetPrice method as before ...

(← $App1 SetPrice 25)

a Break Window appears on the screen (camera has panned over to midscreen where the break window has come up). This window shows that a program is trying to change the value of the price of Apple1 from 85 to 25. By selecting the BT option, we can get a back trace of the calling stack. Here we see that the PutValue was called from inside Apple.SetPrice. We can look at the calling arguments by selecting the item in the stack like this -- and we can inspect those arguments (which may be objects like apple1) like this.

These debugging features enable us to to find the spot in the program that is attempting to set the price. To resume the computation, we can just select the OK option, and the Break window will go away, the computation will procede, and the gauge on the screen will be updated.

Time 13:00

View: Hallway. Austin near the classroom door.

Script for Austin:

Data-oriented programming was the main subject for the afternoon lecture.

Time 13:20

Special Effects: Fade to Loops Color Saturn Logo with subtitle as follows:

Lecture 2

Data-oriented Programming

Film Clip: 03-00-34 to 03-01-06. DGB. Welcome back.

Special Effects: Subtitle appears for a few seconds.

Daniel G. Bobrow

Knowledge Systems Area

Xerox PARC

Film Clip: 03-03-24 to 03-04-22. Dual of object-oriented pgming.

Film Clip: 03-14-27 to 03-14-50. One mechanism, many applications.

Film Clip: 03-17-04 to 03-18-30. Nesting.

Film Clip: 03-19-26 to 03-19-49. In KRL, ....

Film Clip: 03-27-08 to 03-28-20. Arbitrary msgs.

Film Clip: 03-35-16 to 03-37-23. Gauges.

Film Clip: 04-03-32 to 04-03-47. Thank you.

Time 19:30

View: Camera on Austin seated at workstation, ready to work on exercises.

The next set of exercises was about defining and specializing classes. The examples for these exercises were drawn from the Loops gauges.

The first exercise was to make an accumulating gauge, that is, a gauge that indicates the arithmetic sum of all of the values that have been set so far.

View: Workstation screen.

The course material suggests that we create a class for Accumulator by specializing the class LCD. We begin by creating a class browser for the gauges.

(Browse GAUGESCLASSES)

Using the Browser -- we can use the Specialize option, and type in the name of the new class. Note that the new Accumulator class now appears in the browser window.

View: Zoom in on Browser window for gauges.

We can take a look at the Accumulator class. After selecting the PrintSummary option, we see that Accumulator has several methods. The exercise instructions suggest that we specialize the Set method -- listed here. To look at that method, we can use the EM option to examine the method function from the lisp editor.

We wait for a moment while Lisp fetches the source code from a file server, and now we see that the method for Set takes two arguments -- self, the instance of the accumulator class -- and the new reading. To define a new Set message for Accumulator, we type

DM (Accumulator

-- let’s see, what arguments does DM take? We can use ?= facility to find out. --

DM( Accumulator ?=

-- ah -- we just need to name the selector and arguments. Of course. We’re defining a method for Set. -- so

DM (Accumulator Set (self reading) )

So now we’re in the Interlisp editor again. We should put in a comment ---

(* Method for accumulating readings in order to Set an Accumulator.)

-- And we want to just specialize the code for the LCD by adding the new reading to the existing reading in the Accumulator. We can use SendSuper to activate the inherited code for Set. So all we need to do is to add the new reading. Like this:

(←Super self Set (IPLUS reading @reading]

-- and make sure that the method returns that reading as its value.

Austin deletes the self Lisp variable at the end of the Method.

and we can exit the Editor.

Now let’s build an accumulator, and test it out. First we create an instance of the Accumulator class and save it in the Lisp variable ac1.

(SETQ ac1 (← $Accumulator New))

Then the exercise instructions say to set the scale and tell the Accumulator to Update. Okay --

(← ac1 SetScale 0 100)
(← ac1 Update)

-- Ah -- now the picture of the Accumulator-LCD appears on the screen. So we can send it Set messages. We’ll set it to ten.

(← ac1 Set 10)

We’ll try it again and again.

redo
redo
redo

It’s accumulating! It works!

View: Austin in office.

Script for Austin:

There were several more parts to the exercise -- each part more challenging and requiring more initiative than the previous. The last part of the exercise was about creating new classes by combining existing classes. Several of the gauges that come with Loops are made in this way -- by combining parts of simpler gauges.

View: Workstation display view.

Special effect: WIPE!!!

For example, the DigiMeter is made by combining a Meter with an LCD and the DigiScale is made by combining a HorizontalScale with an LCD. The last problem was to define a DigiDial, by combining a Dial with an LCD. I was surprised. Along with almost everybody else in the class, we were actually able to do this. In most programming languages this would be a very difficult thing to do. Even in object-oriented systems lacking a multiple inheritance capability, this would be hard . In Loops it was easy. Facilities for combining classes are an important part of Loops.

View: Camera focuses on Austin in the hallway.

At this point in the course, we all had had a pretty intensive first day. We had learned a lot about object-oriented programming and data-oriented programming, and had all become acquainted with the user interface in Loops. The last session of the day was to introduce the Truckin game.

We hadn’t heard much about Truckin yet. We all knew that it was part of a scheme to teach us to build a small expert system, but we didn’t really know how that was going to work. This lecture was to be a brief introduction, so we could think about the ideas over night.

Time xx:xx

Special Effects: Fade to Loops Color Saturn Logo with subtitle as follows:

Lecture 3

Introduction to Truckin

Film Clip: 05-02-51 to 05-05-25. Sanjay -- introductory fragments.

Special Effects: Subtitle appears for a few seconds.

Sanjay Mittal

Knowledge Systems Area

Xerox PARC

Time xx:xx

View: Sanjay in front of Truckin printout. Wearing same clothing as on the previously-recorded video tape. Sanjay will be pointing at the game board.

Script for Sanjay.

Teaching about expert systems is usually quite time-consuming. In order to study an example expert system, the first several weeks are usually spent learning the vocabulary and concepts of the domain -- be it medical diagnosis, experiment planning, or whatever.

However, this course on knowledge programming in Loops is only three days long. To give you experience with an expert system, we had to find a problem area that you already know about -- something from common experience.

The domain we picked is about planning a truck route -- buying and selling goods to make a profit. Buying goods and going places is something that we all know something about.

Truckin is a simulation world for this domain. It comes to life as a sort of video game, except that it is not played by people. Behind each truck is a small expert system, that makes the decisions about where to go, and what to buy and sell.

Your job, starting tomorrow afternoon, is to build an automated player. Your player will act as an independent trucker, trying to make a profit in the simulation world

This is a game board for the Truckin game. This is a highway, this is a road stop, this is a truck going down the highway.

Truckin provides an interactive environment in Loops for developing your player. Trucks go back and forth. They take turns running. They buy and sell.

Road stops with the icons are called producers. Trucks can buy goods there. Roadstops with a commodity name -- like groceries -- are consumers. Trucks can sell goods there. Some Roadstops sell gas; some levy taxes -- like the weigh stations, some correspond to rough spots in the road. If a truck goes too fast over a rough road it may damage some fragile cargo.

A pedagogical goal in the design of Truckin is that the simulation is intended to be complex enough to preclude trivial solutions -- such as linear programming solutions. It is meant to be like the kinds of domains in which expert systems are usually applied -- messy real-world problems that need expertise, not just mathematical formulas.

Film Clip: 05-12-48 to 05-13-35. SM: An assortment of trucks.

Film Clip: 05-15-55 to 05-16-58. SM: Bandits, conflicting constraints

Film Clip: 05-17-28 to 05-18-00. SM: Austin question.

Film Clip: 05-19-08 to 05-20-40. SM: Starting with Peddler.

Film Clip: 05-24-17 to 05-24-47. SM: What can you do in a move?

Film Clip: 05-27-09 to 05-28-04. SM: Gauges.

Time xx:xx

View: Display screen showing collection of Loops Gauges all counting down from 5 to 0. Ticking sound in background ala 60 minutes.

Time xx:xx

Special effects: A white title on a blue background.

Knowledge Programming in Loops:

Second Day of the Experimental Course

Time xx:xx

Camera focuses on Austin in the hallway.

Script for Austin.

On the first day, several people worked until late in the evening just to get ahead in the exercises of the course. Others went home to read the manuals. Pretty much everybody had started thinking about Truckin -- proposing strategies that they wanted to build into their expert systems.

The first item on the agenda for the second day was a lecture on rule-oriented programming. I was curious about rules, because although everybody in AI has heard a lot about using rules, rule languages have not been widely accepted or available. I had never built a big program using rules, and I expected to learn something about how to do this. Also, we had been told that rules would be an important part of the mini-expert systems that we would be building for Truckin.

Time 03:10

Special Effects: Fade to Loops Color Saturn Logo with subtitle as follows:

Lecture 4

Rule-oriented Programming

Film Clip: 06-03-28 to 06-05-49. MJS. What’s special about rules.

Special Effects: Subtitle appears for a few seconds.

Mark Stefik

Knowledge Systems Area

Xerox PARC

Film Clip: 06-09-10 to 06-11-54. MJS. Wash Machine, 1-shots.

Film Clip: 06-17-36 to 06-19-09. MJS. Explanation ...

Film Clip: 06-20-37 to 06-21-55. MJS. Austin .. how auditing works.

Film Clip: 06-34-21 to 06-36-00. MJS. Peddler ...

Film Clip: 06-54-02 to 06-55-34. MJS. In the exercises.

Time 07:00

View: Fade to Austin sitting at a workstation. A course notebook is at hand, open to the pages of the first set of exercises. Interlisp-D manuals are also at hand.

The workstation screen shows the standard set-up for Truckin. Second camera is on the screen (or a slave screen).

Set Up. Truckin should be initialized, and the Traveler player should be compiled with auditing turned on except for FindStoppingPlace. Truckin is running, but has been interrupted by a CNTRL-SHIFT break.

Script for Austin.

The next set of exercises emphasized debugging in rules. We started with an existing player called Traveler.

A convenient way to access the rules of a player is through a browser. So ...

(Browse $Player)

Here is the Traveler. By selecting the EM option, we can edit one of the methods -- which happens to be implemented as a Loops RuleSet. Now the rules appear on the screen. We will edit the rules in the Traveler that are used to determine a stoppingPlace -- that is, a RoadStop on the route to a final destination. So here are the rules. The instructions say that we should turn on auditing -- that is, the saving of dependency trail -- so we change the compiler options for auditing.

Compiler Options: A;

One of the first things that we did was to practise using the dependency trail mechanism for debugging. So we can type OK to start Truckin going again, and we see the various trucks running. The gauges at the right hand side have been attached to monitor fuel consumption, and the weight of cargo, and such things.

Pause for 5 seconds or so to let people watch and understand the game in action.

Now my truck is going, and I’ll interrupt it with the Rule Exec by typing a CTRL-F. That new window is the Rule Exec. I can get the value of variable by typing its name. So, for example

re: stoppingPlace

That tells me the next place that my player has decided to stop. To see what rule was behind that decision, I type can ask "why" as follows:

re: why stoppingPlace

and now the text of the rule comes up. If we type OK, to the Rule Exec, the simulation just continues. Another debugging technique is to attach additional gauges to things. So to attach a gauge to my stoppingPlace, I could interrupt Truckin again. (Use CTRL-SHIFT.) For example, we can attach an LCD to the stoppingPlace of my trucker as follows:

(←New $LCD Attach $Austin ’stoppingPlace)

and we can place gauge next to the other ones. Now when we run Truckin some more, we see that the new gauge shows the changes to my trucker’s stoppingPlace as they are computed.

Another technique is stepping through the rules. To do this, we stop Truckin again (Use CTRL-SHIFT) and change the compiler options. We go up to the class browser for Players, and edit the method for FindStoppingPlace. Now we change the compiler options

Compiler Options: BT PR;

Now we type OK to start Truckin again, and ah. Now the my RuleSet has started running. We can see a printout of the rule in the top window. In the Rule Exec, I can now ask any question as before. To go to the next rule, I just type OK. And the next rule appears. This technique can be useful in determining why a particular rule does not fire in a RuleSet.

View: Fade to Austin sitting at a workstation. A course notebook is at hand, open to the pages of the first set of exercises. Interlisp-D manuals are also at hand.

The last part of this exercise was to specialize the Traveler to create a new player, with slightly altered structure and behavior. At the end of this exercise, we knew enough about rules to start expressing our own strategy ideas in a personalized Truckin player.

Next we had a lecture about the Truckin knowledge base and simulation.

Time 03:10

Special Effects: Fade to Loops Color Saturn Logo with subtitle as follows:

Lecture 5

The Truckin Knowledge Base

Film Clip: 07-06-20 to 07-07-35. SM. Truckin RoadMap

Special Effects: Subtitle appears for a few seconds.

Sanjay Mittal

Knowledge Systems Area

Xerox PARC

Film Clip: 07-08-02 to 07-08-28. SM. Cheating ...

Film Clip: 07-13-04 to 07-14-35. SM. Austin on browsers.

Film Clip: 07-08-02 to 07-08-28. SM. Cheating ...

Film Clip: 07-30-27 to 07-31-49. SM. 3 msgs to gameMaster.

Film Clip: 08-00-32 to 08-01-00. SM. One more hint. Crowd leaving.

View: Austin sitting at a workstation. A course notebook is at hand, open to the pages of the first set of exercises. Interlisp-D manuals are also at hand.

The workstation screen shows the standard set-up for Truckin. Second camera is on the screen (or a slave screen).

Script for Austin.

We worked for the rest of the afternoon on our independent truckers. People discussed strategy and even shared rules. Some people worked late into the evening, others came early in the morning. Just before lunch we had a lecture on advanced features.

Special effects: Show sequence of slides from 1st course, of people working on their players, puzzling at their workstations. Maybe with music background.

View: Display screen showing collection of Loops Gauges all counting down from 5 to 0. Ticking sound in background ala 60 minutes.

Special effects: A white title on a blue background.

Knowledge Programming in Loops:

Third Day of the Experimental Course

Special effects: Show more of the sequence of slides from 1st course, of people working on their players, puzzling at their workstations. Maybe with music background.

Time 03:10

Special Effects: Fade to Loops Color Saturn Logo with subtitle as follows:

Lecture 6

Advanced Features

Film Clip: 08-01-13 to 08-01-50. DGB. This lecture has the property ...

Special Effects: Subtitle appears for a few seconds.

Mark Stefik

Knowledge Systems Area

Xerox PARC

Film Clip: 08-02-41 to 08-03-44. MJS. Advanced features means ...

Film Clip: 08-16-41 to 08-17-27 MJS. Composite Objects.

Film Clip: 08-23-52 to 08-24-50 MJS. Perspectives.

Film Clip: 08-27-50 to 08-30-15 MJS. Mixins vs. perspectives.

Film Clip: 08-33-00 to 08-33-31 MJS. Knowledge bases.

View: Austin in lounge area.

Script for Austin.

During an afternoon break, Sanjay Mittal gave us a demo of the Loops tester. We learned that the tester is an expert system, written in Loops, used to certify new releases of Loops.

Special Effects: Fade to Loops Color Saturn Logo with subtitle as follows:

Demo

The Loops Tester

Special Effects: Subtitle appears for a few seconds.

Sanjay Mittal

Knowledge Systems Area

Xerox PARC

View: Sanjay seated at workstation. (Second camera is set-up on computer screen).

Script for Sanjay.

Until last fall, we had no systemmatic way of certifying new releases of Loops. Whenever someone on the Loops development team changed the system, he was responsible for verifying that the code worked before putting it into a new release. However, Loops had grown to about three hundred thousand bytes of source code, and sometimes changes to one part of the system had unexpected interactions with another part of the system.

Last fall I started building an expert system that would automatically, and systemmatically put Loops through its paces. It was an expert system about Loops itself, designed to uncover bugs in new releases. Metaphorically, it harnesses Loops specifications -- that is, a knowledge base about what Loops is supposed to do -- to a tireless computer. Now the Loops development team does not have to depend only on its human resources -- three people -- to spot bugs in a new release of Loops. We could call on the services of an expert system to check things out.

Here is an example of the tester in action:

View: Switch to camera on Workstation display.

In Loops, like any system that is built in layers, the more sophisticated features depend on the correctness of the lower level features. Similarly, the tester must first certify the most primitive features of Loops, and then go on to the higher level features.

On the screen the tester has brought up a browser to show the relationships between the tests in its knowledge base. In contrast with a class browser, the lines in the tester browser show dependencies between subtests. The tests on the right depend on the ones in the left.

The current set of tests covers most of Loops functionality, and all of the low level operations -- such as message sending, value putting and getting for various cases. The tester provides a framework for defining new tests. Using this framework, the tests are entered manually. Let’s take a look at one of the tests in the knowledge base.

If we just want to display a test without making any changes, we select the PP option on the middle-button menu for the selected test. However, by selecting the EditTEST option in the left-button menu, we enter a mode where the tests can be created, edited, including the manipulation of various links between tests.

Now we’re ready to run the tester. If we select the AllTests option in the menu, the tester starts. As a test is started, its name is outlined in the browser and a message appears in the typescript window. When a test completes correctly, it is blackened.

This mode of running the tester steps through the entire knowledge base without user interaction -- unless there is an error. Interactive modes of running specific tests are also available -- for situations where bugs have been discovered.

View: Austin in lounge area.

Script for Austin.

Suddenly it was mid afternoon of the last day and time for the knowledge competition. People were quickly putting the finishing touches on their players -- adding that one last rule, saving their knowledge bases.

Before the competition actually started, people were asked to explain the ideas behind their expert systems.

Special Effects: Fade to Loops Color Saturn Logo with subtitle as follows:

The Knowledge Competition

Note: Tapes 9 & 11 are people shots. Tapes 10 & 12 are Truckin display:

Film Clip: 09-00-53 to 09-01-30. Steve Gadol.

Film Clip: 09-02-27 to 09-03-00. Chris Tong.

Film Clip: 09-04-16 to 09-05-15 Martin Kay.

Film Clip: 09-10-06 to 09-11-50. Lee Erman and Steve Reis.

Film Clip: 09-12-56 to 09-13-02 SM: Here’s the gameboard.

Film Clip: 09-21-39 to 09-22-04 MJS: Do we run a Peddler?

Film Clip: 09-10-06 to 09-11-50. Lee Erman and Steve Reis.

Film Clip: 09-12-56 to 09-13-02 SM: Here’s the gameboard.

****

Film Clip: 10-12-09 to 10-12-52 SM: Here’s the game board!

Film Clip: 10-16-47 to 10-17-08. Gauges for Gadol.

Film Clip: 10-22-56 to 09-23-00 Game starts.

Film Clip: 10-28-42 to 10-29-05 Sell that gold!

****

Film Clip: 09-42-01 to 09-42-22. We’re going back to get gas.

Film Clip: 11-06-37 to 11-06-51. Luey got robbed. Go Tek!

****

Film Clip: 12-02-56 to 12-04-09. SM: To summarize ... tomatoes.

Film Clip: 12-04-50 to 12-05-15. Getting into endgame!

****

Film Clip: 11-08-04 to 11-08-43 Mav broke. last ditch strategy.

Film Clip: 12-10-04 to 12-10-43 Very end.

Film Clip: 11-10-04 to 11-10-28 Let’s hear it for the turtle!

View: Austin in hallway.

Script for Austin.

After the knowledge competition, we gathered for a wrap-up session.

Special Effects: Fade to Loops Color Saturn Logo with subtitle as follows:

Lecture 7

Wrap-Up

Film Clip: 13-02-21 to 13-02-52. DGB. The coin we are paid in ...

Special Effects: Subtitle appears for a few seconds.

Daniel G. Bobrow

Knowledge Systems Area

Xerox PARC

Film Clip: 13-06-59 to 13-07-35 DGB. Outline of topics.

Film Clip: 13-15-00 to 13-15-22 Ideas and feedback.

Film Clip: 13-17-26 to 13-17-34 How do you know when to use ...

Film Clip: 13-21-01 to 13-21-27 Objects.

Film Clip: 13-23-05 to 13-23-35 Rules.

Film Clip: 13-26-50 to 13-28-20 Combination methods for ...

Film Clip: 13-33-57 to 13-34-10 Demons - Erman, MJS, DGB.

Film Clip: 13-50-00 to 13-51-43 Research objectives ...

Film Clip: 13-52-00 to 13-52-37 Thank you very much!

View: A sequence of stills selected from the video tape, with a 3-second pause between each:

Still Shot: Mark doing introduction.

Still Shot: Danny at lecture.

Still Shot: Austin beckoning at workstation.

Still Shot: Sanjay at lecture.

Still Shot: Crowd scene from the knowledge competition.

Special Effect: Starts with a still shot of the Truckin gameboard with a truck about to pull into Alice’s Restaurant. This shot becomes animated as a game truck (labeled Xerox) is shown slowing down to park. Fades to a scene filmed in "registration" of a REAL Xerox truck, pulling into a parking place. The doors open, and Danny and Sanjay start running into a building, with Mark racing along behind. Camera pans upward and it is the REAL Alice’s Restaurant in La Honda! Picture freezes and the following credits overlay on the screen or scroll up from below:

Slide:

Script Engineer: Mark Stefik

Production Engineer:Ken Beckman

Music Engineer: Blue Jeans

Knowledge Engineer: Lynn Conway

Loops Course Engineers:
Mark Stefik, Daniel Bobrow, and Sanjay Mittal

View: White letters on a blue background.

The experimental course "Knowledge Programming in Loops" is offered periodically by the Knowledge Systems Area at Xerox PARC.

The Loops Knowledge Programming System is currently available to selected Xerox customers that have been designated as Loops beta-test sites.

THE END