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

Tutorial on Type Analysis

Previous Chapter Next Chapter Table of Contents


Operator Overloading

We here extend our language by binary and unary operators in order to demonstrate type analysis for expressions with overloaded operators.

Operators are overloaded in our language, i.e. an operator symbol like + may denote one of several operations, e.g. integer addition or logical disjunktion (or). The distinction is made using the types of the operands. Hence, we associate to an operator symbol like + an indication like AddOp, which represents a set of operators, like iAdd, bOr.

Each of the following rules associates an indication name to the attribute BinOpr.Indic. (The indication names are introduced below.)

Operator Indications[28]==

RULE: BinOpr ::= '+' COMPUTE BinOpr.Indic = AddOp; END;
RULE: BinOpr ::= '-' COMPUTE BinOpr.Indic = SubOp; END;
RULE: BinOpr ::= '*' COMPUTE BinOpr.Indic = MulOp; END;
RULE: BinOpr ::= '/' COMPUTE BinOpr.Indic = DivOp; END;

RULE: UnOpr ::= '+' COMPUTE UnOpr.Indic = PlusOp; END;
RULE: UnOpr ::= '-' COMPUTE UnOpr.Indic = NegOp; END;
RULE: UnOpr ::= '!' COMPUTE UnOpr.Indic = NotOp; END;
This macro is invoked in definition 34.

For each of the operator indications at least one meaning is specified by one of the following operation descriptions. The first component of an operation description relates it to an indication representing the operator symbol, the second component is a unique name for the operation.

The third component describes the signature of the operation expressed in terms of keys for predefined types.

All names are automatically introduced as names for definition table keys. They may be used explicitly in specifications to distinguish operations, or to associate properties to them.

For each language defined operator its signature is specified; operators that have the same signature can be comprised in one definition: Oil Operation Signatures[29]==

OPER
  iAdd, iSub, iMul, iDiv (intType,intType):intType;
  iPlus, iNeg            (intType):intType;
  bOr, bAnd              (boolType,boolType):boolType;
  bNot                   (boolType):boolType;
This macro is invoked in definition 35.

Next, we associate a set of operators to every indication. Here, for example the AddOp is overloaded with three operations: iAdd and bOr, and MulOp is overloaded with iMul and bAnd. All other indications have singleton sets: Oil indications[30]==

INDICATION
  AddOp:  iAdd, bOr;
  SubOp:  iSub;
  MulOp:  iMul, bAnd;
  DivOp:  iDiv;
  PlusOp: iPlus;
  NegOp:  iNeg;
  NotOp:  bNot;
This macro is invoked in definition 35.

The operation signatures as given above require operands to have exactly those types. E.g. a + 1 is illegal if a was of type boolType.

Type analysis for binary and unary expressions needs to compute the Type attribute of the whole expression (the result type of the operation) and the required types of operands (the corresponding type of the signature of the identified target operator). The latter may differ from the type of the operand in case that coercion is applied. We obtain these computations from the Expression module.

Operator contexts[31]==

SYMBOL BinOpr INHERITS OperatorSymbol END;

RULE: Expression ::= Expression BinOpr Expression COMPUTE
  DyadicContext (Expression[1], BinOpr, Expression[2], Expression[3]);
END;

SYMBOL UnOpr INHERITS OperatorSymbol END;
RULE: Expression ::= UnOpr Expression COMPUTE
  MonadicContext (Expression[1], UnOpr, Expression[2]);
END;
This macro is invoked in definition 36.

The key of the identified operation could be obtained by BinOpr.Oper or UnOpr.Oper, if necessary e.g. for translation.

Operator.con[32]==

Expression syntax[138]
This macro is attached to a product file.

Operator.sym[33]==

Operators[139]
This macro is attached to a product file.

Indications.lido[34]==

Operator Indications[28]
This macro is attached to a product file.

Operator.oil[35]==

Oil Operation Signatures[29]
Oil indications[30]
This macro is attached to a product file.

Operator.lido[36]==

Operator contexts[31]
This macro is attached to a product file.


Previous Chapter Next Chapter Table of Contents