File: AA-13-14.html

package info (click to toggle)
ada-reference-manual 20021112web-3
  • links: PTS
  • area: main
  • in suites: etch, etch-m68k, lenny, sarge
  • size: 18,652 kB
  • ctags: 8,921
  • sloc: makefile: 52; sh: 20
file content (688 lines) | stat: -rw-r--r-- 49,872 bytes parent folder | download
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
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<HTML>
<HEAD>
    <TITLE>AARM95 - Freezing Rules</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>&nbsp;&nbsp;&nbsp;<A HREF="AA-0-29.html">Index</A>&nbsp;&nbsp;&nbsp;<A HREF="AA-13-13-2.html">Previous</A>&nbsp;&nbsp;&nbsp;<A HREF="AA-0-28.html">Next</A></P>
<HR>
<H1> 13.14 Freezing Rules</H1>
<DIV Class="Paranum"><FONT SIZE=-2>1</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;[This clause defines a place in the program text
where each declared entity becomes ``frozen.'' A use of an entity, such
as a reference to it by name, or (for a type) an expression of the type,
causes freezing of the entity in some contexts, as described below. The
Legality Rules forbid certain kinds of uses of an entity in the region
of text where it is frozen.] </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>1.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>This concept has
two purposes: a compile-time one and a run-time one.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>1.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The compile-time purpose of the
freezing rules comes from the fact that the evaluation of static expressions
depends on overload resolution, and overload resolution sometimes depends
on the value of a static expression. (The dependence of static evaluation
upon overload resolution is obvious. The dependence in the other direction
is more subtle. There are three rules that require static expressions
in contexts that can appear in declarative places: The expression in
an <FONT FACE="Arial, Helvetica">attribute_designator</FONT> shall be
static. In a record aggregate, variant-controlling discriminants shall
be static. In an array aggregate with more than one named association,
the choices shall be static. The compiler needs to know the value of
these expressions in order to perform overload resolution and legality
checking.) We wish to allow a compiler to evaluate static expressions
when it sees them in a single pass over the <FONT FACE="Arial, Helvetica">compilation_unit</FONT>.
The freezing rules ensure that.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>1.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The run-time purpose of the freezing
rules is called the ``linear elaboration model.'' This means that declarations
are elaborated in the order in which they appear in the program text,
and later elaborations can depend on the results of earlier ones. The
elaboration of the declarations of certain entities requires run-time
information about the implementation details of other entities. The freezing
rules ensure that this information has been calculated by the time it
is used. For example, suppose the initial value of a constant is the
result of a function call that takes a parameter of type <I>T</I>. In
order to pass that parameter, the size of type <I>T</I> has to be known.
If <I>T</I> is composite, that size might be known only at run time.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>1.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>(Note that in these discussions,
words like ``before'' and ``after'' generally refer to places in the
program text, as opposed to times at run time.) </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>1.e</FONT></DIV>
<DIV Class="Annotations" Style="margin-bottom: 0.4em"><FONT SIZE=-1><B>Discussion:
</B>The ``implementation details'' we're talking about above are: </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>1.f</FONT></DIV>
<UL Class="SmallBulleted"><FONT SIZE=-1><LI TYPE=DISC>For a tagged type, the implementations of all the primitive
subprograms of the type -- that is (in the canonical implementation model),
the contents of the type descriptor, which contains pointers to the code
for each primitive subprogram.</LI></FONT></UL>
<DIV Class="Paranum"><FONT SIZE=-2>1.g</FONT></DIV>
<UL Class="SmallBulleted"><FONT SIZE=-1><LI TYPE=DISC>For a type, the full type declaration of any parts (including
the type itself) that are private.</LI></FONT></UL>
<DIV Class="Paranum"><FONT SIZE=-2>1.h</FONT></DIV>
<UL Class="SmallBulleted"><FONT SIZE=-1><LI TYPE=DISC>For a deferred constant, the full constant declaration,
which gives the constant's value. (Since this information necessarily
comes after the constant's type and subtype are fully known, there's
no need to worry about its type or subtype.)</LI></FONT></UL>
<DIV Class="Paranum"><FONT SIZE=-2>1.i</FONT></DIV>
<UL Class="SmallBulleted"><FONT SIZE=-1><LI TYPE=DISC>For any entity, representation information specified by
the user via representation items. Most representation items are for
types or subtypes; however, various other kinds of entities, such as
objects and subprograms, are possible. </LI></FONT></UL>
<DIV Class="Paranum"><FONT SIZE=-2>1.j</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Similar issues arise for incomplete
types. However, we do not use freezing there; incomplete types have different,
more severe, restrictions. Similar issues also arise for subprograms,
protected operations, tasks and generic units. However, we do not use
freezing there either; <A HREF="AA-3-11.html">3.11</A> prevents problems
with run-time Elaboration_Checks. </FONT></DIV>

