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

New Features of Eli Version 4.4

Previous Chapter Next Chapter Table of Contents

New error reporting for parser conflicts

We have a new default format for reporting parser conflicts: For each conflict, it provides an example of a derivation leading to each of the conflicting situations. Our hope is that it will be easier to determine the cause of the conflict with this information than with the simple printout of the state that was given previously.

Example

Here is a simple example (see Explanation of the grammar for word classification of Guide for New Eli Users): 

text: set_defs .
set_defs: set_def / set_defs set_def .
set_def: set_name '{' set_body '}' .
set_name: word .
set_body: elements / .
elements: set_element / elements set_element .
set_element: word .

Suppose that we make the grammar non-LALR by removing the brackets around set_body. Here is the result of applying the default :parsable: 

Conflicting Derivations
=======================

************************************************************************
   *** shift-reduce conflict on: word

text EOF
set_defs
set_defs set_def
|        set_name set_body
|        word
|
set_def
set_name set_body
         .  [REDUCE] set_body ->  {word} ?

text EOF
set_defs
set_def
set_name set_body
         elements
         set_element
         . word  [SHIFT] set_element -> word .  ?

************************************************************************
   *** shift-reduce conflict on: word

text EOF
set_defs
set_defs set_def
|        set_name set_body
|        word
|
set_def
set_name set_body
         elements .  [REDUCE] set_body -> elements  {word} ?

text EOF
set_defs
set_def
set_name set_body
         elements
         set_element
         . word  [SHIFT] set_element -> word .  ?

************************************************************************

This output gives two examples in which the parser will be unable to decide what to do when it sees a word. Each example shows two conflicting derivations (a derivation is the reverse of the parser's reduction process, see How the generated parser determines phrase structure of Syntactic Analysis Manual).

Each derivation begins with text EOF. Succeeding lines are the result of rewriting a single nonterminal symbol by applying some production of the grammar. The result of a rewriting step is aligned with the symbol being rewritten. Thus we can rewrite text to set_defs, and then rewrite set_defs to set_defs set_def.

The lines adjacent to the vertical bar show how the lookahead symbol can be derived: set_def is rewritten to set_name set_body, and then set_name is rewritten to word.

Below the vertical bar, the main derivation continues by rewriting the symbol at the top of the bar. In this case, set_defs is rewritten as set_def, which is rewritten as set_name set_body in turn. The final line of the first derivation shows the action that the parser would take at that point: reducing an empty string to a set_body in the presence of the lookahead symbol word.

This first derivation of the first example shows that the parser could recognize an empty set body and consider that the lookahead symbol word is the name of the next set. You should convince yourself that the second derivation of the first example shows how the parser could consider the lookahead symbol word in this context to be the first element of the first set. This ambiguity is clearly the result of omitting the opening brace. Without that delimiter, there is no way to make the decision.

The second example also involves a word symbol. Here the question is whether the word is the name of the next set or whether it is the next element of the current set. This error is the result of omitting the closing brace. Again, without that delimiter, there is no way to make the decision.

Help

If you have conflicts in your grammar, the :help derivation will show you messages for a type-`pgsconflict' file. Each message specifies the type of conflict and the set of terminals causing the conflict. Clicking the help browser's Edit button while you are looking at the message screen will bring up your editor on the type-`pgsconflict' file, which contains the sample derivations that illustrate how the conflicts arise (see Example).

Parsable

The :parsable derivation will give you the new diagnostics by default. You can still obtain the state printout by supplying a +pgsOpt parameter to the derivation: 

-> sets.specs +pgsOpt='S' :parsable <

Here the string 'S' requests "standard" processing.

Previous Chapter Next Chapter Table of Contents