The Compiler-Front
library is repsonsible for processing the Front
End Representation of a
Dylan
™
program. It depends only
on the Compiler-Base
library.
Data is passed from the Compiler-Parser
library to the Compiler-Front
library by the
Compiler-Convert
library.
This module defines an interface which can be used to build the front-end representation (FER) of a parsed Dylan ™ program.
Note that this module actually defines two interfaces:
<flow-builder>, an abstract interface for
constructing basic blocks (see the section called “The Flow Module”); and
<fer-builder>, a more specific version of that
interface which is used to construct the front-end
representation. It's not apparent that the former, more general
interface is actually used anywhere else.
This interface is implemented by the Front
module.
The optimize-component generic function gets
implemented by the Compiler-Optimize
library. We need to figure out why it's
defined here instead of there.
This module defines the primitive operations which may appear in Dylan ™ code.
This module does all the heavy lifting for the front-end of the compiler. It's split across a number of source files:
front.dylan
The data structures used in the front-end
representation. These extend the classes defined in the Flow
module.
builder.dylanAbstract classes and generic functions for the
<flow-builder> and
<fer-builder> classes.
fer-builder.dylanThe actual implementation of the various builders. This seems to be where the actual front-end code lives.
fer-dump.dylanCode for dumping the front-end representation as text.
clone.dylanCode to clone the data structures representing a top-level function. This seems to be used when inlining functions.
To add a new class to the FER hiearchy,
you'll need to add code to the following files:
front.dylan,
fer-dump.dylan,
clone.dylan,
fer-od.dylan and
base/od-format.dylan. If you miss any of these
spots, things will break in various entertaining ways.
This module contains code for dumping the front-end
representation as ODF (see the section called “OD-Format Module”). Special case is taken to
make sure that all dumps start with a
<function-literal> object; smaller
components of the front-end representation can not be dumped
individually.
This module implements various subclasses of
<definition> representing functions (see the section called “The Definitions Module”). Most of the machinery for
adding methods to a generic function at compile-time lives here, as
does a good chunk of code related to sealing.
This module implements <variable-definition>.
It also contains some of the code for handling load-time type
expressions.
This is not a very meaty module. It doesn't make much sense
in the absence of the Compiler-Convert
library. It does, however, contain a
few classes for describing the things found at the top level of a
Dylan
™
file and provides the generic function
finalize-top-level-form, which is called by the
compilation driver once everything has been parsed.
This should not be confused with the
Top-Level-Expressions module, which
instantiates the data structures defined in this module.