1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<HTML>
<HEAD>
<TITLE>AARM95 - Program Execution</TITLE>
<META NAME="Author" CONTENT="JTC1/SC22/WG9/ARG, by Randall Brukardt, ARG Editor">
<META NAME="GENERATOR" CONTENT="Arm_Form.Exe, Ada Reference Manual generator">
<STYLE type="text/css">
DIV.paranum {position: absolute; font-family: Arial, Helvetica, sans-serif; left: 0.5 em; top: auto}
TT {font-family: "Courier New", monospace}
DT {display: compact}
DIV.Normal {font-family: "Times New Roman", Times, serif; margin-bottom: 0.6em}
DIV.Wide {font-family: "Times New Roman", Times, serif; margin-top: 0.6em; margin-bottom: 0.6em}
DIV.Annotations {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-bottom: 0.6em}
DIV.WideAnnotations {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-top: 0.6em; margin-bottom: 0.6em}
DIV.Index {font-family: "Times New Roman", Times, serif}
DIV.SyntaxSummary {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-bottom: 0.4em}
DIV.Notes {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-bottom: 0.6em}
DIV.NotesHeader {font-family: "Times New Roman", Times, serif; margin-left: 2.0em}
DIV.SyntaxIndented {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-bottom: 0.4em}
DIV.Indented {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-bottom: 0.6em}
DIV.CodeIndented {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-bottom: 0.6em}
DIV.SmallIndented {font-family: "Times New Roman", Times, serif; margin-left: 10.0em; margin-bottom: 0.6em}
DIV.SmallCodeIndented {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-bottom: 0.6em}
DIV.Examples {font-family: "Courier New", monospace; margin-left: 2.0em; margin-bottom: 0.6em}
DIV.SmallExamples {font-family: "Courier New", monospace; font-size: 80%; margin-left: 7.5em; margin-bottom: 0.6em}
DIV.IndentedExamples {font-family: "Courier New", monospace; margin-left: 8.0em; margin-bottom: 0.6em}
DIV.SmallIndentedExamples {font-family: "Courier New", monospace; font-size: 80%; margin-left: 15.0em; margin-bottom: 0.6em}
UL.Bulleted {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-right: 2.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.SmallBulleted {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.NestedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-right: 4.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.SmallNestedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-right: 8.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.IndentedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-right: 8.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.CodeIndentedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.CodeIndentedNestedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-right: 8.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.SyntaxIndentedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-right: 4.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.NotesBulleted {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-right: 4.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.NotesNestedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
DL.Hanging {font-family: "Times New Roman", Times, serif; margin-top: 0em; margin-bottom: 0.6em}
DD.Hanging {margin-left: 6.0em}
DL.IndentedHanging {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-top: 0em; margin-bottom: 0.6em}
DD.IndentedHanging {margin-left: 2.0em}
DL.HangingInBulleted {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-right: 2.0em; margin-top: 0em; margin-bottom: 0.5em}
DD.HangingInBulleted {margin-left: 4.0em}
DL.SmallHanging {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-top: 0em; margin-bottom: 0.6em}
DD.SmallHanging {margin-left: 7.5em}
DL.SmallIndentedHanging {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-top: 0em; margin-bottom: 0.6em}
DD.SmallIndentedHanging {margin-left: 2.0em}
DL.SmallHangingInBulleted {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
DD.SmallHangingInBulleted {margin-left: 5.0em}
DL.Enumerated {font-family: "Times New Roman", Times, serif; margin-right: 0.0em; margin-top: 0em; margin-bottom: 0.5em}
DD.Enumerated {margin-left: 2.0em}
DL.SmallEnumerated {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-right: 4.0em; margin-top: 0em; margin-bottom: 0.5em}
DD.SmallEnumerated {margin-left: 2.5em}
DL.NestedEnumerated {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-right: 2.0em; margin-top: 0em; margin-bottom: 0.5em}
DL.SmallNestedEnumerated {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
</STYLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFF0" LINK="#0000FF" VLINK="#800080" ALINK="#FF0000">
<P><A HREF="AA-TOC.html">Contents</A> <A HREF="AA-0-29.html">Index</A> <A HREF="AA-10-1-6.html">Previous</A> <A HREF="AA-10-2-1.html">Next</A></P>
<HR>
<H1> 10.2 Program Execution</H1>
<DIV Class="Paranum"><FONT SIZE=-2>1</FONT></DIV>
<DIV Class="Normal"> <A NAME="I3956"></A><A NAME="I3957"></A><A NAME="I3958"></A>An
Ada <I>program</I> consists of a set of <I>partitions</I>[, which can
execute in parallel with one another, possibly in a separate address
space, and possibly on a separate computer.] </DIV>
<H4 ALIGN=CENTER>Post-Compilation Rules</H4>
<DIV Class="Paranum"><FONT SIZE=-2>2</FONT></DIV>
<DIV Class="Normal"> <A NAME="I3959"></A><A NAME="I3960"></A>A partition
is a program or part of a program that can be invoked from outside the
Ada implementation. [For example, on many systems, a partition might
be an executable file generated by the system linker.] <A NAME="I3961"></A>The
user can <I>explicitly assign</I> library units to a partition. The assignment
is done in an implementation-defined manner. The compilation units included
in a partition are those of the explicitly assigned library units, as
well as other compilation units <I>needed by</I> those library units.
The compilation units needed by a given compilation unit are determined
as follows (unless specified otherwise via an implementation-defined
<FONT FACE="Arial, Helvetica">pragma</FONT>, or by some other implementation-defined
means): <A NAME="I3962"></A><A NAME="I3963"></A><A NAME="I3964"></A></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>2.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>From a run-time
point of view, an Ada 95 partition is identical to an Ada 83 program
-- implementations were always allowed to provide inter-program communication
mechanisms. The additional semantics of partitions is that interfaces
between them can be defined to obey normal language rules (as is done
in <A HREF="AA-E.html">Annex E</A>, ``<A HREF="AA-E.html">Distributed
Systems</A>''), whereas interfaces between separate programs had no particular
semantics. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>2.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation defined: </B>The
manner of explicitly assigning library units to a partition.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>2.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation defined: </B>The
implementation-defined means, if any, of specifying which compilation
units are needed by a given compilation unit.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>2.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>There are no
pragmas that ``specify otherwise'' defined by the core language. However,
an implementation is allowed to provide such pragmas, and in fact <A HREF="AA-E.html">Annex
E</A>, ``<A HREF="AA-E.html">Distributed Systems</A>'' defines some pragmas
whose semantics includes reducing the set of compilation units described
here. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>3</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>A compilation unit needs itself;</LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>4</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>If a compilation unit is needed, then so are any compilation
units upon which it depends semantically;</LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>5</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>If a <FONT FACE="Arial, Helvetica">library_unit_declaration</FONT>
is needed, then so is any corresponding <FONT FACE="Arial, Helvetica">library_unit_body</FONT>;</LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>6</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>If a compilation unit with stubs is needed, then so are
any corresponding subunits. </LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>6.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>Note that in
the environment, the stubs are replaced with the corresponding <FONT FACE="Arial, Helvetica">proper_bodies</FONT>.
</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>6.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>Note that a
child unit is not included just because its parent is included -- to
include a child, mention it in a <FONT FACE="Arial, Helvetica">with_clause</FONT>.
</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>7</FONT></DIV>
<DIV Class="Normal"> <A NAME="I3965"></A>The user can optionally designate
(in an implementation-defined manner) one subprogram as the <I>main subprogram</I>
for the partition. A main subprogram, if specified, shall be a subprogram.
</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>7.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>This may seem
superfluous, since it follows from the definition. But we would like
to have every error message that might be generated (before run time)
by an implementation correspond to some explicitly stated ``shall'' rule.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>7.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Of course, this does not mean
that the ``shall'' rules correspond one-to-one with an implementation's
error messages. For example, the rule that says overload resolution ``shall''
succeed in producing a single interpretation would correspond to many
error messages in a good implementation -- the implementation would want
to explain to the user exactly why overload resolution failed. This is
especially true for the syntax rules -- they are considered part of overload
resolution, but in most cases, one would expect an error message based
on the particular syntax rule that was violated. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>7.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation defined: </B>The
manner of designating the main subprogram of a partition.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>7.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>An implementation
cannot require the user to specify, say, all of the library units to
be included. It has to support, for example, perhaps the most typical
case, where the user specifies just one library unit, the main program.
The implementation has to do the work of tracking down all the other
ones. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>8</FONT></DIV>
<DIV Class="Normal"> <A NAME="I3966"></A>Each partition has an anonymous
<I>environment task</I>[, which is an implicit outermost task whose execution
elaborates the <FONT FACE="Arial, Helvetica">library_item</FONT>s of
the environment <FONT FACE="Arial, Helvetica">declarative_part</FONT>,
and then calls the main subprogram, if there is one. A partition's execution
is that of its tasks.] </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>8.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>An environment
task has no master; all nonenvironment tasks have masters.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>8.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>An implementation is allowed to
support multiple concurrent executions of the same partition. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>9</FONT></DIV>
<DIV Class="Normal"> [The order of elaboration of library units is
determined primarily by the <I>elaboration dependences</I>.] <A NAME="I3967"></A><A NAME="I3968"></A>There
is an elaboration dependence of a given <FONT FACE="Arial, Helvetica">library_item</FONT>
upon another if the given <FONT FACE="Arial, Helvetica">library_item</FONT>
or any of its subunits depends semantically on the other <FONT FACE="Arial, Helvetica">library_item</FONT>.
In addition, if a given <FONT FACE="Arial, Helvetica">library_item</FONT>
or any of its subunits has a <FONT FACE="Arial, Helvetica">pragma</FONT>
Elaborate or Elaborate_All that mentions another library unit, then there
is an elaboration dependence of the given <FONT FACE="Arial, Helvetica">library_item</FONT>
upon the body of the other library unit, and, for Elaborate_All only,
upon each <FONT FACE="Arial, Helvetica">library_item</FONT> needed by
the declaration of the other library unit. </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>9.a.1/1</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>{<I><A HREF="defect2.html#8652/0107">8652/0107</A></I>}
<U>``Mentions'' is used informally in the above rule; it is not intended
to refer to the definition of <I>mentions</I> in <A HREF="AA-10-1-2.html">10.1.2</A>.
It would have been better to use ``named'' instead of ``mentioned'' above.</U></FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>9.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>See above for a definition of
which <FONT FACE="Arial, Helvetica">library_item</FONT>s are ``needed
by'' a given declaration.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>9.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Note that elaboration dependences
are among <FONT FACE="Arial, Helvetica">library_item</FONT>s, whereas
the other two forms of dependence are among compilation units. Note that
elaboration dependence includes semantic dependence. It's a little bit
sad that pragma Elaborate_Body can't be folded into this mechanism. It
follows from the definition that the elaboration dependence relationship
is transitive. Note that the wording of the rule does not need to take
into account a semantic dependence of a <FONT FACE="Arial, Helvetica">library_item</FONT>
or one of its subunits upon a subunit of a different library unit, because
that can never happen. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>10</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em"> The environment
task for a partition has the following structure: </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>11</FONT></DIV>
<DIV Class="Examples"><TT><B>task</B> <I>Environment_Task</I>;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>12</FONT></DIV>
<DIV Class="Examples"><TT><B>task</B> <B>body</B> <I>Environment_Task</I> <B>is</B><BR>
... (1) --<I> The environment <FONT FACE="Arial, Helvetica">declarative_part</FONT></I><BR>
--<I> (that is, the sequence of <FONT FACE="Arial, Helvetica">library_item</FONT>s) goes here.</I><BR>
<B>begin</B><BR>
... (2) --<I> Call the main subprogram, if there is one.</I><BR>
<B>end</B> <I>Environment_Task</I>;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>12.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>The name
of the environment task is written in italics here to indicate that this
task is anonymous. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>12.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>The model is
different for a ``passive partition'' (see <A HREF="AA-E-1.html">E.1</A>).
Either there is no environment task, or its <FONT FACE="Arial, Helvetica">sequence_of_statements</FONT>
is an infinite loop rather than a call on a main subprogram. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>13</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em"> <A NAME="I3969"></A>The
environment <FONT FACE="Arial, Helvetica">declarative_part</FONT> at
(1) is a sequence of <FONT FACE="Arial, Helvetica">declarative_item</FONT>s
consisting of copies of the <FONT FACE="Arial, Helvetica">library_item</FONT>s
included in the partition. [The order of elaboration of <FONT FACE="Arial, Helvetica">library_item</FONT>s
is the order in which they appear in the environment <FONT FACE="Arial, Helvetica">declarative_part</FONT>]:
</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>14</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>The order of all included <FONT FACE="Arial, Helvetica">library_item</FONT>s
is such that there are no forward elaboration dependences. </LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>14.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>This rule
is written so that if a <FONT FACE="Arial, Helvetica">library_item</FONT>
depends on itself, we don't require it to be elaborated before itself.
See AI83-00113/12. This can happen only in pathological circumstances.
For example, if a library <FONT FACE="Arial, Helvetica">subprogram_body</FONT>
has no corresponding <FONT FACE="Arial, Helvetica">subprogram_declaration</FONT>,
and one of the subunits of the <FONT FACE="Arial, Helvetica">subprogram_body</FONT>
mentions the <FONT FACE="Arial, Helvetica">subprogram_body</FONT> in
a <FONT FACE="Arial, Helvetica">with_clause</FONT>, the <FONT FACE="Arial, Helvetica">subprogram_body</FONT>
will depend on itself. For another example, if a <FONT FACE="Arial, Helvetica">library_unit_body</FONT>
applies a <FONT FACE="Arial, Helvetica">pragma</FONT> Elaborate_All to
its own declaration, then the <FONT FACE="Arial, Helvetica">library_unit_body</FONT>
will depend on itself. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>15</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>Any included <FONT FACE="Arial, Helvetica">library_unit_declaration</FONT>
to which a <FONT FACE="Arial, Helvetica">pragma</FONT> Elaborate_Body
applies is immediately followed by its <FONT FACE="Arial, Helvetica">library_unit_body</FONT>,
if included. </LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>15.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>This implies
that the body of such a library unit shall not ``with'' any of its own
children, or anything else that depends semantically upon the declaration
of the library unit. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>16</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>All <FONT FACE="Arial, Helvetica">library_item</FONT>s
declared pure occur before any that are not declared pure.</LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>17</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>All preelaborated <FONT FACE="Arial, Helvetica">library_item</FONT>s
occur before any that are not preelaborated. </LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>17.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>Normally, if
two partitions contain the same compilation unit, they each contain a
separate <I>copy</I> of that compilation unit. See <A HREF="AA-E.html">Annex
E</A>, ``<A HREF="AA-E.html">Distributed Systems</A>'' for cases where
two partitions share the same copy of something.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>17.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>There is no requirement that the
main subprogram be elaborated last. In fact, it is possible to write
a partition in which the main subprogram cannot be elaborated last. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>17.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>This <FONT FACE="Arial, Helvetica">declarative_part</FONT>
has the properties required of all environments (see <A HREF="AA-10-1-4.html">10.1.4</A>).
However, the environment <FONT FACE="Arial, Helvetica">declarative_part</FONT>
of a partition will typically contain fewer compilation units than the
environment <FONT FACE="Arial, Helvetica">declarative_part</FONT> used
at compile time -- only the ``needed'' ones are included in the partition.
</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>18</FONT></DIV>
<DIV Class="Normal"> There shall be a total order of the <FONT FACE="Arial, Helvetica">library_item</FONT>s
that obeys the above rules. The order is otherwise implementation defined.
</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>18.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>The only way
to violate this rule is to have Elaborate, Elaborate_All, or Elaborate_Body
<FONT FACE="Arial, Helvetica">pragma</FONT>s that cause circular ordering
requirements, thus preventing an order that has no forward elaboration
dependences. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>18.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation defined: </B>The
order of elaboration of <FONT FACE="Arial, Helvetica">library_item</FONT>s.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>18.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>To be honest: </B><A NAME="I3970"></A><A NAME="I3971"></A>Notwithstanding
what the RM95 says elsewhere, each rule that requires a declaration to
have a corresponding completion is considered to be a Post-Compilation
Rule when the declaration is that of a library unit. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>18.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>Such rules
may be checked at ``link time,'' for example. Rules requiring the completion
to have certain properties, on the other hand, are checked at compile
time of the completion. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19</FONT></DIV>
<DIV Class="Normal"> The full expanded names of the library units
and subunits included in a given partition shall be distinct.</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>This is a Post-Compilation
Rule because making it a Legality Rule would violate the Language Design
Principle labeled ``legality determinable via semantic dependences.''
</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>20</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em"> The <FONT FACE="Arial, Helvetica">sequence_of_statement</FONT>s
of the environment task (see (2) above) consists of either: </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>21</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>A call to the main subprogram, if the partition has one.
If the main subprogram has parameters, they are passed; where the actuals
come from is implementation defined. What happens to the result of a
main function is also implementation defined. </LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>21.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation defined: </B>Parameter
passing and function return for the main subprogram.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>22</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em"> or: </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>23</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>A <FONT FACE="Arial, Helvetica">null_statement</FONT>,
if there is no main subprogram. </LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>23.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>For a passive
partition, either there is no environment task, or its <FONT FACE="Arial, Helvetica">sequence_of_statements</FONT>
is an infinite loop. See <A HREF="AA-E-1.html">E.1</A>. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>24</FONT></DIV>
<DIV Class="Normal"> The mechanisms for building and running partitions
are implementation defined. [These might be combined into one operation,
as, for example, in dynamic linking, or ``load-and-go'' systems.] </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>24.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation defined: </B>The
mechanisms for building and running partitions.</FONT></DIV>
<H4 ALIGN=CENTER>Dynamic Semantics</H4>
<DIV Class="Paranum"><FONT SIZE=-2>25</FONT></DIV>
<DIV Class="Normal"> <A NAME="I3972"></A>The execution of a program
consists of the execution of a set of partitions. Further details are
implementation defined. <A NAME="I3973"></A>The execution of a partition
starts with the execution of its environment task, ends when the environment
task terminates, and includes the executions of all tasks of the partition.
[The execution of the (implicit) <FONT FACE="Arial, Helvetica">task_body</FONT>
of the environment task acts as a master for all other tasks created
as part of the execution of the partition. When the environment task
completes (normally or abnormally), it waits for the termination of all
such tasks, and then finalizes any remaining objects of the partition.]
</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>25.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>The ``further
details'' mentioned above include, for example, program termination --
it is implementation defined. There is no need to define it here; it's
entirely up to the implementation whether it wants to consider the program
as a whole to exist beyond the existence of individual partitions. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>25.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation defined: </B>The
details of program execution, including program termination.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>25.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>To be honest: </B><A NAME="I3974"></A><A NAME="I3975"></A><A NAME="I3976"></A><A NAME="I3977"></A><A NAME="I3978"></A>The
execution of the partition terminates (normally or abnormally) when the
environment task terminates (normally or abnormally, respectively). </FONT></DIV>
<H4 ALIGN=CENTER>Bounded (Run-Time) Errors</H4>
<DIV Class="Paranum"><FONT SIZE=-2>26</FONT></DIV>
<DIV Class="Normal"> <A NAME="I3979"></A><A NAME="I3980"></A>Once
the environment task has awaited the termination of all other tasks of
the partition, any further attempt to create a task (during finalization)
is a bounded error, and may result in the raising of Program_Error either
upon creation or activation of the task. <A NAME="I3981"></A>If such
a task is activated, it is not specified whether the task is awaited
prior to termination of the environment task. </DIV>
<H4 ALIGN=CENTER>Implementation Requirements</H4>
<DIV Class="Paranum"><FONT SIZE=-2>27</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em"> The implementation
shall ensure that all compilation units included in a partition are consistent
with one another, and are legal according to the rules of the language.
</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>27.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>The consistency
requirement implies that a partition cannot contain two versions of the
same compilation unit. That is, a partition cannot contain two different
library units with the same full expanded name, nor two different bodies
for the same program unit. For example, suppose we compile the following:
</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>27.b</FONT></DIV>
<DIV Class="SmallExamples"><TT><B>package</B> A <B>is</B> --<I> Version 1.</I><BR>
...<BR>
<B>end</B> A;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>27.c</FONT></DIV>
<DIV Class="SmallExamples"><TT><B>with</B> A;<BR>
<B>package</B> B <B>is</B><BR>
<B>end</B> B;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>27.d</FONT></DIV>
<DIV Class="SmallExamples"><TT><B>package</B> A <B>is</B> --<I> Version 2.</I><BR>
...<BR>
<B>end</B> A;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>27.e</FONT></DIV>
<DIV Class="SmallExamples"><TT><B>with</B> A;<BR>
<B>package</B> C <B>is</B><BR>
<B>end</B> C;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>27.f</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>It would be wrong for a partition
containing B and C to contain both versions of A. Typically, the implementation
would require the use of Version 2 of A, which might require the recompilation
of B. Alternatively, the implementation might automatically recompile
B when the partition is built. A third alternative would be an incremental
compiler that, when Version 2 of A is compiled, automatically patches
the object code for B to reflect the changes to A (if there are any relevant
changes -- there might not be any).</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>27.g</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>An implementation that supported
fancy version management might allow the use of Version 1 in some circumstances.
In no case can the implementation allow the use of both versions in the
same partition (unless, of course, it can prove that the two versions
are semantically identical).</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>27.h</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The core language says nothing
about inter-partition consistency; see also <A HREF="AA-E.html">Annex
E</A>, ``<A HREF="AA-E.html">Distributed Systems</A>''. </FONT></DIV>
<H4 ALIGN=CENTER>Implementation Permissions</H4>
<DIV Class="Paranum"><FONT SIZE=-2>28</FONT></DIV>
<DIV Class="Normal"> <A NAME="I3982"></A>The kind of partition described
in this clause is known as an <I>active</I> partition. An implementation
is allowed to support other kinds of partitions, with implementation-defined
semantics. </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>28.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation defined: </B>The
semantics of any nonactive partitions supported by the implementation.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>28.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B><A HREF="AA-E.html">Annex
E</A>, ``<A HREF="AA-E.html">Distributed Systems</A>'' defines the concept
of passive partitions; they may be thought of as a partition without
an environment task, or as one with a particularly simple form of environment
task, having an infinite loop rather than a call on a main subprogram
as its <FONT FACE="Arial, Helvetica">sequence_of_statements</FONT>. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>29</FONT></DIV>
<DIV Class="Normal"> An implementation may restrict the kinds of subprograms
it supports as main subprograms. However, an implementation is required
to support all main subprograms that are public parameterless library
procedures. </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>29.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>The implementation
is required to support main subprograms that are procedures declared
by <FONT FACE="Arial, Helvetica">generic_instantiation</FONT>s, as well
as those that are children of library units other than Standard. Generic
units are, of course, not allowed to be main subprograms, since they
are not subprograms.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>29.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Note that renamings are irrelevant
to this rule. This rules says which subprograms (not views) have to be
supported. The implementation can choose any way it wants for the user
to indicate which subprogram should be the main subprogram. An implementation
might allow any name of any view, including those declared by renamings.
Another implementation might require it to be the original name. Another
implementation still might use the name of the source file or some such
thing. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>30</FONT></DIV>
<DIV Class="Normal"> If the environment task completes abnormally,
the implementation may abort any dependent tasks. </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>30.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>If the implementation
does not take advantage of this permission, the normal action takes place
-- the environment task awaits those tasks.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>30.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The possibility of aborting them
is not shown in the <I>Environment_Task</I> code above, because there
is nowhere to put an <FONT FACE="Arial, Helvetica">exception_handler</FONT>
that can handle exceptions raised in both the environment <FONT FACE="Arial, Helvetica">declarative_part</FONT>
and the main subprogram, such that the dependent tasks can be aborted.
If we put an <FONT FACE="Arial, Helvetica">exception_handler</FONT> in
the body of the environment task, then it won't handle exceptions that
occur during elaboration of the environment <FONT FACE="Arial, Helvetica">declarative_part</FONT>.
If we were to move those things into a nested <FONT FACE="Arial, Helvetica">block_statement</FONT>,
with the <FONT FACE="Arial, Helvetica">exception_handler</FONT> outside
that, then the <FONT FACE="Arial, Helvetica">block_statement</FONT> would
await the library tasks we are trying to abort.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>30.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Furthermore, this is merely a
permission, and is not fundamental to the model, so it is probably better
to state it separately anyway.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>30.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Note that implementations (and
tools like debuggers) can have modes that provide other behaviors in
addition. </FONT></DIV>
<DIV Class="NotesHeader"><FONT SIZE=-1>NOTES</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>31</FONT></DIV>
<DIV Class="Notes"><FONT SIZE=-1>8 An implementation may provide
inter-partition communication mechanism(s) via special packages and pragmas.
Standard pragmas for distribution and methods for specifying inter-partition
communication are defined in <A HREF="AA-E.html">Annex E</A>, ``<A HREF="AA-E.html">Distributed
Systems</A>''. If no such mechanisms are provided, then each partition
is isolated from all others, and behaves as a program in and of itself.
</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>31.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>Not providing
such mechanisms is equivalent to disallowing multi-partition programs.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>31.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>An implementation may provide
mechanisms to facilitate checking the consistency of library units elaborated
in different partitions; <A HREF="AA-E.html">Annex E</A>, ``<A HREF="AA-E.html">Distributed
Systems</A>'' does so. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>32</FONT></DIV>
<DIV Class="Notes"><FONT SIZE=-1>9 Partitions are not required
to run in separate address spaces. For example, an implementation might
support dynamic linking via the partition concept.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>33</FONT></DIV>
<DIV Class="Notes"><FONT SIZE=-1>10 An order of elaboration
of <FONT FACE="Arial, Helvetica">library_item</FONT>s that is consistent
with the partial ordering defined above does not always ensure that each
<FONT FACE="Arial, Helvetica">library_unit_body</FONT> is elaborated
before any other compilation unit whose elaboration necessitates that
the <FONT FACE="Arial, Helvetica">library_unit_body</FONT> be already
elaborated. (In particular, there is no requirement that the body of
a library unit be elaborated as soon as possible after the <FONT FACE="Arial, Helvetica">library_unit_declaration</FONT>
is elaborated, unless the pragmas in subclause <A HREF="AA-10-2-1.html">10.2.1</A>
are used.)</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>34</FONT></DIV>
<DIV Class="Notes"><FONT SIZE=-1>11 A partition (active or
otherwise) need not have a main subprogram. In such a case, all the work
done by the partition would be done by elaboration of various <FONT FACE="Arial, Helvetica">library_item</FONT>s,
and by tasks created by that elaboration. Passive partitions, which cannot
have main subprograms, are defined in <A HREF="AA-E.html">Annex E</A>,
``<A HREF="AA-E.html">Distributed Systems</A>''. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>34.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>The environment
task is the outermost semantic level defined by the language.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>34.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Standard has no private part.
This prevents strange implementation-dependences involving private children
of Standard having visibility upon Standard's private part. It doesn't
matter where the body of Standard appears in the environment, since it
doesn't do anything. See <A HREF="AA-A.html">Annex A</A>, ``<A HREF="AA-A.html">Predefined
Language Environment</A>''.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>34.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Note that elaboration dependence
is carefully defined in such a way that if (say) the body of something
doesn't exist yet, then there is no elaboration dependence upon the nonexistent
body. (This follows from the fact that ``needed by'' is defined that
way, and the elaboration dependences caused by a <FONT FACE="Arial, Helvetica">pragma</FONT>
Elaborate or Elaborate_All are defined in terms of ``needed by''.) This
property allows us to use the environment concept both at compile time
and at partition-construction time/run time. </FONT></DIV>
<H4 ALIGN=CENTER>Extensions to Ada 83</H4>
<DIV Class="Paranum"><FONT SIZE=-2>34.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><A NAME="I3983"></A>The concept
of partitions is new to Ada 95.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>34.e</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>A main subprogram is now optional.
The language-defined restrictions on main subprograms are relaxed. </FONT></DIV>
<H4 ALIGN=CENTER>Wording Changes from Ada 83</H4>
<DIV Class="Paranum"><FONT SIZE=-2>34.f</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Ada 95 uses the term ``main subprogram''
instead of Ada 83's ``main program'' (which was inherited from Pascal).
This is done to avoid confusion -- a main subprogram is a subprogram,
not a program. The program as a whole is an entirely different thing.
</FONT></DIV>
<HR>
<P><A HREF="AA-TOC.html">Contents</A> <A HREF="AA-0-29.html">Index</A> <A HREF="AA-10-1-6.html">Previous</A> <A HREF="AA-10-2-1.html">Next</A> <A HREF="AA-TTL.html">Legal</A></P>
</BODY>
</HTML>
|
