Eli   Documents Get Eli: Translator Construction Made Easy at SourceForge.net.
    Fast, secure and Free Open Source software downloads

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 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

Products and Parameters Reference

Next Chapter Table of Contents


Processor Generation

Eli's task is to create a text processor that implements a set of specifications. Two forms of that processor can be extracted from Eli: an executable form and a source form. The processor can also be tested without extracting it from Eli (see Testing a Generated Processor). Regardless of the ultimate disposition of the processor, its behavior can be influenced in a number of ways by parameters.

exe -- Executable Version of the Processor

:exe

A binary file containing the executable program generated from the given specifications. During specification development, :exe is used as a means of collecting error reports (see help -- Cross-Reference to Documentation):

pascal.specs:exe:help

When this derivation yields an empty result, indicating that no errors were detected in the specifications, the generated processor can be tested by requesting the stdout (see stdout -- Standard Output from Processor Execution), output (see output -- Files Resulting from Processor Execution), dbx, gdb (see Debugging -- Debug a Program Interactively at the Source Level), mon, mongdb (see Monitoring -- Monitor a program at the specification level) or run (see run -- Execute the Processor in the Current Directory) products. After testing has been completed, exe can be used to extract the executable processor from the cache for use in arbitrary contexts:

pascal.specs:exe>pc

so -- Shared library Version of the Processor

:so

A shared library containing the executable program generated from the given specifications. Shared libraries do not usually contain a main program, and therefore :so is almost always derived using the +nomain parameter (see nomain -- Omitting the main program).

source -- Source Version of the Processor

:source

A directory containing the source language files and header files necessary to construct the generated processor. This directory is completely self-contained, unless a library specification was given by the user. All Eli library routines used are included in source form. There is also a makefile, so an executable processor can be constructed by entering the directory and giving the command make.

To extract the directory from the cache, use the following Eli request:

pascal.specs:source>dir

Here dir is the name of an existing directory. The directory may or may not be empty. If it is empty, Eli will copy all of the files needed to construct the processor (except user-specified libraries) from the cache to dir. Otherwise, Eli will copy only those files that differ from the files with the same name in dir. This means that if you alter the specifications for the processor and then request a new source directory, only the files actually affected by your specification change will be updated. Therefore if you run make in dir, unaltered routines will not be recompiled.

fwGen -- Obtain the Product Files Generated by FunnelWeb

:fwGen

A directory containing the files generated by the FunnelWeb "tangle" phase. See Output Files of FunnelWeb User's Manual. This derivation can only be applied to type-fw files. The resulting directory will contain all files generated by @O macros in the FunnelWeb file. For example, to generate the "tangled" files from the file `pascal.fw', use the following Eli request:

pascal.fw:fwGen>dir
Here dir is the name of an existing directory.

fold -- Make the Processor Case-Insensitive

+fold

Eli normally produces a compiler that treats upper and lower case letters as distinct characters in identifiers and keywords. If fold is used, implementation of the processor mkidn is altered so that it treats the upper and lower case versions of a letter as being identical.

The fold causes all identifiers to be stored in their upper-case form. When an identifier is output, therefore, it will appear in upper case regardless of its representation in the input text.

define -- Set C Pre-Processor Symbols

+define='item …'

All C compilations required by the derivation will be provided with flag -Ditem for each item in the argument. An item is any sequence of non-white-space characters other than apostrophes. Items are separated by white space. Any number of items may be specified.

The following items are pre-defined:

STOPAFTERBADPARSE
Generate a processor that will terminate after parsing if syntax errors are detected (see Improving Error Recovery in the Generated Parser of Syntactic Analysis).

cc_flags -- Set C Compiler Options

+cc_flags=flag

All C compilations required by the derivation will be provided with each flag in the argument. A flag is any sequence of non-white-space characters, possibly enclosed in apostrophes. Flags are separated by white space. Any number of flags may be specified.

This parameter is often used to specify include files for components that are not generated by Eli. For example:

+cc_flags='-I/opt/icedtea-bin-6.1.11.1/include'

cc -- Choose a Particular C Compiler

+cc=command

All C compilations required by the derivation will be carried out by executing the command command.

ignore -- Do Not Verify include Files

+ignore='path'

Eli normally verifies the presence of files requested by #include directives in any file that it processes. The ignore parameter tells Eli not to verify the presence of such files if their full names begin with path.

If a derivation does not specify any ignore parameters, +ignore='/usr/include' is assumed. (This assumption is not made if any ignore parameters are given explicitly.)

parser -- Choose the parser generator

+parser
+parser=pgs
+parser=cola
+parser=none

Eli incorporates two parser generators, PGS and COLA. Both produce parsers from LALR(1) grammars, and the parsers they produce recover automatically from syntactic errors. A PGS-generated parser does not reduce by chain productions. This means that it accepts some grammars that are not LALR(1), and the generated parser is faster than a COLA-generated parser for languages with many precedence levels in expressions. Parsers generated by COLA include more information in error messages about expected tokens than those generated by PGS do.

The error reports provided by the two parser generators differ somewhat, and it is sometimes useful to try the other generator when one produces a message you don't understand. Remember, however, that PGS accepts a wider class of grammars. Thus COLA may report errors for a grammar and PGS may not.

One of the two parser generators is selected as the default at the time the Eli system is generated. The default parser generator will be used if the parser parameter is absent. A request specifying +parser only will cause the non-default parser generator to be used. Specifying +parser=pgs will cause PGS to be used, while specifying +parser=cola will cause COLA to be used.

The default parser generator can be changed by changing the shell scripts `parserOut.sh', `bnfOut.sh' and `infoOut.sh' in directory `$elipkg/parser'.

Sometimes it is desirable to not have a generated parser. For example, the user may be building a tree for attribution using hand-written code or code produced by an application external to Eli. Specifying +parser=none will cause Eli not to generate a parser.

nomain -- Omitting the main program

+nomain

Normally Eli generates a main program that invokes the generated components in an appropriate order. Sometimes the user wants to have more control by providing their own main program. In this situation +nomain should be specified to omit the standard Eli main program.


Next Chapter Table of Contents