DIANA. An Intermediate Language for Ada: Revised Version (Lecture Notes in Computer Science)

Lecture Notes in Computer Science Edited by G. Goos and J. Hartmanis

161 DIANA An Intermediate Language for Ada Revised Version

Edited by G. Goos, W. A. Wulf A. Evans, Jr., and K.J. Butler

Springer-Verlag Berlin Heidelberg New York Tokyo 1983

Editorial Board D. Barstow W. Brauer R Brinch Hansen D. Gries O. Luckham C. Moler A. Pnueli G. SeegmSller J. Steer N. Wirth

Editors

Gerhard Goos Universit~t Karlsruhe, ~nstitut f~Jr ~nformatik 11 7500 Karlsruhe 1, FRG William A. Wutf Arthur Evans, Jr. Kenneth J. Butler Tartan Laboratories, hc. 477 Melwood Ave., Pittsburgh, PA 15213, USA

DIANA was maintained and revised by TARTAN Laboratories Inc. for the ADA Joint Program Office of the Department of Defense under contract number MDA903-82-C-0148 (expiration date: 1983 February 28). The Project Director of DIANA Maintenance for TARTAN was Arthur Evans, Jr.

1SBN 3-540-12695-3 Springer-Vedag Berlin Heidelberg New York Tokyo ISBN 0-387-12695-3 Springer-Verlag New York Heidelberg Berlin Tokyo This work is subjectto copyright.Ail rightsare reserved,whetherthe wholeor partof the material is concerned,specificallythose of translation,reprinting,re-useof illustrations,broadcasting, reproduction by photocopying machineor similarmeans,and storagein data banks.Under § 54 of the GermanCopyrightLaw where copies are madefor other than privateuse,a fee is payableto "VerwertungsgesellschaftWort~,Munich. © by Springer-VerlagBerlin Heidelberg1983 Printed in Germany Printing and binding: BeltzOffsetdruck, Hemsbach/Bergstr. 2145/3140-543210

DIANA Reference Manual

Page ill TABLE OF CONTENTS

Abstract

1

Acknowledgments

3

Preface

5

1. Introduction

7

1.1. Design Principles 1.1.1. Original Design 1.1.2. Principles Governing Changes 1.1.3. What is a "DIANA User' 1.1.4. Specification of DIANA 1.2. Structure of the Document 1.3. Attribution Principles of DIANA i . 3 . 1 . Static Semantic Information 1.3.2. What is "Easy to Recompute'? 1.3.3. Other Principles 1.3.4. Example,s 1.4. Notation 1.4.1. Example of the IDL Notation 1.4.2. Specification of Representations 1.4.3. Example of a Structure Refinement 1.4.4. DIANA Notational Conventions

8 9 11 12 14 16 17 t8 19 20 20 21 25 25 28 29

2. Definition of the Diana Domain

31

3. Rationale

79

3.1. Comparison with the Abstract Syntax Tree 3.1.1. Semantic Distinctions of Constructs 3.1.2. Additional Concepts 3.1.3. Tree Normalizations 3, 1.4. Tree Transformation According to the Formal Definition 3.1.5. Changes to the AST 3.2. Consequences of Separate Compilation 3 . 2 . 1 . Forward References 3.2.2. Separately Complied Generic Bodies 3.3. Name Binding 3.3.1. Defining Occurrences of Identifiers 3.3.2. Used Occurrences of identifiers 3.3.3. Multiple Defining Occurrences of Identifiers 3.3.4. Subprogram Calls

80 80 81 81 82 82 83 84 84 85 85 86 87 87

Page IV 3.4.

3.5.

3.6,

3.7.

3.8.

3,9,

3,10.

DIANA Reference Manual

Treatment of Types 3 . 4 . 1 . Machine Dependent Attributes 3 . 4 . 2 . Type Specifications 3 . 4 . 2 . 1 . Structural Type Information 3.4, 2, 2, Subtype Specifications 3 . 4 . 2 . 3 . Derived Types 3 . 4 . 2 . 4 . incomplete and Private Types 3 . 4 . 2 . 5 . Anonymous Array Types 3 . 4 . 2 . 6 . Anonymous Derived Types 3 . 4 . 3 . Type Specifications in Expressions 3.40 3. t . Examples for Constraints of Expressions 3 . 4 . 3 . 2 . Type Specifications for Names Entities with Several Declaration Points 3 . 5 . 1 . Type Declarations 3.5, 1.1. incomplete Type Declarations 3 . 5 . 1 . 2 . Private Types 3, 5 . 1 . 3 . Discrimtnant Parts 3 . 5 . 2 , Deferred Constants 3 . 5 . 3 . Subprograms 3 . 5 . 3 . ]. Qeclaration and Body in One Declarative Part 3 . 5 . 3 , 2. Declaration and Body tn Different Compilation Units 3.5, 3, 3. Subprogram Bodies as subunits 3, 5, 3.4. Entries and Accept Statements 3 , 5 . 3 . 5 . Subprogram Formals 3 . 5 . 4 , Packages 3 . 5 . 5 . Tasks 3 . 5 . 5 . t , Task Types and Task Bodies 3, 5 . 5 , 2 . Single Tasks and Task Bodies 3 . 5 . 6 , Generic Units Treatment of lnstantlations 3 . 6 . 1 , instantiation of Subprograms 3 . 6 . 2 . Instantiation of Packages Treatment of Renaming 3 . 7 . 1 . Renaming of Subprograms 3, 7.2. Renaming of Packages 3 . 7 . 3 . Renaming of Tasks ~mplementation Dependent Attributes 3 . 8 . 1 . Evaluation of Static Expressions 3.8, 2, Representation of identifiers and Nutnbers 3 . 8 . 3 . Source Positions 3 . 8 . 4 , Comments 3 . 8 . 5 . Predefined Operators and Built-In Subprograms Equality and Assignment Summary of Attributes 3.10.1. Lexical Attributes 3 . 1 0 . 2 . Semantic Attributes 3 . 1 0 . 3 , Code Attributes 3. 10.4, Unnecessary Attributes

89 90 90 go gl 93 96 96 g6 g6 g7 g8 102 103 103 t04 105 106 106 107 108 109 110 110 111 112 t13 113 t!4 115 tt6 118 118 118 118 121 121 t21 122 122 122 123 123 124 124 125 128 128

DIANA Reference Manual

4. Definition of the Diana Operations 4.1. 4.2. 4.3. 4.4. 4.5. 4, 6.

The DIANA Operations DIANA'S Use of Other Abstract Data Types Summary of Operators General Method for Deriving a Package Specification for DIANA Deriving a Specific ADA Package The DIANA Package In ADA

Page V

129 129 130 130 131 132 133

5. External Representation of DIANA

145

6. implementation Options

153

h The Predefined Environment

157

1.1. I, 2. I. 3. h 4.

157 157 158 158

Universal Types The Predeflned Language Environment Attributes Pragmas

II. The Abstract Parse Tree

161

III. Reconstructing the Source

165

Ill. 1, General Principles IIh 2. Examples IIh 3, Normalizations of the Source t11.4, Comments

165 166 167 168

IV. Diana Summary

171

V. Diana Names

185

Vl. Diana Attributes

193

Vh 1, Vh 2, Vh 8. VI,4.

193

Index

Structural Attributes Lexlcal Attributes Semantic Attributes Code Attributes

194

195 196 199

Page VI

DIANA Reference Manua|

The views, opinions, and findings contained In this report are those of the authors and shoutd not be construed as an official Department of Defense position, policy, or decision, unless designated by other offlclat documentation.

Page Vlt

DIANA Reference Manual UST OF FIGURES

Figure Figure Figure Figure Figure Figure Flgure Flgure Figure Flgure Flgure Figure Figure Figure Figure Figure

I-1 : I-2: I-8: 3-1: 3-2: 8-8: 3--4: S-5: 3-6: 8-7: S-8: 3-9: 3-10: 3-11: 8-12: 3-13:

Figure Figure Figure Figure Flgure Figure Figure Figure Figure Flgure Figure Flgure Flgure Figure Figure

3-14: 3-15: 3-16: 3-17: 3-18: 3-19: 3-20: 3-21: 3-22: 3-23: 4-I : 5-I : 5-2: 5-3: I-I:

TypograLphlc Conventions used In this Document Example of IDL Notation Some Trees In ExpresslonTree Example of a Necessary Tree Transformation Call of Implicitly-Defined Inequality Float constraint created by DIANA DIANA Form of type/subtype Specification An Example for Derived Enumeration Types Constraints on Stices and Aggregates Constraints on Slices and Aggregates Constraints on String Uterals Example of an incomplete Type Example of a Private Type Example of a Deferred Constant Subprogram Structure Subprogram Declaration and Body in Different Compilation Units Example of a Subprogram Body as a subunlt (I) Example of a Subprogram Body as a subunit (11) Example of a Package Body as a subunlt Example of a Task Type and Body Example of Single Tasks Example of a Generic Body as a subunit Instantlatlon of a Generic Procedure Instantiation of a Generic Package Renaming a Procedure Renaming a Package Sketch of the DIANA Package External DIANA Form Example Expression Tree of tDL Notation Example AnotherTree of IDL Example of a Pragma

21 26 27 83 89 92 94 95 99 100 101 104 105 107 108 109 110 111 112 113 114 115 117 119 120 120 134 146 147 149 160

Abstract

Page 1

ABSTRACT

This d o c u m e n t describes Diana, for ADA.

a Descriptive Intermediate Attributed Notation

being both an Introduction and reference manual for It,

DIANA Is an

abstract data type such that each object of the type is a representation of an Intermediate form of an ADA program.

Although the Initial uses of this form were

for c o m m u n i c a t i o n between the Front and Back Ends of an ADA c o m p i l e r . also intended to be suitable for

It is

use with other tools in an ADA p r o g r a m m i n g

environment. DIANA resulted intermediate forms:

from

a m e r g e r of the

TCOL and AIDA.

best properties

of two earlter similar

Acknowledgments

Page 3 ACKNOWLEDGMENTS

A~?,KNOWLIEOGMENTSFOR THE FIRST EDIT1ON DIANA Is based on two earlier proposals for Intermediate forms for ADA programs: TCOL and AIDA. It could not have been designed without the efforts of the two groups that designed these previous schemes. Thus we are deeply grateful to: °

AIDA: Manfred Dausmann, Guido Persch, Sophia Drossopoulou. Gerhard Goos, and Georg Wlnterstein--all from the University of Karlsruhe.

° TCOL: Benjamin Brosgol (Intermetrics), Joseph Newcomer (Carnegie-Mellon University), David Lamb (CMU), David Levine (Intermetrics), Mary Van Deusen (Prime). and Win. Wulf (CMU). "The actual design of DIANA was conducted by teams from Karlsruhe, Carnegie-Mellon, Intermetrics and Softech. Those involved were Benjamin Brosgol, Manfred Dausmann, Gerhard Goos. David Lamb, John Nestor, Richard Simpson, Michael Ttghe, Larry Welssman, Georg Wlntersteln, and Win. Wulf. Assistance in creation of the document was provided by Jeff Baird, Dan Johnston, Paul Knueven, Glenn Marcy, and Aaron Wohl--atl from CMU. We are grateful for the encouragement and support provided for this effort by Horst Clausen (IABG), Larry Druffel (DARPA), and Marty Wolfe (CENTACS), as well as our various funding agencies. Finally, the design of DIANA was conducted at Egltn Atr Force Base with substantial support from Lt. Col. W. Whitaker. We could not have done It without his aid.

DIANA'S original design was funded by Defense Advanced Research Projects Agency (DARPA), the Air Force Avionics Laboratory, the Department of the Army, Communication Research and Development Command, and the 8undesamt fuer Wehrtechntk und Beschaffung. Gerhard Goos Win. A. Wulf Editors, First Edition

Page 4

DIANA Reference Manuat

ACKNOWLE'tX~MENTS FOR THIS EDrI1ON Subsequent to DIANA'S original design, the AOA Joint Program Office of the United States Department of Defense has supported at TARTAN Laboratories Incorporated a continuing effort at revision. This revision has been performed by Arthur Evans, J r . , and Kenneth J. Butler, with considerable assistance from John R. Nestor and Win. A. Wulf, all of TARTAN. We are grateful to the following for their many useful comments and suggestions. = Georg Winterste{n, Manfred Dausmann, Sophia Drossopoulou, Guido Persch, and Juergen Uhl, all of the Karlsruhe ADA implementation Group; ° Julte Sussman and Rich Shapiro of Bolt Beranek and Newman Inc. ; and to ° Charles Wetherell and Peggy Qutnn of Bell Telephone Laboratories Additional comments and suggestions have been offered by Grady Booch, BenJamin Brosgol, Gtl Hanson, Jeremy Holden, Bernd Krleg-Brueckner, David Lamb, H . - H . Nageti, Teri Payton, and Richard Simpson. We thank the ADA Joint Program Office (AJPO) for supporting DIANA'S revision, and in particular Lt. Colonel Larry Druffel, the director of A J P O ~ Valuable assistance as Contracting Officer's Technical Representative was provided first by Lt, C o m m a n d e r Jack Kramer and later by It. Commander Brian Schaar; we are pleased to acknowledge them.

DIANA Is being maintained and revised by TARTAN Laboratories Inc. for the ADA Joint Program Office of the Department of Defense under contract number MDA903-82-C-0148 (expiration date: 1983 February 28). The Project Director of DIANA Maintenance for TARTAN |S Arthur Evans, Jr.

Preface

Page 5

PREFACE

PREFACE TO THE FIP~r EDITION This d o c u m e n t defines Diana, an Intermediate form of ADA [7] p r o g r a m s that Is especially suitable for communication betwoen the front and Back Ends of ADA compilers. It Is based on the formal definition of ADA [6] and resulted from the m e r g e r of the best aspects of two previous proposals: AIDA [4, 101 and TCOL [2]. Although DIANA IS primarily Intended as an Interface between the parts of a c o m p i l e r , it is also suttab|e for other p r o g r a m m i n g support tools and carefully retains the structure of the original source program. The definition of DIANA given here is expressed in another notation, IDL, that is formally defined iin a separate document tg]. The present d o c u m e n t is, however, c o m p l e t e l y s e l f - c o n t a i n e d ; those aspects of IDL that are needed for the DIANA definition are Informally described before they are used. Interested readers should consult the IDL formal description either If they are c o n c e r n e d with a m o r e precise definition of the notation or tf they need to define other data structures In an ADA support environment. In particular, Implementors may need to extend DIANA In various ways for use wlth the tools In a specific e n v i r o n m e n t , and the IDL d o c u m e n t provides Information on how this may be done. This version of DIANA has been "frozen" to meet the needs of several groups who require a stable definition in a very short timeframe, We Invite c o m m e n t s and criticisms for a l o n g e r - t e r m review. We expect to r e - e v a l u a t e DIANA after s o m e practical experience with using it has been accumulated,

Page 6

DIANA Reference Manual

PREFACE TO TIHII8 EDmON S i n c e first publication of the DIANA Reference Manual In March, 1981, further d e v e l o p m e n t s in c o n n e c t i o n with ADA and DIANA have r e q u i r e d revision of DIANA, These d e v e l o p m e n t s include the following: - The o r i g i n a l DIANA design was based on ADA as defined in the July 1980 ADA L a n g u a g e Reference Manual [7]. referred to hereafter as ADA-80; the p r e s e n t revision is based on ADA as defined in the July 1982 ADA LRM [8]. referred to hereafter as ADA-82. ° E x p e r i e n c e with use of DIANA has revealed o r i g i n a l d e s i g n ; t h e s e have been c o r r e c t e d ,

errors

and

flaws

in

the

This publication reflects c u r best efforts to c o p e with the conflicting pressures on us both to impact m i n i m a l l y on existing i m p l e m e n t a t i o n s and to create a l o g i c a l l y d e f e n s i b l e design, TARTAN L a b o r a t o r i e s Inc. Invites any further c o m m e n t s and c r i t i c i s m s on DIANA in g e n e r a l , and this version of the reference manual In particular. Any c o r Paper r e s p o n d e n c e may be sent vie ARPANet mall to DIANA-QUERY@USC-ECLB. mall may be sent to DIANA Manual TARTAN L a b o r a t o r i e s Inc. 477 Melwood Avenue Pittsburgh PA 15213 We believe the c h a n g e s made to DIANA make no undue c o n s t r a i n t on any DIANA users or potential DIANA users, and we wish to hear from those who p e r c e i v e any of these c h a n g e s to be a p r o b l e m .

Page 7

Introduction

CHAPTER 1 INTRODUCTION

The purpose of standardization is to aid the creative craftsman, not to enforce the common mediocrity [1"1].

In a p r o g r a m m i n g e n v i r o n m e n t such as that envisioned for ADA1, there will be a n u m b e r of t o o t s - - f o r m a t t e r s ( p r e t t y p r i n t e r s ) , reference generators, t e s t - c a s e g e n e r a t o r s ,

l a n g u a g e - o r i e n t e d editors,

and the like.

in g e n e r a l ,

cross-

the input

and output of these ~ools is not the source text of the p r o g r a m being d e v e l o p e d ; instead it is some intermediate form that has been produced by a n o t h e r tool in the

environment.

This

document

tributed Notation for A D A . has

been

designed

to

defines

Diana.

Descriptive

Intermediate A t -

DIANA IS an intermediate form of ADA programs which

be

especially

suitable

for

communication

between

two

essential t o o l s - - t h e Front and Back Ends of a c o m p i l e r - - b u t also to be suitable for use by other tools tn an ADA support environment. of lextcal,

syntactic,

and static

semantic analysis,

DIANA e n c o d e s the results but it does not include the

results of dynamic semantic analysis, of optimization, or of code g e n e r a t i o n , It

Is

common

tc

refer

representation of programs. ment. word

to

a

scheme

such

as

suggests

a concrete

structure in primary m e m o r y or o n a file,

Intermediate

it was carefully defined

to

Unfortunately. too often the

realization such

as

a

particular

data

It is important for the r e a d e r to keep

In mind that DIANA does not Imply either of these. the case;

an

Discussions of DIANA. including those in this d o c u -

undoubtedly use this and similar terminology. representation

DIANA as

Indeed. quite the opposite Is

permit a wide variety of realizations as

different concrete data or file structures. A far m o r e accurate characterization of D ~ A type.

is that tt is an abstract data

The DIANA representation of a particular ADA program Is an instance of

this abstract type.

As with all abstract types.

that provide the only way in which modified.

The

actual

DIANA defines a set of o p e r a t i o n s

Instances of the type can

data or file structures

used to

be examined or

r e p r e s e n t the type are

1Ada is a registered Trademark of the /ida Joint Program Office, Department of Defense, United States Government.

DIANA Reference Manual

Page 8 / Section !

hidden

by these

operations,

in

the

sense

that the

implementation

of a private

type tn ADA ~s h i d d e n . We often refer ~o a DIANA " t r e e ' , tree';

similarly,

we refer to

" a b s t r a c t syntax t r e e ' ,

"nodes'

in these trees,

a

parse

tn the context of DIANA as

We a r e not saying that the data structure

is n e c e s s a r i l y

"attributed

~t is i m p o r t a n t to a p p r e c i a t e what is and is not implied by

an a b s t r a c t data type, such terms.

or

tree

using

pointers

and

the

like.

used to i m p l e m e n t DIANA

Rather,

we are

using

the

notion of attributed t r e e s as the a b s t r a c t m o d e l for the definition of DIANA. An

abstract

data

type

type) t o g e t h e r with ( b ) an

a b s t r a c t type

modeling

consists

must

define

of

specifying

method

of

(a)

a set

of values

a set of o p e r a t i o n s on t h o s e values, both

its values and

an

abstract

type

(the

domain

its o p e r a t i o n s . provides

of the

T h e specification of these

The a b s t r a c t definitions

by

defining the values {n t e r m s of some m a t h e m a t i c a l entity with which the r e a d e r is p r e s u m e d to be f a m i l i a r ; thetr effect

on

the

the o p e r a t i o n s of the type are then defined In terms of

modeling

entities.

In the c a s e

m a t h e m a t i c a l m o d e l is that of attributed trees. mind

that the trees of the values

model

being

discussed

in the

are

of DIANA, for e x a m p l e ,

The r e a d e r should always b e a r in

merely c o n c e p t u a l

DIANA d o m a i n .

the

They may or

ones;

they are the

may not exist as an

explicit part of an I m p l e m e n t a t i o n of 'the DIANA a b s t r a c t type 2.

1.1l.

Design P r i n c i p l e s

The cussed

design

of

DIANA is based

in this section°

As with

on

the c o l l e c t i o n

any design

of

intended

principles for

c o m p r o m i s e of these p r i n c i p l e s has on o c c a s i o n been n e c e s s a r y . of d e v i a t i o n s from the p r i n c i p l e s is extremely tow.

however,

that are

practical

use,

dissome

The f r e q u e n c y

and an u n d e r s t a n d i n g

of the p r i n c i p l e s will help the r e a d e r to u n d e r s t a n d DIANA. Section

I.I.

I

DIANA, and Section m a d e since.

p r e s e n t s t h o s e p r i n c i p l e s that motivated the original design of 1.1,2

Section

producer or consumer)

p r e s e n t s those p r i n c i p l e s that have g o v e r n e d c h a n g e s

1, 1 , 3

defines what It m e a n s

and Section

to

be a DIANA user

(I.e.,

] . ] . 4 presents a l a c u n a of the entire DIANA

definition effort.

2An alternative definitional method, algebraic axioms, would have avoided explicit reference to a model such as trees end hence might have been less suggestive of an implementation, We chose riot to use this method in order to retain a close correspondence between Diana end Ada's formal definition l'6].

Section 1 . 1 . 1

Introduction

1.1.1,

/ Page 9

Original Design

The following principles governed the original design of DIANA: is r e p r e s e n t a t i o n i n d e p e n d e n t . AS noted above, we strove to avoid tmplytng any particular Implementation strategy for the DIANA abstract type, For example, where i m p l e m e n t a t i o n - s p e c i f i c i n f o r mation Is needed In a DIANA representation (such as values on the t a r g e t - m a c h i n e ) , we make reference to other abstract types for representing these d a t a ; each implementation is expected to supply the implementation of these types. In addition, we strove to avoid any implications for the strategies to be used In implementing Front or Back Ends of compilers, or, for that matter, any other e n v i r o n ment tools, Finally, we provide an explicit mechanism for i m p l e m e n tations to extend or contract the DIANA form In a consistent m a n n e r to cater to i m p l e m e n t a t i o n - s p e c i f i c purposes,

o Diana

= Diana Is b a s e d on AOA'S f o r m a l d e f i n i t i o n [6], referred to hereafter as the AFD. In defining an Intermediate representation of ADA, we face

three problems: what is the representation of a particular p r o g r a m . what does that representation m e a n ( i . e . , what is the semantics of the particular instance of the representational s c h e m e ) , and when is the representation consistent ( I , e , . meaningful) ? Since the AFD a l r e a d y provides the latter two of these 3. we have chosen to stay as close as possible to the definitional scheme used t h e r e - - p a r t i c u l a r l y to the abstract syntax. Thus, In this d o c u m e n t we can focus exclusively on the first of these questions, n a m e l y how particular programs are represented. of D i a n a . Regularity of d e s c r i p tion and notatton was a principal goal. We believe that this regularity Is an important aspect of both understanding and processing a DIANA intermediate form.

= R e g u l a r i t y Is ~ p r i n c i p a l c h a r a c t e r i s t i c

.

m u s t be efficiently I m p l e m e n t a b l e . As noted above, DIANA IS best viewed as an abstract data type. Its specification Is m o r e abstract than is directly supported by current p r o g r a m m i n g languages. including ADA. Nonetheless, DIANA is Intended to be used~ Hence, tt is essential that there exist an efficient implementation of it ( o r actually, several different efficient implementations of it) in c o n t e m p o r a r y l a n g u a g e s - - e s p e c i a l l y ADA Itself, Later chapters deal with this issue explicitly; for now. the important point ts that Imptementabllity was a primary consideration and that such Implementations do exist.

Diana

= Consideration

of

the

kinds

of

processing

to

be

done

is

paramount.

Although the primary purpose of DIANA iS c o m m u n i c a t i o n between the Front and Back Ends of compilers, other e n v i r o n m e n t tools will use it

3Some problems with ~he AFD as an answer to these questions are addressed in Section 1.1.4 on page 14.

Page lO / Sect{on ~l. t . "~

DIANA Reference Manual

as we~l. The needs of such p r o g r a m s were c o n s i d e r e d carefully. They i n f l u e n c e d a number of the DIANA design d e c i s i o n s , including the following: ° We define two ~ r e e s - - a n A b s t r a c t Syntax Tree c o n s t r u c t e d prior to s e m a n t i c analysis ( s e e A p p e n d i x II). and an attributed tree {the DIANA structure) c o n s t r u c t e d as a result of static s e m a n t i c analysis. These two structures are. of c o u r s e , c l o s e l y related. By defining both of t h e m . we extend the a p p l i c a b i l i t y of DIANA tO include those tools that need only the parsed form. . We considered the size of (varteus i m p l e m e n t a t i o n s of) DIANA r e p r e s e n t a t i o n s , and we m a d e careful tradeoffs between this size and p r o c e s s i n g speed. We envision that at least some ADA support e n v i r o n m e n t s will be i m p l e m e n t e d on small c o m p u t i n g systems; h e n c e , we c o n s i d e r e d it essential that DIANA be usable on these systems. o We never destroy the structure of the original source p r o g r a m ; except for purely lextcal issues ( s u c h as the p l a c e m e n t of c o m m e n t s ) , it is atways possible to r e g e n e r a t e the s o u r c e text from Its DIANA form. See A p p e n d i x ill. - We p e r m i t the possibility of extending the DIANA form to allow the inclusion of information for other kinds of p r o c e s s i n g . Of p a r ticular c o n c e r n , for e x a m p l e , are extensions to e n c o d e i n f o r mation n e e d e d by various optimization and c o d e - g e n e r a t i o n strategies. In Diana, there is a single definition of each Ada entity. Each d e f i n a b l e entity, e . g . v a r i a b l e , s u b p r o g r a m , or type. is r e p r e s e n t e d by a single defining o c c u r r e n c e In DIANA, Uses of the entity atways 4 refe~ to this defining o c c u r r e n c e . Attributes at this definition point make It possible for all information about the entity to be d e t e r m i n e d . Thus. a l t h o u g h the defining o c c u r r e n c e s are part of the p r o g r a m t r e e . the set of them plays the s a m e role as a d i c t i o n a r y or symbol table in conventional compiler termlnolog¢. Diana must respond to the issues posed by Ada "s separate compilation facility, tt is not in the d o m a i n of DIANA to provide the ~lbrary m a n a g e m e n t upon which s e p a r a t e c o m p i l a t i o n of ADA is based. N o n e t h e l e s s , the possibility of s e p a r a t e c o m p i l a t i o n affects the d e s i g n

4There is a single exception: Private types use a different defining occurrence for references inside the package body in which they are defined than they do elsewhere. See Section 3.5,1,2 on page 104. 5Note. in particular, that an implementation may wish to separate these defining occurrences so that, for example, they may be the only portion of the representation present for separately compiled units. Such implementations ere completely consistent with the Diana philosophy. Other implementation options are discussed in Chapter 6.

Section 1.1. ] / Page "11

Introduction

of DIANA In two ways: • The possibility of on DIANA and references, We ward references compiled.

separate compilation places certain restrictions requires the possibility of certain indirect take care, for example, never to require f o r to entities whose definition may be separately

- We recognize that many library systems may wish to store the DIANA fo~'m of a compilation unit--in order to support optimization across compilation units, for example. Various design decisions In DIANA were influenced by this possibility. o There must be at least one form of the Diana representation that can be c o m m u n i c a t e d between computing systems. We have defined in

Chapter 5 an externally visible ASCII form of the DIANA representation of an ADA program. In this form, the DIANA representation can be communicated between arbitrary environment tools and even between arbitrary computing systems. The form may also be useful during the development of the environment tools themselves.

] . 1.2.

Principles Governing Changes

The design principles Just listed that governed the original design of DIANA have been augmented during this phase of modification by a d d i t i o n a l principles. It is important that these, too, be documented, ° Diana will be changed only when something is sufficiently wrong that it requires change. We state this metric despite the fact it Is such a

broad characterization that deciding when something is "sufficiently wrong' Is clearly judgmental. Nonetheless. the principle has utility. For example, it implies that we not make cosmetic changes, no matter how obvious it might be that the change would result in a better product. Our motto: "If It's not broken, don't fix i t . ' Thus we refrain from changes whose impact on existing implementations significantly exceeds anticipated future benefits. Of course, changes with a large enough savings down the road may be made even if doing so affects current implementations. Again, there is a judgmental call here.

= We do not unduly impact existing Diana users.

In several cases, either of two or mere ways to proceed has seemed equally plausible, and we have been unable to determine any significant advantage to any decision. Nonetheless, In such cases we have made a decision. since we judge a sltghtty incorrect decision to be better for the DIANA community than no decision. At least, there is a standard way for DIANA users to to proceed.

= It is often necessary to make some decision,

o Where

possible

we

have

preserved

the

style

of

the

original

Diana

Page ] 2 / Section " 1 . ] . 2

DIANA Reference Manual

design,

Stylistic c o n c e r n s include such ~ssues as creating IDL classes for attributes, p r e s e r v i n g the s a m e naming c o n v e n t i o n s , and so on.

o Diana

does not unnecessarily deviate from ADA'S formal definition. Even though the formal definition effort a p p a r e n t l y is no l o n g e r b e i n g actively pursued s, we continue to a d h e r e to Its style.

Unfortunately the guidelines are s o m e t i m e s

in conflict.

in the

design.

original

just presented and those of the previous section

For e x a m p l e , The

principle

c o n s i d e r a minor

i n c o n s i s t e n c y found

of conalstency might s u g g e s t

a change.

while the p r i n c i p l e of sufficiently wrong might suggest leaving it alone. have d o n e is to be reasonable tn c o n s i d e r i n g c h a n g e s . used,

and

we c o n t i n u e

to

strive to

keep

What we

DIANA is intended to be

DIANA responsive to the

needs

of

its

it

be

users.

1.1.3,

What is a "DIANA User"

inasmuch

as

DIANA ts

an

abstract

i m p l e m e n t e d in any p a r t i c u l a r way. particular Implementation this DRM.

data

type.

Additionally,

may choose

there

is

no

need

a

to use a s u p e r s e t of the DIANA defined

tn

in the face of i n n u m e r a b l e variations on the same theme,

Is a p p r o p r i a t e

to

offer

makes

to

consider

sense

a

definition

of what

DIANA only

that

b e c a u s e DIANA Is e x t e n d a b l e ,

at

it means

the

to

use

Interfaces,

it

DIANA. Is

wo feel it Since

appropriate

it to

c o n s i d e r two ~ypes of DIANA users:

those which produce DIANA, and those which

consume

implementations

it 7.

In

addition,

some

c l a i m to employ DIANA as an i n t e r m e d i a t e form, external DIANA iS p r o v i d e d .

producer

(particularly

even though

compilers)

may

neither interface

to

We c o n s i d e r these t h r e e a s p e c t s tn turn:

~n o r d e r for a p r o g r a m to be c o n s i d e r e d a DIANA producer, it must p r o d u c e as output a structure that Includes all of the information c o n t a i n e d in DIANA as defined in this d o c u m e n t . Every attribute defined herein must be p r e s e n t , and each attribute must have the value defined for c o r r e c t DIANA and may not have any o t h e r vatue. This r e q u i r e m e n t m e a n s , for e x a m p l e , that a d d i t i o n a l values, such as the evaluation of n o n - s t a t i c e x p r e s sions, may not be r e p r e s e n t e d using the DIANA-defined attributes. An i m p l e m e n t a t i o n is not prevented from defining a d d i t i o n a l a t tributes, and in fact It Is expected that most DIANA p r o d u c e r s will

6The ~ormal definition is based on Aria-80, and there is no visible intent to upgrade it to Ada-82, }'These are not mutually exclusive; for example, a cornpiter Front End that produces Diana may also read Diana for separate ¢ornpilation purposes,

introduction

Section t . 1 . 3

/ Page ] 3

also p r o d u c e additional attributes. T h e r e Is an additional r e q u i r e m e n t on a DIANA p r o d u c e r : The DIANA structure must have the p r o p e r t y that it could have been p r o d u c e d from a legal ADA p r o g r a m . This r e q u i r e m e n t Is likely to i m p i n g e most strongly on a tool o t h e r than a c o m p i l e r Front End that p r o d u c e s DIANA. As an e x a m p l e of this r e q u i r e m e n t , In an arithmetic expression, an offspring of a multiplication c o u l d not be an addition but would instead have to be a parenthesized node whose offspring was the addition, s i n c e ADA'S parsing rules require the p a r e n t h e s e s . The motivation for this r e q u i r e m e n t is to ease the c o n s t r u c t i o n of a DIANA c o n s u m e r , s i n c e the task of designing a c o n s u m e r is c o m p l e t e l y o p e n - e n d e d unless it can make some r e a s o n a b l e assumptions about its input. consumer

In o r d e r for a p r o g r a m to be c o n s i d e r e d a DIANA consumer, it must d e p e n d on no more than DIANA as defined herein. This restriction does not prevent a c o n s u m e r from being able to take a d v a n t a g e of additional attributes that may be defined in an i m p l e m e n t a t i o n ; however, the c o n s u m e r must aiso be able to a c c e p t input that does not have these additional attributes. It is also i n c o r r e c t for a p r o g r a m to e x p e c t attributes defined herein to have values that are not here specified. For example, it is w r o n g for a p r o g r a m to expect the attribute sm._value to c o n t a i n values of expressions that are not static.

employer

The intent is The definition of a DIANA employer is more difficult. that the Intermediate form must be close to DIANA; the p r o b l e m Is that we have no useful metric for close. In addition, the lack of a visible external r e p r e s e n t a t i o n of t h e intermediate form a p parently p r e c l u d e s a p p l i c a t i o n of any validation p r o c e d u r e . This point is a d d r e s s e d further below. that a r e not r e q u i r e d

There

are two attributes

that are defined herein

supported

by a DIANA user:

ix_comments and /x_srcpo~.

to be

We believe that t h e s e

attributes a r e too Implementation specific to be r e q u i r e d for all DIANA users. It is instructive 'to examine the p r o b l e m s s u g g e s t e d above of defining a DIANA

employer. a

Inasmuch

as papers have begun to a p p e a r in the literature in which

given Implementa'tlon claims

"to use DIANA' o r

"to

be DIANA-like'.

we feel that

it is a p p r o p r i a t e to offer a metric a g a i n s t which to j u d g e such claims,

Consider

the following three c a n d i d a t e s for such a metric: ,= A r e p r e s e n t a t i o n can p r o p e r l y be called same Information that DIANA contains.

DIANA if it contains

all the

o A r e p r e s e n t a t i o n can properly be called DIANA if one can provide a r e a d e r / w r i t e r for transforming between the r e p r e s e n t a t i o n and DIANA.

Page 14 ! Section 1.1.3

DIANA Reference Manual

o A representation can properly be called OIANA if ~t provides a package equivalent to the o n e described in Chapter 4 for accessing and modifying the structure. A~though the first two definitions have a certain a p p e a l , that neither of 1hem Is at all adequate, original ADA source

since

it is unfortunately true

a Httle thought reveals that

the

One repair pQsslbtllty Is to

text meets either requirement.

attempt to tighten up the second definition by restricting the r e a d e r / w r i t e r to be "simple',

In s o m e sense,

but defining that sense appears to require Solomonlc

wisdom. The third

definition

also

has appeal,

though

it is agatn hard to use as a

metric if the external interface is not actually provided in a useful way. it Is our opinion that !t is not p r o p e r to claim that a given implementation uses DIANA unless either it meets the following two criteria: -

it must be able to read a n d / o r write (as appropriate) form of DIANA defined in Chapter 5 of this d o c u m e n t . That DIANA must meet the requirements consumer as specified in this section,

of

a

the external

DIANA producer

or

or it meets this criterion: o The implementation provides a package equivalent to that described in Chapter 4, We hope that writers of papers will give c o n s i d e r a t i o n to this discussion.

1.1,4.

Specification of DIANA

An ~mportant p r o b l e m faced by new users of DIANA ts to d e t e r m i n e , particular ADA construct,

}ust what DIANA is tO be produced from tt.

for any

Although the

DIANA specification in Chapter 2 specifies precisely what nodes must exist, which attributes each

node

must

contain,

what type the value of each

and

attribute

must have, it often says very little about what value the attribute is to have. This problem is addressed in this d o c u m e n t in several ways. ments

appear

addition,

in

Chapter

2 specifying

or

the

Often,

intended value.

comIn

the lengthy discussion of design rationale in Chapter 3 presents much

additional information.

Unfortunately,

still more help is needed,

solution to the p r o b l e m of providing such document.

suggesting

The

help might take.

and a c o m p l e t e

help Is beyond the capability of this

remainder of this section is speculation about the form such

Section 1 . 1 . 4

Introduction

What Is needed is Is a formal way to determine, and a DIANA structure

/ Page 15

given an ADA source text

purported to be a c o r r e c t representation of the source,

whether or not the DIANA Is In fact correct.

For example,

suppose that = Is

some ADA text and that 0 purports to be a DIANA representation of it.

Needed Is

a predicate ~r such that 7r(=, O) ls true If, and only If, 0 correctly represents a. Ideally,

the structure of v should be such that it Is accessible to a human

r e a d e r who requires from ADA to DIANA.

help in designing

an ADA front end or other t r a n s f o r m e r

No such predicate now exists.

The kinds of questions that

such a predicate should help to answer include the following: ].

is a given program?

2.

What should structure?

abstract

be

syntax tree

the value

of

(AST)

each

correct

semantic

for

a

attribute

given

In

a

Aria

DIANA

3. When Is sharing permitted in the AST? 4.

May the same node appear in several sequences?

We

believe that

one

way to

meet

these

needs

is

by first

transformation from ADA to AST and then defining a predicate,

specifying

the

say v t on ASTs

and DIANA SUCh that for an AST T and a DIANA structure 0 the predicate Trt( T, 0 ) returns true If the DIANA structure 0 is a c o r r e c t representation of the AST "r. This d i c h o t o m y appears useful. Translation

of

ADA source

to

abstract

syntax

tree

(AST)

is

a

two-step

process: =

Translation of ADA source to parse tree ( P T ) . The latter Is a tree in which each node is labeled with the n a m e of a n o n - t e r m i n a l from ADA'S BNF definition and has as many offspring as clauses appear in the relevant definition of that n o n - t e r m i n a l . Given a n o n - a m b i g u o u s BNF for ADA, such a tree is uniquely defined. Although the BNF In ADA's LRM is ambiguous, it is not difficult to create a n o n - a m b i g u o u s verslon that preserves all essential structure.

° Translation of PT to AST. This step, though somewhat harder specify than the previous one, is not conceptually difficult.

to

We believe it is possible to describe the PT to AST transformation by using

Page ] 6 / Section 1 . ~ . 4

DIANA Reference Manual

an attribute g r a m m a r to specify the AST as an attribute of the root of the HT. The specification of the AST to DIANA transformation (including specification of the semantic

attributes)

is

a

much

harder

problem

and

Is still

open.

We

are

exploring methods of attacking these problems.

t . 2.

Structure of the Document

Abstractly. tree.

an instance of the DIANA form of an ADA program is an attributed

The t r e e ' s structure is basically that of the abstract syntax tree defined in

the AFD.

Attributes of the nodes of this tree e n c o d e the results of semantic

analysis.

Operations defined on the DIANA abstract data type ( s e e Chapter 4)

provide the

predicates,

tree and Its attributes.

selectors,

and constructors

required to manipulate this

The structure of this d o c u m e n t reflects the several facets

of the DIANA definition, We do First we define precisely the domain of the DIANA data type. so by specifying the set of abstract trees, their attributes, and various assertions about them (which actually a p p e a r as c o m m e n t s ) . This definition is done in two steps: * in Section 1 . 4 we describe the notation, called IDL. for exhibiting DIANA'S definition. in Chapter 2. we use the notation to define the actual trees and attributes u, S e c o n d . we provide a rationale for some of the m o r e subtle design d e c i s i o n s - - particularly with respect to the attributes of nodes in the abstract tree. This rationale appears in Chapter 3. Third. we define the operations on the DIANA abstract type. This definition a p p e a r s in Chapter 4. and again is done in two steps. First. we describe generically the nature of these operations. S e c o n d . we show how these operations can be realized in c o n v e n tional p r o g r a m m i n g languages by showing how an interface can be derived from the DIANA definition and by showing the specification part ( e x c e p t for t h e private part) of an ADA package that specifies just such an interface. We also show here how the interface is altered w h e n additional attributes or nodes are introduced s.

8Note that e particular implementation may define an extended domain (additional attributes). we define here is a required end adequate set.

What

9Note that an imp|ementation may define addttiona| operation.~. Again, we merety define a required end adequate set here.

Section 1 . 2 / Page 17

introduction

= Fourth, In Chapter 5, we define a canonical way to represent DIANA structures external to a computer. = Finally, In Chapter 6, we discuss Implementation Issues and Illustrate some of the various options that are available. There

are

predeflned

also

six appendices.

environment

for

Appendix I provides the

ADA compilations.

In

Appendix

definition 11 we

of the

define

the

Abstract Syntax Tree from the AFD as a derivative of the DIANA representation. Appendix III describes

how the source of an ADA program can

be r e g e n e r a t e d

from the DIANA representation and includes a discussion of the normalizations of reconstructed source programs imposed by DIANA. Appendices

IV,

V,

and VI provide three summaries of the DIANA definition.

These summaries provide an Invaluable cross reference Into the mal'n definitions and should be an Important aid to the reader. There Is an extensive Index that lists separately topics,

DIANA attributes,

and

DIANA node names.

1.3.

Attribution Principles of DIANA

This section describes the general principles used to decide on the details of DIANA, The

A m o r e detailed rationale Is given In Chapter 3. design

of

an

intermediate representation

involves deciding

what

infor-

mation to represent explicitly and what information to recompute from the stored information,

There are two extreme positions one can take:

= The s o u r c e p r o g r a m ( o r its necessary Information; other necessary.

abstract syntax tree) contains all the Information can be recomputed when

= All Information which can be computed should be computed and stored within the intermediate representation. DIANA'S underlying principles,

which are a c o m p r o m i s e between these extrema,

can b e derived from DIANA'S Intended role In an ADA Program Support E n v i r o n ment (APSE)

[31.

We envisage DL~IA as created by an ADA Front End,

used as

input to that Front End for separate compllation purposes,

used as Input to the

compiler's

by a variety of other

Back End,

and used ( p r o d u c e d or c o n s u m e d )

tools of the APSE. For all these tools DIANA should contain Information that Is both s u f f i c i e n t and

Page 18 / Section ] . 3

appropriate,

DIANA Reference Manual

There

are

two

questions

relevant

to

deciding,

about

a

given

attribute, w h e t h e r or not to Include ft in the DIANA*, Does the information the attribute contains belong ~n the Intermediate representation? o Should the information be represented r e c o m p u t e d from the stored information? We

have used two criteria

in deciding

explicitly,

or

should

It

be

of a given attribute whether or

not to

include it: o DIANA should contain only such information as would be typically d i s covered via static (as opposed to dynamic) semantic analysis of the original p r o g r a m . - ff i n f o r m a t i o n can be easily r e c o m p u t e d ,

It should be omitted.

These two points are discussed at tength in the following two subsections. First,

however,

a point must be made.

Although the original DIANA design

used the metric of e a s e of computation in deciding what attributes to Include, the c o n c e p t

has been c o n s i d e r a b l y oxpanded tn revisions of DIANA and of this

report.

As

criterion,

o u g h t not to be there.

a

result,

reasons:

They a r e

not

attributes

now

exist

in

DIANA which,

according

to

this

We have elected to let them remain for two

sufficiently

wrong

to

would likely unduly Impact existing DIANA users.

require

ftxlng,

and

their

removal

Note that these are the first two

principles e n u n c i a t e d in Section "1.1.2 on page "ll,

"1.3. 1. Static Semantic ~nformatlon We beiteve that It {s a p p r o w i a t e for DIANA to include only that information that is

determined

from

static

semantlo

analysis,

and

that

DIANA should

exclude

Information whose d e t e r m i n a t i o n requires dynamic semantic analysis, This decision affects the eva~uation of non-static expressions and evaluation of For example, the attribute sm value should not be used to hold the

exceptions.

value of an expression that ~s not static,

even if an I m p l e m e n t a t i o n ' s semantic

analyzer is capable of evaluating some such expressions. are part of the execution ( I . e . , reprosonted

~n

D~ANA.

Thus

dynamic) the

r e p r e s e n t an exception to be raised, Of c o u r s e , record

the

Similarly,

exceptions

semantics of ADA and should not be

attribute

sin_value

is

no

Iongor

used

to

as It was In an e a r l i e r version of DIANA,

an Implementation that does compute these additional values may

information

by defining

additional

attributes.

However.

any

DIANA

Introduction

consumer

Section ] , 3 . 1

thut relies on these attributes cannot

"user',

as defined I~ Section 1 . 1 , 3 on page 12.

1.3.2,

What is "Easy to Recompute'?

Part of the criteria

for

Including

be considered a correct

DIANA

an attribute In DIANA IS that It should

omitted if it is easy to rucompute from the stored Information. i m p o r t a n t to avoid such

/ Page 19

redundant encodlngs

I m p l e m e n t a b l e Internal representation.

be

We feel It Is

If DIANA iS tO remain an usefully

Of course this guideline requires that we

define this p h r a s e . . a n d we suggest that an attribute is easily computed if = it requires visits to no m o r e than three to four nodes; or o It can be computed tn one pass through the DIANA tree, nodes with this attribute can be computed in the same pass.

and

all

The first criterion is c l e a r ; the second requires discussion. Consider first an attribute that Is needed by a c o m p i l e r front end (FE) semantic

analysis.

As

(non-DIANA)

attributes

created

those

by

implementations pointers.

who

which

If we

the

for

its

need use

add

FE

does

Its

purposes, them.

To

algorithms

every attribute

work, Thus

require

that that

It

the

do

is

free

desired them

not

anyone

is

to

require

requires,

create

attributes an

to do extra

can

bo

Imposition

on

these

particular

everyone will

be

overwhelmed. Consider now an attribute needed by a back end (BE) tlon.

to do code g e n e r a -

As long as tl~e attribute can be determined In a single pass,

that reads tn the DIANA can readily add it as it reads In the DIANA, implomentors

may

not

need

the

attribute,

and

it

is

the routine Again,

inappropriate

to

some burden

e v e r y o n e with it. It Is for these reasons that we have rejected suggestions for pointers to the enclosing

compilation

pointers in general.

unit,

pointers

to

the

enclosing

namescope,

and

back

These are attributes that are easily computed in one pass

through the DIANA tree and Indeed may not be needed by all Implementations. Of

course,

a

DIANA producor

beyond those specified for DIANA.

can

croate

a

Nevertheless,

on these additional attributes ts not a DIANA user, Section 1 . ' 1 . 3 on page 12.

structure

with

extra attributes

any DIANA consumer that relies as that c o n c e p t is defined In

9age 20 / Section t . 3 . 3

1.3.3,

D~ANA Reference Manuat

Other Principles

There are other

reasons why particular classes of attributes are

present in

DUMA, o A tree-like representation of the source program many of the tools that witl exist in an APSE, analyzers, optimizers, and syntax-directed editors. is represented in DIANA via the structural attributes; abstract syntax tree as given by the AFD, with described in Section 3. 1 on page 80.

is well-suited for such as semantic The tree structure we use the same a few differences

o Lexical attributes (such as symbol and literal representations and source positions) are needed by the compiler ( e . g , , 1or error messages). They are also useful to other APSE tools for referring back 1o the source or for regenerating source text from the intermediate representation. = ADA provides the attribute 'SIZE to determine the minimum number of bits needed to represent some object or subtype. If this attribute is applied to a static type, the result is sta~,tc and is therefore required by ADA'S semantics to be known at compile time. It represents a t a r g e t - m a c h i n e property properly computed by a code generator. However, as it can be used in static expressions, the Front End must know its value in some contexts. For example, the selection of a base type for a derived integer type depends on a range constraint. Without this information, the semantic analyzer cannot perform one of its most important tasks, type and overload resolution. Since the value must be known to the Front End, it is recorded as the value of an attribute to avoid the need for recornputatlon by the Back End,

t,3.4,

Examples

A few examples illustrate these principles: ,, The structure of' a type (whether it is an integer, an array, a record, and so on) can be deduced by searching backward through the chain of derived types and subtypes. This chain could be of arbitrary mength, and so the search is not tolerable. Thus. a subtype specification (a DIANA constrained node) has an attribute sm._type_struct to record this information. o The parent ~ype of a derived type is identical to the base type of the subtype Indication given in the derived type definition, and this information is already recorded in the sm._baae_type attribute of the constrained node which is a child of the derived node. Thus no parent type indication is needed in the derived node. o Some DIANA users have suggested adding an attribute to each DEF OCCURRENCE node to denote the node for the enclosing namescope. Although locating the enclosing namescope (if the at-

Introduction

Section 1.3, 4 / Page 21

tribute is not available) can involve visits to more than three or four nodes, a DIANA reader can readily compute this attribute and decorate the tree with It as the DIANA IS read in. Since this attribute contains information that may not be useful to every implementation and f u r thermore is easy to compute in the above sense, it is not provided in DIANA.

1.4.

Notation

As we have stated several times, modeled as an attributed tree.

DIANA IS an abstract data type that can be

In this document we are concerned with defining

this abstract t y p e - - b o t h Its domain and its operations. type is a subset of the order to

specify this

(mathematical)

subset

precisely,

subset of a notation catted tDL [9). or

understand

this

we introduce

some

special

In

notation,

a

A knowledge of tDL is not necessary to read

document--all

defined in this section.

The domain of the DIANA

domain known as attributed trees,

necessary

information

about

the

notation

is

(A few additional features are defined in Appendix II as

they are used only t h e r e . ) To assist the reader in understanding this material, ventions

are

followed

consistently

throughout

this

certain typographic c o n -

document,

as

illustrated

in

Figure 1 - t .

DECL OP DEF_OCCURRENCE constant var const_id

Ix_srcpos

am_address

Structure

Root

as_exp

reserved word In IDL

begin case pragma INTEGER ' S I Z E BOOLEAN Tax_rate Walk1 Tree

Figure 1-1:

IDL class names IDL node names IDL attributes

ADA reserved words identifier defined by ADA Identifier in an ADA program

Typographic ConvenUons used in this Document

The set of abstract trees used to model the DIANA type can be viewed as a language,

one whose terminal

than strings of characters.

sentences

happen to

be attributed trees

The definition of this language can,

given in a form similar to BNF,

rather

therefore,

be

in particular, we use two definitional forms that

Page 22 / Section ~ , 4

DIANA Reference Manuat

r e s e m b t e the p r o d u c t i o n of the d e s c r i p t i o n . EXP

rufes of BNF,

Consider,

":=

leaf

As is c u s t o m a r y ,

for e x a m p l e ,

i tree

names

this definition

of nodes

tn the

"free

may be read,

t e r m i n a l s In 8 N F , is in defining sentences

are called node

EXP are

node

names.

names, Class

in this case,

names,

never a p p e a r in the s e n t e n c e s of the l a n g u a g e ;

that l a n g u a g e .

(that

"The notion of an EXP is defined

Symbols such as EXP are calted class names; language'

for

the following definition:

;

to be either a leaf or a t r e e . ' both alternative definitions

The first of these defines n o n - t e r m i n a l s

Node names,

is the trees

of our tree

on the

other h a n d ,

language),

Notice.

like

non-

their only use a p p e a r in the

by the way,

that

each definitional rule is t e r m i n a t e d by a s e m i c o l o n . The use of thts form right

hand

side

of the

class or node n a m e s be in B N F ) .

of definition is more restricted than in usual BNF. production

fashion)

directed

graph

be oniy an

alternation

and may not be a c o n c a t e n a t i o n

in a d d i t i o n ,

circular

may

of one

The

or

of two items ( a s

more it may

class n a m e s may not d e p e n d upon t h e m s e l v e s

involving

only

the

constructed

with

an

": : = '

form

e d g e from

each a l t e r n a t e on the right will be a c y c l i c ;

of

definition

each

that is,

class

rules.

name

(in a

Thus

on the

a

left to

it will be a DAG.

As is usual with E~NF, there may be more than o n e such p r o d u c t i o n with the same

left

hand

side" { c l a s s

a d d i t i o n a l alternatives,

name);

Thus,

EXP

:==

leaf

EXP

=:=

tree ;

definitions

after

the

first

merely

introduce

the effect of the two definitions

;

@s no different from that of the single definition given earlier,

T h e d e i i n i t i o n of ~he node n a m e s must specify the attributes that are p r e s e n t In that node,

as wetl as the n a m e s and types of these attributes.

a B N F - I l k e form for such definitions.

To prevent c o n f u s i o n ,

different from the definition of c l a s s n a m e s ; tree Here names EXP).

we

=>

define

(op,

left.

op= OEEI~'i~OR, left= E ~ ,

the

node

tree

and right)

Unlike BNF ( o r

and

for e x a m p l e right= ~

associate with

and their

; it three

respective types

record declarations),

We a g a i n use

this form is slightly

attributes

(OPERATOR,

with

their

EXP,

and

the o r d e r of attribute s p e c i f i c a t i o n s

does not matter. The right hand side of a p r o d u c t i o n defining a node n a m e is also r e s t r i c t e d ; ~t may be only a s e q u e n c e

of zero or more attribute s p e c i f i c a t i o n s s e p a r a t e d by

Introduction

commas are

Section 1 . 4 / Page 23

and

terminated

permitted;

they a r e not Thus,

by a s e m i c o l o n .

definitions alternatives

after the first but,

rather,

Multiple definitions add additional

define

additional

of a node

attribute attributes

name

specifications-of the

node.

for e x a m p l e , tree

=>

o p = OPERATOR ;

tree

=•

left.

tree

=>

op=

tree

=>

right= E~9 ;

=>

left,

EXP, right= ~

;

and OPERATOR ;

, , .

tree

EXP s

are both identical in effect to the single definition given earlier.

Nole also that

the order of both the

all o r d e r s a r e

"::='

equivalent ( a s in B N F ) ,

and

"=>' definition rules is irrelevant;

in partlcuiar,

we reversed the o r d e r ~ o f definition of the

left and right attributes in the last example above;

On o c c a s i o n

doing so has no effect.

it is useful to specify a node which

has no attributes,

as t o t

example foo => ;

Nodes

so defined

are

used

e x a m p l e , the n o d e s plus,

much

minus,

like e n u m e r a t i o n

times,

There are two kinds of p e r m i s s i b l e attribute types: tDL notation,

and private types.

ltterais

tn ADA.

See,

for

and divide in Figure 1-2 on p a g e 2 6 . basic types defined by the

The basic types are:

Boolean

These are the conventional boolean type; the only p e r m i s sible values of such an attribute a r e t r u e and f a l s e .

Integer

This Is the "universal Integer' type,

Rational

This is the "universal rational n u m b e r ' type. which Inctudes atl values typically found in c o m p u t e r integer, floating point and fixed point types.

String

T h e s e are ASCIi strings.

SeqO£



T

This Is an o r d e r e d s e q u e n c e of objects of type T, The must be that of either a node or class n a m e defined e l s e w h e r e . Use of as an attribute type denotes a r e f e r e n c e to either an instance of that node (in the case of a node name) or any of the nodes that can be d e r i v e d from it (in the case of a class n a m e ) . Note that

Page 24 / Section 1 . 4

DtANA Reference Manuat

a r e f e r e n c e here does not necessarily mean a pointer in the c o n c r e t e i m p l e m e n t a t i o n ; d i r e c t Intine inclusion of the node |s p e r m i t t e d , as well as a n u m b e r of o t h e r i m p l e m e n tations, ( S e e Chapter 6 for a discussion of some of the i m p l e m e n t a t i o n alternatives. ) A

private

type

names

an

implementation-specific

a p p r o p r i a t e to speci1'y at the a b s t r a c t structure want to a s s o c i a t e a s o u r c e _ p o s t t l o n This

attribute

is

useful

for

for s o u r c e - l e v e l d e b u g g e r s ,

should

be

defined

as

part

of

level.

the

source

and so on.

this

standard

since

each

that matter,

the c o n c e p t of s o u r c e

arises

a

editor.

is

in-

in DIANA we

position

For

these

program,

for

It is not a type,

notions of how a posltton in the s o u r c e syntax

that

For e x a m p l e ,

idiosyncratic from

structure

attribute with each node of the a b s t r a c t tree.

reconstructing

errors,

data

reporting

however,

that

system

has

computer

p r o g r a m is e n c o d e d .

may not be meaningful reasons,

attributes

such

For

if the DIANA as

source

position are m e r e l y defined to be private types. A private

type is i n t r o d u c e d

by a type d e c l a r a t i o n .

The d e c l a r a t i o n

of

the

private type ' M y T y p e ' would be

Once

such

a declaration

attribute s p e c i f i c a t i o n . tz'ee

Before

=>

proceeding,

"--"

Second,

and

the

identically

is

notation

except

for

different Identifiers le. followed

by

characters

an ('

T h e final illustrated the

entity

grammar.

been

xxxt ~

given,

the type

name

may

be used

in

an

;

we need to make a few remarks about the lexicai s t r u c -

ture of the ~DL notatlon~ hyphen

has

For e x a m p l e .

First,

as in ADA a c o m m e n t is Introduced by a d o u b l e

terminated is the

case

the

end

sensitive;

case

Finally,

optional

by

of

the

of

that letters

the is, in

names (identifiers),

sequence

of

letters,

line

on

which

identifiers them

are

that

it a p p e a r s . are

spelled

considered

to

be

as in ADA, consist of a tetter

digits,

and

isolated

underscore

'). point to

be m a d e

above are e n c l o s e d being

defined

about the

notation

In a syntactic

together

with

the

is that the

definitional

rules

structure

that provides a name for

type

the

of

goal

symbol

of

the

For e x a m p l e , the IDL text

lOcase sensitivity is viewed by some as s questionable notational property; in this instance it was adopted to support a direct correspondence with the AFD (which is case sensitive).

Introduction

Section ] , 4

SomeName Root EXP Is some sequence o~ definitional Dad

/ Page 25

Structure

asserts

that

the

collectlon

in

IDL

terminology)

Structure

structure is an EXP,

of

production

named

rules

rules

defines

"SomeName'

and

an

abstract

that

root

(or

of

this

where EXP is defined by the set of definitional rules.

In

the case of DIANA we are defining a single abstract type.

the

type

so there is a single

occurrence of this syntax that surrounds the entire DIANA definition; other uses of IDL may require

several Sl;ructure

definitions.

Expanding on the analogy that

IDL Is like BNF. the Root: defined here is the "goal symbol' of the grammar;

all

valid

by

instances

of

the

type

defined

by the

IDL

specification

are

derived

expanding this symbol,

t . 4,'1.

Example of the IDL Notation

The following example Illustrates the use of the notation. chosen not to be DIANA to avoid confusion. describe an might

use

abstract type for a

definition

such

Suppose,

representing simple as

the

Although this example is quite simple,

one

shown

EXP and

OPERATOR.

that we wish to

arithmetic expressions. in

Figure

]-2

on

Since they name

We

page

It does illustrate the use of all

features of the IDL notation that are used to define DIANA. defined:

It Is Intentionally

then.

26.

of the

Two class names are

classes

and

not

nodes

(as

Indicated by our typographic conventions),

neither appears in the trees

abstract type (structure)

There are six node names defined:

tree,

leaf,

plus,

minus,

node in the trees. names

and

types

"ExpressionTree'. times,

of

these

private type. S o u r c e P o s i t i o n , this type.

Finally,

either a t r e e

or

a

and divide.

Of the nodes,

Each of these may appear as a

only trees and leafs have attributes,

attributes

are

in the

given,

An

and the

Implementation-defined

is defined; both trees and leafs have attributes of

the fact that the root of the tree must be an EXP, that is. Ileal node,

Is specified.

Figure

'1-3 on page 27 illustrates

several trees that are defined members of ExpresstonTree; for expository reasons the names of the attributes and the source position attribute have been deleted from these pictures.

]. 4.2.

Similar conventions are used In the figures in Chapter 3.

Specification of Representations

IDL can be used to define a r e f i n e m e n t of a structure as well as an abstract data structure. specified in

IDL.

A refinement is treated the same as any other abstract structure A refinement of a structure

about the abstract structure.

is used to provide more detail

In this document we define a refinement of DIANA

Page 26 / Section 1 . 4 . 2

Structure

DIANA Reference Manual

ExpressionTree

--Fizstwe

R o o t EXP Is

define

a private

type.

Type Source_Position;

Next we define EXP

~=

leaf

the n o d e s

a n d t h e i r attributes.

right= EXP

op~ OPERATOR, left= EXP, 8re: S o u r c e _ P o s i t i o n ; namer String ; src: S o u r c e _ P o s i t i o n ;

=> => => =~

EXP.

~ tree

Next we define tree tree leaf leaf

t h e n o t i o n of an expression,

Finally we define the n o t i o n o f an O P E R A T O R as the u n i o n o f a c o l l e c t i o n o f nodes~ the n u l l =~ p r o d u c t i o n s - - a r e n e e d e d % o d e f i n e t h e n o d e t y p e s since N n o d e t y p e n a m e s a r e n e v e r i m p l i c i t l y defined. OPERATOR

It=

p l u s =~

~

plus

minus

i minus

=~

~

I times

t i m e s =~

I divide

;

; d i v i d e =7

End

Figure 1-2:

Example of IDL Notation

that provides representation information for the private ~ypes defined in DIANA. IDt can

be used to define the package that contains the internal r e p r e s e n -

tation of a private type, type.

We

add

this

and can spectfy the externat representation of a private

information

to

the

DIANA abstract

type

in

the

structure

Diana_Concrete in Chapter 2 on page 77. The tnternat representation of a private type is described the form For My~rpe

U s e MyPackage;

by a definition of

Introduction

Section 1.4,2 / Page 27

leaf "xyz"

tree

/1\

leaf

plus

"abc"

leaf "def"

tree

/l\ /L\

leaf times tree ~'

tree

plus

leaf

/1\

leaf minus leaf "X" "Z"

Figure 1-3:

Some Trees in ExpressionTree

Page 28 / Section 1.4~2

DIANA Reference Manual

This definition )ntroduces the n a m e of the package ( ' M y P a c k a g e '

in this case)

w h e r e the definition of a private type ( ' M y T y p e " in this case) is found. The way a private type is to be represented externally can be described in a definition of the form For MyType Use External EA-ternType;

This

definition asserts that the private type MyType ls represented by the type

'ExternType' externally.

The external type may be one of the basic IDL types or

a node type, The refinement o1 a structure is specified with the following syntax Structure AnotherTree Refines ExpressionTree Is Additional IDL statements to further define the -- structure ExpressionTree, such as a specification of the -- internal and external representations for private -- types in the abstract structure ZxpressionTree. New nodes m a y be defined. -

-

-

-

End

]. 4.3.

Example of a Structure Refinement

The following example illustrates the use oi the structure refinement notation. To

continue with our example,

suppose we wished to

refine the abstract type

ExpresslonTree by adding an Internal and external representation to be used for the private type Source_Position.

We might refine the structure:

Structure AnotherTree Renames EXpressionTree Is first the internal representation of Source_Position For ~ u r e e _ P o s i t i o n

Use S o u r c e P a c k a g e ;

next the external representation of Source_Position is given by a new node type, soumc~ e x t e r n a S ~ p For Source_Position Use External source_external_rep; -- finally, we define the node type source_external_rep ~ce_external_rep

End

=>

Hie line char

• string,

.* Integer, : Integer;

Section 1 . 4 . 3

Introduction

This

example c o m p l e t e s

the

discussion

of

IDL,

Notice

that

/ Page 29

in the

second

e x a m p l e the Internal r e p r e s e n t a t i o n and the external r e p r e s e n t a t i o n for the private type

are

package node,

both

given.

called

The

internal

Source_Package.

source_external_rep,

externally as a string, are r e p r e s e n t e d

representation

The

external

that has three

Is d e s c r i b e d

representation

attributes,

a file

and a line number and c h a r a c t e r

externally by the

basic type

"Integer'.

2 we present a r e f i n e m e n t D i a n a _ C o n c r e t e of DIANA.

in

a

separate

Is defined

name.

position,

as

a

represented

both of which

At the end of C h a p t e r

tn Chapter 5 we define the

c a n o n i c a l external r e p r e s e n t a t i o n of DIANA.

l, 4.4.

DIANA Notational Conventions

The

definition

conventions

of

that

DIANA given

are

intended

In the

to

next chapter

improve

the

observes

readability

of

some the

notational

presentation,

These include: ° Wherever AFD.

reasonable,

both

nodes and classes a r e

named

as in the

° T y p o g r a p h i c c o n v e n t i o n s are a d h e r e d to for c l a s s n a m e s , node names, and attributes to assist the reader. These conventions. which are a r e listed In Figure 1-1 on page 2"1. a r e that class n a m e s a p p e a r in all u p p e r - c a s e letters, nodes names in atl lower c a s e , and attribute names italicized. o A class name or node name ending in "_S' or " _ s ' respectively is always a s e q u e n c e of what c o m e s before the " _ ' . Thus the r e a d e r can be sure on seeing a class name such as FOO_S that the definitions FO0_S foo_e

=>

foo_s

=>

a s list:

; 3eq of FO0

;

appear s o m e w h e r e . o A class name ending in " VOID" always has a d e f i n i tion such as FO0 VOID

=> ~

void

=>

I ~oia

;

;

The node void has no attributes, = There are four kinds of attributes defined in DIANA: structural, The names of t h e s e attributes a r e semant~c, and code, lexically distinguished in the definition as follows:

lexical,

as

structural attribute. The structural attributes define the a b s t r a c t syntax tree of an ADA p r o g r a m . T h e i r names a r e

Page 30 / Section l . , L 4 .

those used in the AFD,

DIANA Reference Manual

prefixed with "as_'.

Ix

~exicat attributes. These provide information about the source form of the program, such as the spelling of ~dentlfiers or position ~n the source file.

sm~

semantic attributes. These e n c o d e the results of semantic a n a l y s t s - - t y p e and o v e r l o a d resolution, for example,

cd_

code a t t r i b u t e s - - t h e r e is only one. This provides i n f o r mation from r e p r e s e n t a t i o n specifications that must be o b served by the Back End.

= Although ~DL is insensitive to the o r d e r of attribute definitions with "=>' rules, we have preserved the order used in the AFD. Additionally. for emphasis we have grouped structural, texlcal. semantic, and code attributes, always in that order. The DIANA definition Is organized In the same m a n n e r as the ADA LRM. To establish the c o r r e s p o n d e n c e , each set of DIANA rules begins with a c o m m e n t that gives the c o r r e s p o n d i n g section n u m b e r of the AOA LRM and the c o n c r e t e syntax defined there.

Definition of the Diana Domain

Page 3]

CHAPTER £ DEFINITION OF THE DIANA DOMAIN

This chapter Is devoted to the definition of the domain of the DIANA abstract type - -

that is,

to the definition of the set of attributed trees that model the

values of the DIANA type.

The definition is given in the notation discussed

tn

section "1,4, A simple refinement of the DIANA abstract structure follows the definition of the DIANA d o m a i n .

This refinement defines the external representation of" the p~'ivate

types used, Before beginning the definition, which constitutes the bulk of this chapter, make two observations about things that are not defined here. ° First, there are six private types used in the definition. Each of these c o r r e s p o n d s to one of the kinds of Information which may be Installation or target machine specific. They Include types for the source position of a node, the representation of identifiers, the representation of various values on the target system, and the representation of comments from the source program. The DtANA user must supply an implementation for each of these types, ° Second, as fs explained in the AOA reference manual, a p r o g r a m is assumed to be compiled tn a "standard e n v i r o n m e n t ' . An ADA p r o g r a m may explicitly or Implicitly reference entities defined in this e n v i r o n m e n t , and the DIANA representation of the p r o g r a m must reflect this. The entities that may be referenced Include the predeflned attributes and types. The DIANA definition of these entities is not given here but is assumed to be available. See Appendix I for m o r e details. With these exceptions, the following completely defines the DIANA domain.

we

Page

32

/

Section

2

DIANA R e f e r e n c e

Structure Diana Root COMPILATION Is

Diauna R e f e r e n c e

Version

of

Manual

17 F e b r u a r y

1983

Type sourceposition; defines source position in original source program; used for error messages. Type comments; representation of comments; source reconstruction.

used for

Type symboLrep; ~epresentation of identifiers, strings, and characters Type value; implementation defined gives value of a static expression; can indicate that no value is computed.

N

Type operator; enumeration type for all operators used in implementation Type numbe~_rep; representation of numeric literats --

2.

I,e~ic.al

Elements

- - Syntax 2.0 has no equivalent in concrete syntax

void =>

-- 2 . 3

Xdentifiers,

;

2.4 NuReric

~

Literals,

has no attributes

2.6 String

- - Syntax 2,3 -not of interest for Diana

ID::=

DEF_ID I USEO_ID;

OP ::=

DEF_OP ~ USED._OP;

DESIGNATOR ::=

ID I OP;

DEF_CCCURRENCE ::=

DEFJD ~ DE[FOP | D E F _ C H ~ ;

see 4 . 4 for numeric titeral

Literals

Manual

Definition

-- 2.8

--

of the

Diana

Domain

Section

2

/

Page

33

Pracja~B These productions do not correspond to productions in the concrete syntax.

Syntax 2 . 8 . A pragma : := pragrna identifier [ ( ~ r g u m e n t association {, ~rgoment._essoctation})];

PRAGMA : :=

pragma;

pragma =>

a#_/d a#_param_aasoc_~#

pragma =>

Ix_srcpo# Ix_comment#

PARAM ASSOC S : :=

peram_assoc s;

param_aasoc_s => param aasoc s =>

as_liet tx_#rcpo# Ix_comment#

: : : :

ID, - - a 'used_name id' PARAM_ASSOC S; source position, comments;

: Seq Of PARAM ASSOC; : source_position, : comments;

- - Syntax 2 . 8 . B argumenCassoclation : : : -[argument..identifier => ] name N I [argument_identifier =>] expression - - see 6 . 4 for associations

-

-

3;

-- 3.1

Dec].a.ca.tior~

and

Deolarat£ons

- - Syntax 3.1 - - declaration : : = -object_declaration -I typedeclaration -I subprog ram_.declaration -I taskdeclaration -I exception_declaration -I renaming_declaration

DECL : :=

DECL : : =

number_declaration subtype_dec4aretion peck#g# declaration generio_dedaration generic in=tantiation deferred constant_declaration

constant I var --object_declaratlon (3.2.A) number - - n u m b e r declaration ( 3 . 2 . B ) type - - type._d~laration ( 3 . 3 . 1 ) subtype - - subtype, declaration ( 3 . 3 . 2 ) subprogram d ~ l - - subprogramdeclaration ( 6 , 1 ) package._decl - - package_declaration ( 7 . 1 ) task de¢l - - task declarstion (9.1) generic ~ generlc._declaratton (12.1) ec~ception ~ exceptlondeclaration ( 1 1 . 1 ) See 12.3 for ger~ric_tnstantlation, m See 8 . 5 for renaming declaration, I deferred constant; m deferred_constant_declaration pragma;

(7.4)

pragma allowed as declaration

ADA S e c t i o n

2.3

Page 34 / Sectior~ 2

DIANA Reference Manuat

- - Syntax 3 . 2 . A object_declaration : := identifier list : [¢onstlmt] subtype indication [ : = expression]; -| identifier_list : ~cor,.MJnt] c o n s t r a i n e d a r r a y d e f i n t t i o n [ : = expression]; -

-

=

_

OBJECT DEF ;:= EXP voTD ; : = TYPE- SPEC : := constant = >

EXP VOID; EXP I void; CONSTRAINED; ID S, .-- sequence of 'const id' TYPE SPEC, OBJECT._OEF; source_position, comments;

~s_jd_s

as_type_apec as_object_def fx_,~rcpos lx_oornmenM

constant =>

a~_jd_s

ID.. S,

as_type_spec a~_objecJdef

TYPE_SPEC,

vet =>

~x..srcpo~

OBJECT_DEF; source_.position, comments;

DEF ~D : : =

v~r ~ ;

vat. td =>

~x_srcpos Uxcomments Ix_symrep ~_obLtype ~m..addres,~ •~m_obLdef

vat =>

~x_commenta

var._id =>

DEF_tD : : : - - see

: : : : : :

- - e, sequence of 'var..id'

source position, comments, symbol, rep; TYPE SPEC, EXP ._VOID, OBJECT._DEF;

const id;

rationale Section 3 , 5 , 2 for a discussion of deferred constants

tx_srcpos lx~comrnent,~ tx_symrep srnaddress ~m_obLtype =rnobLdef ~m_first

const id => const id =>

ADA S e c t i o n

3. t

: : : : : : :

sourceposition, comments, symbol rep; EXP...VOID, TYPE._SPEC, OBJECT DEF, DEF._OCCURRENCE;

- - used for deferred

Definition

of the

Diana

Domain

Section

2 /

Page

35

Syntax 3 . 2 . B number decoration : : : identifier._list : oonldNd := univeraat._Matic._expression;

number => number =>

aaid_s aa_exp Ix~rcpoa Ix_commenf~

DEF._ID : :=

number, id;

number id :>

Ix_~rcpo~ Ix_comments Ix_aymrep am_obj_type am_inif_exp

numbeLid =>

: : : :

ID S, ~ always a sequence of 'number id' EXP; source_position, comments;

: : : : :

source_pesition, comments, symbol rep; TYPE SPEC, - - always refers to • universal type EXP;

- - Syntax 3 . 2 . C identifier list ::= identifier [, identifier}

--

- -

- -

- -

ID._S : :=

id_s;

id_s => id s =>

as._list Ix_srcpoa Ix_.commenta

: Seq Of I0; : source_position, : comments;

3.3.z

Syntax 3 . 3 , 1 . A type_declaration : := fu;l_type declaration I incomplete_type_declaration I private_type_declaration full_type_declaration : := type identifier [discriminant.pert] is typedefinition; - - see 7.4 for private_.type, declaration see 3,8.1 for incomplete._type_.declaration type =>

aa_id

type : >

Ix_,srcpos Ix commenfa

D E F J D : :=

type Id;

type_ld =>

Ix_arcpos Ix_©omment~ Ix_.~mrep

type_id =>

8m_type_.spec

aa_dacrmt_var_a aa_fype_ape¢

~n_firat

: tD,

- - a 'type k:P, - - 1_private. type_id' or - - 'pr~ate. type_kJ' : D~'RMT._VAR $, - - dlscrlmlnant list, see 3.7.1 : TYPE SPEC; : source position, : comments;

: aource_po~t~m, : : : :

comments, symbol_rap; TYPE SPEC, DEFOCCURRENCE;

- - used for muir|pie clef

ADA S e c t i o n

3. P. A

Page 3 6 /

Section

2

DIANA R e f e r e n c e

- - Syntax 3 . 3 , 1 , B type_definition : := -enumerationtypedefinition -} reaLtype_definition -I record type_Clefinition I derived type definition

TYPE_SPEC : : =

--

-

--

3.3.2

~

integertypedefinition 1 array type definition ; access type_definition

enumJiteral_s ! integer { fixed I ficet I array record access i derived;

-- enumerationtypedefinition (3.5.1) integertype_definitlon (3,5.4) real type definition ( 3 . 5 . 6 ) array type_definition (3.6) -- recordtypedefinttion (3.7) - - acoess_.type, definition ( 3 . 8 ) derived_typedefinitlon (3.4)

--

-

-

-

]Dec]x~c-af~octa

Syntax 3 . 3 , 2 . A subtypedeclaration

: : = subtype identifier is subtype indice, tion;

aLid as_conMrained /x_srcpos

subtypo => subtype =>

ix._comments OEF._ID : :=

subtype id;

subtype_id :>

~x_srcpo~ ex_commenf,s ~x._~ymrep

s u b t y p e J d =>

~-n type_spec

: : : :

ID, CONSTRAINED; source position, comments;

: : : :

source position, comments, symbol rep; CONSTRAINED;

: : : : : : : :

NAME~ CONSTRAINT; sourceposition, comments; TYPE SPEC, WPE SPEC, CONSTRAINT; Integer;

--- Syntax 3 , 3 , 2 , B subtype ~ndic.stion : : = type_mark [constraint] --

type m=rk : : = type ham e

I ~subtype name

CONSTRAINED : := CONSTRAINT : :=

constrained; void;

constrained =>

aaname a=_consfrainf Ix._ercpos Ix.._comment8 am_type ~trucf am_baae._type am_conMrainf cd._impl_~ize

constrained => constrained => constrained =>

AOA S e c t i o n

3.3,

loA

Manual

Definition

----

of

the

Diana

constraint : := range constraint I index constraint

3.4

Dez~ved

Type

derived =>

derived =>

Page

37

I fixed_point_constraint

(3.7.2)

::= new subtypetndication

: : : : : : : : :

CONSTRAINED; sourceposition, comments; EXP VOID, Rational, Boolean, Boolean, EXP._VOID; Integer;

Sca'ta,"

- - Syntax 3 . 5 -range_constraint --

/

~finitio~s

aa_con~rained Ix_srcpos Ix_comments 8m_aize am_acfual_delfa sm._packing am_confrolled sm_atorege_aize cd._impl_aize

derived => derived =>

3.5

I flosttng_point constraint [ disoriminant constraint

RANGE ~ range constraint ( 3 . 5 ) I float N floating_point_constraint ( 3 . 5 . 7 ) 1 fixed -- fixedpoint_constraint (3,5.5) I dscrt_range s m indax constraint ( 3 . 6 . C ) I dscrmt aggregate; - - dtscriminant_constraint

- - Syntax 3 . 4 -derivedtype._definition m

--

2

Syntax 3 . 3 , 2 . C

CONSTRAINT : :=

--

Section

Domain

: : = ra=n~e range

range : := range attribute I simple_expression . . simple_expression

RANGE : : =

range

range =>

as_axpl

: EXP,

aa_exp2 range =>

Ix_srcpco Ix_comments am_base type

: EXP; : source position, : comments; : TYPE._SPEC;

range =>

Ent.mexa.tion

| attributel

attribute ceil;

'l'yjpes

--

3.5.1

--

Syntax 3 . 5 . t . A enumeration._typedefinltion : : = ( e n u m e r a t i o n literal spectfioation {, enumeration literal_specification})

e n u m l i t e r a l _ s => e n u m literal s => e n u m literal s => e n u m literal s =>

as_list Ix_arcpos Ix_comments am_aize cd_impl__size

Seq Of ENUM LITERAL; source position, comments; EXP_VOfD; Integer;

ADA Section

3.3.2.

B

Page 38 / Section 2

~')|ANA R e f e r e n c e

Manual

Synta~ 3, 5, 1,E~ enumeration liters| ~pecific~t~on : := enumerstionJiter~|

- -

enumeratio~ Jiteral : : = identifier I ¢h~.racter liters|

ENUM LffERAL : : = DEF_ID : : = D E F C H A R : :=

enum._id ~ def._char; enum id; ~ef_ch&r;

enum id =>

lx~rcpo~ Ix comments tx._symrep am_ob}_type

: : : :

~m_po~

:

enum ~d =>

smj e p 8x_srcpo~ lx comment~ ~x_symrep ~mobj_type

d e L c h s r => def char =>

~m_rep -- 3.s.~

sourceposition, contrr~nts= symbol rep; TYPE SPEC, ~ refers to the 'enum Uteral~s' Integer, - - consecutive position (bose 0) Integer; - - user supplied representation value

: : : : : : :

RANGE; source_position, comments; EXP. VOID, TYPE SPEC, TYPE_$PEC; ~ 'derived' Integer;

: : = range constraint

esjange txarcpos 2x_comments sin_size 8m_fypestruct sm_.baaefype ¢dimpl_size

integer => integer => integer => integer => -- 3.5°6

: : : : : :

~[nteger ~L~es

Syntax 3 . 5 . 4 integer._typedefinltion

- -

source._position, comment~, symboLrep; TYPE SPEC, - - refers to the 'ChUm literaL_s' Integer, - - consecutive position (base O) : integer; - - user supplied representation value

ReZLI

- - Synt&x 3 . 5 . 6 -- realtype_definition ::= floating_point_constraint

- -

see 3 . 5 . 7 ,

ADA S e c t i o n

3.5.9

3 . 5. ] , A

~ fixed=point constraint

Definition

--

3.5.7

of the

Diana

Section 2 / Page 39

Domain

Floating Point Types

- - Syntax 3 . 5 . 7 - - floating_point_constraint : := -floating_accuracy_definition [range constraint] --

f l o a t i n g a c c u r a c y d e f i n i t i o n : : = digits static simpie_expression

RANGEVOID : : =

RANGE I void;

float =>

a~...exp as_range_void Ix._arcpos Ix_comments

float => float =>

,~n ~/ze

float =>

am tFpe_~truct sm_baaefype ¢d_impl_slze

--

3.5.9

--

Syntax 3 . 5 . 9 fixed_point constraint : := fixed accu racy_defirdtion [ range_constraint]

--

Fi,~DL~I ] P o i r ~

: EXP, : : : : : : :

RANGE._VOID; sourceposition, comments; EXP_VOID, TYPE SPEC, TYPE SPEC; - - 'derived' Integer;

Types

f i x e d a c c u r a c y d e f i n i t i o n : : = delta staticsimpteexpression

fixed => fixed => fixed =>

fixed =>

aa_exp as_range_void Ix_arcpos Ix_comment~; am_size sm_ scfual_ delta sm_bifs ~'n base_type cd_impl_size

EXP, RANGE_VOtD; sourceposition, comments;

EXP_V~D.

Rational, Integer, TYPE SPEC; - - 'derived' Integer;

ADA S e c t i o n

3.5.6

Page

40

/

Section

DIANA R e f e r e n c e

2

- - SYntax 3 . 6 . A -array type definition : : = -unconstrained array definition ---

m constrainedarraydefinition

unconstrainedarraydefinition ::= stray(index=subtype definition {, ~ndex_subtype definition}) of

---

componentsubtypeindication constrained u r a y definition : : = array index Constraint of componenLsubtypeindioation

as_dserfrange._s aS_cons'trained tx_arcpo~ @x_commenta ~m_aize ~m_packing

array => array => array => DSCRT RANGE S : : =

d a c r L r a n g e s;

dsort range s => dsort range s =>

asJisf Ix_arcpos ~x_comment

: : : : : :

DSCRT RANGE S, ~ CONSTRAINED; ~ sourceposition, comments; EXP VOIO, Boolean;

OSCRT RANGE : : =

index;

index => index =>

as_name tx_srcpos Ix_comments

: NAME; : sourceposition, : comments;

- - Syntax 3 . 6 . C -index constraint : : = (discrete range {, discrete range}) d i s c r e t e r a n g e : : = diacrefe, subtype indication I range

OSCRT RANGE : : =

ADA S e c t i o n

3.5, 9

index subtypes or constraint component subtype

: Seq Of DSCRT RANGE; : source position, : comments;

- - Synta~x 3 , 6 . B i n d e x s u b t y p e d e f i n i t i o n : : = type mark range <>

--

Manual

constrained ~ RANGE;

Definition

--3.7

of the

Diana

Domain

Section

2 /

Page

41

~'1'Y1:~

Syntax 3 , 7 . A record_type_definition : := reoord -component liut end record

--

--

REP I void;

REP_VOID : := record => record =>

a$.Ji~/

Ix._,srcpo,s Ix_comments sm_8ize em_di,scriminant~ ~m_packing em_record_6pec

record =>

: : : : : : :

Seq Of COMP; sourceposition, comments; EXP._VOID, DSCRMT_VAR S, Boolean, REP VOfD;

- - Syntax 3.7,13 - - component_list : : = component_declaration {component declaration} I {component._declaration} v a r i a n t p a r t -I null; componentdeclaration ::= identifier list : component subtype definition [ : = expression]; componentsubtypedefinition

COMP : :=

: : = subtype indication

var I variant_part I nutl comp;

COMP : :=

pragma;

null comp =>

Ix_srcpo.s Ix._comment8

DEFID

comp_id;

::=

COMP.REP._VOIO comp id => comp id =>

::=

component declaration (3.2) where ID is 'comp id' variant_part ( 3 , 7 , 3 . A ) - - null (see below) pragmas are allowed in component declarations : source position, : comments;

COMP REP I void; Ix_srcpoB

Ix commenta IXm#ymrep ~m~_obj_type 8m._init_exp arn_comp_apec

: : : : : :

sourceposltion, comments, symbol._rep; TYPE._SPEC, EXP.VOID, COMP_REP VOID;

ADA S e c t | o n

3, 6, C

Page

42

-- 3.?.1

/

Section

D~ANA R e f e r e n c e

2

D . i s c ¢ ~

- - Syntax 3 . 7 . 1 M discriminant p~rt : : : -(disoriminant_specific~tion -

{; disoriminant_specification})

discrimtnant specification : := identifier l i d : t y p e m a r k [ : :

-

DSCRMT VAR S : : =

expression]

dscrmt vat s;

tx_srcpo~ ix comments

: Seq Of DSCRMT_VAR; : source_position, : comments;

DSCRMT._VAR : :=

dscrrnt vet;

- - where 'ID' is always a 'dscrmt_id'

dsormt_var =>

a~_id_s

dsormt var s => d ~ r m t _ v a r S =>

asJisf

ID__S, - - a sequence of "var_td' NAME, OBJECT DEF; sourceposition, comments;

as_name as_object def dsormt_var = )

tx_#rcpo~ tx_corn menf¢

DE~JD

dscrmt_.id;

:::

tx_srcpos ~x_ comment~ ~x_symrep ~m_obj_type ~m_tnit_exp ~m_fir~t ~m_comp_ spec

dscrmt_id :> dscr'mt _td :>

--

3,7.2

: : : : : : :

sourceposition, comments, symbol rep; TYPE SPEC, EXP. VOID, DEF OCCURRENCe, COMP REP_VOID;

D~Ku:Jw.i.nant

- - Syntax 3 . 7 . 2 -disoriminant constraint : : = (disoriminant association {, disoriminant association}) dtsortminant association : :=

--

[ discrim'~ant simple name { I di~criminsnf simple nsme} => ] expression

dscrmt_eggregate => dsormt_aggregste => dsormt eggregat@ =>

sa_iist : Seq Of COMP ASSOC; tx._srcpos : sourceposition, ix_comments : comments; ~m_normatized_compa : EXP_S;

- - see 4 , 3 . B for discriminant association

ADA S e c t i o n

3.7.

B

Manual

Definition

of the

-- 3.7.3

Vzuciant

--------

Diana

Se~ion

Domain

2

/

Page

43

P~cP.s

Syntax 3 . 7 . 3 , A variantpart ::=

c u e dtscriminant simple_name is variant {variant} erKI came;

var~nt ::= when choice { | choice} => component list

variant_part : >

as_name as var/anf_s

variant_part =>

Ix_srcpos Ix_comments

V A R I A N T S : :=

wrtsnt_s;

variants variants

as_list Ix_srcpo~ Ix_comments

=> =>

: : : :

NAME, VARIANT_S; 8ource_position, comments;

: ~ Of VARIANT; : sourceposition, : comments;

VARIANT : : = CHOICE S : := INNER_RECORD : :=

vari=mt; choices; inner._record;

c h o t ~ s => c h o i c e s =>

as_li~t Ix_srcpo~ Ix_comments

: Seq Of CHOICE; • source position, comments;

v~d=nt =>

as_cho/ce_s asjecord

variant =>

Ix_srcpo~ Ix_comments

: : : :

inner renord => inner record =>

as_list Ix_srcpo~ Ix_conm,mnfs

CHOICES, INNER_RECORD; source_position, comments;

: Seq Of COMP; : sourceposltion, : comments;

- - Syntcx 3 , 7 , 3 , B choice : : = slmple_expressiorl -I d i s c r e t e r a n g e I ol]lte~ I component simple_name

CHOICE : : =

EXP | DSCRT._RANGE

others =>

Ix_srcpoa Ix_comments

I others;

: cource_position, : comments;

ADA S e c t i o n

3.7,2

Page

44

-- 3 . 8

/

Section

Access

2

DIANA F ~ e f e r e n c e

Types

- - Syntax 3. S - - access_type definition ;:= aooess subtype indicstion

as_conMrained ~x_srcpos ix_comments ~m_size sm_stotage_t;ize am_controlled

aCCeSS => access = > aCCeSS =>

: : : : : :

CONSTRAINED; sourceposition, comments; EXPVOID, EXP VOID, Boolean;

- - See 4 . 4 , C ~or nun access value -- 3 . 8 . 1

Inccs~lete

~

Declar~tio~J3

- - Syntax 3.8.1 - - incomplete type_declaration ::= type identifier [discriminsnt part];

TYPE SPEC : :=

void;

incomplete types are described in the rationale Section 3 . 5 . 1 . 1 --' 3,9

Decla/ative

Parts

- - Syntax 3.¢J~A - - dedarative._part ::= -{basic._declarative._item j {later declarative_item} -=_

basic declarative item ::= basic declaration |--representa~on clause I us-e_cteuse

REP I use;

DECk. : :=

--representation is declarative item

- - Syntax 3 . 9 . B - - later declarative item ; ;= body I subprogram_declaration I packagedeclaration | task decleration I generic declaration -I use. clause | generi%instantiation body --

:;=

proper_t~dy I stub

p r o p e r b o d y : : = subprogram body I package body I task_body

ITEM S : := ~TEM ::= -see 3.1, 6.1, items items

item_s; OECL I subprogram_body I package_body I task body; 7.1, 9.1, 10.2 (stub included in b o d y definitions)

=> =>

ADA S e c t i o n

as_tiM

txarcpos ix_comments

3 . 7 , 3. B

: Seq Of ITEM; : sourceposition, : comments;

Manual

Definition

-- 4.

of the

Diana

Domain

Section

2

/

Page

45

Names a n d ] E : ~ c e = m ¢ o r m

-- 4.1 - - Syntax 4 , 1 .A - - name : : = simple name -I character_llteral I operator symbol -t indexed component I slice -I selected_cemponent I attribute --

simple_name : := identifier

m

NAME : :=

DESIGNATOR I usedchar |

indexed

I slice I selected I attribute

identifier and operator ( 2 . 3 ) character literal (see below) indexed ~ m p o n e n t ( 4 . 1 . 1 ) ~ alice ( 4 . 1 . 2 ) I all --selected_component (4,1.3) ] attribute call; --attribute (4,1.4)

USED.K) : :=

us~

used_ob ject_id =>

IX_~rcpos Ix_comments Ix_symrep ~rn_exp_type sm_defn

used_object id =>

ob)ect_id

sm_va/ue used name id => used_name td => used_bltn id => used bltn id => N

~

I uced_name_id : : : : : :

Ix rrrcpos Ix_comments Ix_symrep 8rn_defn Ix_srcpo~ Ix_comment~ Ix_aymrep ~,n._operator

I used_bltn ld;

sourceposition, comments, symbol_rep; TYPE_SPEC, DEF OCCURRENCE, value; source position, comments, symbol rep; DEF OCCURRENCE;

: : : :

sourceposition, comments, wmbol_rep; operator;

see 3 , 8 . 5 of rationale for a discussion of built-in subprograms

USED_OP : :=

used. op 1 used bitn._op;

Uced_op =>

Ix_srcpos Ix_¢omment~ Ix_eymrep am_defn

: : : :

sourceposition, comments, symbol, rep; DEF OCCURRENCE;

used bltn _op =>

Ix_ercpo~ Ix_comments Ix_symrep ~rn_operator

: : : :

scurce position, comments, w m b o l rep; operator;

used_char =>

fx_srcpo~

: : : : : :

source position, sommeflts, symbol rep; DEF OCCURRENCe, 'PfPE SPEC, value;

used_op => uced bltn op =>

used char =>

Ix_commenta Ix_aymrep 4rn_defn m._exp_type am._va~,e

--

~ ~

Syntax 4 . 1 . B prefix : : = name I function call NAME : :=

functioncell;

~

see 6 . 4

ADA S e c t i o n

3.9.

B

Page

46

/

--

DIANA R e f e r e n c e

2

Manuat

Zndk~c~s~ Caaj~oc~n'c.s

-- 4.1.i --

Section

Syntax 4.1,1 indexed component : : = prefix(expression {, expression})

EXP S : : =

exp s;

exp s => exp s =>

as_liar txsrcpo~ ~x_commenta

: Seq OF EXP; : sourceposition, : comments;

indexed =>

as_name as_exp_s txsrcpos ix_comments ~m_exp_type

: NAME, : EXP_S; : sourcepositlon, : comments; : TYPE SPEC;

indexed => indexed =>

-- 4.1.2

sllce8

- - Syntax 4 . 1 . 2 - - sflce ::= prefix(discrete range)

as_name aa_dscrt_range fx_arcpo6 txjomments sm_exp_type ~rnconMreint

slice => slice => slice =>

-- 4.

I.

3

Selected

~

- - Syntax 4 . 1 . 3 - - selected component : : =

~

: : : : : :

NAME, DSCRT._RANGE; sourceposition, comments; TYPE SPEC, CONSTRAINT;

s

prefix. ~elector

selector : := simple name I character_literal I oporator, symbol ~ all

DESIGNATOR CHAR: ;=

DESIGNATOR ~ used. char;

selected =>

es_.neme as_designator_char Ix ercpos tx comments sm_exp_fype

selected => selected => all => all : >

as=name tx_srcpos Ix_comments

all =>

am_exp_fype

ADA S e c t i o n

4.1.

B

character ilterels allowed as aelector

NAME, DESIGNATORCHAR; source position, comments; TYPE_SPEC; : N A M E ; -used for name.all ; source position, : comments; : TYPE SPEC;

Definition

of the

Diana

-- 4 . 1 . 4

Attribut~z

Section

Domain

2

/

Page

47

- - Syntax 4 . 1 . 4 -attribute : := prefix'attribute_designator --

attribute_designator

: : = s i m p l e n a m e [ (unlver=;al.._ststtc_.expression) ]

attribute =>

a~_name a~._id

attribute = >

Ix_arcpo~ Ix_comment=; em_exp_type ~m_value

attribute => attribute call =>

attribute call => attribute_call =>

-- 4.2

a=;_name a=;_exp Ix_=;rcpo~ Ix_comments =;m_exp_type am_value

: NAME, : ID; - - always a 'used nsme_id', - - whose attributes point to - - a predefined 'stir id' sourceposltion, comments; WPE SPEC, value; : NAME, - - USed for attributes - - with arguments N NAME can only be attribute : EXP; : sourceposttion, : comments; : TYPE_SPEC, : value;

I,iteza.ls

- - Refer to 4 . 4 . C for numeric_literal, - - and null access, - - Refer to"4.1 for character.literal

string literal,

- - The enumeration literal is represented as a =used object id' or a 'used chad w h o ~ attributes point to an 'enum i d r o r a 'def_char'. - - See 3 , 5 , 1 . 8

-- 4.3

]~jgzegates

Syntax 4 . 3 . A : := (component.essociation

aggregate

{, component association])

N

EXP : : =

aggregate;

aggregate => aggregate =>

as_list : Seq Of CO~P_ASSOC; Ix_srcpos : source_position, Ix._comment=; : comments; sm_exp_type : TYPE SPEC, am_constrainf CON~RAINT, am_normallzed._comp_s : EXP._S;

aggregate =>

- - Syntax 4 . 3 . B ¢omponent_associatlofl, : : = [choice { I choice} => ] expression

COMP ASSOC : : =

named I EXP;

named =>

a=;_cho/ce_a

named =>

es_exp Ix_srcpos Ix_comment=;

: CHOICE.S, : EXP; : sourse POsRIOn, : comments;

ADA S e c t i o n

4.1.3

Page

48

-- 4.4

/

Section

OIANA R e f e r e n c e

2

E,r,:p,~:csicms

- - Syntax 4 . 4 . A : :: relation {and ~telation} I relation {or relation} J relation {xor relation}

expression

----

EXP : :=

I relation {and then relatien} ! relation {or else relation}

only tar short-circuit expressions; see 3 . 3 . 4 of rationale

binary; --

aa_expl aa_binary_op as_exp2 Ix._arcpOS tx~ment~ am_exptype

binary => btn~ry => binary =>

,~m_vakae BINARY OP : := SHORLCIRCUIT_OP : : =

SHORT_CIRCUILOP; a n d t h e n I or.._else;

and then :>

Ix_arcpaa Ix_comments Ix_arcpo~ ~x._commenta

or. else

=>

: EXP, : BINARY OP, : EXP; : source posiUon, : comments; : TYPE SPEC, - - always the T~fPE SPEC - - of a Boolean type : value;

: : : :

sourceposition, comments; sourceposition, comments;

- - Syntcx 4 . 4 . - - relation : : = -simple expression [relational operator s i m p l e e x p r e s s i o n ] -t simple expression [ n o t ] in range -I simple expression [-not] in t y p e m a r k

EXP : := TYPERANGE ::=

membership; RANGE t NAME;

membership =>

a¢_axp as_memberahip_op as_type_range Ix~ropo~ tx_comments sm_exp_typ~

membership => membership =>

am_value MEMBERSHIP OP : : =

~n_.op ~ not in;

in._op =>

~x_arcpo~ tx_commen~s

~x_srcpco Ix_¢omment~

not_in =>

AOA S e c t i o n

4.3.8

: EXP, : : : : : -:

MEMBERSHIP..OP, TYPE_RANGE; sourceposltion, comments; TYPE SPEC, - - always the TYPE SPEC of a E~>olean type value;

: : : :

sourco posRion, comments; sourGe_position, comments;

Manual

Definition

---

of the

Diana

Section

Domain

2 /

Page

49

Syntax 4 , 4 . C simple expression ::= [unary_operator] term {binary_adding_operator term} term ::= factor {multiplying operator factor}

--

factor : : = primary [ ~ * primary]

Iabs

primary I not primary

- - Syntax 4 . 4 . D m primary : := -numeric_literal | null | aggregate t string literal 1 name I allocator -I funstion call I type conversion I qualified expression I (expression)

EXP ::=

NAME I numer~ literal I null_access I aggregate I string_.llteral I allocator I conversion I qualified I parenthesized;

- - n a m e , function call (4,1, 6,4) numeric literal (below) - - null (se~ below) - - aggregate (4.3) - - string literal (below) allocator (4,8) typeconversion (4.6) qualified, expression (4.7) - - (expression) (below)

This is not a construct in the FoPmal Definition. See rationale parenthesized => parenthesized => parenthesized =>

aa_exp Ix_srcpoa Ix_commenfa am_exp._type am_value

numeric literal =>

Ix_arcpo8 Ix_commenta Ix_numrep am_exp_typo

string literal : >

Ix_.arcpoa Ix_commenM Ix aymrep am_exp_fype am_conutrainf

: : : : :

EXP; ssurce :position, comments; TYPE_SPEC, value;

source_position, comments, number_rep; TYPE SPEC, numeric literal => value; am._va/ue if there is implicit cunversion sm_exp type reflects conversion; otherwise it references a univeraal type

s t r l n g l i t e r a l =>

am_vah.le

null acoess => null access =>

lx_srcpoa Ix_commenta ~m exp_/ype am_value

: source position, : comments, : symbol rep;

: TYPE SPEC, : CONSTRAINT, : value; : ssurce position, : comments;

: TYPE S ~ C , : value;

ADA S e c t i o n

4.4.

B

Page

50

4.5 --

/

Section

2

DIANA R e f e r e n c e

Operators amd Expression ~Taluation

Syntax 4 . 5 logicei_operator

::= ~

relational_operator --

adding operator : : =

--

unary o p e r a t o r multiplying highest

~ or I ~r

::=

::=

operator

precedence

•

= ~ /= t -

~ < I <=

t > ~ >=

~ &

* | ::= ~ I / operetor

t rood

: : = ==

I ram

i ~

t not

operators are incorporated in function calls, see 3 , 3 , 4 of rationale operators are defined in Diana r e f i n e m e n t , Diana Concrete

-- 4 . 6

Type C o n ~ r s i o r s

Syntax 4, G typeconversion

: := type

conversion =>

asname

a~._exp }x_~cpos ~x_comments am__expfype ~m._velue

conversion => conversion =>

4.V ---

mark(e~presston)

NAME, EXP; source_position, comments; TYPE_SPEC, value;

QQcg/ified Expressioms

Syntax 4 . 7 qualifiedexpression : := typemark'(expression)

~ type_mark®aggregate

qualified =>

as_name as._exp

qualified =>

Ox._ercpo~

}x_comment~ ~'n_exp._fype =m_value

qualified =>

4.8

: : : : : :

: : : : : :

NAME, EXP; cource_positton, comments; TYPE_SPEC, value;

~l.locatoz's

Syntax 4 , 8 allocator : := n e w subtype

indication

t n e w qualified

expression

EXP._CONSTRAINED: : =

~P

allocator => allocator =>

=~_exp_conatreined: Ox_~rcpos : fx_¢ommenta : ¢~n_exp_type :

allocator =>

t CONSTRAINED;

~m_va~

ADA S e c t i o n

4, 4 , 0

EXP_CONSTRAINED; sourceposition, comments; TYPE SPEC, : value;

Manuai

Definition

-- 5 .

of the

Diana

Section

Domain

2

t

Page

51

statements

-- 5 . 1

Simple

ar~ Compound

Statea~nts

- Sequences

of Stateaents

- - Syntax 5.1 .A sequence of statements : : = statement {statement}

STM_S : : =

stm s;

=tin s => stm s =>

aa__/i~

Ix_arcpoa Ix_.commenf~

: Seq Of STM; : source position, : comments;

- - Syntax 5. I , 8 ---

statement : := [label] simple_statement

I {label} compound statement

STM : :=

labekad;

labeled : >

aa_./d_a

labeled =>

a~_atm Ix.J;rcpos Ix commenta

DEF._ID : :=

labeLid;

label,id :>

Ix_srcpo~ Ix comment8 Ix_,~ymrep sm_stm

labol_id =>

ID S, - - Seq of 'label id' STM; sourceposition, comments;

: sourceposition, : comments, : symbol rep; STM; - - always 'labeled'

- - Syntax 5.1 .C - - simple statement : : = null statement -I a ~ i g n m e n t statement I procedure_¢~ll statement -t exit_statement I return._statement -I goto statement I entry cell_statement -I delay statement I abort_statement -I raisestatement I code_statement

STM : : =

null stm Is,sign procedure_call exit return goto entry call delay abort raise code;

-------

STM : :=

pragma;

pragma allowed where - - statement allowed

null statement ( 5 . 1 . F ) asa~nment_~stement ( 5 . 2 ) procedure_call statement ( 6 . 4 ) exit statement ( 5 . 7 ) return statement ( 5 . 8 ) goto statement (5.9) entry ¢all ¢tatement ( 9 . 5 . B ) d e l a y s t a t e m e n t (S.6) - - abo~ statement (9.10) raise statment (11.3) code_statement (13.8)

ADA S e c t i o n

4.8

Page

52

/

Section

DIANA R e f e r e n c e

2

Synta~x 5 . 1 . 0 compound statement : : = if statement I io~p statement -I accept statement

--

---

~f -- if.ststme~ (5.3) I case - - case_ststeme~ ( 5 . 4 ) named stm ! LOOP --ioop_stetement (5.5) block ~ block statement ( 5 . 6 ) ; accept - - e c c e ~ ststement ( 9 . 5 . C ) t select | cond_entry ~ t l m e d e n t r y ; select_statement (B. 7)

s'rM ~:=

--

Syntax 5 . 1 . E label : ,= < < l a b e f _ s i m p l e n a m e > >

see

--

--

5.1.B

Syntax 5 . 1 . F nulL statement : : = nu~ ;

null stm =>

-- 5.2

---

case statement block statement select statement

tx_arcpoa tx_comments

: sourceposition, : comments;

~igclment ~catement

Syntax 5 . 2 assignment statement ::= variable name := expression;

assign =>

as_name as_exp fx_srcpos Ix commenta

assign =>

ADA S e c t i o n

5. 1. C

: : : :

NAME, EXP; source_position, comments;

Manual

Definition

- - 5.3

of the

Diana

Domain

Section

2

/

Page

53

If Statements

Syntcx 5 . 3 . A if statement : : = if condition then seq uence_of__statement s - { ~ d f condition then -sequense of_statemenls} - [else -sequence of_statements] -end if; - -

----

if => if =>

ss_li~t Ix_srcpoa Ix_comments

COND_CLAUSE : :=

cond clause;

cond clause =>

a,s_exp_void

cond clause =>

Ix_srcpo~ Ix_comments

as_~tm_s

Seq Of COND_CLAUSE; sourceposition, comments;

: : : :

EXP VOID, ---void for else STM8; sourceposition, comments;

- - Syntcx 5 . 3 . B condition : ; : boolean expression

condition is replaced by EXP --

5.4

Case

Statemen~

- - Syntax 5 . 4 -- casestatement ::: - case expression i8 -cese ,steteme nt_slter native -{cese statement_alternative} end ca=e;

- -

case statement alternative ::= w~ten choice { i choice } :> sequence of _statements}

ALTERNATIVES : := ALTERNATIVE : :=

alternative_.s; alternative I pragma;

cese =>

as_exp

case --->

as_alternstive_s Ix_srcpos Ix_comments

alternative s => alternative"._s =>

ee_li~f Ix_arcpoa

alternative => aiter n~dive =>

pragma allowed where alternative allowed : : : :

EXP, ALTERNATIVE. S; source position, comments;

Ix_comment=

: Seq Of ALTERNATIVE; : sourcepositton. : comments;

as_choices ea_Mm_s Ix_~rcpo~ Ix_comments

: CHOICES, : STM_S; : sourceposition, : comments;

ADA S e c t i o n

5.2

Page

--~- -

54

/

Section

2

DIANA R e f e r e n c e

loop_statement : ;= [loop simple name: [iteration. scheme] |cop sequence_of_statementS end loop [ Ioop_simple_n~me];

named stm => named stm = >

as id as Mm lx._~rcpo~ ~x ¢omment~

DEF ~O : : =

named stm id;

named stm id => named stm "~ =>

~x_.srcpos Ix._comment~ tx_ symrep sm_Mm

LOOP : := iTERATION ; ;=

goop; void;

~oop =>

a~iferafion

loop =>

[x_srcpoa Ix comments

ADA S e c t t o n

5.4

: : : :

ID, - - always a 'named stm id' STM; - - 'loop' or 'block' sourceposition, comments;

~ource_.po$ition, comments, symbot rep; STM; - - always 'named stm ~

: : : :

ITERATION, STM_S; source_position, comments;

Manual

Definition

----

of the

Diana

Section

Domain

2

/

Page

55

Syntax 5 . 5 . B iteration scheme : : = while condition I fo~- loop_parameter_specification loop_parameter.specification : := identifier in [ r e v e r s e ] discrete_range

ITERATION : : =

for I reverse;

f o r =>

aa_jd aaJacrtjange Ix_srcpoa Ix_comments

for => reverse =>

a,s_jd

reverse =>

aa_dacr/ j a n g e Ix._arcpoa Ix_comments

DEF ID : : =

iteration id;

iteration id => iteration._id =>

Ix arcpos Ix__commenfa tx_aymrep ~m_objtype

ITERATION : : =

while;

while => while =>

as_ exp Ix srcpoa Ix_comments

5.6

Blo~

: : : :

|D, - - always an 'iteration id ° DSCRT__RANGE; sourceposition, comments; ID, ~ always an 'iteration_(d' DSCRT RANGE; sourceposition, comments;

: : : :

sourcepositton, comments, symbol_rep; TYPE SPEC;

: EXP; : .sourceposition, : comments;

S~team~

Syntax 5 . 6 block statement : : = [~ock_simple name: ] -[declare declarative pert]

--

--

b ~

N

sequence.of._statements [ exceptio, ~ption_handler {exceptionhandler}]

--

end [block_simplename]; - - see 5 . 5 , A for named block block => block =>

aa_.item_s as_stm_a a,selternative._s Ix_srcpos Ix_cornmenta

: : : : :

ITEM_S, sTMS, ALTERNATIVES; sourse positlon, comments;

ADA S e c t i o n

5, 5 . A

Page

-- 5. ? -

-

56

I

Section

DIANA R e f e r e n c e

2

E x i t ~tatement~

Syntax 5.7 exit statement ::= -exit [/oop name] ~ w h ~ condition]; -

-

NAMEVOID : : =

NAME | void;

exit =>

as.name void =s_exp_void tx_arcpos fx_comments ~m_stm

exit => exit =>

-- 5.8 -

~

-

-

-

-

1;tat~m~nts

Syntax 5.8 r e t u r n s t a t e m e n t : : = ~eturn ~expression];

-

as_expvoid tx..srcpos Ix_comments

return => return =>

-- 5,9 -

NAME__VOtD, EXP_VOID; sourceposition, comments; LOOP; - - Computed even when there is no name given in the source program.

EXP_VC~D; source position, comments;

G o ¢ o Sta'L-emexd:s

Syntax 5, S - - goto statement ::= go~o label_name; -

as_j~ame tx._.srcpos ~x_comments

goto => goto =>

ADA S e c t i o n

5, 6

: NAME; : sourceposttion, : comments;

Manual

Definition

-- 6 .

Diana

Section

Domain

2 /

Page

57

Subprograms

-- 6 . 1 -

o1 t h e

Subprcx/ram

Declarations

Syntax 6.1 .A subprogram._declaration : := subprogram specificetion;

-

SUBPROGRAM DEF : : =

void;

for procedure and function subprogram designator is one of 'proc id', - - 'function id', or 'def.._op' - - for entry subprogram designator is 'entry id' - - for renaming can be any of above or *enum id' see 3.7 in rationale subprogram_decl => subprogram_decl =>

as_designator : DESIGNATOR, ca._header : HEADER, as_~ubprogram_def : SUBPROGRAM DEF; Ix_~rcpos : sourceposition, Ix_comments : comments;

DEF_ID t :=

proc id;

proc id =>

Ix_srcpo~ Ix_¢omment~ tx_~ymrep

proc id =>

sm_spec

DEF IO : :=

function__id;

function id =>

Ix_~rcpo~ Ix c.ommenfs Ix~ymrep

furmtion id =>

,~m ,spec

~m_body ~m_location am_Mub ~m_fir~

am_body am_location ~m_~tub sin_firM DEF_OP : :=

def op;

def_op =>

tx_.~rcpo,s Ix comments Ix_=ymrep

def op =>

am spec ~m_body

amJocation am_~tub am_firM

LANGUAGE : := LOCATION : : = SUBP__BODY DESC : :=

-

-

: : : : : : : :

sourceposition, comments, symbot rep; HEADER, SUBP_BODY._DESC, LOCATION, DEF._OCCURRENCE, DEF_OCCURRENCE;

: : : : : : : :

sourceposition, comments, symbol_rep; HEADER, SUBP BODY DESC, LOCATION, DEF_OCCURRENCE, DEF ~ R R E N C E ;

: : : : : : : :

sour~_.poaition, comments, symbol rep; HEADER, SUBP BODY_DESC, LOCATION, DEF__OCCURRENCE, DEF OCCURRENCe;

argument_id; EXP VOID I pragma_id; block I stub I instantiation I FORMAL SUBPROG DEF t rename | LANGUAGE [ void;

'pragma id' and 'argument_id' only occur in the predefined environment

ADA S e c t i o n

5, 9

Page

58

/

Section

DIANA Reference

2

- - SyntaJ~ 6. t , B -subprogram.specification : := -procedure identifier [ f o r r ~ l p~rt] -m function designator [ f o r m a l p a r t ] return type_mark --

designator : : = identifier ~ operator symbol

--

operator symboi : ;= string_~iterat

HEADER : := HEADER : :=

procedure; ,%nction;

procedure => procedure :~

aa_param~ Ix_.arcpo¢ ~xcomment~

: PARAM S; : sourceposition, : comments;

fUnction =>

a~._param_,s a,s...name_void

function =>

tx~rcpo~ tx._¢omment~

: PARAM S, : NAMEVOID; void in case of tnstantiation : sourceposition, : comments;

-

ADA S e c t i o n

6. ] . A

-

Manua~

Definition

-----

o! the

Diana

Section

Domain

2

/

Page

59

Syntax 6 . 1 . C formal_part : : : (parameter specification [; parameter spocificetion}) parameter_specification : := identifier_list : mode type_mark [ : : mode

::= [In]

I in out I out

PARAM_S : :=

param s;

param s => psram s =>

as_list Ix_.srcpos Ix_commenfs

PARAM : :=

in;

in =>

a~._id_s

: Seq Of PARAM; : sourceposition, : comments;

aa name in =>

as_exp void Ix_srcpos Ix comments Ix_default

PARAM : : = PARAM : : =

in_out; out;

in .out =>

a,s._/d_s as_Rsme

in out = • out : >

: ; : : : :

as_id_s as_name

as_exp void Ix.srcpo8 Ix_comments

DEF ID : : =

in_id;

in_id =>

Ix~rcpos Ix_comments Ix._~ymrep am_obj_type

sm_inlt_exp am firM

1O S, - - always a sequence of 'in id' NAME, EXP_VOID; source Jx)sition, comments, Boolean;

ID_S, ~ always a sequence of 'in out id' NAME, EXP_VOID; - - always void sourceposition, comments;

as_exp._void Ix_srcpos Ix_comments

out : >

in id =>

expression]

: : : : :

ID_S, ~ always a sequence of 'out_ id' NAME, EXP_VOID; - - always void sourceposition, comments;

: : : : : :

source posit~oN, comments, symbol rep; TYPE._SPEC, EXP_VOID, DEF_OCCURRENCE;

DEF ID : : =

in out id

I

out_ld;

in out id =>

Ix_srcpos Ix_comments Ix_~ymrep

in out id =>

srn o b L i y p e

am_firm

: : : : :

sourceposition, comments, ~ymbol rep; WPE._SPEC, DEFOCCURRENCE;

Ix aropos Ix_comments Ix_symrep smobj_type sm firM

: : : : :

source position, ¢omment~, symbol rep; TYPE._SPEC, DEF OCCURRENCE;

out td :> out id =>

ADA S e c t i o n

6, I. B

Page

6.3

60

/ Section

~

2

DIANA R e f e r e n c e

]~cxlies

- - Syntax 6.3 subprogram body : := -subprogramspecification -[declarative p~rt] -begin sequence of statements -[exception exceptionhandler {exceptionhandter} ] -e , d [designator];

BLOCK STUB : :=

btock;

subprogram body =>

aa_designafor

subprogram body =>

as_header aa_block_ stub tx_arcpo~ ~x_commenf ~

AOA S e c t i o n

6. t , C

: DESIGNATOR. ~ one of 'proc id'. 'function id' or 'def op' HEADER. BLOCK STUB; sourceposition, comments;

: ; : :

Manual

Definition

of the

Diana

--

6.4

--

Syntax 6,4 procedure caU statement : := procedure_name [ actual _pa.rameter I>ert];

--

subpzog~

Domain

Section

2 /

Page

61

Ca~ls

function call ::=

func~on name [ a c t u a l p a r a m e t e r p o r t ] actual_porameter .part : := (porameter._assocmtion {, porameter aasociation}) parameterassociatlon [formalparameter

: := =>] actualparameter

formal parameter ::= parameferaimple.name actual_parameter : := expression I variable_name I typemark(variablename)

procedure cal| =2

as_name

procedure call =>

as._paramcs,soca : PARAM ASSOC._S; Ix_~rcpoa : sourceposition, Ix_comment8 : comments; am_normalized_pararns : EXP S;

procedure call => function call =>

as_name aa_param_asaoc8

functioncall =>

Ix .srcpos

function call =>

EXP | assoc;

aSSO¢ =>

as_designator a,s_actual Ix_srcpoa Ix_comments

=>

ACTUAL : : =

NAME, PARAM_ASSOC S; source position, comments; TYPE SPEC, value,

Ix_comments am_exp_type ~;m_value am_normalized_j)aram_a : EXP S, Ix.prefix : Boolean;

PARAM_.ASSOC : : =

aS$OC

: NAME,

: : : :

DESIGNATOR, ACTUAL; sourceposition, comments;

~xP;

ADA S e c t i o n

6.3

Page

62

-- 7 . -- 7 . 1

/

Section

DIANA R e f e r e n c e

2

Packages P

~

Structure

- - Syntax 7 . 1 . A package_dec|aration

package deci

:

:= package specification;

=>

package_decl =>

ac_id a.s_package_def }x,srcpo,s tx_comment=

DEF__ID : : =

pockage ld;

package._id =>

2x_~rcpo~ ~,x_¢omments ,~x_~ymrep

package_id =>

.~m_spec ~m body

~m_addre~ ~m_,stub cmfir~t PACK BODY_OESC : : =

block I stub

: : : :

ID, - - always 'package id' PACKAGE DEF; sourcepositlon, comments;

: : : : : : : :

sourceposition, comments, symbol_rep; PACKAGE SPEC, PACK_BODY. OESC, EXP_VOID, DEF_OCCURRENCE, DEF OCCURRENCE;

I rename

I {nstantiation

t void;

SyntAx 7 . 1 . 8 package._specification : : = package identifier is -{basic_declarative item } [ private -{basic d e c l a r a t i v e i t e m } ' l - -

-

-

--

end [package_simple.name]

PACKAGE_SPEC : := PACKAGE_DEF : :=

package spec; package spec;

package_spec =>

ss_decl_~1 a,s decl ,s2 tx_~rcpos

package., spec =>

I x _ comment s DECL. S : :=

DECL._S, - - visible declarations DECL S; - - private declarations source_posit~on, comments;

decLs;

d e c i s => d e c L s =>

ADA S e c t i o n

: : : :

as_lt~t lx_~rcpos

~x_cotrtmerd~

8.4

: ~ Of DEC,L; : ~ u r c e position, : comments;

Manuat

Definition

of the

Diana

Section

Domain

2 /

Page

63

- - Syntax 7,1 ,C - - package_body : :=

--

pacimge body package_simple

-----

[ declarativepert] [begin sequence of. statements [ exoept~n exception_handier {exceptionhandler}] ]

-

-

- -

--

end [package_simple name];

packagebody => package body =>

-- 7 . 4

- -

---

name h~

Private

Type

es._id a¢_block_.stub Ix_srcpos Ix...commenfs acid D e f e r r e d

: : : :

iO, - - always 'package id' BLOCK STUB; sourceposition, comments;

Constant

Declarations

Syntax 7 . 4 , A private_type_declaration : : = type identifier [discriminant part} is [mimited] Private;

TYPE SPEC : : = TYPE--SPEC : :=

private; I_private;

private =>

Ix_.,srcpos Ix_comments sm_di~criminanfs Ix._srcpos Ix_comments ~mdiscriminents

private => I_privste => I p r i v a t e =>

: : : : : :

source_position, comments; DSCRMT .VAR S; sourceposition, comments; DSCRMT VAR_S;

DEF_ID : :=

private type id I I_private type_id;

private type_id =>

Ix_srcpo~

/x_.comments Ix_~ymrep private type id =>

sm_type_spec

source_position, comments, symbol_rap; TYPE SPEC; Refers to the complete type specification of the private type, - - See 3 . 4 . 2 . 4 of rationale. - -

- -

I private type_id =>

Ix_srcpoa Ix_comments Ix_symrep

t private_type_id =>

~ m type_~pec

source position, comments, symbol rap; TYPE_SPEC; Refers to the complete type specification of the limited private type, See 3 , 4 . 2 , 4 of rationale. - - -

- -

---

Syntax 7 . 4 , B deferred constant_declaration : : = identifier list : actuated t y p e m a r k ; d e f e r r e d c o n s t a n t =>

es_/d..~ 8 S

deferred constant =>

n

a

~

Ix.._srcpos Ix_comments

ID.$, - - sequence of 'const. id' NAME; sourceposition, comments;

ADA S e c t i o n

7.1. S

Page

--

8.4

--

~ntax

--

84

/

Section

U~

8.4 useclause

use

2

DIANA R e f e r e n c e

Clauges : : = use package name {, peckage_narne};

= >

use =>

as lis~ Ix_srcpo~ lx__comments

Seq Ot~ NAME; sourceposition, comments;

--S.5~em~mingDeclazati~ --

Syntax 8 , 5 renemiP,g declaoration : : = identifier : t y p e m a r k | identifier : exception -~ package identifier -I subprogram Specification

--

--

r e n a m e s object_name; r e n a m e 8 exception_name;

reP,ames p a c k a g e n a m e ; renames aubprogram or entry name;

See Section 3, 7 of rationele for discussion of ren~,ming

OBJECT DEF : : = EXCEPTS'ON DEF : : = PACKAGE DEF : : = SUBPROGRAM DEF : ;=

rename; rename; rename; rename;

r e r ~ m e => r e n a m e =>

Be_name Ix.._srcpos ;xcommenfs

ADA Section 7.4, 8

: NAME; : source position, : comments;

Manual

Deflnilion

-- 9 . 1

of the

Task

Diana

Domain

specifications

and Task

Section

2

/

Page

65

Bodies

- - Syntax 9. t .A -task-.declaration : := task-.specification; --- -

- -

task_specification : := task [ t y p e ] identifier [is {entry d e c l a r a t i o n } {representation clause} end [ t a s k s t m p l e _ n a m e ] ]

see 3 . 3 for task type declaration TASK_DEF : : =

task_spec;

task_decl =>

as_id

task._decl =>

Ix_~rcpos Ix_comments

TYPE._SPEC : : =

task._spec;

task._spec => task._spec =>

as_decl_s Ix_srcpos Ix_comments

task-.spec =>

,vn_body

a~_task_def

am_address

=m_storege._aize BLOCK STUB VOID : : =

: : : :

ID, ~ s i w a y s s vsr id TASK DEF; source position, comments;

: : : :

DECL_S; sourceposition, comments; BLOCK_STUB_VOID, ~ Void only - - in the presence - - of separate compilation. - - See 3 . 5 . 5 of rationale. : EXP VOID, EXP--_VOID;

block I stub I void;

- - Syntcx 9 . 1 . B - - task body : : = ~ body Ie~k simpte naJme is -[dectarettve._psrt] begin seque rice of...,,;tatements

- -

- -

-

-

--

-

[excepti~

exception_hal~ller {exception_handler} ] end [ t a s k s i m p t e _ n a m e ] ;

task-body =>

as_/d

task body =>

a~_block._stub lx_srcpos Ix_.comments

DEFID

: :=

task-_body ld = > task-.body id =>

IO, - - always 'task._body id' BLOCK STUB; soume position, comments;

task._body id;

Ix_srcpos Ix_comments Ix_symrep .Sm_type_spec era_body am_first sm ~tub

: ; : : : : :

source position, comments, symboLrap; TYPE SPEC, BLOCK STUB_VOID, DEF. OCCURRENCE, DEFOCCURRENCE;

ADA S e c t i o n

8.5

Page

66

-- 9,5 ---

--

/

Section

Entrles,

2

Entry

DtANA R e f e r e n c e

Calls

and Accept

Syntax 9 . 5 . A entrydeclaration ::= entry identifier [ ( d i s c r e t e _ r a n g e ) ]

3tateme~rts

[formal_part];

- - entry uses subprogram deci, see ~5,1 HEADER : := entry; OSCRT_RANGE VOID : := DSCRT RANGE J void;

a.s._d~;crt_range~void : DSCRT RANGE_VOID, as_param_.s : PARAM_S; Ix_srcpos : sourceposition, tx_comment,s : comments;

entry :> entry =>

DEF_ID : : :

entry_id;

entry id =>

~x_srcp~s !x_¢emments Ix_mymrep ~m_~pec sm_addres¢

e n t w id =>

--

entry cell =>

- - 5"yntax 9 . 5 . C --, accept_statement : := -acmept entry simple_name [ ( e n t r y -sequence of_statements

--

part];

as_name : NAME, - - indexed when entry ol~ family as_paramaasoc_s : PARAM ASSOC S; 8x._srcpos : sourceposition, 2x._comment~ : comments; ~m_normalized_param_~ : EXP_S;

entry call : >

-

: comments, : symbol rap; : HEADER, : EXP VOID;

Syntax 9 . 5 , 8 entry ¢alLstatemen ~ : : : entryname [ actuaLparameter

e n t w call :>

-

: source position,

index)] [formal part] [do

end [ e n t r y s i m p l e n a m e ] ] ; e~ry

index : := expression

asname

accept =>

: : : : :

a,s_.param_s as ~tm_=

accept =>

-- 9~6

Del~y

tx_srcpoa ix_comments State.ants,

Duration

and

NAME, PARAM S, STM S; sourceposition, comments;

Time

- - Syntax 9 . 6 delay statement : : = d ~ a y simple expression;

ssexp tx_.ercpos 1x.._comments

delay => delay =>

AOA S e c t i o n

9. ~ , B

: EXP; : sourceposition, : comments;

Manual

Definition

-- 9 . 7

of the

Select

Diana

Section

Domain

2

/

Page

67

Statements

- - Syntax S.7 select statement : := ~elective wait -I "~.,onditionat_entry. call 1 "timed_entry ceil

- - see below

-- 9 . 7 . 1

Selective

1~aits

- - Syntax 9 . 7 . 1 . A - - s e l e c t i v e w a i t ::= --

select_alternative {or

-----

select alternative} [else sequence of_statements] end select;

as_sele~clause_s a~_stm_s Ix_srcpos Ix_commenfs

select => select =>

SELECT C L A U S E S : : = sek~ct_c'Tause_s => select clause._s =>

SELECTCLAUSES, STM._S; source_position, comments;

=elect ClaUses;

as.Ji~Ix_srcpos Ix._comments

: Seq Of SELECT_CLAUSE; : source position, : comments;

- - Syntax 9 . 7 . 1 . 8 - - selective alternative : := -[ w h e ~ condition = > ] selectivewait_alternative

--

selective wait alternative : := accept alternative I delay_alternative I terminate alternative accept_alternative : : = accept_statement [sequence of_statements]

--

delay alternative : : = d e l a y s t a t e m e n t

--

terminate_alternative : : = terminate;

SELECT_CLAUSE : := SELECTCLAUSE : :=

Imlect_ctause; pragma;

select clause =>

as_exp_vold

select__ctause

es_stm_s Ix_~rcpo~

=>

Ix_commenfs STM : :=

terminate;

terminate =>

Ix_srcpo~ Ix comment~

[sequence of statements]

pragma allowed where alternative allowed EXP_VOtD, S Y M . _ S ; - first stm is accept or delay source_position, comments;

: sourceposition, : comments;

ADA S e c t i o n

9.6

Page

--

68

/

Section

2

D|ANA R e f e r e n c e

Conditional Entry

9.7.2

Syntax 9.7.:~ conditional entry catl : := =.~tect entry call statement -~sequence .=el_statements] -el~ -sequence o~ statements -~ ~ t ; --

as,s~m_~1 s¢_~trn_s2 tx_.srcpos ix_comments

cond_entry => tonal_entry =>

: : : •

STM S . - - first stm is entry_cell STM_S; source position, comments;

: : : :

STM S , - - first stm is entry_r, all S ~ M _ S ; - - first stm is delay sourceposition, comments;

Syntax 9 . 7 , 3 timed entry c~,i! : := -select entry_ca~| statement -[sequence of statements] --

----

¢lr

--

de|ay_alternstive end ee~eck

a~s_Mm_sl

timed_entry =>

as_afro_s2

tx,_srcpo,s 8x_comment~

timed entry =>

--

9.10

Abort

Statements

Syntax 9 . 1 0 - - abort statement : : = abort task name {, task_name};

--

NAME S : : =

name ~,;

name $ => n a m e s =>

: Seq Of NAME; : sourceposition, : comments;

a,sname_s Ox_srcps8 tx_comments

: NAMES; : souros_positiofl, : comments;

~_ti,st

abort =>

abort =>

ADA S e c t i o n

tx_arcpos ix comments

9.7.

~.8

Manua|

Definition

-- i0. -- 1 0 . 1

of the

Program

Diana

Structure

Compilation

Section

Domain

Onits

and -

Compilation Library

2 /

Page

69

Zssues

Units

-- Syntax 10.1,A

--

compilation : : = {cornpiUstion_unit}

COMPILATION : :=

compilation;

compilation => compilation =>

a~,._liM lx srcpos Ix_comments

- - Syntax 10,1 ,B - - compilation_unit : : : -context clause l i b r a r y u n i t

: Seq Of COMP_UNR'; : sourceposition, ; comments;

I context_.clause secondaryunit

--

l i b r a r y u n i t : := subprogram _decls.ration t pockage_dedaration I generic_.declaration I generiLinstantiation I subprogram_body

--

s e c o n d a r y u n i t : := libraryunit_body

--

libraryunit_body::=

--

i subunit

subprogram body I package_body

COMP UNIT : : = UNIT BODY : : =

comp unit; package body I pockage._de¢l I subunit I generic I subprogram body | subprogram decl I void; - - UNIT_BODY is void only when ¢omp_unit consists of only pragmas PRAGMA._S ::=

pragma_s;

pragma, s => pragma s =>

as_ti~t

comp unit => comp unit => CONTEXT_ELEM : : : -- C o n t e x t

Clauses

Ix._~rcpos Ix_comments

: Seq Of PRAGMA; : source position, : comments;

as_context as_unit._body ae_pragmas Ix_srcpos Ix_comments

: CONTEXT, : UNITBODY, : PRAGMA S; ~ extension to FD. : source position, : comments;

pragma;

- - pragm8 allowed in clause

- With

clauses

- - Syntax 10,1.1.A -- context clause ::= {with clause {use clause}}

CONTEXT_ELEM : := CONTEXT : :=

use; context;

context => context =>

as_list Ix srcpos Ix_comments

: Seq Of CONTEXT ELEM; : source position, : comments;

ADA S e c t i o n

9. l 0

Page 70 / Section 2

DIANA Reference

- - Syntax 10, 1, ~.~ -w i t h _ c l a u s e : : = with u ~ i L s i m p l e

CONTEXT ELEM : :=

with;

with => w i t h =>

as_#sf ix_trcpo~ Ix_comments

-- i 0 . 2

Subunits

of

-

-

-

--

--

proper

body

as_name

subunit =>

as_subunit....body Ix arcpoa tx_comment8

SUBUNIT__~3DY : : =

subprogram

10.2,B body_stub : : = subprogram_specification

body

: : : :

NAME, SUBUNITJ~DDY; source_position, comments;

I package_body

I task body;

Syn~

is s~parate;

I paokage body package simple_name is separate; I task body task_simplename is separate;

--

-

Units

subunit =>

--

--

: Seq Of NAME; : sourceposition, : comments;

Coa~ilation

- - Syntax 1 0 . 2 . A -- sgbunit : := -separate (parent unit n a m e )

---

name {, unit. simple._name};

BLOCK STUB : :=

stub;

stub =>

#x._~rcpo6 ~x_comment¢

11.

Emoe~ions

11.z

E~ption

Syntax 11.1 exception_declaration

EXCEPTION._DEF

Declaratio.s ::=

: :=

exception =>

DEFjD exception

::=

Section

list : exception;

void;

~cept~n_

id =>

exception_id

identifier

aa_id_a aa_excepUon_def ?x.~rcpoa Ix_commenta

exception =>

ADA

: source_position. : comments;

Ix_~rcpo~

]0.

], ~,A

ID_$, - - 'axception EXCEPTION DEF; sourceposition, comments;

td;

Ix_comment~ Ix_aymrep am_exception_def

=>

: : : :

source

position,

©ommont.%, symbol rep; EXCEPTION_DEF;

td' sequence

Manual

Definition

-- 1 1 . 2

o f 1he D i a n a

Exception

Section

Domain

2 /

Page

71

itamcl].ers

- - Syntax 11.2 - - exception_handler ::= -when exception_choice { | exception choice} => sequence of_statements

- -

--

exception choica : : = exceptionname

i others

--- see 5,4, 5,6, 3 . 7 . 3 . 8 -- ii. 3

Raise

Statements

- - Syntax 1 t , 3 - - raise_statement : : = raise [exception_name];

aa_narnevoid Ix_srcpos Ix_comments

raise => raise =>

- -

- -

- -

- -

---

12. 12.1

Generic

Program

: NAMEVOID; : source_position, : comments;

uP-its

oeneric Declax~io~

Syntax 12,1.A genericdeclaration ::= generic_specification; genericspecification : := generi%.format_pert subprogram_specification I generic, formal_pert packagespecification

GENERIC_HEADER generic => generic =>

::::

procedure I function | package spec;

as_id a~_generic_param_a asgenericheader Ix._srcpo8 Ix_comments

DEF._ID : : =

generic_id;

g e n e r i q j d :>

Ix_ symrep : Ix_~rcpos Ix_commenta am_generic_param_a :

generic td =>

am_~pec

H_body ~m first am_~tub

ID, -- 'generic. id' GENERIC PARAM_$, GENERICHEADER; source position, comments;

symboLrep, seurce position, comments; GENERIC._PARAM S, GENERICHEADER, BLOCK STUB VOID, DEF OCCURRENCE, DEF' OCCURRENCE;

ADA

Section

11.1

Page

72

/

Section

- - Syntax 12. I . B - - generic formal j ~ r t

2

DIANA R e f e r e n c e

: : = generic { g e n e r i c p a r a m e t e r d e c t a r a t i o n }

GENERIC PARAM $ : : =

generic_param s;

generic_peram s => generic param s =>

as_li~ ix_srcpos Ix_comments

: 8eq Of GENERIC PARAM; : source_position, : comments;

- - Syntax 1Z.1.C - - generic parameter declaration ::= -identifier list : [ i n [ e u t ] ] t y p e m a r k [ : = expression]; -| type i d e ~ i f i e r is generic type definition; i- private type declaration I with subprogram specification [ i s name]; -I with subprogram_specification [ i s < > ] ;

GENERIC PARAM ::=

in ! in_out

SUBPROGRAM DEF : : =

FORMAL SUBPROG DEF;

FORMAL SUBPROG DEF : : = box => no default =>

fx_srcpos ix_commenfs ~xsrcpos Ix comment~

I type

I subprogram decl;

NAME m box t no default; : : : :

source position, comments; sourceposition, comments;

- - Syntax 12. t . 0 - - generic type definition ::= (<>) I n m g e <> t ~ <> J delta <> -~ array_type definition | access_type_definition

--

FORMAL TYPE SPEC; TYPE SPEC : := - - (<>~ FORMAL TYPE_SPEC : : = formal dscrt range < > I formal integer delta <> ! formal._fixed - - d i g i t s <> t formaLftoat; formal, dscrt = > formal. Hxed =~ format Noat => formal integer =>

ADA S e c t i o n

~2. t , A

ix srcpos tx_commenf s ix_srcpos Ix_¢ommenfs ~x_.srepo~ tx~comments ix_ srepos Ix comments

: : : : : : : :

sourceposition, comments; source position, comments; sourceposition, comments; source position, comments;

Manual

Definition

-- 1 2 . 3

---

--------

of the

Generic

Diana

Domain

Section

2

/

Page

73

In~tantiation

Syntax 12.3.A generic instantiation ::= package identifier Is

~ gener(c_package_name [ g e n e r i c _ a c t u a l p a r t ] ; ] procedure identifier is new generic._procedurename [ g e n e r i c a c t u a l p a r t ] ; t function identifier is new generdicluncfionname [generic._actualpart]; generio actual_part : : = (generic association {, generic association}) - - See 3 , 6 of rationale for discussion of instarKiation SUBPROGRAM_DEF : :=

instantiation;

PACKAGE DEF : :=

instantiation;

GENERIC ASSOC S ::=

generic asso¢.._s;

generic_assoc s => generio_assoc s =>

aa_fi,st lx._arcpo,s lx_commenf~

: Seq Of GENERIC_ASSOC; : source_positlon, : comments;

instantietion =>

a~_narne as_generic_assoc_s Ix_ercpo8 Ix_commenf~ sm_decl_~

: : : : :

instantiation => instentiation =>

NAME, GENERICASSOC_S; sourceposition, comments; DECL._S;

- - Syntax 1 2 . 3 , B generic association : : = [ g e n e r i c _ f o r m a l p a r a m e t e r = > ] generio actual_parameter -

-

--

generic f o r m a l _ . p a r ~ e t e r

GENERIC ASSOC : : =

- - Syntax 12,3.C -- genericactualparameter

--

t ~ubprogrem._nanle

GENERIC ASSOC : :=

: : = paramefer_simple_r~me

I operator_symbo!

assoc;

: : = expression

I entryname

I variablename I type_mark

ACTUAL;

ADA S e c t i o n

12,1,D

Page

74

-- 1 3 . -

-

l

Section

2

l~sentati~

IRp1ementation

-- 1 3 . 1

D~ANA R e f e r e n c e

Clauses Dependent

Representation

Clauses

--Syntax 13.1 -representation ctause ::= -type_representation clause

--

a.~

Features

~ addres%_clause

type representation_clause : := length clause I enumeration_representation clause I record representation clause

REP ::=

simple rep

~ -~ ~

address record rep; -- 1 3 . 2 -- 1 3 . 3

Length Clause Enumeration RepEesentation

Syntax 13.2 -- lengthclause

length clause and enumeration representation_clause {13.2) address clause (13.5) record ~'epresentatton clause (13.4)

clauses

--

: : = for attribute use simple expression;

- - Syntax 13.3 enumeration_representation clause ; := -for type simpte name use aggregate; -

-

s~_name a~_exp ~x_srcpos 9x_cemments

simple rep => simple rep =>

-- 13. %

Record

Representation

: : : :

NAME, EXP; source_position, comments;

Clauses

- - Syntax 1 3 . 4 . A - - record representation clause ::= -

-

--

----

Ior type_simplename use record [alignment_clause] {component clause} end recerd; alignment_clause : : = at rood ~at/c simp4e expression;

ALIGNMENT : : =

alignment;

alignment =>

as_pragma~ ae_exp void

; PRAGMA S, - - pragrna allowed in clause : EXP VO4D;

~8_nerne

:

NAME,

aa_etignmenl a~_comp_.rep_a ~x_arcpos ~x_comment s

: : : :

ALIGNMENT, COMP_REP S; source position, comments;

record_rep => record rep =>

ADA S e c t i o n

12.3. C

Manual

Definition

--

--

of the

Diana

Section 2 / Page 75

Domain

Syntax 1 3 . 4 . B component._clause : :=

component_simplename at staticsimple_expression ronge static range;

COMP REP $ : : = COMP__REP : := COMP REP : :=

comp_rep s; comp_rep; pragma;

~

comp rep s => comp rap s =>

cs_list Ix_srcpos Ix_commenit;

: Seq Of COMP REP; source, position, : comment~;;

¢omp rep =>

as_name

: : : : :

compjep

-- 1 3 . 5

as_exp esJenge ix._srcpos Ix_comments

=>

]~h, ess

pragma allowed in clause

NAME, EXP, RANGE; sourco pos|tion, comments;

Clauses

- - Syntax 13.5 -address clause : : = for simple_name use at simple expression;

address =>

as_name

address =>

as_exp Ix_srcpos Ix_comment,s

-- 13.8

Machine

Cod~

: : : :

NAME, EXP; source position, comments;

Insertions

- - Syntax 13.8

--

code_statement : := type_mark°record aggregate;

code => =>

as_name

ae_exp Ix~rcpos Ix._comments

: : : :

NAME, EXP; source posRion, comments;

14.o zn~t-o~l~ - - I / 0 procedure calls are not specially handled. They are - - represented by procedure or function calls (see 6 . 4 ) .

Page

--

76

/

Section

~.def~ed

Diana

2

DIANA R e f e r e n c e

L=~v~rocment

- - see Appendix ~ Of this manual DEF ID : := ARGUMENT : :=

attr id I pragma_~d I ARGUMENT; argu'ment id;

attr id =>

tx,_symrep

TYPE SPEC ; : =

universal integer I universe| fixed i universal_real;

: syrnbot rep;

universal integer => universal fixed => universal real => argument id =>

Ix_~ymrep

: symbol rep;

pragma id => pragma id =>

a~li~t tx_symrep

: Secl Of ARGUMENT; : symbol rep;

End

ADA S e c t i o n

]3.8

Manua{

Definition of the

Diana Domain

Section

Structure Diana Concrete Refines Diana I~-

Refined Diana Specification

Version of 11 February 1963

For sourceposition For symbol rep For value

For operator For number rep For comments

Use USERPK,SOURCE POS1TION; - - defines source position in original - - source program, used for error messages, Use USERPK.SYMBOL REP; - - representation of identifiers, strings and characters Use USERPK.MACHINEVALUE; - - implementation defined - - gives value of an expression. can indicate that no value is computed. Use USERPK.OPERATOR; - - enumeration type for all operators Use USERPK.NUMBER REP; - - representation of numeric literals Use USERPK.COMMENTS; representation of comments from source program

This defines the external representations M

For symbol rep For numberrep For operator For value

Use External String; - - the external representation of symbol rep uses IDL basic type string. Use External String; the external representation of number rep uses IDL basic type string. Use External OP_CLAS$; - - the external representation of operator uses the private type OP_CLASS Use External VAL. CLASS; - - the external representation of values - - uses the private type VAL. CLASS

2 /

Page

77

Page

78

/

Section

OP C L A S S ---

2

DIANA

is e n e n u m e r a t i o n

Syntax 4.5 logical operator

--

relational

--

adding._operator

::=

operator

:;= ::=

=

I

~ I

unary

multip~ying._operator

::=

--

htghest._precedence

operator

: :=

unary_plus =>

--

VAL._CLASS

VAL_CLASS

: :=

I

<=

t

~

>

I

>=

I *

|

/

I

::=

m¢
I

rein

| eb~

I

not

-- and --or -- xor

ne lit I le I gt ge I plus I minus ~cat unary_plus unaryminus n abs t not t mutt

-- /= --< --<= --> - - >= -- + ----& ~ + ---- abs -- not -- *

I rood I ram exp;

~ ~ ~

o r => ; ~t=> ; p l u s => ; unaP~ m i n u s => dh~ => ;

is a ctass t h a t d e f i n e s

n o . _ v a l u e => s t r i n g _ v a l u e => bool v a l u e => int ~ l u e :> r~. v a l u e => End

~ <

I &

and I or t xor

a n d => ; he=> ; g e => ;

m u t t => ; e x p => ;

*

t h e Ada o p e r a t o r s

I ]mr 1=

-

--

CLASS

::=

I or

--

OP

operator

and

class t h a t d e f i n e s

Reference

no value int. v a l u e s t r vag b o o val int.~al ~tn. val

rood ram **

x o r => ; le=> ; m i n u s => ; ; a b s => ; rood => ;

the possible

e q => ; g t => ; c a t => ; n o t => ; r e i n => ;

Diana values

t stringvalue ~ real. value; -: : : :

| bool_value

1

no v a l u e h a s b e e n c o m p u t e d S t r i n g ; - - c h a r a c t e r and s t r i n g Boolean; -- boolean value Integer; -- integer value Rational; ~ real and f i x e d v a l u e s

Manual

Rationale

Page 79

CHAPTER 3 RATIONALE

The design of DIANA iS based on the principles listed in Section 1.1.

Unfor-

tunately these principles are not always compatible with each other and with ADA. Under

some circumstances

minor ways,

It was necessary to deviate from

them.

albeit in

The main purpose of this chapter is to clarify the DIANA approach

and to give reasons for our compromise decisions. An important principle tn the design of DIANA was to adhere to the Formal Definition of ADA (AFD).

and In particular, to the abstract syntax defined there,

The first section below compares DIANA trees with those of the Abstract Syntax and shows the transformations from the DIANA form AFD.

The

DIANA.

second

The third

section section

dictionary or symbol table, of the

describes

discusses the

back to that given In the of separate compilation on

DIANA approach to the

notion

of

a

In the fourth section we discuss an important Output

semantic analyzer--the type

information about objects,

special situations and solutions which given in the last chapter.

the effects

We

point out

may not be obvious from the definition

The fifth section discusses a n o t h e r principle that it

was not possible to apply consistently--the requirement that there be a single definition

for

each

compilation facility.

entity,

Here

the

language,

Impose a compromise on

and

DIANA.

especially

its

The sixth and

sections discuss the special problems of Instantiatlons and renaming.

separate seventh

The eighth

section deals with implementation dependent attribute types that are introduced in DIANA in

order

to

avoid

constraining

an

Implementation.

The

discusses the notions of equality and assignment for attributes.

ninth

section

A summary of

the non-structural attributes closes the chapter. This

chapter contains

a number of examples where the structure

of DIANA

trees is given In a g r a p h i c a l manner to illustrate the relations between attribute values and nodes. of the

To emphasize the important points, we show only those parts

structure which

are of interest for the

particular example.

Thus.

a

subtree is sometimes replaced by the string which It represents or by ellipses if It is not important.

If attributes are attached to a node.

node and the attributes of Interest are enclosed In a box.

then the kind of the It Is our intention

that these figures capture only the essential information for the purpose at hand and hence suppress unnecessary detail; they should not be viewed as complete,

Page 80 / Section 3 . ]

DIANA Reference Manual

S. 1. C o m p a r i s o n with the Abstract Syntax Tree In this section we show that the Abstract Syntax Trees used ~n the AFD [6] and the DIANA trees (with only structural attributes)

are equivalent.

This e q u i v -

a l e n c e is usefut for the description of the semantics of a DIANA tree; Inherit the semantics from the AFD.

Further,

abstract syntax r e p r e s e n t a t i o n of p r o g r a m s . deviate from the AFD in m i n o r ways, reasons

why

they

are

necessary;

we simply

It enforces standardization of the

Since,

however, it was necessary to

we list these deviations and point out the

we

also

Indicate

how

the

Abstract

Syntax

Tree can be reconstructed from the DIANA tree. We r e c o g n i z e that the ADA AFD is based on the 1980 revised ADA Language Reference Manual [7] and does not reflect c h a n g e s 1982 r e f e r e n c e manual.

3.1.1.

Semantic Distinctions of Constructs

Several nodes AFD.

in

DIANA have no

c o u n t e r p a r t In the Abstract Syntax of the

They are introduced in cases w h e r e a single construct in the AFD may

have several

distinct

a p p r o p r i a t e semantic original

construct

largest

number

distinguish tifier,

made to the syntax in the

This issue ts addressed in Section 3 . 1 . 5 .

semantic

meanings.

is extended with of

Different

attributes to each. spltts

has

between a defining

prefixes which

been

made

occurrence

nodes

In all such for

allow us to attach

cases the

name

of the

denote the distinction.

the

Id-construct;

and s used o c c u r r e n c e

but also between the kinds of the items denoted by It.

we

not

The only

of an i d e n -

For example,

const_ld

ts a node which can a p p e a r in a constant declaration to define a constant object. If such an object is referenced by an identifier in an expression, the construct

used_objecLid

is used, The semantic attributes of both constructs can be found in the DIANA definition,

Note that the attributes of these two types of

'_ld'

nodes are disjoint and that

their union contains all the information needed. The ortgtnat Abstract Syntax Tree can easily be reconstructed by omitting the prefix

of

necessary,

these

nodes,

tt

should

be

noted

that

no

tree

transformation

is

s i n c e the structure of the new DIANA nodes Is the same as that of

their c o u n t e r p a r t s In the Abstract Syntax.

Rationale

3.1.2.

Section 3, 1 , 2 / Page 81

Additional Concepts

There a r e nodes Introduced in DIANA which are used to deal with issues that are

not c o n s i d e r e d

parentheses

In

In

the

AFD,

expressions.

They are

If the

nodes

used for

to

represent

parentheses

pragmas

and

pragmas

are

and

removed from the tree, the original Abstract Syntax structure is restored. Under s o m e circumstances parentheses have a semantic effect In ADA,

Con-

sider the following examples: F((A)) A + (B + C) ( A + B) * C

-- Parameter cannot be in or in out - - P a r e n t h e s e s force t h e g r o u p i n g - - P a r e n t h e s e s force the p r o p e r p a r s e

In each of these cases the parentheses have a semantic effect. ADA c o n f o r m a n c e parentheses match,

be

rules

(see

preserved

DIANA requires

Section

In

6.3.1

order

that

all

to

of the ADA LRM [8])

check

parentheses

that in

may

carry

the

commands

given

require

subprogram

the

preserved t h r o u g h the use of parenthesized nodes, Pragmas

In addition, the

original

AOA s o u r c e

by the

user

modules after sema~'ltlc analysis and must be preserved. DIANA classes

were

expanded

to

allow

are

See Section 1 , 1 . 3 . to Since

other

compiler

pragmas

o c c u r in so m a n y places in ADA ( s e e Section 2 . 8 of the ADA LRM [ 8 ] ) , structure of the abstract syntax tree,

that

specifications

pragmas.

This

does

not

may many

affect

the

However. the presence of p r a g m a s also

caused us to c h a n g e the structure of the c o m p _ u n i t node of the abstract syntax. Pragmas

can

be

given for

together

with

the

corresponding

a

compilation node.

unit The

and

are

comp_unlt

therefore node

represented

now

has

throe

children: ¢omp unit =>

From

the

selector,

3.1.3,

context unit_body pragma._a

abstract

: CONTEXT, : UNIT_BODY, : PRAGMA $ ;

datatype viewpoint.

DIANA has

merely added

one

additional

The original selectors of the AFD are retained unchanged,

Tree Normalizations

The AFD uses various normalizations of the tree. are also Imposed by DIANA. because after such

Most,

but not all.

of them

Those which are not performed in DIANA were elided

normalizations it is difficult,

and sometimes

impossible,

to

r e c o n s t r u c t the source text. We

do

not

follow

the

AFD

tn

normalizing

anonymous

types,

The

AFD proposes that all anonymous types be replaced by type marks and have an

Page 82 / Section 3, !, 3

DIANA F~eference Manual

explicit d e c l a r a t i o n |ust before their original a p p e a r a n c e .

This tree transformation

is not required by DIANA.

For example, the declaration of a task object does not

require a d e c l a r a t i o n of an anonymous task type to be placed in the DIANA tree before the task object. We do not normalize p a r a m e t e r associations,

In the AFD,

all s u b p r o g r a m form.

calls have their p a r a m e t e r sequences normalized to the n a m e d a s s o c i a t i o n

as the user wrote them and avoids filling

DIANA leaves positional p a r a m e t e r s default p a r a m e t e r s .

in

(DIANA does have a semantic attribute for s u b p r o g r a m calls

that normalizes p a r a m e t e r sequences and fills in default parameters,

but s e m a n t i c

attributes a r e not represented in the Abstract Syntax T r e e ) . All

other

function

normalizations

calls)

are

~n the

AFD

(e.g,,

imposed by DIANA,

The

treating

built-in

operators

as

impact of these normalizations on

reconstruct{on of the original source p r o g r a m from the DIANA tree is discussed in Appendix Ill,

The normalizations which are not assumed by DIANA must be d o n e

to get the Abstract Syntax Tree; the AFD defines how these are done,

3. 1.4.

Tree Transformation According to the Formal Oefinition

Some ambiguities of the concrete syntax cannot be resolved by the parser, but

must

be

removed

during

semantic

Syntax contains an appiy construct, sions,

and slices,

analysis,

Appendix

of this II),

it

example,

the

Abstract

calls,

conver-

in most cases semantic analysis merely has to r e n a m e the

node to e n c o d e the nature of the construct; The result

For

covering indexed expressions,

process should

is assumed be

noted

there are no structural differences.

In DIANA aS well as

that

one

possibility

In the

requires

AFD a

(See

structural

transformation of the tree, namely when an apply node has to be changed Into a call to a p a r a m e t e r t e s s entry family m e m b e r . Ati these c h a n g e s

ere

Figure 8-1

illustrates this case.

!n a c c o r d a n c e with the AFD and require

no actions to

r e c o n s t r u c t the Abstract Syntax Tree.

3.1,5.

Changes to the AST

The majority of the changes in ADA syntax have not produced a c h a n g e In the structure of the Abstract Syntax Tree.

For example,

the c h a n g e In syntax that

requires the result subtype of a function to be specified by a type mark instead of a subtype

indication

has a~lowed DIANA tO use a NAME

function instead of a CONSTRAINED node. the

sense

that

the

number

of

children

as a child

of the

This does not affect the structure In that

the

function

node

has

has

not

Section 3 . 1 . 5 / Page 83

Rationale

apply

/

entry call

.,/\

\

used name_id

...

general_assoc s

I

int._numbe r

indexed

/\

used_name_id

parzm_assoc_s

exp_s

I

Int_numbee Figure 3-'1:

changed,

Example of a Necessary Tree Transformation

One node has been changed structurally, the allocator node.

has been changed to have only one child,

as exp_constralned,

which

Instead of the

two children specified in the Abstract Syntax Tree defined In the AFD, Two DIANA nodes have been Introduced to consistently represent the changes to AOA syntax.

The dtscrlmtnant specification requires a type mark instead of a

subtype indication. dlscrlmlnant node.

'The Abstract Syntax Tree uses a var node to represent both

specifications

dscrmLvar,

and variable declarations.

DIANA uses a separate

~o represent the dlscrlmlnant specification.

Similarly.

a

deferred constant declaration differs from a full constant declaration in that it requires a type mark instead of a subtype indication, constant node

in

the Abstract

Syntax Tree.

Both are represented by a

DIANA represents the

deferred

constant declaration with the deferred constant node.

8 . 2 . Consequences of Separate Compilation The separate compilation facility of AOA affects the intermediate representation of programs.

"ihe Front End must be able to use the Intermediate represen-

tation of a previously compiled unit again,

Further, the Front End may not have

complete information about a program unit. The

design

of

DIANA carefully

avoids

constraints

on

a

separate

compilation system, aside from those Imptled directly by the ADA language.

The

Page 84, / Section 3 . 2

design can

be extended to cover the full APSE requirements.

specification,

possible, The

that

simultaneous

compilation

within

the

same

project

is

and that units of o t h e r libraries can be used effectively [5]. basic

decision

forward r e f e r e n c e s ; out

We have taken

that several versions of a unit body can exist c o r r e s p o n d i n g to a

special c a r e single

DIANA Reference Manual

some

which

these facilities

makes

tmptementabie is

this decision is explained in the next SeCtion.

limitations

imposed

on

the

Front

End

by

to forbid

We then point the

separate

c o m p i l a t i o n facility.

3.2.1.

Forward References

The basic

principle of DIANA that there is a single definition point for each

AOA entity conflicts with those ADA facilities that have m o r e than one d e c l a r a t i o n point.

In these cases,

DIANA restricts

occurrences

to be identical

compilation,

the

(see

requirement

that

the attribute values of all the defining

Section 3 . 5 ) . the

in the p r e s e n c e of s e p a r a t e

values of

the

attributes

o c c u r r e n c e s are the s a m e can only be met temporarily. (sm_body)

assumed

by OIANA are void in these cases.

at

all

defining

The forward references The reasons for this

a p p r o a c h are: o A unit can be used even when the corresponding body is not yet compiled, in this case, the forward reference must have the value void since the entity does not exist. o Updating a DIANA representation would require write access to a file which may cause synchronization problems ( s e e [5]), o A library system may allow for several versions of bodies for the same specification, if we w e r e to update an attribute, we would overwrite ~ts previous value. M o r e o v e r , we believe that the m a i n t e n a n c e of different versions shouid be part of the tlbrary system and should not influence the ~ntermedlate representation,

3.2.2. The

Separately Compiled Generic Bodies AOA separate

compilations, complied,

it

is

compilation possible

provided that

to

facility

does

use

unit

a

its specification

does n o t n o r m a l l y cause a problem,

has

not

impose

a

whose

body

has

been compiled.

total not This

order yet

on

boen

procedure

since the specification usually contains all

the information needed to use a unit. However, a generic unlt can be Instantlated regardless of whether the generic

Rationale

Section 3 , 2 , 2 / Page 85

body has been compiled,

Thus,

in many cases the Front End cannot instantlate

the body at the time it compiles" an tnstanttatton.

It would be possible to keep

track of the Instantlations and compile them once the body becomes available, But this method wouk:l imply that already-stored intermediate representations have to be modified,

After such an update,

existing references to the updated unit

might be Invalid, DIANA assumes that only the specification Is Instantlated (see Section 3 , 6 for how this is d o n e ) ,

This assumption is safe, since the specification must already

have been analyzed, the

Back

analyzed,

End

The task of tnstantiating the body is left to the Back End;

cannot

be

run

until

the

body of

the

generic

unit

has

been

This procedure has the advantage of allowing the Back End to decide

whether to use common code for several Instantiatlons of the same generic .unit,

N a m e Binding

3.3.

Each entity of an ADA'program is introduced by a declaration with a defining occurrence of the name of that entity, this defining occurrence,

Uses of the entity always refer back to

Attributes at the definition point make it possible for

all Information about the entity to be determined,

The defining nodes for entities

together with their attributes play the same role as a dictionary or symbol table In a conventional compiler strategy. ces

of

an

Identifier

in the

tree

To support the DIANA approach, the a p p e a r a n have to

be divided

into

defining

and

used

occurrences (see Section 3, 1, "t),

3,3.1,

Defining Occurrences of Identifiers

All declarative nodes (see DECL, Section 2 , 3 , 1 )

have a child which consists

of a sequence of one or more nodes representing the Identifiers used to name the newly defined entitles,

These nodes are termed the defining occurrence of

their

they

respective

associated entity,

Identifiers;

carry

all

the

information

Because the set of attributes which

that

describes

the

is necessary for this

purpose depends heavily on the nature of the denoted entity, we distinguish the defining identifiers according to the nature of the entity which they denote, we have the following set of node types:

Thus

Page 86 / S e c t i o n 3 . 3 , "t

OEP'JO : ; =

DIANA Reference Manual

~rgumenL~d ~ttr id l ¢omp td ! const icl I ~6crmLid I entry id I enum id I exception._id funetion._id I genertL~ I m_ld I m._ouLtd I ~teration_id ! ~abe! Id I Lpriv'ats_type_id I flamed stm_id I ,,~umber_id I out id I ~¢'-kage_~ 1 pr=gmLid I private type_kl I pro¢ ld l subtype_id I t==sk body ld i ~ype id 1 vat id;

The defining occurrence of an e n u m e r a t i o n c h a r a c t e r operator (DEF_OP) The

consistency names

(argumenLid).

of

the whole

scheme

(attr_id).

and

the

requires

that we

provide a definition

T h e s e a r e p r a g m a names (pragma__td), names

of

the

arguments

of

pragmas

The p r e d e f l n e d identifiers a r e d e s c r i b e d in A p p e n d i x I.

it shoutd be noted that although ~abel n a m e s , in ADA are Impttcffty declared

loop n a m e s ,

and block n a m e s

at the end of the c o r r e s p o n d i n g

they a r e not e x p l i c i t l y r e p r e s e n t e d In DIANA. (labeLid)

and of an

fa!l into the class of defining o c c u r r e n c e s as well.

point for p r e d e f t n e d Identifiers as well. attribute

(DEF CHAR)

declarative part.

The d e f i n i n g o c c u r r e n c e

is its a p p e a r a n c e in a l a b e l e d statement,

of a label

The defining o c c u r r e n c e of

a n a m e d _ s t m _ t d is its a p p e a r a n c e In a named s t a t e m e n t .

3.3.2,

Used O c c u r r e n c e s

All occurrences

of identifiers

of identifiers

treated as used occurrences. an attribute occurrence

(sm_defn of

that

which

are not m e n t i o n e d

o r sin_operator)

identifier

in Section 3 . 3 . 1

are

The node for a used o c c u r r e n c e of an entity has

(where

that refers ell

to the n o d e for the defining

information

is

stored),

DIANA d i s t i n -

g u i s h e s between t h r e e different kinds of usage d e p e n d i n g on the context in which the entity is r e f e r e n c e d . USEDJD ::=

used name Id I USed object Id I

Section 3 . 3 . 2

Rationale

A u s e d _ o b j e c t J d Is used when the sm_defn denotes an object, tion

literal,

or

a

number.

In

represented by a used_name_id,

all

other

contexts,

the

use

/ Page 87

an e n u m e r a -

of

an

entity

the entity.

Additionally we have a used_char (treated as a used_object_ld)

a

(treated

used_op

is

whose only attribute refers to the definition of

as a u s e d _ n a m e _ i d ) ,

identifiers

for

built-in

and

entities are

discussed in Section 3 . 3 . 4 .

3.3.3.

Multiple Defining Occurrences of identifiers

Recall that o n e of the basic principles of the DIANA design stated that every entity has a single defining o c c u r r e n c e .

(e.g..

i n c o m p l e t e types,

principle.

deferred c o n s t a n t s ) .

DIANA c a n n o t strictly follow this

In the Instances where multiple defining o c c u r r e n c e s can o c c u r .

uses the following solution. multiply defined 8.3.1.

As this is not the case in ADA Itself

are

However.

represented

these defining

by a DEF_ID occurrences

as

described

have an

above In Section

sin_first,

attribute,

refers to the node for the first defining o c c u r r e n c e of the identifier, the sm_defn

attribute of used o c c u r r e n c e s

several defining

DIANA

All defining o c c u r r e n c e s of an entity that could be

occurrences

(Section 3 . 3 . 2 ) .

Nonetheless.

of the entity all have the same

that

similar to the

attribute values.

The c o m p l e t e details of how DIANA treats multiply defined identifiers are described in Section 3 . 5 .

3.3.4.

S u b p r o g r a m Calls

In ADA it IS possible to write built-in operators as function calls and to write u s e r - d e f i n e d operators as operators.

For example.

st:aundazd."+"(x => Z, y' => 2 ) In DIANA all function calls and operators are represented as function calls. only exceptions to this method are the s h o r t - c i r c u i t else and the membership operators In and not In. c a n n o t be represented as functions,

The

operators and then and or which cannot be o v e r l o a d e d .

and cannot be written as function calls.

DtANA records whether a function call was m a d e using infix or prefix notation through

the Ix_prefix attribute.

This

Information

specification c o n f o r m a n c e rules (Section 6 . 3 . 1 The

klnd

of

functlon call node. may

be

a

functlon which

USED_ID

DESIGNATOR_CHAR

or

child

call

is

Is necessary for

indicated

by

the

first

child

represents the name of the function. USED_OP,

or

Is a USED ID or

subprogram

of the AOA LRM [8]).

a

selected

USED_OP.

the

This attribute

component Thls

of

where

the

used o c c u r r e n c e

Page 88 / Sectior~ 3 . 3 , 4 distinguishes

butit-~n

DIANA Reference Manual

operators

(or

even

procedures and

entries)

from

user-

defined subprograms, in

a

uaed_op

or

used_name_ld

occurrence

defining

of

the

node,

user-defined

the ~m_defn entity,

attribute

in

a

denotes

used_bltn_op

the (or

the sin_operator attribute indicates the built-in entity; this attribute

used_bltnjd),

}s a private type and is implementation-defined. It represents numeric operators such

as

"+"

and

"*"

but also

represents the

implicitly-defined

relations for

user-defined types. Derived subprograms are indicated by the original definition from which they are derived. sufficient

to

The actual parameters all have type information attached. compare the ,actual types to the

original

ones to

It is

determine the

implicit type conversion necessary for parameter association if the representation changes.

Since

sm_exp_type of an

type actual

checking

has

parameter

is not equal to the sm_ob/_type

already

been

performed,

corresponding formal (in the sense described in Section 3 . 9 ) ,

If

the

of the

it must be the

case that the actual parameter is of a type ultimately derived from that of the formal.

Following the chain of derivations starting with the type of the actual

parameter will give the sequence of type conversions which must be performed. Similarly for a derived function,

the result type of the function_call node can be

compared with the result type of the funotion_ld. if a user defines an equality operator for a limited private type, equality is introduced Implicitly.

sm_detn attribute of a used_op node. defining

occurrence.

The tree

then

in-

The user-defined equality is identified by the in the case of Inequality,

is therefore transformed to

operation apptled to the user-defined

equality.

there is no

a standard

"not"

Thts situation is illustrated in

Figure S-2. The order;

parameter associations for

a subprogram call

are

in the

user-written

it is therefore possible to reconstruct the source program In most cases.

tt would be awkward ~o Introduce named associations In the case of predeflned operators.

{t would be impossible for implicit ones such as equality, since there

is no defining occurrence of the formal parameters. Therefore, normalize parameter associations to named associations. use the sm_.normaltzed_parsm__s attribute

DIANA does

attribute to record the normalized positional list

of actuals used in the subprogram call, (The

DIANA does not

However,

sm_normelized_comp_s

aggregates and dlserlminant constraints).

including any default actual parameters. serves

a

similar

purpose

for

record

Section 3,4 / Page 89

Rationale

function_call

us(~d_bl tn_op

param_assoc_s

sm o p e r a t o r = op_not functionj a i l

,,/\ used_op

param assoc_s

smdsfn

/

~

"X"

Figure 3-2:

"Y"

Call of Implicitly-Defined Inequality

8, 4. Treatment of Types Since anonymous types do not have an explicit declaration In DIANA (see 3.1.3),

we cannot use the type identifier as the description of

Instead we use the type specification (TYPE_SPEC).

the type.

In all contexts where

structural type information is required, the attributes have values which denote a TYPE_SPEC,

e.g.,

sm_exp_type

Ir~

expressions

and

sm_.base_type

in

constrained nodes. This treatment implies that all nodes which can represent a type specification must carry those attributes which describe the detailed type. The meaning of these attributes is explained In the following sections. it should be noted that most of the attributes described in these sections can be computed from other attributes which are also present In DIANA. reason for adding them is that it makes code generation easier.

The main

The attributes

represent information which the Front End already has and which would be difficult for the code generator to recompute (especially in the presence of separate compilation).

DIANA Reference Manual

Page g0 / Section 3,4~1

3,4. t.

Machine Dependent Attributes

DIANA origtnatty required machine dependent attributes to be computed because their values were a}towed in AOA static expressions and therefore could appear In type declarations. LRM [8])

The

rules for static expressions (Section

4.9

of the ADA

now only a~low attributes of static subtypes in static expressions;

at-

tributes whose values are no longer machine dependent.

3.4.2.

Type Specifications

There are several ways to specify a type in ADA,

Fortunately they all have

different syntactic structures so that we are not forced to introduce new node types to carry the different semantic attributes appropriate to each type (as was done for identifiers, see 3, 1 . 1 ) ,

The following sections give a detailed d e s c r i p -

tion of the attributes for each

kind of type specification.

involve the notion of structural

type information;

These doscrlptlons

this notion is defined In the

following section. 3 . 4 . 2 , 1. Structural Type ~nformatlon The structural information for a type is expressed by the following nodes of a DIANA Tree: for for for for for for

integer, fixed, float enu~=literal_8 ~ord array access

task_epec

and the universal types

numeric types enumeration types record types array types access types task types

(see Appendix t),

Each of these

has attributes for

values of user defined or ~mptementatlon chosen attributes, There are tanguage pragmas (PACK,

CONTROLLED) which can be applied to

types and which are used instead of a representation specification.

Occurrences

of these pragmas remain in the DIANA Tree to reconstruct the source,

are

additionally

recorded

with

the

type

structures

they

affect

but they

using

the

sin_packing and sin_controlled attributes. For record types,

there may be representation specifications for the record

and its components (including discrlmlnants), is

recorded

in

dscrmLid nodes.

semantic

attributes

of

A reference to this specification the

Similarly for enumeration types,

record_id,

comp_id,

and

information from r e p r e s e n -

tation specifications for the enumeration llterats is recorded with the enum_ld.

Section 3 , 4 . 2 . 2

Rationale 3.4.2.2,

/ Page 91

Subtype Specifications

All subtype indications are represented by a constrained node which has type mark

and

constraint

declaration can given),

attributes.

The

constraint

can

also be used just to rename a type

be

void.

(when

A

subtype

no constraint

is

so there may be a sequence of subtype declarations without constraint

information,

For code generation purposes,

applicable constraint,

it is necessary to know the last

hence a constrained node In DIANA has a corresponding

attribute, sin_constraint, that points directly to this constraint; the code generator is not forced to walk backwards through the chain of subtype declarations to find the appropriate constraint. For fixed and floating point types the last applicable constraint may have two parts, a digits ( o r delta} constraint and a range, to point to the last applicable constraint, created

for

reproducibility

the

purpose

reasons,

relevant Information,

the

of

representing

structural

in order for the am_conatraint

a fixed or float node may need to be this

constraint

constraint, may

not

For

contain

source

all

of

the

Figure 3-3 Illustrates the float node that DIANA creates for

the following example: type MYFLOAT iS digits 6 range -1.0..I.0; sub~ MYFLOAT2 is MYFLOAT digits 2;

The

code

generator

also needs the

Information

about the type structure.

which is obtained from the original type from which all intermediate derived types and subtypes are constructed, that for

derived

structure,

if any.

record

This attribute is named sm_type_struct,

Note

and enumeration types It denotes the duplicated type

This situation is discussed In the next section. 8 . 4 , 2 . 3 .

In a chain of type specifications, a user can add attributes to each type by representation specifications; these specifications are possible only for types, for subtypes, type,

The attribute sin_base_type denotes its type specification, I.e..

type (see Section 3 , 4 . 2 . 3 )

or a type structure (see Section 3 , 4 . 2 . ] )

representation information can be found, a case

not

The type from which a subtype is constructed is called its base where all

The DIANA structure that results in such

is Illustrated for the following example In Figure 3-4.

information is present at the last subtype declaration: values are in the range ] . . 9 .

a derived

Note that all

it is an integer type.

and Its representation must not exceed 8 Bits,

the

DIANA Reference Manua~

Page 92 ! Section 3 . 4 . 2 , 2

type

/\ "MYFLOAT-

float

/ \ /\

~'6"

range

"-1.0"

"1.0"

subtype

/\ "MYFLOAT2"

float

/\

/\ "MYFLOAT"

~2 n

float

/\ "2"

Figure 3 - 3 :

r~nge

/\ "- 1.0"

void

Float constraint created by

"1.0"

Section 3 . 4 . 2 . 2

Rationale

type T1 is T2 type T3 is subtype T% a ~ T5

/ Page 93

range l..Joo0; [~s T1 range 1.. 9~ new T2; is T3; is T4;

for T3'SIZE use 8;

3.4.2.3.

Derived Types

A derived type Is used to Introduce a new type which inherits characteristics of the parent type. derived type.

A user can give a new representation specification for every

tf no representation is specified,

type are Inherited.

then the attributes of the p a r e n t

"1"o treat all derived types uniformly,

the c o r r e s p o n d i n g DIANA

attributes are copied and stored with the derived type specification. a r e overwritten if the user gives a new representation.

The values

To support this,

am_alze, am_storage_size, sin_actual_delta, am_Packing, attributes am_controlled, as welll as cd.jmpl_slze, are present in a derived node,

the and

The subtype Indication defines the parent subtype and the p a r e n t type Is the base type of the parent subtype (AOA LRM [8].

Section 3 . 4 ) ,

so the Information

about the parent type can be obtained from the subtree of the d e r i v e d node, The c o r r e s p o n d i n g subtype Indication Is represented by a constrained node which has an attribute am_j)ase_type (which

sm_type_atruct (which

denotes

the

denotes the base type)

structural

information

for

and an attribute that

type);

see

Section 3 . 4 . 2 . 2 . If this structure is a record or an e n u m e r a t i o n type, then It ts possible that a representation specification is given for the derived s t r u c t u r e - - o v e r w r i t i n g the old values.

For a record structure,

declarations ( e . g . , an

enumeration

these values are recorded with the c o m p o n e n t

c o m p _ i d has the attribute am_comp_spec). type,

the

values

are

literal ( e n u m _ l d has an attribute sm_rep).

recorded

with

In the case of the

enumeration

The solution of this p r o b l e m In DIANA

requires the creation of a new type structure where the new attribute values can be filled in.

This new structure is referenced by the sm,_type_atruct attribute of

the c o n s t r a i n e d node of the derived type declaration, Duplication has another advantage for e n u m e r a t i o n Ilterals; since we now have a

defining

occurrence

for

a

literal,

the

derivation

of

an

enumeration

type Introduces new defining o c c u r r e n c e s for Ilterals that belong to the derived type and overload the old ones.

DSANA Reference Manua~

Page 94 / Section 3 . 4 . 2 . 3

typ~

subtype

/\

/\ "t1"

integer

~t3"

"t4"

constrained

derived

sin_base_type

constPained~

//

\

.t2 ~

\

void simplerep

/\ / \

"it"

attribute

"t3"

Figure 3-4:

"8"

range

/\ "1"

"SIZE" ~

Form of type/subtype Specification

"g"

Rationale

Section 5 . 4 . 2 . 3

/ Page 95

The duplication of the record structure is only meaningful and necessary if a representation specification Is given by the user, can

choose

whether to copy or to denote

An Implementation of DIANA

the old

structure.

It makes

no

difference from the logical point of view. in figure 3 - 5 we Illustrate the DIANA structure that results from the following ADA source. t y g e T I i s (RED, GRE~); T2 i s r ~ T1; for T2 use (5, 10); type

/\ "tl"

enum literal s

"YELLOW"

type

/\

f

"t2"

,,> enum_l i t e r a l _ s

/

\

derived

1

,/ "tl"

Figure 3-5:

\ vold

An Example for Derived Enumeration Types

DIANA Reference Manuat

Page g6 / Section 3 . 4 , 2 . 4 3.4.2,4.

incomplete and Private Types

For Incomplete and private types, same entity. discussed

there are two defining occurrences of the

The general solution for entitles with several declaration points Is

in

Section

3.5;

the approach

for

incomplete and

prtvate types

In

particular is described in Section 3 . 5 . 1 . 3.4.2.5.

Anonymous Array Types

"l-he ADA rutes for multiple elaborations (ADA LRM [8] Section 3 . 3 . 1 )

require

that the object declaration: X, Y= array (i..I0) of INTEGER

result

!n

X

and

Y

having

different

~= (I. ,i0 => O)

types

and

in

fact

also

cause

the

aggregate occurring above to be evaluated twice with two different types In the two evaluations,

DIANA requires that the var_ld's for X and Y refer to different

intermediate nodes so that the fact X and Y are different types can be readily determined, 3.4.2.6.

Anonymous Derived Types

The ADA semantics require that an integer type declaration is equivalent to a subtype declaration of an anonymously derived integer type (Section 3 . 5 . 5 AOA LRM [8])°

of the

To represent this in DIANA without normalizing the source program

we have introduced the attribute am_base_type for integer nodes that denotes a derived node that is created to give a unique type definition for the subtype, Similarly, this attribute is also present on float and fixed nodes,

3,4.3.

Type Specifications In Expressions

DIANA records the result of overload resolution ~n every expression node;

am_exp_type attribute denotes the result type of the expression.

Additionally.

the if

the value is statically evaluated, the value is recorded In the sm_.value attribute (see Section 3 . 8 . 1 ) . As far

as overloading resolution is concerned,

expression is of interest,

only the base type

of an

However, for expressions which denote values which

are assured to satisfy a certain constraint,

the constraint information is useful.

For this reason sm_exp_type should refer to a constrained node for (only) follow}ng nodes: = conversion and qualified whose as_name denotes a subtype name. ,, indexed and aU.

the

Section 3, 4 . 3 / Page 97

Rationale

° function_call,

if the function name Is not a built-in operator, and

o u s e d _ o b j e c t _ i d if the object Is not specification and Is not a single task,

declared

using

an

array

type

There a r e t h r e e kinds of expressions which implicitly introduce an a n o n y m o u s subtype:

aggregates,

slices,

and string Ilterals.

The resulting subtype can be

used to constrain an object If such an expression appears as an initial value for a constant object of an unconstrained array type (ADA LRM [8], The sm_constralnt attribute is used subtype constraint.

Unfortunately,

in these cases

Section 3 . 6 . l ) .

to denote a c o r r e s p o n d i n g

this constraint does not exist in all cases,

so

it must be computed by creating a suitable structure outside the tree. In the case of a record a g g r e g a t e the dlscrlmlnant values are extracted from the a g g r e g a t e and used to bultd a d s c r m t _ a g g r e g a t e node as a constraint for the type to which the aggregate belongs. In the case of an array a g g r e g a t e the constraint attribute denotes a r a n g e whose bounds are computed as described This

range can

In the ADA LRM [8],

Section 4 . 3 . 2 .

be used as a constraint for the index type of the underlying

array structure. The sm_constralnt attribute of a string literal denotes a range whose bounds a r e computed from the underlying string type (denoted by sm_exp_type) and the length of the string literal. in the preceding two cases, tree.

In the case of slices,

the slice Itself or,

the constraint must be constructed outside the

It Is already present; either It denotes the range of

if only a type mark was given, It denotes the r a n g e of the

c o r r e s p o n d i n g subtype. Note that because DIANA creates structures outstde of the tree. tree traversal ( o n e that reaches only the structural, yield

all

of

the

structural

information.

structural information do exist;

Tree

an obvious

"as._', attributes) will not

traversals

that yield

all

of

the

these necessarily follow s o m e semantic attributes

as well as the structural attributes. 3,4,3.1. Figures source,

Examples fer Constraints of Expressions 3-6

and

3-7

illustrates

the

DIANA structure

for

the

following

ADA

Page 98 / Section 3 . 4 . 3 , 1

tyj~e II is z ~

I, ,!o0o;

¢-yge A i s ~

(zz) of INTE~;

Z2 ~ B

The

DIANA Reference Manua~

Zl range I..10;

~= A;

figures

provide examples for

the

va~ue of the sm_con~tratnt attribute for

slices and a g g r e g a t e s , Figure 3 - 8 illustrates the DIANA structure for the following ADA source. < > ) Of CHARACTER;

MY_STRING ~ array (INTEGER ~ C : co~trt~mt M Y S T R ~ N G := "~¢~BC";

3, 4 . 3 . 2 .

Type Specifications for Names

The DIANA class EXP includes the class NAME which can a p p e a r in contexts other than express!ons ( l . e , ,

w h e r e v e r a n a m e can appear in an ADA p r o g r a m ) ,

in all contexts other than expressions, be

associated

with

the

nodes

there is no type and no value which can

representing

the

name,

However.

It

is

not

possible to attach different attributes to the same node type d e p e n d i n g on the context in which it is used. for these oases.

This section defines the values of these attributes

(it should be noted that those nodes in the class NAME that

can never r e p r e s e n t an expression, e . g . . have the attribute sm._value,

any node In the class DEF_IO,

do not

This discussion Is limited to those names that may

be used to r e p r e s e n t an e x p r e s s i o n . ) We ~equtre that the value of sm_exp_type be void for name nodes which a r e not used to r e p r e s e n t expressions.

The sin_value attribute in these cases must

have a distinguished value ( s e e 3 . 8 . 1 ) been evaluated.

which indicates that the attribute has not

This applies as well to u s e d _ c h a r when it a p p e a r s in contexts

o t h e r t h a n express|ons~ C o n s i d e r the following hvQ ADA fragments, ~ • ;= P.Qs I ~= p . Q ' A D D R E S $

In both cases P , Q

ts represented by a selected node.

used in an expression.

tn the first case It Is

A type can be attached to the selected node.

the type of the selected object,

in the second case the selected node is used

to d e n o t e an object for which an ADA attribute is to be computed. might have a type, of

the

attribute

as before,

does

indicating The node

but this type is unnecessary since the evaluation

not depend

on

it.

A

more

convincing

example is

the

a p p e a r a n c e of a selected node in a with clause. Note that the selected node does not have a sm.._value attribute and does not

Sectlon 3 4,3 2 / Page 99

Rationale

E×ample I : Representation of b(1..5) (slice with range)

vat

type

eprese

tion of bC1..5)

,~igo

/

l_sm.exp_type I sm ex t e y -

/

~

"0" . . .'0"

/

\

)

dscrt dscrt_~nge_s r~nge s

dscrt range_s range

constrained

/\

"i1"

/\ "1"

Figure 3-6:

:= (0.0.0.0.0)

void

"5"

Constraints on Slices and Aggregates

constrained c,/ \

integer

void

DIANA Reference Manual

Page "~00 / Section 3 , 4 . 3 , 2

Example 3 : Representation of b ( i 2 ) { s l i c e with subtype) typ~

vat

/\ slice Mm

t ~

= ... ~i

sm cons t r a l ntF--~. --

~

\

,,~.,,F'"

"

|

]

/....

~/~.r \

/

I

Cox,t~ / Oo_
"'~f

"i1"

"b"

I

constrained i ~a

,/\ ~

subtype

integer range

\

\

/ \

-

"i000"

dscrt range s -

-

1

constrained

/\

constrained " i n t e g e r " void

/ \

-,,.

.o,o

range

/\ "I"

Figure 3-7:

x

"10"

Constraints on Slices and Aggregates

void

Rationale

Section 3.4.3.2 / Page 101

t~rpe

l

/ \r,

type_~d sm..type_spec "my_strlng"

dscrt_range_s

I l

index

constrained

/\

• character"

Void

• integer"

constant

..... const_td sm_ob~_type

I l

sm..obJ_dqaf ~ [

"ABC" dscrt range_s

!

"C m

range

/\ INTEGER'FIRST

Figure 3-8:

INTEGER'FIRST+2

Constraintson String Literais

Page 102 t Section 3 . 4 , 3 . 2

record

DIANA Reference Manuat

Thus the DIANA nodes selected,

all. and a g g r e g a t e do not have the attribute sin_value,

indexed, slice,

8.5,

Only expressions of scalar

its value in the context of an expression,

types can be static (ADA LRM [8] Section 4 . 9 ) ,

Entities with Severai Declaration Points

One o1 the basic principles of DIANA requires that there is a single definition of each ADA entity.

This conflicts with those ADA facilities that allow or r e q u i r e

m o r e than one d e c l a r a t i o n point for the same entity: o i n c o m p l e t e type declarations = (limited}

private type declarations

= deferred constants o s u b p r o g r a m d e c l a r a t i o n and body o p a c k a g e d e c l a r a t i o n and body ® s u b p r o g r a m formats (in the formal part of subprogram declaration and body) = discrimlnants

(in the discriminant part of incomplete or private types)

Alt instances of multiple defining o c c u r r e n c e s possible,

are treated as consistently as

The principles that apply In all cases are

1, The first defining o c c u r r e n c e of an entity Is treated as the defining o c c u r r e n c e , and 2.

all r e f e r e n c e s to the entity should r e f e r e n c e the first defining o c c u r rence,

All defining o c c u r r e n c e s are represented with DEF_ID nodes (Section 3 . 3 . 3 ) , Multiple

defining

node.

DIANA USeS the attribute sin_first to differentiate a m o n g defining o c c u r -

rences

and

to

occurrences allow

create

references

attribute sm...first references

the

back first

multiple to

the

defining

Instances first

of

defining

occurrence

the

same

DEF ID

occurrence.

of the entity In

s a m e way sm_defn denotes the defining o c c u r r e n c e for a used ld,

The the

The node

that is the first defining o c c u r r e n c e has an sin_firM that references Itself, Note that all used o c c u r r e n c e s must r e f e r e n c e the same defining o c c u r r e n c e . the o n e that o c c u r s first. occurrence

This Is the most consistent approach since this Is the

that ts elaborated in Ada semantics.

This r e q u i r e m e n t allows for a

Section 3 . 5 / Page ]03

Rationale

consistent treatment of all Identifiers.

The attributes for all defining occurrences

must still be determined and for all defining occurrences the attributes must be Identical,

(The

attributes may be different when separate compilation Issues

intervene; see Section 3 , 2 , 1 ) . There

ts only one

(llmlted)

case that

private types,

deviates from

these

principles,

the case

of

Private types are given special treatment in DIANA. as

they are in Ada (Section 3 . 5 . 1 . 2 ) . In the following paragraphs we show the details of the DIANA structure which

preserves these principles,

We present the details Individually for all the cases

where the language allows several declaration points of the same entity.

(it

should be noted that representation specifications are not treated as declaration points, although they do appear In declarative parts. )

3.5.1.

Type Declarations

There are two forms of type declaration in which Information about the type is given at two different places: private and Incomplete types. 3.5. "t. 1. Incomplete Type Declarations The notion of an Incomplete type permits the definition of mutually dependent types.

Only the new name is introduced at the point of the incomplete d e c l a -

ration,

"fhe structure of the type Is given in a second type declaration which

must appear In the same declarative part,

(This r e s t r i c t i o n ensures that there is

no Interference from separate compilation, ) The defining occurrences of both types are described by type_ld nodes which have the semantic attribute sm_type_spec.

In both cases,

the value of this

attribute can denote the full type specification which satisfies the DIANA r e s t r i c tion,

The defining nodes also have the attribute sm first which refers to the first

occurrence,

the incomplete declaration,

Note that if the incomplete type d e c l a -

r a t i o n includes a discrlmlnant part. that becomes the defining occurrence of the dtscrtmlnant identifiers (see Section 3 . 5 . 1 , 3 Figure

3-9

Illustrates the

declaration, t y p e T~

below).

DIANA structure for the following

Incomplete type

Page 104 / Sect}on 3 . 5 . ] . 2

DIANA Reference Manual

Lype

/ \

type

_/\

I type d smtype spec

void

type_id _~ record

i Figure 3 - 9 : 3 . 5 . ] , 2.

Example of an

Incomplete Type

Private Types

Private types are used to hide information from the user of a p a c k a g e ;

a

private type d e c l a r a t i o n

is given in the visible

structural

information.

The futl declaration is given In the private part of the

package

specification,

from

(This

separate compltatlon).

for Incomplete types; attributes,

restriction

part of a package without any

ensures that there

Unfortunately,

is no

Interference

we cannot adopt the solution used

If both defining o c c u r r e n c e s had the same node type and

we could

not determine whether the type Is a private one or

not,

This i n f o r m a t i o n is important when the type is used outside of the package. DIANA v~ews the

declarations

as

though

they were

declarations

e n t i t i e s - - o n e is a private type and the o t h e r a normal one, s a m e type structure tn their s m t y p e _ s p e c achieved

by

tntroducing

private.._type td.

a

new

kind

attribute,

of

the

case

of

defining

it has the attribute s m t y p e _ s p e c

Information given in the fult type d e c l a r a t i o n . the s a m e way,

a

however.

of

dlflerent

Both d e n o t e the The distinction Is

occurrence,

namely

Umtted private types are treated In

except that their defining o c c u r r e n c e is a L p r t v a t e _ t y p e _ i d ,

(limited)

the

which denotes the structural

private types the sm first

attribute of the type_id

refers to the prlvate_type_ld or L p r l v a t e _ t y p e _ i d . Figure 3-'d0 illustrates the DIANA structure for the following example.

tn node

Section 3 , 5 , 1 . 2

Rationale

/ Page 105

package DF-~_T i s ~ T

is private~

private type T .%s a ~ e s s

...

° Q °

/\

type

type

private_type_id

type_id

~

access

sin_type spec

?,)-

Figure 8-10:

Example of a Private Type

Since we have Introduced two distinct defining occurrences for the type we must specify which of these definitions a used occurrence

private

refers to.

Any use outside of the package denotes the prlvate_type_ld or I_private_ld (but nevertheless

has

structural

information)

and

any

usage

inside

the

package

denotes the full type declaration; in the interior context, there are no restrictions on the use of the type, 3, 5. ] . 8, Dlscrimlnant Parts When contains

an a

Incomplete type dlscrlmlnant

normal type declaration, Identifiers.

part.

declaration or the

(limited)

dlscrlmlnant

part

private type must also

declaration

appear

in the

This creates a multiple definition of the dtscrlmlnant

Thus the dscrmt_id node also has an attribute sin_first that refers to

the first definition point.

ADA semantics demand that the dlsorlmlnant part be

elaborated at the first occurrence. The attribute sm_dlscrlmlnants exists for I_prlvate and private nodes because for a generic forma~ private type declaration, the dlscrimlnants are not supplied until

Instantlatlon.

After

Instantiatlon,

this attribute denotes the

dlscrimlnants

Page ] 0 6 / Section 3,5. t . 3

DIANA Reference Manual

supplied by the generic actuat type, When a dtscrlmlnant part Is supplied in the (limited) private type declaration. the sm_d/scrtminants of the private node and the record node in the normal type declaration should always refer to the dlscrtmlnants in the first,

(limited) private.

type dectaratton,

3, 5 . 2 .

Deferred Constants

Deferred constants are a direct consequence of the concept of private types; since the structural details of a type are hidden, the structure of the initialization expression must be hidden as wetl.

They are deferred to the private part,

The

deferred constant declaration ( r e p r e s e n t e d by the node deferred_constant)

and

the full declaration of the deferred constant (a constant node) are both defining occurrence

of the const_ld.

The attributes of both defining occurrences

deferred constant have the same values, tributes

denote

the

type

specification

satisfying our requirement,

and

the

of a

The a t -

initialization expression.

Both

attribute values are equal to those of the full declaration of the deferred c o n stant.

Note that const_id

defining occurrence.

also has the attribute sin_first to denote the first

Figure 3-11

Illustrates the DIANA structure for the following

example, T is ~£ivate; A

: c~nstant: T;

t3rge T is ~ m c ~ 0..10; A : oons~cant T -= O~

3.5.5.

Subprograms

The declaration and body of a subprogram can be separate from each other. Moreover, stub

~n the

declaration

case

can

in

also

which be

the

given.

body All

is

three

complied

as

declarations

a

subunit,

a

appear

in

can

different compilation units: the declaration in a package specification, the stub in the package body, and the body as a compltation unit (subunlt) itself. examine the

simplest case

declarative part.

where

declaration and

body appear

in the

Then we adapt the solution for the cases where

compilation is involved.

We first same

separate

Section 3 , 5 . 3 . 1 / Page 107

Rationale

deferred_constant

type

/\ "t"

private "t"

const_td sm_ob~_type =m_0bj_de~ constant

const id

~

type

/\ Jl

"0"

constrained

sm_obj_type

sm_type_struct

sm_obj_def

sm c o n s t r a i n t

"t"

/\ "t"

integer

range

void

/\ "0"

Figure 8-11:

"10"

Example of e Deferred Constant

3 , 5 . 8 , 1. Declaration end Body in One Declarative Part The declaration and

the body of a subprogram

belonging to the same entity,

Therefore.

are viewed In DIANA as

according to our restriction,

both

defining occurrences must reference the first defining occurrence (the subp~ogram declaration) and must have the same attribute values. Since the header of

the

first

defining occurrence

Is used to elaborate

the

subprogram,

the

8m_apec attribute of both defining occurrences denotes the header of the decla-

ration. Both

defining

describes the body,

subprogram

Identifiers

further

reference

the

block

which

This method leeds to the structure shown in Figure 3-12,

Page 108 / 8ec~tcn 3 , 5 . 3 . 2

DIANA Reference Manual

subprogram d e c 1

proc

id subprogram b o d y

sm_spec srn_body

procedure

proc_id

block

sm_spec

sin_body

Figure 8-t2:

Subprogram Structure

3, 5 , 3 , 2. Deciaratton and Body in Different Compilation Units Since a subprogram body cannot appear in a package specification but must be

declared

tn

the

package

body,

and

since

package

bodies

will

often

be

separately compiled, the declaration and body of the subprogram will often be tn separate compilation units. Updates to previously complied units are forbidden in DIANA. not possible to insert the value of am_body in the declaration. this decision are discussed in more detail in Section 3 . 2 . 1 . cases where the

body is in a separate unit,

Therefore,

it is

The reasons for Therefore,

In all

the value of sin_body Is void.

Nevertheless, If the DIANA tree for the declaration is processed, the attribute may be temporarily set to point to the corresponding body if It is present as well, Thus, during processing DIANA principles lor multiple definitions are followed, The permanent structure for a subprogram declaration and body in separate compilation units is as shown in Figure 3-13,

Section 3 . 5 . 3 . 3 / Page 109

Rationale

subprogram _d e C1

/1\

proc_id

void

sm_spec sm_body

proc ~d

~

b

l

o

c

k

sm..spec am_body

Figure 3-13: 5.5.3.8,

Subprogram Declaration and Body in Different Compilation Units

Subprogram Bodies as subunlts

If a subprogram body Is compiled as a subunit, It is possible for there to be a third defining occurrence, a stub declaration, making a defining occurrence in three different compilation units.

We adapt the solution presented above, adding

the stub declaration which makes the picture more complicated, as is shown in Figure 3-14. The attribute am_stub Is used to refer to the defining occurrence of the stub. This attribute provides a quick means of finding the stub when It is in a separate compilation

unit.

Figure

am_first and am_stub.

3-]5

shows

the

DIANA values

for

the

attributes

(In subsequent figures the values for the attributes

am_first and sin_stub are not shown.

The treatment of am_first and am_stub for

other DIANA constructs does not differ significantly from the treatment shown in figure 3-15.) am_body

is

prevented

am stub is required compilation unit.

to

be

Just

as

void

from when

forward the

stub

references, appears

the in

a

value

of

separate

Page l'tO / Section 3 . 5 . 3 . 4

DIANA Reference Manuat

subprogram _de c'i

procedure

void subprogram b o d 3'

/

procid

stub

sm_spec sm_body

subprogram_bo dy

Figure 3 - 1 4 : 3.5, 3.4.

Example of a Subprogram Body as a subunit (I)

Entries and Accept Statements

An entry dectaratlon and its corresponding accept statements are not treated as different definition points of the same entity.

The abstract syntax Indicates a

name for an accept statement which Is viewed as a used occurrence; the same approach.

DIANA uses

Thus the entry_ld Is the unique defining occurrence;

a

used_neme_ld appears as a child of an accept statement and refers to the entry declaration.

However,

the formal part of the entry declaration and the accept

statement multlpiy define the entry formals (see Section 3 . 5 . 3 . 5 8.5.3.5. When body

betow).

Subprogram Formals

the declaration of a subprogram is separate from the subprogram

(and

stub)

the

subprogram

formal

part

multiple definition of the subprogram formals,

ts

repeated,

This

creates

a

Thus the subprogram defining

Section 3 , 5 . 3 , 5

Rationale

/ Page 111

subprogrzrn _dec1

proc_id subprogram b 0 d3,

s m first

sm_s~.ub void

proc id

procedure

stub

sin_first s m stub subprogram..body

proc_id

procedure

bloc~.

srn Ilrst srn stub •

Figure 3-15: occurrences (In_id, the first occurrence°

•

t

Example of a Subprogram Body as a subunlt (ll) In_out_.ld, and out_ld) have the attribute sin_first to refer to ADA semantics require that the first occurrence Is the one

that Is elaborated. -rhls treatment applies to formal parts In entry declaratlons and accept statements also.

S. 5 . 4 .

Packages

Packages are declared by at least a specification and possibly a body: In the case of subunlts, a stub declaration must also be given, the same situation as subprograms,

Thus packages present

and the DIANA treatment of packages Is in

principle the same as that for subprograms (except that the structure and the attribute names are different).

Page t 1 2 / Section 3 . 5 , 4

DIANA Reference Manual

We ~estrtct ourselves to the complicated case of having three different definition places for packages; the DIANA structure is shown tn Figure 3-16. package_dec]

package id J

package_spec package_body

Figure 3-16:

3.5.5.

Example of a Package Body as a subunlt

Tasks

Task specifications can appear tn two contexts, single task specification. Identifier (type_ld. task..body_Ido rences

and

attributes.

as a task type and as a

The context Is distinguished by the kind of the defined

var_ld).

A task body is neither,

so DIANA has additionally a

This addltlona~ node Implies that there are two defining o c c u r therefore two distinct

DIANA entitles whtch do not have the

same

Although there are different nodes, the DIANA structure looks similar

to the solution for packages.

In particular, the same principles are applied in

the presence of separate compilation.

Rationale

3.5,5.1.

Section 3 . 5 . 5 . 1

/ Page 113

Task Types and Task Bodies

In the case of a task type and a corresponding body, structure shown in Figure 3-17.

sm._body attribute denotes void for stub declaration.

we have the DIANA

In the presence of separate compilation, the the

task

specification

and

stub

for

the

This approach parallels the approach used for for packages

and subprograms.

Used occurrences of the task Identifier denote the type_id;

the am_first for the task_body_td also references the type_id.

type

\ type_id

sm_body

block

task_body_id

sm type_spec smbody

Figure 8-17: 3.5.5.2.

Example of a Task Type and Body

Single Tasks and Task Bodies

Single tasks are represented by a task_decl node with a Yar._ld. specification Is given as an anonymous type specification.

The task

The DIANA structure,

nearly the same as the structure used for task types, ts shown In Figure 3-18. Used

occurrences

reference

the

var._id;

the

smJirat

attribute

of

the

a single task,

the

t~sk..body_id also references the var_ld. Note that

In the

case

of

an

address specification

sin_address of the var._ld and the task_spec are both set.

of

Page ~ 4

/ Sec~lo~ 3 . 5 , 8

DIANA Reference Manuaf

task c~ec~

j/

,/ \

/

L L

/I

v~r_id sm~ objm type

Figure 8-18:

3, 5 . 6 .

Example of Single Tasks

Generic Un}ts

Like subprograms and packages, points:

generic units can have severat declaration

the specification and the body (and possibly the stub as w e l l ) ,

to have the same information at these declaration points,

In order

the identifier of the

body of the generic unit has to be a generic_ld with the same attribute values as the

defining

occurrence

within

the

specification,

Thus

the

attribute

sm._generlc_param_s points to the list of generic parameters given with the specification, and the attributes sm.._spec and sm._body are set as in the case of simple s u b p r o g r a m s or packages, program

forma~s

are

treated

as

Note that for generic subprograms the s u b described

in

Section

3,5.3.5,

structure for a generic subprogram is illustrated in figure 3-19.

The

DIANA

Section 3 . 6 / Page 115

Rationale

generic

gener;c_param..s

generic~d sm_generic_param_s

p roce du r e

.~

subprog ram _b o d 3'

smspec L

am_body

Figure 3-19:

3.6.

Example of a Generic Body as a subunit

Treatment of Instantlationa

In this section we describe how DIANA treats Instantlatlons of generic units, An

obvious implementation would copy the generic

unit and

substitute the

generic actual parameters for all uses of the generic formal parameters In the body of the unit.

This substitution cannot be done If the body of the generic

unit Is compiled separately.

A more sophisticated Implementation may try to

optimize tnstantlatlons by sharing code between several Instanttattons.

Therefore

the body of a generic unit Is not copied in DIANA in order to avoid constraining an implementation,

indeed,

an instantlatlon may occur

in the absence of a

generic body, In DIANA the Instantlatlon Is performed In two steps. of the generic parameters Is created.

First.

a normalized list

The nodes of the type inatantlation have

the semantic attribute sm_decl_s with a sequence of declarations.

This attribute

Is the normalized list of the generic parameters, including entries for all default parameters.

The values of this attribute are determined as follows:

- For every generic formal In-parameter, a constant declaration is created (the am_obl._def refers to either the expression given or to its default value),

Page "116 / Section 3.~

OIANA ReJerenc:e M a n u a l

for every generic formal ~n-out-parameter, a Yarlable declaration is created (the sm_obi_def refers to a rename node which indicates the object in the actual itst that is renamed by the new declaration), for every generic formal type,

a subtype declaration ~s created

(the

sm_type_spec attribute is a constrained node wtth a void constratnt that references the type name given in the association list), and for every generic formal subprogram, a new subprogram declaration Is created (the sin_body attribute references a rename node which Indicates that the newly created subprogram renames either the subprogram given In the association list or that chosen by the analysis as the default), tn the second step the specification part of the generic unit is copied.

Every

reference to a tormal parameter in the original generic specification Is changed to reference the corresponding newly created declaration, dlscrlmlnants,

references

to them are changed to

If a formal type has

point to the corresponding

dlscrlmlnants of the base type of the newly created subtype, Examples of ~nstantiations are presented ~n the following two sections,

3.6.1.

Jnstanttatton of Subprograms

The generic

Instantlatton of a subprogram

shown in Figure 3-20. functions

is represented by the structure

We use procedures as an example; the structure for

is similar.

Figure

3-20

illustrates the

Instantlation of the following

generic: gene~cic L E N G T H = ~NTEGER 2= 200; type E L E M is private; p r o c e d u r e E X C H A N G E (U = in o u t ELEM); procedure

The

procedure

SWAP is

node

of

parameter list is empty. associations;

EXCHANGE(ELEM

the

~> INTEGER)#

subprogram_decl

contains

no

Information;

Its

The lnstantlatlon node represents the generic parameter

it is referenced by the sm._body attribute of the proc_ld node. The

Instantlation

node

contains

constant

a

new

-- default value

also

has

a

declaration

normalized of

list

"LENGTH'

of

the

ustng

generic the

parameters;

default

and

a

It

type

declaration of the subtype "ELEM' using the type name given tn the association tist.

The sm__spec attribute of the proc td node references the header of the

instanttated

subprogram,

it

is

obtained

by copying

the

generic

subprogram's

header and replacing references to the generic f o r m a l parameters with references to the new subtype declaration and constant declaration,

Section 3.6.2 / Page ll7

Rationale

subprogram _d • c 1

L

proc_td

procedure t~nti~tton I

1

pec Q

!

•

/\

•

"EXCHJ~(3E"

"SWAP"

J -'----'~

constant-

/l\

a.%oc "length"

• • •

/\

procedure

!

"ELEM"

pararLs

"200"

"|ntege r" subtype ~ J ~

/\

i in_out

"ELEM"

J \\

"U"

P_s

constrained

E

t[

hELE~ N

, sin_defn

Figure 8-20:

InstantlaUon of a Generic Procedure

D~ANA R e l e r e n c e Manuaf

Page 118 / SecUon 3 . 6 . 2

3.6.2,

!nstanttation of Packages

The g e n e r i c tnstantlation of a package ts represented In DIANA by the structure shown

tn

Figure

3-21,

The

instantlatlon

sin_body attribute of the package Identifier, structed

by

references actual

copying

the

to g e n e r i c

specification

of

node

~s

referenced

by

the

The package specification Is c o n the

generic

unit

and

replacing

all

forma~ p a r a m e t e r s with references to their c o r r e s p o n d i n g

parameters,

The

resulting

specification

is

denoted

by

the

sm_spec attribute ef the package Identifier.

3.7.

T r e a t m e n t of Renaming

The r e n a m i n g of entitles does not introduce further problems, DIANA r e p r e s e n t a t i o n

for

some

renamlngs

may not be

However. the

obvious.

This

section

clarifies how DIANA treats entitles introduced by a renaming d e c l a r a t i o n . Renaming

of

objects

and

Note that an h3entifler which

exceptions

are

simple

and

not

discussed

here,

r e n a m e s a constant object has to be a c o n s L I d .

Constant objects are constants,

dlscrlminants,

and parameters of m o d e In,

as

well as c o m p o n e n t s of constant arrays,

3.7. t.

Renaming of S u b p r o g r a m s

The renamed

renaming

d e c l a r a t i o n for

item,

a subprogram

Th~s h e a d e r can

be denoted by the am_spec

n e w l y - i n t r o d u c e d s u b p r o g r a m identifier, the sm._body attribute, Information. Note that

must repeat the h e a d e r of the attribute of the

The r e n a m e information Is referenced by

since the actual body can be obtained from the r e n a m e

The structure is illustrated In Figure 3-22. an

identifier which

family has to be an entry_|d, literal as a function.

renames

an entry or

a member

of an

entry

it is possible In ADA tO r e n a m e an e n u m e r a t i o n

~n such a case the identifier that renames an e n u m e r a t i o n

tlteral has to be an e n u m J d .

3 . 7 , 2. The

Renaming of Packages renaming

specification.

The

declaration

~mspec

of

a

attribute

package of the

r e f e r e n c e s the origlna| p a c k a g e specification, always

present

r e n a m e node,

for

a

package

identifier,

does

net

repeat

new package

the

package

identifier

therefore

in o r d e r that the specification

The

is

sm_,body attribute d e n o t e s the

The resulting structure is illustrated in Figure 3 - 2 3 .

Section 3 . 7 . 3 / Page 119

Rationale

package_dec1

instantiation srn_body sm spec

~

1

package_spe¢

/\ decl_sl

1

Figure 3-21:

decl s2

I

InatantlaUon of a Generic Package

Page 120 / Section 3, 7, 3

DIANA

subprog dec1

~- proc_id sm_spec

procedure rename -~

1

I sin_body

Figure 3-22:

. . .

Renaming a Procedure

package dec1

I =-~P~ b-~

..-

package_spec

/\ decl_sl

Figure ~-28:

decl._s2

Renaming a Package

Reference Mar}uai

Rationale

3.7.3.

Section 3 . 7 . 3 / Page 121

Renaming of Tasks

Task objects

can

be renamed

like other objects.

treated Just like the renaming of objects. types.

3.8.

The task

renaming

is

Task types are renamed just like other

Note that there Is no other renaming declaration for tasks,

Implementation Dependent Attributes

Representation Independence was a principal design goal of DtANA.

DIANA

does not force an implementation strategy on either a F r o n t or Back E n d - - o r on any other tool for that matter. (in

part)

by using

defined,

An

representation,

The description of DIANA deals with this problem

private types for attributes that are to

implementation

has

the

freedom

to

be implementation

choose

but it must support the corresponding attributes.

a

suitable

Thus an i m -

plementation must provide appropriate packages in which the attribute types are defined, together with the necessary access operations, In this section we describe the purpose of the attributes in detail and sketch possible Internal and external representations of them,

3.8.1.

Evaluation of Static Expressions

The language requires that static expressions be evaluated at compile time in particular contexts

(see

ADA LRM [8].

Section 4 . 9 ) .

This evaluation can

be

done either by the code generator or by the Front End (with target and host independent a r i t h m e t i c ) . structure

may

be

used

Both ways are supported by DIANA. as

Input to the

Front

End

in the

Since the DIANA case

of

separate

compilation, the latter solution has the advantage that the previously evaluated expression can be used in the currently complied unit.

For this purpose every

expression node that can have a static value has an attribute sin_value whose type is Implementation dependent 1. Chapter 5.

The

Its external representation is discussed

value of this attribute which Indicates that the expression Is not evaluated. does

not

provide

in

implementation of the type must provide for a distinguished for

non-static

values

to

be

computed,

even

DI/~A If

an

imptementatlon's semantic analyzer Is capable of evaluating some such expressions (see Section 1 . 1 . 3 ) .

1Note that only .acalar types can have static expressions

Page ] 2 2 / Section 3, 8, P.

3,8.2,

DIANA P,eference Manual

Representattor~ of !dentiflers and Numbers

The

attribute types symboI.Jep and

number_fep are not defined

Their externat representation is discussed in Chapter 5. tation is not specified,

3, 8, 3.

in

DIANA.

Their internal r e p r e s e n -

so that DIANA does not impose a special implementation.

Source Positions it may

Source position is important for e r r o r messages from the c o m p i l e r . also

be

usefut

to

other

tools

that

work

with

the

DIANA structure,

such

as

interpreters or debuggers. The structure system

has

its

of this attribute is not defined by DIANA since each c o m p u t e r own

notation

of

a

position

in

a source

notation can vary between too|s of the same environment;

file.

M o r e o v e r this

an interactive syntax-

directed e d i t o r may have a different type of source position than a b a t c h - o r i e n t e d c o m p i l e r for example. DIANA does not require that this attribute be supported by every Implementation ( s e e Section

t, 1.3)~

Any implementation that does support this attribute must

define a distinguished value for this type for undefined source positions,

which

can be used if nodes are created which have no equivalence in the source file. The ~lbrery m a n a g e r for certain Implementations may need a value indicating which c o m p i l a t i o n unit a DIANA entity comes from. belongs

with

the

source

position,

and

should

This Information a p p r o p r i a t e l y be

incorporated

into

such

an

I m p l e m e n t a t i o n ' s definition of the private type,

S, 8.4. Comments The Ix_comments program.

The

attribute ~s used for

structure

of this

recording comments from the s o u r c e

attribute is not defined

by DIANA since

every

i m p l e m e n t a t i o n may have its own method of attaching comments to DIANA nodes. A g e n e r a l i z e d method for attaching c o m m e n t s to nodes is impractical; no method that will be accurate for all c o m m e n t i n g styles,

there is

We envision local

c o m m e n t i n g standards that wttl be enforced to match the implementation c h o i c e s for attaching c o m m e n t s to tree nodes~

Note that support of the Ix_comments

attribute Is not required for an implementation to be considered a DIANA producer or a DIANA consumer,

Section 3 . 8 . 5

Rationale 3,8.5.

/ Page ] 2 3

Predeflned Operators and Built-In Subprograms

sin_operator

The

attribute

Is

i m p l e m e n t a t i o n - d e p e n d e n t built-in treated as functions

in DIANA and

used

to

Identify

subprograms 2. are

predeflned User'deflned

not considered here.

operators

and

operators

are

The predeflned

operators and built-in subprograms are treated specially because it Is important information for the code generator and for an optimizer. The type of this attribute is implementation-defined,

A likely implementation

is an enumeration type with at least one literal for each predeflned language operator,

The refinement of DIANA given in chapter 2 gives the minimum subset

of operators that must be supported.

An implementation can obviously support

further operators which can be added to this enumeration, The means by which this information is made known to the Front End is not specified in analysis:

DIANA,

We provide only for

representing the

result of semantic

tf the Front End recognizes that a compilation unit uses one of the

built-In subprograms, then the used_name_ld of the subprogram is changed to a used_bltn_id whose sin_operator attribute is set to denote the particular built-in subprogram that was used,

3.9.

Equality and Assignment

The

DIANA representation assumes a welt-defined notion of equality for

attribute types, an

equality

including tree-valued attributes, comparison

operation

so

all

An implementation must provide that,

for

instance,

the

am_type_spec attribute of two entities of the same type will be equal and will not be equal to the sm_Cype_spec attribute of a n y entity of different type. If

an

Implementation

attributes as equality.

pointers,

Implements

nodes

as

access

then the equality comparison can

types

and

tree-valued

be a simple pointer

DIANA does not force this implementation, however.

It Is still possible

for an implementation to make separate copies of a defining occurrence,

For

example, consider a situation where a separately complied unit A defines a type, two other units B and C use this type to declare variables X and Y. and a fourth unit D references both X and Y. It is posslble for an implementation to decide to copy some type Information from A Into B and C. However.

a tool processing

21:or example, an imptementatlonmay "build in" knowledgeof the LOG function from tlbrary p~t~ge MATH LIB,

Page 124 / Section 3 . 9

D~ANA Reference Manuat

the representation ~or unit O must be able to compare the sm_type_spec tributes of X and Y for equality.

at-

Thus the implementation making the copies

must keep enough information in its representations to be able to tell that the copies

are copies

of the same thing,

One possible solution

is to attach a

unique key to every entry and to copy the key along with the other portions of the entlty~

The equality test can use this key for comparison.

DIANA ~mposes a further procedures.

requirement on

Implementations of attribute-storing

If an ~mp~ementatton stores an attribute of a defining occurrence or

a type specification, Once again,

this change must be visible to all uses of such entitles.

making the change visible ls easy If the corresponding attributes in

the uses are Implemented as pointers. has copies of such

entities,

In the case where an Implementation

the store procedure must ensure that all copies

which might be referenced are updated appropriately. Note that the duplication of tree structures imposed by DIANA, especially those described

in Sections 3 . 4 , 2 . 3

section.

They represent information for new objects,

of Instantiated units.

and 3 . 6 ,

are not copies In the sense of this either of derived types or

The new objects must be different from the original ones.

DIANA does make a requirement about the value of tree-valued attributes in the external ASCII form (Chapter 5 ) .

Tree-valued attributes that are equal must

be represented externally by a reference to the same tree; they must essentially share the value.

3.10.

This issue is addressed more completely In Chapter 5.

Summary of Attributes

A short description of all attributes of DIANA closes the Rationale. describe

the

structural

attributes

(for

the

tree) ;

this

description

We do not is

In

the

AFO and can be deduced from the concrete syntax of ADA (which Is Included In the DIANA definition for c o n v e n i e n c e ) . described.

The remaining three attribute classes are

If they are already explained in the Rationale, then only a reference

to that section appears.

3. ]0. ] .

Lexical Attributes

Ix_numrep:

Internal (or external) representation of a numeric the type is Implementation dependent, see 3 . 8 . 2 .

literal,

lx,_defauit:

is of type Boolean, indicates whether the mode of ~n-parameter was specified (False) or defaulted ( T r u e ) .

an

Section 3 . 1 0 . 1

Rationale

/ Page 125

Ix_prefix:

is of type Boolean; indicates whether a function call was written using prefix (True) or infix (False) notation, see 3.3.4.

Ix arcpos:

source position of the corresponding implementation dependent, see 3 . 8 . 3 .

Ix_sym rep:

Internal (or external) representation of a symbol ( I . e . . an identifier or a string), the type Is Implementation dependent, see 3 . 8 . 2 .

Ix comments:

representation of comments from the program source, type is implementation dependent, see 3 . 8 . 4 .

3.10.2.

node.

the

type

Is

the

Semantic Attributes

am_actual_delta:

is of universal rational number type. contains the value of the predeflned attribute 'ACTUAL_DELTA.

sin_address:

denotes the expression given in a representation specification for the predeflned attribute "ADDRESS. it is void if the user has not given such a specification.

am_ba~oJype:

denotes the base type of a subtype, see 5 . 4 . 2 . 2 .

sm_b lfs :

Is of a universal integer type. predeflned attribute 'BITS.

am_body:

denotes the body of a subprogram or package. It is void If the body or stub are not in the same compilation unit. see 3,. 2. ] . For Instantlated or renamed entities It has the type InstanUation or rename (see 3 . 6 or 3 . 7 . respectively). For generic formal subprograms it denotes the FORMAL_SUBPROG_DEF. If the pragma INTERFACE has been applied to the subprogram, it denotes the defining occurrence of the given language name in the predefined environment(see Appendix I).

sm_comp_spec:

refers to the representation specification for a record c o m ponent or discrlminant.

am_constraint:

for expressions see 3 . 4 . 8 .

am_controlled:

Indicates whether the pragma CONTROLLED has been a p plied to the type.

8m_decl_a :

belongs to an instantlation node. tt refers to a normalized parameter list which contains a declaration (DECL) node for all formal parameters, see 3 . 6 .

contains the value of the

for subtypes see 3 . 4 . 2 . 2 .

Page 126 f Section 3, tO. 2

O!ANA F~eference Manuat

~m_defn:

denotes ~he defining 3~3~

occurrence

oL' a used

identifier,

see

smd/scrtmtnants:

denotes the sequence of dlscrlmfnants given for a r e c o r d o r (t~mtted) private type, may be empty, see S. 5. "I.8.

s m _ e x c e p t i o n _ d e f : denotes the EXCEPTION_DEF subtree of an exception d e c l a ration, which ts void In normal cases and a r e n a m e node if !t is a renaming declaratlon. sm_expjype :

denotes the type of the expression as the result of o v e r !ceding resolution, see 3 . 4 . 8 ,

am_first:

refers to the first o c c u r r e n c e of a multiply defined identifier, see 8 . 3 . 8 .

s m _ g e n e r i c _ p c ram_~ : denotes the list of generic p r o g r a m or package,

p a r a m e t e r s of a g e n e r i c

sub-

amJnlt_exp ;

denotes the initialization expression given for numbers, p a r a m e t e r s , record c o m p o n e n t s , and dlscrlminants.

in

smJocation:

denotes the tocation of a s u b p r o g r a m ; it may be (a) void, (b) the Identifier ( p r a g m a _ l d ) of the p r a g m a INLINE if that has been applied to the s u b p r o g r a m , or (c) an expression supplied by the user in an address specification for the subprogram.

am._normalt zed._comp_s : denotes the normalized list of vatues for a record a g g r e g a t e or for a discrlmlnant constraint, including default values. 8 m _ n o r m a l i zed._param_a : denotes the normalized Itst of parameters for a p r o c e d u r e , function, or entry call, including the default parameters. s m _ o b f _ cfef :

denotes the initialization expression of an object, it is void if none is given. In the case of a r e n a m e d ob}ect, it denotes the r e n a m e node of the declaration structure,

am_obi_type :

denotes the type specification of a declaration (constants~ p a r a m e t e r s , discrlmlnants, numbers, variables, e n u m e r a t i o n Hterals, and tasks). For deferred constants see 3 . 5 , 5. in case of numbers it denotes one of the universal types, see Appendix I.

sin_operator:

denotes o n e of the predeflned p r o g r a m s , see 5 . 8 . 5 .

operators

or

built-in

sub-

Section 3.10..2 / Page 127

Rationale

sm...packlng :

indicates whether the pragma PACK has been applied to that type.

sm_pos :

Is of universal Integer type, contains the value of the predeflned language attribute 'POS of an enumeration literal.

,sm j e c o r d _ , s p e c

:

refers to the representation specification for a record.

arn r e p :

ts of universal integer type, contains the value of the predeflned language attribute 'VAL of an enumeration Ilferah which can set by the user, See aiso 3, 4 . 2 . 3 ,

8m_slze :

denotes the expression given in a representation specification for the predeflned language attribute 'SIZE; it is void if the user has not given such a specification.

•s m . s p e c :

denotes the specification of a subprogram or package. In the case of subprograms, it is its header (for Instantlatlons, see 3 . 6 ) . In the case of packages, it Is the package specification, For Instanttated packages, see Section 3 . 6 and for renamed packages, see Section 3 . 7 . In the case of a generic unit, tt is the generic header of the unit,

sm_Mm :

denotes the statement to which a label, loop name. or block name definition belongs or the loop which is left by an exit statement.

sin s t o r a g e _ s i z e :

denotes the expression given in a representation specification for the predefined language attribute 'STORAGE SIZE; it is void if the user has not given such a specification.

am_stub:

refers to the defining occurrence of the stub, see 8 . 5 . 3 . 3 .

sm type_spec:

denotes the specification which belongs to a type Identifier; for private and Incomplete types, see Section 3 . 5 . 1 , for tasks and task body identifier, see Section 3 . 5 . 5 .

8m type_struct:

denotes 3.4.2.2,

8m_value:

contains the value of the corresponding expression If It Is statically evaluated, its type is implementation dependent, see 8 . 8 , 1.

the structural information of or derived type, see 3 . 4 . 2 . 3 .

a

subtype,

see

Page 128 ! Section 3, '~0.3

3.10.3.

DIANA Reference Manua~

Code Attributes

cd_impl_~ize :

3.10.4.

of type unlversal integer, contains the value of the attribute 'SIZE for static subtypes. It may be less than a user defined size,

U n n e c e s s a r y Attributes

There are a number of attributes one might expect of semantic analysis that are not explicitly represented In DIANA since they are very easy to r e c o m p u t e . The

floating

'LARGE,

point

attributes

corresponding

to

'MANTISSA,

and 'EPSILON can all be computed from 'DIGITS,

expression.

be e

static

3.5.7

and 3 . 5 . 8

Formulae for

these

'SMALL,

which Is required to

attributes are

of the Language Reference Manual,

"EMAX, given

in

Sections

and are r e p r o d u c e d here

for c o n v e n i e n c e : 'MANTISSA

= ceiling('DIGITS * LnC~t0) / L n ( 2 ) )

'EMAX

= 'MANTISSA * 4

'SMALL

= o5 * 2 * * ( - ' E M A X )

'LARGE

= ( 1 . 0 - ~EPSILON)

'EPSILON

= 2o 0 * x ( - ' M A N T I S S A )

For

fixed

point

types,

'ACTUAL_DELTA and 'BITS.

all

x 2~,EMA×

attributes

can

be

defined

in

terms

of

Page 129

Definition of the Diana Operations

CHAPTER 4 DEFINITION OF THE DIANA OPERATIONS

Recall that DIANA Is an abstract data type.

By the nature of an abstract data

type as implemented in a p r o g r a m m i n g language, aU that need be known about the type are the functions and procedures that operate on objects of the type. Thus to realize the abstract type DIANA In some programming language, Is needed Is to write those functions and procedures.

all that

In a language like ADA It

IS possible to separate the specification of these functions and procedures from their Implementation. In this chapter we provide an ADA specification (but not Implementation) of the Interface to the necessary functions and procedures to define DIANA, ther.

we suggest how.

in general,

Fur-

an implementatlon-specific package may be

derived from an IDL definition.

Since the derivation of packages from an IDL

description is a complex topic,

we only sketch one possible derivation for one

particular language.

A detailed discussion of the package derivation process is

given In the IDL Formal Description [9].

4. 1. The DIANA Operations Every object of type DIANA IS the representation of some specific ADA program (or

portion of an ADA p r o g r a m ) .

Specifically,

It may be thought of as the

output from passing that program through the Front End of an ADA compiler.

A

minimum set of operations on the DIANA type must Include the following functions and procedures:

type_getter

Such a function permits the user to determine of a given object what its type Is. In DIANA terms, tf an object Is known to belong to some specific node class, the function determines the obJect's node type.

8e~c~r

Such a function returns the value of a specific attribute of a node.

constructor

Such a procedure builds a node from Its constituent parts, or changes the value of an attribute of a node.

In addition,

operators are necessary to determine the equality of DIANA objects,

Specifically.

are a given pair of instances of a DIANA type In fact the same

Pago ~30 / SecIIon 4.~

~nstance.

DIANA Reference Manua~

as opposed to oquivalent ones1?

In case there are variables of this

abstract data type, an aaslgnment o p e r a t o r is necessary as well.

4.2.

DIANA'S Use of Other Abstract Data Types

An IDL definition (such as the definition of DIANA In Chapter 2) subsidiary abstract data types. (such

as I n t e g e r ,

types (such

These

Boole~J~, ,Secz OD

as s o u r c e _ p o s i t i o n ,

include those used

In the

Is built upon IDL notation

as well as i m p l e m e n t a t i o n - d e f i n e d attribute

symbol_rap,

and so o n ) .

o f have the same o p e r a t l o n s as described above,

All of these except

it must be carefully noted

that for the scalar types ( I n t e g e r ,

~>olean) t h e r e is usually no distinction drawn

between equality and equivalence,

Whenever doing so Is necessary, we carefully

draw such a distinction. The s e q u e n c e type seq o f few special o p e r a t o r s , ~s empty and

to fetch

can be considered as a b u i l t - i n type that has a

Specifically, there must be a way to c h e c k if a s e q u e n c e ~tems from

a sequence.

Additionally.

there

must

be

o p e r a t o r s for adding and removing Items from a sequence, The ;mpiementatton defined types must have all the o p e r a t i o n s a p p r o p r i a t e to them as well as those described above for attributes and nodes.

4.8. Summa~' of Operators This section summarizes the operations described above. The operations on nodes are = c r e a t e a node; o fetch the value of an attribute of a given node; set the value of an attribute of a given node; ° c o m p a r e two nodes to see If they are the same node; and ,, assign a specific node to a variable, The o p e r a t o r s d e l i n e d for the iDL sequence type ( a n o r d e r e d |let of nodes of the same class)

are

c r e a t e a s e q u e n c e of a given type; select an e l e m e n t of a s e q u e n c e ; = add an e l e m e n t to a s e q u e n c e ;

1This distinction is addressed further In Section 3,9 on page 123,

Definition of the Diana Operations

Section 4 , 3 / Page 131

= remove an element from a sequence; ° compare two sequences to see If they are the same sequence; and ° assign a sequence to a variable of sequence type. The

operators

required for the

IDL scalar types

(Integer,

Rational,

and

Boolean) are ° create a scalar: ° compare two scalars scalar) ; and o assignment,

4.4.

to

see

If they

are

equal

(I.e..

the

same

General Method for Deriving a Package Specification for DIANA

To derive a general package specification for defining this abstract data type called DIANA, further decisions concerning the Implementation model need to be made.

For

objects.

example,

one

must

decide

how to

After these decisions have been made,

represent

the various

DIANA

a straightforward process can

be applied to derive the package specification from the DIANA domain.

A formal

method for specifying these decisions Is presented In the IDL formal description. Indeed,

an

IDL toot

would

produce

definition of DIANA In Chapter 2. following discussion is sufficient. The implementation First,

there are the

model

such For

a

the

package purposes

automatically from

the

of

the

this

document,

must deal with two separate areas of concern.

implementation restrictions imposed by the choice

source language that the DIANA type Is being Implemented In.

of the

Secondly, there Is

the choice of corresponding entities in the implementation language for entities in the DIANA domain ( I . e . ,

how DIANA objects are represented).

These decisions

can be driven by the design considerations of tools that expect to use the DIANA type, as well as by specific restrictions of the host system. The general steps are as follows: of IDL types. An Implementation for each of the IDL types must be chosen, Normally for the scalar types, the i m p l e m e n tation language supports an equivalent ( o r close enough) abstract type. For the sequence type and the Implementation defined types, the same decisions need to be made. and an abstract data type for these derived and specified. (The DIANA domain specification provides a handle on the abstract data types for the Implementation defined types, )

= representation

of node classes. 7he class names of the DIANA language must be handled by the package derivation process, because

= representation

D~ANA Reference Manual

Page 132 / Section 4 . 4

the types oi~ the attributes are defined using these mete-variables. representation of nodes. The node representation choice must permit attribute values to be associated with the node, since each specific Instance of a node may have different attribute values. method of defining operators. The operators in the language must be specified either as functions and procedures in the implementation language or by equating them to specific operations already In the implementation language.

4.5.

Deriving a SpectfJc ADA Package

To derive a specific ADA package, we apply the general method as outlined in the previous section,

First,

we choose an implementation model of an abstract

data type defined as a stngte package.

A single ADA private type is used to

define all nodes in the OIANA domain.

All operations are calls on procedures or

functions

Having

specified

In the

package.

made these

decisions,

we then

address the following points: , representation of /DL types. The 1DL ]~<>lean type could be I m p l e mented directly by the ADA BOOLEAN predeflned type. However, the IDL I n t e g e r and R a t i o n a l types would have to be represented s o m e how so as to be able to represent arbitrarily large quantities, and (in the case of rationals) to represent them exactly with no approximation2 Using the ADA predefined types INTEGER and FLOAT would not be adequate. For the sequence type Seq o f , we include a private type definition and primitive operations. The operations permit creation of an empty sequence ( M a k e ) , functions to add an element at the beginning (Insert) and end (Append) of a sequence, and functions for selecting the first element of a sequence (Head) and the remainder of a sequence (Tall). There is also a function to determine If a list Is empty (Is_Empty), Note that additional functions and procedures for this type could be added, :epresentatlon of node classes. Since a single type is being used to represent all nodes in the domain, the distinction between different classes is not necessary= representation of nodes, A slngte private type (called Tree) is provided for eH the node names defined tn the DIANA domain. An enumerated type (called Node_Name) is defined which provides a

2These requirements are spelled out in the Ads LRM, which requires that some arithmetic performed at compile time be done exactly,

Section 4 , 5 / Page 133

Definition of the Diana Operations

name for all the various nodes defined in the DIANA domain. An additional function (named Kind and returning a result of type Node_Name) Is added to the Tree type to distinguish between different node kinds, , method of defining operators. The create operator for the various nodes becomes a single function that takes a N o d e N a m e and returns a new Tree node with most of Its attributes not defined. Each of the DIANA attributes has a corresponding procedure and function in the package spectfloatl'on that respectively modify and fetch the value of an attribute. The procedure and function both take the specific Tree node as an argument. The procedure takes an additional argument which gives the new value for the attribute; the function returns the corresponding attribute value.

The comparison operators for the nodes and for sequences are the built-in ADA comparison operators ( ' = ' ,

'/=')

which are defined for private types,

The

comparison operators for the scalar types are not defined In this package.

The

AOA language provides all create operations for the scalar types. operators

are

private types.

the

pre-deflned

ADA assignment operators for

The assignment variables

of

the

Except for these assumptions on the use of built-In operations,

the full AOA package is given, A few facts are important: ° Because some of the words, we choose to (short for DIANA).

DIANA node types conflict with ADA reserved prefix all node_names with the prefix "dn_"

= Remember that this specification defines a minimal set of operations; Implementations may augment it with other useful ones for particular applications. = We have added an additional and functions (ARITY. Son1. In the ADA Formal Definition traversals essential to many tools.

4.6.

type (ARITIES) and several procedures Son2. and Son3) which are mentioned and which are very useful in the tree phases of compilers, as well as other

The DIANA Package in ADA

A summary of essential appears in Figure 4-1

points of the ADA package specification

on page

134.

For ease of understanding,

for

DIANA

the figure

contains only as much of the package as fits onto one page. The package defines and makes available the following types, functions, procedures:

and

Page

)34

/

Section

4,6

DIANA Reference Manual

Dia~+a is type Tree is private; type SEQ_TYPE is private; type N O D E N A M E

-- a Diana node -- sequence of nodes

is

-- enumeration class for node names -- about 160 different node types

); --- Tree constructors, function MAKE (c: In NODE_NAME) prooedttrQ DESTROY (t: in TREE);

return TREE;

function

return NODE~NAM~;

--

KIND

( t ~ in TREE)

Tree traversers from the Ada Formal Definition.

type ARITIES is (nullary, unary, binary, ternary, arbitrary); function function procedure function

ARITY SONI SON1 SON2

(t : (t, (t" (t: (t: (t~ (t:

procedure SON2 function SON3 procedure SON3

in

in in in in in in

TREE ) return TREE) return out TREE; v: in TREE); TREE) return out TREE; v: in TREE); TREE) return OUt TREE; V¼ i n TREE);

-- Handling of list const z-ache. function HEAD (I: in SEQ_TYPE) function TAIL ( I. in S~2_TYPE) function MAKE function func~n

function

IS_EMPTY (i~ in S E Q _ T ~ E ) INSERT (I: in out SEQ_TYPE; i: in T m ~ ) APPEND (i~ in out SEQ_TYPE; i' is TREE)

ARITIES; TREE~ TREE; TREE;

return TREE; -- LISP CAR return SEQ_TYPE; -- LISP CDR return SEQ_TYPE; -- return empty list return BOOLEAN; return SEQ_TYPE; -- inserts i at s t a r t of I SEQ_TYPE; inserts i at end of 1

-- Handling of LIST attribute of list constructs. procedure LIST (t: in out TREE; W in SEQ_TYPE); function LIST (%~ in TREE) retuxD SEQ_TYPE; -- Structural Attributes, procedure ~Z_ACTUAL function AS_ACTUAL

(t: in out TREE; v¼ in TREE); ( t. in TREE) return TREE ; -- assoc

-- followed by functions and procedures for about 100 attributes private -- To be £illed in°++

end Diana;

Figure 4 - t :

Sketch ol the DIANA Package

.....

Section 4 . 6 / Page ] $ 5

Definition of the Diana Operations

type TREE

An object structure,

of

this

private

type

is

a

node

of

the

DIANA

type SEQ_TYPE

An object of this private type is a sequence of nodes of the same class,

type NODE_NAME This Is an e n u m e r a t i o n type providing an e n u m e r a t i o n literal for each kind of DIANA node. function MAKE

This function creates and returns a DIANA node of the kind which is its a r g u m e n t . Note that it is o v e r l o a d e d so as also to be able to create an empty list.

p r o c e d u r e DESTROY This p r o c e d u r e indicates that a node Is no longer required. function KiND

Given a node,

type ARITtES

This e n u m e r a t i o n type provides a literal for each n u m b e r of structural children a node might have.

function SON k

For k = 1, 2, 3, offspring of a node.

p r o c e d u r e SON k

For k = 1, 2, 3, each such offspring of the node.

list processing

A collection of functions and usual l i s t - p r o c e s s i n g primitives.

attributes

For each possible attribute, there is a function to return the value of that attribute at a node, and a p r o c e d u r e to store a new v a l u e for the attribute,

A c o m p l e t e listing chapter.

this function returns Its n o d e - k i n d .

of the entire

each

such

function

returns

the

kth

procedure stores a new k th

procedures

DIANA package specification

implement

concludes

the

this

Page 336 / Section 4 . 6

DIANA Reference Manua~

w i t h USERPK; uBe USERPK~ -- Package USERPK provides the following items (see page 77 ): -- source_position ~ -- symbol~rep .~ value -

-

-- operator: -- number_rep z comments • -

-

Defines source position in original source program. Used for error messages. Representation of identifiers, strings and characters. ~mplementation defined. Gives value of an expression. Can indicate that no value is computed Enumeration type for all operators. Representation of numeric literals. Representation of comments from source program.

package Diana i8 type TREE is privabe; type SEQ_TYPE is private;

Definition of the Diana Operations

(

Section 4 . 6 / Page 137

NODENAME is

an_abort,

dn~accept, dn_aggregate, tin_allocator, tin_and_then, tin_assign, tin_attribute, tin_block, tin_choice s, dn_comp rep, tin_compilation, dn_const_id, tin_context, d~_de f_char, dn_de lay, dn_dsczm% id, dn_dscrt_range_s, dn_entry_id, tin_exception, dn_exp_s, dn_for, tin_formal float, tin_function_call, tin_generic assoc_s, dn_goto, dn_in, tin_in_out, tin_indexed, tin_integer, dn_labe l_id, dn_l_private, dn_name s, dn_named_stm_id, tin_null_access, tin_number, dn_or else, dn_out_id, tin_package id, dn_para~_s, dn_pragma_id, dn_pr irate %ype_id, dn procedure_ call, tin_range, tin_rename, dn_se lect, dn_se lected, dn_stm_s, dn_subprogram_bo~y, dn_subtype_id, dn_task_body_id, tin_terminate, dn_iTpe, dn_type_id, tin_universal_integer, tin_universal_real, drt_used_bitn_id, drt_used_bltn_op, dn_used_name_id, dn_used_ob ject_id, dn_var, dn_var_id, dn_var iant_Im%rt, dn_variant_s, rift_while, dn_with

dn_address, dn_all, dn_alternat ive_s, dn_array, dn_attr_id, tin_binary, dn_case, dn_comp_id, dn_comp unit, dn_cond_entry, tin_constrained, dn_decl_s, dn_de letted_constant, dn_dscrmt_aggregate, dn_dacrmt vat e, tin_entry_call, dn_enum_literal_s, tin_exit, tin_float, dn_forma~_fixed, tin_function, dn_generic, dn_generic_param_s, dn_if, drt_in_op, rift.index, dn_instant iation, dn_iteration_id, dn_loop, dn_3membership, dnu named_sire, tin_not_in, dn_null_stm, dn_numeric literal, tin_out, tin_package_dec i, dn_param_assoc_e, dn_pragma, dn_private, tin_procedure, dn_raise, dn_recor~_rep, dn_reverse, dn_select_clauee_s, drt_slice, dn_stub, d~_subtype, tin_task_body, dn_task_spec,

);

d~t_access, dn_alig nment, tin_alternative, dn_argument_id, dn_assoc, tin_attribute_call,

dn_box, dn_code, dn_comp_rep s, dn_cond_ clause, tin_constant, tin_conversion, dn_def_op, tin_derived, dn_dscrmt_var, d~_entry, dn_enua_id, tin_exceptiort_id, dn_f~ xed, dn_formal_dscrt, dn~formal_integer, dn_ funct ion_id, dn_generic id, dn_id_s, dn_in_id, d~_i~_out_id, tin_inner_record, drt_iten1_s, tin_labeled, dn_l_private_type_id, tin_named, tin_no_defau It, dn_null_comp, dn_number_id, dn_others, dn./>ackage_body, rift_package spec, rift_parenthesized, dn_pragma_s, dn_proc_id, dn_qualified, tin_record, dn_return, dn_se lect_clause, dn_simple_rep, dn_strin~_litera 1, dn_subprogram_decl, dn_subunit, dn_task_decl, dn_timed_entry, tin_universal_fixed, dn_use, rift_used_char,

dn_use~_op, dn_variant, tin_void,

Page 138 / Section 4.6

DIANA Reference Manual

Tree oonstructors. function MAKE procedure DESTROY function KIND Tree traversers

AR~TY SON1 ~Nl SON2 SON2 SON3 SON3

return NODE NAME;

from the Ada Formal Definition.

type ARITIES is (nullary, function function procedure £tu~t ion proQe~Mze function pzooedure

return TREEj

( c: in NODE_NAME) ( ~ z in TREE)I ( h : in TREE)

(t: (t: (t: (t: (t: (t: (t:

in in in in in in in

unary, binary,

ternary,

TREE) TREE) out TREE; v: in T~.) out TREE; v : i n TREE) o~t TREE; v: in

return return I~EE); return TRKE); return TREE);

arbitrary); ARITIES; TNME; '],~:Z; TREE;

-- Handling of list constructs. function function function

HEAD TAIL MAKE

fume/on ~ n

IS_EMPTY (i: in SEQ_TYPE) INSERT (i: in out SEQ_TYPE; i: in TREE)

function

(i. in SEQ_TYPE) ( I: in SEQ TYPZ)

APPEND ( 1: in out SEQ_TYPE; i: in TREE )

return TREE; -- LISP CAR return SEQ_TYPE; -- LISP CDR return SEQ_TYPE; -- return empty list return BOOLEAN; return SEQ_TYPE; -- inserts i at start of I return SEQ._TYPE; -- inserts i at end of 1

Definition

of the

Diana Operations

Section

4.6

1 Page

139

-- H a n d l i n g o f L I S T attribute o f list consLructs. procedure function

LIST LIST

(t: i n o u t TREE; v: i n SEQ_TYPE); (t: i n T R E E ) r e t u r n SEQ_TYPE; aggregate has Seq Of -- a l t e r n a t i v e s has Seq Of -- choices has Seq Of -- compilation has Seq of --- c c m ~ _ r e p _ s has Seq of -- context has Seq Of -- decl_s has Seq of d s c r m t aggregate has Seq Of dscrt_range_s has Seq Of enu~_literal_s has Seq of -- exp_s has Seq Of generic_assoc_s has Seq Of - generic_param_s has Seq Of - - id s has Seq of -- if has Seq of inner_record has Seq Of ~-~ item_s has Seq of name_s has Seq of --- p a r a m ~ a s s o c s has Seq Of param_s has Seq Of - - pragn~3._id has Seq Of pragm~_s has Seq Of h a s Seq O£ -- record -- select_clause_s has Seq Of - - stm_s has Seq of use has Seq Of --- v a r i a n t _ s has Seq of -- v a r _ s has Seq of --- w i t h has Seq of - -

- -

- - -

- -

- -

- -

- -

- -

--

COMP ASSOC ALTERNATIVE CHOICE COMP_E~IT COMP_REP CONTEA~ ELEM DECL COMP_ASSOC DSCRT RANGE ENUM_LITEPJ~L EXP GENERIC_ASSOC GENERIC_PARAM ID COND CLAUSE CoMP Iq'EM NAME PARAM~ASSOC PARAM ARGUMENT PRAGMA CoMP SELECT_CLAtL~E STM NAME VARIANT VAR NAME

- - S t r u c t u r a l Attributes. procedure AS_ACTUAL function A S ~ p r o c e d u r e AS_ALIGNMENT function AS_ALIGNMENT p r o c e d u r e A S _ A L T E R N A T IVE_S function AS_ALTERNATIVE_S

( t : i n o u t TREE; v: ( t : i n TREE) return ( t : i n o u t TREE; v; ( t : i n TREE) return ( t : i n o u t TREE; v:

~¢~oeclure A S _ B INARY_OP function AS_BINARY_OP AS_~L0CK~STUS

in T ~ ) ; T R E E ; -- a s s o c i n TREE); TREE ; -- r e c o r d _ r e p in TREE); (t: in T R E E ) r e t u r n T R E E ; -- case - -

function

ASBLOCK_STUB

(t: (t. (t: (t:

function

AS_CHOICE S AS CHOICE S

(t: i n (t. i n

AS_CO~_REP S AS_COMP_REP_S AS CONSTP~t~ZD AS_CONSTRAINED

(t: i n (t. i n

b ] o c ~

in TREE; v: in TREE) xe£urn i n o u t TREE; v : in TREE) zeturn

i n TREE); TREE ; -- binary i n TREE); TREE ; -- package_body [ -- t a s k _ b o d y ] -- s u b p r o g r a m _ b o d y o u t TREE; v: i n TREE); TREE) ~Lurn TREE ; -- alternative I named -- v a r i a n t o u t TREE; v : i n TREE); TREE) ~eLurn TREE ; -- record_rep o u t TREE; v. i n TREE); T R E E ) zet-urn T R E E ; - - a c c e s s l d e r i v e d --array I subtype

o u t

- -

fu.ction function

AS_CONSTRAINT function AS_CONSTRAINT procedure A S _ ~ function AS_CONTEXT

(t:

in

(t: i n (t: (t: (t: (t:

in in in in

o u t TREE; v : i n TREE); TREE) return TREE ; -- constrained o u t TREE; v: i n TREE); TREE) return TREE ; -- comp_unit

Page 140 1 S e c t i o n 4 . 8

~x~K]ure function procedure function function ~3edure function procedure function procedure function function

DIANA Reference

AS_DECL S AS_DECL_S AS_DECL_SI AS_DECL_SI AS DECL_S2 AS_DECL_S2 ASDESIGNATOR AS_DESIGNATOR

(t: (t : ( t: ( t:
AS_DESIGNATOR_CY~R AS DESIGNATOR_CHAR AS_DSCRMT VAK_S AS_DSCRMT VAK_S AS DSCRT_RANGE AS_DSCRT RANGE

(t : (t : (t: (t, ( t. {t :

procedure function ~xmx~%tre function

Manual

out TREE; v: in TREE); TREE) return TREE ; -- task spec TREE; v: in TREE); TREE) l-et-ur. TREE ; -- package spec out TREE; v: in TREE); TREE) return TREE ; -- package_spec out TREE; v: in TREE); TREE ) return TREE ; - - subprogram_body -- subprogram_decl --assoc I generic in TREE); in out TREE; v: TREE ; selected TREE) return in in out TREE; v: in TREE); in TREE) retur. TREE ; - - t y p e in out TREE; v: in TREE); I reverse in TREE) return TREE ; - - f o r -slice in out TREE; v: in T ~ E ) ; in TREE) retur. TREE ; -- array in out TREE; v: in TREE); in TREE} zetur. TREE ; -- entry in out TREE; v: in TREE); in TREE ) ~eLurn TREE ; - - exception i n ou~ TREE; v: in TREE); I case ret.zn TREE ; - - d e l a y in ~ ) - - f i x e d I float - - m e m b e r s h i p | while --address I assign --code I conversion - - n a m e d I number -- qualified -simple_rep - - u n a r y I comp_rep -- parenthesized in out TREE; v: in TREE); TREE ; - - b i n a r y I range in TPZE) ~ in out TREE; v: in TREE); in ~ Z Z ) retUr. TREE ; - - range -- binary in out TREE; v: in

in in in in in in in in

AS_DSCRT_RANGE S AS DSCRT RANGE_S AS DSCRT RANGE VOID AS DSCRT RANGE_VOID AS~ION_D~ function AS_EXCEPTION_DEF p r o c e d u r e AS EXP function AS~EXP

{t: ( t: ( t: (t: (t: (t: (t: (t:

procedure function procedure function

AS_2XPI AS_EXPl AS_EXP2 AS_EXP2

(t: (t: (t: (t:

procedure TREE); function procedure function

A S _ E X P CONSTRAINED

(t:

AS_EXP C O N S ~ N E D AS_EXP_S AS EXP_S

{ t: in TREE) zeturn TREE ; - - allocator (t: in out TREE; v: in TREE); (t: in TREE ) return TREE ; - - indexed -- attribute_call (t: in out TREE; v : in TREE); TREE ; -- return return (t: in T R E E ) -- tonal_clause -- in I in_out I exit --out I record rep

fIamctio~

AS_EKP VOID AS_/DfP VOID

Section 4.6 / Page 141

Definition of the Diana Operations

p r o c e d u r e AS_HEADER function AS_HEADER

(t: (t: (t: (t. (t: (t: (t: (h :

~rocedure AS_ID function AS_ID

(t: i n O ~ t TREE; v: (t: i n TREE) r e t u r n

p r o c e d u r e A S _ I D_S function AS_ID_S

( t : i n o u t TREE; v : (t: i n TREE) r e t u r n

procedure function procedure function procedure function

function l~rocedure function ~rocedure function function

AS_GENERIC_ASS0C_S AS_GENERIC_ASSOC_S ASGENERIC_HEADER AS GENERIC_HEADER AS_GENERIC_PAP/%M_S AS GENERIC PARAM_S

AS_ITEM S AS_ITEMS AS_ITERATION AS ITERATION AS_MEMBERSHIP_OP AS_MEMBERSHIP_OP AS_NAME AS_NAME

(t: (t: (t. (t: (t: (t: (t.' (t:

in in in in in in in in

in in in in in in in in

o u t TREE; v: TREE) r e t u r n o u t TREE; v: TREE) return o u t TREE; v: TREE) ret~-'n O U t TREE; v: TREE ) r e t u r n

o u t TREE; v: TREE) return o u t TREE; v: TREE) r e t u r n o u t TREE; v : TREE) return o u t TREE; v: TREE) r e t u r n

i n TREE); T R E E ; -- i n s h a n h i a t i o n i n TREE); TREE ; -- generic i n TREE); TREE ; -- generic i n TREE); T R E E ; -- s u b p r o g r a m _ b o d y -- subprogram_decl i n TREE); T R E E ; - - for I a t t r i b u t e labeled i r e v e r s e -- n a m e d _ s t m -- p a c k a g e _ b o d y -- p a c k a g e d e c 1 -- subtype -- t a s k _ b o d y -- v a r i a n t _ p a r t --type I task_decl -- p r a g m a i n TREE); TREE ; -- exception --number I constant -- in I in_out .... o u t i v a r in TREE); TREE ; -- block i n TREE); TREE ; -- loop i n TREE); TREE ; -- membership i n TREE); T R E E ; - - accept | a d d r e s s -- procedure_call - - a l l I comp rep -- constrained -- indexed -- ins h a n h i a t i o n --goto I index -- qualified -- s e l e c t e d - - r e n a m e I slice variant_part M attribute_call -entry_call -- record_rep -allocator -assign --attribute | code -- conversion -- function_call --. s i m p l e rep subunit

Page ]42 / Seclion 4.

DIANA Reference

p r o c e d u r e AS_~NAME_S AS_NAME_S funchion

(t: in (MXt TREE; V: in TREE); (t: in TREE) return TREE ;

procedure function procedure futw2tion ~z)oe~ttre fu~ction procedure function

(t: (t: (t" (t: (t: t: (t: {t:

AS_~AME VOID AS_NAME_ VOID AS_OBJECT_DEF AS OBJECT DEF A S PAC~KAGE_DEF A S JPACKAGE_DEF ASJARAM ASSOC_S AS_PAPmM ASSOC_S

pzoceaure AS P A ~ _ S function

AS_p~w/e~ S

function function

AS_PRAGMA_S AS_I~ AS_RANGE

procedure function procedure function pin0(~ure function

AS_RANGE_VOID AS_RANGE_VOID ASRECORD AS RECOt~D AS_SELECT CLAUSE_S AS_SELECT CLAUSE_S

As ~ A G M A _ S

p r o c e m = ~ AS_STM function

AS STM

function

AS_STM_S

AS_ST~_S

procedure AS_STM_SI funchion AS_STM_S i

in in in in in in in in

(t~ i n (t: i n (t: in (t : in (t: in (t : in (t: (t: (t: (t : (t: (t. (t: (t:

in in in in in in in in

(t: in (t : in

(t: in ( t. i n

procedure AS_STM_SZ

(t: in

funchion

(t: in

AS_STM_S2

~roo~lure flmction p ~ function

AS~SUBPROGRAM_DEF AS_SUBPROGRAM_DEF AS SUBUNIT_BODY AS_SUBUNIT_BODY AS_TASK~DEF function AS_TASK_DEF proceauze AS ~E ~%N~ function ASTYPE_RANGE p~.~cedure A S TYPE SPEC ~ o n AS_TYPE_SPEC

procedure AS_UNIT_BODY function AS_UNIT_BODY

As V A ~ A N T _ S function

AS_VARIANT_S

(t:

in

Manual

abort w i t h I use

o u t TREE; v: TREE) return OUt TREE; V: TREE) r e t u r ~ o u t TREE; v. TREE) return out TREE; v: TREE) return

i n TREE); TREE ; raise | exit in TREE); TREE ; - - constant I v a t in TREE); TREE ; --- p a c k a g e _ d e c l in TREE); TREE ; - - p r o o e d u r e _ c a l l -- e n t r y _ c a l l -- pragma -- f u n c t i o n _ c a l l out TREE; v: in TREE); TREE) ~ t u z n TREE ~ - - p r o c ~ u r e -- function --entry I accept O~rh TREE; V: in TREE); T R E E ) return T R E E ; --- c o m p _ u n i t o u t TREE; v: in TREE); TREE ) retul~ TREE ; - - i n t e g e r -- c o m p _ r e p out TREE; v: in TREE); TREE) return TREE ; --- fixed I float o u t TREE; V: i n TREE); TREE) r e t u r n TREE ; --- v a r i a n t out TREE; v: in TREE); TREE) return TREE ; - - select o u t TREE; v : in TREE); TREE) return TREE ; - - l a b e l e d -- n a m e d s t m o u t TREE; v: in TREE); TREE ) r e t u r n TREE ; - - a l t e r n a t i v e -- c o n d _ c l a u s e -- loop I select accept | block o u t TREE; V: i n TREE); TREE ) return TREE ; - - c o n d _ e n t r y -- t i m e d e n t r y o u t TREE; V: in TREE); TREE) return TREE ; --- c o n d _ e n t r y timed_entry OUt

TREE;

v.

in T R E E b TREE ; --- subprogran~_decl

(t. in o u t TREE; v : in TREE); (t. in TREE) return TREE ; - - s u b u n i t (t: i n o u t TREE; V: in TREE);

(t: (t: (t: (t: (t:

in in in in in

TREE) z e t u z n out TREE; v: TREE) return o u t TREE; v: TREE) ze~Jra

(t: (t: (t: (t :

in in in in

o u t TREE; v: TREE) z~turn o u t TREE; v: TREE ) return

TREE ; ~ task_decl in TREE); TREE ; - - m e m b e r s h i p

in TREE); TREE

; c o n s t a n t I in - - i n out I out -- vat -- type i n TREE); TREE ; - - c o m p _ u n i t i n TREE); TREE ; -- v a r i a n t _ p a r t

Section 4 . 6 / Page 143

Definition of the Diana Operations

-- Lexicai Attributes. procedure function procedure function procedure function prooedure function procedure function

LX_COMMENTS LX_COMMENTS LX_DEFAULT LM~_DEFAULT LX_NUM~P LK._NUMREP LX_PREF IX LX_PREF IX LX_SRCPOS LX_SRCPOS

(t: ( t: (t: (t: (t: (t: (t: (E: (t: (t: (t: ( t:

procedure LX_SYM~2 function

LX_SYMREP

in in in in in in in in in in in in

out TREE; v: TREE ) return out TP~E; v: TREE) return OUt TREE; V: TREE.) return OUt TREE; v: TREE) r e t u r n out TREE; v: TREE) return out TREE; v: TREE) return

comments); comments ; Boolean); Boolean; number_rep); number_rep ; Boolean); Boolean; source_pos~t~on); source_position ; symbol_rep); symbol_rep ;

--. Semantic Attributes. procedure SM_ACTUAL_DELTA function SM_ACTUAL_DELTA procedure SM_ADDRESS function

SM~ ADDRESS

prooedure SM_BASE_TYPE funchion

SM_BASE_TYPE

~xxmM~s/re SMA_BITS function SM_BITS prooedum~ SM_BODY

function

SM_BOD¥

(t: in out TREE; v: Float); (t: in TREE) return Float; (t: in out TREE; v: in TREE); -- v: EXP_VOID (t: in TREE) return TREE ; -- returns EXP_VOID (t: in out TREE; v: in TREE); -v: TYPE_SPEC (t: in TREE) return TREE ; -returns TYPE SPEC (t: in out TREE; v: Integer); (t: in TREE) return Integer; (t: in out TREE; v: in TREE); -v: SUBP_BODY_DESC, -PACK_BODY_DESC, -BLOCK_STUB_VOID

(t. in TREE)

zetur. TREE ; --

--~ooedurQ

SM_COMP_SPEC

(t. in out TREE;

SN~COMP_SPEC

(t:

returns SUBP_BODY_DESC, PACK_BODY_DESC, BLOCK_STUB_VOID v: in

TREE); function

in TREE) return TREE ; (t: in out TREE; v : i n TREE); -v: CONSTRAINT fu.ction SM_CONSTRAINT (t. in TREE) r e t u r n TREE ; -returns CONSTRAINT precem=. SM_CONTRDLLED ( t: in out TREE; v: Boolean); SM_CONTROLLED ( t: in TREE) return Boolean ; m x ~ e a u ~ SM_DECL_S (t: in out TREE; v: in TREE); -- v: DECL_S function SM_DECL_S ( t: in TREE) return TREE ; -- returns DECL_S ~aure TREE; v: in TREE); SM_DEFN (t, in v : DEFOCCURRENCE function SM_DEFN (t: in TREE) r e t - u r n ' l g , EE ; returns DEF_OCCURRENCE SM_DI SCRI MINANTS ( t : in out TREE; v: in TREE); -v: VAK_S function SM_DISCRIMINANTS ( t : in TREE) L~=Lurn TREE ; -- returns VAR_S SM_EXCEPTION DEF (t: in out TREE; v: in TREE); V : EXEEPTION_DEF function SM_EXCEPTION_DEF (t : i n T ~ ) zetuzn TREE ; -- returns EXEEPTION_DEF proc~ure SM_EXP_TYPE ( t: in out TREE; v: in TREE); -- v: TYPE_SPEC function SM_EXP_TYPE ( t: in TREE ) return TREE ; -- returns TYPE_SPEC ~ o c ~ u r e SM_FIRST ( t: in out TREE; v: in TREE); -- v: DEF_OCCDRR SM_FIRST ( t: in TREE ) return TREE; -- returns DEF_OCCURR

mx~ea.re SM_CONSTRAINT

-

Page ] 4 4 / Section 4+0

~/oosdure

DIANA Reference Manua[

SM_GENE~C_P~M_S(

t

+

i n o u t TREE;

v: i n TREE);

v: GENERIC_PARAM~_S TREE; -- r e t u r n s G E N E R I C _ P A R A M _ S SM_INIT_EXP ( t : i n o ~ t TREE; V: E X P _ V O I D v: i n TREE); function returns E X P _ V O I D SM_INIT_EXP ( t: in TREE ) ~ e ~ u r n T R E E ; S M ~ L O C A T ION ( t : i n o u t TREE; v: i n TREE); -v: L O C A T I O N --- returns L O C A T I O N function SM LOCATION (t : i n T R E E ) r e t u r n T R E E ; v.~ i n TREE); -v: E X ~ _ S SM NORMALIZED_PARAM_S (t:TREE; function SM_NO~U~LI Z E D ~ P A R A M ~ S (t: i n TREE) r e t u r n T R E E ; --- returns E X P _ S v: i n TREE); - - v: O B J E C T _ D E F SM_OBJ_DEF ( t: in otrt ~ ; returns oBJEC~_DEF return TREE ; function SM_OBJ DEP (t : i n T R E E ) (t: i n o u t TREE; v: in TREE); --- v: T Y P E _ S P E C procedure SM_OBJ_TYPE returns T Y P E _ S P E C SM_OBJ_TYPE (t: i n TREE) return TREE ; function SM_OPERATOR (t: in o u t TREE; v: operator); pr~ku~e SM_OPERATOR (t. i n T R E E ) return operator ; function SM_PACKING (t: in ourt TREE; v: Boolean); ( t : in TREE ) r e t u r n B o o l e a n ; SM~PACKING function SMPOS (t: in o u t TREE; v: Integer); SM~POS (t: i n TREE) return Integer ; function SM_P~P (t: i n o u t TREE; v: Integer); SMREP (t : i n TREE) return Integer ; function SM_SIZE (t: i n O u ~ TREE; v: i n TREE); -v: E X P _ V O I D returns EXP V O I D SM_SIZE (t: i n TREE) return TREE t function procedure SM_SPEC (t: in out TREE; v: in TREE); -- V: H E A D E R -GENERIC_HEADER, -PACK_SPEC (t:TREE) r e t u r n T R E E ; - - returns H E A D E R f~M2~iion S M _ S P E C -- GENERIC_HEADER, -- P A C K _ S P E C (t: i n o u t TREE; v: in TREE); -v: STM, L O O P p r o c e d u r e SM~_STM SM_STM (t: i n TREE) return TREE ; --- returns STM, L O O P function (t: i n o u t TREE; v: i n TREE); -v: E X P _ V O I D p r o o ~ u ~ SM STORAGE_SIZE returns E X P _ V O I D S M _ S T O R A G E SIZE (t: in TREE) retzu~ TREE ; function ~ u ~ SM_STUB (t: i n o u t TREE; V: i n TREE); SM~STUB ( t : in TREE ) r e t u r n T R E E ; function v: T Y P E _ S P E C SM_TYPE_SPEC (t. i n o u t TREE; v: i n TREE); SM TYPE_SPEC ( t : in TREE) r e t u r n T R E E ; - - returns T Y P E _ S P E C function SM TYPE_STRUCT (t: i n o u t TREE; v: i n TREE); - - v: T Y P E _ S P E C SM_TYPE_STRUCT (t: i n T R E E ) r e t u r n T R E E ; - - returns T Y P E _ S P E C function SM~VALUE (t: i n o u t TREE; v: value); ~ure SM_VALUE (t: i n T R E E ) r e t u r n v a l u e ; function

function

SM_GENERIC_PARAM_S(t

+

in T R E E )

re~rn

-

-

-

-

-

-

-

-

-

-

-

-

-

-- C o d e Attribute. procedure CD_IMPL_SIZE function C D IMPL SIZE private -- T o b e filled in..+ e n d Diana;

(t: in o u t TREE; v: Integer); (£: in TREE) r e t u r n integer ;

-

Page 145

External Representation of DIANA CHAPTER 5 EXTERNAL REPRESENTATION

OF DIANA

This chapter describes how a DIANA tree may be represented In ASCII for communication between different computing systems. mal:

The presentation is infor-

for a detailed discussion of the Issues Involved, see Chapter 4 of the IOL

Reference

Manual [g].

Although

any

conforming

implementation of

DIANA IS

required to be able to map to a n d / o r from this external representation of DIANA, other internal

representations are

(non-conforming)

permitted.

between tools on a single computing system. defined

to

assist

Indeed,

we expect these

latter

representations to be the preferred means of communication debugging

and

to

The standard external form

allow communication

between

Is

computing

systems, not as the typical communication between tools. The design of this external representation was guided by three principles: o There must be a relatively straightforward way of deducing the external representation from the DIANA specification of Chapter 2, - The external representation must not unduly constrain the I m p l e m e n tation options outlined tn Chapter 6, ° It must be possible to map between the external representation and a variety of internal representations in a reasonably efficient manner. We expect that each Installation that wishes to communicate with others via an ASCtl representation of DIANA will create a r e a d e r / w r i t e r utility to map between the external representation and whatdver Internal representations are in use at the Installation, The external representation Is described In Figure 5-1 the usual sort of recurslve construction.

on page 146.

It Is

Note that square brackets [ . . . ]

sur-

round the attributes of a node and angle brackets <., ,> surround Items of a sequence, We Illustrate the external representation using the IDL example from Section 1.4, 1.

repeated here as Figure 5 - 2 on page 147.

From this example, nodes

plus. leaf. and tree might be represented externally as follows: plus

-- a node w i t h no attributes

l e a f [ name "A"; s r c representation_of_source_position ] - - l e a f Eor A tree [ left leaf [name "A"]~ right leaf [name "B"]t o p plus] - - A + B

Page t 4 6 I Section 5

DIANA Reference Manual

~EFINITION OF

EXTERNAL ]~)iANA

node

represented by the name of its type, followed by "[', followed by the representation of its attributes (separated by s e m i c o l o n s ) . followed by "]', if there are no attributes, the "[ ]' may be omitted.

attribute

represented by the name of the attribute, representation of the vaiue of the attribute.

comment

start wlth double hyphen ~Ine.

('--');

followed

by

the

terminate with the end of the

REPRESENTATION OF BA,~C TYPES Boolean

represented by the tokens ,z~rJE and FALSE.

Integer

represented by a sequence of digits with an optional sign. value is interpreted as being a decimal Integer.

Rational

represented as a decimal or based number (in the ADA sense and using the AOA syntax), or as the quotient of two unsigned ~ntegers, decimal numbers, or based numbers.

String

represented as the sequence of ASCII characters representing the vatue of the string, surrounded by double quotes. Any quotes within the string must be doubled. The nonprlnttng ASCII characters are represented as in ADA.

The

Sequence represented by a sequence of representations for individual values of the sequence, separated by spaces, and surrounded by angle brackets ( " ' ) . Private types are provided by the structure definition. For our purposes, the external representations of the private types used in DIANA are provided in a refinement of the DIANA abstract structure.

Spaces are not significant except to separate tokens. Case distinctions between identifiers (such as node names) are significant, as In IDL,

Figure 5-1:

External DIANA Form

Section 5 / Page 147

External Representation of DIANA

Note that no representation is shown for the value of the attribute s r c , the

private t y p e Source_Position;

this

point is addressed further

which is

below.

Note

also that,

because these examples show external DIANA which is expected to be

ASCIi text.

the usual typographic conventions for node names and attributes are

not followed In them.

Structure

ExpressionTree

R o o t E X P Is

- - F i r s t w e d e f i n e a p r i v a t e type. T y p e Source_Position;

- - N e x t w e d e f i n e t h e n o t i o n o f a n expression, EXP

::=

leaf

EXP.

I tree ;

- - N e x t w e d e f i n e t h e nodes a n d t h e i r attributes. tree tree leaf

-----

,,> => => m>

op: OPERATOR, left: E X P , src: S o u r c e _ P o s i t i o n ; name: String ; st'c: S o u r c e P ~ i t i o n ;

right: ~

;

F i n a l l y w e d e f i n e the n o t i o n o f a n O P E R A T O R as t h e u n i o n o f a c o l l e c t i o n o f nodes; t h e n u l l => p r o d u c t i o n s are needed to define the node types since n o d e t y p e n a m e s a r e n e v e r i m p l i c i t l y defined.

OPERATOR p l u s ->

: :-

;

plus

I Rinus

m.~um => ;

I times

I divide

;

t:i.al~ -> ; dLividle =,> ;

End

Figure 5 - 2 :

Example ExpresatonTree of IDL Notation

The external representation also provides a means for s h a r i n g attribute values between nodes.

This fact does

not necessarily imply that the c o r r e s p o n d i n g

Internal r e p r e s e n t a t i o n is shared: for some attributes, the sharing in the external representation

can

be viewed simply

as

a technique

for

compressing

space.

Page ] 4 8 / Section 5

However.

any

DIANA Reference Manual

attribute

value

which

~s

represented externally in shared form.

inherently

shared

must

internally I

be

All of the t r e e - v a l u e d attributes of OIANA

fall in this category. ~n o r d e r for an attribute value to be shared ~n the external representation, of the value must be labeled and atl other o c c u r r e n c e s

one o c c u r r e n c e

refer to that labet.

Any attribute value may be labeled,

including

The labeled o c c u r r e n c e of the value is represented in a n o r m a l way,

attributes.

except that it is preceded by a label identifier and a colon ( " : ' ) . reference

consists of the label identifier followed by a caret

the usual representation of the attribute value. of letters,

must

node-valued

digits,

rather than

A label identifier Is a sequence

and isolated u n d e r s c o r e s starting,

tions a m o n g the letters are significant.

Each label

('"),

with a letter;

case d i s t i n c -

For example, the tree for A+A could be

represented in any one of the following four ways ( a m o n g o t h e r s ) : tree [ left leaf [ name "A"]; op plus; right leaf [ name "A" ] ] tree [ left leaf [ name y: "A" ]; op plus; right leaf [ name y^ ] ] tree [ left

x.leaf [ name "A"]; op plus; right x ^ ]

tree [ left x"; op plus; right x=leaf [ name "A" ] ]

Additionally, nested

a n o d e - v a l u e d attribute can be written free standing without being

within

some

other

node.

For

example,

a fifth

r e p r e s e n t a t i o n for

the

preceding e x a m p l e is tree [ left x^; op plus; right x ~ ] x. leaf [ name "A" ]

Note that in these examples we have consistently avoided giving a r e p r e s e n tation for the source position attributes.

Recall that source position is a private

type whose r e p r e s e n t a t i o n must be supplied as part of the structure definition or a r e f i n e m e n t of the structure. use the r e p r e s e n t a t i o n defined page 28,

One way to represent the source

position is to

in the example refinement in Section

repeated here for c o n v e n i e n c e in Figure 5 - 3 on page 149.

external f o r m .

1.4.3

on

Using this

a source position might be represented using the node structure:

leaf [ name "&"; src source_position [ file-<user>test.ada"

;

line 3 ;

char 15 ]

]

1The phrase "inherently shared internally' is intentionally loose. We believe that the phrase captures the essence of the situations where it is convenient to use sharing in the external representation. For a complete discussion of this issue, see the IDL Reference Manual.

Section 5 / Page 149

External Representation of DIANA

Structure AnotherTree Renames ExpressionTree Is -- first the internal representation of Source_Position For S o u r c e P o s i t i o n

Use Source_Package;

-- next the external representation of Source_Position -- is given by a new node type, source_external_rep For Source_Position Use External souroe_external_rep; -- finally, we define the node type s o u r o e _ e x t e ~

file line char

s o u r c e _ e x t e r n a l _ r e p =>

: String, : Integer, : Integer;

End Example AnotherTree of IDL

Figure 5-3:

Alternatively,

a specification could define the source position to be represented

externally as a string: leaf [ name "A"; src "<user>test.ads/15/3"]

Each of these same

particular external representations in some sense

information

in

that

either

one

representation by the reader utility. for

communicating

packages to external form. are

possible,

between

allow such Of course,

the

could

be mapped to the

contains the same

internal

Each installation must establish conventions reader/writer

user-supplied types to

utility

and

its

be mapped to

user-supplied and

from

the

other representations for the source position attribute

many containing

quite different information.

A

more

complete

treatment ol the external representation of private types may be found in the IDL Reference Manual. The refinement of the DIANA structure defines the external representation for private types, symbol_rep, number_rap, operator, and v a l u e . Types 8ymbol_rep, and number_rap are represented as strings externally, and operator four

Is represented by an enumeration type. The type symbol..Iep is a string that contains the source identifiers,

representation of

The type symbol_rap also represents character llterals,

which are

distinguished from other identifiers by surrounding the character with single q u o t e

Page ] 5 0 / Section 5 marks,

as in AOA,

case c h a r a c t e r s : basic c h a r a c t e r preserve the

DIANA Reference Manual

An ~mp~ementation must decide how to treat upper and fower It can

set,

case

normalize the representations of Identifiers to use the

all ~ower case letters changed to upper case. used

In the source,

so that source

can

or

it can

be reconstructed

accurately. The

type

number._rep

n u m e r i c titerals,

is

a

string

that

has

the

source

representation

of

An implementation may choose to normalize numeric_literala by

removing u n d e r s c o r e s . The type operator is

represented

by an e n u m e r a t i o n type.

DIANA specification a minimum e n u m e r a t i o n set ts given;

In the refined

It may be expanded by

an i m p l e m e n t a t i o n to include any other built-in subprograms. The ~ p e vatue is represented as an integer or rattona! type if a value has been c o m p u t e d , not yet been

or with a distinguishing node for the cases where the value has

computed.

A representation for ADA strings

and arrays is also

provided: a s e q u e n c e o4 values. A c o m p t e t e external representation starts with an indication of the root node of

the

corresponding

structure,

r e p r e s e n t a t i o n s of nodes.

followed

by

a

sequence

of

zero

or

more

The root indication can be either a tabei r e t e r e n c i n g

a node e l s e w h e r e in the external representation or the root node itself.

Since

the representstfon o4 subnodes can be contained within the representation of the parent n o d e ,

it is posslbte for the entire external representation to be given by

the root (a c o m p i l a t i o n node tn D~ANA).

it iS permissible, on the other hand,

to

represent the DIANA tree In a flat form,

where n o d e - v a l u e d attributes are always

r e p r e s e n t e d by labels referencing n o n - n e s t e d representations of the nodes. Following are two examples, fragment amples,

is followed

both in fiat form.

by the external form

like the figures in Chapter 3,

omitted for expository c o n v e n i e n c e ,

of the

in each case a short ADA DIANA,

Note that these e x -

are incomplete in that s o m e attributes are

External R e p r e s e n t a t i o n of DIANA

--

Section 5 / Page 151

F r o m p a c k a g e STANDARD ( s o r t of)

type BOOLEAN iS (FALSE, TRUE); type INTEGER is r a n g e MtN_INT . .

PD0:

type

PD1 : t y p e _ i d

MAX INT;

[ as_ld P D ] " : a s _ v a t s PD2" ; a s _ t y p e _ s p e c PD3" ] [ Ix s y m r e p "BOOLEAN" ; s i n _ t y p e spec PD3* ] [ as_list < > ]

PD2:

var._s

PD3:

e n u m literal_s

[ as_list < P D 4 " P D 5 " sin_size void ]

PD4:

enum_ld

[ Ix_symrep "FALSE" ; s m _ o b j _ t y p e PD3" ; sm rep 0 ; sm_pos 0 ]

PD5:

enum_id

[ Ix_symrep "TRUE" • s m _ o b j _ t y p e PD3" ; sm_rep t ; sm_pos 1 ]

PD6:

type,

[ as_ld PD8" : a s _ v a r _ s PDT" : a s _ t y p e _ s p e c PDg" ]

PDT:

var_s

[ as_list ( >

PDS:

type_ld

[

PD9:

integer

[ a s _ r a n g e PD10" ; s m _ t y p e _ s t r u c t PD9" sin_size void ]

PD]0:

range

PD] 1: u s e d _ o b j e c t _ i d

PD12:

used_object_ld

>

J

Ix_symrep "INTEGER" : s m _ t y p e _ s p e c PDg" J :

[ a s _ e x p l PD11" ; a s _ e x p 2 PD12" : s i n _ b a s e _ t y p e PD9" ] [ I x _ s y m r e p "MIN_INT" ; sm_defn xxx" ; sin_value xxx" : s m _ e x p _ t y p e PDg" ] [ Ix_.symrep "MAX_INT" s m _ d e f n xxx" ; sin_value xxx" ; s m _ e x p _ t y p e PD9" ]

---

def for MIN_INT def for MIN_INT

---

def for MAX tNT def for MAX_INT

;

Page t52

/ Section

package

DIANA Reference Manual

5

REPORT ~s

function

E Q U A L ( ×.

Y : ~NTEGER ) r e t u r n EK)OLEAN;

e n d REPORT:

A01:

comp_unit

A02: A03: A04:

pragma_s context package_decl

A05:

package

A06:

package_spec

A07: A08: A09:

as_dect_s as_deci_s subprogram_dect

A10:

function

td

{d

A1 ~: f u n c t i o n A12: A13:

param in

s

A14: A15:

iris in_Id

A16:

In_Id

AI 7:

used_name_td

At8:

used

name

id

[ as_pragma_s A02" : as_context A03" ; as_unit_body A04* ] [ as_list < > ] ~ as_tist < > ] ~ as_id A05" : as_package_def A06" } E Ix s y m r e p "REPORT" : sm_spec A06" ; sin_body void : sm a d d r e s s void ] [ as d e c l _ s l A 0 8 " : as_decl_s2 A07" ] ~ as_list < > ] E as_tist < A0g* > ] ~ as_designator A10" : aS h e a d e r A11" ; as_subprogram_def void ] ~ t x _ s y m r e p "EQUAL" : s m _ s p e c A11" ; sin_body void ; sm_location void ] as_param_s A12" : as_name At8" ] [ as list < A 1 3 " > ] { as_ld_s A14" ; as_name A17" ; a s _ e x p v o i d void ] [ as_fist < A15" A16" > J [ t x _ s y m r e p "X* ; sm_inlt._exp void : sm_obj_type PD9" | f x _ s y m r e p "Y" ; sm_iniL_exp void : sm_obJ_type PD9" ] [ I x _ s y m r e p *INTEGER" ; s m _ d e f n PDS" : { Ix._symrep " B O O L E A N " ; sm_defn POt" ]

Page 153

Implementation Options

CHAPTER 6 IMPLEMENTATION OP~ONS

One obvious implementation of a compiler using the DIANA Intermediate form Is to p r o d u c e the complete DIANA abstract tree as the result of semantic analysis, representing each abstract tree node by a variant record on a heap and using pointers

to

i m p l e m e n t those

attributes that

reference

other

nodes.

In

some

applications such an implementation may be completely a p p r o p r i a t e ; in others, may not. options

that

options:

it

The purpose of this chapter Is to Illustrate some other i m p l e m e n t a t i o n are

possible.

We

cannot,

of

course,

describe

all

conceivable

our goal is merely to describe e n o u g h of them to make the point that

the obvious implementation is not the only possible one. At the risk of repeating the point once

representation independent. mentioned

below,

too often,

we stress

that DIANA Is

Possible implementations include any of the schemes

many others,

and

combinations of

them,

Each

possibility

makes good sense in certain applications or for certain i m p l e m e n t a t i o n e n v i r o n ments,

A Coroutine Organization:

The Front and Back Ends of the c o m p l l e r might be

organized in a coroutine m a n n e r ,

in which the Front End produces a portion of

the Intermediate form after which the Back End produces code for this portion and then discards the unneeded pieces of Its Input,

In this organization t h e r e

would never be a DIANA representation of the entire c o m p i l a t i o n unit at any o n e time.

Instead,

cated

is needed.

only a consistent DIANA subtree for the portion being c o m m u n i Although this type o1 organization may limit the a m o u n t of

optimization that can be done. the DIANA model.

it is often useful and Is completely consistent with

To use this style of c o m p i l e r organization,

the user needs

only to ensure that the values of all of the attributes for the portion of the tree being c o m m u n i c a t e d are defined properly.

Non-Tree Structures: Many simple compilers use a linear representation, such as

Polish

postfix,

for the intermediate form,

Such

a representation has

the

a d v a n t a g e of simplifying certain tree traversals, and Indeed may be obtained from the DIANA tree by just such a traversal, a d v a n t a g e In that they are o v e r h e a d s are high. DIANA.

Again,

more such

Such representations may also have an

efficient

where storage

is

limited

or

paging

representations are fully within the spirit of

Where DIANA requires a ( c o n c e p t u a l )

pointer,

It may be replaced by an

DIANA Reference ManuaI

Page 15,~ / Section 6

index ~nto the !inear representation.

DAG

Representation:

The

structural

attributes

responding to the abstract syntax of ADA. do

not

shared

require

distinct

save

to

acyclic graph,

copies

of

memory space, or DAG.

identical The

of

DIANA define

a

tree

cor-

So tong as the processing algorithms subtrees,

resulting

such

subtrees

storage structure

may

be

is a directed

This observation is especially important with respect to

leaves of the tree and to certain attribute vaiues, half the nodes in a tree are leaves;

thus.

Typically. for example, about

substantial space can be saved by

using a single instance of a used name_ld node to represent alt of its logical occurrences

in

the

DIANA tree,

Similarly,

occurrences

of the

attributes

that

represent ~lterai values and the string name of identifiers in the program can be pooled,

Attributes Outside ~'he Nodes: be

stored

contiguousiy.

As

illustrate just one here.

There is no need for the attributes of a node to there

are

many

variations

on

this

theme,

we

Suppose that the general storage representation to be

used involves storing each node as a record tn the heap and using pointers to encode

the

attributes

structural

associated

attributes, with

attributes dtrectty in the

each

Because node

records

type.

there one

representing the

define a number of vectors (of records)

are

may

a

number

not wish

nodes,

to

instead,

vector.

the

nodes

themselves

need

different these

one might

where the records in each vector are

taitored to the various groupings of attribute types tn DIANA nodes, scheme,

of

store

contain

only

an

index into

Using thts the

relevant

Such a scheme has the advantage of making nodes of uniform size as

well as facilitating the sharing of identical sets of attribute values,

General Set of Attrlb~rtes: All nodes can be implemented with a general set of attributes,

and atl other attributes could be kept outside the nodes,

A Boolean-

valued attribute in the node can then be used to indicate that an attribute outside the node exists.

This method is useful

for attributes that may be on several

nodes but is generally void (such as Ix_comments).

Nc~e~

i n s i d e Other Node~:

another node,

Although

an attribute of a node may reference

there ~s no implication that a pointer is required;

the referenced

node may be directly included tn the storage structure of the outer node so long as the processing permits this.

This approach is especially important where the

Feferenced node has no attributes. an attribute catted as_btnary_op nodes--all

of which

For example, the binary node of DIANA ha~

which

have no attributes,

references one of a number of possible in effect,

this attribute's value is an

Section 6 / Page 155

Implementation Options

e n u m e r a t i o n type

and

can

be

implemented

as a small

integer

stored

In the

binary n o d e ' s storage area,

Copies of Attribute Values: of an attribute, e . g . ,

An implementation may c h o o s e to copy .the value

If the attribute value is stored in another compilation unit,

The i m p l e m e n t a t i o n must,

of course,

preserve the semantics of the equality test

and assignment operations for attribute values, as discussed in Section 3 . 9 ,

Separate

Symbol

Tables:

The

collection

of

DEF_OCCURRENCEs are effectively a symbol table. such nodes as il they were part of the tree.

nodes

which

constitute

This presentation discusses

but an i m p l e m e n t a t i o n may elect to

collect these nodes together into a c o m p a c t structure, the tree.

types

physically separate from

The Predeflned Environment

Page 157

APPENDIX ! THE PREDEFINED ENVIRONMENT

The

semantics

of ADA provide that an ADA program

entities that are not defined within the program Itself,

universal types

may r e f e r e n c e

certain

There are four cases:

These cannot be mentioned by the p r o g r a m m e r but are referenced only implicitly, For example, they are referenced in describing the type of a n u m b e r , or in describing the result of certain ADA attributes.

predeflned language environment This is essentially the package STANDARD,

attributes

These Include both those predeflned those defined by the implementation.

by

ADA as

well

as

pragmas

These include both those predefined those defined by the implementation.

by

AOA as

well

as

In the following four sections of this appendix we describe how the DIANA form for each of these Is derived.

h 1. Universal Types The

notion

number

of

universal types is

declaration

and

to

define

used the

in ADA tO associate

result

type

of

certain

a

type with

attributes,

a To

r e p r e s e n t these notions. DIANA extends the class TYPE_SPEC by t h r e e nodes: WPIE SPIEC ::=

universal_integer I universaLreal I univer,sal, fixed ;

These

nodes,

attributes

of

which a

have no attributes,

program;

they

never

can

appear

be referenced directly

in

the

only by s e m a n t i c tree,

The

type

u n i v e r s a l _ r e a l covers both fixed and float types in cases w h e r e they c a n n o t be distinguished,

as in number declarations.

1.2. The Predeflned Language Environment The predeftned e n v i r o n m e n t of" /iDA Is specified given in Appendix C of the ADA LRM.

by the package STANDARD.

The DIANA tree for It may be obtained by

simply compiling this package with a Front End.

though the c o m p i l a t i o n must be

Page 158 / Section t, 2

DIANA Reference Manual

d o n e {n a speota~ m o d e since some attributes must be d e t e r m i n e d by special rules,

in a few cases (such as cd_lmpl size for numeric t y p e s ) ,

must be explicitly assigned; inquiry.

the attributes

they c a n n o t be derived from any further e n v i r o n m e n t

Note that this operation need be done only o n c e ;

the DIANA fOrm can

then be preloaded into all programs that process the DIANA form of ADA. Since the Front End and Back End must be abie to a g r e e on the operator type ( s e e Section 3 . 8 , 5)

and the Front End must be able to c o m m u n i c a t e this

information to the Back End.

the two must agree on how the representation of

package STANDARD is to be augmented to include this information.

, S. Attributes Appendix attributes;

of

A

these

4.].4.

the

may

ADA

be

DIANA does

extended

an

set

of

predefined

language

see

of these

attribute

not define additional Information for checking

that a t -

unique

by

a

point

a

tributes are used c o r r e c t l y ; implementation.

describes

Implementation,

DIANA requires

identifiers.

LRM

definition

for

each

LRM

Section

the design of this information is a c h o i c e for each

We also need a string representation of the attribute name (to

r e c o n s t r u c t the s o u r c e ,

for e x a m p l e ) .

DEF_IO ::=

a~rjd;

attr id =>

~x.symrep

The resulting structure looks like:

: sym~l rep;

The c o m p l e t e definition of an ADA program requires nodes for all the I m p l e m e n tation supported attributes;

these are easily constructed.

Using the external form

of DIANA defined in Chapter 5. for example, two of the predeflned attribute nodes are: attr_id [ IX_symrep "BITS" ] attr_id [ Ix_symrep "SMALL" ]

L 4. Pragmas Appendix B O~ the ADA LRM fists the language-defined pragmas for ADA. i m p l e m e n t a t i o n is free to expand this set by defining additional pragmas.

An DIANA

provides a definition point for the Identifiers needed to r e p r e s e n t the complete set of p r a g m a s known to an implementation.

The DIANA r e p r e s e n t a t i o n of these is

similar

described

to

its

environment,

representation diana

provides

of the

attributes

information

above:

necessary

to

in

the

identify

predefined the

pragma

The Predeflned Environment

Section 1,4 / Page 159

names and their names of its arguments,

(e.g,.

of a pragma*s arguments are named and " O F F ' ) ,

In addition, for

where the possible values

pragma LIST the values "ON"

a defining occurrence for the names of the values is also provided.

The defining occurrence for an Identifier used in conjunction with a pragma in DIANA has the following structure:

DEF._ID : :=

pragma id

pra~ma....id =>

as_liM

ARGUMENT : : =

argument_id

l:)r~3ma. Id =>

lx_syrnrep

: symbol._rep ;

Ix_,symrep

: symboLrep ;

=>

argument_td

A

list

of

argument

: Seq Of ARGUMENT ;

names

is

argument names are possible, the SUPPRESS pragma.

ARGUMENT ;

Introduced

for

those

situations

where

multiple

as for example for the various check names for

Note that the list is also used to introduce the names of

the values the pragma's arguments may take. As with the attributes,

an implementation must supply a set of nodes for the

various language-defined and Implementation-defined pragmas,

Here are two e x -

amples In external DIANA form:

pragma_id [ iX_symrep "LIST"; as_list ] LI: argument id [ Ix_symrep "ON" ] La: argun~nt_id [ Ix~_symrep "OFF"] pragmat_id [ lx_symrep "PRIORITY" ]

All

checks

concerning

been done during

the

semantic

correct

analysis,

use of a pragma are

assumed to have

and performing these checks will

neces-

sarily require knowledge of the semantics the pragma that DIANA cannot supply. The

predefined

environment

merely

provides the

defining

occurrences

for

the

the

pragma

subtree

the

proper semantic

identifiers used. For

language-defined

represents checking

a has

correct been

pragmas,

pragma; done.

that

For

DIANA requires Is,

for

pragmas

each

that

pragma

not supported

by an

implementation

DIANA requires that the structure of the pragma subtree Is present and contains the

lexical

correct.

information

but

does

not

require

that

the

semantic

attributes

are

In most cases this requirement means the pragma name and argument

names are represented by used_name Id nodes whose sm._defn attribute is void.

DIANA Reference Manua~

Page t 8 0 ~ Section 1.4

There are severat situations where the arguments to a pragma are types or objects defined by the

user.

The pragma node has a structural attribute which

represents the ttst of actual arguments to a particular pragma: p r a g m a _ l d corresponds in a sense to formal parameters. tree for the fragment

type C is array(l..lO) of C~kRAC'TER; prac~ PACK(C)~

/

pragma

! used_name_t4

param_assoc s

smdefn

I used_name_id sm_defn

i

pragma_id "PACK"

i type_id for C

Figure I-1:

Example of a Pragma

the list in the

Figure I-'1 shows the

The Abstract Parse Tree

Page 161

APPENDIX U THE ABSTRACT PARSE TREE

ADA's Formal Definition assumes a parse tree that is structurally quite similar to

the

DIANA tree

described

in

Chapter

2,

This

appendix shows

the

IDL

representation for this parse tree. Following are the principal differences between the parse tree and the DIANA tree: ,, The parse tree has no semantic or code attributes. = The parse tree has apply nodes Instead of function call. procedure call, entry call, attribute call, indexed, conversion, and slice nodes. IDL

provides

a

means

for

deriving

a

structure

from

a

previously

defined

structure by describing the new structure in terms of changes or edits to the old structure.

This form of structure declaration has the following basic form: Structure newstructure Root r o o t F r o m o l d _ s t r u c t u r e Is - - "edits" t o o l d structure End

There are two sorts of edits: from

It.

Additions

structure

declaration

are as

additions to the

Indicated normal

by simply

from

the

original

Including

IDL definitions.

clauses beginning with the keyword Without. deleted

original structure

structure

In

the

and deletions

additions within

Deletions

are

Indicated

forming

the

new

one.

Five

kinds

= Deletion of a particular element from the right side of a class definition Is Indicated by an entry of the form = := e l e m e n t _ n a ~ e

Here a n *element" can example:

be either a class or a node.

Here is an

Old E X P ::= foo [ leaf I t r e e -- without clause W i t h o u t E X P : := leaf new E X P ::= foo I t r e e -

-

-

-

by

followed by a list of Items to be

deletions can be made:

class_na=e

the

= Deletion of a particular attribute from the right side of a node definition is Indicated by a line of the form

of

Page 162 / S e c t i o n ~i

nodename

OIANA A e f e r e n c e Manua~

=> a t t r i b u t e _ n a m e

Here is a n e x a m p l e : old t r e e => left:ED(P, op..OP, r i g h t : E X P -- without clause w i t h o u t t r e e => left ~new t r e e =7 op:OP, r i g h t : E x P

o Deletion of an entire class definition c l a s s n a m e ~ollowed by " : : = ' , as in

is indicated

by giving just the

= D e l e t i o n of an entire n o d e definition n o d e n a m e 1otiowed by "=>'. as in

is indicated

by giving just the

f o o => = Detetlon of an attribute name is indicated by writing 1: ~=> fO0 The attribute Is t h e r e b y deleted from all nodes which named it, Using this notation, root COMPILATION,

we now derive from Diana the structure

ParseTree.

with

The

Abstract

Section

Tree

Parse

II /

Structure ParseTree Root COMPILATION From Diana is - - ParseTree has APPLY nodes instead of function cell, procedure call, - - entry cell. attribute cell, indexed, conversion, and slice nodes. Without function call =>, procedur-e call =>, errtry calt =>, attribute call =>, indexed --=>, slice =>, conversion => ,

--

NAME : := NAME : := NAME : := NAME : := EXP : : =

attribute call, function call, slice, indexed, conversion,

STM ::= STM ::=

procedure ce., entry call;

additions for APPLY STM : := NAME : : =

NAME; apply;

apply =>

as _nlm'm

: : Ix._oom,'m~nts : as_param_a~.soc_a :

Ix~rcpos

GENERAL ASSOC S : : = general assoc_s; as_list general _a~soc s -->

: : : ACTUAL I RANGE I

Ix_arcpos Ix_commenfa

GENERAL ASSOC : :=

NAME, sourceposition, comments, GENERAL_AS$OC S; Seq Of GENERAL ASSOC, sourceposition, comments, named;

- - ParaeTree has only one kind of USED ID Without used

name

Jd

..~:o~w.-_~

=>

=,

,

,

U~ad number id =>, used bltn i d ' ~ > , USED._ID : := USED tD : := USED ID : :=

used_name_id, used_object_id, uced b~n id;

additions for USED...ID USED ID : := used_id =>

used_~;

Ix sr¢po~ Ix_comments Ix_symrep

: sourceposition, : comments, : symbol rap;

ParaeTree has only one kind of U S ~ _ O P Without use , string_literal => , usod bttn op => , DESIGNATOR : : = EXP : : =

used op, string literal;

- - additions for USED._OP DESIGNATOR : := u s ~ string =>

us~

stri~;

lx_ercpoa Ix_comment.s Ix_aymrep

: sourceposition, : comments, : symbol rap;

Page

163

Page

164

/

--

Section

DIANA

I~

Parselrres hes no ~ m ~ n t t c

attributes

Without : ~ sm ectual d e , e . * => sm address. * :'> sm ba~e t y p s , * * * * * *

=> => => => => => => * => * =>

~m body~ Sr(~ cornp_spe¢, sm constraint, ~m c o n t r o l ~ . ~m_declj. smJe~. ~ ' t discriminents. ~ exoept~on_def. sm e x p t y p e .

=>sm g e ~ s r i c p a r a m s. => ~ j n R .exp, => Sm location. => sm normelized c o m p s. => s m ~ n o r m a l t z e d pIIram s. => sm ,obLdefo => s m _ o b L t y p e . => sm o p e r a t o r . => sin_packing.

* * * * * * *

* => sm r e c o r d spec. => sm r e p ,

=> => => * => * => * =:) -

-

smjtm. sm store.ge size. sm b'tul~, sm t y p e _ s p e c . ~m t y p e ~ u c t . sm V~il)e;

P a r s e T r e e hes no code a t t r i b u t e s

Without => ¢d_imp~ End

size;

Re{erence

Manua~

Page 165

Reconstructing the Source

APPENDIX III RECONSTRUCTING THE SOURCE

One source

of

the

basic

principles

of

DIANA Is that the

structure

p r o g r a m is to be retained in the DIANA representation,

designed

so

that

the

front

end

of

an, ADA c o m p i l e r

(or

of

the original

DIANA has been

any other

tool

that

p r o d u c e s DIANA from ADA) can include in the DIANA sufficient information so that, to a first approximation at least, the original ADA text can be r e c r e a t e d from the DIANA,

This ability enables an APSE tool such as a p r e t t y - p r i n t e r to work directly

from the DIANA form.

or a syntax-directed editor to operate directly on It.

DIANA form can stand alone without reference to the original source;

The

some APSE

designs might elect to discard the source and keep Dust the DIANA form,

using a

p r e t t y - p r i n t e r when a source listing Is required. DIANA'S programs.

design These

deliberately are

Includes

omissions

from

r e c o n s t r u c t the original program exactly,

certain the

normalizations

DIANA of

enough

of

source

Information

to

and the effect of omitting these data is

that the reconstructed source program is of necessity normalized in certain ways. (The lost

normalizations are discussed by

making

these

lexical attributes.

in Section i U . 3 . )

normalizations could

Although

be retained

by

the information

p r o v i d i n g additional

DIANA'S design is predicated on the assumption that the value to

the user of this information does not JustifY Imposing on all DIANA users the cost in processing time to record the additional data or in space to store them.

III. 1. General Principles The

structure

Tree (AST)

of

DIANA'S original

design

of the ADA Formal Definition ( A F D ) .

followed

a d e q u a t e information to permit source reconstruction. based on ADA-80.

and DIANA'S (present)

the

Abstract

Syntax

which was designed to Include Unfortunately. the AFD is

design is based on the syntax of on

ADA-82, which differs from that of ADA-80 in important ways. In Chapter 2.

we showed the connection between the ADA-82 syntax and the

DIANA structure by Including the f o r m e r with the description of the c o r r e s p o n d i n g nodes and attributes.

There

is a close c o r r e s p o n d e n c e

and DIANA'S structural attributes,

between ADA'S syntax

as shown in the examples in the next section.

It is this c o r r e s p o n d e n c e that permits source reconstruction.

Page ]66 / Section ~'~

DIANA Reference Manuat

The discuss{on on ~ormaiization of DIANA ~n Section 1 . 1 . 4 on page 14 {s a|so relevant.

Any technique to somve the problem addressed in that section will shed

~ight on source reconstruction.

lit. 2.

Examples

A few examples illustrate the reconstruction process,

Consider first the ADA

assignment statement, with syntax and DIANA structural attributes as follows: Ada Syntax (Section 5.2 of the Ada DR.M)= assigrm~nt_sta%ement : .'= name ~= e~Dression ; Diana rules assign => a s _ n a m e

: NAME, : KX9;

as_exp

The ADA tex~ corresponding to an assign node is thus the text that ted to the NAME ( i . e . 0

the value of the as_name attribute),

the text that ~ed to the EXP (i. e . . ";'.

followed by ' : = ' .

the value of the as_exp attribute,

followed by followed by

We can summarize by writing that the source text for an assign node is

Here the

angle

,'=

<EXP> ;

brackets

( < > ) indicate that the the text for the

corresponding

subtrees must be fitled in, As a second exampte, c o , sider an ADA b~ock: A d a Syntax (Section 5.6 of the Ada L~M): block statement : := [ block_simple_name ]

[Oecla~ dec laxa%ive_isar£ ]

~eg~ sequence_o£_st at emen%s

[exaction exception handler

{exception_handler} ]

e n d [block_simple_name]

Diana rules block => as..jtem__s

as._stm_s as..alternatlve_s Thus

~or an

generated.

unlabeled

block

node

: [ T E M S S,

• STM_S, : ~TIV~_S;

used

as

e statement

the

following

text

~s

Section 111.2 / Page 167

Reconstructing the Source

declare < itent_s >

exception ~alternative_s > end;

In a few places the text to be generated depends on the structural child. the block statement example, only

when

the

sequence

of

child Is e m p t y ) ,

as._alternatlve_s

alternatives

Is

non-empty

the

(i. e,,

since the syntax of ADA-82 requires at least one

exception handler after the word exception. handlers.)

In

It Is Important that the text exception be g e n e r a t e d

(ADA-80 permitted an empty list of

Similarly, a private part should be generated only for a p a c k a g e that

contains a n o n - e m p t y list of private declarations. In

a

similar

structural

vein,

parent.

sometimes

Again

the

the

block

text node

to

be

provides

generated a

good

bluck appears as the descendant of a s u b p r o g r a m _ b o d y node,

depends

on

example.

the

When

the word declare

should not be generated.

III. 3. Normalizations of the Source A n o r m a l i z a t i o n of the source Is a deliberate omission from the DIANA structure

of

information

source

text.

that would Most

of

be

the

required

to

produce

normalizations

are

an

exact

Imposed

recreation

by the

of

AFD.

includes the following normalizations: = The optional Identifiers following the reserved word end are not represented In DIANA. This decision means that during reconstruction the program is normalized either always to include the end labels or always to omit them. = DIANA does not require preserved.

that extra spaces

between lexlcal tokens

be

° Variant spelling of an Identifier, as for example "FOO" and "Foo" and "too". need not be recorded In DIANA. ThiS Is a lexlcal Issue that does not affect the semantics. o Alternate writings of numeric constants need not be preserved. example, in 2

002

For

0--0_.2

2#1111_1111# 12el 1,2e2

16#FF# 0.12e+3

all the values on each

016#OFF# 01.2e02

line would

255

be represented

the DIANA

identically in the

Page t68 / Sect{or~ IH.3

DIANA Reference Manual

DIANA and So would be reconstructed ~denticaHy. This ~ssue ts e s s e n tially the same as the variant spelling of Identifiers; DIANA does not require that variations be preserved. A few normallzations of the AFD are no longer ~n DIANA, because of changes in ADA-82"S syntax from the ADA-80 syntax used in the AFD. o In the AFD (and therefore in the original design of DIANA), all infix operators (except the short circuit and membership operators) are converted to function calls. That Is, each of X4Y -+"(x,

~)

gave rise to the same DIANA structure. Thus the original program could not be reconstructed, since it could not be determined whether the original had an infix or prefix form for these operators. ADA-82 requires that this distinction be maintained to meet the conformance rules for initial values of default format parameters, stated in ADA LRM Section 6 . 3 , t, = in formal parameter declarations for subprograms, the mode in is optional Originally, the presence of the word in in a formal part was not recorded in the DIANA. The conformance rules of Section 6 . 3 , ] requires that this information be maintained. ,, The AFD omits parenthesized nodes If the parentheses are redundant. The conformance rules Just referred to require retention of these nodes.

Ill. 4.

Comments

in order properly to reconstruct the source. ing

comments,

attribute ( i . e . .

To this

end,

every

DIANA must be capable of r e c o r d -

DIANA node

that

has

a

source

position

att those which correspond to points in the source program)

has

the additional attribute Ix c o m m e n t s

which how

IS an

: comments;

implementatlon-dependent

accurate|y c o m m e n t

type.

The

positions are recorded

implementation

and

may

choose

how to associate c o m m e n t s

with partlcular nodes. The any

way a user chooses

internal representation

nodes.

When

assumptions

can

there be

to c o m m e n t to m a k e

is a coding made

a

a program meaningful

standard

that enforces

to

style,

easier.

Since standards are treated as an

type. DIANA

the association

of c o m m e n t s

a commenting

such as these are Hkeiy to be only enforced locally, c o m m e n t s Implementatlon-dependent

that m a k e

greatly atlects the ability of association

makes

no

requlrement

about

either

the

Reconstructing the Source

Section 11t.4 / Page ] 6 9

Internal or the external representation of c o m m e n t s ,

and an implementation does

not have to support the Ix_comments attribute to be considered a DtANA producer or DIANA consumer, One m e t h o d for distinguishes

attaching comments to tree nodes ls described

between

comments

represented by the node,

preceding

or

following

the

subtree

in ['ll. which

It is

Diana Summary

Page 171

APPENDIX DIANA

IV

SUMMARY

This appendix contains a list of all the ,class and node definitions sorted by the

name

names With

each

2 where

of

are

the

class

upper

case.

definition the

or

node. Node

is l i s t e d

corresponding

the

Class

definitions section

concrete

ACTUAL : := EXP; ALIGNMENT ::= alignment; ALTERNATIVE : ;= alternative I pragma; ALTERNA~VE S : := a l t e r n a t i v e s ; ARGUMENT ; ; = argumep~t id; BINARY OP : : = SHORT CIRCUIT OP; BLOCK~STUB ::= block; BLOCK STUB ::= stub; BLOCK STUB_VOID :;= block I stub I void; CHOICE : : = EXP I DSCRT_RANGE ! others; CHOICE S ::= choice s; COMP : : = pragma; COMP : : = var I variant_part I null._comp; COMPILATION : := compilation; COMP ASSOC : := named I EXP; COMP REP : : = comp rap; COMP REP : ;= pragma; COMP REP S ::= comp rap s; COMP REP VOID ::= COMP REP I void; COMP UNIT : : = comP_unit; COND CLAUSE : := cond clause; CONSTRAINED : := constrained; CONSTRAINT : := RANGE t float I fixed ! dscrt realge s ! dscrmt._aggregate; CONSTRAINT : := void; CONTEXT ::= context; CONTEXT_.ELEM ::= pragma; CONTEXT_EI_EM : : = use; CONTEXT ELEM : : = with; DECL : : = REP I use; DECL ; := constant I var ! number I type I subtype I subprogram._decl I package _decl | task dect |

definitions follow;

number

syntax can

are

node and

page

be found. S,4 13.4.A 5.4

61 74 53

5.4 App, I 4.4.A 6.3 10,2,B 9,1,A

53 76 48 60 70 65

3.7,3. B

43

3.7.3,A 3,7,B 3.7,B

43 41 41

10,1 .A 4.3.B

69 47

13.4.B 13,4.B 13.4.B 3.7.B

75 75 75 41

lO, l . B 5.3.A 3.3.2.B 3.3.2.C

69 53 36 37

3.3.2.B 10.1.1,A 10.1,B 10.1.1.A 10.1,1.B 3,9oA

36 69 69 69 70 44

3,1

33

3.1

33

ger~r~ 1 exception 1

deferred_constant; DECL ::= pragma;

given

names

first; are

number

all

lower within

class case.

Chapter

Page

172

/

Sec|lon

DIANA R e f e r e n c e

iV

7.~,B 3.5,1.B

DECL._S : : = deci_s; DEF _CHAR : := def_char; DEF ID : : = att,r id l

~p. i

ARGUMENT; ¢omp id; const id; dscrmt id; entry_id; enum_id; exception_td; function id; generic id; in id; in OUt id | out_|d; DEF ID ::= iteration id; DEF ID ::= label id; DEF ID ::= named stm id; DEF tD : : = number id; DEF ID : : = package td; DEF_ID : : = private type_id m I_private_type td; DEF._ID := proc id; DEF ID := subtype ~ ; DEF_ID := task body_id; OEF--ID := type_td; DEF_ID := var_id; DEF_OCCURRENCE : : = DEF_ID

DEF ID DEF ID DEF ID DEFZID DEF_ID DEF ID DEF ID OEF ID

::= ::= ::= : := : := : := ::= ::= DEF_IO : : = DEF |D : : =

DEF_OP !

DEF_CHAR; OEF OP ::= def op; DESFGNATQR ::= ID I OP; D~St(~NATOR CHAR : : = DESIGNATOR l used_char; DSCRMT_VAR : := dscrmt,..var; DSCRM'[ VAR S ::= dscrmt vat s; DSCRT RANGE : : = constrained I RANGE;

DSCRT_RANGE : := ~ndex; DSCRT_RANGE S ~:= dscrt_.range_s; ÙSCRT_RANGE_VOID ::= DSCRT_RANGE void; ENUM...LITERAL : : = enum id I clef char; EXCEPTION DEF : := rename; EXCEPTION DEF ::= void; EXP ::= NAME I numeric_literal I null access t agg'r-egaide I string_litera! | allocator I cotlversion | qualified | parenthesized; EXP : := aggregate; EXP ::= binary; EXP ;:= membership; EXP CONSTRAINED ; : = EXP | CONSTRAINED; EXP_S : := exp_s; EXP_VOID ::= EXP I void; FORMAL SUBPROG DEF ::= NAME I

]

3.7.B 3.2.A 3.7.1 9.5.A 3.5.1,B 11.1 S.1.A t2.1.A S.I.C S.1 .C

41 34 42-

5.5,B 5.1.B 5.5.A 3.2,B 7,1,A 7.4,A

55 51 54 35 62 63

5.1.A 3.3,2,A 9.1.B 3,3,1~A 3.2.A 2.3

57 36 65 35 34 32

6.1,A 2.3

57 32

4,1.3

46

3.7,1 3.7.1 3.6.C

42 42 40

3.6,B 3.6.A 9.5.A

40 40 66

3.5.1,B

38

8.5 11,1 4.4,D

64 70 49

4.3,A 4.4.A 4.4.B 4,8

47 48 48 50

4.I,1 3.2.A

46 34

12.1 .C

72

t2.1,D

72

12.3,C 12.3.B

73 73

bexl r~_d~ault:

FORMAL ~fPE SPEC : : = ~ormal dscrt t formal integer I formal fixed | formeLfloat; GENERIC ASSOC ; := ACTUAL; GENERIC ASSOC : := assoc;

62 38 76

38 70 57 71 59 59

Manual

Diana Summary

Section

GENERIC ASSOC S ::= generic_assoc s; GENERIC_--HEADER : := procedure I function I

12.3.A 12.1 .A

73 71

GENERIC PARAM ::= in I in out I

12.1.C

72

12,1.B 9.5.A 6.1,B 6,1.B 2,3

72 66 58 58 32

3,2,C 3.7.3.A 3.9.B

35 43 44

9,9.B 5,5,B

44 55

5.5,A 5.5.B 6.1.A 6.1.A

54 55 57 57

5,5,A 4.4,B

54 48

4.1.A

45

4.1.B 9.10 5.7

45 68 56

3.2.A 8.5 2,3

34 64 32

12.3,A 7.1,B 8.5 7.1,B 7,1.A

73 62 64 62 62

6.1.C 6,1.C 6.1.C 6.4

59 59 59 61

2.8.A 6.1.C 2.8.A 10,1.B 3.5

33 59 33 69 37

3.5.7

39

19.1

74

3.7.A

41

package_spec;

subprogram _de¢~; GENERIC PARAM S ::= generic_param s; HEADER "~:= entr~; HEADER : := function; HEADER : := procedure; ID : : = D E F J D I USED IO; ID S ::= id S; INNER_RECORD : := inner_record; ITEM ::= DECL I subprogram_body I package body I task body; ITEM S : : = item s; ITERA,'TION : := for I reverse; ITERATION : := void; ITERATION : := while; LANGUAGE : := argument._id; LOCATION : : = EXP VOID I pragma id; LOOP ::= loop; MEMBERSHIP.UP ::= in..op I notin; NAME : := DESIGNATOR t used char 1 indexed I slice I selected I all l attribute I attribute call; NAME ::= function call; NAME S ::= name s; NAME._VOID ::= NAME I void; OBJECT DEF ::= EXP VOID; OBJECT_DEF : : = rename; UP : : = DEF UP I

usE~_oP;

PACKAGE DEF : := instantiation; PACKAGE DEF : := package._spec; PACKAGE DEF : := rename; PACKAGE_SPEC : := package spec; PACK_BODY DESC ::= block I stub I rename I instantiation I void; PARAM : : = in; PARAM : : = in out; PARAM : := out; PARAM._ASSOC : : = EXP I assoc; PARAM_ASSOC S : := param_ass~ s; PARAM S : ; = param s; PRAGMA ::= pragma; PRAGMA S ::= pragma._s; RANGE : : = range I attribute | attribute call; RANGE_VOID ::= RANGE I void; REP ::= simple rep I address I record rep; REP VOID ::= REP I

IV /

Page

]73

Page

1.74 / S e c t i o n

DIANA R e f e r e n c e

mV

vo~d; SELECT CLAUSE : := pragma; SELECTCLAUSE ::= select clause; SELEC'f CLAUSE S ::= select clause s; SHORT CIRCUIT.=OP ::= and then I or else; STM ::= if l case | named strn | LOOP l block | accept I select I cond _entry I timed entry; STM : : = tabe|ed; STM : : = nu, stm I

9.7.1.B 9.7.1.B 9.7.1.A 4,4,A

67 5/' 67 48

5.1.D

5?,

5.1.B 5.1.C

51 51

5.t.C ¢J.7,t.B 5,1,A 12.1.O 12.3.A 8.5 6,1.A 5.1 ,A

5t 67 51 72 73 64 57 57

10.2.A

70

9,1,A 4,4,B

55 48

3.2.A 12.1.D 3.3.1 .B

34 72 36

7.4.A 7.4.A 9.1.A

App.

63 63 65 76

3.8.1 10,1,B

44 69

4,1,A

45

exit | return | goto I entry ¢~.11 m detey | abort | raise |

code; STM : := pragme; STM : := term|nero; STM S : : = sire_s; SUBPROGRAM_DEF SUBPROGRAM_DEF SUBPROGRAM DEE SUBPROGRAM DEF SUBP BODY_DESC

::= ::= ::= ::= ::=

FORMAL SUBPROG OEF; instant|at|on; rename; void; block l stub | instantiation FORMAL. SUBPROG DEF | rename I LANGUAGE I void; SUBUNIT_BODY : := subprogram body I package=body | tesk_ body; TASK_DEF : := task spec; TYPE RANGE : : = RANGE t NAME; TYPE SPEC : := CONSTRAINED; TYPE SPEC : : = FORMAL TYPE SPEC; TYPE SPEC : : = enum literal s I integer | fixed I

flo~t ! array I record | access I derived; TYPE SPEC ::= ~ privete; TYPE SPEC : : = private; TYPE SPEC : : = task apec; TYPE SPEC : := universal integer I universeLfixed t Univer~1_reaI; TYPE SPEC : := void; UNIT BODY : : = psckege body | packe~3e._decl | subonit generic subprogram body I subprogram dect I void; USEDJD ::= used object_|d | use~l name. id | used bltn id;

Manuaf

Section

Diana Summary

USED_OP ::= used_op I used_bttn._op; VARIANT ::= variant; VARIANTS : := variant_s; abort => as name s:NAME S; abort => IX srcpos:courco position, Ix comments: comments; accept => as_name:NAME, as param_s: PARAM S, as stm s:STM S; accept => Ix srcpos:cource_position, Ix comments:comments; access =• as constrained :CONSTRAINED; access => Ix srcpos:source position, Ix comments:comments; access => sm_size:EXP_VOID, sm storage_size: EXP VOID, sin_controlled: Boolean; address = > as name: NAME, as_exp: EXP; address => Ix srcpos:source position, Ix_comments: comments; aggregate => as_list:seq of COMP ASSOC; aggregate =• Ix. srcpos:cource position, Ix comments:comments; aggregate => sm exp_type:TYPE_SPEC, am_constraint: CONSTRAINT, sm normalized comp_s:EXP._S; alignment => as ~ragma_s:PRAGMA._S, as _exp_void: EXP_VOID; all => as name:NAME; all => Ix_srcpos:cource_position, Ix comments:comments; all => sin_exp._type:TYPE SPEC; allocator =• as exp_constrained:EXP._CONSTRAINED; allocator => Ix._srcpos:sourco__position, Ix comments:comments; allocator => sm_exp_.type:TYPE SPEC, sm._value: value; alternative => as .choice s:CHOICE_S, as stm s:STM_S; alternative =• Ix_srcpo$:sourca position, Ix comments:comments; alternatives => as list:seq of ALTERNATIVE; alternstive s => Ix srcpos:cource_position, Ix_comments: comments; end_then => Ix._srcpos:sourco position, Ix comments: comments; argument id => Ix symrep:symbol_rep; a r r w => as_dscrt_range_s:DSCRT RANGE_S, as constrained: CONSTRAINED; array => Ix._arcpos:lmurco position, Ix comments:comments; array => sm size:EXP._VOID, sm .packing: Boolean; assign =• as name:NAME, as exp: EXP; assign => Ix_srcpos:sourco position, Ix comments:comments; assoc => as_designator:DESIGNATOR, as._actual: ACTUAL; ascoc => Ix._arcpos:sourca_position, Ix._comments: comments; attr id => Ix symrep:symbol rep; attr~ute => as name:NAME, as_id : ID; attribute => Ix_srcpos:source position, Ix comments:comments; attribute => sm exp_type:TYPE SPEC, am.. value: value; attribute call => asname:NAME, as_exp: EXP; attribute call => Ix srcpos:sourco position, Ix comments:comments;

4.1.A

45

3.7.3.A 3.7.3.A 9.10 9.10

45 43 68 68

9.5.C

68

9.5.C

66

3.8 3.8

44 44

3.8

44

13.5

75

13.5

75

4.3,A 4.3.A

47 47

4.3.A

47

13.4.A

74

4,1.3 4.1.3

46 46

4,1.3 4.8 4.8

46 50 5O

4.8

5O

5.4

53

5,4

53

5.4 5.4

53 53

4.4.A

48

App.! 3.6.A

76 4O

3.6.A

4O

3.6.A

4O

5.2

52

5.2

52

6.4

61

6.4

61

App. I 4.1.4

76 47

4.1.4

47

4.1.4

47

4.1.4

47

4.1.4

47

IV /

Page

175

Page

]76

/

Section

DIANA R e f e r e n c e

iV

attribute_c~ll => sm e~p_~pe:TYPE_SPEC, sin. value: value; binary => as expl:EXP, as binary op: BINARY OP, as exp2: EXP; binary => Ix_srcpos:sour¢~ position, Ix comments :comments; binary => sin. ex~ type: TYPE SPEC, sm _valu,e: value; block => as ffem s:ffEM S~ as stm s:STM $, ¢s~eitemative "s:ALTERNATIVE S; block => Ix srcpos:sourc~ position, ix comments: comments; box => Ix srdpos: source position, Ix comments :comments; case => as_e~p:EXP, as _attern~tive s: ALTERNATIVES; case => Ix srcpos:sourse position, Ix comments :comments; choice s => as lis~:seq of CHOICE; choice_s => I~ srcpos:source positi0n, Ix comments:comments; code => es._n~e;NAME, e~_exp: EXP; code => Ix. srcpos:s0urce position, Ix comments:comments; ¢omp. id => t~ srcpos:source position, Ix comments: comments, Ix. symrep: symbol_rep; comp id => sm obLtype:TYPE $PEC, sm init exp: EXP VOID, sm ¢omp spec: COMP REP VOID; ¢omp rap => a,s name:NAME, ~s _e~.p:EXP, as rathe: RANGE; comp rep => tx srcpos:source_position, ix comments:comments; comp rap s => as list:seq of COMP REP; comp rep s => |x srcpos: source position, Ix comments: comments; comp unit => as context:CONTEXT, as unit body:UNITBODY, as pragma s: PRAGMA S; comp unit = > Ix srcpos:source position, ix comments ;commerrts; compilation => a's ltst:seq of COMP_UNIT; compilation => I~ srcpos:source position, Ix comments :comments; cond clause => as. exp void:EXP. VOID, as_sire s: STM_S; tend Clause => ~x ~rcpos:source position, ~x comments: comments; tend entry => as stm sl:STM_$, es stm s2:STM_S; cond entry => P~ srcpos:source_positlon, Ix comments:comments; const id => Ix srcpos:source position, Ix_comments: comments, Ix symrep: ~fmbol rap; const id => sm__address:EXP VOID, sm obLtypo: TYPE SPEC, $m obj. clef: OBJECT DEF, sm _first: DEF OCCURRENCE; constant => as id s:tD S, a s j y p e spec :TYPE_SPEC, as _object det: OBJECT_DEF; con~ant => Ix srcpos:source position, Ix comments: comments; constrained => asname:NAME, as constraint: CONSTRAINT; constrained => cd impl size:integer; constrained'=> ~_--srcpos:source _position, Ix comments:comments;

4,1.4

47

4,4,A

48 48

~.4.A

48

5.6

55

5,6

55

~2.1.C

72

5.4

53

5,4

53

3.7,3.A 3,7.3.A

43 43

13.8

75

13.8

75

3.7,B

41

3,7.B

41

13,4,B

75

13,4oB

75

13.4.B 13,4.B

75 75

10.1 .B

68

10.1.B

68

10.1 .A 10.1,A

6S 68

5.3oA

53

5.3oA

53

9.7.2

6B

9,7.2

68

3,2.A

34

3,2.A

34

3.2.A

34

3.2.A

34

3,3.2.B

36

3.3.2.B 3.3.2.B

36 36

Manua~

Diana

Summary

constrained => sm_type_strust:TYPE_SPEC, am base_type: TYPE SPEC, sm constraint: CONSTRAINT; context => as list:seq of CONTEXT ELEM; context => Ix_ srcpos:source_position, Ix comments:comments; conversion => asname:NAME, as._exp: EXP; conversion => Ix srcpos:source position, lx comments: comments; conversion => sm exp type:3WPE SPEC, sm._value: value; decl s => as list:seq of DECL; decl s => Ix_srcpos:source_position, Ix comments :comments; def char => Ix._srcpos:source_position, Ix comments: comments, Ix__symrep: symbol rap; d e f c h a r => $m obj._type:'i~PE SPEC, sm pos: Integer, sm rap: Integer; d e f o p => Ix_srcpos:source_position, Ix_comments:comments, tx _symrep: symbol_rap; def op => sm_spec:HEADER, sm body: SUBP_BODY_DESC, sm location: LOCATION, sm stub: DEF OCCURRENCE, sm__first: DEF_OCCURRENCE; delerred constant => as id_s:lD_S, as_name: NAME; deferred constant => Ix_srcpos:source_position, Ix comments: comments; delay => as exp:EXP; delay => Ix arcpos:source_position, Ix_comments: comments; derived => as constrained:CONSTRAINED; derived => cd impl size: Integer; derived => Ix_srcpos:source position, Ix comments: comments; derived => $m SIze:EXP. VOID, am actualdelta: Rational, sm /~¢king: Boolean. sm controlled: Bcotean, sin_storage, size: EXP__VOID; dscrmt aggregate => as.list:seq of COMP ASSOC; dscrmt aggregate => lx_srcpos:source position, Ix comments:comments; dscrmt aggregate => sin_normalized ¢omp s:EXP_S; d s c r m t i d => Ix_srcpos:source_.positlon, Ix comments:comments, Ix_symrep: symbol rap; dscrmt_id => sin_obj._type:TYPE SPEC, sm init_exp: EXP VOID, am_first: DEF_O(:~URRENCE, sm comp_spec:COMP REP VOID; dsct'mt var => as id s:lD S, a s n a m e : NAME, as _object det: OBJECT_DEF; dscrmt vat : > Ix srcpo$:source position, Ix._comments: comments; dicrmt .ver._s => as._list:~eq of DSCRMT_VAR; dscrmt var._a => Ix srcpos:source_posltton, ix comments: comments; dscrt range s => as_list:seq of DSCRT RANGE; d s c r t j a n g e _s :> ~._srcpos:source_position, Ix comments:comments; entry => as dsc~_range_void:DSCRT RANGE VOID, as_par am a: PARAM_S; entry => tx_srcp0s:sourceposition, Ix comments:comments;, entry cell => as name:NAME, as._param_assoc._s: PARAM_ASSOC S; entry cell => Ix srcpos:source position,

Section

3.3.2.B 10.1.1.A 10.1.1.A

69 69

4.6

50

4.6

50

4.6

50

7.1.B 7.1.B

62 62

3.5.1.B

38

3.5.1.B

38

6.1.A

57

6.t.A

57

7.4.B

63

7.4.B

63

9,6 9.6

66 66

3.4 3.4 3.4

37 37 37

3.4

37

3.7.2 3.7.2

42 42

3.7,2

3.7.1

42 42

3.7.1

42

3.7,1

42

3.7.1

42

3.7.1 3.7.1

42 42

3.6,A 3.6.A

40 40

9,5,A

66

9.5.A

66

3.5.B

66

9.5.B

66

IV /

Page

177

Page

]78

t

Section

!V

~ comments: ~mments~ enb~J c~l! => sm normalized p~rsm s:E~P_S; entry id = > Ix. Srcpos : source,_position, I~ comments: comments, Ix symrep: symbol .r~p; entry td => sm spec:HEADER, sm address: EXP VOID; enum id => Ix srcpos:sour~poSttion, ix comments: comments, Ix symrep; symbol rep; enum id => sm obj type: TYPE SPEC, smpos:tnteger, sm rep: Integer; enum titera! s => aS l i s t : ~ q of ENUM LtTERAL; enum-literal--s => ¢d~impl size:Integer; enum liters| s =~ ix step, s:source position, |x comments :comments; enum._titeraLs => smsize:EXPVOID; excoption => as id s:lD S, as excepti0ri def: EXCEPTION DEF; exception => t× srcpos:source position, ~ comment~: comments; exception id => Ix srcpos:source_position, IX c~mments: comments~ I~ symrep: ~3tmbol rep; e)~ception_id => sm ~coptionJef:EXCEPTlON DEF; exit => as name void:NAME VOID, a s e x p , void: EXP VO|O; exit => Ix. srcpos:source posttion~ Ix_comments:comments; exit => am_sire:LOOP; exp._~ => as_list:seq of EXP;

e x p s => Ix srcpos:sourco position, Ix comments:comments; fixed => =s_.exp:EXP, as rangevoid: RANGEVOtD; fixed => cd._impl size:Integer; fixed => Ix=_srcpo~:source posltion, tx._comments: comments; ~lxed => sm size:EXP VOID, Sm actual delta: Rational, sin_bits: Integer, sm baseJype ~TYPE SPEC; float => as._exp:EXP, as_range void: RANGEVOID; float => od impl size:Integer; float => Ix_srcpos:source position, Ix comments: comments; float => sm size:EXP VOID, sm type ~truct: TYPE_SPEC, sm b~se_type: TYPE SPEC; for => as_id:lD, as_dsc~ r~nge: D$CRT RANGE; tar => Ix_srcpos:source positlon, ix. comments: comments; ~ormal_dscrt => P~ srcpos:source position, ~ comments: Comments; formal fixed => |x srcpos:source_position, ix comments:comments; ~ormal float => I~ sropos:souroe_positton, |:~comments; comments; ' formal, integer => Ix~rcpos:~ource position, Ix Comments: comments; function => as J~ram s:PARAM $, asJ~ame void : NAMEVOID; function => Ix srcpos:source J>OSitton, Ix_comments: comments; i u n c ~ i o n ~ t l => asname:NAME, furmtion ¢~11 => ~ srcpos:sourc~j>osition, ~x comments: comments; iunction call => sm exp type:TYPE SPEC, sm value: value, sm normalized p s r a m j : EXP S,

OlANA R e f e r e n c e

9.5.B @.5.A

66

~.5.A

66

3.5.~.B

38

3.5.1.B

38

3.5.1.A 3.5. t . A 3.5.1.A

37 37 37

3.5.1.A 11.1

37 70

1t.1

70

1t.1

70

11.1 5.7

70 56

5.7

56

5.7 4.1.1 4.1.1

56 46 46

3.5.9

39

3.5.9 3.5.9

39

3.5.9

39

3.5.7

39

3.5.7 3,5.7

39 39

3.5.7

39

5.5.B

55

5.5.B

55

12.1.D

72

IZ.1 .O

72

t2,1,D

72

39

1Z,1.D

7Z

6. t . B

58

6.1 .E~

58

6.4

61

6.4

61

6.4

61

~anual

Diana Summary

Ix prefix: Boolean; function id => Ix srcpos:source_position, Ix_comments: comments, Ix symrep: symbol rep; function id => sm_spec:HEADER, am_body: SUBP BODY DESC, sin_location: LOCATION, sm stub: DEF_OCCURRENCE, am first: DEF OCCURRENCE; generic => as id:lD, as generic_param s: GENERIC PARAM S, as generic header: GENERIC HEADER; generic => Ix srcpos:source position, Ix comments:comments; generic assoc s => as list:seq of GENERIC ASSOC; generic._assoc s => Ix srcpos:source position, Ix_comments: comments; generic id => Ix symrep:symbol_rep, Ix_srcpos:sourceposition, Ix comments:comments; generic id = > sm generic_param_s: GENERIC PARAM S, sm_spec: GENERICHEADER, sm_body: BLOCK_STUB_VOID, sm first: DEF OCCURRENCE, sm_stub: DEF OCCURRENCE; generic_parem s => as list:seq of GENERIC PARAM; generic parem s => Ix_srcpos:aource position, Ix_comments: comments; goto => asname:NAME; gore => Ix ercpos:source position, Ix_comments: comments; id_s => as list:seq of ID; id_s => Ix_arcpos:source_position, Ix comments: comments; if => as list:seq of COND CLAUSE; if => IX srcpos:source_position, Ix comments :comments; in => as id s:lD S, as name:NAME, as _exp._void: EXP VOID; in => IX srcpos:source position, Ix comments:comments, Ix._detault: Boolean; in id => Ix srcpos:source position, Ix. comments:comments, Ix_symrep: symbol rap; in id => sm_obj._type:'WPE SPEC, am_tnit_exp: EXP_VOID, sm first:DEF OCCURRENCE; in_op => Ix._'srcpos:sou'rce_position, Ix comments: comments; in_out => as id s:lD S, as name:NAME, as_.exp._void:EXP._VOID; in_out => Ix_srcpos:source position, Ix comments: comments; in out id => Ix._srcpos:source position, Ix comments:comments, IX _symrep: wmbol rap; in out id => sm_obj._type:TYPE_SPEC, am flrst:DEF OCCURRENCE; index => as_name:NAME; -index => Ix_.srcpos:source position, Ix comments: comments; indexed => asname:NAME, as_exp s: EXP S; indexed => Ix srcpos:source_posttion, Ix comments :comments; indexed => sm_exp type:TYPE SPEC; inner record => as list:seq of COMP; inner record => Ix srcpos:source_position, Ix comments:comments; tnstentiation => as_name:NAME, as generic_assoc_s: GENERIC ASSOC S;

Section

6.1.A

57

6.1.A

57

12.1.A

71

12.1.A

71

12.3.A 12.3.A

73 73

12.1.A

71

12.1. A

71

12.1,B 12,1,B

72 72

5.9 5.9

56 56

3.2.C 3,2,C

35 35

5.3.A 5.3.A

53 53

6.1.C

59

6.1.C

59

6.1.C

59

6.1.C

59

4,4.B

48

6.1.C

59

6.1.C

59

6.1.C

59

6,1.C

59

3.6.B 3.6.B

40 40

4.1,1

46

4.1.1

46

4.1.1 3.7.3oA 3.7.3.A

46 43 43

12.3.A

73

IV /

Page

179

Page

t80

/ S e c t i o n ~V

instanti~tiOn => ;x sf'cpos:~urce posiUon, tx comments: comments; tnstantiaUon => sm decLs:DECL S; integer => ~s range:RAnGE; integer => od impt ~lze:tnteger; integer => Ix srcpos:source position, Ix ¢c~mments:comments; integer => sm size:EXP. VOID, sm typo street: TYPE SPEC, sm tmse type: T/PE SPEC; ttem_s => as lisL:seq of iTEM; i t e m s => Ix srcpos:scurce position, i x comments: comments; fferation id =~ Ix srcpos:sour~position, Ix comrnent~: comments, l~ ~mrep: symbel_rep; itenaUon..id => Sm obj._type:TYPE...SPEC; ~_private => Ix t~rcpos:source posiUon, Ix comments: comments; i_private => sm disoPImi~nts:DSCRMT._VAR_.S; ~._pr~ate t3~pe id => Ix=srcpos:source position, lx commen~: comments, Ix .~tmr~p: symbof _rep; Lprivate tyl)e ~ => sin. typ~ spec:TY~_SPEC; labeLid => Ix srcpos:source position, Ix comments: comments, Ix wmrep: symt~l rep; |abel id => sm stm:STM; labeled => as id s;ID S, as_sire: STM; labeled => k srcpos:source position, Ix c0mments:comments; loop => as tteration:lTERATIOH, as stm s: ST~ S; Icop => Ix srcpos: source position, ix comments: comments; membership => ss exp:EXP, as membership op: MEMBERSHIP OP, as typ~ range: TYPERANGE; membership => ~ srcpos:source position, ix comments: comments; membership => sm exp type:TYPE SPEC, $m valse: value; name s => as list:seq ot NAME; name s => Ix srcpos:source position, ix comments :comments; named => as choice s:CHOICE S, as e~p;EXP; named => Ix srcpos:source_position, Ix comments:comments; nsmed_stm => as id:lD, as stm:STM; named stm => Ix srcpos:source position, Ix comments:comments; named stm id => Ix srcpos:source position, I× ¢ommencs: comments, Ix _symrep: symbel_rep; named stm id => sm stm:STM; no. defsult => k j r c p o s : s o u r c e position, Ix ¢omment~: comments; not in => ix srcpos:source position, Ix comments :comments; null_access = > Ix srcpos: ~ource position, Ix commen~s: comments; nulLaccess => sm e~p_type:TYPE SPEC, sm value: value; null comp => Ix srcpos:source position, ix comments: comments; null_sire => Ix srcpos:source position, ~X comments: comments; number => a s j d s:lD $, as exp:EXP; number = > i~ srcpos: source position, Ix comments: comments;

DIANA R e f e r e n c e

12.3.A

73

12.3.A 3.5,4 3.5.4 3.5.4

73 38 38 38

3.5.4

38

3.9,B 3.9.B

44 44

5.5.B

55

5.5.B 7.4.A

55 63

7.4.A 7.4.A

63 63

7.4.A 5.t.B

63 51

5.1.B 5.1.B

51 51

5.1.B

51

5.5.A

54

5.5.A

54

4.4.B

48

4.4.B

48

4.4.B

48

9.10 9.10

68 68

4.3.B

47

4.3.B

47

5.5.A

54

5.5.A

54

5.5.A

54

5.5.A t2.1.C

54 72

4.4.B

48

4.4.D

49

4.4.D

49

3.7.B

41

5.1.F

52

3.2.B

35

3.2.B

35

Manua~

Diana

Summary

number_id => Ix_srcpos:source position, Ix_comments: comments, Ix_wmrep: symbol_rep; number_id => sm_obj_type:TYPE SPEC, sm_init_exp: EXP; numeric literal => Ix srcpos:source position, Ix_comments: comments, IX numrep: number_rep; numeric_literal => sm exp type:TYPE SPEC, sin_value: value; or_else => IX srcpos:source position, Ix comments:comments; others => Ix_srcpos:source position, Ix comments: comments; out => as. id s:lD S, as._~me: NAME, as exp void: EXP_VOID; out : > Ix_srcpos:source_position, Ix comments:comments; out id => ~_srcpos:source position, Ix comments:comments, Ix_symrep: symbol rep; out_id => sm obj_type:TYPE SPEC, sm first: DEF OCCURRENCE; package_body => as id:lD, as_blockstub: BLOCK STUB; package_body = > IX srcpos: source position, Ix comments:comments; package_decl => as id:lD, as_packagede f: PACKAGE DEF; package_decl => Ix_srcpos:source position, Ix comments: comments; package_id => Ix_srcpos:source position, Ix cerements: comments, IX symrep: symbol rep; package_id => sm_spec:PACKAGE SPEC, sm_body: PACK BO]~Y DESC, sm_address: EXP VOID, sm stub: DEF OCCURRENCE, sm first: DEF OCCURRENCE; package spec => as_decl_sl:DECL S, as decl s2:DECL S; package spec => Ix_srcpos:source position, Ix comments:comments; param__assoc s = > as_list: seq of PARAM_ASSOC; param__assoc_s => Ix_srcpos:source position, Ix comments:comments; param_s => as._list:seq of PARAM; param s => Ix. srcpos: source position, Ix _comments: comments; parenthesized => as. exp:EXP; parenthesized => ~._srcpos:source position, Ix_comments: comments; parenthesized => sm_exp_type:TYPE SPEC~ sin_ value; value; pragma => as_id:lD, as._param_assoc_s: PARAM ASSOC S; pragma => IX srcpos:source position, Ix_comments: comments; pragma_id => as list:seq of ARGUMENT; pragma id => ~ symrep:symbol rep; pragma s => as__list:seq of PRAGMA; pragma s => IX srcpos: source position, Ix_comments: comments; private => Ix srcpos: sourceposition, Ix comments: comments; private => sm discriminants:DSCRMT VAR $; private type id => Ix srcpos:sourceposition, Ix_comments: comments, Ix_symrep: symbol rep; private_.type_id => sm._type spec:TYPE SPEC; proc id => IX srcpos:source position, Ix comments: comments, IX symrep: symbol rep;

Section

3.2.B

35

3.2.B

35

4.4.D

49

4,4.D

49

4.4,A

48

3.7.3.B

43

6.1.C

59

6.1.C

59

6.1.C

59

6.1.C

59

7.1.C

63

7.1.C

63

7.1.A

62

7.1.A

62

7.1.A

62

7.1.A

62

7.1.B

62

7.1 .B

62

2.8.A 2.8.A

33 33

6.1.C 6.1.C

59 59

4.4.D 4.4.D

49 49

4.4.D

49

2.8.A

33

2.8.A

33

App,! App. I 10,1.B

76 76

10,1 ,B

69 69

7.4,A

63

7,4.A 7.4.A

63 63

7,4.A 6.1.A

63 57

IV /

Page

181

Page

382

/ Section

JV

proc id => sm spec:HEADER, a m body:SUBP ~DY__OESC, sm IocaUon: LOCATION. sm stub: OEF._OCCURRENCE, sm first: DEF_OCCURRENCE; procedure => as._param_s:PARAM S; procedure => Ix srcpos:source position, tx_~omments: comments; procedure c~ll => as name;NAME, as__param_asso¢_s:PARAM_ASSOC S; procedure_c~ll => Ix srcpos:source_position, Ix comments: comments; procedure._call => sm_normatized_param s:EXP S; qualified => as_name:NAME, as. exp: E~P qualified = > Ix_srcpos: source_position, Ix comments:comments; qualified => sm exp type:TYPE SPEC, sm_value: value; raise = > as name void: NAME VOID; raise = > Ix_srcpos: source position, Ix comments: comments; range => as_expl:E×P, as exp2: EXP; range => Ix arcpos:source_posttion, Ix comments: comments; range => sm base type:TYPE SPEC; record => asJist:seq of COMP; record => Ix srcpos:source_position, Ixcomments: comments; r e ~ r d => sm_size:EXP VOID, sm_discriminants: DSCRMT _VAR_S, sin_packing: Boolean, sm_record_spec: REP_VOID; record_rep => as_name:NAME. as alignment: ALIGNMENT, as comp rep s: COMP_REP S; ~'ecord_rep => ~x srcpos:source_position, |x comments: comments; rename => as name:NAME; rename => b~ srcpos:source_position, Ix_comments: comments; return = > as_exp_void: EXP_VO~D; return => Ix_srcpos:source_position, Ix comments: comments; reverse => aa_id:lD, as_.dscrt_range: DSCRT RANGE; reverse => lx_arcpos:source_position, ix_comments: comments; select => as_select clause s:SELECT_CLAUSE_S. as stm ~ S T M j T, select => Ix_srcpos:source position, Ix_comments: comments; select_clause => as_exp_void: EXP__VOID, aS_atm s: STM S; select, clause => l~'.,srcpos:sourse_position, Ix comments: comments; select_clause s => as list:seq of SELECT_CLAUSE; select_clause s => Ix_srcpos:source position, ix_comments: comments; selected => as_name:NAME. as_designator char: DESIGNATOR_CHAR; selected => Ix_srcpos:source position, Ix comments :comments; selected => sm_exp_type:TYPE SPEC; simple_rep => as_name:NAME, as exp:EXP; simp|e rep => Ix_$rcpos:source_position, ~x comments: comments; slice => as_name:NAME, as. dscrt._ra,ge: DSCRT_RANGE; slice => Ix srcpos:source position, ix comments :comments; slice => sm e~p typo :TYPE SPEC,

DIANA R e f e r e n c e M a n u a l

6,1.A

57

S.I.B 5.1.B

58 58

5.4

61

5.4

51

5.4 4.7

61 50

4.7

50

4.7

50

11.3 11.3

71 71

3.5

37

3.5

37

3.5 3.7.A 3,7.A

37 41 41

3.7.A

41

13.4,A

74

13.4.A

74

8.5 8.5

54 64

5,8 5.8

56 56

5.5.8

55

5.5.B

55

9.7.1.A

67

g.7.1.A

67

9.7. t . B

67

9.7.1.B

67

9.7.1.A 9.7.1.A

67 67

4,1,9

46

4.1.3

46

4.1.3 13.3

46 74

19.3

74

4.1.2

46

4.1.2

46

4.1.2

46

Diana Summary

sm constraint: CONSTRAINT; stm_a --> asJist:seq of STM; 5.1.A stm s => ix $rcpos:source position, 5.1,A txcomments: comments; string_titeral = > Ix srcpos: source position, 4.4. D tx comments: comments, Ix symrep: symbol_rep; string literal => sm exp. type:TYPE SPEC, 4.4.D sm constraint: CONSTRAINT, sm__value: value; stub => Ix srcpos:source position, 10.2.B tx comments: comments; subprogram body => asdesignator:DESIGNATOR, 6,3 as header: HEADER, as block Stub:BLOCK STUB; subprogram body => tx_-srcpos-.'source posi~on, 6.3 Ix_comments: comments; subprogramdec! => as_designator:DESiGNATOR, 6.1.A asheader: HEADER, as_subprogram de¢:SUBPROGRAM DEF; subprogram decl => IX_srcpos:source_position, 6,1.A ix comments: comments; subtype => as id:lD, 3.3.2,A asconstrained: CONSTRAINED; subtype => Ix srcpos:source position, 3,3.2,A Ix comments :comments; subtype_id => Ix srcpos:source position, 3.3.2,A Ix Comments: comments, ix symrep: symbol rep; subtype id => sm type_spec:CONSTRAINED; 3,3.2.A subunit => asname:NAME, 10,2,A as _subunit..body: SUBUNIT BODY; subunit => Ix srcpos:source position, 10.2,A Ix comments:comments; task_body => as id:lD, 9.1~B as block stub:BLOCK STUB; task body => Ix'srcpo~.source_posi~on, 9.1. B ix comments:comments; task body_id => ix srcpos:source position, 9.1.B ix comments :comments, ix symrep: symbol rep; task_body id => sm_typo_spec:TYPE SPEC, 9.1,B sm body: BLOCKSTUB_VOID, sm_first: DEF_OCCURRENCE, sm stub: DEF_OCCURRENCE; task._decl => as |d:i[), 9.1.A as task def:TASK_DEF; task._decl => ix srcpos: source position, 9.1. A txcomments: comments; task spoc => as decl s:DECL_S; 9.1.A task spoc => Ix .srcpos:source._position, 9.1.A Ix comments: comments; task spec => sm body:BLOCK_ STUB._VOID, 9,1.A sm address: EXP__VOID, sm storage size: EXP_VOID; terminate => ix srcpos:source_position, 9.7,1,B Ix comments: comments; timed entry => as stm sl:STM_S, 3.7.3 as stm s2:STM_S; t i m e d e n t r y => ix srcpos:source_position, 9.7.3 Ix comments: comments; type => as id:lO, 3.3,1.A as dscrmt var s: DSCRMT._VAR_S, as type spec: TYPE SPEC; type => ix srcpos:source._position, 3.3.1.A Ix comments:comments; type_id => IX srcpos:source position, 3.3.1.A Ix comments: comments, Ix symrep: symbol rep; type id => sm type spec:TYPE_SPEC, 3.3.1.A sm first: DEF_OCCURRENCE; universal fixed => ; App. I universal_integer => ; App. I universalreal => ; App. I

Section

51 51 49 49 70 60 60 57 57 36 36 36 36 70 70 65 65 65 65

65 65 65 65 65 67 68 68 35 35 35 35 76 76 76

IV /

Page

]83

Page

184 1 S e c t i o n tV

use => as l i s t : s e q of NAME; use => I~_srcp0s:so~rce,position, Ix comments: comments; used t~tn id => ix srcpos:~ource position, tx_~comments: comments, ~x .~ymrep: symboLrep; used bltn id => sm operator,operator; used bltn. op => ~x srcpos:source position, Ix.comments: comments, Ix.symrep: symbol rep; used bltn_op => sm operator:operator; used char => tx.srcpos:source position, Ix comments: comments, Ix symnsp: sym b~l._rep; used char => sm defn: DEF OCCURRENCE, sm e~p type: TYPE_SPEC, Sm vatue: value; used name id =:. l~ srcpo¢:source._position, IX comments:comments, lx~symrep: symboLrep; used name ~d => ~m def~:DEF OCCURRENCE; used~objecEid => lX srCpos:source positioh, ~x comments: comments, Ix symrep: symbol rep; used._object id => sm exp type: TYPE SPEC, sm defn: DEF OCCURRENCE, sm value: value; used_op => Ix srcpos:source position, ~x commen~: comments, tx..symrep: .%,rebel rep; used op => sm defn:DEF OCCURRENCE; var => as id s:ID $, as~ty--pe spec: TYPE_SPEC, as_object def: OeJECT OEF; vsr => ~._srcpos:source position, Ix comments:comments; vat id => Ix srcpos: source..positton, Ix comments :comments, ix symrep: symbol rep; var id => sm obj type:TYPE SPEC, sm address:EXP VOID, sm~obL def: OBJEC'[ DEF; variant => as choice s:CHOICE $, as record: INNER RECORD; variant = > ~ s r c p o s :source position, Ix comments:comments; variant part => as name~NAME, as veri~n~ s: VARIANTS; v a r i a n t p e r t => Ix srcpos : s o u r c e position, Ix comments: comments; v a r i a n t s => as. list:seq of VARIANT; v a r i a n t s => Ix srcpos:seurce position, Ix comments: comments; void => ; while => as__exp:E~P; while => Ix. srcpos:~urce position, Ix commentsi comments; with => as list:seq of NAME; with => Ix_srcpo~:source position, Ix comments:comments;

~)IANA R e t e r e n c e

8,4 8.4

54 C~

4.~.A

~k5

4.1.A 4.1.A

45 45

4.t.A 4.1.A

45 45

4. t . A

45

4.1.A

45

4.1.A 4.1.A

45 45

4,1,A

,~5

4.1.A

45

4.1.A 3.2.A

45 34,

3.2.A

34

3.2.A

34

3.2.A

34

3.7.3.A

43

3.7.3.A

43

3.7.3.A

43

3.7.3.A

43

3.7,3.A 3.7.3.A

43 43

2 5.5,B 5.5.B

32 55 55

10.1.1,13 10.1.1.B

70 70

Manual

Diana Names

Page 185 APPENDIX V DIANA NAMES

This

appendix

definition;

is

an

index of

all

of

the

these n a m e s include class names,

attribute types.

The section

number

the

The

CHOICE CHOICE_S COMP COMPILATION COMP_ASSOC COMP_REP COMP REP S COMP REP VOID COMP. UNIT COND CLAUSE CONS~rRAINED CONSTRAINT CONTEXT CONTEXT._ELEM DECL DECL_S DEF CHAR DEF~ID

DEF OCCURRENCE DEF OP DESIGNATOR DESIGNATOR CHAR DSCRMT._VAR DSCRMT VAR S DSCRT..RANGE DSCRT RANGE S DSCRT--'RANGE_~VOIO ENUM UtERAL EXCEP-TIONDEF EXP

node names,

occur

In

the

attribute l a b e l s ,

DIANA and

page-number-list

list gives all the sections of C h a p t e r 2 which

page number

name m a y be found. ACTUAL ALIGNMENT ALTERNATIVE ALTERNATIVES ARGUMENT BINARY_OP BLOCK STUB BLOCK STUB_VOID Boolean

which

Each name is shown in the form

name [section-number-list]

name,

names

make use of

list gives p a g e s of this d o c u m e n t on w h i c h

Either list may be split a c r o s s several lines, [6.4, 12.3.C] [ 13.4. A] [5, 41 [5.4, 5,6] [App. 11 [4.4. A] [6,3, 7.t.C, 9. t.B, 10,2.8] [9.1,A, 9.1.B, 12.1.A] [3.4, 3.6.A, 3.7.A, 3.8, 6.1,C, 6.41 [3.7.3.A, 3.7.3.S1 [3,7.3.A, 4.3,e, 5.42 [3.7.A, 3.7.B, 3.7.3.A] [ 10.1, A] [3,7.2, 4.3.A, 4,3.B] [3.7,8, 13.4.B1 [13,4.A, 13.4.B] [3.7.B, 3,7,t 2 [10.1.A, 10.1.B] [5.3.A 1 [3.2.A, 3.3.2.A, 3,3.2,B, 3,4, 3.6.A, 3.8, 4,82 [3.3.2.B, 3.3.2.C, 4.1,2, 4,3.A,

61, 74 53 53, 76 48 60, 65, 37,

[10.1.1 ,A, 10.1 .B] [10.1,1.A, 10.1.B, 10.1.1.B] [3.1, 3,9.A, 3.9,8, 7.1.B] [7.1.8, 9.1.A, 12.3.A] [2.3, 3.5.1.B] [2.3, 3.2.A, 3,2,B, 3.3.1,A, 3.3.2,A, 3.5.1.8, 3.7.B, 3.7.1, 5.1.B, 5,5.A, 5.5,B, 6.1,A, 6,1.C, 7.1,A, 7,4.A, 9.1.8, 9.5.A, 1I.t, 12.1.A, App. 11 [2.3, 3.2.A, 3.3.1,A, 3.7,1, 4,1.A, 6.1.A, 6.1.C, 7.1,A, 9.1.B, 12.1.A] [2.3, 6,1.A] [2,3, 4.1.A, 4,1.3, 6.1.A, 6.3,

69 69, 33, 62, 32, 32, 42, 62, 76

70 44, 65, 38 34, 51, 63,

32, 59, 32, 32,

34, 35, 42, 45, 57, 62, 65, 71 57 45, 46, 57, 60, 61

[4.1.31 [3.7.11 [3.3,1.A, 3.7.A, 3.7,1, 7.4,A] [3.6.A, 3.6.0, 3.6,C, 3.7.3.8, 4.1.2, 5,5,8, 9.5.A] [3.6.A] [9.5. A1 [3.5.1.A, 3.5.1.B1 IS. 5, 11.11 [3,2.A, 3.2.B, 3.5, 3.5.7, 3.5.9, 3.7.3.8, 4.1.1, 4.1.4, 4.3.A,

46 42 35, 41, 42, 63 40, 43, 46, 55, 66

4.4.Ol

s.4]

43 43, 41, 69 42, 41, 74, 41, 69 53 34,

73 55 G3, 65, 70 71 40, 41, 44, 59, 61 47, 53 43 47 75 75 42 36, 37, 40, 44, 50

36, 37, 46, 47, 49

40 66 37, 64, 34, 47,

62 73 35, 36, 38, 41, 54, 55, 57, 59, 65, 66, 70, 71,

38 70 35, 37, 39, 43, 46, 48, 49, 50, 52, 53,

the

Page 386 / Sect~or~ V

EXP_CONSTRAtNED ExP.$ EXp v0|o

FORMAL_SUBPROG DEF FORMAL__TYPE._SPEC GENERIC._.ASSOC GENERIC._ASSOC S GENERIC_HEADER GENERIC_PARAM GENER.~C.. PARAM. S HEADER ~D ~DS INNERRECORD EEM ITEM_S iTERATION integer LANGUAGE LOCATION LOOP MEMBERSHIP._OP NAME

NAMES NAME VOID OBJE~ OEF OP PACKAGE.._DEF PACKAGE SPEC PACK BODY._DESC PARAM PARAM ASSOC PARAM ASSOC. S PARAM S PRAGM~ PRAGMA S RANGE RANGE. VOID REP REP VOID Ration,st SELECT CLAUSE SELECT-CLAUSE S SHOR T_CISC,Uff_OP S%'~A STM S SUBPROGRAM DEF SUBP BODY I~'ESC SUBUNIT BODY TASK DEF TYPERANGE I'YPE SPEC

DIANA R e f e r e n c e M a n u a l

4,3.B, 4..~.A, 4.4.B, 4.4.0, 4.5, 4,7, 4.5, 5.2, 5.4, 5,5.B, 6,4, 9.6, t3.3, t3°4.S, 13.5, 13.8]

55, 61, $6, 74, 75

~3,7.2, 4.1,1, 4.3.A, [3.2.A, 3;4, 3,5.1.A, 3,5,9, 3.6.A, 3.7.A, 3.8, 5.3.A, 5,7, 5,8,

42, 34, 42, 62,

"46, 37, 44, 65,

57, 72 73 73 71 72 71, 57, 32,

72

6.4, 9.5.B] 3.5.4, 3.5.7, 3.7,B, 3.7.1, 6. t.A, 6.1.C,

7,1.A, 9.1.A, 9.5,A, 9.7.1,S, 13.4,.A] ~6,1.A, 12.1,C]

~12, I.O]

[12.3.A, 12.3,B, 12.3.C] ;12,3.A] [ ~2. I,A] [12.1.B, 12.1;C} ~12.1.A, 12.1.B] [6~1.A, 6.1,B, 5.3, 9.5,A] [2,3, 2.8.A, 3,2.C, 3.3.I,A, 3,302.A, 4, t,4, 5.5.A, 5.5,B, 7.~.A, 7.1.C, 9.1.A, 9. t,B, 12.1.A] [3,2,A, 3.2.B, 3.2.C, 3.7.I, 5,1,B, S.I.C, 7.4.B, 11.1] ~3.7.3,A]

[5,1. A] Z6,1,A] ~5.1.D, 5.5,A, 5.7] C4.4. B]

57

[3.3.2.B, 3.6.B, 3.7.1, 3.7.3.A,

~.5, 9.5.B, 9,5.C, 5.10, 10.1.1.B, 10,2.A, 12.1.C, 12.3.A, 13.3, %3.4,A, 13.4.B, 13.5, 13.8] I s , lO] ~5.7, 5.1.B, 11.3] [3.2.A, 3.7.1, 8.5] ~2..3] ~7,1.A, 7.1,B) 8.5, 12.3.A] ~7.1.A, 7. I.B] C7.1.A]

[6.1. C]

[2,8.A) 6,4] ~2,8.A, 6.4) 9.5.B] [6.1.B, 6.1,C, 9.5.A, 9.5.C] [2.8.A, t0.1,B] [ I O . t . 8 , 13.4.A] [3=3.2.C, 3,5, 3.5.4, 3.5.7, 3.6.C, 4,4,8, 13.4.B] [3,5.7, 3.5.9] ~3,7.A, 3,9.A, 13.1]

[3.7.A]

E3.4, 3.5.9] ~9;7.1.A, 9.7.1.B] [9.7, 1).A]

;4.4.A]

54, 55 36, 37, 38, 39 57

52, 54, 56

36, 47, 59, 70,

40, 48, 5t, 72,

42, 49) 63, 73,

43, 50, 64, 74,

56, 58, 71 34, 42, 64 32 62, 54, 73 62 59 33, 33, 58, 33, 69, 37,

61 61, 66 59, 66 6.9 74 38, 39, 40, 48, 75

31(3 41, 44, 74 41 37, 39 67 57 51, 52, 54, 67

[6.1.A, 8.5, 12.1.C, 12.3.A] [e, t. A]

57, co4, 72~ 73 57 70 65

[I0.2.A]

[9.1.k] [4.4.D] [3.2.A, 3.2.B, 3.3.1.A, 3.3.1.B, 3.3.2.B, 3.5, 3.5.1.B, 3.5.4,

45. 46, 52) 56, 66, Co8, 75

68

ES.1.A, 5.1.B, 5.1.C, 5,1,D, 5.5.A, ~.7. I .B] ~5.1,A, 5.3.A, 5.4, 5.5.A, 5.6, 9.5.C, 9.7.1.A, 9.7.1.B, 9.7.2)

9.7.3]

56 40, 41, 57, 59, 74

34, 35, 42, 51, 59, 63, 70

44, 55

~,I,A, 4.1.B, 4,1.1, 4.1.2, 4.1.3, 4,1,4, 4.4.8, 4.4.0) 4.6) 4,7, 5.2, 5,7, 5.9. 6.1,C) 6.4, 7,4,B,, 5.4.

61, 39, 56, 67,

72 58, 60, 66 33, 35, 36, 47, 54, 55, 62, 63, 65, 71

[3,s,8] [3.9.s, 5.5] ~5,5.A, 5;5.B]

~3.3.2=B, 3,4, 3.5.1.A, 3.5.1.B, 3.5.4, 3.5.7, 3,5.9]

47, 38, 53) 66,

51, 53, 54, 55, 66, 67, CoO

34, 35, 36, 37, 3.8, 39, 41, 42, 44, 45, 46, 47,

Section V / Page 187

Diana Names

3.5.7, 3,5.3, 3.7,B, 3.7.1, 3.8.1, 4,1.A, 4,1.1, 4.1.2, 4.1.3, 4.1.4, 4.3.A, 4,4.A, 4.4.B, 4,4.D, 4.6, 4.7, 4.8, 5.5.B, 6.1.C, 6.4, 7.4,A, 9,1.A, 9.1,B, 12,1,D, App. I]

48, 49, 50, 55, 59, 61, 63, 65, 72, 76

UNIT BODY USEI)'_ID USED OP VAR~T VARIANTS abort accept access address aggregate alignment all allocator alternative alternative s and then ergu-ment id array as_actual as alignment aLalternative s as binary op as block stub =s_-choic;_s as._comp rep. s as_constrained asconstraint as context as decl s as dec! 81 as decl 82 as--desic~nator asdesignator c h a r as dscrmt var s as dscrt range as .dscrt_range_s as _dscrt_range void as exception def as exp

[lO.l.B]

as expl as_exp2 as exp constrained aLexp_s as exp._void

[3.5, 4,4.A] [3.5, 4.4.A]

37, 48 37, 48 ,so

[5.3.A, 5.7, 5.8, 6.1.C, 9.7,1.B, 13.4.A] [12,3.A]

53, 56, 59, 67, 74

aLgenertc assoc a as_generic_header as ¢Jeneri¢ param s asheader as id as_id a as item s as iteration as list

as membership_op asname

[5.4] [5.4]

ss 32, 32, 43 43 51, 52, 36, 74, 47, 74 45, 49, 53 53

[4.4.k]

48

[6.1.A, App. q [3.3,1.B, 3.6.A]

57, 76 36, 40

[2.3, 4.1.A] [2.3. 4,1.A] [3.7.3,A] [3.7.3.A] [5.1.c, 8.10] [5.1.D, 3.5.C] [3.3.1,B, 3.8] [13.1, 13.5] [4.3.A, 4.4.D] [13.4.A] [4.1.A, 4.1.3] [4.4.D, 4.8]

[s.4]

[13.4,A]

[5,4, 5.6]

[4.4.A] [6.3, 7,1.C, 8.1.B] [3.7.3,A. 4,3.B, 5.4]

[13.4.A]

[3.3.2.A, 3.4, 3.6.A, 3.8] [3.3.2.B]

[1O.I.B]

[8.I.A] [7.t,B] [7.1,B] [6.1.A, 6.3, 6.4]

[4.1.31

[3.3.1,A] [4.1.2, 5.5,B] [3.6.A]

[8.5.A]

[11.1] [3.2.8, 3.5.7, 3.5.3, 4,1.4, 4.3.B, 4.4.B, 4.4.D, 4.6, 4.7, 5.2, 5.4, 5,5,B, 9.6, 13.3, 13,4.B, 13.5,

13.8]

[4,8] [4.1.1]

[12.1.A] [12,1.A]

[6.1.A, 6.3] [2.8.A, 3.3,1.A, 3.3.2.A, 4.1.4, 5.5.A, 5.5.B, 7.1.A, 7,1.C, 9.1.A, 9.1.B, 12.1.A] [3.2.A, 3.2.B, 3.7.1, 5.1.B, 6.1.C, 7.4.B, 11.1] [5.S] [5.S.A] [2.8.A, 3.2.C, 3.5.1.A, 3.6,A, 3.7.A, 3.7.1, 3,7,2, 3.7.3,A, 3.8.B, 4.1.1, 4.3.A, 5.1.A, 5.3.A, 5.4, 6.1.C, 7.1,B, 8.4, 8.7.1.A, 9.10, 10.1.1.A, 10.1.A, 10.1.B, 10.1.1.B, 12,1.B, 12.3.A. 13.4.B, App. |]

[4.4.8] [3.3.2.B, 3.6.B, 3.7.1, 3.7.3.A,

4.1,1, 4,1.2, 4.1,3, 4.1.4, 4.6,

45 45

r~

66 44 75 49 46 50

61

74

53, 48 60, 43, 74 36, 36 SS r~ 62 62 57, 46 35 46, 40 68 70 35, 52,

55 63, 65 47, 53 37, 40, 44

60, 61 55

39, 47, 48, 48, 50, 53, 55, 66, 74, 75

46

73

71 7'1

57, 60 33, 35, 36, 47, 54, 55, 62, 63, 65, 71 34, 35, 42, 51, 59, 63, 70 54 33, 43, 59, 70,

35, 44, 62, 72,

37, 46, 64, 73,

40, 47, 67, 75,

41, 42, 51, 53, 68, 69, 76

48 36, 40. 42, 43, 46, 47, 50, 52, 56, 59, 61, 63,

Page ] 8 8

/ Section V

as name s as=namevoid aLobject_def aLpackage_def aLparam._¢ssoc__s as param s aLpragma_s aLrange aLrange._void as record as select ¢|ause s asstm as stm s as stm 81 as stm 82 a~ subprogram def as subunit body aLtask .def aS_ type_range aLtype_spe¢ as unit._body aLvartanLs

a~n

a$$0C a1~r,_id attribute atb'tbute, call btP~ty block box case cd impl._size choices code corr~men~

¢omp id comp_rep ¢omp rep s ¢omp unit compilation cond._clause cond entry const id constant constr=ined context conversion

decks

def char def _op

DIANA R e f e r e n c e ManuaU

4.7, 5.2, 5.9, 6.1.C, 6.4, 7.4.B, 8.5, 9.5.B, 8,5.C, 10.2,A, 12.3.A, 13.3, 13.4.A~ 13.4.B, 13.5, 13,81

64, 66, 70, 73, 74, 75

E5~7. 8.1.B, 11.3]

56, 58, 71

[3,2.A, 3.7,1] [7. t,A]

E2.S,A, 6.4. 9.5,B] [8. I.B, a.S,k, a.5.C] [tO, 1.B, 13,4.A]

3.5,4,

13.4.8]

[3,5.7, 3;5.9] ~3.7.3,A} ~9,7,1.A]

~5,1.B, 5.5,A]

[5,3,A, 5.4, 5,5.A, 5.6, 8.5,C, 9o7.1.A, 9.7.1.B] [8.7.2, 9.7.3] [8.7.2, 9.7.31 [5,1 .A] [10.2.A]

[S.I,A] [4.4.e]

34, 42 52 33, 61, 66 88. 66 $9, 74 38, 75 39 =.3 67 51, 54 53, 54, 55, 66, 67 $8 68 57 70

35

[3,2,A, 3.3,1,A]

34, 35

[~,t,C, 5.2]

51, 52 61, 73 76 37, 45, 47 37, 45, 47

[1o.1,8.] [3,7.3.A] [8,4, lapp, [3,5, [3.5,

12.3,B] I] 4.1.A, 4.1.4] 4.1.A, 4.1.4]

E4.4.A]

[5.1,D, 5.6, 6.1.A, 6.3, 7,1,A,

9.1.A] [12.1.c] [5.1.0, 5.4]

52, 55, 57, 60, 62. 65

72 52, 53

~3.3.2.B, 3.4, 3.5.1,A, 3.5.4, 3.5.7, 3.5.9] ~3,7.3.A] [5.1.C, 13.6] [2.8.A, 3.2.A, 3.2.B, 3.2.C, 3.3,1,A, 3,3.2.A, 3,3.2.B, 3,4, 3~5, 3.5.1.A, 3.5.1,B, 3.5.4, 3.5,7, 3.5,9, 3.6.A, 3.6.B, 3,7.A, 3.7.B, 3.7,1, 3.7.2, 3.7.3.A, 3.7.3.8, 3.8, 3.9.B, 4.1,A, 4,1,1, 4,1.2, 4.1,3, 4.1,4, 4.3.A, 4.3.B, 4;4,A, 4.4,B, 4.4.0, 4.6, 4,7, 4.8, 5.1.A, 5.1,B, 5.1.F, 5.2, 5.3.A, 5.4, 5.5.A, 5.5.B, 5.6, 5.7, 5.8, 5.9, 6. t,A, 6.1.B, 6,1.C, 6.3, 6.4, 7.1,A, 7.1.1B, 7.1.C, 7.4.A, 7.4.B, 8.4, 8.5, 9,1.A, 9.1,B, 9.5.A, 9.5.B, 9.5;C, 9.6, 9.7,1.A, 9,7.1,8, 9,10, 9.7.2, 9.7.3, I0,1.1,A, 10.1.A, 10,1.B, 10,1,1.B, 10.2,A, 10,2,B, 11.1, 11.3, 12.1,A, 12.1.B, 12.1.C, 12.1.D, 12.3,A, I3,3, 13,4.A, 13.4.B, 13.5, 13.8] ~3.7.B] [13,4.B]

36, 37, 38, 39

[5.1.0, 9.7.2] [3.2.A.] [3.~, 3,2.A] [3,3.2;B, 3.6.C]

52, 68 34 33, 34 38, 40

[13.4,e.1 [lO.1,e] [10.1.A] ~5.3.A]

[10.1:1.A] [4.~,.D, 4,6] [7,1. B] [3.5. I .B] [6.1 ,A]

43 51, 33, 38, 45, 51, 57, 63, 69, 75

75 34, 40, 46, 52, 58, 64, 70,

4| 75

75 ss Ss 53

69 45, so 62 38 57

35, 41, 47, 53, 59, 65, 71,

36, 42, 48, 54, 60, 66, 72,

37, 43, 49, 55, 61, 67, 73,

38, 44, 50, 56, 62, 68, 74,

•

->"

I~

.

.

•

..a

•

UIlU(~...),-_ " "" (D o

.

,,-~-~"

.

• .0

"

-

-

.

O~

o

o

•

.,.,.~J.,~.b,

"

o" "

.b

>,

•

).

• m • -" ~ l ~• - b .

..IQ2.~i-iO'~.lt

.

,

~-,

.

j~

•

•

..I

.

U~U~. * ~ " 1 ~~ . ..~ r"

~(,O(U-

), "

v ~t,O"

(~.,,~m(.~.

®

I

~'E55 '-

~.a

~

1.0

-"-'

°~'-~''3~

I'*" =E~

-

~-J

-.^

EE~'~'.~.~.~I ..o~.

I I L

o

(.,'~(11

.

C;O

I

>"

-,

~ "

~

"4""5.5.1~;EE~1 31<1<1"'~3"11 ~ 8

~.

~D

g

(D

<

0"; (I) 0 0=J

u)

3

Z

3

E~

Page ] 9 0 / Sectio~'~ V

tx..symrep

membership name s

named named_stm named stm id no defsult no~_in Null acc4~$s null comp null stm num-'ber number id numberrep numeric literal operator-or else otEers out out id package._body package_decl package id package, spec param_assoc _s par~m s parenthesized pragm~ pragmLid pragma s priv'~te private_type td proc id procedure procedure c~ll qualified raise range record record rep rename return reverse select select_clause se|ect_dause s selected seq of ALTERNATIVE seq of ARGUMENT seq of CHOICE seq of COMP

DIANA R e f e r e n c e M a n u a l

3.3.1oA, 3.3.2.A, 3.3.2,B, 3.4, 3,5, 3.5.1.A, 3.5.1.B, 3.5.4, 3.5,7, 3=5.9, 3.6.A, 3,6,B, 3.7.A, 3.7.B, 3.7.1, 3,7.2, 3.7.3,A, 3,7.3,B, 3,8, 3.9,B, 4.1.A, 4.1.1, 4.1.2, 4~1,3, 4.1.4, 4.3.A, 4,3.B, 4.4,A, 4.4.B, 4.4.D, 4,6, 4,7, 4.8, 5.1.A, 5,1.15, 5.1.F, 5.2, 5.3.A, 5,4, 5.5,A, 5,5,B, 5.6, 5,7, 5.8, 5.9, 6.1.A= 6.1.B, 6.1.C, 6.3, 6.4, 7.1.A, 7.1.B, 7.1.C, 7.4.A, 7.4.B, 8.4, 8,5, 9.1.A, 9.1.B, 9,5.A, 9.5.B, 9.5.C, 9.6, 9.7.1,A, 9.7.1.B, 9.10, 9.7.2, 9.7,3, 10.1.1.A, 10,1.A, 10.1.B, 10,1.1.B, 10.2.A, 10.2.B, 11.1, 11,3, 12.1.A, 12.1.B, 12,1.C, 12,1.1D, t2.3.A, t3.3, 13.4.A, 13,4.B, 13.5, 13.8] [3.2.A, 3.2.B, 3.3.1.A, 3.3.2.A, 3.5,1.B, 3,7.B, 3.7,1, 4.1.A, ~.4.D, 5,1.B, 5.5.A, 5,5,B, 6. I,A, 5:t.C, 7,1.&, 7,4.A, 9. I,Bo 9.5.A, 11.1, t2. I.A, App, I]

39, 45, 5t, 57, 53, 69, 75

40, 46, 52, 58, 64, 70,

34, 45, 59, 7t,

35, 36, 38, 41, 42, 49, 51, 54, 55, 57, 62, 53, 65, 66, 70, 76

[4.4.B] [9. lO]

98

[5.1.0, 5.5.A] [5.S.A] [12.1.c]

52, 54 54 72

[4.3.B]

[4.4.B] 4.4;D] 3.7.B]

[5. t.c, 5.1.F] £3.1, 3,2.B] [3.2. B]

[4.4,D] [4.4.0]

41, 47, 53, 59, 65, 71,

42, 48, 54, 60, 66, 72,

43, 49, 55, 61, 67, 73,

44, 50, 56, 62., 68, 74,

48

47

48 49 41

61, 52 33, 35

35 49 49

[4. t. A]

{4,4,A]

E3.7.3.B]

[6.1.c] ~6.1.c]

[3.9.B, 7.1,C, 10.1.B, 10,2,A] [3.1, 7.1.A, 10.1.B] ~7.1.A]

[7~1.B, 12.1.A]

43 59 59

44, 63, 69, 70 33, 52, 69 62 52, 71

[2,8.A]

33

[4.4.D] [2.8.A, 3.1, 3.7.B, 5.1.C, 5.4, ~.7,1.B, t0,1.B, 13.4.B] [6. t.A, App. l]

49 33, 41, 5t, 53, 67, £)9, 75 57, 76

[7.4.A]

53

[6, I. A] [6.1.B, 12.1.A] [5.1.C, 6.4] [4,4.0, 4.72 [5,1,C, 11.3]

57 58, 51, 49, 51,

[3.3.1.B, 3,7.A] [13.1, 13.4.A] [6;1.A, 7.1.A, 8.5] [5.1.C, 5.8] [5.6.B] [5:1.D, 9.7.1.A]

36, 41 74 57, 52, 64 51, 56

C9.7. %.A] [4.1.A, 4.1.3]

67 45, 46

[6:1 ,c]

[10.1.B] [7.4.A]

[3.6]

[9.7.1. B] [5.4]

lapp. I]

[3.7.3.A] ~3.7.A, 3.7.3.A]

59

69

71 61 50 71

37

52, 67 67 s3

76 43 41, 43

~,

°

"

. . . .

m~

~

°

l
.

•

I I I.

~

l~,l,,,l.,~,l,r,l o

~

loIoI

~

~

i~

I I I I..,

~

I~.

•

.

-,_

I Iclcl,~l =

~

,,

I I

.

.

~

...~,1

:o[m>=:0[~:

zz

=oopzz~[

..a

-o D)

m

3

o

o

Pa e

192 / Section V

~tm s stria'g_ fiter~ stub subprogram body subprogram decl subtype subtype id subunit symbol rep

task._body task body_id task de¢l task _spac terminate tlmedentry type type id unfversaLfixed univer~l integer univers~Lrea! use used bltn ld used bltn_op used char used name id us~_--obje~_~ used op value vaF vat id vaunt variantpart variants void while with

DIANA R e f e r e n c e Manuat

5.~, 6.1.A, 6.1,B, 6,1.C, ~.3, G,4, 7~I,A, 7.1.8, 7.1.C, 7.4.A, 7.4.B, 8,4, 8.5, 9.1.A, 9,1,B, 9.5.A, 9.5,B, 8.5,C, 9.6, 9.7.1.A, 9,7,t.B, 8,;t0, 9,7,2, 9.7.3, 19. t~1,A, 10.1.A, 10.1.B, 10.1,1.B, t0,2,A, 10.2,B, 11.1, 11.3, 12.1,A, ~2.1.B, t2.1,C, 12,1,D, 12,3,A, ~3.3, t3.4=A, I3.4.B, 13.5, 13.8] [5o 1 .A]

~4,4.o]

[6.1.A, 7.1.A, 9.1.A, 19.2.B] ~3,9,B, 6.3, 10;1,B, 10,2,A] [3.1, 6.1.A, 10.1.B, 12.1.C] [3.1, 3.3.2.A] [3.3,2.A] [10.1,B, t0.2.A] [3,2.A, 3,2.B, 3.3,t.A, 3,3.2,A, 3.5,1.8, 3.7.B, 3.7,1, 4.1.A, 4.4.0, 5.1.1B, 5.5.A, 5.5.B, 6.1.A, ~.~.C, 7. I=A, 7.4,A, 9.1.B, 9.5.A, ~1.1, 12.1.A, App. l] [3.9.1B, 9.1.B. 10.2.A]

r3.1, 9.1.A] [9. t.A] [~,7,1.B] [5.1.D. 9.7.3] ~3. t, 3.3.1.A, 12.1.(3] [3.3,t.A] lapp. i] [App. I] [App. l] ~3.9.A, 8.4, 10.1.1,A] [4.1.A] [4. t .A] [4.1.A, 4,1.3] [4.1.A] [4.1 .A] [4.1.A] [4.1.A, 4.1.4, 4.4.A, 4.4.B, 4.4.D, 4,6, 4.7, 4.8, 6,4] [3,1, 3.2,A, 3,7.B] [3.2.A] [3.7o3.A] ~ . 7 . B , 3.7.3.A] ~3.7,3,A] ~2; 3.2.A, 3,3.2.B, 3.5.7, 3.7,A, 3,7.B, 3.8,1, 5.5.A= 5.7, 6.1.A, 7.1.A. 9.1.A, 9.5.A, 10.1.8, 11.1] [5.5.0] [lo.1.1.o]

5I 49 57, 44, 33, 33, 36 69, 34, 45, 58, 71,

62, 65, 70 60, 59, 70 57, 69, 72 36 70 35, 36, 38, 41, 4?., 49, 51, 54, 55, 57, 62-, 63, 65, 66, 70, 76

44, 65, 70

33, SS 85 87 52., 68 33, 35, 72 35 76 76 44, 64, 69 45 45, 46

~S

4~ 45, 47, 48, 49, 50, 61 33, 34 43 4% 43 32, 54, 69, 55

70

34, 41 43 34, 36, 3<3, 41, 44, 56, 57, 62, 65, 66, 70

Diana Attributes

Page ]93

APPENDIX Vl DIANA ATTRIBUTES

This nodes,

appendix

Is an

index of all of the attributes w h i c h

label = type [section-number-list] The

occur

In

DIANA t r e e

E a c h attribute is s h o w n in the form

section

number

the a t t r i b u t e . attribute attributes

may are

list gives all the s e c t i o n s of C h a p t e r 2 which

The p a g e n u m b e r be

page-number-list

found,

grouped

Either into

list gives p a g e s of this d o c u m e n t list

four

may

sections:

be

split

across

structural,

several

lexlcah

make

use of

on which lines.

semantic,

the The and

code.

VI. 1.

Structural Attributes

S t r u c t u r a l a t t r i b u t e s d e f i n e the b a s i c s h a p e of the DIANA tree. as_.actual: ACTUAL [s,4] as._alignment: ALIGNMENT [13.4.A] -%._alternative_ $: ALTERNATIVE._S [5,4, 5,s) a%_binary._op:BINARY OP 4.4.A1 as blockstub:BLOCK_STUB 6,3, 7.1,C, 9.1.B] as choice s:CHOICE S [3.7.3,A, 4,3.B, 5,41 as~comp_~ep s:coM-'P REP S [13.4.A] as._constrained: CONSTRAINED [3.3.2.A, 3,4, 3.6.A, 3.8] as constraint: CONSTRAINT [3.3.2.B] as context: CONTEXT [~o.l.e] as decl sl:DECL_S [7.1.B] as.. decl 32: DECL_S [7.1 .B] as decl s:DECL_S [9. I.A3 ss._designator:DESIGNATOR [6.1.A, 6,3, 6.4] as_designator char: OESIGNATOR CHAR

[4,1.s]

as dscrmt vat s:DSCRMT VAR S [3.3.1.A] as_dscrt range: DSCRT_RANGE [4.1.2, 5.5.B] as dscrt range_.$: DSCRT_RANGE_S [3,6.A] a%_d~-'rt_range void: DSCRT RANGE_VOID [S.5.A] as_exception_.def: EXCEPTION_DEF [ 11+1] as expl :EXP [3.5, 4.4.A] a%._exp2:EXP [3,5, 4.4,A] as._exp:EXP [3.2.B, 3,5,7, 3.5.9, 4.1.4, 4.3.B, 4,4.B, 4.4.D, 4,6, 4,7, 5.2, 5.4, 5,5,B, 9.6, 13.3, 13.4,B, t3.5, 13.e] as exp constrained: EXP__CONSTRAINED [4.8] as._exp_s: EXP_S [4,1,1] asexp._void:EXP._VOID [5,3.A, 5,7, 5,8, 6,1,C, 9.7.1.B, 13,4.A] as_generic._assoc_s: GENERIC_ASSOC S [12.3,A] as._generic._header: GENERIC._HEADER [12,1,A] as_generic_.param s: GENERIC_PARAM S [12,1,A] asheader:HEADER [6,1,A, 6.3] as id:lD [2.8,A, 3,3,1.A, 3.3.2.A, 4.1,4, 5,5.A, 5.5,B, 7,1.A, 7.1.C, 9,1.A,

61 74 53, 48 60, 43, 74 36, 36 69 62 62 65 57.

55 63, 65 47, 53 37. 40. 44

50. 61

46 35 46. 55 4O 66 7O 37. 37. 35. 52.

48 48 39. 47. 48. 48. 50. 53. 55. 66. 74. 75

50 46 53, 56, 59, 67, 74 73 71 71 57, 60 33, 35, 36, 47, 54, 55, 62, 63, 65, 71

Page ~

/ S e c t i o n Vi.~

DIANA R e f e r e n c e M a n u S l

9.1.8, 12. I.AJ [3.2.A, 3.2.8, 3.7.3, 5.1.8, 8.~.C, 34, 35, 7.4.8, 11,1] 70 aLltem_s: f f E M S 55 [s.6] as iteration: I~RA¥10N [5.5.A] 54 as list:~q of ALTERNATIVE [~.4] 53 as tlst:~¢! of ARGUMENT 76 [App. Ij aLlist:l~e q of CHOICE 43 [3.7.3.A] aLltst:s(~q of COMP 41, 43 [3,7.A, 3.7.3.A] as iist,seq of C O M P A,?:~OG [3.7.2, 4.3.A] 42, 47 aLlist:aeq of COMP REP 75 [13,4.B] as_list:~q of COMP UNIT 69 [10,1.A] as_tist:seq of COND_CLAUSE [5.3.A] 53 as iist:seq of CONTEXLELEM [10.1,1.A] 69 as!ist:seq of DECL 6,2 ~7.1.t3] aLlist:we q of DSCRMT_VAR 42 [3,7.1] as list.'l~eq of OSCRT RANGE 4O [3.6.A] as._|ist:seq of ENU~ITER~L 37 [3.5.1.A] aLiist:se q of EXP 46 [4.1.t] as_list:~q of GENERIC ASSOC [12,3.A] 73 72 as._l~st:~ of GENERIC PARAM [12. ~.B] aLlist:seq of iD [3,~.c] 35 44 u list:lN~ of iTEM [3.9,s] 64, 69, [8.4, 9.10, 10, t . t . B ] as iist:lmq of NAME u_.iist:seq of PARAM 59 [6.1. C] as list:seq of PARAM ASSOC 33 [2.8,A) aLlist:se q of PRAGMA 69 [t0.1.8] as_list:seq of SELECLCLAUSE 67 [S.7.1.A] as l i s t : ~ q of ST~ 51 IS. I,A] ~s list:~eq of VARIANT 43 [3.7.3.A] ~s=.membership_op: MEMBERSHIP_OP [4A.B] 48 asname: NAME 38, 40, [3.3.2.0, 3.6.0~ 3.7.1, 3.7.3.A, 50, 52, 4. t.1, 4.1.2, 4.1.3, 4.1.4, 4.6, 64, 66, 4.7, 5.2, 5.9, 6,1.C, 8.4, 7.4.B, ~.5, 9.5.8, 9.5.C, 10.2.A, 12.3.A, t3.3, 13.4.A, 13.4.0, 13.5, 13.8] ¢Lname~s: NAk4E $ 68 IS. tO) as_name void: NAME VOID [5.7, 6.1.B, 11.3] 68, 68, 34, 42 aLobject_def: OBJECT. DEF [3.2,A, 3,7.1] 62 aLl:~ckage def: PACKAGE DEF [7.1.A] a s . . p a r a m _ a s s o c s : PARAM ASSOC 8 [2.8.A, 6.4, 9,5,B] 33, 61= 58, 66 a s param._s: PARAM S [6.1.8, 6.6.A, 8,5.c] aS .pragmLs: PRAGMA S [10.1.B, 13.4.A] 69, 74 38, 75 as .range: RANGE [3.5.4, 13.4.B] as_range void: RANGE_VOID [3.s.7, 3.5.8] 38 as record: INNER. RECORD [3.7.3.A] 43 as_select clau~e_s: SELECT_CLAUSE S [S.T.1.A] 67 a L U m : STM [5.1.B, 5.5.A] 5% 54 =s stm sl:STM_S [9,7.2, 9.7.3] 68 as stm s2: STM S [9.7,2, 9.7.3] 68 aLstm_s:$TM S [5,3.A, 5,4, 5,5.A, 5.6, 9.5.C, 53, 54, 9o7.1.A, 9.7.1.B] aLsubprogram, clef: SUBPROGRAM. DEF [6.1 .A] 57 as_subunit, body: SUBUNIT BODY [ 10.2. A] 70 as task def:TASK DEF [¢J,1.A] 65 48 as-'tyl~_range :WP'E RANGE [4.4. B] as type spat:TYPE SPEC [3.2.A, 3.3.1,A] 34, 35 69 •,s unit body: UNITBODY [ 10.1. B] 43 as varian?_s: VARIANTS [3.7.3. A] aL~d s: IO._S

Vl. 2.

42, 51, 59, $31

70

42, 43, 46, 47, 56, 59, 61, 63, 70, 73, 74, 75

7I 66

55, 66, 67

Lextcai A t t r i b u t e s

Lexicat a t t r i b u t e s r e p r e s e n t i n f o r m a t i o n p r o v i d e d by the lexical a n a l y s i s p h a s e . |x_comments:comment~

[2.8.A, 3.2.A, 3.2.B, 3.2.C, 3.3.1.A, 3.3.2.A, 3.3.2.B, 3.4, 3.5, 3.5.1.A, 3 . 5 . ! . 8 , 3.5.4,

33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43. 44, 45, 46, 47, 48, 49, 50,

Section Vl. 2 / Page %95

Diana Attributes

3.5.7, 3.5.9, 3.6.A, 3.6.B, 3.7.A, 3.7.B, 3.7.1, 3.7.2, 3.7.3.A, 3.7.3.B, 3.8, 3.3.B, 4.1.A, 4.1.1, 4.1.2, 4.1.3, 4.1.4, 4.3.A, 4.3.B, 4.4.A, 4.4.B, 4.4.D, 4.6, 4.7, 4.8, 5.1.A, 5.1.B, 5.1.F, 5.2, 5.3.A, 5.4, 5.5.A, 5.5.B, 5.6, 5.7, 5.8, 5.9, 6.1.A, 6.1.B, 6.1.C, 6.3, 6.4, 7.1.A, 7.1.B, 7.1.C, 7.4.A, 7.4.B, 8.4, 8.5, 9.1,A, 9.1.B, 9.5.A, 9.5.B, 9.5.C, 9.6, 9.7.1.A, 9.7.1.B, 9.10, 9.7.2, 9.7.3, 10.1.1.A, 10.1.A, 10.1.B, 10.1.1.B, 10.2.A, 10.2.B, 11.1, 11.3, 12.1.A, 12.1.B, 12.1.C, 12.1.D, 12.3.A, 13.3, 13.4.A, 13.4.B, 13.5, 13.8] [6. I,C]

lx._default: Boolean tx._numrep: number rep Ix_prefix: Boolean tx._srcpos:sourceposttion

51, 57, 63, 69, 75

59 49 61 33, [2.8.A, 3.2.A, 3.2.B, 3.2.C, 39, 3.3.1.A, 3.3.2.A, 3.3.2.B, 3.4, 45, 3.5, 3.5.1.A, 3.5.1.B, 3.5.4, 3.5.7, 3.5.9, 3.6.A, 3.6.B, 3.7.A, 51, 57, 3.7.B, 3.7.1, 3.7.2, 3.7.3.A, 3.7.3.B, 3.0, 3.9.B, 4.1.A, 4.1.1, 63, 69, 4.1.2, 4.1.3, 4.1.4, 4,3.A, 4.3.B, 4.4.A, 4.4.B, 4.4.D, 4.6, 4.7, 4.8, 75 5.1.A, 5.1.B, 5.1.F, 5.2, 5.3.A, 5.4, 5.5.A, 5,5.B, 5.6, 5.7, 5.8, 5.9, 6.1.A, 6,1,B, 6,1,C, 6.3, 6.4, 7.1.A, 7.1.B, 7.1.C, 7.4.A, 7.4.B, 8.4, 8.5, 9.1.A, 9.1.B, 9.5.A, 9.5.B, 9.5.C, 9,6, 9.7.1.A, 9.7.1.B, 9.10, 9.7.2, 9.7.3, 10.1.1.A, 10.1.A, 10,1.B, 10.1.1.B, 10.2.A, 10.2.B, 11.1, 11.3, 12.1.A, 12.1.B, 12.1.C, 12.1.D, 12.3.A, 13.3, 13.4.A, 13.4.B, 13.5, 13.8] 34, [3.2.A, 3.2.B, 3.3.1.Ao 3.3.2,A, 3.5.1.B, 3.7,B, 3.7.1, 4.1.A, 45, 4.4.D, 5.1.B, 5.5.A, 5.5.B, 6.1.A, 59, 6.1.C, 7.1.A, 7.4,A, 9.1.B, 9.5.A, 71, 11.1, 12.1.A, App. I]

[4.4,D] [6.4]

~_.symrep: symbol_rep

52, 58, 64, 70,

53, 59, 65, 71,

54, 60, 66, 72,

55, 61, 67, 73,

56, 62, 68, 74,

34, 40, 46, 52, 58, 64, 70,

35, 41, 47, 53, 59, 65, 71,

36, 42, 48, 54, 60, 66, 72,

37, 43, 49, 55, 61, 67, 73,

38, 44, 50, 56, 62, 68, 74,

35, 36, 38, 41, 42, 49, 51, 54, 55, 57, 62, 63, 65, 66, 70, 76

VI. 3. Semantic Attributes Semantic

attributes

represent

the

result

of semantic

analysis

and

provide

information on the meaning of the program represented by the DIANA tree, $m actual delta:Rational sm_--addres's:EXP._VOID sm._base_type:TYPE_SPEC sin_bits: Integer sin_body: BLOCK STUB_VOID sm._body:PACK BODY OESC sm._body:SUBP._BODY_DESC sm ¢omp_spec: COMP REP_VOID $m._constraint: CONSTRAINT sm._controlled: Boolean sm._decl $: DECLS sm_defn: DEF_OCCURRENCE sm_discriminants: DSCRMT_VAR_.S sm...exception_def: EXCEPTIONDEF sm _exp_type: TYPE SPEC

[3.4, 3.5.9] [3.2.A, 7.1.A, 3.1.A, 9.5.A1 [3.3.2.B, 3.5, 3.5.4, 3.5.7, 3.5.9]

[3.5.9]

[3.1.A, 9.1.B, 12.1,A] [7. I.A] [6.1 .A] [3.7.B, 3.7.1] [3.3.2.B, 4.1.2, 4.3,A, 4.4.D] [3.4, 3.8] [12.3.A]

[4.1.A]

[3.7.A, 7.4.A] [t1.1] [4.1.A, 4.1.1, 4.1.2, 4.1.3, 4.1.4, 4.3.A, 4.4.A, 4.4.B, 4.4.D, 4.6, 4.7, 4.8, 6.4] sin_first: DEF._OCCURRENCE [3.2.A, 3.3.1.A, 3.7.1, 6.1.A, 6.1.C, 7.1.A, 9.1.B, 12.1.A] sm generic._param s: GENERIC_PARAM_S

37, 3'3

34, 36, 39 65, 62 57 41, 36, 37, 73 45 41, 70 45, 61

62, 65, 66 37, 38, 39 71 42 46, 47, 49 44 63 46, 47, 48, 49, 50,

34, 35, 42, 57, 59, 62, 65, 71

Page t 9 6

$m_init._exp: IEXP sm init_exp:EXP VOiD sin. location: LOCATION sm. normalized comp s:EXP_$ sm. normalized_param_$: EXP_$ sm obLdef: OBJECT_DEF ~m. obj_.type:TYPE._SPEC sm operator: operator sm packing:Boo|ean sm _po$:integer sm_.reoord spec: REP_VOiD sm rep: tnteger sm_.size:EXP=VO|O sm spe¢: GENERIC_HEADER sm spec:HEADER $m Spec:PACKAGE...SPEC $m stm: LOOP sm stm:STM sm_storage..size:EXP VOIO sm 8tub:DE'F OCCURRENCE sm type spec: CONSTRAINED sm._type spec:TYPE SPEC sm._type_struct:TYPE._SPEC Sm vaiue:v~|us

Vh 4.

DIANA Reference IVlanual ;I2.1.A] ~3,2. B] [3.7,B, 3,7.1, 6,t,C] [6.1, A] ~3.7.2, 4.3.A] ~6.4, 9.5. B] [ 3.2. A] ~3,2.A, 3.2.B, 3,5.1,B, 3.7.B, 3 . 7 ; I , 5.5.B, 6.1.C] ~4.1. A] ~3,4, 3.6.A, 3.7.A] ~3~5.1.8] ~3,7, A] ~3° 5.1. B] ~3.4, 3.5.1.A, 3.5.4, 3.5.7, 3.5.9, 3.6.A, 3.7.A, 3.8] ~12.1, A] ~6.t.A, 9.5.A] ~7,1 .A] ~5.7] [5.1.B, 5.5.A] ~3.4, 3.8, 9.1.A] ~6.1.A, 7.1.A, 9.1.B, 12.1.A] ~3.3,2.A] ~3.3.1.A, 7.4.A, S.I.B] ~3.3.2.B, 3.5.4, 3.5.7] ~4.1.A, 4.1.4, 4.4.A, 4.4.B, 4.4.D, ~.6, 4.7, 4.8, 6.4]

71 35 41, 57 42, 61, 34 34, 59 45 37, 38 41 38 37, 71 57, 62 56 51, 37, 57, 36 35, 36, 45,

42, 59 47 66 35, 38, 41, 42, 55, 40, 41

38, 39, 40, 4t, 44 66 54 44, 65 62, 65, 71 63, 65 38, 38 47, 48, 49, 50, 61

C o d e Attributes

C o d e attributes p r o v i d e t a r g e t - m a c h i n e - s p e c i f i c ¢d imp| size:integer

information,

[3.3,2,B, 3.4, 3,5,1.A, 3.5.4, 3.5.7, 3.5.91

36, 37, 38, 39

DIANA Reference Manual

Page 197

[1]

P.F. Albrecht, P.E. Garrison. S.L. Graham, R.H, Hyerle. P. lp. and B. Krieg-Bruckner. S o u r c e - t o - S o u r c e Translation: Ada to Pascal and Pascal to Ada, ACMIn Symposium on the Ada Programming Language. pages 1 8 3 - t 9 3 . StGPLAN. Boston, December. 1980.

[21

B, M. Brosgol. J . M . Newcomer, D.A. Lamb. D. Levtne. M. S. Van Deusen. and W.A. Wult, TCOL~x/a: Revised Report on An Intermediate Representation for the Preliminary Ada Language. Technical Report CMU-CS-80-105, Carnegie-Mellon University. Computer Science Department, February. 1980.

[3]

J, N. Buxton. Stoneman: Requirements for Ada Programming Support Environments. Technical Report. DARPA. February. "1980.

[41

M. Dausmann, S, Drossopoulou. G. Goos. G. Persch. G. Wtnterstein. AIDA Introduction and User Manual, Technical Report Nr. 38/80. Instttut fuer tnformatik I1. Universttaet Karlsruhe, 1980.

[51

M. Dausmann. S. Drossopoulou. G. Persch. G. Winterstein. On Reusing Units of Other Program Libraries. Technical Report Nr. 31/80, Institut fuer Informatik II, Universttaet • Kartsruhe. 1980.

[61

Formal Definition of the Ada Programming Language November 1980 edition. Honeywell, I n c . , Cii Honeywell Bull. INRIA,

1980.

[71

J.D. Ichbiah. B. Krieg-Brueckner. B.A. Wichmann. H.F. Ledgard, J . C , Hellard. J.R. Abrlal, J . G . P . Barnes. M. Woodger. O. Roubine, P.N, Hilflnger. R. Firth. Reference Manual for the Aria Programming Language The revised reference manual. July 1980 edition, Honeywell. I n c . , and Cii-Honeywell Bull, 1980.

[81

J , D . Ichbiah, B. Krieg-Brueckner. B.A. Wichmann, H,F. Ledgard, J . C . Hellard. J.R. Abrlat. J . G . P . Barnes, M. Woodger, O. Roubine, P.N. HIIflnger. R. Firth, Reference Manual for the Ada Programming Language Draft revised MIL-STD 1815, July 1982 edition, Honeywell, I n c . . and Cii-Honeywell Bull. 1982,

[91

J.R. Nestor, W.A. Wulf. D.A. Lamb, IDL - Interface Description Language: Formal Description. Technical Report CMU-CS-81-139, Carnegie-Mellon University. Computer Science Department. August. 1981.

[t01

G. Persch. G. Winterstein. M. Dausmann. S. Drossopoulou. G. Goos. AIDA Reference Manual. Technical Report Nr. 89/80. Institut fuer tnformatik II. Universitaet Karlsruhe. November, 1980.

[111

Author unknown, Found on a blackboard at Eglin Air Force Base.

DIANA R e f e r e n c e

Manual

Page

199

INDEX

Abstract Syntax Tree 10, 80, 81, 82, 83, 165 accept statement 110 actual parameters 126 address specification 113, 125, 126 AFD 9, 80, 81, 82, 83, 124 aggregate 96. 97, 98, 126 anonymous subtype 97 anonymous type 89, 96 apply 02 node in abstract syntax 82, 161 APSE 17, 83 array aggregate 97 array type 96 attribute assignment 124, 155 attribute equality 123, 124, 155 base type 89, 91, 93, 96, 125 built-in operator 87 operators 123 subprograms 123 code generaUon 85, 89, 91, 123 comments 1 2 2 , 125, 168, 169 Diana private type 122, 168 compilation unit 61, 83, 84, 106, 108, 109, 122, 125 constant declaration 83, 1t5, t16 as part of lnstentJatton 115, 116, t18 See also deferred constant declaration constraint array 97 discriminant 88, 97 fixed point 91 floating point 91 on expression values 96 slice 97, 98 string literal 97, 98 subtype 91, 93, 96, 97 See also Diana node ¢omd0rained consumer 13, 14, 18, 19, 122, 168 dedarslive pert 103, 106 deferred constant 87, 102. 106 deferred constant declaration 83, 108 See also constant declaration defining occurrence 10, 85 attribute names 86, 158 enumeration character 86 enumeration Ilterals 93 identifiers 80, 85 implicit 68 label frames 86 loop arid block names 86 multiple 84, 87, 102, 103, 104, 105, 106, 107, 106, 109, 110, 111, 112, 113, 114, 126 operators 86 pragma arguments 86, 158, 159 prsgma names 86, 150, 159 references to 86, 87, 88, 10~, 103, 105, 106, 107, 108, 109, 110, 111, 112, t13, 114, 116, 126 derivation IDL definition 161, 162 derived subprograms 68 derived subtype 91 derived type 9% 93. 95, 96, 124 disorlminant constraint 88, 126

disoriminant pert 1 0 2 , 103, 105, 106, 126 discriminant specification 83 See also Diana node d ~ l l n t ~ltr entry call 82 entry declaration 1t0, 118 enumeration literal 90, 93, 118, 127 enumeration type 90, 91, 93, o.5, 118, 127 expression 89, 96, 97, 98 See also static expression external Diana 11, 124, 145, 148, 150, 151, 152, 158 fixed type 91, 96 float type 91, 96 Formal Definition of Ada AFD See also formals 102, 110, 114 forward reference 84, 108, 109 function call infix vs. prefix 87, 168 See also Diana attribute Ix_prefix generai_assoc s node in abstract syntax 82 generic actuals 1 0 5 , 115 body 84, 114, 115 formal private type 105 formals t14, 115, 116, 118 package 114, 118, 126 parameters 114, 115, 116, 118, 126 specification 85, 1t4 subprogram 114, 116, 118, 126 generic instantistion 84, 85, 105, 115, 116, 118, 124, 125, 127 generic unit 114, 115, 116, 118 IDL 21 implementation dependent attributes 121, 124, 158, 159 incomplete type 87, 96, 102, 103, 105, 127 integer type 91, 96 library maneger 84, 122 limited private type See also private type machine dependent attributes 90 names 98 normalizations 81 anonymous types 81, 82 discriminant constraints 88 generic parameters 115, 116 in source reconstruction 165 operators 82, 67 parameter associations 82, 88 record aggregates 88 source reconstruction 167, 168 subprogram calls 82, 07 number, rap Diana private type 122, 150 operator built-in 82, 87, 88, 123, 126 defining occurrence 86 Diana prtvate type 88, 123, 150, 158 member~hlp 87 normalized as function call 82, 87 short-circuit 87 user-defined 87, 88 overload resolution 96 package body 102, 106, 108, 111, 112, 125 package declaration 102

DIANA Reference Manual

Page 200

package specificatio*~ 10~, 106, 108, 1111, 112, 118 parameters actual 88 formal 88 generic 115, 116, 1t8 normalized 82, 88 parentheses 13, 81 pragma CONTROLLED 90, 125 INLtNE 126 INTERFACE 125 LIST 159 PACK 90. 127. t60 PRIORITY 159 SUPPRE~S 159 pragma.s 8t, 90, t5;', 158, 159, t60 predefined attribute names 86, 127, 158 pregma arguments 86, 158, 159 pragrna names 86, t58, 159 predefined environment 31, 86, t23, 125, 157, 158, 159 private part 167 private type Ads 96, 102, 103, 104, 105, 106, 126, 127 IDL 24. 26, 28, 31, 17.1, 122., 123, 130, 131, 145, 149 producer 12, 13, 14, 19, 122~ 169 record aggregate 88, 97 record type 90, 91, 93, 103, 106= t26, 127 refinement 25, 31, 149 renaming 118, 125 as part of instantlation I16 constant 118 entry 118 enumeration as function 118 exceptions 118 objects 118, 126 packages 118 subprogram 118 tasks 121 representation specification 90, 91, 93, 95, 103, 125, 127 result type 88 separate compilation 10, 83, 84, 89, 103, 104, 106, 108, 109, 111, 1t2, 113, 115, 121 sharing 124, 154 in external Diana I47 slice 97 source position t22, 125 source reconstruction 10. 81, 82. 88. 90. 9t, 165, 166, 16T, 168 sourceposition Diana private type 122 See also source position STANDARD Ads package 157. t58 static expression 12, 13, 18, 90, 96, 98, 121, 127 string literal 97 stub t06, 109, 1 t l , 113, 114, 125, 127 subprogram body 102. 105, 107'. 108, 109. 110, 125 subprogram declaration 102, 106, 107, 108, 109, 110. 116 subtype declaration 91, 116 as part of instantiation 116, 118 subtype indication 82, 83, 91, 93 subtype specification 91, 93 See also constraint subunit 105, 109, 11t, 112, 114

symbol table 10, 85, 155 symbol_rep Diana private type 122, 149, 158, 159 syntax-directed editor 122, 165 task body 113 task type 1t2, 113 anonymous 82, 113 ta.sks 112 tree traversal 97 type conversion 88 type declaration 90, 103 type mark 82, 83, 91 Dype specification 89, 90, 93, 96, 98, 127 b/pc structure 89, 90, 91, 93, 127 universal type 90, 126, 157 used occurrence 80, 85, 8S, 88, 102, 105, 110. t13 va~ue Diana private type 98. 121, 150 variable declaration 83, 1t5 as part of instantiation 116 See a l s o Diana vsr with clause 98 ~)lana Classes ARGUMENT 159 ATTR tD 158 CONS-TRAINED 82 OECL 85 DEF_CHAR 86 OEF__ID 85, 87, 98, 102, 159 DEF OP 86 OES~'GNATOR_CHAR 87 E~XP 9~, 166 NAME 82, 98, 166 TYPE SPEC 89, 157 USED_ID 87 USED_OP 87 Diana Nodes access 90, 105 aggr~ 97, 102 all 96, 102 allocator 82 w'gument id 85, 88, 159 90, 98 a~ig. a=~o¢

98,

166

116 stir id 88. 86, 158 at~-~ 93 block 107, 108, 109, t12, 113, 114, 166, 167 ¢=~p__~ 88, 98, s3 ¢~.p_t~t el ==~,.pikCdon 150 ¢on~t id 85. 98, 106, 118 ¢omfa~ 83. 98, 106, 116 ~.ined 20, 89. 91, ~3. 96. 98. 106. 116 convention 82. 96 deal s 118 de~_ooltstimt 83. 106 derived 2 0 , 9 3 , 9 5 . 9 6 a=m.t eggregate 97 ¢l=m.t_kl 88, 90, 105 ¢bmrmt var 83 asat_raa~__s se eney ¢~1 s2 ~rdbry id 85, 110, 118 erwm._'KI 85, 90, 93, 95, 118 e n u m literal s 90, 95

¢=w~on _~- 88

Page 201

DIANA Reference Manual e.p._=

82 fixed 90, 91, 96 flollt 90, 91, 96 fulc~on 82 funcUon ¢ldl 82, 87, 88, 96 fu~_== as. 98 114 g.,.~ ~ ss, 114 in_'== e5, 11o in out == 85, 110 index 98 indexed 82, 96, 102 iMtlmt~Uon 115, 116, 118, 125 irdbBger 90, 93, 96, 98, 106 iterab~ id 85 I_.pllNid~ 105 i~_type id 05, 104 label id 85, 86 ss named 86 n=~_=e._~ as, 86 number Id 85 n ~ literal 82 out_== 85, 110 paCk~je_bo~y 112 pad~je_ded 112, 11e pldmge.~ 85, 112, 118 ~ lRm¢ 112, 118 INIram_r,,~,,;.;. a 82, 88, 160 INIram. = 116 t3 pragr~ 160 pllglrnl_id 85, 86, 126, 159, 160 105, 106 prtv,ste_type...~ aS, lO4, 10~ ill 85, 107, t06, 109, 116, 116 107, 108, 109, 114, 116, 118 pm¢tKlure can 82 quliified 96 rings 91, 93, 98, 106 record 98, 103, 106 recmrd_k~ SO 116, 118, 125, 126 Nlected 98 8impale_he9 93 IdiCe 82, 97, 98, 102 I m body 114 lm~ ~ e ¢ 114 =~Jrce_po~ti~ 130 =tt~Lm~r~ 98 stub 109, 112, 113 IOIR~ogl~m. body 107, 106, 109, 114, 167 ~R,g,,-~,gram dad 107, 108, 106, 116, 116 t t ~ 91, 93, 98, 116 =~type_~ as s3mtboLrep 130 t ~ k body 113 task_body_M 85, 112, 113

tuk_,~

113

tlUlk_lll~¢ 90, 113 type 91, 93, 95, 98, 103, 105, 106, 113 tYlpe_.~ 85, 103, 104, 112, 113, 160 u~erlal_fl=ed 157 um~nm tmeger 157 tm~er=al reel 157 umd ~ == 86, 88, 123 u~d urm op ms ulmd char 87, 98 ulmd == 102 u~ed name td 82, 87, 88, 110, 123, 159, 160 um~l_object ld 86, 87, 97 uled op 87, 88 83, 98

+--kl

85, 96, 112, 113 84, 91, 93, 95, 98, 103, 106, 107, 106, 109, 113, 159

Diana Attributes

as_alfernative_a 166, 167 ss_sxp 166 as_exp_conMrained 83 aa_'ttem_s 166 asJ i l t 159 aa_nsms 96, 166 aa_param_assoc_a 160 aa_stm_s 166 cd._impL~tza 93, 128, 158 Ix_commenfa 13 Ix._~rcpoa 13 Ix_comments 122, 125, 168 Ix_default 124 Ix_numrep 124 Ix_prefix 87, 124 Ix_srcpoa 125 Ix_.symrep 125, 158, 159 • m_value 13, 16 4m_scfual_delta 93, 125 113, 125 am_addrl~s am_ba~eJype 20, 89, 9% 93, 95, 96, 125 ~m_blta 125 am_body 84, 107, 108, 109, 112, 113, t14, 116, 118, 125 am_comp._apec 93, 125 • m_conMrsinf 91, 93, 97, 98, 106, 125 am_controlled 90, 93, 125 am_de¢l 116 am._decl_a 115, 125 am defn 86, 87, 88, 102, 125, 159, 160 • m_discrtminsnfa 1 0 5 , 106, 126 am_exception_clef 126 88, 89, 96, 97, 98, 126 am_exp_type ='n_firM El, 102, 103, 104, 105, 106, 109, 110, 113, 126 atPLgeneric_parsm_a 114, 126 am..jnit_exp 126 ~m.Jocation 126 am_normalized_comp_a 88, 126 am_normalized...param_a 88, 126 am_obLdef 98, 106, 115, 116, 126 am_obLtype 88, 98, 106, 126 ~m operafor 86, 88, 123, 126 am._packlng 90, 93, 126 am_poa 127 am_record_apse 127 ~m_rep 93, 95, 127 am_size 93, 127 am_apse 107, 108, 109, 112, 114, 116, 118, 127 8triMs 127 am_storage_size 63, 127 am_stub 109, 127 am_fype_apec 98, 103, 104, 105, 106, 1t3, 116, 125, 127 am_fype_afruct 20, 91, 93, 95, 127 am_value 96, 96, 102, 121, 127