General Information

 o Eli: Translator Construction Made Easy
 o Global Index
 o Frequently Asked Questions

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

Reference Manuals

 o User Interface
 o Eli products and parameters
 o LIDO Reference Manual

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

 Questions, Comments, ....

LIDO - Reference Manual

Previous Chapter Next Chapter Table of Contents


Computations

Computations are associated with rules or with symbols. Each computation (that is not overridden) is executed exactly once for every instance of its context in a particular tree. A computation may yield a value denoted as an attribute which may be used by other computations.

Computations may also be specified as depending on one another without passing a value in order to specify dependencies on side-effects of computations (see Dependent Expressions).

Syntax

    Computations ::=  [ 'COMPUTE' Computation ]

    Computation  ::=  Computation Computation |
                   | Expression Terminator
                   | Attribute '=' Expression Terminator
    Terminator   ::= ';'
                   | 'BOTTOMUP' ';'




Examples

    COMPUTE
      Expr.postType = boolType;
      Stmt[1].code = PTGWhile (Expr.code, Stmt[2].code);
      printf ("while loop in line %d\n", LINE);
      printf ("value = %d\n", Expr.val) BOTTOMUP;

There are two forms of computations: attribute computations denoted as an assignment to an attribute, and plain computations that are simple expressions.

A computation is executed by evaluating its expression. It depends on every attribute that occurs in the expression regardless whether the attribute is used for the evaluation. We say those attributes are the preconditions of the computation. The attribute on the left-hand side of an attribute computation represents the postcondition of that computation. Plain computations do not establish a postcondition for any other computation. The evaluator is generated such that the computations are executed in an order that obeys these dependencies for any tree of the tree grammar.

If both a symbol computation and a rule computation define the same attribute of a symbol, the rule computation will be executed in that context, overriding the symbol computation.

An expression may occur in value context, where it must yield a value, or it may occur in VOID context, where it may or may not yield a value. If it does yield a value in VOID context, the value is discarded. These terms will be used in sections below where further constructs are introduced which contain expressions.

If the left-hand side attribute of an attribute computation has a type different from VOID the right-hand side expression is in value context; the result of the expression evaluation is assigned to the attribute. If the left-hand side attribute has the type VOID the right-hand side expression is in VOID context. In this case the attribute simply states the postcondition that the computation has been executed.

A plain computation is in VOID context, i. e. it may or may not yield a value.

Computations may be specified to be executed BOTTOMUP, that means while the input is being read and the tree is being built. LIGA then tries to arrange the computations such that those are executed already when their tree node is constructed. This facility is useful for example if the generated language processor is to produce output while its input is supplied (like desktop calculators), or if a computation is used to switch the input file.

Note: A BOTTOMUP computation may depend on other computations. These dependencies should be specified the usual way. Such precondition computations should NOT be specified BOTTOMUP unless they themselves are to be related to input processing. Without such an overspecification Liga can apply more sophisticated means to correctly schedule the precondition computations automatically.

Note: Due to the parser's lookahead, one token beyond the last token of the context of the BOTTOMUP computation is read before before the computation is executed.

Restrictions

If the attribute in an attribute computation has a non-VOID type the evaluation of the expression must yield a value of that type. This condition is not checked by Liga. It is checked by the compiler that compiles to the generated evaluator.

Multiple symbol computations that define the same attribute are forbidden.

There must be exactly one attribute computation for each synthesized attribute of the left-hand side nonterminal and for each inherited attribute of each right-hand side nonterminal in the production of a rule context.

There may not be any cyclic dependencies between computations for any tree of the tree grammar.

Contexts that may belong to subtrees which are built by computations (see Computed Subtrees) may not have computations that are marked BOTTOMUP or contribute to BOTTOMUP computations.

LIGA may fail to allocate BOTTOMUP computations as required due to attribute dependencies or due to LIGA's evaluation strategy. In such cases messages are given.


Previous Chapter Next Chapter Table of Contents