Eli   Documents

General Information

 o Eli: Translator Construction Made Easy
 o Global Index
 o Frequently Asked Questions
 o Typical Eli Usage Errors

Tutorials

 o Quick Reference Card
 o Guide For new Eli Users
 o Release Notes of Eli
 o Tutorial on Name Analysis
 o Tutorial on Scope Graphs
 o Tutorial on Type Analysis
 o Typical Eli Usage Errors

Reference Manuals

 o User Interface
 o Eli products and parameters
 o LIDO Reference Manual
 o Typical Eli Usage Errors

Libraries

 o Eli library routines
 o Specification Module Library

Translation Tasks

 o Lexical analysis specification
 o Syntactic Analysis Manual
 o Computation in Trees

Tools

 o LIGA Control Language
 o Debugging Information for LIDO
 o Graphical ORder TOol

 o FunnelWeb User's Manual

 o Pattern-based Text Generator
 o Property Definition Language
 o Operator Identification Language
 o Tree Grammar Specification Language
 o Command Line Processing
 o COLA Options Reference Manual

 o Generating Unparsing Code

 o Monitoring a Processor's Execution

Administration

 o System Administration Guide

Mail Home

Library Reference

Next Chapter Table of Contents


Using Frame Modules

The library modules described in this manual are implemented directly in C. These modules may export constants, variables and routines to their clients. To reduce overhead, these modules have been pre-compiled and stored in the frame. Frame modules need not be instantiated, although it is allowable to do so. A frame module will be incorporated into a specification whenever anything exported by that module is used in the specification. If a frame module is instantiated by a specification, however, it will be included regardless of whether any exported facilities are used. In either case, source code for the module is included in the source product. See Source Version of the Processor of pp.

Each module is associated with a header file that specifies the interface it presents to its clients. Any module requiring access to the exports of another module must include the header file associated with the exporting module.

Library header files are written according to certain conventions. We recommend strongly that you follow the same conventions when defining code modules to carry out tasks specific to your problem. Your header files will be included in generated modules, and Eli will make the same assumptions about them that it does about header files from the library. Failure to follow these conventions may result in errors when the generated programs are compiled. Since you will not recognize the generated programs, such errors may be difficult to diagnose.

Conventions for writing interfaces

By convention, every header file is complete: Including a module's header file in a C program provides all of the information needed to use that module. For example, the environment module exports operations that deliver definition table keys as their results. In order to use the environment module, therefore, a client must have access to the interface of the definition table module. Our convention therefore requires that the header file for the environment module include the header file for the definition table module. If the environment module header file did not include the definition table module header file, a C program that included that included the environment module header file would not necessarily have all of the information needed to use the environment module.

This convention greatly simplifies decisions about which header files to include, and avoids all questions of the order in which header files should be included. It does, however, require that each header file be protected against multiple inclusion. Protection is provided by defining a symbol in each header file and skipping the entire contents if that symbol is already defined. The symbol is the name of the header file, given as upper-case characters with any periods replaced by underscores.

Example of a header file

Here is an excerpt from `envmod.h', the header file for the environment module:

#ifndef ENVMOD_H
#define ENVMOD_H

#include "deftbl.h"

typedef struct EnvImpl *Environment;    /* Set of Identifier/Definition pairs */

...

/***/
#if defined(__cplusplus) || defined(__STDC__)
extern DefTableKey DefineIdn(Environment env, int idn);
#else
extern DefTableKey DefineIdn();
#endif
/* Define an identifier in a scope
 *    If idn is defined in env then on exit-
 *       DefineIdn=key for idn in env
 *    Else let n be a previously-unused definition table key
 *    Then on exit-
 *       DefineIdn=n
 *       idn is defined in env with the key n
 ***/

...

#endif

Protection against multiple inclusion is provided by the test of ENVMOD_H. DefineIdn returns a definition table key, so the completeness convention requires that `deftbl.h' (the definition table module interface) be included. Environment is a type exported by the environment module, and it is defined in this interface.


Next Chapter Table of Contents