File: idem_2.html

package info (click to toggle)
eli-doc 4.4.0-4
links: PTS
area: main
in suites: sarge
size: 13,256 kB
ctags: 4,583
sloc: makefile: 42
file content (772 lines) | stat: -rw-r--r-- 30,883 bytes
<HTML>
<HEAD>
<!-- This HTML file has been created by texi2html 1.29
     from ../tnf/idem.tnf on 12 Febuary 2003 -->

<TITLE>Abstract Syntax Tree Unparsing - Available Kinds of Unparser</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#FF0000" BACKGROUND="gifs/bg.gif">
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0" VALIGN=BOTTOM>
<TR VALIGN=BOTTOM>
<TD WIDTH="160" VALIGN=BOTTOM><IMG SRC="gifs/elilogo.gif" BORDER=0>&nbsp;</TD>
<TD WIDTH="25" VALIGN=BOTTOM><img src="gifs/empty.gif" WIDTH=25 HEIGHT=25></TD>
<TD ALIGN=LEFT WIDTH="600" VALIGN=BOTTOM><IMG SRC="gifs/title.gif"></TD>
</TR>
</TABLE>

<HR size=1 noshade width=785 align=left>
<TABLE BORDER=0 CELLSPACING=2 CELLPADDING=0>
<TR>
<TD VALIGN=TOP WIDTH="160">
<h4>General Information</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="index.html">Eli: Translator Construction Made Easy</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="gindex_toc.html">Global Index</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="faq_toc.html" >Frequently Asked Questions</a> </td></tr>
</table>

<h4>Tutorials</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="EliRefCard_toc.html">Quick Reference Card</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="novice_toc.html">Guide For new Eli Users</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="news_toc.html">Release Notes of Eli</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="nametutorial_toc.html">Tutorial on Name Analysis</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="typetutorial_toc.html">Tutorial on Type Analysis</a></td></tr>
</table>

<h4>Reference Manuals</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="ui_toc.html">User Interface</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="pp_toc.html">Eli products and parameters</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="lidoref_toc.html">LIDO Reference Manual</a></td></tr>
</table>

<h4>Libraries</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="lib_toc.html">Eli library routines</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="modlib_toc.html">Specification Module Library</a></td></tr>
</table>

<h4>Translation Tasks</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="lex_toc.html">Lexical analysis specification</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="syntax_toc.html">Syntactic Analysis Manual</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="comptrees_toc.html">Computation in Trees</a></td></tr>
</table>

<h4>Tools</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="lcl_toc.html">LIGA Control Language</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="show_toc.html">Debugging Information for LIDO</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="gorto_toc.html">Graphical ORder TOol</a> </td></tr>
</table>
<p>
<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="fw_toc.html">FunnelWeb User's Manual</a> </td></tr>
</table>
<p>
<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="ptg_toc.html">Pattern-based Text Generator</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="deftbl_toc.html">Property Definition Language</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="oil_toc.html">Operator Identification Language</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="tp_toc.html">Tree Grammar Specification Language</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="clp_toc.html">Command Line Processing</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="cola_toc.html">COLA Options Reference Manual</a> </td></tr>
</table>
<p>
<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="idem_toc.html">Generating Unparsing Code</a> </td></tr>
</table>
<p>
<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="mon_toc.html">Monitoring a Processor's Execution</a> </td></tr>
</table>

<h4>Administration</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="sysadmin_toc.html">System Administration Guide</a> </td></tr>
</table>

<HR WIDTH="100%">
<CENTER>&nbsp;<A HREF="mailto:elibugs@cs.colorado.edu"><IMG SRC="gifs/button_mail.gif" NOSAVE BORDER=0 HEIGHT=32 WIDTH=32></A><A HREF="mailto:elibugs@cs.colorado.edu">Questions, Comments, ....</A></CENTER>

</TD>
<TD VALIGN=TOP WIDTH="25"><img src="gifs/empty.gif" WIDTH=25 HEIGHT=25></TD>

