Eli   Documents

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


Predefined Entities

The names described in this chapter have a predefined meaning in LIDO specifications.

The following types are predefined in LIDO:

VOID
Attributes of this type describe a computational state without propagating values between computations. Those attributes do not occur as data objects in the generated evaluator.

int
The terminal type.

NODEPTR
Attributes of this type represent computed subtrees.

The predefined value NULLNODEPTR of type NODEPTR denotes no tree.

The CLASS symbol ROOTCLASS is predefined. It is implicitly inherited by the root of the tree grammar (see Symbol Specifications).

The following attribute is predefined in LIDO:

GENTREE
Every insertion point symbol has an attribute GENTREE of type NODEPTR.

The following functional notations have a specific meaning in LIDO. They are translated into suitable C constructs rather than into function calls:

IF (a, b, c)
denotes a conditional expression. At runtime either b or c is evaluated, if a yields a non-zero or a zero value. For determination of the static evaluation order each of a, b, c contribute to the precondition of the computation that contains the IF construct. If it occurs in value context b and c are in value context, too. Then b and c have to yield values of the same type (not checked by LIGA). Otherwise b and c are in VOID context and may or may not yield a value of some type.

IF (a, b)
is a conditional computation of b, which is executed only if a yields a non-zero value. For determination of the static evaluation order both a and b contribute to the precondition of the computation that contains the IF construct. This IF construct must occur in VOID context. b is in VOID context, too.

ORDER (a, b, ..., x)
The arguments are evaluated in the specified order. If it occurs in VOID context all arguments are in VOID context. If it occurs in value context it yields the result of the last argument x. The others are in VOID context and may or may not yield a value. For determination of the static evaluation order all arguments of the ORDER construct contribute to the precondition of the computation containing it. Any nesting of ORDER, IF, function calls, and other expressions is allowed, as long as the stated conditions for VOID and value contexts hold.

RuleFct (C_String, arguments ...)
A call of this function is substituted by a call of a function whose name is composed of the C_String and the name 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 named rBlock a call RuleFct ("PTG", a, b) is substituted by PTGrBlock (a, b).

RhsFct (C_String, arguments ...)
A call of this function 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.

TermFct (C_String, arguments ...)
A call of this function is substituted by a comma separated sequence of calls of functions whose names are composed of the C_String and the name of the non-literal terminals in the rule that has (or inherits) this call. The remaining arguments are taken as arguments of the substituted calls. E.g. the following symbol computation
  SYMBOL X COMPUTE
    SYNT.Ptg = f (TermFct ("ToPtg", TERM));
  END;
  RULE: X ::= Y Number Z Ident ';' END;
yields the following rule computation
  RULE: X ::= Y Number Z Ident ';' COMPUTE
    X.Ptg = f (ToPtgNumber (Number), ToPtgIdent (Ident));
  END;
The order of the calls corresponds to the order of the terminals in the rule. The TermFct call must occur on argument position if there is more than one terminal in the rule.

The following names can be used in computations to obtain values that are specific for the context in the abstract tree in which the computation occurs:

LINE
the source line number of the tree context.
COL
the source column number of the tree context.
COORDREF
the address of the source coordinates of the tree context, to be used for example in calls of the message routine of the error module or in calls of tree construction functions.
RULENAME
a string literal for the rule name of the tree context, to be used for example in symbol computations.

Note: These names are translated by LIGA into specific constructs of the evaluator. Hence, they can not be used with this meaning in macros that are expanded when the evaluator is translated. (That was allowed in previous versions of LIGA.)

The following C macros are defined as described for the generated evaluator, and can be used in the LIDO text:

   APPLY (f, a, ... )  (*f) (a, ... )   a call of the function f
                                        with the remaining arguments

   CAST(tp,ex)         ( (tp) (ex) )
   SELECT(str,fld)     ( (str).fld )
   PTRSELECT(str,fld)  ( (str)->fld )
   INDEX(arr,indx)     ( (arr)[indx] )

   ADD(lop,rop)        ( lop + rop )
   SUB(lop,rop)        ( lop - rop )
   MUL(lop,rop)        ( lop * rop )
   DIV(lop,rop)        ( lop / rop )
   MOD(lop,rop)        ( lop % rop )
   NEG(op)             ( -op )

   NOT(op)             ( !op )
   AND(lop,rop)        ( lop && rop )
   OR(lop,rop)         ( lop || rop )

   BITAND(lop,rop)     ( lop & rop )
   BITOR(lop,rop)      ( lop | rop )
   BITXOR(lop,rop)     ( lop ^ rop )

   GT(lop,rop)         ( lop > rop )
   LT(lop,rop)         ( lop < rop )
   EQ(lop,rop)         ( lop == rop )
   NE(lop,rop)         ( lop != rop )
   GE(lop,rop)         ( lop >= rop )
   LE(lop,rop)         ( lop <= rop )

   VOIDEN(a)           ((void)a)

   IDENTICAL(a)        (a)
   ZERO()              0  
   ONE()               1
   ARGTOONE(x)         1
The last four macros are especially useful in WITH clauses of CONSTITUENTS constructs.


Previous Chapter Next Chapter Table of Contents