<H4 ALIGN=CENTER>Language Design Principles</H4>
<DIV Class="Paranum"><FONT SIZE=-2>1.k</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>An evaluable construct should
freeze anything that's needed to evaluate it.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>1.l</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>However, if the construct is not
evaluated where it appears, let it cause freezing later, when it is evaluated.
This is the case for <FONT FACE="Arial, Helvetica">default_expression</FONT>s
and <FONT FACE="Arial, Helvetica">default_name</FONT>s. (Formal parameters,
generic formal parameters, and components can have <FONT FACE="Arial, Helvetica">default_expression</FONT>s
or <FONT FACE="Arial, Helvetica">default_name</FONT>s.)</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>1.m</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The compiler should be allowed
to evaluate static expressions without knowledge of their context. (I.e.
there should not be any special rules for static expressions that happen
to occur in a context that requires a static expression.)</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>1.n</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Compilers should be allowed to
evaluate static expressions (and record the results) using the run-time
representation of the type. For example, suppose Color'Pos(Red) = 1,
but the internal code for Red is 37. If the value of a static expression
is Red, some compilers might store 1 in their symbol table, and other
compilers might store 37. Either compiler design should be feasible.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>1.o</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Compilers should never be required
to detect erroneousness or exceptions at compile time (although it's
very nice if they do). This implies that we should not require code-generation
for a nonstatic expression of type <I>T</I> too early, even if we can
prove that that expression will be erroneous, or will raise an exception.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>1.p</FONT></DIV>
<DIV Class="Annotations" Style="margin-bottom: 0.4em"><FONT SIZE=-1>Here's
an example (modified from AI83-00039, Example 3): </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>1.q</FONT></DIV>
<DIV Class="SmallExamples"><TT><B>type</B>&nbsp;T&nbsp;<B>is</B><BR>
&nbsp;&nbsp;&nbsp;&nbsp;<B>record</B><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;...<BR>
&nbsp;&nbsp;&nbsp;&nbsp;<B>end</B>&nbsp;<B>record</B>;<BR>
<B>function</B>&nbsp;F&nbsp;<B>return</B>&nbsp;T;<BR>
<B>function</B>&nbsp;G(X&nbsp;:&nbsp;T)&nbsp;<B>return</B>&nbsp;Boolean;<BR>
Y&nbsp;:&nbsp;Boolean&nbsp;:=&nbsp;G(F);&nbsp;--<I>&nbsp;doesn't&nbsp;force&nbsp;T&nbsp;in&nbsp;Ada&nbsp;83</I><BR>
<B>for</B>&nbsp;T&nbsp;<B>use</B><BR>
&nbsp;&nbsp;&nbsp;&nbsp;<B>record</B><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;...<BR>
&nbsp;&nbsp;&nbsp;&nbsp;<B>end</B>&nbsp;<B>record</B>;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>1.r</FONT></DIV>
<DIV Class="Annotations" Style="margin-bottom: 0.4em"><FONT SIZE=-1>AI83-00039
says this is legal. Of course, it raises Program_Error because the function
bodies aren't elaborated yet. A one-pass compiler has to generate code
for an expression of type T before it knows the representation of T.
Here's a similar example, which AI83-00039 also says is legal: </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>1.s</FONT></DIV>
<DIV Class="SmallExamples"><TT><B>package</B>&nbsp;P&nbsp;<B>is</B><BR>
&nbsp;&nbsp;&nbsp;&nbsp;<B>type</B>&nbsp;T&nbsp;<B>is</B>&nbsp;<B>private</B>;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;<B>function</B>&nbsp;F&nbsp;<B>return</B>&nbsp;T;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;<B>function</B>&nbsp;G(X&nbsp;:&nbsp;T)&nbsp;<B>return</B>&nbsp;Boolean;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;Y&nbsp;:&nbsp;Boolean&nbsp;:=&nbsp;G(F);&nbsp;--<I>&nbsp;doesn't&nbsp;force&nbsp;T&nbsp;in&nbsp;Ada&nbsp;83</I><BR>
<B>private</B><BR>
&nbsp;&nbsp;&nbsp;&nbsp;<B>type</B>&nbsp;T&nbsp;<B>is</B><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<B>record</B><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;...<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<B>end</B>&nbsp;<B>record</B>;<BR>
<B>end</B>&nbsp;P;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>1.t</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>If T's size were dynamic, that
size would be stored in some compiler-generated dope; this dope would
be initialized at the place of the full type declaration. However, the
generated code for the function calls would most likely allocate a temp
of the size specified by the dope <I>before</I> checking for Program_Error.
That dope would contain uninitialized junk, resulting in disaster. To
avoid doing that, the compiler would have to determine, at compile time,
that the expression will raise Program_Error.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>1.u</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>This is silly. If we're going
to require compilers to detect the exception at compile time, we might
as well formulate the rule as a legality rule.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>1.v</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Compilers should not be required
to generate code to load the value of a variable before the address of
the variable has been determined.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>1.w</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>After an entity has been frozen,
no further requirements may be placed on its representation (such as
by a representation item or a <FONT FACE="Arial, Helvetica">full_type_declaration</FONT>).
</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>2</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;<A NAME="I4750"></A><A NAME="I4751"></A>The <I>freezing</I>
of an entity occurs at one or more places (<I>freezing points</I>) in
the program text where the representation for the entity has to be fully
determined. Each entity is frozen from its first freezing point to the
end of the program text (given the ordering of compilation units defined
in <A HREF="AA-10-1-4.html">10.1.4</A>). </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>2.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>The ``representation''
for a subprogram includes its calling convention and means for referencing
the subprogram body, either a ``link-name'' or specified address. It
does not include the code for the subprogram body itself, nor its address
if a link-name is used to reference the body. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>3/1</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{<I><A HREF="defect1.html#8652/0014">8652/0014</A></I>}
<A NAME="I4752"></A>The end of a <FONT FACE="Arial, Helvetica">declarative_part</FONT>,
<FONT FACE="Arial, Helvetica">protected_body</FONT>, or a declaration
of a library package or generic library package, causes <I>freezing</I>
of each entity declared within it, except for incomplete types. <A NAME="I4753"></A>A
noninstance body<U> other than a renames-as-body</U> causes freezing
of each entity declared before it within the same <FONT FACE="Arial, Helvetica">declarative_part</FONT>.
</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>3.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>This is worded
carefully to handle nested packages and private types. Entities declared
in a nested <FONT FACE="Arial, Helvetica">package_specification</FONT>
will be frozen by some containing construct.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>3.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>An incomplete type declared in
the private part of a library <FONT FACE="Arial, Helvetica">package_specification</FONT>
can be completed in the body. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>3.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>The part
about bodies does not say <I>immediately</I> within. A renaming-as-body
does not have this property. Nor does a <FONT FACE="Arial, Helvetica">pragma</FONT>
Import. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>3.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>The reason bodies
cause freezing is because we want <FONT FACE="Arial, Helvetica">proper_bodies</FONT>
and <FONT FACE="Arial, Helvetica">body_stub</FONT>s to be interchangeable
-- one should be able to move a <FONT FACE="Arial, Helvetica">proper_body</FONT>
to a <FONT FACE="Arial, Helvetica">subunit</FONT>, and vice-versa, without
changing the semantics. Clearly, anything that should cause freezing
should do so even if it's inside a <FONT FACE="Arial, Helvetica">proper_body</FONT>.
However, if we make it a <FONT FACE="Arial, Helvetica">body_stub</FONT>,
then the compiler can't see that thing that should cause freezing. So
we make <FONT FACE="Arial, Helvetica">body_stub</FONT>s cause freezing,
just in case they contain something that should cause freezing. But that
means we need to do the same for <FONT FACE="Arial, Helvetica">proper_bodies</FONT>.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>3.e</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Another reason for bodies to cause
freezing, there could be an added implementation burden if an entity
declared in an enclosing <FONT FACE="Arial, Helvetica">declarative_part</FONT>
is frozen within a nested body, since some compilers look at bodies after
looking at the containing <FONT FACE="Arial, Helvetica">declarative_part</FONT>.
</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>4/1</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{<I><A HREF="defect1.html#8652/0046">8652/0046</A></I>}
<A NAME="I4754"></A>A construct that (explicitly or implicitly) references
an entity can cause the <I>freezing</I> of the entity, as defined by
subsequent paragraphs. <A NAME="I4755"></A>At the place where a construct
causes freezing, each <FONT FACE="Arial, Helvetica">name</FONT>, <U><FONT FACE="Arial, Helvetica">expression</FONT>,
<FONT FACE="Arial, Helvetica">implicit_dereference</FONT></U><S>expression</S>[,
or <FONT FACE="Arial, Helvetica">range</FONT>] within the construct causes
freezing: </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>4.a</FONT></DIV>
<DIV Class="Annotations" Style="margin-bottom: 0.4em"><FONT SIZE=-1><B>Ramification:
</B>Note that in the sense of this paragraph, a <FONT FACE="Arial, Helvetica">subtype_mark</FONT>
``references'' the denoted subtype, but not the type. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>5</FONT></DIV>
<UL Class="Bulleted" Style="margin-bottom: 0.3em"><LI TYPE=DISC><A NAME="I4756"></A>The occurrence of a <FONT FACE="Arial, Helvetica">generic_instantiation</FONT>
causes freezing; also, if a parameter of the instantiation is defaulted,
the <FONT FACE="Arial, Helvetica">default_expression</FONT> or <FONT FACE="Arial, Helvetica">default_name</FONT>
for that parameter causes freezing.</LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>6</FONT></DIV>
<UL Class="Bulleted" Style="margin-bottom: 0.3em"><LI TYPE=DISC><A NAME="I4757"></A>The occurrence of an <FONT FACE="Arial, Helvetica">object_declaration</FONT>
that has no corresponding completion causes freezing. </LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>6.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>Note that
this does not include a <FONT FACE="Arial, Helvetica">formal_object_declaration</FONT>.
</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>7</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC><A NAME="I4758"></A>The declaration of a record extension
causes freezing of the parent subtype. </LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>7.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>This combined
with another rule specifying that primitive subprogram declarations shall
precede freezing ensures that all descendants of a tagged type implement
all of its dispatching operations.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>7.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The declaration of a private extension
does not cause freezing. The freezing is deferred until the full type
declaration, which will necessarily be for a record extension. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>8/1</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{<I><A HREF="defect1.html#8652/0046">8652/0046</A></I>}
<A NAME="I4759"></A>A static expression causes freezing where it occurs.
<U><A NAME="I4760"></A>An object name or</U><S>A</S> nonstatic expression
causes freezing where it occurs, unless the <U>name or </U>expression
is part of a <FONT FACE="Arial, Helvetica">default_expression</FONT>,
a <FONT FACE="Arial, Helvetica">default_name</FONT>, or a per-object
expression of a component's <FONT FACE="Arial, Helvetica">constraint</FONT>,
in which case, the freezing occurs later as part of another construct.</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>8.1/1</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{<I><A HREF="defect1.html#8652/0046">8652/0046</A></I>}
<U><A NAME="I4761"></A>An implicit call freezes the same entities that
would be frozen by an explicit call. This is true even if the implicit
call is removed via implementation permissions.</U></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>8.2/1</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{<I><A HREF="defect1.html#8652/0046">8652/0046</A></I>}
<U><A NAME="I4762"></A>If an expression is implicitly converted to a
type or subtype <I>T</I>, then at the place where the expression causes
freezing, <I>T</I> is frozen.</U></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>9</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em">&nbsp;&nbsp;&nbsp;The following rules
define which entities are frozen at the place where a construct causes
freezing: </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>10</FONT></DIV>
<UL Class="Bulleted" Style="margin-bottom: 0.3em"><LI TYPE=DISC><A NAME="I4763"></A>At the place where an expression causes
freezing, the type of the expression is frozen, unless the expression
is an enumeration literal used as a <FONT FACE="Arial, Helvetica">discrete_choice</FONT>
of the <FONT FACE="Arial, Helvetica">array_aggregate</FONT> of an <FONT FACE="Arial, Helvetica">enumeration_representation_clause</FONT>.
</LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>10.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>We considered making
enumeration literals never cause freezing, which would be more upward
compatible, but examples like the variant record aggregate (Discrim =&gt;
Red, ...) caused us to change our mind. Furthermore, an enumeration literal
is a static expression, so the implementation should be allowed to represent
it using its representation. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>10.b</FONT></DIV>
<DIV Class="Annotations" Style="margin-bottom: 0.4em"><FONT SIZE=-1><B>Ramification:
</B>The following pathological example was legal in Ada 83, but is illegal
in Ada 95: </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>10.c</FONT></DIV>
<DIV Class="SmallExamples"><TT><B>package</B>&nbsp;P1&nbsp;<B>is</B><BR>
&nbsp;&nbsp;&nbsp;&nbsp;<B>type</B>&nbsp;T&nbsp;<B>is</B>&nbsp;<B>private</B>;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;<B>package</B>&nbsp;P2&nbsp;<B>is</B><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<B>type</B>&nbsp;Composite(D&nbsp;:&nbsp;Boolean)&nbsp;<B>is</B><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<B>record</B><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<B>case</B>&nbsp;D&nbsp;<B>is</B><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<B>when</B>&nbsp;False&nbsp;=&gt;&nbsp;Cf&nbsp;:&nbsp;Integer;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<B>when</B>&nbsp;True&nbsp;&nbsp;=&gt;&nbsp;Ct&nbsp;:&nbsp;T;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<B>end</B>&nbsp;<B>case</B>;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<B>end</B>&nbsp;<B>record</B>;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;<B>end</B>&nbsp;P2;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;X&nbsp;:&nbsp;Boolean&nbsp;:=&nbsp;P2.&quot;=&quot;(&nbsp;(False,1),&nbsp;(False,1)&nbsp;);<BR>
<B>private</B><BR>
&nbsp;&nbsp;&nbsp;&nbsp;<B>type</B>&nbsp;T&nbsp;<B>is</B>&nbsp;<B>array</B>(1..Func_Call)&nbsp;<B>of</B>&nbsp;Integer;<BR>
<B>end</B>;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>10.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>In Ada 95, the declaration of
X freezes Composite (because it contains an expression of that type),
which in turn freezes T (even though Ct does not exist in this particular
case). But type T is not completely defined at that point, violating
the rule that a type shall be completely defined before it is frozen.
In Ada 83, on the other hand, there is no occurrence of the name T, hence
no forcing occurrence of T. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>11</FONT></DIV>
<UL Class="Bulleted" Style="margin-bottom: 0.3em"><LI TYPE=DISC><A NAME="I4764"></A>At the place where a <FONT FACE="Arial, Helvetica">name</FONT>
causes freezing, the entity denoted by the <FONT FACE="Arial, Helvetica">name</FONT>
is frozen, unless the <FONT FACE="Arial, Helvetica">name</FONT> is a
<FONT FACE="Arial, Helvetica">prefix</FONT> of an expanded name; <A NAME="I4765"></A>at
the place where an object <FONT FACE="Arial, Helvetica">name</FONT> causes
freezing, the nominal subtype associated with the <FONT FACE="Arial, Helvetica">name</FONT>
is frozen. </LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>11.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>This only
matters in the presence of deferred constants or access types; an <FONT FACE="Arial, Helvetica">object_declaration</FONT>
other than a <FONT FACE="Arial, Helvetica">deferred_constant_declaration</FONT>
causes freezing of the nominal subtype, plus all component junk.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>11.b/1</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><FONT SIZE=-1><I>This paragraph
was deleted.</I></FONT>{<I><A HREF="defect1.html#8652/0046">8652/0046</A></I>}
<S><FONT FACE="Arial, Helvetica">Implicit_dereference</FONT>s are covered
by <FONT FACE="Arial, Helvetica">expression</FONT>.</S> </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>11.1/1</FONT></DIV>
<UL Class="Bulleted" Style="margin-bottom: 0.3em"><LI TYPE=DISC>{<I><A HREF="defect1.html#8652/0046">8652/0046</A></I>}
<U><A NAME="I4766"></A>At the place where an <FONT FACE="Arial, Helvetica">implicit_dereference</FONT>
causes freezing, the nominal subtype associated with the <FONT FACE="Arial, Helvetica">implicit_dereference</FONT>
is frozen.</U></LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>12</FONT></DIV>
<UL Class="Bulleted" Style="margin-bottom: 0.3em"><LI TYPE=DISC>[<A NAME="I4767"></A> At the place where a <FONT FACE="Arial, Helvetica">range</FONT>
causes freezing, the type of the <FONT FACE="Arial, Helvetica">range</FONT>
is frozen.] </LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>12.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Proof: </B>This is consequence
of the facts that expressions freeze their type, and the Range attribute
is defined to be equivalent to a pair of expressions separated by ``..''.}
</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>13</FONT></DIV>
<UL Class="Bulleted" Style="margin-bottom: 0.3em"><LI TYPE=DISC><A NAME="I4768"></A>At the place where an <FONT FACE="Arial, Helvetica">allocator</FONT>
causes freezing, the designated subtype of its type is frozen. If the
type of the <FONT FACE="Arial, Helvetica">allocator</FONT> is a derived
type, then all ancestor types are also frozen. </LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>13.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B><FONT FACE="Arial, Helvetica">Allocator</FONT>s
also freeze the named subtype, as a consequence of other rules.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>13.b</FONT></DIV>
<DIV Class="Annotations" Style="margin-bottom: 0.4em"><FONT SIZE=-1>The
ancestor types are frozen to prevent things like this: </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>13.c</FONT></DIV>
<DIV Class="SmallExamples"><TT><B>type</B>&nbsp;Pool_Ptr&nbsp;<B>is</B>&nbsp;<B>access</B>&nbsp;System.Storage_Pools.Root_Storage_Pool'Class;<BR>
<B>function</B>&nbsp;F&nbsp;<B>return</B>&nbsp;Pool_Ptr;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>13.d</FONT></DIV>
<DIV Class="SmallExamples"><TT><B>package</B>&nbsp;P&nbsp;<B>is</B><BR>
&nbsp;&nbsp;&nbsp;&nbsp;<B>type</B>&nbsp;A1&nbsp;<B>is</B>&nbsp;<B>access</B>&nbsp;Boolean;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;<B>type</B>&nbsp;A2&nbsp;<B>is</B>&nbsp;<B>new</B>&nbsp;A1;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;<B>type</B>&nbsp;A3&nbsp;<B>is</B>&nbsp;<B>new</B>&nbsp;A2;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;X&nbsp;:&nbsp;A3&nbsp;:=&nbsp;<B>new</B>&nbsp;Boolean;&nbsp;--<I>&nbsp;Don't&nbsp;know&nbsp;what&nbsp;pool&nbsp;yet!</I><BR>
&nbsp;&nbsp;&nbsp;&nbsp;<B>for</B>&nbsp;A1'Storage_Pool&nbsp;<B>use</B>&nbsp;F.all;<BR>
<B>end</B>&nbsp;P;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>13.e</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>This is necessary because derived
access types share their parent's pool. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>14</FONT></DIV>
<UL Class="Bulleted" Style="margin-bottom: 0.3em"><LI TYPE=DISC><A NAME="I4769"></A>At the place where a callable entity
is frozen, each subtype of its profile is frozen. If the callable entity
is a member of an entry family, the index subtype of the family is frozen.
<A NAME="I4770"></A>At the place where a function call causes freezing,
if a parameter of the call is defaulted, the <FONT FACE="Arial, Helvetica">default_expression</FONT>
for that parameter causes freezing. </LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>14.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>We don't worry
about freezing for procedure calls or entry calls, since a body freezes
everything that precedes it, and the end of a declarative part freezes
everything in the declarative part. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>15</FONT></DIV>
<UL Class="Bulleted" Style="margin-bottom: 0.3em"><LI TYPE=DISC><A NAME="I4771"></A>At the place where a subtype is frozen,
its type is frozen. <A NAME="I4772"></A><A NAME="I4773"></A>At the place
where a type is frozen, any expressions or <FONT FACE="Arial, Helvetica">name</FONT>s
within the full type definition cause freezing; the first subtype, and
any component subtypes, index subtypes, and parent subtype of the type
are frozen as well. <A NAME="I4774"></A><A NAME="I4775"></A>For a specific
tagged type, the corresponding class-wide type is frozen as well. For
a class-wide type, the corresponding specific type is frozen as well.
</LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>15.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>Freezing
a type needs to freeze its first subtype in order to preserve the property
that the subtype-specific aspects of statically matching subtypes are
the same.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>15.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Freezing an access type does not
freeze its designated subtype. </FONT></DIV>

