KHEPERA is similar to some compiler construction kits. However, these systems usually restrict the scanning and parsing tools used ; specify AST transformations using a low-level language, such as C  (instead of a high-level transformation-oriented language); or require that the AST always conforms to a single grammar specification, making translation from one language to another difficult [4,3,14]. Further, some systems rely on an attribute grammars for all AST transformations, without providing for a more general-purpose scheme for tree-pattern matching and replacement.
SORCERER, from the PCCTS toolkit , is the most similar, since it does not require the use of specific scanning and parsing tools, and since it provides a ``little language'' in the style of lex and yacc with embedded procedures written in another general-purpose programming language (e.g., C). SORCERER and KHEPERA share abilities to describe tree structures, perform syntax-directed translations, and support the writing of AST-based interpreters. In contrast, KHEPERA also supports rule-based translations that do not require a complete grammar specification; KHEPERA rules are well suited for the construction of ``use-def'' chains, data-flow dependency graphs, and other compiler-required analyses; and writing pretty-printer rules in KHEPERA does not require a complete tree-grammar specification. This allows pretty-printing to easily take place during grammar evolution.
None of the previous systems, including SORCERER, contain built-in support for ``replay'' of transformations, or for automatic and transparent tracking of debugging information. When translating programs from one language to another, the ``discovery'' of the best order for transformation application is often difficult, involving considerable AST analysis. The code to perform this analysis is often difficult to verify or is undergoing constant change during the implementation phase of a DSL. However, after the transformations are discovered and recorded in a database, a much simpler program (i.e., one that is easier to verify) could be written that applies all of the discovered transformations in the specified order, thereby proving, by construction, that the translation preserves semantics. In this case, only the semantics preserving characteristics of the transformations themselves must be proven--not the code which performs analysis and discovery. While we have not yet implemented such a prover, we have utilized the transformation discovery and replay capabilities of KHEPERA to implement a browser that presents intermediate views of the transformation process, and which can answer typical queries posed by a debugger (see Section 4.6).