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

Tasks related to input processing

Next Chapter Table of Contents

Insert a File into the Input Stream

This module supports generating processors that include the contents of a file into the currently read input stream. The effect is the same as that known from the preprocessor cpp. There file inclusion is initiated by a cpp command like #include "myfile", here it is initiated by a computation of the language processor. It usually takes the file name from the text of a token found in the input stream.

Such facilities are used, for example, in some systems for functional or logical languages, where commands like

   use ["myfile"]
cause the inclusion of the given file at the place of the use command.

The file is included at the current position of the input stream when that computation is executed. That computation can either be specified within the concrete grammar to be initiated by the parser. Or it can be specified in a .lido specification. In the latter case the computation has to be executed while input is being read (and the tree is constructed bottom-up) to achieve the desired effect.

This module is instantiated without generic parameters by


The module provides the following function:

int NewInput (char *name)
It switches input reading to the file named name. When its end is encountered input reading is switched back to the next not yet processed token in the file that was the current when NewInput was called. The call of NewInput yields 1 if the file could be opened; otherwise it yields 0.

This facility is demonstrated by inserting a construct into our running example that allows to comprise sets of declarations on separate files and include them in the program text. Such declaration files may be used to specify common interfaces.

The file inclusion construct is introduced by the concrete productions

   Declaration:   FileInclusion ';'.
   FileInclusion: 'include' FileName.

We add a scanner specification for the terminal symbol FileName:

   FileName: C_STRING_LIT       [c_mkstr]
Hence, an input program may contain file inclusion commands like include "myfile"; wherever a Declaration is allowed.

The following .lido specification attaches the call of NewInput to the FileInclusion context:

   ATTR InpFileEx: int;
   RULE: FileInclusion ::= 'include' FileName COMPUTE
         .InpFileEx = NewInput (StringTable (FileName)) BOTTOMUP;

         IF (NOT (.InpFileEx),
         message (ERROR, CatStrInd ("can not open file ", FileName),
                  0, COORDREF));
The file name is specified to be the text of the FileName token. The computation has to executed while the input is read and the tree is built bottom-up. Hence it is specified BOTTOMUP.

Note: The above computation is executed when the FileInclusion tree node is built. Then the last token read from the current input stream is the terminating ; of the Declaration, due to the lookahead of the parser. Hence, the contents of the included file is being processed as if it stood immediately following that ; of the Declaration. Due to this reason it was essential to use two productions in the concrete grammar as stated above. A single production like

   Declaration:  'include' FileName ';'.
instead would delay insertion until the token following that ; has been read.

Next Chapter Table of Contents