3.5.2 OO languages: Death to If Statements

Motivation

In an OO system, control is a polymorphic thing. Messages are sent to different objects and what happens depends on the class of the receiver.

That is, in pure-OO, we never case on type. Rather, we are clever when creating our instances such that, at runtime, everyone knows how to handle themselves.

Usual Stuff

Setup

Perform the weekly set up instructions for project 2, homework b. If you find that you are missing any files, copy them over from 2/a.

CAUTION: do not cp 2/a/* as that may copy the magic .svn directory into 2/b (thus messing up your repo). Copy them over the old-fashioned way (e.g. cp ../a/gold.lisp .) then svn add them.

What to hand in

Report:

• All the lisp functions you’ve written;
• The ‘repl.txt’ coming from your REPL session where you run (main) (described below);
• Your svn log showing all the commits generated as part of this week’s homework.
• A file containing your deftests for all parts of the following;

What deftests? you might ask. This code generates output. What can we deftest?

We’ll if you really understand the following, you’ll see lots of little tasks that require lots of little tests. When co-ordinating between team members, you divide up functionality, commit changes, then email your colleagues "hey, XYZ is working, see !thisTest". So deftest becomes your communication tool.

So I want you to show me that you actually have some team skills. I want to see at least one file per team member (with your name on it) and each file contains at least five deftests. And I want to see in the svn log statements like "hey guys! deftest XYZ is working- check it out", or "I found a bug in your deftest and wrote another deftest to show you where it crashes".

Our Class Hierarchy

*object*
   *phrase* (does "act", has "$head") 
      *rule* (does "register", has "$body")
      *terminal* 

Note that:

• For graduates of Mr. Morehead’s 210 subject, this is the composite pattern.
• The above list of methods and instance variables is incomplete. You have to work out what is missing.

Here, *rule*s and *terminal*s both have "$head"s but only *terminal*s have a "$body".

"Act" is different in *rule*s and *terminal*s:

• For *rule* it recurses over the "$body" and calls recursively on the stuff found in the "$body". Note that, in this design, much of the functionality of generate becomes methods inside *rule*.
• For *terminal*, it just prints the head.

So the way this runs is that some clever function inputs the rules of your current grammars (a -> b c ) and outputs a hash table of *phrase* instances, indexed by their "$head" (don’t know how to do hash-tables in LISP? see section 4.8 of Graham’s text). This function returns the first phrase in the grammar.

Then, the message act is sent to the first rule in the grammar. After than, act rampages round the instances, recursing deeper and deeper into the structure.

What to do

• Implement the class hierarchy shown above
• Move the generate functionality of homework one into the above classes.
• Write the instance generation function described above. It will work something like this:

  ; warning: written, not tested
  (defun phrases->instances (all universe)
         (mapcar #'(lambda (one)
                         (phrase->instance one universe)) 
                   (cdr all))
         (phrase->instance (car all) universe))
  
  (defun main (all)
         (let* ((universe (make-hash-table))
                (start    (phrases->instances all universe)))
           (act start universe)))
  
  (defun phrase->instance (rule universe)
     "returns an instance of class phrase"
     (let ((head (first rule))
           (body (cdr (cdr rule)))
           (phrase (inst *phrase*)))
       (setf (gethash head universe) phrase) ; store phrase
       ...; fill in phrase
       phrase ; return phrase
     ))
  

• Test the above on a tiny grammar (two or three phrases). Make sure your grammar has "ands" and "or" in the body.

This document was generated on April 19, 2011 using texi2html 5.0.