CS611 Lecture 12 Modules and State 25 September 2006Lecturer: Dexter Kozen1 IntroductionIn the last two lectures, we studied the static and dynamic approaches to variable scoping. These scopingdisciplines are mechanisms for binding names to values so that the values can later be retrieved by theirassigned name.Both static and dynamic naming strategies are hierarchical in the sense that variables enter and leavescope according to the program’s abstract syntax tree (in the case of static scoping) or the tree of functioncalls (in dynamic scoping). This dependence on hierarchy might prove restrictive or inflexible for writingcertain kinds of programs. In such cases we might want a more liberal naming discipline that is indepe ndentof any hierarchy induced by the syntactic structure or call structure.Such a non-hierarchical scoping structure is provided by modules. A module is like a software blackbox with its own local namespace. It can export resources as a set of names without revealing its internalcomposition. Thus the names that can be used at a certain point in a program need not “come down fromabove” but can also be names exported by modules.Good programming practices encourage modularity, especially in the construction of large systems. Pro-grams should be composed of discrete components that communicate with one another along small, well-defined interfaces and are reusable. Modules are consistent with this idea. Each module can treat the othersas black boxes; that is, they know nothing about what is inside the other module except as revealed by theinterface.Early programming languages had one global namespace in which names of all functions in source filesand libraries were visible to all parts of the program. This was the approach for example of FORTRAN andC. There are certain problems with this:• The various parts of the program can become tightly coupled. In other words, the global namespacedoes not enforce the modularity of the program. Replacing any particular part of the program withan enhanced equivalent can require a lot of effort.• Undesired name collisions occur frequently, since names inevitably tend to coincide.• In very large programs, it is difficult to come up with unique names, thus names tend to becomenon-mnemonic and hard to remember.A solution to this problem is for the language to provide a module mechanism that allows related functions,values, and types to be grouped together into a comm on context. This allows programmers to create a localnamespace, thus minimizing naming conflicts. Examples of modules are classes in Java and C++, packagesin Java, or structures in ML. Given a module, we can access the variables in it by qualifying the variablenames with the name of the module, or we can import the whole namespace of the module into our code, sowe can use the module’s names as if they had been declared locally.2 ModulesA module is a collection of named things (such as values, functions, types etc.) that are somehow related toone another. The programmer can choose which names are public (exported to other parts of the program)and which are private (inaccessible outside the mo dule).There are usually two ways to access the contents of a module. The first is with the use of a selectorexpression, where the name of the m odule is prefixed to the variable in a certain way. For instance, we writem.x in Java and m::x in C++ to refer to the entity with name x in the module m.The second method of accessing the contents of a module is to use an e xpression that brings names froma module into scope for a section of code. For example, we can write something like with m do e, whichmeans that x can be used in the block of code e without prefixing it with m. In ML, for instance, the1command “Open List” brings names from the module List into scope. In C++ we write “using namespacemodule name;” and in Java we write “import module name;” for the similar purposes.Another issue is whether to have modules as first class or second class objects. First class objects areentities that can be passed to a function as an argument, bound to a variable or returned from a function. InML, modules are not first class objects, whereas in Java, modules can be treated as first class objects usingthe reflection mechanism. While first-class treatment of modules increases the flexibility of a language, itusually requires some extra overhead at run-time.3 Module Syntax and Translation to u MLWe now extend uML, our simple ML-like language, to support modules. We call the new language uML+Mto denote that it supports modules. There must be some values that we can use as names with an equalitytest. The syntax of the new language is:e ::= . . .| module (x1= e1, . . . , xn= en) (module definition)| em.e (selector expression)| with eme (bringing into scope)| lookup − error (error)We now want to define a translation from uML+M to uML.1To do this, we notice that a module isreally just an environment, since it is a mapping from names to values. Here is a translation of the moduledefinition:[[module (x1= e1, x2= e2, . . . , xn= en)]] ρ4=λx. if x = x1then [[e1]] ρ elseif x = x2then [[e2]] ρ else. . .if x = xnthen [[en]] ρ elselookup-errorThe above is one possible translation. Note that ρ is passed as the environment to the translation ofe1, . . . , en. This has an important consequence: variables defined within the module are not visible within theinitialization expression of other variables in the module. For instance, in the above translation, we cannotrefer to any of the xi’s within any of the ei’s. Nor does it seem possible to use the resulting environmentwithin itself for the purpose of accessing the module variables, since this leads to circularity problems.However, we could translate module using techniques from the translation of letrec. The environmentthat results after the translation should be the same that is used within the module. This can be found bytaking the fixpoint of the functionλρ0. λx. if x = x1then [[e1]] ρ0elseif x = x2then [[e2]] ρ0else. . .if x = xnthen [[en]] ρ0elselookup-error1Actually our translation is to the target language uML+S+lo ok up-error, a simple extension to uML that contains equalityoperators for strings and an extra token called lookup-error, which is returned when a variable name is not found in a module.2This works fine if the ei’s are functions. However, it is not clear how to handle variables whose