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

Introduction of specification modules

Previous Chapter Table of Contents


Instantiation and Use of Modules

To use a specification module, e.g. the AlgScope module in the Name library, it is instantiated by the line

   $/Name/AlgScope.gnrc :inst
in a .specs file. All component specification files of the module are thus included in the set of specifications. A derivation
   x.specs:allspecs
can be used to inspect all the instantiated files.

The module instance obtained by the instantiation command above provides .lido symbol computations for a symbol named IdUseEnv, among other specifications.

The above instantiation command is sufficient if only one instantiation of the AlgScope module is used. Several instantiations of the same module are distinguished by generic instance names supplied as arguments of the instantiation

   $/Name/AlgScope.gnrc +instance=CtrlVar :inst
In this case another instance of the AlgScope module is generated having the instance name CtrlVar. It may coexist with the unnamed instance created above. The names of its files and of specified entities (symbols, attributes, etc.) are prefixed by the instance identifier, e.g. CtrlVarIdUseEnv.

Some modules have a second generic parameter referto. It may specialize the module in a second dimension on instantiation: The AlgScope module provides compuations for Key attributes in IdUseEnv contexts that represent applied occurrences of identifiers. In some situations it may be necessary to compute more than one Key attribute in an IdUseEnv context (if the identifier is bound in different name spaces). Hence, the referto of the AlgScope module modifies the names of the Key attributes. If the AlgScope module is instantiated by

   $/Name/AlgScope.gnrc +instance=CtrlVar +referto=Ctrl :inst
it provides computations for the attribute CtrlVarIdUseEnv.CtrlKey, among other computations.

Other modules use the referto parameter for different purposes, e.g. specifying the element type for a generic stack module.

If any of the two generic parameters instance or referto is omitted, as in the first two examples, their value is assumed to be the empty string.

If a module is instantiated as described its facilities can be used in certain components of the user's specification: Symbol computations as those provided by the AlgScope module are associated to symbols of the user's tree grammar by .lido constructs like

   SYMBOL UseIdent INHERITS IdUseEnv END;

Note: The symbols provided by modules are CLASS symbols in the sense of LIDO, i. e. they may not be used directly as tree grammar symbols. INHERITS constructs like the above are needed to bind their computations to symbols of user's specification. This means avoids accidental coincidence between names of tree grammar symbols and of module roles.

Further .lido specifications may be neccessary to supply information to or obtain information from the thus inherited computations.

Modules may also provide C functions (directly or via specifications for other tools), e.g. functions of the environment module in case of the AlgScope module. They may be called in computations of the user's .lido specification, or in user's C modules if the appropriate header file is included.

The same instantiation mechanism may be applied to include user defined modules:

   /user/Lib/ModName.gnrc:inst
instantiates the module ModName of a user library.

Such a module must contain of at least two files , e.g. /user/Lib/ModName.fw containing the module's specifications and /user/Lib/ModName.gnrc. The latter is an executable shell script that performs the generic module instantiation. It should have the following form:

   #!/bin/sh
   moddir=`expr $0 : '\(.*\)/.*' \| '.'`

   $1 -e "s/|NAME|/$2/g
   s/|KEY|/$3/g" "$moddir"/ModName.fw > "$2"ModName.fw
The last two lines use sed to substitute the instance parameter for any occurrence of |NAME| in the file ModName.fw and the referto parameter for any occurrence of |KEY|.


Previous Chapter Table of Contents