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

Frequently Asked Questions and Answers

Previous Chapter Next Chapter Table of Contents

Using Specifications Developed with Earlier Versions

Further hints for updates of specifications can be found in New Features of Eli Version 4.1, and in New Features of Eli Version 4.0.

Eli doesn't find module include files any more

    4 |#include "envmod.h"
(test.c) cannot find include file: "envmod.h"

Eli no longer automatically extracts all modules that are mentioned somewhere in #include files. For example, in order to add the envmod module to a specification, some .specs file must contain the line $/Name/envmod.specs. ($ in this context is a shorthand for the package directory in the cache currently being used.)

Migrating the usage of Module IdPtg

> Am I correct in noting that the link between the key table and the
> string table containing non-literal strings was possible via the
> following (in Eli3)

> ATTR Key:  DefTableKey;
> RULE Name: xName ::=  xIdent
>         xName.Ptg = xIdent.Ptg;
>         xName.Sym = xIdent.Sym;
> END;

There are two different tasks:

  • Consistent renaming for name analysis (that's what Key's are for)
  • Output text generation with Ptg (based on the string representation)

There is Module Library support for both tasks. In your example you use

  • IdDefNest for name analysis
  • IdPtg for output text generation for identifiers

IdPtg computes an inherited attribute Ptg containing the PTG representation of the identifier to which IdPtg is inherited. IdPtg could be inherited to terminals (as you do above) in earlier Eli versions. The precondition for the application of IdPtg is that the symbol to which IdPtg is inherited provides an attribute named Sym containing the string table index of the associated identifier.

Since Eli Version 4.x, inheritance to terminals is no longer possible. That is the only difference for your application. So you simply have to move your PTG computation one level up to the symbol xName. This should give you:

   RULE Name: xName ::=  xIdent
        xName.Sym = xIdent.Sym;

which even looks a bit simpler than the 3.8 solution.

Why does C_STRING_LIT not use c_mkstr?

> I'm surprised that C_STRING_LIT now uses mkstr instead of c_mkstr.
> What's the reason?

c_mkstr had the problem that if the string in the source text contained a null character, that string was silently truncated:

        "abc\0def" became "abc"

This is a consequence of the string storage module implementation, and could only be avoided by placing a high cost on all string operations. To avoid the problem, c_mkstr was changed to report an error if it found "\0" in a string. The changed c_mkstr no longer implements C strings, so it could not be used as the processor for C_STRING_LIT.

Previous Chapter Next Chapter Table of Contents