Assignment 5: Test2 output

[LordHoto]

Hi,

I am wondering about the expected output given for the second test case. For label 3 ("y := 10 / (x - 1)") there is only a "divideBy((x - 1))" event generated, but according to the definition of the events used it should also create a "change(y)" event (and indefinitly many other change(...) events for all possible expressions, which use "y", but that goes a bit too far then ) I would say, since the change of y affects the evaluation of an expression y and y is used in the program. But maybe the idea is to only generate events for expressions used on the RHS, so variable names, which only occur on the LHS should not be tracked. Would be nice to hear some clarification about this.

// Johannes

[aderhold]

Yes, it suffices to generate events "change(a)" for arithmetic expressions "a" that occur in the program. As you mentioned, this includes expressions that occur in a RHS of an assignment. But it also includes expressions that occur in a Boolean expression.

Currently I don't see why it would help (or be necessary) to generate an event "change(y)" if "y" is never used in the program (i.e., if "y" does not occur in the sense described before). So if you see a necessity to generate "change(y)", then feel free to do so and explain the reason in your documentation of the event extraction function.

[DanielSchoepe]

If I understand this correctly, it would mean that the event extraction function would have to have access to the program code, to see which expressions are actually used. However, the
the assignment says that the function shall depend on the property and have type \(\chi : E_C \to E^*\). Wouldn't this mean, that the function's results can't depend on the actual program, since it's defined in general for a property and doesn't get the program as an argument? (Of course, a java method can access more objects than just its arguments, but then it would no longer implement a mathematical function of that type).

Or is the actual result of the (mathematical) function supposed to be infinite and our Java implementation that looks at the program (or some other mutable state) is just an implementation to
handle infinitely many events being generated? In this case it should be mentioned though, that \(E^*\) is the set of possibly infinite sequences, since the same notation is often used to
denote the set of finite sequences of \(E\)s. (For example, if one sees \(A^*\) as the operator giving you the free monoid on A). Arguably, this is implicitly given in Definition 2 (from Assignment 4) though.

[aderhold]

The idea is that (at least in this case) the event extraction function has access to the program code, so \(\chi : E_C \times \mathit{Stmt} \to E^*\). Thanks for pointing this out.

As usual, \(E^*\) denotes finite sequences. Consequently, Definition 2 on Assignment 4 does not claim that \(\tau\) is an element of \(E^*\).

[DanielSchoepe]

The idea is that (at least in this case) the event extraction function has access to the program code, so \(\chi : E_C \times \mathit{Stmt} \to E^*\). Thanks for pointing this out.

I realize that this question is probably too late, but what do you mean by "in this case"? Is there some general signature, like the one you gave, that extraction functions have to have or can they get
arbitrary information about the interpreter state, if it's useful? I was working under the assumption that the function (and its implementation) has to fit that signature and cannot, for instance, access the
current state or similar. If it could, it would make the analyses more precise though.

[aderhold]

The definition of an extraction function is not set in stone in general. For the purpose of this lab course (and the specific programming language at hand) it was defined to be independent of the program. The exception (and the meaning of "in this case") is that for the "change(a)" events it needs to depend on the program.