Scope Resolution
I purchased myself a really nice Christmas present: Concepts, Techniques, and Models of Computer Programming. So far it has been a really nice read. Though I’m not familiar with the Mozart/Oz system that’s used (and conceptually developed) throughout the book, I’m beginning to glimpse some of the vast array of rather difficult choices that are available to the language designer. For example: scoping can be done lexically/statically or dynamically. Van Roy and Haridi had this to say:
Which default is the right one? The correct default is procedure values with static scoping. This is because a procedurethat works when it is defined will continue to work, independent of the environment where it is called. This is an important software engineering property.
Dynamic scoping remains useful in some well-defined areas. For example, consider the case of a procedure whose code is transferred across a network from one computer to another. Some of this procedure’s external references, e.g., calls to common library operations, can use dynamic scoping. This way, the procedure will use local code for these operations instead of remote code. This is much more efficient.7
&vdots;
7. However, there is no guarantee that the operation will behave in the same way on the target machine. So even for distributed programs the default should be static scoping.
I particularly like the advice that goes beyond just linguistic concern, branching out into systems design, because it meshes with my personal conviction that a programing language is a conceptual system in its own right. I’ve also had personal experience with having to modify my $LD_LIBRARY_PATH just to get certain programs to run. Still, I think that is an acceptable cost for keeping the memory load to a minimum by avoiding the redundancy inherent in running statically compiled code.
With regard to the scoping of values in a procedure, I must ask: What if you actually wanted the procedure to have different behavior based on the run-time execution environment? I didn’t see this discussed, but I would solve it with the addition of an external <var> in <statement-block> end, thereby making a diversion from the default explicit.
On the whole, the Mozart/Oz system supports more coding paradigms than I would have thought possible. This is accomplished through a rather elegant Kernel language approach, where the graft each of the available language architecture decisions onto a very small kernel language as the book progresses. Thus building the entire language one conceptual piece at a time.