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

LIDO - Reference Manual

Previous Chapter Next Chapter Table of Contents

Expressions

An expression is evaluated as part of a computation. The evaluation may yield a value, cause an effect, or both.

Dependent Expressions

The evaluation of an expression depends on all attributes to which it refers. The expression is evaluated only after all those attributes are evaluated.

Further attributes may be added as preconditions for expression evaluation without using their values for computing the expression's result. The additional attributes may describe a computational state that has to be reached before the expression is evaluated. These attributes are specified by a DependsClause.

Syntax

    Expression    ::= SimpExpr [ DependsClause ]
    DependsClause ::= '<-' DepAttrList
    DepAttrList   ::= DepAttr
                    | '(' DepAttrs ')'
    DepAttrs      ::= DepAttrs ',' DepAttrs
                    | DepAttr
    DepAttr       ::= Attribute | RemoteAccess | RhsAttrs

Examples

    GetProp (UseId.Key,0) <- UseId.PropIsSet
    printf ("%s ", Opr.String) <- (Expr[2].printed, Expr.[3].printed)

A DependsClause has a VOID context, i.e. its attributes may have any type; their values are discarded.

Terminal Access

Named terminal symbols that occur in a production represent values that are usually obtained from corresponding input tokens when the tree node is constructed. Those values can be used in both rule and symbol computations.

Syntax

    SimpExpr ::= SymbolRef
               | 'TERM' [ '[' Number ']' ]

Examples

    RULE:   DefIdent ::= Ident COMPUTE
      DefIdent.Key = DefineIdn (DefIdent.Env, Ident);
    END;
    RULE:   Point ::= '(' Numb Numb ')' COMPUTE
      printf ("X = %d, Y = %d\n", Numb[1], Numb[2]);
    END;
    SYMBOL Point COMPUTE
      printf ("X = %d, Y = %d\n", TERM[1], TERM[2]);
    END;

In rule computations the value of a terminal in the production is denoted by the SymbName, which is indexed if and only if there are multiple occurrences of the SymbName in the production.

Note: In a rule computation a non-indexed identifier that is not a name of a symbol in the production of this rule denotes some entity of the generated C program, even if it coincides with the name of a terminal that occurs in other productions.

In lower computations of a symbol X terminal values are accessed by TERM or TERM[i], where TERM is equivalent to TERM[1]. TERM[i] denotes the i-th terminal in each production that has X (or a symbol that inherits X) on its left-hand side, regardless of the terminal's name.

Restrictions

TERM must not be used in rule computations or in upper symbol computations.

A terminal accessed in a symbol computation must exist in every production the computation is associated with.

Simple Expressions

Expressions are written as nested function calls where the basic operands are attributes, C identifiers and C literals. The functions are either predefined in LIDO or their definitions are supplied by the user in the form of C functions or macros outside the LIDO specification. There is no operator notation for expressions in LIDO.

Syntax

    SimpExpr  ::= C_Name | C_Integer | C_Float | C_Char | C_String
                |  Attribute | RemoteAccess | RhsAttrs
                |  FunctionName '(' [ Arguments ] ')'
    Arguments ::= Arguments ',' Arguments
                |  Expression

Examples

    printf ("Val = %d\n", Expr.val)
    IF (LT (Expr.val, 0), 0, Expr.val)

Evaluation of a function call notation in LIDO has the same effect and result as the equivalent notation in C.

There are some predefined FunctionNames that have a special meaning in LIDO (see Predefined Entities).

Function calls need not yield a value if they are in a VOID context. All arguments of a function call are in a value context.

C_Name, C_Integer, C_Float, C_Char, C_String are names and literals denoted as in C.

Restrictions

Every FunctionName and C_Name must be predefined in LIDO or supplied by a user definition.

All arguments of non-predefined functions must yield a (non-VOID) value. For predefined LIDO functions specific rules apply (see Predefined Entities).

Type consistency for non-VOID types is not checked by LIGA. Those checks are deferred to the compilation of the generated evaluator.

A C_Name or a FunctionName should not begin with an underscore, in order to avoid conflicts with LIGA generated identifiers.

Previous Chapter Next Chapter Table of Contents