General Information

 o Eli: Translator Construction Made Easy
 o Global Index
 o Frequently Asked Questions

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

Reference Manuals

 o User Interface
 o Eli products and parameters
 o LIDO Reference Manual

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

 Questions, Comments, ....

Tutorial on Type Analysis

Previous Chapter Next Chapter Table of Contents


Declaration of Typed Objects

We here consider a variable declaration as an example for a language construct that defines a typed object. In our language a variable declaration may define several variables. An ObjDecl states the type and the name for each of them. Until now we allow types to be denoted only by predefined type identifiers, TypeUseIdent. Further forms of TypeDenoter are specified below.

We use the module Typing for support of type analysis.

Declare.specs[14]==


$/Type/Typing.gnrc:inst

This macro is attached to a product file.

Types are represented by DefTableKeys. Such a key is created for each program construct which denotes a particular type. The unknown type is represented by NoKey. Typed objects, like variables, have the property TypeOf that represents their type.

The pair of module roles TypedDefinition and TypedDefId support the pattern of declaring typed objects: ObjDecl has the role TypedDefinition, i. e. a construct that specifies the types of all TypedDefIds in its subtree. The attribute ObjDecl.Type has to be set appropriately.

Declare.lido[15]==


SYMBOL ObjDecl INHERITS TypedDefinition END;
SYMBOL DefIdent INHERITS TypedDefId END;

ATTR Type: DefTableKey;

RULE: ObjDecl ::= TypeDenoter DefIdent COMPUTE
  ObjDecl.Type = TypeDenoter.Type;
END;

This macro is attached to a product file.

The module roles TypedUseId and TypeDefUseId distinguish between used names of typed objects and used names of types. The corresponding check roles issue messages if that classification is violated.

The use of TypedUseId causes the attribute UseIdent.Type to be set to the type defined for the object.

TypeUseIdent.lido[16]==


SYMBOL UseIdent INHERITS TypedUseId, ChkTypedUseId END;
SYMBOL TypeUseIdent INHERITS TypeDefUseId, ChkTypeDefUseId END;

RULE: TypeDenoter ::= TypeUseIdent COMPUTE
  TypeDenoter.Type = TypeUseIdent.Type;
END;

This macro is attached to a product file.

In order to report some results of the type analysis we associate the string valued property TypeName to every type key.

The specification [KReset] causes an additional definition table operation to be created, such that a call KResetTypeName (k, v) sets the value v to the key k and returns that key. That allows us to nest several calls of functions which set properties to one key. The definition of KReset is obtained from the PropLib module which is available when using the Typing module.

PrtType.pdl[17]==

 
TypeName: CharPtr [KReset]; "Strings.h"

intType ->  TypeName = {"int"};
realType -> TypeName = {"real"};
boolType -> TypeName = {"bool"};
voidType -> TypeName = {"void"};

This macro is attached to a product file.

For every used identifier that string is to be printed:

PrtType.lido[18]==

 
SYMBOL UseIdent INHERITS PrtType END;

SYMBOL PrtType COMPUTE
  printf ("line %d Type %s\n", LINE,
          GetTypeName (THIS.Type, "no type name"));
END;

This macro is attached to a product file.


Previous Chapter Next Chapter Table of Contents