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 ~ >=

~ &

* | ::= ~ 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



I

>=

I *

|

/

I

::=

m¢= -- + ----& ~ + ---- 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

~
; 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_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: 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