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

Eli System Administration Guide

Examples of Package Use

Each example uses a cache directory with an explicit name given by a -c parameter. If you don't generally work on more than one project at a time, then you may wish to omit the -c parameter and use the same cache for every project (see Name of the cache).

All of these examples assume that you have installed eli in directory `/opt/eli' (see Installing Eli).

Using a single additional package

The Eli packages understand LALR(1) grammars and how to use them to generate deterministic parsers. Unfortunately, some languages are very difficult to describe using such grammars.

A package named bisonglr is available from the Eli web site. It uses the Bison parser generator's "GLR" facility to create parsers for grammars that cannot easily be rewritten to make them LALR(1). This package assumes that you have the Bison parser generator available in your path, under the name bison. No change in specifications is required; the package handles all of the necessary translations and integration.

Suppose that you have downloaded the bisonglr package and unpacked it to your home directory. Then the following command builds a cache called GLRCACHE in your home directory. Assuming that $ODINPATH is empty, GLRCACHE is built from the bisonglr package plus the standard Eli and Odin packages (see Packages in the cache).

eli -c $HOME/GLRCACHE -R -p $HOME/bisonglr

Note that absolute path names are used for both the cache directory and the package directory.

If you frequently worked on languages whose grammars required the bisonglr package, you could add it to the Eli package library by making the request:

-> $HOME/bisonglr +d_dest=(/opt/eli/lib/Eli) :installpkg

After making this request, the next time you build a cache the standard Eli packages will include bisonglr.

Maintaining distributed packages

The text for the Eli system is kept in a CVS repository. For the purposes of this example, assume that you have checked out a copy of the distribution directory `Elidistrib'. The name of your working directory will therefore be `Elidistrib'. The directory containing the standard Eli package collection is then `Elidistrib/Eli/pkg', and the directory containing the standard Odin package collection is `Elidistrib/Odin/pkg'.

You will use your working directory to develop and test changes to the standard packages, ultimately checking in the final version. During the development process, you want to run Eli with certain package directories from your working directory substituted for the corresponding directories in `/opt/eli'.

For example, suppose that your working directory is a subdirectory of your home directory and you need to debug the gla package. The following command will build the cache `DBGCACHE' in which the gla package from your working directory takes the place of the standard gla package:

eli -c $HOME/DBGCACHE -R -p $HOME/Elidistrib/Eli/pkg/gla

If you need to work on several packages at once, a good strategy is to create a new package collection directory and populate it with symbolic links to package directories in your working directory:

mkdir $HOME/pkg
ln -s $HOME/Elidistrib/Eli/pkg/gla    $HOME/pkg
ln -s $HOME/Elidistrib/Eli/pkg/parser $HOME/pkg
ln -s $HOME/Elidistrib/Eli/pkg/pgs    $HOME/pkg
...

You then put the names of the packages you want to work on into `$HOME/pkg/PKGLST' and build the debug cache with the following command:

eli -c $HOME/DBGCACHE -R -p $HOME/pkg

Once you have finished debugging, you can leave the `pkg' directory with its symbolic links in place. When you need to debug other packages, you add any new links and edit `PKGLST' to name the packages on which you want to work. Links to currently-uninteresting packages remain for future debugging sessions, but because their names are not listed in `PKGLST' they are ignored.

Developing additional packages

A package being developed requires a package directory. It is often useful to make that directory a subdirectory of the `$HOME/pkg' directory (see Maintaining distributed packages). It can then be used either singly or in combination with other packages being debugged.

All of the additional packages developed to date are kept in the Packages directory of the CVS repository. If you are developing an additional package for Eli, you might decide to check out the Packages directory and develop your package in a subdirectory of the resulting working directory. This is generally not a good idea. The reason is that you will ultimately want to use a CVS import command to add your package to the repository. That command expects a directory distinct from your working directory. A subsequent checkout with the -d parameter will add the imported directory to your working directory. If the package directory that you developed is a subdirectory of your working directory, it will have to be moved before the checkout takes place. Thus it is better develop the package in a directory (such as `$HOME/pkg') that is disjoint from your working directory.