<H4 ALIGN=CENTER>Legality Rules</H4>
<DIV Class="Paranum"><FONT SIZE=-2>16</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em">&nbsp;&nbsp;&nbsp;&nbsp;[The explicit declaration
of a primitive subprogram of a tagged type shall occur before the type
is frozen (see <A HREF="AA-3-9-2.html">3.9.2</A>).] </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>16.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>This rule is needed
because (1) we don't want people dispatching to things that haven't been
declared yet, and (2) we want to allow tagged type descriptors to be
static (allocated statically, and initialized to link-time-known symbols).
Suppose T2 inherits primitive P from T1, and then overrides P. Suppose
P is called <I>before</I> the declaration of the overriding P. What should
it dispatch to? If the answer is the new P, we've violated the first
principle above. If the answer is the old P, we've violated the second
principle. (A call to the new one necessarily raises Program_Error, but
that's beside the point.)</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>16.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Note that a call upon a dispatching
operation of type <I>T</I> will freeze <I>T</I>.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>16.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>We considered applying this rule
to all derived types, for uniformity. However, that would be upward incompatible,
so we rejected the idea. As in Ada 83, for an untagged type, the above
call upon P will call the old P (which is arguably confusing). </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>17</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em">&nbsp;&nbsp;&nbsp;&nbsp;[A type shall be
completely defined before it is frozen (see <A HREF="AA-3-11-1.html">3.11.1</A>
and <A HREF="AA-7-3.html">7.3</A>).]</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>18</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em">&nbsp;&nbsp;&nbsp;&nbsp;[The completion
of a deferred constant declaration shall occur before the constant is
frozen (see <A HREF="AA-7-4.html">7.4</A>).]</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19/1</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{<I><A HREF="defect1.html#8652/0009">8652/0009</A></I>}
<U>An operational or</U><S>A</S> representation item that directly specifies
an aspect of an entity shall appear before the entity is frozen (see
<A HREF="AA-13-1.html">13.1</A>). </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19.a/1</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>{<I><A HREF="defect1.html#8652/0009">8652/0009</A></I>}
From RM83-13.1(7). The wording here forbids freezing within the <U><FONT FACE="Arial, Helvetica">aspect_clause</FONT></U><S><FONT FACE="Arial, Helvetica">representation_clause</FONT></S>
itself, which was not true of the Ada 83 wording. The wording of this
rule is carefully written to work properly for type-related representation
items. For example, an <FONT FACE="Arial, Helvetica">enumeration_representation_clause</FONT>
is illegal after the type is frozen, even though the <FONT FACE="Arial, Helvetica">_clause</FONT>
refers to the first subtype. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Proof: </B>The above Legality
Rules are stated ``officially'' in the referenced clauses. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19.c</FONT></DIV>
<DIV Class="Annotations" Style="margin-bottom: 0.4em"><FONT SIZE=-1><B>Discussion:
</B>Here's an example that illustrates when freezing occurs in the presence
of defaults: </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19.d</FONT></DIV>
<DIV Class="SmallExamples"><TT><B>type</B>&nbsp;T&nbsp;<B>is</B>&nbsp;...;<BR>
<B>function</B>&nbsp;F&nbsp;<B>return</B>&nbsp;T;<BR>
<B>type</B>&nbsp;R&nbsp;<B>is</B><BR>
&nbsp;&nbsp;&nbsp;&nbsp;<B>record</B><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;C&nbsp;:&nbsp;T&nbsp;:=&nbsp;F;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;D&nbsp;:&nbsp;Boolean&nbsp;:=&nbsp;F&nbsp;=&nbsp;F;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;<B>end</B>&nbsp;<B>record</B>;<BR>
X&nbsp;:&nbsp;R;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19.e</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Since the elaboration of R's declaration
does not allocate component C, there is no need to freeze C's subtype
at that place. Similarly, since the elaboration of R does not evaluate
the <FONT FACE="Arial, Helvetica">default_expression</FONT> ``F = F'',
there is no need to freeze the types involved at that point. However,
the declaration of X <I>does</I> need to freeze these things. Note that
even if component C did not exist, the elaboration of the declaration
of X would still need information about T -- even though D is not of
type T, its <FONT FACE="Arial, Helvetica">default_expression</FONT> requires
that information. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19.f</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>Although
we define freezing in terms of the program text as a whole (i.e. after
applying the rules of Section 10), the freezing rules actually have no
effect beyond compilation unit boundaries. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19.g</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>That is important,
because Section 10 allows some implementation definedness in the order
of things, and we don't want the freezing rules to be implementation
defined. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19.h</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>These rules
also have no effect in <FONT FACE="Arial, Helvetica">statement</FONT>s
-- they only apply within a single <FONT FACE="Arial, Helvetica">declarative_part</FONT>,
<FONT FACE="Arial, Helvetica">package_specification</FONT>, <FONT FACE="Arial, Helvetica">task_definition</FONT>,
<FONT FACE="Arial, Helvetica">protected_definition</FONT>, or <FONT FACE="Arial, Helvetica">protected_body</FONT>.
</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19.i</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation Note: </B>An
implementation may choose to generate code for <FONT FACE="Arial, Helvetica">default_expression</FONT>s
and <FONT FACE="Arial, Helvetica">default_name</FONT>s in line at the
place of use. <A NAME="I4776"></A>Alternatively, an implementation may
choose to generate thunks (subprograms implicitly generated by the compiler)
for evaluation of defaults. Thunk generation cannot, in general, be done
at the place of the declaration that includes the default. Instead, they
can be generated at the first freezing point of the type(s) involved.
(It is impossible to write a purely one-pass Ada compiler, for various
reasons. This is one of them -- the compiler needs to store a representation
of defaults in its symbol table, and then walk that representation later,
no earlier than the first freezing point.)</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19.j</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>In implementation terms, the linear
elaboration model can be thought of as preventing uninitialized dope.
For example, the implementation might generate dope to contain the size
of a private type. This dope is initialized at the place where the type
becomes completely defined. It cannot be initialized earlier, because
of the order-of-elaboration rules. The freezing rules prevent elaboration
of earlier declarations from accessing the size dope for a private type
before it is initialized.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19.k</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><A HREF="AA-2-8.html">2.8</A>
overrides the freezing rules in the case of unrecognized <FONT FACE="Arial, Helvetica">pragma</FONT>s.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19.l/1</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>{<I><A HREF="defect1.html#8652/0009">8652/0009</A></I>}
<U>An <FONT FACE="Arial, Helvetica">aspect_clause</FONT></U><S>A <FONT FACE="Arial, Helvetica">representation_clause</FONT></S>
for an entity should most certainly <I>not</I> be a freezing point for
the entity. </FONT></DIV>

