Eli   Documents

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

Migration of Old Library Module Usage

Next Chapter Table of Contents


Migration of Eli Version 3.8 modules

This section gives a quick reference to modifications that have been made in library modules of Eli version 3.8. Users who are still using modules of Eli version 3.6 first see Migration of Eli Version 3.6 modules.

In all library modules that provide LIDO specifications the symbol roles are now specified to be CLASS SYMBOLs. This classification avoids accidental name coincidences between grammar symbols and roles provided by modules.

As a consequence such a symbol may not occur as a name of a tree grammar symbol. It rather has to be inherited by a tree grammar symbol:

  RULE: Program ::= Source END;
  SYMBOL Program INHERITS RootScope END;
Constructs like
  RULE: RootScope ::= Source END;
will cause error messages. Hence, the grammar symbols have to be renamed consistently in such cases.

We assume that some names like IdDef or IdUse have been used in this now illegal way. In order to simplify migration those module roles are now renamed IdDefScope and IdUseEnv. Hence, specifications which use IdDef or IdUse as grammar symbols may continue to do so. Only

  SYMBOL IdDef INHERITS IdDefScope END;
  SYMBOL IdUse INHERITS IdUseEnv END;
is to be added.

The following table contains a list symbol roles that are provided by modules of Eli version 3.8 and have been changed in the current version. All these adaptions refer to modules of the Name library.

The following library modules have been modified:

BitSet
Use $/Adt/BitSet.fw instead of instantiation. (see Bit Sets of Arbitrary Length of Abstract data types to be used in specifications)

DynSpace
Use $/Adt/DynSpace.fw instead of instantiation. (see Dynamic Storage Allocation of Abstract data types to be used in specifications)

LeafPtg
Use $/Output/LeafPtg.fw instead of instantiation. (see PTG Output for Leaf Nodes of Tasks related to generating output)

Indent
Use $/Output/Indent.fw instead of instantiation. (see Indentation of Tasks related to generating output)

List
The module uses obstack directly instead of using module DynSpace.

OutStr
Use $/Output/OutStr.fw instead of instantiation. (see Output String Conversion of Tasks related to generating output)

Name Analysis
There are minor modifications in all name analysis modules. See table of entity modifications below, and (see Basic Scope Rules of Name analysis according to scope rules) (see Scopes Being Properties of Objects of Name analysis according to scope rules) (see Inheritance of Scopes of Name analysis according to scope rules)

PreDefId
Instead of instantiating the module PreDefId once for each predefined identifier, all predefined identifiers are be described in one file. Its name is supplied as referto parameter. (see Predefined Identifiers of Name analysis according to scope rules)

PropLib
Use $/Prop/PropLib.fw instead of instantiation. (see Some Useful PDL Specifications of Association of properties to definitions)

Type CType BuType
These modules are still usable. But they are not maintained anymore. It is recommended to use the module Typing (See Typed Entities of Type Analysis Reference Manual,) instead. The functionality of CType and BuType, where the C-like name analysis scheme is also imposed upon type analysis is not supported by Typing. Modules having corresponding facilities are not yet available.

The following entities of library modules have been modified:

AnyScope.GotScopes
Replaced: use RootScope.GotScopeProp (see Scopes Being Properties of Objects of Name analysis according to scope rules)

AnyScope.GotScopesDefs
Replaced: use RootScope.GotScopeProp (see Scopes Being Properties of Objects of Name analysis according to scope rules)

IdDef
Renamed to IdDefScope. (see Basic Scope Rules of Name analysis according to scope rules)

IdDefScopeProp
Deleted: The scope property is now associated to a key in the context of the role RangeScopeProp. (see Scopes Being Properties of Objects of Name analysis according to scope rules)

IdGetScopeProp
Deleted: Use the GetScope function explicitly if necessary. (see Scopes Being Properties of Objects of Name analysis according to scope rules)

IdUse
Renamed to IdUseEnv. (see Basic Scope Rules of Name analysis according to scope rule)

IdUseScope
modified: The default scope to be used can not be changed (see Basic Scope Rules of Name analysis according to scope rule); use IdUseScopeProp if necessary (see Scopes Being Properties of Objects of Name analysis according to scope rule).

InheritScopeProp
Renamed and modified: use InheritScope. (see Inheritance of Scopes of Name analysis according to scope rule)

RangeScopeProp
Modified: A computation of THIS.ScopeKey for the key to which the scope is to be associated has to be provided, instead of THIS.Scope. (see Scopes Being Properties of Objects of Name analysis according to scope rule)


Next Chapter Table of Contents