11.5 Chapter Summary

In this chapter, we implemented non-recursive and recursive, user-defined functions in Camille. In Camille, functions are represented as closures. We built three representations for the closure data type: an abstract-syntax representation (ASR), a closure representation (CLS), and a Python closure representation (i.e., lambda expressions in Python; Programming Exercise 11.2.12). When a function is invoked, we pass the values to be bound to the arguments of the function to the closure representing the function. For the ASR and CLS representations of a closure, a pointer to the environment in which the function is defined is stored in the closure (i.e., lexical scoping). For the Python closure representation (i.e., lambda expressions in Python), a pointer to the environment in which the function is called is stored in the closure. We continue to see that identifiers as references are superfluous in the abstract-syntax tree processed by an interpreter; only lexical depth and position are necessary. Thus, we developed both named and nameless non-recursive environments, and named and nameless recursive environments (Table 11.3) and interpreters using these environments (Table 11.4). Moreover, we continue to see that deep binding is not lexical scoping and that shallow binding is not dynamic scoping. Deep, shallow, and ad hoc binding are only applicable in languages with first-class functions (e.g., Scheme, Camille).

Table 11.3 Variety of Environments in Python Developed in This Text (Key: ASR = abstract-syntax representation; CLS = closure; LOLR = list-of-lists representation; PE = programming exercise.)

Table 11.4 Camille Interpreters in Python Developed in This Text Using All Combinations of Non-recursive and Recursive Functions, and Named and Nameless Environments. All interpreters identified in this table work with both the CLS and ASR of closures (Key: ASR = abstract-syntax representation; CLS = closure; LOLR = list-of-lists representation; PE = programming exercise.)

Figure 11.12 and Table 11.5 present the dependencies between the versions of Camille we have developed. Table 11.6 summarizes the versions of the Camille interpreter we have developed. Note that if closures in Camille are represented as Python closures in version 2.0 of the Camille interpreter, then the (Non-recursive Functions, 2.0) cell in Table 11.6 must contain "↓ lambda ↓". Similarly, if closures in Camille are represented as Python closures in version 2.1 of the Camille interpreter, then the (Recursive Functions, 2.1) cell must contain "↓ lambda ↓".

Table 11.5 Versions of Camille (Key: ASR = abstract-syntax representation; CLS = closure; LOLR = list-of-lists representation.)

Table 11.6 Concepts and Features Implemented in Progressive Versions of Camille. The symbol ↓ indicates that the concept is supported through its implementation in the defining language (here, Python). Python keyword included in each cell, where applicable, indicates which Python construct is used to implement the feature in Camille. The symbol ↑ indicates that the concept is implemented manually. The Camille keyword included in each cell, where applicable, indicates the syntactic construct through which the concept is operationalized. (Key: ASR = abstract-syntax representation; CLS = closure; LOLR = list-of-lists representation. Cells in boldface font highlight the enhancements across the versions.)

Table 11.7 outlines the configuration options available in Camille for aspects of both the design of the interpreter (e.g., choice of representation of referencing environment) and the semantics of implemented concepts (e.g., choice of scoping method). As we vary the latter, we get a different version of the language (Table 11.6). Note that the nameless environment is not available for use with the interpreter supporting dynamic scoping.

Table 11.7 Configuration Options in Camille