General Information

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

Tutorials

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

Reference Manuals

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

Libraries

	Eli library routines
	Specification Module Library

Translation Tasks

	Lexical analysis specification
	Syntactic Analysis Manual
	Computation in Trees

Tools

	LIGA Control Language
	Debugging Information for LIDO
	Graphical ORder TOol

FunnelWeb User's Manual

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

Generating Unparsing Code

Monitoring a Processor's Execution

Administration

System Administration Guide

Products and Parameters Reference

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.