Enviroment-passing style

[BastiS]

I have a question concerning the environment passing-style introduced in the lecture about implementing state.
On slide 23 we have the following code:

Code: Alles auswählen

(local ((define a (box 1)))
  (local ((define f (lambda (x) (+ x (unbox a)))))
    (begin
      (set-box! a 2)
      (f 5))))

It actually evaluates to 7, which have been my intuition too.

On slide 24 it's written (concerning the same piece of code) "Static scoping rules for function application will defeat environment-passing style"
My question: Why?
Isn't this just what we wanted to implement? Having a sequence where a first expression may affect the second one? I don't see any disadvantage resulting of schemes static scoping, in my opinion the "dynamic scoping of the set-box!" leads to this result....and this is exactly the result we want to have. If we'd have strict static scoping we would have 6 as the result.

Due to this problem I don't really see a reason for introducing the store-passing style.

Can anyone help here?

[Nori]

As far as I understood, store-passing-style is needed to distinguish between variable definitions, and value updates. In enviroment-passing-style, a local definition of a variable in the first statement of a seqn would still be visible in the second statement of the seqn, because it was added to the environment This is against static scoping rules.
In store-passing-style, new variables are not visible in the next statement, while updates to old ones are.

Was that clear?

[Julius]

So just do be sure I understand the idea of introducing a store right:

The reason of introducing an additional indirection is that we want to separate the names of bound identifiers from their values. Static scoping forces us to not propagate the introduction of new identifiers when sequencing (that means the environment is not passed along within the sequence) but we want to propagate the changes done to identifiers that are not new to the environment (therefore we pass the store along within the sequence). The store then potentially includes entries of new introduced identifiers but they are never referenced within the environment and therefore not visible.

Did I get the idea right?

And an other question: It would not change the semantics if we would implement the update of an entry in the store by replacing the old entry instead of inserting it to the beginning of the store, right?

[sewe]

@Julius: Yes, do did get the idea right FWIW, I find extent and scope to be useful terms when discussing this; we want to be able to distinguish the time interval in which a value lives in memory (its extent) from the (union of) interval(s) in which it is visible (its scope).

And yes, we could update the entries in the store in-place. (The store is, after all, just our version of RAM.)