Skip to content

PA5: Operational Semantics

Goal

Programming assignments 2 through 4 involved the constructed of the front-end (lexer, parser) and gatekeeping (semantic analyzer, type checker) stages of an interpreter. In this assignment you will write the code that performs the execution and interpretation of valid programs.

For this assignment you will write an interpreter. Among other things, this involves implementing the operational semantics specification of Cool. You will track enough information to generate legitimate run-time errors (e.g., dispatch on void). You do not have to worry about "malformed input" because the semantic analyzer (from PA4) has already ruled out bad programs.

You will also write additional code to unserialize the class and implementation maps produced by the semantic analyzer and the parse tree produced by the parser.

Specification

You will turn in a program that takes a single command-line argument (e.g., file.cl-type). That argument will be an ASCII text Cool class map, implementation map, and AST file (as described in PA4). Your program must execute (i.e., interpret) the Cool program described by that input. If your program is called interp, invoking interp file.cl-type should yield the same output as cool file.cl.

You will only be given .cl-type files from programs that pass the semantic analysis phase of the reference interpreter. You are not responsible for correctly handling (1+"hello") programs.

Error Reporting

To report an error, write the string:

ERROR: line_number: Exception: message

to standard output and terminate the program. You may write whatever you want in the message, but it should be fairly indicative. Example erroneous input:

1
2
3
4
5
6
class Main inherits IO { 
  my_void_io : IO ; -- no initializer => void value 
  main() : Object { 
    my_void_io.out_string("Hello, world.\n") 
  } ; 
} ;
Coresponding example error report output:

ERROR: 4: Exception: dispatch on void

Commentary

Tests

  • You can use the following tests to check your implementation.
  • You can do basic testing as follows:
$ cool --type file.cl 
$ cool file.cl >& reference-output 
$ my-interp file.cl-type >& my-output 
$ diff my-output reference-output
  • Note that this time, whitespace and newlines matter for normal output. This is because you are specifically being asked to implement IO and substring functions.
  • You should implement all of the operational semantics rules in the Reference Manual. You will also have to implement all of the built-in functions on the five Basic Classes.

Video Guides

now so that you have plenty of time for the rest of the features later.

Turn-In and Grading

PA5c

PA5c is a checkpoint for PA5 to encourage you to start early. The Interpreter is a large and complicated assignment; we do not want you to fall behind.

For the PA5c checkpoint you will only be tested on something akin to hello-world.cl. If you can interpret that, you pass the checkpoint. (You can "cheat" the checkpoint by hard-coding output for that single test case, but you're ultimately only hurting yourself!) The goal of the checkpoint is not to do the minimal amount of work possible for this program, but instead to do the greatest amount possible

PA5

You must turn in a zip file containing these files:

  1. readme.txt -- a plain ASCII text file describing your design decisions. In addition, answer the following questions in your readme.txt:
    1. What are some challenging parts for this assignment? What did you do to solve them?
    2. Suggestions for both the instructor and future students for this assignment?
  2. main.ml -- your implementation

Grading Rubric

PA5 Grading (out of 100 points)

  • 66 points --- for autograder tests
    • Each missed test removes points, to a minimum of 0/66, even if there are more tests than total points.
  • 10 points --- for a correct PA5c submission
  • 8 points --- for a clear description in your README
    • 8 --- thorough discussion of design decisions (e.g., the handling of let and new and dispatch) and choice of test cases; a few paragraphs of coherent English sentences should be fine
    • 4 --- vague or hard to understand; omits important details
    • 0 --- little to no effort
  • 8 point --- for valid and novel test1.cl, test2.cl, test3.cl and test4.cl files
    • 8 --- wide range of test cases added, stressing most Cool features and some error conditions, novel files
    • 4 --- added some tests, but the scope not sufficiently broad
    • 0 --- little to no effort, or parts of course files resubmitted as tests
  • 8 point --- for code cleanliness
    • 8 --- code is mostly clean and well-commented
    • 4 --- code is sloppy and/or poorly commented in places
    • 0 --- little to no effort to organize and document code