Global access to the entire problem is definitely what we want to avoid. Encapsulation is a useful tool for maintaning invariants, controlling access to data and so forth. We don't want to give it up, and we may not even be able to give it up to begin with.
One way to consider an environment is that it may be a physical machine with a set of bindings, variables and processes on it, where some of the bindings point to other environments - ie, other machines.
Then if you're a user of the tree, and you want to invoke loudly, there exists at least one other machine, dog, between yourself and bark. You obviously don't know what is on the bark machine because the dog mediates your access to it. You don't really have any access to it other than by sending a message to dog which asks it to send a message to bark.
So the number of "loudly" options in such a network (ie, the internet) is potentially unbounded. The dog machine might know, by virtue of asking the machines it is directly connected to, whether the binding loudly exists, and it can chose to expose either the binding, or another message named loudly which discriminates between multiple loudly options if the other machines connected to it (aka, dynamic dispatch).
In the example above, replace "$branch" with "$spawn" and "$walk" with "$send", and you effectively have the actor model, which is more like the OOP imagined by Kay and others. The fun part here would be to implement $spawn and $send though.
Ah, you inspire the thought that we don't necessarily know what the valid inputs are to a distributed program! But realize that this problem will bite you even higher up the food chain (so to speak) because what if there is more than one dog node? What does your program do in that case?
An environment can only bind a symbol to one expression, so the symbol "dog" in the tree environment is bound to an opaque reference to an environment (or machine), containing the dog's bindings. There can be many of these machines containing dog's bindings, but if you were to bind them all to dog, you would only have access to the most recently bound one, since binding a name in an environment overwrites any existing binding with a new one.
The solution is therefore, that we must either use bindings such as "dog1", "dog2" and whatnot, or we have a binding "dogs" which binds a list of environment objects, which we can index to refer to a specific dog. Actually, "dogs" could itself just be an environment which binds specific dog's names, like spike to their respective environments
One way to consider an environment is that it may be a physical machine with a set of bindings, variables and processes on it, where some of the bindings point to other environments - ie, other machines.
Then if you're a user of the tree, and you want to invoke loudly, there exists at least one other machine, dog, between yourself and bark. You obviously don't know what is on the bark machine because the dog mediates your access to it. You don't really have any access to it other than by sending a message to dog which asks it to send a message to bark.
So the number of "loudly" options in such a network (ie, the internet) is potentially unbounded. The dog machine might know, by virtue of asking the machines it is directly connected to, whether the binding loudly exists, and it can chose to expose either the binding, or another message named loudly which discriminates between multiple loudly options if the other machines connected to it (aka, dynamic dispatch).
In the example above, replace "$branch" with "$spawn" and "$walk" with "$send", and you effectively have the actor model, which is more like the OOP imagined by Kay and others. The fun part here would be to implement $spawn and $send though.