General Information

	Eli: Translator Construction Made Easy
	Global Index
	Frequently Asked Questions
	Typical Eli Usage Errors

Tutorials

	Quick Reference Card
	Guide For new Eli Users
	Release Notes of Eli
	Tutorial on Name Analysis
	Tutorial on Scope Graphs
	Tutorial on Type Analysis
	Typical Eli Usage Errors

Reference Manuals

	User Interface
	Eli products and parameters
	LIDO Reference Manual
	Typical Eli Usage Errors

Libraries

	Eli library routines
	Specification Module Library

Translation Tasks

	Lexical analysis specification
	Syntactic Analysis Manual
	Computation in Trees

Tools

	LIGA Control Language
	Debugging Information for LIDO
	Graphical ORder TOol

FunnelWeb User's Manual

	Pattern-based Text Generator
	Property Definition Language
	Operator Identification Language
	Tree Grammar Specification Language
	Command Line Processing
	COLA Options Reference Manual

Generating Unparsing Code

Monitoring a Processor's Execution

Administration

System Administration Guide

Name analysis according to scope rules

Predefined Identifiers

In most languages some identifiers are predefined, e.g. names for basic types or for constants like true and false. Their definitions are valid in any program as if they were bound in the outermost environment. The two modules PreDefine and PreDefId described here allow to easily introduce such predefinitions. They require that one of the basic scope rule modules (see Basic Scope Rules) is used.

Both modules PreDefine and PreDefId are to be instantiated to introduce a set of predefined entities in a name space.

The implementation of the modules use two functions which introduce a source identifier into the identifier table and establish a binding for it in some environment. These functions can be used directly for example in cases where predefinitions are to be established for other environments than the outermost one. Those functions are described below.

The PreDefine module is instantiated by

   $/Name/PreDefine.gnrc +instance=NAME +referto=IDENT :inst

The referto parameter specifies the symbol name used for identifier terminals in the grammar. The referto parameter must not be omitted.

If a grammar has several identifier terminal symbols predefinitions can be made using several instances of this module, if they belong to different name spaces.

The module provides two functions NAMEPreDefine and NAMEPreDefineSym which are called by the instance of the PreDefId module. NAMEPreDefineSym inserts a string into the identifier module to be used as an IDENT symbol. NAMEPreDefine additionally binds that symbol to a key in the root environment given by the global variable NAMERootEnv.

The predefined identifiers are to be described in a file as explained below. The name of that file has to be given as referto parameter of the instantiation of the PreDefId module:

   $/Name/PreDefId.gnrc +instance=NAME +referto=(FILENAME) :inst

   $/Name/PreDefId.gnrc +referto=(Predef.d) :inst

The description file contains a sequence of macro calls, one for each predefined identifier, e.g.

  PreDefKey ("int", intKey)
  PreDefKey ("real", realKey)
  PreDefSym ("external", externSym)
  PreDefSymKey ("fail", failSym, failKey)
  PreDefSymKeyBind ("write", writeSym, writeKey, writeBind)

Each call of one of the macros establishes a predefinition for one identifier, and makes the result accessible via the supplied variable names. Usually not all of those variables are needed. Hence, the available macros differ in the combinations of those variables. We first explain the most general macro. The meanings of the other macros are deduced from it.

PreDefSymKeyBind ("xxx", sym, key, bind) encodes the character string xxx as an identifier, stores it in the identifier table, and stores the encoding in the int variable sym.

Note: The string need not obey the rules specified for the notation of IDENT symbols. That facility can be used if artifacts are predefined, which can not be referred to by a name in a program.

key is introduced as a PDL known key.

key is bound to sym in the environment NAMERootEnv. That binding is assigned to the Binding variable bind. The key, the identifier code, and the environment can be accessed from the Binding value (KeyOf, IdnOf, EnvOf).

The variables sym and bind and the known key key are defined, exported, and made accessible via a .HEAD.phi specification. The binding is established and the assignments are made in the initialization phase of the processor. Hence, the results can be used only after that phase, i.e. during all computations in the tree.

According to the above description the following macro call

  PreDefSymKeyBind ("write", writeSym, writeKey, writeBind)

  int writeSym;
  DefTableKey writeKey;
  Binding writeBind;

The other macros that are provided cause a subset of the effects described for PreDefSymKeyBind:

PreDefSymKey ("xxx", sym, key) As described above, except: The binding is established but not assigned to a variable.

PreDefKeyBind ("xxx", key, bind) As described above, except: The symbol is encoded and stored in the identifier table, but the encoding is not assigned to a variable.

PreDefKey ("xxx", key) As described above, except: Neither the symbol encoding nor the binding are stored in a variable.

PreDefBind ("xxx", bind) As described above, except: The symbol encoding is not stored in a variable. The key is created dynamically rather than as a known key. Both, symbol encoding and the key can be accessed via the stored Binding value.

PreDefSym ("xxx", sym) encodes the character string xxx as an identifier, stores it in the identifier table, and stores the encoding in the int variable sym. No binding is established.

The thus introduced variables and known keys may be used in .lido specifications; the known keys may be additionally used in any specification where PDL defined entities are available.

The described modules are based on a C module which provides the following two functions. They may be used directly to establish bindings in other environments than the outermost one, for example. In that case it is sufficient to use the module PreDefMod.specs. Then the modules PreDefine and PreDefId need not be instantiated, if the macros explained above are not used.

The two functions are:

void PreDefineSym (char *name, int code, int *sym)

The string name is encoded with the given syntax code. That is usually the code of the symbol used for identifier terminals in the grammar (cf. the referto parameter in the instantiation of the module PreDefine explained above). *sym is set to the symbol index.

void PreDefine (char *name, int code, int *sym, Environment env, DefTableKey key,Binding *bind)

The string name is encoded with the given syntax code which is bound to key in the given environment env. *sym is set to the symbol index. *bind is set to the created binding, if successful, otherwise to NoBinding.

In our running example we introduce predefined names for some basic types and for Boolean constants by the module instantiations

   $/Name/PreDefine.gnrc +referto=Ident :inst
   $/Name/PreDefId.gnrc +referto=(Predef.d):inst

  PreDefKey ("int", intKey)
  PreDefKey ("real", realKey)
  PreDefKey ("bool", boolKey)
  PreDefKey ("true", trueKey)
  PreDefKey ("false", falseKey)

   trueKey -> TypeOf = {boolType};
   falseKey -> TypeOf = {boolType};