Compiler-Front
libraryThe 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.
Builder-Interface
ModuleThis 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.
Front
ModuleThis module does all the heavy lifting for the front-end of the compiler. It's split across a number of source files:
The data structures used in the front-end
representation. These extend the classes defined in the Flow
module.
Abstract classes and generic functions for the
<flow-builder>
and
<fer-builder>
classes.
The actual implementation of the various builders. This seems to be where the actual front-end code lives.
Code for dumping the front-end representation as text.
Code 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.
FER-OD
ModuleThis module contains code for dumping the front-end
representation as ODF (see the Section called The 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.
Function-Definitions
ModuleThis 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.
Variable-Definitions
ModuleThis module implements <variable-definition>
.
It also contains some of the code for handling load-time type
expressions.
Top-Level-Forms
ModuleThis 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.