## 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 mutandis^{3} 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.

,