Assignment 2

In this assignment you will modify an interpreter for the PostFix language as described in the Turbak text, Chapters 1-3. Your interpreter will mirror the small-step operational sematics rewrite rules on page 47 of the text. This assignment will also give you an opportunity to use the pattern-matching facilities of Scheme+.

• Scheme+
• Support procedures for PostFix and PostText
• Interpreter for PostFix

To get started with PostFix, we first must load the Scheme+ file and the PostFix support file into the interpreter.

(load "scheme+.scm")
(load "base.scm")
(load "postfix.scm")

After that, we can begin testing some simple PostFix programs with the supplied semantics.

In general, to evaluate a PostFix program, apply it to a list of numbers with as many elements as the first argument to postfix.

The interpreter closely follows the rewrite rules presented as part of the small-step operational semantics of PostFix. These rules are listed on page 47 of the Turbak text. Each rewrite rule transforms a configuration into another. In PostFix, a configuration is a tuple consisting of a list of commands and a stack. For example, the rule labeled [pop] takes a configuration with pop at the head of the command list and a value at the top of the stack, and returns a configuration with pop removed from the command list and the value at the top of the stack removed.

The interpreter makes use of a function small-step which, given a PostFix configuration, returns a new PostFix configuration representing the completion of one step of the PostFix computation. That is, given a configuration, it applies one of the rewrite rules and returns the rewritten configuration.

The PostFix support file contains the declarations of several datatypes which are used in the interpreter. These datatypes define what configurations, commands, and stack values look like to the small-step interpreter.

As described in section 1.4.1 of the Turbak text, the commands in PostFix are:

• Integer numerals
• Command tokens: add, div, eq, exec, gt, lt, mul, nget, pop, rem, sel, sub, swap
• Executable sequences

The provided PostFix infrastructure converts PostFix syntax into a list of commands, where each command matches one of the following:

• (@num n): An integer numeral
• (@seq s): An executable sequence
• (@arithop op): An arithmetic operation
• (@relop op): An arithmetic comparison
• The rest: (@exec), (@nget), (@pop), (@sel), and (@swap)

As stated in section 1.4.2 of the Turbak text: a value on the stack is either (1) an integer numeral or (2) an executable sequence. The provided infrastructure expects data matching one of the following:

• ($num n): An integer numeral
• ($seq s): An executable sequence

Notice the difference between the constructors for stack data and commands: the stack data constructors begin with '$' while the commands begin with '@'.

A configuration is simply a tuple containing a command list and a list of stack values: ($conf command-list stack).

The infrastructure calls small-step with a configuration, and expects it to return a configuration. The code assumes that the command list passed to small-step is non-null; that is, it has at least one command in it. The provided semantics uses Scheme+ pattern matching to get at that first command and the stack:

(define (small-step config)
  (match config
    (($conf (cons cmd rest-cmds) stack) ... )))

Notice that Scheme+ pattern matching was able to look not only inside the configuration, but also inside one of its elements, namely the command list. This facility will be useful for examining the state of the stack for some of the commands. In fact, the only way to inspect the type of values present on the stack is to use pattern matching.

Now looking inside the ... in the above code from the semantics:

     (match cmd
       ((@num n)
	($conf rest-cmds (cons ($num n) stack)))
       ((@pop)
	(match stack
          ((cons _ rest-stk) ($conf rest-cmds rest-stk))
	  (_ (stuck "pop"))))
       ...)

The first example matches numeric literals, and simply returns a new configuration with the number removed from the command list and added to the top of the stack. Each clause looks roughly like this, matching a command name and returning a new configuration using $conf.

The second example above, @pop, performs a pattern match on the stack, ignores the top element, and returns the rest of the stack. This example highlights the use of stuck: if the pattern match fails, then no rewrite rule applies for this configuration in the operational semantics. Therefore, we cannot continue computation; we say we are stuck.

In the implementation of small-step, if no rewrite rule applies to the given configuration, the code calls stuck, passing it a string with the name of the command that failed. Every syntactically correct PostFix program does not cause a pattern match failure or otherwise cause an error; the interpreter instead calls stuck.

One of the chief limitations of the PostFix language is that there is no way to name values. In this problem, we consider extending PostFix with a simple naming system. We will call the resulting language PostText. (This is adapted from a problem in the Turbak text.)

The grammar for PostText is the same as that for PostFix except that there are three new commands:

C ::= ...
	| I [Name]
	| def [Definition]
	| ref [Name-reference]

Here, I is an element of the syntactic domain Identifier, which includes all alphabetic names except for the PostText command names (pop, exec, def, etc.), which are treated as reserved words of the language.

The model of the PostText language extends the model of PostFix by including a current dictionary as well as a current stack. A dictionary is an object that maintains bindings between names and values. The commands inherited from PostFix have no effect on the dictionary. The informal behavior of the new commands is as follows:

I: I is a literal name that is similar to an immutable string literal in other languages. Executing this command simply pushes I on the stack. The Value domain must be extended to include identifiers in addition to numerals and executable sqeuences.

def: Let v₁ be the top stack value and v₂ be the next to top value. The def command pops both values off of the stack and updates the current dictionary to include a binding between v₂ and v₁. v₂ should be a name, but v₁ can be any value (including an executable sequence or name literal). It is an error if v₂ is not a name.

ref: The ref command pops the top element v_name off of the stack, where v_name should be a name I. It looks up the value v_val associated with I in the current dictionary and pushes v_val on top of the stack. It is an error if there is no binding for I in the current dictionary or if v_name is not a name.

Consider the following evaulations:

In an SOS for PostText, the usual PostFix configuration space must be extended to include a dictionary object as a new state component:

CF_PostText = Commands X Stack X Dictionary

Suppose that a dictionary is represented as a sequence of identifier/value pairs:

D ∈ Dictionary = (Identifier X Value)*

1. Define the final configurations, input function, and output function for the PostText SOS.
2. Give the rewrite rules for the I, def, and ref commands.

• The command datatype must be extended to contain the new commands provided by PostText. Once added, these commands can be used in pattern matching expressions within the interpreter.
• The parse-command function must be taught how to parse PostText syntax. Hint: to parse identifiers, the last line should pattern match on (symbol->sexp sym) to match all symbols other than the ones listed above it (e.g. the commands).
• As discussed above, the configuration datatype has to change to accomodate PostText. Keep in mind that this data structure is both the argument and the return type of small-step, and is also used by evaluate and returned by make-initial-config (which is the input function of the operational semantics).
• Update small-step to handle all these changes to the core data structures of the interpreter.
• After all the PostFix commands work again, add implementations of I, def, and ref.

(check '((posttext 1 4 add) '(3)) 7)
(check '((posttext 0 1 2 pop swap) '()) "stuck: swap")

• Warmup: Complete the implementation of PostFix's small-step
• Implement nget using pattern matching on the stack
• Call stuck if no rewrite rule applies
• Problem 1a: Complete the semantics for PostText
• Problem 1b: Implement PostText (including nget)
  • Update the datatypes, parser, and small-step to implement the PostText semantics defined in problem 1
• Problem 2: Write test cases using check to validate your code
• Submit your work
  • Put the write up for Problem 1 in a PDF file called uniqname.pdf (please no Word .doc files!)
  • Put your PostText implementation and test cases in a file called uniqname.scm
  • Send those files to pdarga@umich.edu