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

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
 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

Products and Parameters Reference

Previous Chapter Next Chapter Table of Contents


Generating Specifications

Sometimes a common problem can be solved by a collection of specifications having a particular structure. These specifications themselves can be generated, given simpler specifications. The products and parameters described in this chapter are most often used in requests that appear in type-specs files. They result in specifications that are then used to describe the complete processor.

consyntax -- Concrete Syntax

:consyntax

Requesting :consyntax will result in a type-`con' file containing the complete concrete syntax. This includes all concrete syntax rules provided by the user in type-`con' files (translated into strict BNF form) as well as rules added to the concrete syntax as a result of the mapping process (see Mapping of Syntactic Analysis).

abstree -- Abstract Tree Grammar

:abstree

Requesting :abstree will result in a type-`lido' file containing the complete abstract tree grammar. This consists of all rules supplied by the user in type-lido files, plus any additional rules derived from rules appearing only in type-con files in the syntax mapping process (see Mapping of Syntactic Analysis).

absyntax -- Abstract Syntax

:absyntax

Requesting :absyntax will result in a type-lido file containing the complete abstract syntax. This derivation differs from the :abstree derivation (see abstree -- Abstract Tree Grammar) in that rules which can only be derived for computed subtrees (see Computed Subtrees of LIDO - Reference Manual) are not included.

pgram -- Parsing Grammar

:pgram

The parsing grammar requested by the :pgram derivation is the input to the parser generator. This includes the integer encodings of the terminal symbols, any directives supplied by the user to direct the automatic error correction of the parser, and each of the BNF rules in the concrete syntax with associated actions. These actions include actions supplied by the user as well as actions generated to construct an abstract syntax tree.

Note that the mapping process may cause the injection of certain chain rules due to BOTTOMUP constraints specified in the attribute grammar. These injected rules do not appear in the result of the :consyntax derivation, which makes :pgram the most appropriate derivation to consult when trying to resolve parsing conflicts which may have resulted from the injection of these chain rules. See BOTTOMUP of Syntactic Analysis.

kwd -- Recognize Specified Literals as Identifiers

file.gla :kwd

Specifications that force literals whose lexical structure is defined by file.gla to be handled specially by the generated scanner.

Normally, each literal found in the context-free grammar is recognized explicitly by the scanner as the specified character sequence. This is in contrast to identifiers, denotations and comments, whose lexical structures are defined by regular expressions. The literals are defined by their appearance in the grammar, and no type-gla file describes their structure.

The :kwd product is used when literals are representative of the character strings that should appear in the program, but not necessarily identical to them. The classic case in which :kwd would be used (and from which its name is derived) is the recognition of mixed-case keywords. A literal 'if' appearing in a Pascal grammar is representative of the character strings if, If, iF and IF but is identical to only the first. Whenever any one of these four character strings appears in a Pascal program, it should be recognized by the scanner as an instance of the literal 'if'. All Pascal keywords behave in this fashion, and each has the form of an identifier.

Suppose that file pkeys.gla defines the structure of the literals used in the grammar, and the following line were added to one of the type-.specs files for a Pascal compiler:

pkeys.gla :kwd

This would prevent the scanner of the generated compiler from recognizing Pascal keywords explicitly as the character sequences specified by the literals given in the grammar. Other literals (such as :=), which did not fit the definition given by pkeys.gla, would still be recognized by the scanner as the specified character sequences.

It is important to remember that the type-`gla' file to which the kwd derivation is applied defines the form of the literals in the grammar, not in the input text.

inst -- Instantiate a Generic Module

file.gnrc :inst

A specification consisting of one or more files is generated from file.gnrc. This product is normally used to instantiate the common problem solutions that have been stored in the library (see Module Instantiation of Specification Module Library):

$elipkg/Name/AlgScope.gnrc :inst