<H4 ALIGN=CENTER>Incompatibilities With Ada 83</H4>
<DIV Class="Paranum"><FONT SIZE=-2>19.m</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><A NAME="I4777"></A>RM83 defines
a forcing occurrence of a type as follows: ``A forcing occurrence is
any occurrence [of the name of the type, subtypes of the type, or types
or subtypes with subcomponents of the type] other than in a type or subtype
declaration, a subprogram specification, an entry declaration, a deferred
constant declaration, a <FONT FACE="Arial, Helvetica">pragma</FONT>,
or a <FONT FACE="Arial, Helvetica">representation_clause</FONT> for the
type itself. In any case, an occurrence within an expression is always
forcing.''</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19.n</FONT></DIV>
<DIV Class="Annotations" Style="margin-bottom: 0.4em"><FONT SIZE=-1>It
seems like the wording allows things like this: </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19.o</FONT></DIV>
<DIV Class="SmallExamples"><TT><B>type</B>&nbsp;A&nbsp;<B>is</B>&nbsp;<B>array</B>(Integer&nbsp;<B>range</B>&nbsp;1..10)&nbsp;<B>of</B>&nbsp;Boolean;<BR>
<B>subtype</B>&nbsp;S&nbsp;<B>is</B>&nbsp;Integer&nbsp;<B>range</B>&nbsp;A'Range;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;--<I>&nbsp;not&nbsp;forcing&nbsp;for&nbsp;A</I></TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19.p</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Occurrences within <FONT FACE="Arial, Helvetica">pragma</FONT>s
can cause freezing in Ada 95. (Since such <FONT FACE="Arial, Helvetica">pragma</FONT>s
are ignored in Ada 83, this will probably fix more bugs than it causes.)
</FONT></DIV>

