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

New Features of Eli Version 4.1

Next Chapter Table of Contents

LIDO Language and Liga System

The modifications of the Lido language and the Liga system refer to the following topics: The use of symbol computations is further simplified by removal of certain restrictions, and by introduction of some new constructs. Some restrictions on bottom-up evaluation are removed. A mechanism has been installed such that messages given by the C compiler on the generated evaluator are related back to the Lido text.

None of the modifications invalidates existing Lido specifications.

For complete descriptions of the modified constructs see the Liga documentation: See LIDO -- Reference Manual. See LIDO - Computation in Trees.

CONSTITUENTS Restrictions Removed

If a symbol computation contains a CONSTITUENTS construct, like 

  CLASS SYMBOL CS COMPUTE
    SYNT.c = f (CONSTITUENTS X.a WITH (t, f2, f1, f0));
  END;
it was not allowed to inherit CS to a symbol that has a production with an empty right-hand side. It was also a violation if X were a CLASS symbol that is not inherited to any symbol. This was sometimes annoying, especially when using library modules.

Both restrictions have been removed. The result of the CONSTITUENTS is in such cases the result of the f0-function. A VOID CONSTITUENTS is replaced by nothing in such cases.

See CONSTITUENT(S) of LIDO -- Reference Manual.

CHAIN in Empty Rules

It was a violation if a computation containing a TAIL chain access is inherited to a symbol that has a production with an empty right-hand side. A HEAD computation was dropped in such cases. This was sometimes annoying, especially when using library modules. This restriction has been removed.

Now, if a computation that contains a CHAINSTART, HEAD, or TAIL is inherited to a rule with an empty right-hand side, its effect is as if there was a symbol on the right-hand side that passes the chain unchanged.

See CHAIN of LIDO -- Reference Manual.

Grammar Root Symbol

The 

  CLASS SYMBOL ROOTCLASS END;
is predefined without any computation. It is inherited to the particular root symbol of the tree grammar.

This facility is especially useful for writing grammar independent modules which need to associate computations to the grammar root. Module users then do not need to explicitly inherit a root role.

See Predefined Entities of LIDO -- Reference Manual.

Right-Hand Side Access

The entities TermFct, RhsFct, and RULENAME are predefined to simplify symbol computations that access the right-hand side of rules they are inherited to.

See Predefined Entities of LIDO -- Reference Manual.

A function TermFct is predefined to be used for systematic access of terminal values in computations. It is intended to be used in computations of CLASS SYMBOLs: 

  CLASS SYMBOL LeafNode COMPUTE
    SYNT.Ptg = TermFct ("ToPtg", TERM);
  END;
  SYMBOL LiteralExpr INHERITS LeafNode END;

If there were the following two rules for LiteralExpr that derive to different terminals, then the above computation is expanded as shown below: 

  RULE: LiteralExpr ::= IntNumber COMPUTE
    LiteralExpr.Ptg = ToPtgIntNumber (IntNumber);
  END;
  RULE: LiteralExpr ::= FloatNumber COMPUTE
    LiteralExpr.Ptg = ToPtgFloatNumber (FloatNumber);
  END;
Suitable functions have to be defined for the calls constructed by prefixing the terminal name with the string given in the TermFct call.

A call of the predefined function RhsFct (C_String, arguments ...) is substituted by a call of a function whose name is composed of the C_String and and two numbers that indicate how many nonterminals and terminals are on the right-hand side of the rule that has (or inherits) this call. The remaining arguments are taken as arguments of the substituted call. E.g. in a rule RULE: X ::= Id Y Id Z Id END;, where Y, Z are nonterminals, and Id is a terminal, a call RhsFct ("PTGChoice", a, b) is substituted by PTGChoice_2_3 (a, b). Usually, RhsFct will be used in symbol computations, having arguments that are obtained by the RHS construct and by a TermFct call.

RULENAME can be used in computations. It is replaced by the rule name as a string literal.

Bottom-up Evaluation

Liga's strategy for scheduling BOTTOMUP computations has been changed: The generated evaluator performs computations during the tree construction phase if and only if there are some computations marked BOTTOMUP.

See Computations of LIDO -- Reference Manual.

Requesting BOTTOM_UP or TREE_COMPLETE in a .ctl file is now unnecessary and meaningless.

See Order Options of LIGA - Control Language.

Attributes are computed during the tree construction phase only if they are needed for BOTTOMUP computations. That strategy reduces the size of the tree in general.

Information about the results of Liga's analysis for BOTTOMUP can be obtained by deriving OrdInfo.

The restrictions on BOTTOMUP computations have been relaxed: The facility of subtrees being built by computations may be used together with some other computations being marked BOTTOMUP, unless computations in such generated subtrees are preconditions for BOTTOMUP computations.

Furthermore, chain productions may be introduced into the tree grammar, if necessary, without having corresponding chain productions in the concrete grammar, as long as they are not involved in BOTTOMUP computations. This situation is automatically checked in cooperation between Liga and the Maptool.

Next Chapter Table of Contents