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

New Features of Eli4.0

Previous Chapter Next Chapter Table of Contents


Lido News for Eli 4.0

Terminals

In previous LIDO versions non-literal terminals were considered to be symbols that may have attributes - several inherited attributes and at most one that is supplied when the node is constructed. Hence, non-literal terminals may have upper symbol computations, and their attributes may be used in adjacent and in remote contexts.

In the new LIDO version a non-literal terminal, like Ident in a rule

   RULE decl: Declaration ::= Ident ':' Type END;

may supply a value to computations associated to the RULE context. That value usually describes a property of the corresponding input token, e. g. the encoding of an identifier determined by the scanner and passed through by the parser.

The type of the value supplied by a non-literal terminal is specified by a terminal specification like

   TERM Ident : int;

The above construct can be omitted if the type is int, i.e. in all cases where the terminal is provided by an Eli generated scanner. Types other than int may occur if tree nodes are created by explicit computations.

The value of a non-literal terminal of a certain context can be used in computations associated to that context, e. g.

   Declaration.Key = DefineIdn (INCLUDING Root.Env, Ident);

There the name of the non-literal terminal stands for its value. If there are several occurrences of a non-literal terminal in a production, their values are distinguished by indexing their names, e. g. Ident[1], Ident[2], ...

The values of non-literal terminals may also be used in symbol computations. There the notation is TERM, TERM[1], TERM[2], ..., e. g. in

   SYMBOL Use COMPUTE
      SYNT.Key = KeyInEnv (INCLUDING Root.Env, TERM);
   END;

In order not to immediatly invalidate existing specifications LIGA still accepts most uses of old style terminals and internally transforms them into new style terminals.

TRANSFER

The TRANSFER construct provided by former LIDO versions is no longer available.

Separators

The new LIDO version requires semicolons (';') to terminate RULE and SYMBOL specifications and computations. In previous versions of LIDO the ';' after the last specification or computations could be ommited.

Bottom-Up Evaluation

If computations are to be executed while the input is read they are now to be marked BOTTOM_UP, e.g.

        printf ("immediate reply\n") BOTTOM_UP;
instead of using a LIGAPragma.

Bottom-Up attribute evaluation, i.e. attribute computations during abstract structure tree construction ("parse-time") is no-longer the default strategy used in Eli. To switch to Bottom-Up evaluation it has to be activated in an .ctl specification (ORDER: TREE BOTTOM_UP), See Order Options of LCL - Liga Control Language, or requested by a BOTTOM_UP specifier in LIDO See Computations of LIDO - Reference Manual.

CLASS and TREE SYMBOLS

Symbols that describe computational roles (e.g. RangeScope) are now explicitly distinguished from tree grammar symbols by using the keyword CLASS before SYMBOL, e.g.

   CLASS SYMBOL RangeScope COMPUTE ... END;

Symbols that occur in the tree grammar (tree symbols) are specified as TREE SYMBOLS:

   TREE SYMBOL expr COMPUTE ... END;

With this extension Liga can then check whether incidentally the name of a tree grammar symbol coincides with a CLASS symbol, that may be obtained from a library module.

Liga will issue warning messages if there is an INHERITS from a tree grammar symbol, or if a CLASS symbol is also a tree grammar symbol. For upward compatibility symbol specifications without TREE or CLASS prefix are still supported.

LIGAPragma

The LIGAPragma notation of former versions has been substituted by simpler notations (see Outdated constructs of LIDO - Reference Manual).

Terminals in LISTOF productions

In previous LIDO versions terminals were allowed to be used as LISTOF elements, e.g.:

   RULE: Idents LISTOF Identifier

This facility is not supported anymore.

DEPENDS_ON

An alternative token <- for DEPENDS_ON is accepted.

LINE, COL, COORDREF

If the source coordinates of contexts are used in computations, the identifiers LINE, COL, COORDREF must occur directly in the Lido text. They may not be introduced by macros defined in a `.head' file. As a consequence the library module Message has been removed.

If there is no such coordinate usage in a certain context, that information is not stored in the tree node. The storage needed for the tree is reduced by this means.

Chain Productions

Chain Productions of the form

   Production  ::=  SymbName  'IS'  SymbName
are no longer valid.

Productions using ::= now have the same meaning as the former IS. The effect of hiding such productions from the parser is achieved by mapping the concrete grammar to the tree grammar.

Type Definitions

Specifications of the form

   Specification   ::=     'TYPE' TypeName [Extern] ['LISTEDTO' TypeName]
   Extern          ::=     Literal

are no longer valid. TypeNames are now simply introduced by their use.

Separated CHAINSTART

Computations of the form

   Computation     ::=     'CHAINSTART' ChainAttr
are no longer valid.

The keyword CHAINSTART is now attached to the computation that starts the chain.

LIDO Tokens

The keyword STATIC (equivalent to COMPUTE) is no longer valid.

The := token (equivalent to =) in computations is no longer valid.

The keyword CONDITION in front of plain computations (computations that do not compute an attribute) is now omitted.


Previous Chapter Next Chapter Table of Contents