> I just found that in the example program in exercise 3, "x < 5" should be
> replaced with "x <= 5",

You are right. I just can't seem to remember that IMP doesn't have a full
set of boolean connectives. Good eyes.

> Also I'm wondering when interpreting the "try" command, the exception
> handler (i.e. the command "c2" in "try c1 catch x c2") should see the
> side effects of c1 or not.  I'm assuming the answer is yes.

Yes. More precisely, the exception handler c2 should see any side effects
of c1 that happened before the final uncaught exception (the one caught and
bound to x in c2) was thrown in c1.

        - Wes

---

> Hi, On HW2#3 what is the purpose of the after c_1 statement?  In C#/Java
> it is just try {c_1} catch x {c_2} finally {c_3}, and I am not sure what
> the purpose of the after statement is, or if it is an accident...

In Java the catch and finally blocks are both optional. I wanted to keep
the syntax very clear and separate the notion of "finally" from the notion
of "catch". For example, when you are writing out the opsem rule for "try"
I don't want you to have to worry about whether a finally block is present
or not or somehow bake that into the inference rule.

If you have this in Java:

        try {c1} catch (x) {c2} finally {c3}

It would look like this in "IMP with Exceptions":

  after
    try
      {c1}
    catch x
      {c2}
  finally {c3}

Another way to think about it: we are working on the *abstract* syntax. You
might imagine that the concrete syntax is try-catch-finally but that it is
translated internally by the parser into two separate commands: the catch
one and the finally one.

[ If your question was really low level, the purpose of the "after" keyword
  is to avoid a potential LALR(1) shift-reduce parsing conflict because of
  "c1 ; c2" and "c1 finally c2" without having to worry about specifying
  precedence. But since this is not an undergrad compilers class I won't
  spend any time talking about such things unless asked to. ]

        - Wes

---

> [In Homework 2, Problem 2. ] Just want to make sure that b is a boolean
> expression, instead of a boolean "command".

Yes, b should be a "boolean expression". Sorry about that. 

        - Wes