Seite 1 von 1

SRCFLAE: wrong passed store

Verfasst: 2. Mär 2018 21:34
von Hoang

Is the store used in line 158 (line 3 in the code fraction below) of SRCFLAEInterp.scala correct?

Code: Alles auswählen

case LetRec(boundId, namedExpr, boundBody) => {
      val (newLoc,s2) = store.malloc(stack, NumV(0))
      val extStack = stack.head + (boundId -> newLoc) :: stack.tail
      val (namedVal, bodyStore) = interp(namedExpr, extStack, store)
      interp(boundBody, extStack, bodyStore.update(newLoc, namedVal))
I think at this point we have to use s2 instead of the current store store.
As I understand:
- First, we reserve a position in the current store by allocating a dummy NumV(0). This yields a new store s2
- Second, we extend the stack by adding a binding for the boundId to that reserved location
- Third, we interpret the namedExpr. Here is where I confuse because the used stack is the extended stack, which corresponds to the new store s2, but the used store is not s2 but the current store store.
- Finally, we update the reserved location with the value of the namedExpr and interpret the boundBody with the extended stack and the updated store. <- Here is another clue why we should use s2 instead of store in the previous step. Because if store is used then no one knows what is at the location newLoc, and the reservation of newLoc is wasted.

Is that correct?

Best Regards

Re: SRCFLAE: wrong passed store

Verfasst: 3. Mär 2018 11:41
von Jannis
Disclaimer: I am not a tutor

I would say that what you said is correct and that the implementation somehow mixed up the different stores. However, as we model our store as a mutable object, the stores are actually all the same (store == s2 is true and bodyStore == store is also true) and therefore it does not matter which one we take.

Re: SRCFLAE: wrong passed store

Verfasst: 3. Mär 2018 11:45
von Ragnar

yes you are right, s2 should be used to interpret the namedExpr.
Basically, every time a store is updated in any way, and then used again is incorrect.

However, I suspect the code still works as expected, because we have correctly obtained a new location, and we correctly update that location at the end. The intermediate value does not matter. (Actually, updating the store causes side effects, so s2 and store actually are the same object …)