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


 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


 o Eli library routines
 o Specification Module Library

Translation Tasks

 o Lexical analysis specification
 o Syntactic Analysis Manual
 o Computation in Trees


 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


 o System Administration Guide

Mail Home

Abstract Syntax Tree Unparsing

Previous Chapter Next Chapter Table of Contents

Changing Structure or Representation

The computation of IdemPtg in a given context can be decomposed into two tasks: collecting the IdemPtg attribute values from the children, and combining those values into a representation of the current context. Methods for attribute value collection depend on the tree grammar, and are embodied in LIDO computations. Methods for combining values, on the other hand, depend on the desired form of the unparsed text. They are embodied in PTG patterns.

There are two ways to override the output defined by the IdemPtg attribute at a given node:

  1. Override the PTG pattern associated with that node
  2. Override the computation of the IdemPtg attribute in the associated rule

The first method should be used when the change is simply one of format (adding constant strings, changing the order of the components, or omitting components). When it is necessary to add significant content to the unparsed representation of a node, then the second method should be used. Any arbitrary computation yielding an object of type PTGNode can be carried out, using any information at the processor's disposal. (Such a solution usually also requires overriding of the pattern.)

Overriding PTG patterns

The generated unparser specification contains a PTG pattern for each non-literal terminal symbol and each LIDO rule in the definition of the tree grammar. Each pattern name is the name of the construct (non-literal terminal or rule), preceded by a prefix followed by an underscore. The default prefix is Idem.

All of the non-literal terminal symbols are represented by patterns of the following form (`name' is the non-literal terminal symbol):

Idem_`name': [PtgOutId $ int]

This pattern is a single function call insertion (see Function Call Insertion of PTG: Pattern-based Text Generator). PtgOutId is a function exported by the PtgCommon module (see Commonly used Output patterns for PTG of Tasks related to generating output). Its argument is assumed to be a string table index (see Character String Storage of Library Reference Manual) and it outputs the indexed string.

This default pattern for a non-literal terminal symbol assumes that the value of that symbol is, in fact, a string table index. If the internal representation of the symbol was created by either the token processor mkidn (see Available Processors of Lexical Analysis) or the token processor mkstr, this will be the case.

In the expression language specification, mkidn is used to establish the internal representation of an Identifier, and mkstr is used to establish the internal representation of an Integer. Suppose, however, that the internal representation of an Integer was created by the token processor mkint. In that case, the user would have to provide the following PTG pattern to override the normal pattern generation.

Idem_Integer: $ int

It is vital to ensure that the PTG pattern associated with a non-literal terminal symbol is compatible with the token processor creating the internal representation of that symbol.

The only differences between the infix and postfix representations of an expression tree are in the literal terminal symbols reconstructed by the textual unparser (parentheses appear in an infix representation but not in a postfix representation) and in the order in which values are combined (operators between operands in an infix representation but following them in a postfix representation). Thus we can override the PTG patterns generated from the expression language definition to produce a postfix unparser:

Idem_PlusExp: $1 $2  "+" [Separator]
Idem_StarExp: $1 $2  "*" [Separator]
Idem_Parens:  $1
Idem_CallExp: $1 $2 [Separator]

Earlier (see Using an Unparser), we used a LIDO computation to ensure that a textual unparser generated from the expression language definition separated the arguments of a call with commas. The same effect can be achieved by simply overriding the PTG pattern that defines the "combine" function of the computation inherited by Arguments:

Idem_2ArgList: $ { "," [Separator] } $

As usual, an invocation of Separator follows the terminal symbol ,.

In some situations, it is necessary to omit one or more children of a node. This cannot be done simply by omitting indexed insertion points from the appropriate PTG pattern, because PTG determines the number of arguments to the generated function from the set of insertion points. An invocation of the generated function, with one argument per child, already appears in the computation for the node. Thus any change in the number of insertion points would result in a mismatch between the number of parameters to the function and the number of arguments to the call.

A child can be omitted from the unparsed tree by "wrapping" the corresponding indexed insertion point in the PTG pattern (`i' is the integer index):

[ IGNORE  $`i'  ]

IGNORE is a macro defined in the generated FunnelWeb file. It does nothing, so the effect is that the indexed sub-tree does not appear in the unparsed output.

Changing IdemPtg computations

The unparser generator implements the computation of the IdemPtg attribute as a class symbol computation. This class symbol computation can be overridden either by a tree symbol computation or by a rule computation (see Inheritance of Computations of LIDO - Reference Manual).

When overriding the default computation for an IdemPtg value, it is often convenient to be able to write the new computation in terms of the overridden value. Thus the unparser generator actually produces two class symbol computations: The IdemOrigPtg attribute of the class symbol is first computed by applying the appropriate PTG function to the IdemPtg attributes of the children. Then the IdemPtg attribute of the class symbol is assigned the value of the IdemOrigPtg attribute of the class symbol.

To see how IdemPtg and IdemOrigPtg could be used when an unparser's behavior must be changed, suppose that the Parens rule were omitted from the definition of the expression language. In that case, the unparser has no information about parentheses present in the original input text. Thus a pretty-printer would fail to output parentheses that were necessary to override the normal operator precedence and association in certain expressions, changing the meaning of those expressions.

Here is a simple tree symbol computation to ensure that the unparsed form has the same meaning as the original tree. It overrides the class symbol computation for IdemPtg that was produced by the unparser generator by a tree symbol computation:


PTGParen is defined by the pattern:

Paren: "(" $ ")"

This specification puts parentheses around every expression, which certainly preserves the meaning but may make the result hard to read. A more readable representation could be created by parenthesizing only those expressions containing operators:

RULE: Expression ::= Expression Operator Expression

RULE: Expression ::= Operator Expression

This illustrates the use of rule computations to override the generated class symbol computation.

A comma-separated argument list can be produced by overriding the computation of IdemOrigPtg (or IdemPtg, see Using an Unparser):

RULE: Arguments LISTOF Expression
    CONSTITUENTS Expression.IdemPtg SHIELD Expression
      WITH (PTGNode, PTGArgSep, IDENTICAL, PTGNull);

Previous Chapter Next Chapter Table of Contents