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

Attributes

Attributes are associated with symbols and with rules. They are defined and used in rule computations and in symbol computations.

Each symbol has two disjoint sets of attributes: synthesized (SYNT) attributes that are defined by computations in lower contexts of the symbol, and inherited (INH) attributes that are defined by computations in upper contexts of the symbol.

Attributes are introduced by their occurrence in computations. They are not explicitly declared. How types and classes of attributes are determined is described in Types and Classes of Attributes.

Syntax

    Attribute ::= SymbolRef '.' AttrName
                | RuleAttr
    RuleAttr  ::= '.' AttrName
    SymbolRef ::= SymbName
                | SymbName '[' Number ']'
    RhsAttrs  ::= 'RHS' '.' AttrName

Examples

    RULE: Stmt ::= 'while' Expr 'do' Stmt COMPUTE ...
      ... Expr.postType ...
      ... Stmt[1].code ...
      ... .label ...
      ... RuleFct ("PTG", RHS.Ptg) ...
    END;
    SYMBOL Expr COMPUTE
      ... SYNT.preType ...
      ... INH.postType ...
      ... THIS.preType ...
      ... RuleFct ("PTG", RHS.Ptg) ...
    END;

Attributes in rule computations have the form X.a or X[i].a where X is a nonterminal in the production of the rule. They refer to the attribute a of the tree node corresponding to X. The index distinguishes multiple occurrences of the nonterminal in the production, counting from left to right starting at 1.

Rule attributes of the form .b may be used in rule computations, to simplify reuse of computed values. They are defined and used within the computations of a single rule. They are not associated with any symbol.

In symbol computations attributes of the considered symbol are denoted using SYNT, INH, or THIS instead of the SymbName: SYNT.a for a synthesized attribute, INH.b for an inherited attribute, or THIS.c leaving the attribute class to be specified elsewhere.

A RhsAttrs construct, such as RHS.a, is a shorthand for a sequence of attributes all named a, one for each right-hand side nonterminal of the rule context associated with the computation. If there is more than one such nonterminal the construct may only occur in function calls, where it contributes part of the argument sequence, or in DependsClauses(see Dependent Expressions). If a symbol computation contains a RhsAttrs its sequence of attributes is determined for each rule context of the symbol individually. In combination with the predefined function RuleFct a RhsAttrs construct may be used to specify a call pattern that is instantiated differently for each rule context (see Predefined Entities).

Restrictions

The SymbolRef must occur in the production of the rule.

The SymbolRef must be indexed if and only if the symbol occurs more than once in the production.

The index of a SymbolRef must identify an occurrence of the symbol in the production.

SymbNames and indices may not be used in attributes of symbol computations.

Rule attributes may not be used in symbol computations.

Types and Classes of Attributes

Each attribute has a certain type characterizing the values propagated by the attribute. Attributes that describe only postconditions of computations without propagating a value have the predefined type VOID. Non-VOID types must be specified explicitly.

Each attribute has either the class synthesized (SYNT), if it is computed in all lower contexts of its symbol, or it has the class inherited (INH), if it is computed in all upper contexts of its symbol. Attribute classes are usually derived from computations without explicit specifications.

Syntax

    AttrSpec     ::= 'ATTR' AttrNames ':' TypeName [ AttrClass ]

    SymSpec      ::= SymbKind SymbNames ':' [ AttrSpecs ]

    AttrSpecs    ::= AttrSpecs ',' AttrSpecs
                   | AttrNames ':' TypeName [ AttrClass ]

    AttrClass    ::= 'SYNT' | 'INH'

Examples

    ATTR code: PTGNode SYNT;
    SYMBOL Expr, UseIdent: preType, postType: DefTableKey;

An attribute name specification (ATTR) determines the type and optionally the class of all attributes having one of the AttrNames.

An AttrSpec for a nonterminal determines the type and optionally the class of attributes given by the AttrNames for all nonterminals given by SymbNames. These specifications override the type and the attribute class stated by ATTR specifications.

If the type of an attribute is left unspecified it is assumed to be VOID.

Note: Misspelling of an attribute name in a computation leads to introduction of a VOID attribute, and is usually indicated by messages on missing computations for that attribute or illegal use of a VOID attribute.

Note: The type of a non-VOID rule attribute has to be specified by ATTR specifications.

Restrictions

There may be several ATTRspecifications for the same AttrName provided their properties are not contradictory.

A specified attribute class must be consistent with all computations of that attribute.

VOID attributes may not be used in value contexts.

The type specified for an attribute must denote an assignable C type that is available in the generated evaluator. LIGA does not check whether non-VOID attributes are used consistently with respect to their types. Violations will be indicated when the generated evaluator is compiled.

Previous Chapter Next Chapter Table of Contents