Previous Up Next

5  Symbol

stable. Untested for the version which uses the functor from Table.

The module contains the implementation for symbols and generic symbol tables. Cf. [App98b, p. 108]. The functional implementation (via the Table-functor IntmaptableFun) uses the module for finite maps. The symbol tables will be used (among other things) to implement the environments, i.e., the bindings of variable names, respectively type names to corresponding values. This is done in Section sec:env.

Note that in the general library lib/ocaml, there is an alternative implementation of the symbol tables, using the Map-module, not the hash-tables as here. But it’s a bit unclear. Anyway, the implementation of the symbol tables here are a bit more complex than the symbol tables in the library; in some sense, the underlying “tables” are split out.

In the Java-implementation [App98a], p. 114, the package Symbol has two “tables”, one mapping strings to symbols and one mapping symbols to whatever it is needed in the semantics (i.e., here types). The string-symbol mapping is implemented using the hashtable implementation from the library.

What is the use of the Symbol-exception in [App98b]?

[Implementation] The implementation here differs from the one listed in the book [App98b]. It uses as another layer of abstraction functor from the module Table (cf. Section 3) which encapulates and implements mutatis mutandis3 the tables by referring to the library. The reason to factor out another layer of “tables” is that the functor Table.IntmaptableFun will be instantiated with different keys in different phases of the compiler.

The implementation of symbol table uses hashtables for the mapping from strings to integers, more specifically, the generic, non-functorized interface.

 ,
Previous Up Next