File: RM-01.txt

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 (554 lines) | stat: -rw-r--r-- 20,645 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





=====================================================================

INTERNATIONAL STANDARD                                 ISO/IEC 8652:1995(E)
with COR.1:2000


=====================================================================

 
 
 


Information technology - Programming

Languages - Ada

 
 
 



                             Section 1: General


1     Ada is a programming language designed to support the construction of
long-lived, highly reliable software systems. The language includes facilities
to define packages of related types, objects, and operations. The packages may
be parameterized and the types may be extended to support the construction of
libraries of reusable, adaptable software components. The operations may be
implemented as subprograms using conventional sequential control structures,
or as entries that include synchronization of concurrent threads of control as
part of their invocation. The language treats modularity in the physical sense
as well, with a facility to support separate compilation.

2     The language includes a complete facility for the support of real-time,
concurrent programming. Errors can be signaled as exceptions and handled
explicitly. The language also covers systems programming; this requires
precise control over the representation of data and access to system-dependent
properties. Finally, a predefined environment of standard packages is
provided, including facilities for, among others, input-output, string
manipulation, numeric elementary functions, and random number generation.


1.1 Scope


1     This International Standard specifies the form and meaning of programs
written in Ada. Its purpose is to promote the portability of Ada programs to a
variety of data processing systems.


1.1.1 Extent


1     This International Standard specifies:

2     The form of a program written in Ada;

3     The effect of translating and executing such a program;

4     The manner in which program units may be combined to form Ada programs;

5     The language-defined library units that a conforming implementation is
      required to supply;

6     The permissible variations within the standard, and the manner in which
      they are to be documented;

7     Those violations of the standard that a conforming implementation is
      required to detect, and the effect of attempting to translate or execute
      a program containing such violations;

8     Those violations of the standard that a conforming implementation is not
      required to detect.

9     This International Standard does not specify:

10    The means whereby a program written in Ada is transformed into object
      code executable by a processor;

11    The means whereby translation or execution of programs is invoked and
      the executing units are controlled;

12    The size or speed of the object code, or the relative execution speed of
      different language constructs;

13    The form or contents of any listings produced by implementations; in
      particular, the form or contents of error or warning messages;

14    The effect of unspecified execution.

15    The size of a program or program unit that will exceed the capacity of a
      particular conforming implementation.


1.1.2 Structure


1     This International Standard contains thirteen sections, fourteen
annexes, and an index.

2     The core of the Ada language consists of:

3     Sections 1 through 13

4     Annex A, ``Predefined Language Environment''

5     Annex B, ``Interface to Other Languages''

6     Annex J, ``Obsolescent Features''

7     The following Specialized Needs Annexes define features that are needed
by certain application areas:

8     Annex C, ``Systems Programming''

9     Annex D, ``Real-Time Systems''

10    Annex E, ``Distributed Systems''

11    Annex F, ``Information Systems''

12    Annex G, ``Numerics''

13    Annex H, ``Safety and Security''

14    The core language and the Specialized Needs Annexes are normative,
except that the material in each of the items listed below is informative:

15    Text under a NOTES or Examples heading.

16    Each clause or subclause whose title starts with the word ``Example'' or
      ``Examples''.

17    All implementations shall conform to the core language. In addition, an
implementation may conform separately to one or more Specialized Needs Annexes.

18    The following Annexes are informative:

19    Annex K, ``Language-Defined Attributes''

20    Annex L, ``Language-Defined Pragmas''

21    Annex M, ``Implementation-Defined Characteristics''

22    Annex N, ``Glossary''

23    Annex P, ``Syntax Summary''

24    Each section is divided into clauses and subclauses that have a common
structure. Each section, clause, and subclause first introduces its subject.
After the introductory text, text is labeled with the following headings:


                                   Syntax

25    Syntax rules (indented).


                            Name Resolution Rules

26    Compile-time rules that are used in name resolution, including overload
resolution.


                               Legality Rules

27    Rules that are enforced at compile time. A construct is legal if it
obeys all of the Legality Rules.


                              Static Semantics

28    A definition of the compile-time effect of each construct.


                           Post-Compilation Rules

29    Rules that are enforced before running a partition. A partition is legal
if its compilation units are legal and it obeys all of the
Post-Compilation Rules.


                              Dynamic Semantics

30    A definition of the run-time effect of each construct.


                          Bounded (Run-Time) Errors

31    Situations that result in bounded (run-time) errors (see 1.1.5).


                             Erroneous Execution

32    Situations that result in erroneous execution (see 1.1.5).


                         Implementation Requirements

33    Additional requirements for conforming implementations.


                         Documentation Requirements

34    Documentation requirements for conforming implementations.


                                   Metrics

35    Metrics that are specified for the time/space properties of the
execution of certain language constructs.


                         Implementation Permissions

36    Additional permissions given to the implementer.


                            Implementation Advice

37    Optional advice given to the implementer. The word ``should'' is used to
indicate that the advice is a recommendation, not a requirement. It is
implementation defined whether or not a given recommendation is obeyed.

      NOTES

38    1  Notes emphasize consequences of the rules described in the
      (sub)clause or elsewhere. This material is informative.


                                  Examples

