| Question | |
|---|---|
| 1 | Meaningless answer (such as drawing a parse-tree of a Core program as the
answer to this question): 0 pts Wrong answer, i.e., "this cannot be done", with a poor explanation for why (such as the Tokenizer doesn't know anything about the Core grammar): 4 pts Wrong answer, i.e., "this cannot be done", with a somewhat plausible explanation for why (such as the Tokenizer doesn't tell us which particular integer it read, only that it was an integer (token no. 31) or which particular id it read, only that it was an integer (token no. 32): 10 pts Partially to totally correct answer: 11-15 pts. |
| 2 | Most people got the first part of this question right. It was in the second part, about the three types of errors (context-free, context-sensitive, runtime) as they occur in Java, that several had problems. The most common one was claiming that only runtime (or only runtime and c.s.) errors are possible in Java. That is not true; it is true that the JVM only handles runtime errors but that is because the Java compiler has already taken care of handling c.f. and c.s. errors. So, e.g., a mistyped keyword would be a c.f. error; a mistyped identifier or mismatched type of identifier would be a c.s. error; and array index out of bounds or division by zero would be r.t. errors. Assuming that the only mistake in the answer is this one --talking only about the errors handled by JVM-- would mean a 3 or 4 point penalty; if there are other errors, the grading would depend on the details of the error. |
| 3 | The common error in this problem was thinking that the eIds[] array contains the actual Id objects when, in fact, it is simply a set of pointers to the Id objects which are created whenever the parser encounters a new identifer in the input stream. The eIds[] array allows the parser, by following the pointers that eIds[] contains, to go to the existing individual Id objects and check their names against the name of identifier just read from the input stream. If the name of one of those already existing identifiers matches the name just read, the parser does not create a new Id object; but if it doesn't find a match, it creates a new one and adds a *pointer* to the newly created Id object to the eIds[] array (which was created when the interpreter *started* running, when no Id objects had yet been created). (idCount is simply a count of the number of entries in eIds[].) The *purpose* of eIds[] is to ensure that only one identifier with a given name is created, no matter how many times it appears in the source Core program. Now the source program is, of course, looked at *only* by the parser; once the parser finishes, the abstract parse tree and the Id objects have all been created; and wherever a given identifer appears in the source program, such as the left side of an assignment statement, the object corresponding to the Assign node will include a pointer to the particular Id object and the *parser* would have ensured this; and that Id object will contain all the relevant information about that identifier, such as its name, its current value (during execution), etc.. Therefore, once the parsing is complete, there is no longer any need for eIds[] or idCount. As I said earlier, this was a common error; and if this was the only error, in a given student's answer, the penalty will be 5 points. The penalty for other errors will depend on the particular error. |
| 4 | Make sure you read the document I posted earlier (midterm comments) that explained the details of how OO polymorphism works, including what "runtime dispatching" means. A number of students didn't get this at all; you should make sure you understand it well because, chances are, someone in some job interview will ask you about it! Depending on how wrong your answer is, you will lose between 10 and 15 points (less, in the case of minor errors). | 5 and 6 | A number of students simply wrote *imperative* code in answering these questions; that is completely wrong. Penalty for such answers will be substantial, 12 points or more in each case. For other less problematic answers, the penalty will be lower, depending on how reasonable the answers were; these answers ranged from completely correct to, especially in the case of problem (6), completely incorrect. |