CS 451 Programming Paradigms
LISP Assignment Three: CLOS Simulation

Object-Oriented Simulation

Your third assignment deals with creating object environments using a LISP interpreter. It has three parts. The first part you should do alone. The second and third parts you should do in groups of two.

Part A

We discussed in class the use of the closure over a lambda-expression to create instances of objects. We discussed a meta-interpreter for accessing a world of objects created in this way. You are given the following function which uses a closure over a lambda expression to create an object.


(defun make-fixed-object (position)
	(let ((x (car position)) (y (cadr position)))
		#'(lambda (msg)
			(cond
				((equal msg 'get-x) #'(lambda (self) x))
				((equal msg 'get-y) #'(lambda (self) y))
				(t nil)))))

Write a function make-moving-object which returns an instance of an object that inherits from make-fixed-object. It should take two arguments. The first is a position to be used in creating the make- fixed-object from which this one inherits. The second is a velocity which, like position, is a two-element list containing x and y components. There should be two "instance variables" for these, as well as one of for the instance of fixed-object to which inherited behavior will be delegated. There should at least be accessor methods for the two instance variables. Remember to include the mechanism for delegating behavior to the parent object. Each INDIVIDUAL should turn this in ON PAPER in class.

Part B

You should write a simulation using CLOS. You should have at least three different kinds of objects in the system you simulate and there should be inheritance. You should write an interface for your simulation (a set of simple functions for generating objects and their behavior in your simulation). If you are unsure of whether the system you wish to simulate meets the requirements, see George or Joseph right away. Among the many things you can do to go beyond the base 'B' level work is the output of commands to be used by a future GUI written in Java.

Some simulation ideas that are good:


--a bank queue simulation to determine the average wait of 
	a customer--# people coming in per minute, # queues, # tellers,
  # people served per minute by tellers are all parameters
  (or have random behavior constrained by parameters)

--some kind of competitive object simulation such as a field 
	with rabbits, grass, and wolves with various consumption rates
  (and possibly survival strategies) accompanied by some 
  indication of the population as time goes by

--a competitive system simulation, like the heater simulation
	in George's book--it can be of plants vs. animals in a closed-
  oxygen environment, dryness vs. moisture (and other parameters)
  in, say, a greenhouse for different-climate plants, etc.

--a simulation of a processor or of multiple distributed processors

--a traffic flow simulation where a basic rule of speed-up-if-
	car-ahead-is-far-away and slow-down-if-it-is-close is applied
  with random degrees for all cars--the congestion (cars per
  unit space at a given time instant) being the value of interest

Each GROUP should bring to class TWO COPIES ON PAPER of your part B. Remember that this should inlude design a textual description, design diagrams, code, and tests. Remember to use staples or binder clips both sets of your work together. Turn one copy in to us.

In general you should run your idea by us AFTER you have thought about the objects and messages involved. This is the best way to ensure that when we say it's a good idea you know you have covered enough details.

Part C

Your group will be reviewing another group's work. In class on the due date, you should find another group with which to exchange your other copy of part B (text, diagrams, code and test results). Each group will make comments on the other's code (approach, style, additional ideas, missed bugs, etc.). The groups will also need to meet and test each other's code online, the results of which you can comment on along with your other comments on their paper. While you can turn in the code with the comments on it, you should summarize your review using a word processor. On this document you should clearly mark
REVIEWERS: <names of your group members>
AUTHORS OF REVIEWED CODE: <names of members of group whose work you reviewed>
Submit this packet (in office hours or mailbox) by 5pm on the due date.

As with all the assignments this semester, the baseline of expectations will earn you a 'B'. Here that baseline is at least three objects that have some inheritance among them and of which you create at least a few instances that interact with each other in some fashion. An 'A' can be earned, typically, by putting some effort into the interactions among the objects (e.g. that they are fairly rich) and into the interface for using the system (e.g. does it just run with a complicated top-level call and return a number as a result, or are there several functions that allow access to the behavior of the simulation as the ongoing interactions among the objects continue to evolve the state of the simulation, are these made visible to the user in some reasonable way). We will talk further in class about what makes a good program. And of course, your code must actually work to get points for the assignment.

[ Back to CS451: The LISP Segment ]