39    Examples illustrate the possible forms of the constructs described. This
material is informative.


1.1.3 Conformity of an Implementation with the Standard



                         Implementation Requirements

1     A conforming implementation shall:

2     Translate and correctly execute legal programs written in Ada, provided
      that they are not so large as to exceed the capacity of the
      implementation;

3     Identify all programs or program units that are so large as to exceed
      the capacity of the implementation (or raise an appropriate exception at
      run time);

4     Identify all programs or program units that contain errors whose
      detection is required by this International Standard;

5     Supply all language-defined library units required by this International
      Standard;

6     Contain no variations except those explicitly permitted by this
      International Standard, or those that are impossible or impractical to
      avoid given the implementation's execution environment;

7     Specify all such variations in the manner prescribed by this
      International Standard.

8     The external effect of the execution of an Ada program is defined in
terms of its interactions with its external environment. The following are
defined as external interactions:

9     Any interaction with an external file (see A.7);

10    The execution of certain code_statements (see 13.8); which
      code_statements cause external interactions is implementation defined.

11    Any call on an imported subprogram (see Annex B), including any
      parameters passed to it;

12    Any result returned or exception propagated from a main subprogram (see
      10.2) or an exported subprogram (see Annex B) to an external caller;

13    Any read or update of an atomic or volatile object (see C.6);

14    The values of imported and exported objects (see Annex B) at the time of
      any other interaction with the external environment.

15    A conforming implementation of this International Standard shall produce
for the execution of a given Ada program a set of interactions with the
external environment whose order and timing are consistent with the
definitions and requirements of this International Standard for the semantics
of the given program.

16    An implementation that conforms to this Standard shall support each
capability required by the core language as specified. In addition, an
implementation that conforms to this Standard may conform to one or more
Specialized Needs Annexes (or to none). Conformance to a Specialized Needs
Annex means that each capability required by the Annex is provided as
specified.

17    An implementation conforming to this International Standard may provide
additional attributes, library units, and pragmas. However, it shall not
provide any attribute, library unit, or pragma having the same name as an
attribute, library unit, or pragma (respectively) specified in a Specialized
Needs Annex unless the provided construct is either as specified in the
Specialized Needs Annex or is more limited in capability than that required by
the Annex. A program that attempts to use an unsupported capability of an
Annex shall either be identified by the implementation before run time or
shall raise an exception at run time.


                         Documentation Requirements

18    Certain aspects of the semantics are defined to be either implementation
defined or unspecified. In such cases, the set of possible effects is
specified, and the implementation may choose any effect in the set.
Implementations shall document their behavior in implementation-defined
situations, but documentation is not required for unspecified situations. The
implementation-defined characteristics are summarized in Annex M.

19    The implementation may choose to document implementation-defined
behavior either by documenting what happens in general, or by providing some
mechanism for the user to determine what happens in a particular case.


                            Implementation Advice

20    If an implementation detects the use of an unsupported Specialized Needs
Annex feature at run time, it should raise Program_Error if feasible.

21    If an implementation wishes to provide implementation-defined extensions
to the functionality of a language-defined library unit, it should normally do
so by adding children to the library unit.

      NOTES

22    2  The above requirements imply that an implementation conforming to
      this Standard may support some of the capabilities required by a
      Specialized Needs Annex without supporting all required capabilities.


1.1.4 Method of Description and Syntax Notation


1     The form of an Ada program is described by means of a context-free
syntax together with context-dependent requirements expressed by narrative
rules.

2     The meaning of Ada programs is described by means of narrative rules
defining both the effects of each construct and the composition rules for
constructs.

3     The context-free syntax of the language is described using a simple
variant of Backus-Naur Form. In particular:

4     Lower case words in a sans-serif font, some containing embedded
      underlines, are used to denote syntactic categories, for example:

    5     case_statement

6     Boldface words are used to denote reserved words, for example:

    7     array

8     Square brackets enclose optional items. Thus the two following rules are
      equivalent.

    9     return_statement ::= return [expression];
          return_statement ::= return; | return expression;

10    Curly brackets enclose a repeated item. The item may appear zero or more
      times; the repetitions occur from left to right as with an equivalent
      left-recursive rule. Thus the two following rules are equivalent.

    11    term ::= factor {multiplying_operator factor}
          term ::= factor | term multiplying_operator factor

12    A vertical line separates alternative items unless it occurs immediately
      after an opening curly bracket, in which case it stands for itself:

    13    constraint ::= scalar_constraint | composite_constraint
          discrete_choice_list ::= discrete_choice {| discrete_choice}

14    If the name of any syntactic category starts with an italicized part, it
      is equivalent to the category name without the italicized part. The
      italicized part is intended to convey some semantic information. For
      example subtype_name and task_name are both equivalent to name alone.

15    A syntactic category is a nonterminal in the grammar defined in BNF
under ``Syntax.'' Names of syntactic categories are set in a different font,
like_this.

16    A construct is a piece of text (explicit or implicit) that is an
instance of a syntactic category defined under ``Syntax.''

17    A constituent of a construct is the construct itself, or any construct
appearing within it.