<TD VALIGN=TOP WIDTH="600">
<H1>Abstract Syntax Tree Unparsing</H1>
<P>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="idem_1.html"><IMG SRC="gifs/prev.gif" ALT="Previous Chapter" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="idem_3.html"><IMG SRC="gifs/next.gif" ALT="Next Chapter" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="idem_toc.html"><IMG SRC="gifs/up.gif" ALT="Table of Contents" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT="">
<HR size=1 noshade width=600 align=left>
<H1><A NAME="SEC2" HREF="idem_toc.html#SEC2">Available Kinds of Unparser</A></H1>
<A NAME="IDX13"></A>
<A NAME="IDX14"></A>
<P>
Eli is capable of generating specifications for the following kinds of
unparsers:
<P>
<DL COMPACT>
<DT>Textual
<DD>Print a "source text" representation of the tree.
This kind of unparser is most useful for processors that solve a
"source-to-source" translation problem, such as pretty-printing or
language extension.
<P>
<DT>Structural
<DD>Print a "structural" representation of the tree.
This kind of unparser is most useful for debugging applications,
and for processors that output textual representations
of tree-structured data objects.
</DL>
<P>
<H2><A NAME="SEC3" HREF="idem_toc.html#SEC3">Textual unparser</A></H2>
<A NAME="IDX15"></A>
<A NAME="IDX16"></A>
<P>
A textual unparser creates source text which, when parsed, results in the
tree that was unparsed.
For example, the pretty-printer described above accepted a sentence in the
expression language and built a tree.
It then unparsed that tree to produce an equivalent sentence in the
expression language that was formatted in a particular way.
If the resulting sentence were parsed according to the rules of the expression
language, the result would be the tree from which it had been created.
<P>
Consider the tree representing the following sentence in the expression
language:
<P>
<PRE>
a((b+c)*d, e)
</PRE>
<P>
None of the terminal symbols <KBD>(</KBD> <KBD>)</KBD> <KBD>+</KBD> <KBD>*</KBD> is stored
explicitly in the tree.
Thus the textual unparser must
<A NAME="IDX18"></A>
<A NAME="IDX17"></A>
reconstruct these terminal symbols from the
LIDO rules defining the tree nodes.
<P>
The terminal symbol <KBD>,</KBD> doesn't appear in any of the LIDO rules, and
therefore it cannot be automatically reconstructed by the textual unparser.
Additional information must be provided by the user to insert it into the
unparsed text.
This is a common consequence of using
<A NAME="IDX20"></A>
<A NAME="IDX19"></A>
<CODE>LISTOF</CODE> productions.
<P>
Our definition of the tree grammar for the expression language contains the
following rule:
<P>
<PRE>
RULE Parens: Expression ::= '(' Expression ')' END;
</PRE>
<P>
The purpose of this rule is to support the unparser by retaining
information about the presence of parentheses used to
<A NAME="IDX22"></A>
<A NAME="IDX21"></A>
override the normal operator precedence.
Such parentheses result in a <CODE>Parens</CODE> node in the tree, and the
unparser can then use this LIDO rule to reconstruct the parentheses.
<P>
<CODE>Parens</CODE> is an example of a <EM>chain rule</EM>, in which the left-hand
non-terminal symbol appears exactly once as the only non-terminal symbol
on the right-hand side.
Such chain rules are often eliminated from a tree grammar, because they have no
significance to the computations it supports.
If a textual unparser is to be generated, however, then either a chain rule
must be in the tree grammar or there must be additional information that
allows the unparser to
<A NAME="IDX24"></A>
<A NAME="IDX23"></A>
reconstruct its terminal symbols.
<P>
One important aspect of the textual form of the program that is missing from
the LIDO rules is how to separate the basic symbols.
For example, consider a <CODE>CallExp</CODE> in the expression language:
<P>
<PRE>
a(b, c)
</PRE>
<P>
There is no information in the LIDO rules about whether a space should precede
and/or follow a <KBD>(</KBD> or <KBD>,</KBD>.
Spacing is important for making the text readable, however, and cannot
simply be ignored.
<P>
<H3><A NAME="SEC4" HREF="idem_toc.html#SEC4">Computations for plain productions</A></H3>
<A NAME="IDX25"></A>
<A NAME="IDX26"></A>
<P>
A generated textual unparser defines the following computation (two
attributes are used to simplify overriding,
see  <A HREF="idem_3.html#SEC12">Changing <CODE>IdemPtg</CODE> computations</A>):
<A NAME="IDX27"></A>
<A NAME="IDX28"></A>
<A NAME="IDX29"></A>
<P>
<PRE>
ATTR IdemPtg, IdemOrigPtg: PTGNode;

CLASS SYMBOL IdemReproduce COMPUTE
  SYNT.IdemOrigPtg=
    RuleFct("PTGIdem_", RHS.IdemPtg, TermFct("PTGIdem_"));
  SYNT.IdemPtg=THIS.IdemOrigPtg;
END;
</PRE>
<P>
The class symbol <CODE>IdemReproduce</CODE> is inherited by every
non-terminal symbol appearing on the left-hand side of a plain production.
For example, it is inherited by <CODE>Expression</CODE> and <CODE>Axiom</CODE> in the
textual unparser specification generated from the expression language
definition.
<P>
This computation invokes a function specific to the LIDO rule and, if the
rule contains any instances of non-literal terminal symbols, a function
specific to each.
For example, the effect of <CODE>Expression</CODE> inheriting
<CODE>IdemReproduce</CODE> is to carry out computations at the <CODE>StarExp</CODE> and
<CODE>CallExp</CODE> rules that are equivalent to the following rule
computations:
<P>
<PRE>
RULE StarExp: Expression ::= Expression '*' Expression
COMPUTE
  Expression[1].IdemOrigPtg=
    PTGIdem_StarExp(Expression[2].IdemPtg,Expression[3].IdemPtg);
  Expression[1].IdemPtg=Expression[1].IdemOrigPtg;
END;

RULE CallExp: Expression ::= Identifier '(' Arguments ')'
COMPUTE
  Expression[1].IdemOrigPtg=
    PTGIdem_StarExp(Arguments.IdemPtg,PTGIdem_Identifier(Identifier));
  Expression[1].IdemPtg=Expression[1].IdemOrigPtg;
END;
</PRE>
<P>
(For details about <CODE>RuleFct</CODE> and <CODE>TermFct</CODE>,
see  <A HREF="lidoref_12.html#SEC21">Predefined Entities of LIDO - Reference Manual</A>.)
<P>
Here are several PTG patterns appearing in a textual unparser generated
from the expression language definition that illustrate how the
PTG functions are specified:
<P>
<PRE>
Idem_StarExp: $1  "*" [Separator]  $2
Idem_IdnExp:  $1  [Separator]
Idem_CallExp: $2  [Separator] "(" [Separator]  $1  ")" [Separator]
</PRE>
<P>
Notice how these patterns
<A NAME="IDX31"></A>
<A NAME="IDX30"></A>
reconstruct the terminal symbols <KBD>*</KBD>,
<KBD>(</KBD>, and <KBD>)</KBD>.
<P>
The different orders of the indexed insertion points in the patterns
<CODE>Idem_StarExp</CODE> and <CODE>Idem_CallExp</CODE> are due to
the definition of the computation above.
<CODE>Idem_StarExp</CODE> has two non-terminal children,
which appear in order as the arguments of the generated rule function.
<CODE>Idem_CallExp</CODE>, on the other hand,
has a non-literal terminal as its first child and a non-terminal as its second.
The non-literal terminal arguments of the generated rule function follow
the non-terminal arguments.
<A NAME="IDX32"></A>
<P>
<CODE>Separator</CODE> is the function that makes the decision about how to place
layout characters
(see  <A HREF="output_8.html#SEC8">Introduce Separators in PTG Output of Tasks related to generating output</A>).
A call to <CODE>Separator</CODE> is inserted into every pattern after each
terminal symbol, both literal and non-literal.
This allows a decision to be made about layout characters between each
pair of terminal symbols.
<P>
The separator module provides the following output functions, which must be
used instead of the corresponding PTG output functions
(see  <A HREF="ptg_3.html#SEC7">Output Functions of PTG: Pattern-based Text Generator</A>):
<A NAME="IDX33"></A>
<P>
<PRE>
PTGNode Sep_Out(PTGNode root);
PTGNode Sep_OutFile(char *filename, PTGNode root);
PTGNode Sep_OutFPtr(FILE *fptr, PTGNode root);
</PRE>
<P>
The module library contains two modules that implement different strategies
for selecting layout characters:
<P>
<A NAME="IDX34"></A>
<DL COMPACT>
<DT><TT>`Sp_Separator.fw'</TT>
<DD>A single space is used as a separator regardless of the context.
<P>
<A NAME="IDX35"></A>
<DT><TT>`C_Separator.fw'</TT>
<DD>Reasonable separator placement rules for C program text:
a newline is added after any of <KBD>;</KBD> <KBD>{</KBD> <KBD>}</KBD>,
no separator is added after any of <KBD>(</KBD> <KBD>[</KBD> <KBD>.</KBD> <KBD>++</KBD>
<KBD>--</KBD>,
no separator is added before any of <KBD>[</KBD> <KBD>]</KBD> <KBD>,</KBD> <KBD>.</KBD> <KBD>;</KBD>
<KBD>++</KBD> <KBD>--</KBD>,
and a single space added in all other cases.
</DL>
<A NAME="IDX36"></A>
<A NAME="IDX37"></A>
<A NAME="IDX38"></A>
<P>
If none of the available modules is satisfactory,
then you must create your own.
The simplest approach is to modify one from the library.
Here is a sequence of Eli requests that will
extract <TT>`C_Separator.fw'</TT> as file <CODE>My_Separator.fw</CODE>,
make <CODE>My_Separator.fw</CODE> writable,
and
initiate an editor session on it:
<P>
<PRE>
-&#62; $elipkg/Output/C_Separator.fw &#62; My_Separator.fw
-&#62; My_Separator.fw !chmod +w
-&#62; My_Separator.fw &#60;
</PRE>
<P>
In order to change the decision about what (if any) separator is to be
inserted in a given context, you need to change the function called
<A NAME="IDX39"></A>
<CODE>Sep_Print</CODE>.
<CODE>Sep_Print</CODE>
(see  <A HREF="output_8.html#SEC8">Introduce Separators in PTG Output of Specification Module Library: Generating Output</A>)
<A NAME="IDX40"></A>
has three arguments:
a pointer to the file to which the separator is to be written,
a pointer to the string that immediately precedes the separator,
and a pointer to the string that immediately follows the separator.
<P>
<CODE>Sep_Print</CODE> must decide whether a separator is appropriate between the
two strings given by its second and third arguments,
and if so then what that separator should be.
If a separator is required, <CODE>Sep_Print</CODE> must write that separator to the
file.
<CODE>Sep_Print</CODE> must not modify the strings passed to it.
<P>
<H3><A NAME="SEC5" HREF="idem_toc.html#SEC5">Computations for LISTOF productions</A></H3>
<A NAME="IDX41"></A>
<A NAME="IDX42"></A>
<P>
A generated textual unparser defines the following computation for a
<CODE>LISTOF</CODE> production named <SAMP>`r'</SAMP> with left-hand side <SAMP>`X'</SAMP> and
elements <SAMP>`Y | Z'</SAMP> (two attributes are used to simplify overriding,
see  <A HREF="idem_3.html#SEC12">Changing <CODE>IdemPtg</CODE> computations</A>):
<A NAME="IDX43"></A>
<P>
<PRE>
ATTR IdemPtg, IdemOrigPtg: PTGNode;

CLASS SYMBOL IdemReproduce_X COMPUTE
  SYNT.IdemOrigPtg=
    PTG_r(
      CONSTITUENTS (Y.IdemPtg, Z.IdemPtg) SHIELD (Y, Z)
      WITH (PTGNode, PTGIdem_2r, PTGIdem_1r, PTGNull));
  SYNT.IdemPtg=THIS.IdemOrigPtg;
END;
</PRE>
<P>
The class symbol <CODE>IdemReproduce_X</CODE> is inherited by the
non-terminal symbol <CODE>X</CODE>.
For example, in the textual unparser specification generated from the
expression language, there is such a rule with
<CODE>r</CODE> being <CODE>ArgList</CODE>, 
<CODE>X</CODE> being <CODE>Arguments</CODE>, and
<CODE>Y</CODE> being <CODE>Expression</CODE>.
There is no <CODE>Z</CODE> in that case:
<P>
<PRE>
CLASS SYMBOL IdemReproduce_Arguments COMPUTE
  SYNT.IdemOrigPtg=
    PTG_ArgList(
      CONSTITUENTS (Expression.IdemPtg) SHIELD (Expression)
      WITH (PTGNode, PTGIdem_2ArgList, PTGIdem_1ArgList, PTGNull));
  SYNT.IdemPtg=THIS.IdemOrigPtg;
END;
</PRE>
<P>
<CODE>Arguments</CODE> inherits <CODE>IdemReproduce_Arguments</CODE> in the textual
unparser specification generated from the expression language definition.
<P>
The computation for the class symbol invokes three functions
specific to the LIDO rule.
Here are the three PTG patterns specifying those functions for the
<CODE>ArgList</CODE> rule:
<P>
<PRE>
Idem_ArgList:  $
Idem_2ArgList: $ $
Idem_1ArgList: $
</PRE>
<P>
PTG patterns for other <CODE>LISTOF</CODE> productions will differ from these
only in the pattern names.
<P>
<H2><A NAME="SEC6" HREF="idem_toc.html#SEC6">Structural unparser</A></H2>
<A NAME="IDX44"></A>
<A NAME="IDX45"></A>
<P>
A structural unparser creates a textual description of the tree in terms
of rule names and non-literal terminal symbols.
For example, the sentence <SAMP>`a(b,c)'</SAMP> in the expression language
could be unparsed as the XML file:
<P>
<PRE>
&#60;rule_000&#62;
  &#60;CallExp&#62;
    a
    &#60;ArgList&#62;
      &#60;IdnExp&#62;b&#60;/IdnExp>
      &#60;IdnExp&#62;c&#60;/IdnExp>
    &#60;/ArgList&#62;
  &#60;/CallExp&#62;
&#60;/rule_000&#62;
</PRE>
<P>
The entire sentence is output as a <CODE>rule_000</CODE> because the LIDO rule
defining <CODE>Axiom</CODE> was generated, and was given the name <CODE>rule_000</CODE>
by Eli.
The single child of this node is a <CODE>CallExp</CODE> with two components,
the non-literal terminal symbol <SAMP>`a'</SAMP> and an <CODE>ArgList</CODE>
made up of two <CODE>IdnExp</CODE> nodes.
<P>
Appropriate layout, with meaningful line breaks and indentation,
is important for a human trying to understand the output of
a structural unparser.
This formatting depends only on structure, however, not on the content of
the output.
<P>
Structural unparser generators producing both simple descriptions of trees and
descriptions in several standard languages are available.
It is also possible for a user to create an unparser generator that
describes the tree in a language of their own choosing.
<P>
<H3><A NAME="SEC7" HREF="idem_toc.html#SEC7">Computations for plain productions</A></H3>
<A NAME="IDX46"></A>
<A NAME="IDX47"></A>
<P>
A generated structural unparser defines the following computation (two
attributes are used to simplify overriding,
see  <A HREF="idem_3.html#SEC12">Changing <CODE>IdemPtg</CODE> computations</A>):
<A NAME="IDX48"></A>
<A NAME="IDX49"></A>
<A NAME="IDX50"></A>
<P>
<PRE>
ATTR IdemPtg, IdemOrigPtg: PTGNode;

CLASS SYMBOL IdemReproduce COMPUTE
  SYNT.IdemOrigPtg=
    RuleFct("PTGIdem_", RHS.IdemPtg, TermFct("PTGIdem_"));
  SYNT.IdemPtg = THIS.IdemOrigPtg;
END;
</PRE>
<P>
The class symbol <CODE>IdemReproduce</CODE> is inherited by every non-terminal
symbol appearing on the left-hand side of a plain production.
For example, it is inherited by <CODE>Expression</CODE> and <CODE>Axiom</CODE> in the
structural unparser specification generated from the expression language
definition.
<P>
This computation invokes a function specific to the LIDO rule and, if the
rule contains any instances of non-literal terminal symbols, a function
specific to each.
For example, the effect of <CODE>Expression</CODE> inheriting
<CODE>IdemReproduce</CODE> is to carry out computations at the <CODE>StarExp</CODE> and
<CODE>CallExp</CODE> rules that are equivalent to the following rule
computations:
<P>
<PRE>
RULE StarExp: Expression ::= Expression '*' Expression
COMPUTE
  Expression[1].IdemOrigPtg=
    PTGIdem_StarExp(Expression[2].IdemPtg,Expression[3].IdemPtg);
  Expression[1].IdemPtg=Expression[1].IdemOrigPtg;
END;

RULE CallExp: Expression ::= Identifier '(' Arguments ')'
COMPUTE
  Expression[1].IdemOrigPtg=
    PTGIdem_StarExp(Arguments.IdemPtg,PTGIdem_Identifier(Identifier));
  Expression[1].IdemPtg=Expression[1].IdemOrigPtg;
END;
</PRE>
<P>
(For details about <CODE>RuleFct</CODE> and <CODE>TermFct</CODE>,
see  <A HREF="lidoref_12.html#SEC21">Predefined Entities of LIDO - Reference Manual</A>.)
<P>
Here are several PTG patterns from a structural unparser generated from
the expression language definition that illustrate how those functions are
specified:
<A NAME="IDX51"></A>
<A NAME="IDX52"></A>
<A NAME="IDX53"></A>
<P>
<PRE>
Idem_StarExp:
  "&#60;StarExp&#62;" [BP_BeginBlockI]
    [BP_BreakLine] $1 [BP_BreakLine] $2 [BP_BreakLine]
  [BP_EndBlockI] "&#60;/StarExp&#62;"
Idem_IdnExp:
  "&#60;IdnExp&#62;" [BP_BeginBlockI]
    [BP_BreakLine] $1 [BP_BreakLine]
  [BP_EndBlockI] "&#60;/IdnExp&#62;"
Idem_CallExp:
  "&#60;CallExp&#62;" [BP_BeginBlockI]
    [BP_BreakLine] $2 [BP_BreakLine] $1 [BP_BreakLine]
  [BP_EndBlockI] "&#60;/CallExp&#62;"
</PRE>
<P>
These patterns are the ones generated if the output is to be an XML file
(see  <A HREF="idem_2.html#SEC9">Languages describing tree structure</A>).
<A NAME="IDX54"></A>
<A NAME="IDX55"></A>
<P>
The different orders of the indexed insertion points in the patterns
<CODE>Idem_StarExp</CODE> and <CODE>Idem_CallExp</CODE> are due to the definition
of the computation above.
<CODE>Idem_StarExp</CODE> has two non-terminal children,
which appear in order as the arguments of the generated rule function.
<CODE>Idem_CallExp</CODE>, on the other hand,
has a non-literal terminal as its first child and a non-terminal as its second.
The non-literal terminal arguments of the generated rule function follow
the non-terminal arguments.
<P>
Generated structural unparsers use the
<A NAME="IDX57"></A>
<A NAME="IDX56"></A>
block print module
(see  <A HREF="output_6.html#SEC6">Typesetting for Block Structured Output of Tasks related to generating output</A>)
to provide
<A NAME="IDX58"></A>
layout.
The generated PTG patterns invoke functions of this module to mark
potential line breaks and the boundaries of logical text blocks.
The block print module provides the following output functions, which must be
used instead of the corresponding PTG output functions
(see  <A HREF="ptg_3.html#SEC7">Output Functions of PTG: Pattern-based Text Generator</A>):
<A NAME="IDX59"></A>
<P>
<PRE>
PTGNode BP_Out(PTGNode root);
PTGNode BP_OutFPtr(FILE *fptr, PTGNode root);
PTGNode BP_OutFile(char *filename, PTGNode root);
</PRE>
<P>
Note that the textual representation of the <EM>children</EM> of every node
is considered to be a logical text block.
A line break can occur before each child.
The effect of this specification is to keep the textual representation of a
node on a single line if that is possible.
Otherwise, the sequence of children is written one per line, indented from
the name of the block's rule.
<P>
<H3><A NAME="SEC8" HREF="idem_toc.html#SEC8">Computations for LISTOF productions</A></H3>
<A NAME="IDX60"></A>
<A NAME="IDX61"></A>
<P>
A generated structural unparser defines the following computation for a
<CODE>LISTOF</CODE> production named <SAMP>`r'</SAMP> with left-hand side <SAMP>`X'</SAMP> and
elements <SAMP>`Y | Z'</SAMP> (two attributes are used to simplify overriding,
see  <A HREF="idem_3.html#SEC12">Changing <CODE>IdemPtg</CODE> computations</A>):
<A NAME="IDX62"></A>
<A NAME="IDX63"></A>
<A NAME="IDX64"></A>
<P>
<PRE>
ATTR IdemPtg, IdemOrigPtg: PTGNode;

CLASS SYMBOL IdemReproduce_X COMPUTE
  SYNT.IdemOrigPtg=
    PTG_r(
      CONSTITUENTS (Y.IdemPtg, Z.IdemPtg) SHIELD (Y, Z)
      WITH (PTGNode, PTGIdem_2r, PTGIdem_1r, PTGNull));
  SYNT.IdemPtg=THIS.IdemOrigPtg;
END;
</PRE>
<P>
The symbol <CODE>IdemReproduce_X</CODE> is inherited by the non-terminal symbol
<CODE>X</CODE>.
For example, in the structural unparser specification generated from the
expression language, there is such a rule with
<CODE>r</CODE> being <CODE>ArgList</CODE>, 
<CODE>X</CODE> being <CODE>Arguments</CODE>, and
<CODE>Y</CODE> being <CODE>Expression</CODE>.
There is no <CODE>Z</CODE> in that case:
<P>
<PRE>
CLASS SYMBOL IdemReproduce_Arguments COMPUTE
  SYNT.IdemOrigPtg=
    PTG_ArgList(
      CONSTITUENTS (Expression.IdemPtg) SHIELD (Expression)
      WITH (PTGNode, PTGIdem_2ArgList, PTGIdem_1ArgList, PTGNull));
  SYNT.IdemPtg=THIS.IdemOrigPtg;
END;
</PRE>
<P>
<CODE>Arguments</CODE> inherits <CODE>IdemReproduce_Arguments</CODE> in the structural
unparser specification generated from the expression language definition.
<P>
The computation for the class symbol invokes three functions
specific to the LIDO rule.
Here are the three PTG patterns specifying those functions for the
<CODE>ArgList</CODE> rule:
<P>
<PRE>
Idem_ArgList:
  "&#60;ArgList&#62;" [BP_BeginBlockI]
   [BP_BreakLine] $ [BP_BreakLine]
  [BP_EndBlockI] "&#60;/ArgList&#62;"
Idem_2ArgList: $ { [BP_BreakLine] } $
Idem_1ArgList: $
</PRE>
<P>
PTG patterns for other <CODE>LISTOF</CODE> productions will differ from these
only in the rule name.
<P>
<H3><A NAME="SEC9" HREF="idem_toc.html#SEC9">Languages describing tree structure</A></H3>
<P>
By default, a structural unparser generator uses a generic functional
representation to describe the tree.
Here's the default representation of the sentence <SAMP>`a(b,c)'</SAMP>
in the expression language:
<P>
<PRE>
rule_000(CallExp(a,IdnExp(b),IdnExp(c)))
</PRE>
<P>
(Recall that the entire sentence is output as a <CODE>rule_000</CODE> because the
LIDO rule defining <CODE>Axiom</CODE> was generated, and was given the name
<CODE>rule_000</CODE> by Eli.)
<P>
Three other standard representations are available:
<P>
<A NAME="IDX65"></A>
<A NAME="IDX66"></A>
<DL COMPACT>
<DT><CODE>XML</CODE>
<DD>Generates an unparser that produces an XML representation of the tree,
and a separate DTD file defining the possible structures.
<A NAME="IDX67"></A>
<A NAME="IDX68"></A>
<P>
<DT><CODE>CPP</CODE>
<DD>Generates an unparser that produces C++ code to build the tree,
and a separate module defining the set of C++ classes used.
<A NAME="IDX69"></A>
<A NAME="IDX70"></A>
<P>
<DT><CODE>Java</CODE>
<DD>Generates an unparser that produces Java code to build the tree,
and a separate package defining the set of Java classes used.
</DL>
<A NAME="IDX71"></A>
<P>
It is also possible to build structural unparser generators for other
application languages by modifying existing generator specifications.
All unparser generators have the same general organization: they analyze the
tree grammar and produce class symbol computations and
PTG patterns to output any tree defined by that grammar.
Much of the analysis is common, with differences appearing only in the
final output of the generated FunnelWeb file.
<A NAME="IDX72"></A>
<P>
The unparser generator specifications available in the library are:
<P>
<A NAME="IDX73"></A>
<DL COMPACT>
<DT><TT>`$/Unparser/Analysis.fw'</TT>
<DD>Analysis of the input text that defines the tree grammar.
Common attribute computations supporting a wide range of unparsers.
<A NAME="IDX74"></A>
<P>
<DT><TT>`$/Unparser/Idem.fw'</TT>
<DD>Attribute computations specific to textual unparsers.
<A NAME="IDX75"></A>
<P>
<DT><TT>`$/Unparser/Tree.fw'</TT>
<DD>Attribute computations specific to the generic functional representation.
<A NAME="IDX76"></A>
<A NAME="IDX77"></A>
<P>
<DT><TT>`$/Unparser/Xml.fw'</TT>
<DD>Attribute computations specific to XML files and the associated DTD file.
<A NAME="IDX78"></A>
<P>
<DT><TT>`$/Unparser/Cpp.fw'</TT>
<DD>Attribute computations specific to C++ code and the associated module
definition.
<A NAME="IDX79"></A>
<A NAME="IDX80"></A>
<P>
<DT><TT>`$/Unparser/Java.fw'</TT>
<DD>Attribute computations specific to Java code and the associated package
definition.
</DL>
<P>
Suppose that you wanted to create an unparser generator that would
produce Modula-3 code to build the tree, and a separate interface file
defining the tree structure.
Because Modula-3 is quite similar to Java in its structure,
you might start by modifying <TT>`$/Unparser/Java.fw'</TT> from the library.
Here is a sequence of Eli requests that will
extract <TT>`Java.fw'</TT> as file <CODE>Modula-3.fw</CODE>,
make <CODE>Modula-3.fw</CODE> writable,
and
initiate an editor session on it:
<P>
<PRE>
-&#62; $elipkg/Unparser/Java.fw &#62; Modula-3.fw
-&#62; Modula-3.fw !chmod +w
-&#62; Modula-3.fw &#60;
</PRE>
<P>
After suitable modification, <TT>`Modula-3.fw'</TT> could be combined with the
library specification <TT>`$/Unparser/Analysis.fw'</TT> to define the new
unparser generator.
Thus you might create a file called
<A NAME="IDX81"></A>
<TT>`M3.specs'</TT> with the following content:
<P>
<PRE>
Modula-3.fw
$/Unparser/Analysis.fw
</PRE>
<P>
The unparser generator could then be derived from <TT>`M3.specs'</TT> as usual
(see  <A HREF="pp_1.html#SEC2">exe -- Executable Version of the Processor of Products and Parameters Reference</A>):
<P>
<PRE>
-&#62; M3.specs :exe
</PRE>
<P>
<HR size=1 noshade width=600 align=left>
<P>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="idem_1.html"><IMG SRC="gifs/prev.gif" ALT="Previous Chapter" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="idem_3.html"><IMG SRC="gifs/next.gif" ALT="Next Chapter" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="idem_toc.html"><IMG SRC="gifs/up.gif" ALT="Table of Contents" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT="">
<HR size=1 noshade width=600 align=left>
</TD>
</TR>
</TABLE>

</BODY></HTML>