<H4 ALIGN=CENTER>Extensions to Ada 83</H4>
<DIV Class="Paranum"><FONT SIZE=-2>19.q</FONT></DIV>
<DIV Class="Annotations" Style="margin-bottom: 0.4em"><FONT SIZE=-1><A NAME="I4778"></A>In
Ada 95, <FONT FACE="Arial, Helvetica">generic_formal_parameter_declaration</FONT>s
do not normally freeze the entities from which they are defined. For
example: </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19.r</FONT></DIV>
<DIV Class="SmallExamples"><TT><B>package</B>&nbsp;Outer&nbsp;<B>is</B><BR>
&nbsp;&nbsp;&nbsp;&nbsp;<B>type</B>&nbsp;T&nbsp;<B>is</B>&nbsp;<B>tagged</B>&nbsp;<B>limited</B>&nbsp;<B>private</B>;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;<B>generic</B><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<B>type</B>&nbsp;T2&nbsp;<B>is</B><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<B>new</B>&nbsp;T&nbsp;<B>with</B>&nbsp;<B>private</B>;&nbsp;--<I>&nbsp;Does&nbsp;not&nbsp;freeze&nbsp;T</I><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;--<I>&nbsp;in&nbsp;Ada&nbsp;95.</I><BR>
&nbsp;&nbsp;&nbsp;&nbsp;<B>package</B>&nbsp;Inner&nbsp;<B>is</B><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;...<BR>
&nbsp;&nbsp;&nbsp;&nbsp;<B>end</B>&nbsp;Inner;<BR>
<B>private</B><BR>
&nbsp;&nbsp;&nbsp;&nbsp;<B>type</B>&nbsp;T&nbsp;<B>is</B>&nbsp;...;<BR>
<B>end</B>&nbsp;Outer;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19.s</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>This is important for the usability
of generics. The above example uses the Ada 95 feature of formal derived
types. Examples using the kinds of formal parameters already allowed
in Ada 83 are well known. See, for example, comments 83-00627 and 83-00688.
The extensive use expected for formal derived types makes this issue
even more compelling than described by those comments. Unfortunately,
we are unable to solve the problem that <FONT FACE="Arial, Helvetica">explicit_generic_actual_parameter</FONT>s
cause freezing, even though a package equivalent to the instance would
not cause freezing. This is primarily because such an equivalent package
would have its body in the body of the containing program unit, whereas
an instance has its body right there. </FONT></DIV>