18    Whenever the run-time semantics defines certain actions to happen in an
arbitrary order, this means that the implementation shall arrange for these
actions to occur in a way that is equivalent to some sequential order,
following the rules that result from that sequential order. When evaluations
are defined to happen in an arbitrary order, with conversion of the results to
some subtypes, or with some run-time checks, the evaluations, conversions, and
checks may be arbitrarily interspersed, so long as each expression is
evaluated before converting or checking its value. Note that the effect of a
program can depend on the order chosen by the implementation. This can happen,
for example, if two actual parameters of a given call have side effects.

      NOTES

19    3  The syntax rules describing structured constructs are presented in a
      form that corresponds to the recommended paragraphing. For example, an
      if_statement is defined as:

20    if_statement ::=
          if condition then
            sequence_of_statements
         {elsif condition then
            sequence_of_statements}
         [else
            sequence_of_statements]
          end if;

21    4  The line breaks and indentation in the syntax rules indicate the
      recommended line breaks and indentation in the corresponding constructs.
      The preferred places for other line breaks are after semicolons.


1.1.5 Classification of Errors



                         Implementation Requirements

1     The language definition classifies errors into several different
categories:

2     Errors that are required to be detected prior to run time by every Ada
      implementation;

3     These errors correspond to any violation of a rule given in this
      International Standard, other than those listed below. In particular,
      violation of any rule that uses the terms shall, allowed, permitted,
      legal, or illegal belongs to this category. Any program that contains
      such an error is not a legal Ada program; on the other hand, the fact
      that a program is legal does not mean, per se, that the program is free
      from other forms of error.

4     The rules are further classified as either compile time rules, or post
      compilation rules, depending on whether a violation has to be detected
      at the time a compilation unit is submitted to the compiler, or may be
      postponed until the time a compilation unit is incorporated into a
      partition of a program.

5     Errors that are required to be detected at run time by the execution of
      an Ada program;

6     The corresponding error situations are associated with the names of the
      predefined exceptions. Every Ada compiler is required to generate code
      that raises the corresponding exception if such an error situation
      arises during program execution. If such an error situation is certain
      to arise in every execution of a construct, then an implementation is
      allowed (although not required) to report this fact at compilation time.

7     Bounded errors;

8     The language rules define certain kinds of errors that need not be
      detected either prior to or during run time, but if not detected, the
      range of possible effects shall be bounded. The errors of this category
      are called bounded errors. The possible effects of a given bounded error
      are specified for each such error, but in any case one possible effect
      of a bounded error is the raising of the exception Program_Error.

9     Erroneous execution.

10    In addition to bounded errors, the language rules define certain kinds
      of errors as leading to erroneous execution. Like bounded errors, the
      implementation need not detect such errors either prior to or during run
      time. Unlike bounded errors, there is no language-specified bound on the
      possible effect of erroneous execution; the effect is in general not
      predictable.


                         Implementation Permissions

11    An implementation may provide nonstandard modes of operation. Typically
these modes would be selected by a pragma or by a command line switch when the
compiler is invoked. When operating in a nonstandard mode, the implementation
may reject compilation_units that do not conform to additional requirements
associated with the mode, such as an excessive number of warnings or violation
of coding style guidelines. Similarly, in a nonstandard mode, the
implementation may apply special optimizations or alternative algorithms that
are only meaningful for programs that satisfy certain criteria specified by
the implementation. In any case, an implementation shall support a standard
mode that conforms to the requirements of this International Standard; in
particular, in the standard mode, all legal compilation_units shall be
accepted.


                            Implementation Advice

12    If an implementation detects a bounded error or erroneous execution, it
should raise Program_Error.


1.2 Normative References


1     The following standards contain provisions which, through reference in
this text, constitute provisions of this International Standard. At the time
of publication, the editions indicated were valid. All standards are subject
to revision, and parties to agreements based on this International Standard
are encouraged to investigate the possibility of applying the most recent
editions of the standards indicated below. Members of IEC and ISO maintain
registers of currently valid International Standards.

2     ISO/IEC 646:1991, Information technology - ISO 7-bit coded character set
for information interchange.

3     ISO/IEC 1539:1991, Information technology - Programming languages -
FORTRAN.

4     ISO 1989:1985, Programming languages - COBOL.

5     ISO/IEC 6429:1992, Information technology - Control functions for coded
graphic character sets.

6     ISO/IEC 8859-1:1987, Information processing - 8-bit single-byte coded
character sets - Part 1: Latin alphabet No. 1.

7     ISO/IEC 9899:1990, Programming languages - C.

8/1   ISO/IEC 10646-1:1993, Information technology - Universal Multiple-Octet
Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane,
supplemented by Technical Corrigendum 1:1996.


1.3 Definitions


1     Terms are defined throughout this International Standard, indicated by
italic type. Terms explicitly defined in this International Standard are not
to be presumed to refer implicitly to similar terms defined elsewhere. Terms
not defined in this International Standard are to be interpreted according to
the Webster's Third New International Dictionary of the English Language.
Informal descriptions of some terms are also given in Annex N, ``Glossary''.