Consequences

Tradeoffs of Translator are:

• External functionality. Translator makes it easy to add interpretations to data structures with heterogeneous elements. In contrast to Visitor [4] there is no need to impose an Accept method on the elements. Spreading interpretations over all elements (i.e., object-oriented design) would demand changing all elements when introducing a new interpretation. Gathering all related behavior into one generic function (i.e., functional design) -- thus separating unrelated behavior (e.g., compilation from pretty-printing) -- results in a clean partition and allows to hide interpretation specific details (like interpretation specific data structures and accumulated state) in generic functions.

  
  

    

  Figure 6: Distinct interpretation phases

  
  
  
• Instability. When using Translator, adding new elements (e.g., changing the abstract syntax of a language) becomes difficult. Unlike Visitor, Translator does not demand that one extends all interpretations with a meaning for a new element (e.g., compilation is not affected by adding a new type-declaration node). However, updating of concrete function packages and creation of specific functions is required. Note that the latter point must be done anyway, but if interpretations are element methods, then their completeness can be enforced by the compiler. Using Translator, runtime errors caused by an undefined mapping to a specialized function may occur.

• Extensibility. It is easy to add new translations and/or target structures. A new interpretation simply requires

  1.

  defining a new target structure (top exclamation mark in figure 3),

  2.

  defining specialized functions (rightmost exclamation mark), and

  3.

  providing a function package that maps the source elements to their specialized functions (leftmost exclamation mark).

  The last action is a tribute to the emulation of generic functions.
• Flexibility. Elements to be translated need not be from one class hierarchy (a counter example is Iterator [4]). In any case, the full individual interface can be accessed by the associated specialized functions.
• Broken encapsulation. Since specialized functions can access the public interface of elements only, the interface may be forced to be wider than necessary for other clients. A remedy is to use selective export or another kind of ``friend'' mechanism.

• Separation. The semantics of an interpretation is defined in terms of a target structure semantics (see figure 6). Thus, a clear separation between translation (mapping to a target) and target semantics (meaning of target) is achieved.
  
    

  Figure 7: Splitting the interpretation

  
  
  Figure 7 depicts how an interpretation is split into a translation to a new Target structure and an evaluation function that produces the final result. During the translation several simplifications are possible (see table 1).
  
   

  Table 1: Simplifications possible while translating

  Notation	Meaning	Example
  $\phi(op_{1})=op',\linebreak\phi(op_{2})=op'$.	Map distinct source elements onto one destination element.	Translate both assign and initialize to store.
  $\phi(op(a,b))=op'(\phi(a))$.	Drop source operands.	Do not consider type declarations for compilation.
  $\phi(op(a,b))=\phi(a)$.	Prune source operators.	Compile procedure bodies only and forget about headers.
  $\phi(op(a,b,c))=\phi(b), \linebreak\mathit{if}\; \mathit{pred}(a)$.	Perform static analysis to select operands.	Compile if-then-else to its then branch, if the boolean condition is always true.

   
  
  

  A pretty-print, therefore, is not a sequence of side effects but, at first, a hierarchical structure of print-elements, combinators, and possibly layout functions. In a second step the, e.g., string representation of a pretty-print is produced from this structure. Note that now it is perfectly alright to implement the semantics of the target structure as member methods of the target structure. Since that structure is meant for only one purpose, as opposed to the abstract syntax tree which has many interpretations, there is no drawback involved.
  

    

  Figure 8: Non-interfering semantics

  
  
  Figure 8 shows the separation between interpretations and their associated target structures (T_c and T_p). The operation names inside the target structure boxes denote their definition as member methods. There will be no new interpretations on target structures that would require to open and change the whole set of their classes. The interpretation can be defined locally for each element, exploiting inheritance and redefinition, without the disadvantages mentioned in section 2.2.

  Besides the nice partition between translation- and semantic related code, the target structure also may serve as a logical structure for the final representation. For instance, a mouse click onto a keyword could cause highlighting the whole corresponding statement and its subcomponents. While this could be achieved by back-pointers into the original abstract syntax tree as well, it is cleaner and more appropriate (as no reinterpretation is necessary) to refer to the pretty-print structure. This argument becomes more obvious in case of interpretations whose logical structure bear less resemblance to the abstract syntax tree (e.g., type-checking information).

  Also, assuming multiple users are working simultaneously on one abstract syntax tree, multiple intermediate structures allow them to, e.g., use different compilation options to achieve various code results. If semantic results are stored directly in the source structure, this would be a cause for interference.

  Furthermore, an intermediate structure is also helpful when aiming for incremental updates.

• Incrementality. Naturally, target structures are subject to fast incremental recomputation since they are produced by homomorphic mappings from their source structure (see section 1). Assuming N to be the number of source structure elements, the asymptotic amount of recalculation needed to update the result of an abstract interpretation is reduced from $\mathop{\smash{\rm O}}\nolimits(N)$ down to $\mathop{\smash{\rm O}}\nolimits(\log{N})$. However, it is necessary to store previously computed results somewhere. Our approach of non-intrusive addition of interpretations forbids storing these at the source elements. The target structure, however, (see figure 6; the flash signs denote places of change) can serve as a store for incremental results. The target structure can play the role of an Observer [4] that becomes notified by changes in the source structure and starts the necessary recomputations. The target structure, in turn, is observed by the final result.
• Space overhead. If incremental evaluation is not an issue and space efficiency is a priority, then the intermediate structure should be avoided in favor of a direct translation to the final semantics. In a distributed setting, however, we may purposely want to trade space for speed. The intermediate structures can be made local to their users, while the single source structure is accessed only when needed. Ergo, frequent evaluations of target structures do not add to net traffic.