<H4 ALIGN=CENTER>Wording Changes from Ada 83</H4>
<DIV Class="Paranum"><FONT SIZE=-2>19.t</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The concept of freezing is based
on Ada 83's concept of ``forcing occurrences.'' The first freezing point
of an entity corresponds roughly to the place of the first forcing occurrence,
in Ada 83 terms. The reason for changing the terminology is that the
new rules do not refer to any particular ``occurrence'' of a name of
an entity. Instead, we refer to ``uses'' of an entity, which are sometimes
implicit.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19.u</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>In Ada 83, forcing occurrences
were used only in rules about <FONT FACE="Arial, Helvetica">representation_clause</FONT>s.
We have expanded the concept to cover private types, because the rules
stated in RM83-7.4.1(4) are almost identical to the forcing occurrence
rules.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19.v</FONT></DIV>
<DIV Class="Annotations" Style="margin-bottom: 0.4em"><FONT SIZE=-1>The
Ada 83 rules are changed in Ada 95 for the following reasons: </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19.w</FONT></DIV>
<UL Class="SmallBulleted"><FONT SIZE=-1><LI TYPE=DISC>The Ada 83 rules do not work right for subtype-specific
aspects. In an earlier version of Ada 95, we considered allowing representation
items to apply to subtypes other than the first subtype. This was part
of the reason for changing the Ada 83 rules. However, now that we have
dropped that functionality, we still need the rules to be different from
the Ada 83 rules.</LI></FONT></UL>
<DIV Class="Paranum"><FONT SIZE=-2>19.x</FONT></DIV>
<UL Class="SmallBulleted"><FONT SIZE=-1><LI TYPE=DISC>The Ada 83 rules do not achieve the intended effect. In
Ada 83, either with or without the AIs, it is possible to force the compiler
to generate code that references uninitialized dope, or force it to detect
erroneousness and exception raising at compile time.</LI></FONT></UL>
<DIV Class="Paranum"><FONT SIZE=-2>19.y</FONT></DIV>
<UL Class="SmallBulleted"><FONT SIZE=-1><LI TYPE=DISC>It was a goal of Ada 83 to avoid uninitialized access values.
However, in the case of deferred constants, this goal was not achieved.</LI></FONT></UL>
<DIV Class="Paranum"><FONT SIZE=-2>19.z</FONT></DIV>
<UL Class="SmallBulleted"><FONT SIZE=-1><LI TYPE=DISC>The Ada 83 rules are not only too weak -- they are also
too strong. They allow loopholes (as described above), but they also
prevent certain kinds of <FONT FACE="Arial, Helvetica">default_expression</FONT>s
that are harmless, and certain kinds of <FONT FACE="Arial, Helvetica">generic_declaration</FONT>s
that are both harmless and very useful.</LI></FONT></UL>
<DIV Class="Paranum"><FONT SIZE=-2>19.aa</FONT></DIV>
<UL Class="SmallBulleted"><FONT SIZE=-1><LI TYPE=DISC>Ada 83 had a case where a <FONT FACE="Arial, Helvetica">representation_clause</FONT>
had a strong effect on the semantics of the program -- 'Small. This caused
certain semantic anomalies. There are more cases in Ada 95, because the
<FONT FACE="Arial, Helvetica">attribute_representation_clause</FONT>
has been generalized. </LI></FONT></UL>

<HR>
<P><A HREF="AA-TOC.html">Contents</A>&nbsp;&nbsp;&nbsp;<A HREF="AA-0-29.html">Index</A>&nbsp;&nbsp;&nbsp;<A HREF="AA-13-13-2.html">Previous</A>&nbsp;&nbsp;&nbsp;<A HREF="AA-0-28.html">Next</A>&nbsp;&nbsp;&nbsp;<A HREF="AA-TTL.html">Legal</A></P>
</BODY>
</HTML>