Eli   Documents
Eli: Translator Construction Made Easy

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

Eli User Interface Reference Manual

Next Chapter Table of Contents

Referring to Objects

The objects in Eli's universe are divided into two classes, source objects and derived objects. Source objects are owned by the user of Eli, and may be manipulated in any way. Derived objects are owned by Eli; the user may inspect them or obtain copies of them on request, but has no direct access to them and cannot change them. Each derived object can be manufactured from some set of source objects, and therefore does not represent any new information.

Every object has a name. The name of a source object is its Unix file name and the name of a derived object is an odin-expression. The remainder of this chapter explains the form and meaning of an odin-expression.

Eli splits each file name into two parts: a root and a type-name. The type-name is the longest suffix of the file name that matches one of the declared source type suffixes. If no suffix match is found, the type-name is the empty string.

Lexical Conventions

Lexically, an odin-expression consists of a sequence of identifier and operator tokens terminated by a newline character. An odin-expression can be continued on multiple lines by escaping each newline character with a backslash. This backslash (but not the newline) is deleted before the expression is parsed. Multiple odin-expressions can be specified on the same line by separating them with semicolons.

An identifier token is just a sequence of characters. The following characters must be escaped to be included in an identifier: 

: + = ( ) / % ; ? $ < > ! <space> <tab> <newline> # \ '

A single character can be escaped by preceding it with a backslash (e.g. lost\+found). A sequence of characters can be escaped by enclosing them in apostrophes (e.g. 'lost+found').

Unescaped white space characters (spaces, tabs, and newlines) are ignored during parsing except when they separate adjacent identifiers. A comment begins with a sharp and is terminated by the next newline character: 

# this is a comment

Each comment is equivalent to white space.

An odin-expression can be surrounded by parentheses. Parentheses are required for nested odin-expressions (such as values of parameters) or for the empty expression () which represents an immutable empty file.

Selection Expressions

A selection expression, indicated by the slash operator, selects a file from a directory. The argument to the slash operator is the file name of the desired file. For example, the following odin-expression selects prog.c from the directory src: 

src/prog.c

Any special character must be escaped. For example, src/c++/prog.c must be escaped, as in src/c\+\+/prog.c or 'src/c++/prog.c'.

Derivation Expressions

A derivation expression, indicated by the colon operator, is used to specify a derived object. The argument to the colon operator is an object type (or product) (see Top of Products and Parameters): 

sets.specs :exe
sets.specs :source :names

The first line names the executable program derived from the specifications enumerated in file `sets.specs', while the second names a text file containing the names of the C files, header files and Makefile from which that program can be built.

A derived object can be a directory, in which case it is called a derived directory. Elements of a derived directory are selected with the same slash operator used to select elements of source directories. For example, if examples/sets.specs:source is a derived directory containing the source code files that implement a text processor, and this directory contains three files named `Makefile', `driver.c', and `HEAD.h', then these three files are named by the odin-expressions: 

examples/sets.specs:source/Makefile
examples/sets.specs:source/driver.c
examples/sets.specs:source/HEAD.h

Parameterization Expressions

A parameterization expression, indicated by the + operator, extends an object with additional information that affects the derived objects produced from that object. The argument to the + operator is a parameter type (see Top of Products and Parameters), optionally followed by an = operator and a value consisting of a sequence of one or more identifiers and parenthesized odin-expressions: 

test +cmd=(sets.specs +fold :exe) +cmd=data :run
test +cmd=(sets.specs +fold :exe) data :run
test +cmd=(sets.specs +fold=' ' :exe) data :run
test +cmd=(sets.specs +fold :exe) +cmd=data +cmd=data :run

(We shall see that all of these lines are equivalent.)

If the parameter value is omitted, it is equivalent to specifying the identifier consisting of a single space ' ' as the value.

The parameter values of a given parameter type in an odin-expression form an ordered set, where the order of the values is the order specified in the odin-expression. If multiple copies of the same parameter value appear, only the first of the multiple copies is kept. The parameter value lists of each parameter type are disjoint, therefore, the order of parameters of different types is not significant.

If a parameter has a value that is a sequence, that value is only considered the same as another identical sequence. Thus the following odin-expression is not equivalent to those given above: 

test +cmd=(sets.specs +fold :exe) data +cmd=data :run

Although data is an element of the parameter value list for parameter type cmd, it was introduced as part of a sequence. Its second appearance is as a single value, which is not equivalent to the previous sequence. Therefore it will not be considered a duplicate element, and the final list will be (sets.specs +fold :exe) data data.

Frequently, several odin-expressions share a common set of parameters. To support this kind of sharing, a parameterization expression can take the form of a + followed by a parenthesized odin-expression. The common set of parameters are then stored in the file named by the odin-expression. For example, suppose the file `my.prms' contained the text: 

+debug +lib_sp=(/local/lib) +monitor +fold

The odin-expression my.prms denotes the file `my.prms' in the current directory, so the following odin-expressions would be equivalent: 

sets.specs +(my.prms) :exe
sets.specs +debug +lib_sp=(/local/lib) +monitor +fold :exe

Next Chapter Table of Contents