Here the path `$elipkg/Name' accesses the portion of the library devoted to problems arising in the context of name analysis (see Name Analysis Library of Specification Module Library: Name Analysis).

Type-gnrc files can be supplied by a user. They are simply shell scripts that carry out whatever actions are needed to instantiate a generic specification. Thus a user of Eli can construct generic specifications appropriate to a specific domain and use them exactly like library specifications.

Scripts appearing as type-gnrc files are invoked with up to three parameters. The first parameter is the sed(1) program, the second parameter is the string specified by +instance, and the third parameter is the string specified by +referto. When the script is invoked, its full path name is used. Therefore the script can determine the directory in which it is stored, and access specific files in that directory.

Here is an example of a type-gnrc file, `$elipkg/Name/AlgScope.gnrc':

#!/bin/sh
# $Id: pp.tnf,v 2.15 2012/07/30 22:55:15 profw Exp $
# Copyright, 1994, AG-Kastens, University Of Paderborn

moddir=`expr $0 : '\(.*\)/.*' \| '.'`

$1 -e "s/|NAME|/$2/g
s/|KEY|/$3/g" "$moddir"/AlgScope.fw > "$2"AlgScope.fw

It first sets moddir to the name of the directory in which it resides, then uses sed to modify file `AlgScope.fw' in that directory. The script replaces the string |NAME| with the string specified by the +instance parameter of the original request. (If no +instance parameter was supplied, $1 is empty and every occurrence of the string |NAME| is simply deleted.) Similarly, it either replaces the string |KEY| with the string specified by the +referto parameter or deletes it. Finally, the name of the output file depends on the +instance parameter of the original request.

The output file will become part of the specification that contained the :inst request.

ExpInfo -- Information about remote attribute access

:ExpInfo

Obtain information about the processing of LIDO specifications, especially information concerning the expansion of remote attribute accesses (i. e. INCLUDING, CONSTITUENTS, and CHAIN). The generated listing describes how each remote access construct can be replaced by a set of equivalent computations propagating the accessed values through adjacent contexts. This file is useful if special difficult cases regarding problems with remote dependences arise.

Additional information about attribute dependences and attribute storage optimization can be obtained by adding the parameters +OrdI and +OptimI.

Example: foo.specs+OrdI:ExpInfo>

For a more detailed description of Liga's protocol options and more advanced options, see Liga Control Language Manual of Liga Control Language Manual.

OrdInfo -- Information about attribute dependence

:OrdInfo

Obtain information about the processing of LIDO specifications, especially information concerning the attribute dependences. The protocol provides for each grammar rule the set of direct dependences between attributes occurring in this rule.

Additional information about remote attribute access and attribute storage optimization can be obtained by adding the parameters +ExpI and +OptimI.

Example: foo.specs+ExpI:OrdInfo>

For a more detailed description of Liga's protocol options and more advanced options, see Liga Control Language Manual of Liga Control Language Manual.

OptimInfo -- Information about attribute storage optimization

:OptimInfo

Obtain information about the processing of LIDO specifications, especially information on attribute storage optimization. For each attribute this protocol provides information where this attribute is stored. Possible storage locations are "tree node", "global variable" and "global stack".

Additional information about remote attribute access and attribute dependences can be obtained by adding the parameters +ExpI and +OrdI.

Example: foo.specs+ExpI:OptimInfo>

For a more detailed description of Liga's protocol options and more advanced options, see Liga Control Language Manual of Liga Control Language Manual.

show -- LIDO Table Viewers showFe and showMe

:showFe
:showMe

Obtain a list of files that contain internal representations of LIDO text translated into readable text. :showFe shows LIDO text after the processing by the frontend of the Liga-System, :showMe shows the same information after attribute evaluator construction.

These informations can be useful for debugging a LIDO-Specification or to understand LIGA-Processing in more depth.

See Overview of SHOW - Debugging Information for LIDO, for more details.

instance -- Name an Instance of a Generic Module

+instance='string'

Use string to name the instance generated by the request. No spaces are allowed within the string, and characters meaningful to the shell that interprets the associated type-gnrc file may cause problems.

Not all generic modules allow distinct instances to be created. See the documentation of each such module for the precise effect of +instance.

referto -- Relate Instances of Generic Modules

+referto='string'

Use string to relate the current instance of a generic module to some specific instance of another generic module.

Not all generic modules allow relationships to be specified. See the documentation of each such module for the precise effect of +referto.


Previous Chapter Next Chapter Table of Contents