SAZ::2019

Compiler-compiler
In computer science, a compiler-compiler or compiler generator is a programming
tool that creates a parser, interpreter, or compiler from some form of formal description of
a programming language and machine. The input may be a text file containing
the grammar written in BNF or EBNF that defines the syntax of a programming language,
and whose generated output is some source code of the parser for the programming
language, although other definitions exist. Usually, the resulting source code will have to be
extended upon before a complete compiler emerges.[1]
A metacompiler is a software development tool used chiefly in the construction
of compilers, translators, and interpreters for other programming languages.[2] The input to a
metacompiler is a computer program written in a specialized
programming metalanguage designed chiefly for the purpose of constructing
compilers.[2][3][4] The language of the compiler produced is called the object language. The
minimal input producing a compiler is a metaprogram specifying the object
language grammar and semantic transformations into an object program.[

Variants
A typical parser generator associates executable code with each of the rules of the grammar
that should be executed when these rules are applied by the parser. These pieces of code are
sometimes referred to as semantic action routines since they define the semantics of the
syntactic structure that is analyzed by the parser. Depending upon the type of parser that
should be generated, these routines may construct a parse tree (or abstract syntax tree), or
generate executable code directly.
One of the earliest (1964), surprisingly powerful, versions of compiler-compilers is META
II, which accepted an analytical grammar with output facilities that produce stack
machinecode, and is able to compile itself and other languages.
Some experimental compiler-compilers take as input a formal description of programming
language semantics, typically using denotational semantics. This approach is often called
'semantics-based compiling', and was pioneered by Peter Mosses' Semantic Implementation
System (SIS) in 1978.[6] However, both the generated compiler and the code it produced
were inefficient in time and space. No production compilers are currently built in this way,
but research continues.
The Production Quality Compiler-Compiler project at Carnegie-Mellon University does not
formalize semantics, but does have a semi-formal framework for machine description.
Compiler-compilers exist in many flavors, including bottom-up rewrite machine generators
(see JBurg) used to tile syntax trees according to a rewrite grammar for code generation,
 SAZ::2019
and attribute grammar parser generators (e.g. ANTLR can be used for simultaneous type
checking, constant propagation, and more during the parsing stage).
Metacompilers
Metacompiler metalanguages are powerful string and symbol processing languages that are
also useful for generating a wide range of other software engineering and analysis tools.[4][7]
Besides being useful for domain-specific language development, a metacompiler is itself a
prime example of a domain-specific language, designed for the domain of compiler writing.
A metacompiler is a metaprogram usually written in its own metalanguage or an existing
computer programming language. The process of a metacompiler, written in its own
metalanguage, compiling itself is equivalent to self-hosting compiler. Most common
compilers written today are Self-hosting compilers. Self-hosting is a powerful tool, of many
metacompilers, allowing the easy extension of their own metaprogramming metalanguage.
The feature that separates a metacompiler apart from other compiler compilers is that it takes
as input a specialized metaprogramming language that describes all aspects of the compilers
operation. A metaprogram produced by a metacompiler is as complete a program as
a program written in C++, BASIC or any other general programming language.
The metaprogramming metalanguage is a powerful attribute allowing the ease of
development of computer programming languages and other computer tools. Command line
processors, text string transforming and analysis are easily coded using metaprogramming
metalanguages of metacompilers.
A full featured development package includes a linker and a run-time support library.
Usually a machine oriented language is required for writing the support library. C or C++
could be used as a machine oriented language. A library consisting of support functions
required for the compilation process usually rounds out the full metacompiler package.
FORTH metacompiler
Many Forth advocates call the process of creating a new implementation of Forth a meta-
compilation and that it constitutes a metacompiler. The FORTH definition of metacompiler
is:
"A metacompiler is a compiler which processes its own source code, resulting in an
executable version of itself."
This Forth use of metacompiler is disputed in mainstream computer science. See Forth
(programming language) and History of compiler construction. The actual Forth process
of compiling itself is a combination of a Forth being a Self-hosting Extensible
programming language and sometimes Cross compilation, long established terminology
in computer science. Metacompilers are a general compiler writing system. Besides the
FORTH metacompiler concept being indistinguishable from self-hosting and extensible
language. The actual process acts at a lower level defining a minimum subset of forth
 SAZ::2019
words, that can be used to define additional forth words, A full FORTH implementation
can then be defined from the base set. This sounds like a bootstrap process. The problem
is that almost every general purpose language compiler also fits the FORTH
metacompiler description.
When (self-hosting compiler) X processes its own source code, resulting in an
executable version of itself, X is a metacompiler.
Just replace X with any common language, C, C++, Pascal, COBOL, FORTRAN,
Ada, Modula-2, etc. And X would be a meta compiler according to the FORTH usage
of metacompiler. A metacompiler operates at an abstraction level above the compiler
it compiles. It only operates at the same (self-hosting compiler)level when compiling
itself. One has to see the problem with this definition of metacompiler. It can be
applied to most any language.
However, on examining the concept of programming in FORTH, adding new words
to the dictionary, extending the language in this way is metaprogramming. It is this
metaprogramming in forth that makes it a metacompiler.
Programming in FORTH is adding new words to the language. Changing the language
in this way is metaprogramming. FORTH is a metacompiler because FORTH is a
language specifically designed for metaprogramming.[3] Programming in FORTH is
extending FORTH adding WORDS to the forth vocabulary creates a new
FORTH dialect. FORTH is a specialized metacompiler for FORTH language dialects.

History
The first compiler-compiler to use that name was written by Tony Brooker in 1960 and was
used to create compilers for the Atlas computer at the University of Manchester, including
the Atlas Autocode compiler.
The early history of metacompilers is closely tied with the history of SIG/PLAN Working
group 1 on Syntax Driven Compilers. The group was started primarily through the effort of
Howard Metcalfe in the Los Angeles area.[8] In the fall of 1962 Howard Metcalfe designed
two compiler-writing interpreters. One used a bottom-to-top analysis technique based on a
method described by Ledley and Wilson.[9] The other used a top-to-bottom approach based
on a work by glennie to generate random English sentences from a context-free grammar.[10]
At the same time, Val Schorre described two "meta machines". One generative and one
analytic. The generative machine was implemented and produced random algebraic
expressions. Meta I the first metacompiler was implemented by Schorre on an IBM 1401 at
UCLA in January 1963. His original interpreters and metamachines were written directly in a
pseudo-machine language. Meta II, however, was written in a higher-level metalanguage
able to describe its own compilation into the pseudo-machine language.[11][12][13]
 SAZ::2019
Lee Schmidt at Bolt, Beranek, and Newman wrote a metacompiler in March 1963 that
utilized a CRT display on the time-sharing PDP-l.[14] This compiler produced actual machine
code rather than interpretive code and was partially bootstrapped from Meta I.
Schorre bootstrapped Meta II from Meta I during the Spring of 1963. The paper on the
refined metacompiler system presented at the 1964 Philadelphia ACM conference is the first
paper on a metacompiler available as a general reference. The syntax and implementation
technique of Schorre's system laid the foundation for most of the systems that followed. The
system was implemented on a small 1401, and was used to implement a small ALGOL-like
language.
Many similar systems immediately followed.
Roger Rutman of A. C. Sparkplug developed and implemented LOGIK, a language for
logical design simulation, on the IBM 7090 in January 1964.[15] This compiler used an
algorithm that produced efficient code for Boolean expressions.
Another paper in the 1964 ACM proceedings describes Meta III, developed
by Schneider and Johnson at UCLA for the IBM 7090.[16] Meta III represents an attempt to
produce efficient machine code, for a large class of languages. Meta III was implemented
completely in assembly language. Two compilers were written in Meta III, CODOL, a
compiler-writing demonstration compiler, and PUREGOL, a dialect of ALGOL 60. (It was
pure gall to call it ALGOL).
Late in 1964, Lee Schmidt bootstrapped the metacompiler EQGEN, from the PDP-l to the
Beckman 420. EQGEN was a logic equation generating language.
In 1964, System Development Corporation began a major effort in the development of
metacompilers. This effort includes powerful metacompilers, Bookl, and Book2 written in
LISP which have extensive tree-searching and backup capability. An outgrowth of one of
the Q-32 systems at SDC is Meta 5.[17] The Meta 5 system incorporates backup of the input
stream and enough other facilities to parse any context-sensitive language. This system was
successfully released to a wide number of users and had many string-manipulation
applications other than compiling. It has many elaborate push-down stacks, attribute setting
and testing facilities, and output mechanisms. The fact that Meta 5 successfully translates
JOVIAL programs to PL/l programs clearly demonstrates its power and flexibility.
The LOT system was developed during 1966 at Stanford Research Institute and was modeled
very closely after Meta II.[18] It had new special-purpose constructs allowing it to generate a
compiler which would in turn be able to compile a subset of PL/l. This system had extensive
statistic-gathering facilities and was used to study the characteristics of top-down analysis.
 SAZ::2019
SIMPLE is a specialized translator system designed to aid the writing of pre-processors for
PL/I, SIMPLE, written in PL/I, is composed of three components: An executive, a syntax
analyzer and a semantic constructor.[19]
The TREE META compiler was developed at Stanford Research Institute in Menlo Park,
California. April 1968. The early metacompiler history is well documented in the TREE
META manual. TREE META paralleled some of the SDC developments. Unlike earlier
metacompilers it separated the semantics processing from the syntax processing. The syntax
rules contained tree building operations that combined recognized language elements with
tree nodes. The tree structure representation of the input was then processed by a simple
form of unparse rules. The unparse rules used node recognition and attribute testing that
when matched resulted in the associated action being performed. In addition like tree
element could also be tested in an unparse rule. Unparse rules were also a recursive language
being able to call unparse rules passing elements of thee tree before the action of the unparse
rule was performed.
The concept of the metarnachine originally put forth by Glennie is so simple that three
hardware versions have been designed and one actually implemented. The latter at
Washington University in St. Louis. This machine was built from macro-modular
components and has for instructions the codes described by Schorre.
CWIC (Compiler for Writing and Implementing Compilers) is the last known Schorre
metacompiler. It was developed at Systems Development Corporation by Erwin Book,
Dewey Val Schorre and Steven J. Sherman With the full power of (lisp 2) a list processing
language optimizing algorithms could operate on syntax generated lists and trees before code
generation. CWIC also had a symbol table built into the language.
With the resurgence of domain-specific languages and the need for parser generators which
are easy to use, easy to understand, and easy to maintain, metacompilers are becoming a
valuable tool for advanced software engineering projects.
Other examples of parser generators in the yacc vein are ANTLR, Coco/R, CUP,[citation
needed]
GNU bison, Eli,[20] FSL,[citation needed] SableCC, SID (Syntax Improving
Device),[21] and JavaCC. While useful, pure parser generators only address the parsing part
of the problem of building a compiler. Tools with broader scope, such
as PQCC, Coco/R and DMS Software Reengineering Toolkit provide considerable support
for more difficult post-parsing activities such as semantic analysis, code optimization and
generation.