OC Systems Wiki! bitnami_mediawiki http://sandbox.wgvc.com/w/index.php/OCS:OC_Systems MediaWiki 1.32.0 first-letter Media Special Talk User User talk docs.ocsystems.com docs.ocsystems.com talk File File talk MediaWiki MediaWiki talk Template Template talk Help Help talk Category Category talk Property Property talk Form Form talk Concept Concept talk smw/schema smw/schema talk Rule Rule talk OCS OCS talk PowerAda PowerAda talk Guide Guide talk Template:95lrm 10 854 4497 4496 2019-05-05T23:52:18Z WikiVisor 11 wikitext text/x-wiki Copyright © 1992,1993,1994,1995 Intermetrics, Inc.<br>Copyright © 2000 The MITRE Corporation, Inc. [[Category:95lrm]] <span class="guide" style="display: inline;">Ada Reference Manual</span> eh3pbr294p3du1o2n5wsqghcp1sga22 Guide:95lrm 4200 853 4500 4480 2019-05-06T00:03:01Z WikiVisor 11 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-TTL|Legal]]</div> <div class="jumbotron text-center"> = Ada Reference Manual = with Technical Corrigendum 1 '''Language and Standard Libraries''' </div> <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-TTL|Legal]]</div> __NOEDITSECTION__ {{DISPLAYTITLE: Guide <span class="hide">- Ada Reference Manual</span> }} {{95lrm}} 2bve7ekqcn9w3pcnq0pxpb0n3fdbmgi Guide:95lrm/RM-0-1 4200 855 3578 3577 2019-05-04T23:35:03Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-0-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Foreword to this version of the Ada Reference Manual}} The International Standard for the programming language Ada is ISO/IEC 8652:1995(E). The Ada Working Group ISO/IEC JTC1/SC 22/WG 9 is tasked by ISO with the work item to interpret and maintain the International Standard and to produce Technical Corrigenda, as appropriate. The technical work on the International Standard is performed by the Ada Rapporteur Group (ARG) of WG 9. In September 2000, WG 9 approved and forwarded Technical Corrigendum 1 to SC 22 for ISO approval, which was granted in February 2001. Technical Corrigendum 1 was published in June 2001. The Technical Corrigendum lists the individual changes that need to be made to the text of the International Standard to correct errors, omissions or inconsistencies. The corrections specified in Technical Corrigendum 1 are part of the International Standard ISO/IEC 8652:1995(E). When ISO published Technical Corrigendum 1, it did not also publish a document that merges the Technical Corrigendum changes into the text of the International Standard. However, ISO rules require that the project editor for the Technical Corrigendum be able to produce such a document on demand. This version of the Ada Reference Manual is what the project editor would provide to ISO in response to such a request. It incorporates the changes specified in the Technical Corrigendum into the text of ISO/IEC 8652:1995(E). It should be understood that the publication of any ISO document involves changes in general format, boilerplate, headers, etc., as well as a review by professional editors that may introduce editorial changes to the text. This version of the Ada Reference Manual is therefore neither an official ISO document, nor a version guaranteed to be identical to an official ISO document, should ISO decide to reprint the International Standard incorporating an approved Technical Corrigendum. It is nevertheless a best effort to be as close as possible to the technical content of such an updated document. In the case of a conflict between this document and a Technical Corrigendum 1 approved by ISO (or between this document and the original 8652:1995 in the case of paragraphs not changed by Technical Corrigendum 1), the other documents contain the official text of the International Standard ISO/IEC 8652:1995(E). As it is very inconvenient to have the Reference Manual for Ada specified in two documents, this consolidated version of the Ada Reference Manual is made available to the public. == Using this version of the Ada Reference Manual == This document has been revised with the corrections specified in Technical Corrigendum 1 (ISO/IEC 8652:1995/COR1:2000). In addition, a variety of editorial errors have been corrected. Changes to the original 8652:1995 can be identified by the version number /1 following the paragraph number. Paragraphs not so marked are unchanged by Technical Corrigendum 1 or editorial corrections. Paragraph numbers of unchanged paragraphs are the same as in the original Ada Reference Manual. In addition, some versions of this document include revision bars near the paragraph numbers. Where paragraphs are inserted, the paragraph numbers are of the form pp.nn, where pp is the number of the preceding paragraph, and nn is an insertion number. For instance, the first paragraph inserted after paragraph 8 is numbered 8.1, the second paragraph inserted is numbered 8.2, and so on. Deleted paragraphs are indicated by the text ''This paragraph was deleted.'' Deleted paragraphs include empty paragraphs that were numbered in the original Ada Reference Manual. == Acknowledgements for this version of the Ada Reference Manual == The editor [R. Brukardt (USA)] would like to thank the many people whose hard work and assistance has made this revision possible. Thanks go out to all of the members of the ISO/IEC JTC 1/SC 22/WG 9 Ada Rapporteur Group, whose work on creating and editing the wording corrections was critical to the entire process. Especially valuable contributions came from the chairman of the ARG, E. Ploedereder (Germany), who kept the process moving; J. Barnes (UK) and K. Ishihata (Japan), whose extremely detailed reviews kept the editor on his toes; G. Dismukes (USA), M. Kamrad (USA), P. Leroy (France), S. Michell (Canada), T. Taft (USA), J. Tokar (USA), and other members too numerous to mention. Special thanks go to R. Duff (USA) for his explanations of the previous system of formatting of these documents during the tedious conversion to more modern formats. Special thanks also go to the convener of ISO/IEC JTC 1/SC 22/WG 9, J. Moore (USA), without whose help and support the corrigendum and this consolidated reference manual would not have been possible. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-0-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} riqb7q23s0alc8t6hfhn6kvtojd4r3v Guide:95lrm/RM-0-2 4200 856 3580 3579 2019-05-04T23:35:03Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-0-1|Previous]] | [[Guide:95lrm/RM-0-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Foreword}} ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote. International Standard ISO/IEC 8652 was prepared by Joint Technical Committee ISO/IEC JTC 1, ''Information Technology''. This second edition cancels and replaces the first edition (ISO 8652:1987), of which it constitutes a technical revision. Annexes A to J form an integral part of this International Standard. Annexes K to P are for information only. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-0-1|Previous]] | [[Guide:95lrm/RM-0-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} hosd0cxxb9brmqc2n1vwihttq28ohaa Guide:95lrm/RM-0-28 4200 857 3582 3581 2019-05-04T23:35:03Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-14|Previous]] | [[Guide:95lrm/RM-A|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: The Standard Libraries}} </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-14|Previous]] | [[Guide:95lrm/RM-A|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} h72zrdt0vaoipsud9hky35rjfnuepxd Guide:95lrm/RM-0-29 4200 858 4495 4494 2019-05-05T23:31:53Z WikiVisor 11 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-P|Previous]]</div> {{DISPLAYTITLE: Index}} Index entries are given by paragraph number. A list of all language-defined library units may be found under Language-Defined Library Units. A list of all language-defined types may be found under Language-Defined Types. A list of all language-defined subprograms may be found under Language-Defined Subprograms. :& operator [[Guide:95lrm/RM-4-4#I2377|4.4(1)]], [[Guide:95lrm/RM-4-5-3#I2541|4.5.3(3)]] :<nowiki>*</nowiki> operator [[Guide:95lrm/RM-4-4#I2384|4.4(1)]], [[Guide:95lrm/RM-4-5-5#I2566|4.5.5(1)]] :<nowiki>**</nowiki> operator [[Guide:95lrm/RM-4-4#I2398|4.4(1)]], [[Guide:95lrm/RM-4-5-6#I2597|4.5.6(7)]] :+ operator [[Guide:95lrm/RM-4-4#I2369|4.4(1)]], [[Guide:95lrm/RM-4-5-3#I2533|4.5.3(1)]], [[Guide:95lrm/RM-4-5-4#I2556|4.5.4(1)]] :- operator [[Guide:95lrm/RM-4-4#I2373|4.4(1)]], [[Guide:95lrm/RM-4-5-3#I2537|4.5.3(1)]], [[Guide:95lrm/RM-4-5-4#I2560|4.5.4(1)]] :/ operator [[Guide:95lrm/RM-4-4#I2390|4.4(1)]], [[Guide:95lrm/RM-4-5-5#I2572|4.5.5(1)]] :/= operator [[Guide:95lrm/RM-4-4#I2347|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2499|4.5.2(1)]] :10646-1:1993, ISO/IEC standard [[Guide:95lrm/RM-1-2#I1107|1.2(8/1)]] :1539:1991, ISO/IEC standard [[Guide:95lrm/RM-1-2#I1092|1.2(3)]] :1989:1985, ISO standard [[Guide:95lrm/RM-1-2#I1095|1.2(4)]] :6429:1992, ISO/IEC standard [[Guide:95lrm/RM-1-2#I1098|1.2(5)]] :646:1991, ISO/IEC standard [[Guide:95lrm/RM-1-2#I1089|1.2(2)]] :8859-1:1987, ISO/IEC standard [[Guide:95lrm/RM-1-2#I1101|1.2(6)]] :9899:1990, ISO/IEC standard [[Guide:95lrm/RM-1-2#I1104|1.2(7)]] :< operator [[Guide:95lrm/RM-4-4#I2351|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2503|4.5.2(1)]] :<= operator [[Guide:95lrm/RM-4-4#I2355|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2507|4.5.2(1)]] :<nowiki>=</nowiki> operator [[Guide:95lrm/RM-4-4#I2343|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2495|4.5.2(1)]] :> operator [[Guide:95lrm/RM-4-4#I2359|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2511|4.5.2(1)]] :>= operator [[Guide:95lrm/RM-4-4#I2363|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2515|4.5.2(1)]] == A == :AARM [[Guide:95lrm/RM-0-3#I1002|0.3(5)]] :abnormal completion [[Guide:95lrm/RM-7-6-1#I3158|7.6.1(2)]] :abnormal state of an object [[Guide:95lrm/RM-13-9-1#I4380|13.9.1(4)]] ::[''partial''] [[Guide:95lrm/RM-9-8#I3650|9.8(21)]], [[Guide:95lrm/RM-11-6#I3958|11.6(6)]], [[Guide:95lrm/RM-A-13#I6003|A.13(17)]] :abnormal task [[Guide:95lrm/RM-9-8#I3640|9.8(4)]] :abort ::of a partition [[Guide:95lrm/RM-E-1#I6698|E.1(7)]] ::of a task [[Guide:95lrm/RM-9-8#I3639|9.8(4)]] ::of the execution of a construct [[Guide:95lrm/RM-9-8#I3643|9.8(5)]] :abort completion point [[Guide:95lrm/RM-9-8#I3646|9.8(15)]] :abort-deferred operation [[Guide:95lrm/RM-9-8#I3644|9.8(5)]] :abort_statement [[Guide:95lrm/RM-9-8#I3634|9.8(2)]] ::''used'' [[Guide:95lrm/RM-5-1#I2783|5.1(4)]], [[Guide:95lrm/RM-P#I7607|P]] :Abort_Task ::''in'' Ada.Task_Identification [[Guide:95lrm/RM-C-7-1#I6475|C.7.1(3/1)]] :abortable_part [[Guide:95lrm/RM-9-7-4#I3622|9.7.4(5)]] ::''used'' [[Guide:95lrm/RM-9-7-4#I3615|9.7.4(2)]], [[Guide:95lrm/RM-P#I7817|P]] :abs operator [[Guide:95lrm/RM-4-4#I2402|4.4(1)]], [[Guide:95lrm/RM-4-5-6#I2586|4.5.6(1)]] :absolute value [[Guide:95lrm/RM-4-4#I2404|4.4(1)]], [[Guide:95lrm/RM-4-5-6#I2588|4.5.6(1)]] :abstract data type (ADT) ::''See'' private types and private extensions [[Guide:95lrm/RM-7-3#I3081|7.3(1)]] ::''See also'' abstract type [[Guide:95lrm/RM-3-9-3#I2032|3.9.3(1)]] :abstract subprogram [[Guide:95lrm/RM-3-9-3#I2035|3.9.3(1)]], [[Guide:95lrm/RM-3-9-3#I2039|3.9.3(3)]] :abstract type [[Guide:95lrm/RM-3-9-3#I2031|3.9.3(1)]], [[Guide:95lrm/RM-3-9-3#I2037|3.9.3(2)]] :abstract_subprogram_declaration [[Guide:95lrm/RM-6-1#I2883|6.1(3)]] ::''used'' [[Guide:95lrm/RM-3-1#I1271|3.1(3)]], [[Guide:95lrm/RM-P#I7337|P]] :accept_alternative [[Guide:95lrm/RM-9-7-1#I3589|9.7.1(5)]] ::''used'' [[Guide:95lrm/RM-9-7-1#I3586|9.7.1(4)]], [[Guide:95lrm/RM-P#I7803|P]] :accept_statement [[Guide:95lrm/RM-9-5-2#I3437|9.5.2(3)]] ::''used'' [[Guide:95lrm/RM-5-1#I2791|5.1(5)]], [[Guide:95lrm/RM-9-7-1#I3590|9.7.1(5)]], [[Guide:95lrm/RM-P#I7614|P]] :acceptable interpretation [[Guide:95lrm/RM-8-6#I3286|8.6(14)]] :Access attribute [[Guide:95lrm/RM-3-10-2#I2110|3.10.2(24/1)]], [[Guide:95lrm/RM-3-10-2#I2120|3.10.2(32)]] ::''See also'' Unchecked_Access attribute [[Guide:95lrm/RM-13-10#I4394|13.10(3)]] :access discriminant [[Guide:95lrm/RM-3-7#I1856|3.7(9)]] :access parameter [[Guide:95lrm/RM-6-1#I2929|6.1(24)]] :access paths :::distinct [[Guide:95lrm/RM-6-2#I2945|6.2(12)]] :access type [[Guide:95lrm/RM-3-10#I2041|3.10(1)]] :access types ::input-output unspecified [[Guide:95lrm/RM-A-7#I5490|A.7(6)]] :access value [[Guide:95lrm/RM-3-10#I2042|3.10(1)]] :access-to-constant type [[Guide:95lrm/RM-3-10#I2072|3.10(10)]] :access-to-object type [[Guide:95lrm/RM-3-10#I2058|3.10(7/1)]] :access-to-subprogram type [[Guide:95lrm/RM-3-10#I2059|3.10(7/1)]], [[Guide:95lrm/RM-3-10#I2074|3.10(11)]] :access-to-variable type [[Guide:95lrm/RM-3-10#I2073|3.10(10)]] :Access_Check [[Guide:95lrm/RM-11-5#I3928|11.5(11/1)]] ::[''partial''] [[Guide:95lrm/RM-4-1#I2184|4.1(13)]], [[Guide:95lrm/RM-4-6#I2679|4.6(49)]] :access_definition [[Guide:95lrm/RM-3-10#I2056|3.10(6)]] ::''used'' [[Guide:95lrm/RM-3-7#I1850|3.7(5)]], [[Guide:95lrm/RM-6-1#I2918|6.1(15)]], [[Guide:95lrm/RM-P#I7439|P]] :access_to_object_definition [[Guide:95lrm/RM-3-10#I2049|3.10(3)]] ::''used'' [[Guide:95lrm/RM-3-10#I2047|3.10(2)]], [[Guide:95lrm/RM-P#I7468|P]] :access_to_subprogram_definition [[Guide:95lrm/RM-3-10#I2053|3.10(5)]] ::''used'' [[Guide:95lrm/RM-3-10#I2048|3.10(2)]], [[Guide:95lrm/RM-P#I7469|P]] :access_type_definition [[Guide:95lrm/RM-3-10#I2046|3.10(2)]] ::''used'' [[Guide:95lrm/RM-3-2-1#I1340|3.2.1(4)]], [[Guide:95lrm/RM-12-5-4#I4088|12.5.4(2)]], [[Guide:95lrm/RM-P#I7358|P]] :accessibility ::from shared passive library units [[Guide:95lrm/RM-E-2-1#I6720|E.2.1(8)]] :accessibility level [[Guide:95lrm/RM-3-10-2#I2097|3.10.2(3)]] :accessibility rule ::Access attribute [[Guide:95lrm/RM-3-10-2#I2113|3.10.2(28)]], [[Guide:95lrm/RM-3-10-2#I2121|3.10.2(32)]] ::record extension [[Guide:95lrm/RM-3-9-1#I1998|3.9.1(3)]] ::requeue statement [[Guide:95lrm/RM-9-5-4#I3517|9.5.4(6)]] ::type conversion [[Guide:95lrm/RM-4-6#I2635|4.6(17)]], [[Guide:95lrm/RM-4-6#I2640|4.6(20)]] :Accessibility_Check [[Guide:95lrm/RM-11-5#I3938|11.5(21)]] ::[''partial''] [[Guide:95lrm/RM-3-10-2#I2115|3.10.2(29)]], [[Guide:95lrm/RM-4-6#I2677|4.6(48)]], [[Guide:95lrm/RM-6-5#I3045|6.5(17)]], [[Guide:95lrm/RM-E-4#I6776|E.4(18/1)]] :accessible partition [[Guide:95lrm/RM-E-1#I6700|E.1(7)]] :accuracy [[Guide:95lrm/RM-4-6#I2655|4.6(32)]], [[Guide:95lrm/RM-G-2#I6995|G.2(1)]] :ACK ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4656|A.3.3(5)]] :acquire ::execution resource associated with protected object [[Guide:95lrm/RM-9-5-1#I3426|9.5.1(5)]] :activation ::of a task [[Guide:95lrm/RM-9-2#I3354|9.2(1)]] :activation failure [[Guide:95lrm/RM-9-2#I3356|9.2(1)]] :activator ::of a task [[Guide:95lrm/RM-9-2#I3357|9.2(5)]] :active partition [[Guide:95lrm/RM-10-2#I3796|10.2(28)]], [[Guide:95lrm/RM-E-1#I6693|E.1(2)]] :active priority [[Guide:95lrm/RM-D-1#I6523|D.1(15)]] :actual [[Guide:95lrm/RM-12-3#I4018|12.3(7)]] :actual duration [[Guide:95lrm/RM-D-9#I6656|D.9(12)]] :actual parameter ::for a formal parameter [[Guide:95lrm/RM-6-4-1#I3018|6.4.1(3)]] :actual subtype [[Guide:95lrm/RM-3-3#I1394|3.3(23)]], [[Guide:95lrm/RM-12-5#I4061|12.5(4)]] :::of an object [[Guide:95lrm/RM-3-3-1#I1425|3.3.1(9)]] :actual type [[Guide:95lrm/RM-12-5#I4063|12.5(4)]] :actual_parameter_part [[Guide:95lrm/RM-6-4#I3002|6.4(4)]] ::''used'' [[Guide:95lrm/RM-6-4#I2997|6.4(2)]], [[Guide:95lrm/RM-6-4#I3001|6.4(3)]], [[Guide:95lrm/RM-9-5-3#I3486|9.5.3(2)]], [[Guide:95lrm/RM-P#I7679|P]] :Acute ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4802|A.3.3(22)]] :Ada [[Guide:95lrm/RM-A-2#I4574|A.2(2)]] :Ada calling convention [[Guide:95lrm/RM-6-3-1#I2964|6.3.1(3)]] :Ada.Asynchronous_Task_Control [[Guide:95lrm/RM-D-11#I6675|D.11(3)]] :Ada.Calendar [[Guide:95lrm/RM-9-6#I3539|9.6(10)]] :Ada.Characters [[Guide:95lrm/RM-A-3-1#I4577|A.3.1(2)]] :Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4580|A.3.2(2)]] :Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4648|A.3.3(3)]] :Ada.Command_Line [[Guide:95lrm/RM-A-15#I6007|A.15(3)]] :Ada.Decimal [[Guide:95lrm/RM-F-2#I6820|F.2(2)]] :Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5545|A.8.4(2)]] :Ada.Dynamic_Priorities [[Guide:95lrm/RM-D-5#I6581|D.5(3)]] :Ada.Exceptions [[Guide:95lrm/RM-11-4-1#I3884|11.4.1(2)]] :Ada.Finalization [[Guide:95lrm/RM-7-6#I3129|7.6(4/1)]] :Ada.Float_Text_IO [[Guide:95lrm/RM-A-10-9#I5901|A.10.9(33)]] :Ada.Float_Wide_Text_IO [[Guide:95lrm/RM-A-11#I5910|A.11(3)]] :Ada.Integer_Text_IO [[Guide:95lrm/RM-A-10-8#I5898|A.10.8(21)]] :Ada.Integer_Wide_Text_IO [[Guide:95lrm/RM-A-11#I5907|A.11(3)]] :Ada.Interrupts [[Guide:95lrm/RM-C-3-2#I6405|C.3.2(2)]] :Ada.Interrupts.Names [[Guide:95lrm/RM-C-3-2#I6426|C.3.2(12)]] :Ada.IO_Exceptions [[Guide:95lrm/RM-A-13#I5992|A.13(3)]] :Ada.Numerics [[Guide:95lrm/RM-A-5#I5262|A.5(3)]] :Ada.Numerics.Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6965|G.1.2(9/1)]] :Ada.Numerics.Complex_Types [[Guide:95lrm/RM-G-1-1#I6913|G.1.1(25/1)]] :Ada.Numerics.Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6962|G.1.2(9/1)]] :Ada.Numerics.Complex_Types [[Guide:95lrm/RM-G-1-1#I6910|G.1.1(25/1)]] :Ada.Numerics.Discrete_Random [[Guide:95lrm/RM-A-5-2#I5361|A.5.2(17)]] :Ada.Numerics.Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5328|A.5.1(9/1)]] :Ada.Numerics.Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5325|A.5.1(9/1)]] :Ada.Numerics.Float_Random [[Guide:95lrm/RM-A-5-2#I5338|A.5.2(5)]] :Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6921|G.1.2(2)]] :Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6871|G.1.1(2/1)]] :Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5268|A.5.1(3)]] :Ada.Real_Time [[Guide:95lrm/RM-D-8#I6616|D.8(3)]] :Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5505|A.8.1(2)]] :Ada.Storage_IO [[Guide:95lrm/RM-A-9#I5598|A.9(3)]] :Ada.Streams [[Guide:95lrm/RM-13-13-1#I4474|13.13.1(2)]] :Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5916|A.12.1(3)]] :Ada.Strings [[Guide:95lrm/RM-A-4-1#I4881|A.4.1(3)]] :Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5006|A.4.4(3)]] :Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4943|A.4.3(5)]] :Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4900|A.4.2(3)]] :Ada.Strings.Maps.Constants [[Guide:95lrm/RM-A-4-6#I5191|A.4.6(3)]] :Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5105|A.4.5(3)]] :Ada.Strings.Wide_Bounded [[Guide:95lrm/RM-A-4-7#I5211|A.4.7(1)]] :Ada.Strings.Wide_Fixed [[Guide:95lrm/RM-A-4-7#I5208|A.4.7(1)]] :Ada.Strings.Wide_Maps.Wide_Constants [[Guide:95lrm/RM-A-4-7#I5257|A.4.7(28)]] :Ada.Strings.Wide_Unbounded [[Guide:95lrm/RM-A-4-7#I5214|A.4.7(1)]] :Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5217|A.4.7(3)]] :Ada.Synchronous_Task_Control [[Guide:95lrm/RM-D-10#I6659|D.10(3)]] :Ada.Tags [[Guide:95lrm/RM-3-9#I1966|3.9(6)]] :Ada.Task_Attributes [[Guide:95lrm/RM-C-7-2#I6492|C.7.2(2)]] :Ada.Task_Identification [[Guide:95lrm/RM-C-7-1#I6465|C.7.1(2)]] :Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5621|A.10.1(2)]] :Ada.Text_IO.Complex_IO [[Guide:95lrm/RM-G-1-3#I6975|G.1.3(3)]] :Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6834|F.3.3(3)]] :Ada.Text_IO.Text_Streams [[Guide:95lrm/RM-A-12-2#I5978|A.12.2(3)]] :Ada.Unchecked_Conversion [[Guide:95lrm/RM-13-9#I4372|13.9(3)]] :Ada.Unchecked_Deallocation [[Guide:95lrm/RM-13-11-2#I4441|13.11.2(3)]] :Ada.Wide_Text_IO [[Guide:95lrm/RM-A-11#I5904|A.11(2)]] :Ada.Wide_Text_IO.Complex_IO [[Guide:95lrm/RM-G-1-4#I6991|G.1.4(1)]] :Ada.Wide_Text_IO.Editing [[Guide:95lrm/RM-F-3-4#I6864|F.3.4(1)]] :Ada.Wide_Text_IO.Text_Streams [[Guide:95lrm/RM-A-12-3#I5985|A.12.3(3)]] :Ada_To_COBOL ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6257|B.4(14)]] :adafinal [[Guide:95lrm/RM-B-1#I6085|B.1(39)]] :adainit [[Guide:95lrm/RM-B-1#I6084|B.1(39)]] :address ::arithmetic [[Guide:95lrm/RM-13-7-1#I4339|13.7.1(6)]] ::comparison [[Guide:95lrm/RM-13-7#I4320|13.7(14)]] ::''in'' System [[Guide:95lrm/RM-13-7#I4315|13.7(12)]] :Address attribute [[Guide:95lrm/RM-13-3#I4196|13.3(11)]], [[Guide:95lrm/RM-J-7-1#I7092|J.7.1(5)]] :Address clause [[Guide:95lrm/RM-13-3#I4178|13.3(7)]], [[Guide:95lrm/RM-13-3#I4198|13.3(12)]] :Address_To_Access_Conversions ::''child of'' System [[Guide:95lrm/RM-13-7-2#I4349|13.7.2(2)]] :Adjacent attribute [[Guide:95lrm/RM-A-5-3#I5443|A.5.3(48)]] :Adjust [[Guide:95lrm/RM-7-6#I3126|7.6(2)]] ::''in'' Ada.Finalization [[Guide:95lrm/RM-7-6#I3135|7.6(6)]] :adjusting the value of an object [[Guide:95lrm/RM-7-6#I3147|7.6(15)]], [[Guide:95lrm/RM-7-6#I3149|7.6(16)]] :adjustment [[Guide:95lrm/RM-7-6#I3148|7.6(15)]], [[Guide:95lrm/RM-7-6#I3150|7.6(16)]] ::as part of assignment [[Guide:95lrm/RM-5-2#I2818|5.2(14)]] :ADT (abstract data type) ::''See'' private types and private extensions [[Guide:95lrm/RM-7-3#I3082|7.3(1)]] ::''See also'' abstract type [[Guide:95lrm/RM-3-9-3#I2033|3.9.3(1)]] :advice [[Guide:95lrm/RM-1-1-2#I1048|1.1.2(37)]] :Aft attribute [[Guide:95lrm/RM-3-5-10#I1751|3.5.10(5)]] :aggregate [[Guide:95lrm/RM-4-3#I2254|4.3(1)]], [[Guide:95lrm/RM-4-3#I2256|4.3(2)]] ::''used'' [[Guide:95lrm/RM-4-4#I2443|4.4(7)]], [[Guide:95lrm/RM-4-7#I2706|4.7(2)]], [[Guide:95lrm/RM-P#I7589|P]] ::''See also'' composite type [[Guide:95lrm/RM-3-2#I1304|3.2(2)]] :aliased [[Guide:95lrm/RM-3-10#I2066|3.10(9)]] :aliasing ::''See'' distinct access paths [[Guide:95lrm/RM-6-2#I2946|6.2(12)]] :Alignment ::''in'' Ada.Strings [[Guide:95lrm/RM-A-4-1#I4889|A.4.1(6)]] :Alignment attribute [[Guide:95lrm/RM-13-3#I4202|13.3(23)]] :Alignment clause [[Guide:95lrm/RM-13-3#I4179|13.3(7)]], [[Guide:95lrm/RM-13-3#I4204|13.3(25)]] :All_Calls_Remote pragma [[Guide:95lrm/RM-E-2-3#I6741|E.2.3(5)]], [[Guide:95lrm/RM-L#I7145|L(2)]] :All_Checks [[Guide:95lrm/RM-11-5#I3941|11.5(25)]] :Allocate ::''in'' System.Storage_Pools [[Guide:95lrm/RM-13-11#I4405|13.11(7)]] :allocator [[Guide:95lrm/RM-4-8#I2720|4.8(2)]] ::''used'' [[Guide:95lrm/RM-4-4#I2446|4.4(7)]], [[Guide:95lrm/RM-P#I7580|P]] :Alphanumeric ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6260|B.4(16)]] :alphanumeric character ::a category of Character [[Guide:95lrm/RM-A-3-2#I4644|A.3.2(31)]] :Alphanumeric_Set ::''in'' Ada.Strings.Maps.Constants [[Guide:95lrm/RM-A-4-6#I5200|A.4.6(4)]] :ambiguous [[Guide:95lrm/RM-8-6#I3303|8.6(30)]] :ampersand [[Guide:95lrm/RM-2-1#I1139|2.1(15)]] ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4688|A.3.3(8)]] :ampersand operator [[Guide:95lrm/RM-4-4#I2379|4.4(1)]], [[Guide:95lrm/RM-4-5-3#I2543|4.5.3(3)]] :ancestor ::of a library unit [[Guide:95lrm/RM-10-1-1#I3708|10.1.1(11)]] ::of a type [[Guide:95lrm/RM-3-4-1#I1484|3.4.1(10)]] ::ultimate [[Guide:95lrm/RM-3-4-1#I1486|3.4.1(10)]] :ancestor subtype ::of a formal derived type [[Guide:95lrm/RM-12-5-1#I4073|12.5.1(5)]] ::of a private_extension_declaration [[Guide:95lrm/RM-7-3#I3093|7.3(8)]] :ancestor_part [[Guide:95lrm/RM-4-3-2#I2289|4.3.2(3)]] ::''used'' [[Guide:95lrm/RM-4-3-2#I2287|4.3.2(2)]], [[Guide:95lrm/RM-P#I7531|P]] :and operator [[Guide:95lrm/RM-4-4#I2335|4.4(1)]], [[Guide:95lrm/RM-4-5-1#I2475|4.5.1(2)]] :and then (short-circuit control form) [[Guide:95lrm/RM-4-4#I2341|4.4(1)]], [[Guide:95lrm/RM-4-5-1#I2470|4.5.1(1)]] :angle threshold [[Guide:95lrm/RM-G-2-4#I7029|G.2.4(10)]] :Annex ::informative [[Guide:95lrm/RM-1-1-2#I1013|1.1.2(18)]] ::normative [[Guide:95lrm/RM-1-1-2#I1010|1.1.2(14)]] ::Specialized Needs [[Guide:95lrm/RM-1-1-2#I1007|1.1.2(7)]] :Annotated Ada Reference Manual [[Guide:95lrm/RM-0-3#I1001|0.3(5)]] :anonymous access type [[Guide:95lrm/RM-3-10#I2077|3.10(12)]] :anonymous array type [[Guide:95lrm/RM-3-3-1#I1402|3.3.1(1)]] :anonymous protected type [[Guide:95lrm/RM-3-3-1#I1404|3.3.1(1)]] :anonymous task type [[Guide:95lrm/RM-3-3-1#I1403|3.3.1(1)]] :anonymous type [[Guide:95lrm/RM-3-2-1#I1344|3.2.1(7)]] :Any_Priority ::''in'' System [[Guide:95lrm/RM-13-7#I4324|13.7(16)]] :APC ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4779|A.3.3(19)]] :apostrophe [[Guide:95lrm/RM-2-1#I1140|2.1(15)]] ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4689|A.3.3(8)]] :Append ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5020|A.4.4(13)]], [[Guide:95lrm/RM-A-4-4#I5022|A.4.4(14)]], [[Guide:95lrm/RM-A-4-4#I5024|A.4.4(15)]], [[Guide:95lrm/RM-A-4-4#I5026|A.4.4(16)]], [[Guide:95lrm/RM-A-4-4#I5028|A.4.4(17)]], [[Guide:95lrm/RM-A-4-4#I5030|A.4.4(18)]], [[Guide:95lrm/RM-A-4-4#I5032|A.4.4(19)]], [[Guide:95lrm/RM-A-4-4#I5034|A.4.4(20)]] ::''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5122|A.4.5(12)]], [[Guide:95lrm/RM-A-4-5#I5124|A.4.5(13)]], [[Guide:95lrm/RM-A-4-5#I5126|A.4.5(14)]] :applicable index constraint [[Guide:95lrm/RM-4-3-3#I2322|4.3.3(10)]] :application areas [[Guide:95lrm/RM-1-1-2#I1008|1.1.2(7)]] :apply ::to a callable construct by a return_statement [[Guide:95lrm/RM-6-5#I3038|6.5(4)]] ::to a loop_statement by an exit_statement [[Guide:95lrm/RM-5-7#I2869|5.7(4)]] ::to a program unit by a program unit pragma [[Guide:95lrm/RM-10-1-5#I3757|10.1.5(2)]] :arbitrary order [[Guide:95lrm/RM-1-1-4#I1069|1.1.4(18)]] :Arccos ::''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6941|G.1.2(5)]] ::''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5300|A.5.1(6)]] :Arccosh ::''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6957|G.1.2(7)]] ::''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5320|A.5.1(7)]] :Arccot ::''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6945|G.1.2(5)]] ::''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5308|A.5.1(6)]] :Arccoth ::''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6961|G.1.2(7)]] ::''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5324|A.5.1(7)]] :Arcsin ::''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6939|G.1.2(5)]] ::''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5296|A.5.1(6)]] :Arcsinh ::''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6955|G.1.2(7)]] ::''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5318|A.5.1(7)]] :Arctan ::''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6943|G.1.2(5)]] ::''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5302|A.5.1(6)]] :Arctanh ::''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6959|G.1.2(7)]] ::''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5322|A.5.1(7)]] :Argument ::''in'' Ada.Command_Line [[Guide:95lrm/RM-A-15#I6011|A.15(5)]] ::''in'' Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6901|G.1.1(10)]] :argument of a pragma [[Guide:95lrm/RM-2-8#I1249|2.8(9)]] :Argument_Count ::''in'' Ada.Command_Line [[Guide:95lrm/RM-A-15#I6009|A.15(4)]] :Argument_Error ::''in'' Ada.Numerics [[Guide:95lrm/RM-A-5#I5263|A.5(3)]] :array [[Guide:95lrm/RM-3-6#I1761|3.6(1)]] :array component expression [[Guide:95lrm/RM-4-3-3#I2317|4.3.3(6)]] :array indexing ::''See'' indexed_component [[Guide:95lrm/RM-4-1-1#I2187|4.1.1(1)]] :array slice [[Guide:95lrm/RM-4-1-2#I2199|4.1.2(1)]] :array type [[Guide:95lrm/RM-3-6#I1762|3.6(1)]] :array_aggregate [[Guide:95lrm/RM-4-3-3#I2299|4.3.3(2)]] ::''used'' [[Guide:95lrm/RM-4-3#I2259|4.3(2)]], [[Guide:95lrm/RM-13-4#I4243|13.4(3)]], [[Guide:95lrm/RM-P#I7944|P]] :array_component_association [[Guide:95lrm/RM-4-3-3#I2312|4.3.3(5)]] ::''used'' [[Guide:95lrm/RM-4-3-3#I2310|4.3.3(4)]], [[Guide:95lrm/RM-P#I7543|P]] :array_type_definition [[Guide:95lrm/RM-3-6#I1763|3.6(2)]] ::''used'' [[Guide:95lrm/RM-3-2-1#I1338|3.2.1(4)]], [[Guide:95lrm/RM-3-3-1#I1410|3.3.1(2)]], [[Guide:95lrm/RM-12-5-3#I4084|12.5.3(2)]], [[Guide:95lrm/RM-P#I7918|P]] :ASCII ::package physically nested within the declaration of Standard [[Guide:95lrm/RM-A-1#I4561|A.1(36)]] :aspect of representation [[Guide:95lrm/RM-13-1#I4134|13.1(8)]] ::coding [[Guide:95lrm/RM-13-4#I4245|13.4(7)]] ::controlled [[Guide:95lrm/RM-13-11-3#I4456|13.11.3(5)]] ::convention, calling convention [[Guide:95lrm/RM-B-1#I6068|B.1(28)]] ::exported [[Guide:95lrm/RM-B-1#I6072|B.1(28)]] ::imported [[Guide:95lrm/RM-B-1#I6070|B.1(28)]] ::layout [[Guide:95lrm/RM-13-5#I4249|13.5(1)]] ::packing [[Guide:95lrm/RM-13-2#I4157|13.2(5)]] ::record layout [[Guide:95lrm/RM-13-5#I4251|13.5(1)]] ::specifiable attributes [[Guide:95lrm/RM-13-3#I4175|13.3(5/1)]] ::storage place [[Guide:95lrm/RM-13-5#I4253|13.5(1)]] :aspect_clause [[Guide:95lrm/RM-13-1#I4119|13.1(2/1)]] ::''used'' [[Guide:95lrm/RM-3-8#I1905|3.8(5/1)]], [[Guide:95lrm/RM-3-11#I2135|3.11(4/1)]], [[Guide:95lrm/RM-9-1#I3337|9.1(5/1)]], [[Guide:95lrm/RM-9-4#I3388|9.4(5/1)]], [[Guide:95lrm/RM-9-4#I3400|9.4(8/1)]], [[Guide:95lrm/RM-P#I7765|P]] :assembly language [[Guide:95lrm/RM-C-1#I6370|C.1(4)]] :assign ::''See'' assignment operation [[Guide:95lrm/RM-5-2#I2805|5.2(3)]] :assigning back of parameters [[Guide:95lrm/RM-6-4-1#I3030|6.4.1(17)]] :assignment ::user-defined [[Guide:95lrm/RM-7-6#I3119|7.6(1)]] :assignment operation [[Guide:95lrm/RM-5-2#I2804|5.2(3)]], [[Guide:95lrm/RM-5-2#I2816|5.2(12)]], [[Guide:95lrm/RM-7-6#I3146|7.6(13)]] ::during elaboration of an object_declaration [[Guide:95lrm/RM-3-3-1#I1434|3.3.1(19)]] ::during evaluation of a generic_association for a formal object of mode in [[Guide:95lrm/RM-12-4#I4043|12.4(11)]] ::during evaluation of a parameter_association [[Guide:95lrm/RM-6-4-1#I3023|6.4.1(11)]] ::during evaluation of an aggregate [[Guide:95lrm/RM-4-3#I2262|4.3(5)]] ::during evaluation of an initialized allocator [[Guide:95lrm/RM-4-8#I2730|4.8(7)]] ::during evaluation of an uninitialized allocator [[Guide:95lrm/RM-4-8#I2733|4.8(9)]], [[Guide:95lrm/RM-4-8#I2734|4.8(10/1)]] ::during evaluation of concatenation [[Guide:95lrm/RM-4-5-3#I2553|4.5.3(10)]] ::during execution of a for loop [[Guide:95lrm/RM-5-5#I2859|5.5(9)]] ::during execution of a return_statement [[Guide:95lrm/RM-6-5#I3048|6.5(21)]] ::during execution of an assignment_statement [[Guide:95lrm/RM-5-2#I2817|5.2(12)]] ::during parameter copy back [[Guide:95lrm/RM-6-4-1#I3031|6.4.1(17)]] :assignment_statement [[Guide:95lrm/RM-5-2#I2801|5.2(2)]] ::''used'' [[Guide:95lrm/RM-5-1#I2775|5.1(4)]], [[Guide:95lrm/RM-P#I7599|P]] :associated components ::of a record_component_association [[Guide:95lrm/RM-4-3-1#I2282|4.3.1(10)]] :associated discriminants ::of a named discriminant_association [[Guide:95lrm/RM-3-7-1#I1880|3.7.1(5)]] ::of a positional discriminant_association [[Guide:95lrm/RM-3-7-1#I1881|3.7.1(5)]] :associated object ::of a value of a by-reference type [[Guide:95lrm/RM-6-2#I2942|6.2(10)]] :asterisk [[Guide:95lrm/RM-2-1#I1144|2.1(15)]] ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4692|A.3.3(8)]] :asynchronous ::remote procedure call [[Guide:95lrm/RM-E-4-1#I6788|E.4.1(9)]] :Asynchronous pragma [[Guide:95lrm/RM-E-4-1#I6783|E.4.1(3)]], [[Guide:95lrm/RM-L#I7148|L(3)]] :asynchronous remote procedure call [[Guide:95lrm/RM-E-4#I6763|E.4(1)]] :asynchronous_select [[Guide:95lrm/RM-9-7-4#I3613|9.7.4(2)]] ::''used'' [[Guide:95lrm/RM-9-7#I3575|9.7(2)]], [[Guide:95lrm/RM-P#I7796|P]] :Asynchronous_Task_Control ::''child of'' Ada [[Guide:95lrm/RM-D-11#I6673|D.11(3)]] :at-most-once execution [[Guide:95lrm/RM-E-4#I6772|E.4(11)]] :at_clause [[Guide:95lrm/RM-J-7#I7087|J.7(1)]] ::''used'' [[Guide:95lrm/RM-13-1#I4123|13.1(2/1)]], [[Guide:95lrm/RM-P#I7931|P]] :atomic [[Guide:95lrm/RM-C-6#I6449|C.6(7)]] :Atomic pragma [[Guide:95lrm/RM-C-6#I6438|C.6(3)]], [[Guide:95lrm/RM-L#I7151|L(4)]] :Atomic_Components pragma [[Guide:95lrm/RM-C-6#I6444|C.6(5)]], [[Guide:95lrm/RM-L#I7154|L(5)]] :Attach_Handler ::''in'' Ada.Interrupts [[Guide:95lrm/RM-C-3-2#I6417|C.3.2(7)]] :Attach_Handler pragma [[Guide:95lrm/RM-C-3-1#I6387|C.3.1(4)]], [[Guide:95lrm/RM-L#I7157|L(6)]] :attaching ::to an interrupt [[Guide:95lrm/RM-C-3#I6379|C.3(2)]] :attribute [[Guide:95lrm/RM-4-1-4#I2223|4.1.4(1)]], [[Guide:95lrm/RM-K#I7103|K(1)]] ::representation [[Guide:95lrm/RM-13-3#I4162|13.3(1/1)]] ::specifiable [[Guide:95lrm/RM-13-3#I4174|13.3(5/1)]] ::specifying [[Guide:95lrm/RM-13-3#I4163|13.3(1/1)]] :attribute_definition_clause [[Guide:95lrm/RM-13-3#I4164|13.3(2)]] ::''used'' [[Guide:95lrm/RM-13-1#I4120|13.1(2/1)]], [[Guide:95lrm/RM-P#I7928|P]] :attribute_designator [[Guide:95lrm/RM-4-1-4#I2227|4.1.4(3)]] ::''used'' [[Guide:95lrm/RM-4-1-4#I2226|4.1.4(2)]], [[Guide:95lrm/RM-13-1#I4127|13.1(3)]], [[Guide:95lrm/RM-13-3#I4169|13.3(2)]], [[Guide:95lrm/RM-P#I7937|P]] :Attribute_Handle ::''in'' Ada.Task_Attributes [[Guide:95lrm/RM-C-7-2#I6494|C.7.2(3)]] :attribute_reference [[Guide:95lrm/RM-4-1-4#I2224|4.1.4(2)]] ::''used'' [[Guide:95lrm/RM-4-1#I2162|4.1(2)]], [[Guide:95lrm/RM-P#I7494|P]] :attributes ::Access [[Guide:95lrm/RM-3-10-2#I2109|3.10.2(24/1)]], [[Guide:95lrm/RM-3-10-2#I2119|3.10.2(32)]] ::Address [[Guide:95lrm/RM-13-3#I4195|13.3(11)]], [[Guide:95lrm/RM-J-7-1#I7091|J.7.1(5)]] ::Adjacent [[Guide:95lrm/RM-A-5-3#I5442|A.5.3(48)]] ::Aft [[Guide:95lrm/RM-3-5-10#I1750|3.5.10(5)]] ::Alignment [[Guide:95lrm/RM-13-3#I4201|13.3(23)]] ::Base [[Guide:95lrm/RM-3-5#I1523|3.5(15)]] ::Bit_Order [[Guide:95lrm/RM-13-5-3#I4292|13.5.3(4)]] ::Body_Version [[Guide:95lrm/RM-E-3#I6755|E.3(4)]] ::Callable [[Guide:95lrm/RM-9-9#I3653|9.9(2)]] ::Caller [[Guide:95lrm/RM-C-7-1#I6482|C.7.1(14)]] ::Ceiling [[Guide:95lrm/RM-A-5-3#I5429|A.5.3(33)]] ::Class [[Guide:95lrm/RM-3-9#I1976|3.9(14)]], [[Guide:95lrm/RM-7-3-1#I3105|7.3.1(9)]] ::Component_Size [[Guide:95lrm/RM-13-3#I4230|13.3(69)]] ::Compose [[Guide:95lrm/RM-A-5-3#I5417|A.5.3(24)]] ::Constrained [[Guide:95lrm/RM-3-7-2#I1888|3.7.2(3)]], [[Guide:95lrm/RM-J-4#I7085|J.4(2)]] ::Copy_Sign [[Guide:95lrm/RM-A-5-3#I5447|A.5.3(51)]] ::Count [[Guide:95lrm/RM-9-9#I3659|9.9(5)]] ::Definite [[Guide:95lrm/RM-12-5-1#I4075|12.5.1(23)]] ::Delta [[Guide:95lrm/RM-3-5-10#I1746|3.5.10(3)]] ::Denorm [[Guide:95lrm/RM-A-5-3#I5399|A.5.3(9)]] ::Digits [[Guide:95lrm/RM-3-5-8#I1701|3.5.8(2/1)]], [[Guide:95lrm/RM-3-5-10#I1752|3.5.10(7)]] ::Exponent [[Guide:95lrm/RM-A-5-3#I5413|A.5.3(18)]] ::External_Tag [[Guide:95lrm/RM-13-3#I4235|13.3(75/1)]] ::First [[Guide:95lrm/RM-3-5#I1517|3.5(12)]], [[Guide:95lrm/RM-3-6-2#I1817|3.6.2(3)]] ::First(N) [[Guide:95lrm/RM-3-6-2#I1819|3.6.2(4)]] ::First_Bit [[Guide:95lrm/RM-13-5-2#I4279|13.5.2(3)]] ::Floor [[Guide:95lrm/RM-A-5-3#I5427|A.5.3(30)]] ::Fore [[Guide:95lrm/RM-3-5-10#I1748|3.5.10(4)]] ::Fraction [[Guide:95lrm/RM-A-5-3#I5415|A.5.3(21)]] ::Identity [[Guide:95lrm/RM-11-4-1#I3911|11.4.1(9)]], [[Guide:95lrm/RM-C-7-1#I6480|C.7.1(12)]] ::Image [[Guide:95lrm/RM-3-5#I1548|3.5(35)]] ::Input [[Guide:95lrm/RM-13-13-2#I4499|13.13.2(22)]], [[Guide:95lrm/RM-13-13-2#I4503|13.13.2(32)]] ::Last [[Guide:95lrm/RM-3-5#I1519|3.5(13)]], [[Guide:95lrm/RM-3-6-2#I1821|3.6.2(5)]] ::Last(N) [[Guide:95lrm/RM-3-6-2#I1823|3.6.2(6)]] ::Last_Bit [[Guide:95lrm/RM-13-5-2#I4281|13.5.2(4)]] ::Leading_Part [[Guide:95lrm/RM-A-5-3#I5452|A.5.3(54)]] ::Length [[Guide:95lrm/RM-3-6-2#I1829|3.6.2(9)]] ::Length(N) [[Guide:95lrm/RM-3-6-2#I1831|3.6.2(10)]] ::Machine [[Guide:95lrm/RM-A-5-3#I5457|A.5.3(60)]] ::Machine_Emax [[Guide:95lrm/RM-A-5-3#I5397|A.5.3(8)]] ::Machine_Emin [[Guide:95lrm/RM-A-5-3#I5395|A.5.3(7)]] ::Machine_Mantissa [[Guide:95lrm/RM-A-5-3#I5393|A.5.3(6)]] ::Machine_Overflows [[Guide:95lrm/RM-A-5-3#I5407|A.5.3(12)]], [[Guide:95lrm/RM-A-5-4#I5482|A.5.4(4)]] ::Machine_Radix [[Guide:95lrm/RM-A-5-3#I5390|A.5.3(2)]], [[Guide:95lrm/RM-A-5-4#I5478|A.5.4(2)]] ::Machine_Rounds [[Guide:95lrm/RM-A-5-3#I5405|A.5.3(11)]], [[Guide:95lrm/RM-A-5-4#I5480|A.5.4(3)]] ::Max [[Guide:95lrm/RM-3-5#I1528|3.5(19)]] ::Max_Size_In_Storage_Elements [[Guide:95lrm/RM-13-11-1#I4432|13.11.1(3)]] ::Min [[Guide:95lrm/RM-3-5#I1526|3.5(16)]] ::Model [[Guide:95lrm/RM-A-5-3#I5471|A.5.3(68)]], [[Guide:95lrm/RM-G-2-2#I7015|G.2.2(7)]] ::Model_Emin [[Guide:95lrm/RM-A-5-3#I5465|A.5.3(65)]], [[Guide:95lrm/RM-G-2-2#I7008|G.2.2(4)]] ::Model_Epsilon [[Guide:95lrm/RM-A-5-3#I5467|A.5.3(66)]] ::Model_Mantissa [[Guide:95lrm/RM-A-5-3#I5463|A.5.3(64)]], [[Guide:95lrm/RM-G-2-2#I7006|G.2.2(3)]] ::Model_Small [[Guide:95lrm/RM-A-5-3#I5469|A.5.3(67)]] ::Modulus [[Guide:95lrm/RM-3-5-4#I1634|3.5.4(17)]] ::Output [[Guide:95lrm/RM-13-13-2#I4497|13.13.2(19)]], [[Guide:95lrm/RM-13-13-2#I4501|13.13.2(29)]] ::Partition_ID [[Guide:95lrm/RM-E-1#I6701|E.1(9)]] ::Pos [[Guide:95lrm/RM-3-5-5#I1653|3.5.5(2)]] ::Position [[Guide:95lrm/RM-13-5-2#I4277|13.5.2(2)]] ::Pred [[Guide:95lrm/RM-3-5#I1537|3.5(25)]] ::Range [[Guide:95lrm/RM-3-5#I1521|3.5(14)]], [[Guide:95lrm/RM-3-6-2#I1825|3.6.2(7)]] ::Range(N) [[Guide:95lrm/RM-3-6-2#I1827|3.6.2(8)]] ::Read [[Guide:95lrm/RM-13-13-2#I4491|13.13.2(6)]], [[Guide:95lrm/RM-13-13-2#I4495|13.13.2(14)]] ::Remainder [[Guide:95lrm/RM-A-5-3#I5437|A.5.3(45)]] ::Round [[Guide:95lrm/RM-3-5-10#I1758|3.5.10(12)]] ::Rounding [[Guide:95lrm/RM-A-5-3#I5431|A.5.3(36)]] ::Safe_First [[Guide:95lrm/RM-A-5-3#I5473|A.5.3(71)]], [[Guide:95lrm/RM-G-2-2#I7010|G.2.2(5)]] ::Safe_Last [[Guide:95lrm/RM-A-5-3#I5475|A.5.3(72)]], [[Guide:95lrm/RM-G-2-2#I7012|G.2.2(6)]] ::Scale [[Guide:95lrm/RM-3-5-10#I1755|3.5.10(11)]] ::Scaling [[Guide:95lrm/RM-A-5-3#I5422|A.5.3(27)]] ::Signed_Zeros [[Guide:95lrm/RM-A-5-3#I5409|A.5.3(13)]] ::Size [[Guide:95lrm/RM-13-3#I4209|13.3(40)]], [[Guide:95lrm/RM-13-3#I4214|13.3(45)]] ::Small [[Guide:95lrm/RM-3-5-10#I1742|3.5.10(2/1)]] ::Storage_Pool [[Guide:95lrm/RM-13-11#I4415|13.11(13)]] ::Storage_Size [[Guide:95lrm/RM-13-3#I4219|13.3(60)]], [[Guide:95lrm/RM-13-11#I4417|13.11(14)]], [[Guide:95lrm/RM-J-9#I7100|J.9(2)]] ::Succ [[Guide:95lrm/RM-3-5#I1530|3.5(22)]] ::Tag [[Guide:95lrm/RM-3-9#I1980|3.9(16)]], [[Guide:95lrm/RM-3-9#I1982|3.9(18)]] ::Terminated [[Guide:95lrm/RM-9-9#I3657|9.9(3)]] ::Truncation [[Guide:95lrm/RM-A-5-3#I5435|A.5.3(42)]] ::Unbiased_Rounding [[Guide:95lrm/RM-A-5-3#I5433|A.5.3(39)]] ::Unchecked_Access [[Guide:95lrm/RM-13-10#I4392|13.10(3)]], [[Guide:95lrm/RM-H-4#I7067|H.4(18)]] ::Val [[Guide:95lrm/RM-3-5-5#I1655|3.5.5(5)]] ::Valid [[Guide:95lrm/RM-13-9-2#I4390|13.9.2(3)]], [[Guide:95lrm/RM-H#I7039|H(6)]] ::Value [[Guide:95lrm/RM-3-5#I1566|3.5(52)]] ::Version [[Guide:95lrm/RM-E-3#I6753|E.3(3)]] ::Wide_Image [[Guide:95lrm/RM-3-5#I1544|3.5(28)]] ::Wide_Value [[Guide:95lrm/RM-3-5#I1554|3.5(40)]] ::Wide_Width [[Guide:95lrm/RM-3-5#I1550|3.5(38)]] ::Width [[Guide:95lrm/RM-3-5#I1552|3.5(39)]] ::Write [[Guide:95lrm/RM-13-13-2#I4489|13.13.2(3)]], [[Guide:95lrm/RM-13-13-2#I4493|13.13.2(11)]] == B == :Backus-Naur Form (BNF) ::complete listing [[Guide:95lrm/RM-P#I7289|P]] ::cross reference [[Guide:95lrm/RM-P#I7968|P]] ::notation [[Guide:95lrm/RM-1-1-4#I1064|1.1.4(3)]] ::under Syntax heading [[Guide:95lrm/RM-1-1-2#I1018|1.1.2(25)]] base [[Guide:95lrm/RM-2-4-2#I1216|2.4.2(3)]], [[Guide:95lrm/RM-2-4-2#I1224|2.4.2(6)]] ::''used'' [[Guide:95lrm/RM-2-4-2#I1212|2.4.2(2)]], [[Guide:95lrm/RM-P#I7312|P]] :base 16 literal [[Guide:95lrm/RM-2-4-2#I1209|2.4.2(1)]] :base 2 literal [[Guide:95lrm/RM-2-4-2#I1203|2.4.2(1)]] :base 8 literal [[Guide:95lrm/RM-2-4-2#I1206|2.4.2(1)]] :Base attribute [[Guide:95lrm/RM-3-5#I1524|3.5(15)]] :base decimal precision ::of a floating point type [[Guide:95lrm/RM-3-5-7#I1687|3.5.7(9)]] ::of a floating point type [[Guide:95lrm/RM-3-5-7#I1689|3.5.7(10)]] :base priority [[Guide:95lrm/RM-D-1#I6522|D.1(15)]] :base range ::of a decimal fixed point type [[Guide:95lrm/RM-3-5-9#I1732|3.5.9(16)]] ::of a fixed point type [[Guide:95lrm/RM-3-5-9#I1727|3.5.9(12)]] ::of a floating point type [[Guide:95lrm/RM-3-5-7#I1686|3.5.7(8)]], [[Guide:95lrm/RM-3-5-7#I1691|3.5.7(10)]] ::of a modular type [[Guide:95lrm/RM-3-5-4#I1622|3.5.4(10)]] ::of a scalar type [[Guide:95lrm/RM-3-5#I1508|3.5(6)]] ::of a signed integer type [[Guide:95lrm/RM-3-5-4#I1619|3.5.4(9)]] ::of an ordinary fixed point type [[Guide:95lrm/RM-3-5-9#I1728|3.5.9(13)]] :base subtype ::of a type [[Guide:95lrm/RM-3-5#I1525|3.5(15)]] :based_literal [[Guide:95lrm/RM-2-4-2#I1211|2.4.2(2)]] ::''used'' [[Guide:95lrm/RM-2-4#I1188|2.4(2)]], [[Guide:95lrm/RM-P#I7303|P]] :based_numeral [[Guide:95lrm/RM-2-4-2#I1218|2.4.2(4)]] ::''used'' [[Guide:95lrm/RM-2-4-2#I1213|2.4.2(2)]], [[Guide:95lrm/RM-P#I7313|P]] :basic letter ::a category of Character [[Guide:95lrm/RM-A-3-2#I4641|A.3.2(27)]] :basic_declaration [[Guide:95lrm/RM-3-1#I1265|3.1(3)]] ::''used'' [[Guide:95lrm/RM-3-11#I2134|3.11(4/1)]], [[Guide:95lrm/RM-P#I7480|P]] :basic_declarative_item [[Guide:95lrm/RM-3-11#I2133|3.11(4/1)]] ::''used'' [[Guide:95lrm/RM-3-11#I2131|3.11(3)]], [[Guide:95lrm/RM-7-1#I3061|7.1(3)]], [[Guide:95lrm/RM-P#I7478|P]] :Basic_Map ::''in'' Ada.Strings.Maps.Constants [[Guide:95lrm/RM-A-4-6#I5205|A.4.6(5)]] :Basic_Set ::''in'' Ada.Strings.Maps.Constants [[Guide:95lrm/RM-A-4-6#I5197|A.4.6(4)]] :become nonlimited [[Guide:95lrm/RM-7-3-1#I3102|7.3.1(5/1)]], [[Guide:95lrm/RM-7-5#I3115|7.5(16)]] :BEL ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4657|A.3.3(5)]] :belong ::to a range [[Guide:95lrm/RM-3-5#I1503|3.5(4)]] ::to a subtype [[Guide:95lrm/RM-3-2#I1317|3.2(8)]] :bibliography [[Guide:95lrm/RM-1-2#I1087|1.2(1)]] :big endian [[Guide:95lrm/RM-13-5-3#I4287|13.5.3(2)]] :binary ::literal [[Guide:95lrm/RM-2-4-2#I1204|2.4.2(1)]] ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6246|B.4(10)]] :binary adding operator [[Guide:95lrm/RM-4-5-3#I2531|4.5.3(1)]] :binary literal [[Guide:95lrm/RM-2-4-2#I1202|2.4.2(1)]] :binary operator [[Guide:95lrm/RM-4-5#I2462|4.5(9)]] :binary_adding_operator [[Guide:95lrm/RM-4-5#I2456|4.5(4)]] ::''used'' [[Guide:95lrm/RM-4-4#I2429|4.4(4)]], [[Guide:95lrm/RM-P#I7566|P]] :Binary_Format ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6279|B.4(24)]] :bit field ::''See'' record_representation_clause [[Guide:95lrm/RM-13-5-1#I4255|13.5.1(1)]] :bit ordering [[Guide:95lrm/RM-13-5-3#I4285|13.5.3(2)]] :bit string ::''See'' logical operators on boolean arrays [[Guide:95lrm/RM-4-5-1#I2481|4.5.1(2)]] :Bit_Order ::''in'' System [[Guide:95lrm/RM-13-7#I4322|13.7(15)]] :Bit_Order attribute [[Guide:95lrm/RM-13-5-3#I4293|13.5.3(4)]] :Bit_Order clause [[Guide:95lrm/RM-13-3#I4184|13.3(7)]], [[Guide:95lrm/RM-13-5-3#I4295|13.5.3(4)]] :blank ::in text input for enumeration and numeric types [[Guide:95lrm/RM-A-10-6#I5892|A.10.6(5)]] :Blank_When_Zero ::''in'' Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6844|F.3.3(7)]] :block_statement [[Guide:95lrm/RM-5-6#I2860|5.6(2)]] ::''used'' [[Guide:95lrm/RM-5-1#I2790|5.1(5)]], [[Guide:95lrm/RM-P#I7613|P]] :blocked ::[''partial''] [[Guide:95lrm/RM-D-2-1#I6542|D.2.1(11)]] ::a task state [[Guide:95lrm/RM-9#I3317|9(10)]] ::during an entry call [[Guide:95lrm/RM-9-5-3#I3506|9.5.3(19)]] ::execution of a selective_accept [[Guide:95lrm/RM-9-7-1#I3599|9.7.1(16)]] ::on a delay_statement [[Guide:95lrm/RM-9-6#I3565|9.6(21)]] ::on an accept_statement [[Guide:95lrm/RM-9-5-2#I3477|9.5.2(24)]] ::waiting for activations to complete [[Guide:95lrm/RM-9-2#I3358|9.2(5)]] ::waiting for dependents to terminate [[Guide:95lrm/RM-9-3#I3365|9.3(5)]] :blocked interrupt [[Guide:95lrm/RM-C-3#I6378|C.3(2)]] :blocking, potentially [[Guide:95lrm/RM-9-5-1#I3431|9.5.1(8)]] ::Abort_Task [[Guide:95lrm/RM-C-7-1#I6486|C.7.1(16)]] ::delay_statement [[Guide:95lrm/RM-9-6#I3568|9.6(34)]], [[Guide:95lrm/RM-D-9#I6654|D.9(5)]] ::remote subprogram call [[Guide:95lrm/RM-E-4#I6775|E.4(17)]] ::RPC operations [[Guide:95lrm/RM-E-5#I6814|E.5(23)]] ::Suspend_Until_True [[Guide:95lrm/RM-D-10#I6671|D.10(10)]] :BMP [[Guide:95lrm/RM-3-5-2#I1589|3.5.2(2)]], [[Guide:95lrm/RM-3-5-2#I1594|3.5.2(3)]] :BNF (Backus-Naur Form) ::complete listing [[Guide:95lrm/RM-P#I7288|P]] ::cross reference [[Guide:95lrm/RM-P#I7967|P]] ::notation [[Guide:95lrm/RM-1-1-4#I1063|1.1.4(3)]] ::under Syntax heading [[Guide:95lrm/RM-1-1-2#I1017|1.1.2(25)]] :body [[Guide:95lrm/RM-3-11#I2137|3.11(5)]], [[Guide:95lrm/RM-3-11-1#I2152|3.11.1(1/1)]] ::''used'' [[Guide:95lrm/RM-3-11#I2132|3.11(3)]], [[Guide:95lrm/RM-P#I7479|P]] :body_stub [[Guide:95lrm/RM-10-1-3#I3729|10.1.3(2)]] ::''used'' [[Guide:95lrm/RM-3-11#I2139|3.11(5)]], [[Guide:95lrm/RM-P#I7484|P]] :Body_Version attribute [[Guide:95lrm/RM-E-3#I6756|E.3(4)]] :Boolean [[Guide:95lrm/RM-3-5-3#I1598|3.5.3(1)]] ::''in'' Standard [[Guide:95lrm/RM-A-1#I4550|A.1(5)]] :boolean type [[Guide:95lrm/RM-3-5-3#I1601|3.5.3(1)]] :Bounded ::''child of'' Ada.Strings [[Guide:95lrm/RM-A-4-4#I5004|A.4.4(3)]] :bounded error [[Guide:95lrm/RM-1-1-2#I1039|1.1.2(31)]], [[Guide:95lrm/RM-1-1-5#I1078|1.1.5(8)]] ::cause [[Guide:95lrm/RM-6-2#I2947|6.2(12)]], [[Guide:95lrm/RM-7-6-1#I3167|7.6.1(14/1)]], [[Guide:95lrm/RM-9-5-1#I3429|9.5.1(8)]], [[Guide:95lrm/RM-9-8#I3647|9.8(20)]], [[Guide:95lrm/RM-10-2#I3793|10.2(26)]], [[Guide:95lrm/RM-13-9-1#I4385|13.9.1(9)]], [[Guide:95lrm/RM-13-11-2#I4444|13.11.2(11)]], [[Guide:95lrm/RM-C-7-1#I6487|C.7.1(17)]], [[Guide:95lrm/RM-C-7-2#I6505|C.7.2(13.1/1)]], [[Guide:95lrm/RM-D-5#I6588|D.5(11)]], [[Guide:95lrm/RM-E-1#I6703|E.1(10)]], [[Guide:95lrm/RM-E-3#I6759|E.3(6)]], [[Guide:95lrm/RM-J-7-1#I7097|J.7.1(11)]] :Bounded_String ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5010|A.4.4(6)]] :bounds ::of a discrete_range [[Guide:95lrm/RM-3-6-1#I1811|3.6.1(6)]] ::of an array [[Guide:95lrm/RM-3-6#I1789|3.6(13)]] ::of the index range of an array_aggregate [[Guide:95lrm/RM-4-3-3#I2326|4.3.3(24)]] :box ::compound delimiter [[Guide:95lrm/RM-3-6#I1794|3.6(15)]] :BPH ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4750|A.3.3(17)]] :broadcast signal ::''See'' protected object [[Guide:95lrm/RM-9-4#I3373|9.4(1)]] ::''See'' requeue [[Guide:95lrm/RM-9-5-4#I3511|9.5.4(1)]] :Broken_Bar ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4787|A.3.3(21)]] :BS ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4658|A.3.3(5)]] :Buffer_Size ::''in'' Ada.Storage_IO [[Guide:95lrm/RM-A-9#I5599|A.9(4)]] :Buffer_Type ::''in'' Ada.Storage_IO [[Guide:95lrm/RM-A-9#I5600|A.9(4)]] :by copy parameter passing [[Guide:95lrm/RM-6-2#I2935|6.2(2)]] :by reference parameter passing [[Guide:95lrm/RM-6-2#I2938|6.2(2)]] :by-copy type [[Guide:95lrm/RM-6-2#I2940|6.2(3)]] :by-reference type [[Guide:95lrm/RM-6-2#I2941|6.2(4)]] ::atomic or volatile [[Guide:95lrm/RM-C-6#I6461|C.6(18)]] :Byte ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6288|B.4(29)]] ::''See'' storage element [[Guide:95lrm/RM-13-3#I4193|13.3(8)]] :byte sex ::''See'' ordering of storage elements in a word [[Guide:95lrm/RM-13-5-3#I4296|13.5.3(5)]] :Byte_Array ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6290|B.4(29)]] == C == :C ::''child of'' Interfaces [[Guide:95lrm/RM-B-3#I6094|B.3(4)]] :C interface [[Guide:95lrm/RM-B-3#I6093|B.3(1/1)]] :C standard [[Guide:95lrm/RM-1-2#I1105|1.2(7)]] :C_float ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6124|B.3(15)]] :Calendar ::''child of'' Ada [[Guide:95lrm/RM-9-6#I3537|9.6(10)]] :call [[Guide:95lrm/RM-6#I2879|6(2)]] :call on a dispatching operation [[Guide:95lrm/RM-3-9-2#I2014|3.9.2(2)]] :callable [[Guide:95lrm/RM-9-9#I3656|9.9(2)]] :Callable attribute [[Guide:95lrm/RM-9-9#I3654|9.9(2)]] :callable construct [[Guide:95lrm/RM-6#I2880|6(2)]] :callable entity [[Guide:95lrm/RM-6#I2878|6(2)]] :called partition [[Guide:95lrm/RM-E-4#I6765|E.4(1)]] :Caller attribute [[Guide:95lrm/RM-C-7-1#I6483|C.7.1(14)]] :calling convention [[Guide:95lrm/RM-6-3-1#I2963|6.3.1(2/1)]], [[Guide:95lrm/RM-B-1#I6056|B.1(11)]] ::Ada [[Guide:95lrm/RM-6-3-1#I2965|6.3.1(3)]] ::associated with a designated profile [[Guide:95lrm/RM-3-10#I2076|3.10(11)]] ::entry [[Guide:95lrm/RM-6-3-1#I2971|6.3.1(13)]] ::Intrinsic [[Guide:95lrm/RM-6-3-1#I2967|6.3.1(4)]] ::protected [[Guide:95lrm/RM-6-3-1#I2969|6.3.1(12)]] :calling partition [[Guide:95lrm/RM-E-4#I6764|E.4(1)]] :calling stub [[Guide:95lrm/RM-E-4#I6770|E.4(10)]] :CAN ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4674|A.3.3(6)]] :cancellation ::of a delay_statement [[Guide:95lrm/RM-9-6#I3566|9.6(22)]] ::of an entry call [[Guide:95lrm/RM-9-5-3#I3507|9.5.3(20)]] :cancellation of a remote subprogram call [[Guide:95lrm/RM-E-4#I6773|E.4(13)]] :canonical form [[Guide:95lrm/RM-A-5-3#I5392|A.5.3(3)]] :canonical semantics [[Guide:95lrm/RM-11-6#I3952|11.6(2)]] :canonical-form representation [[Guide:95lrm/RM-A-5-3#I5404|A.5.3(10)]] :case insensitive [[Guide:95lrm/RM-2-3#I1182|2.3(5)]] :case_statement [[Guide:95lrm/RM-5-4#I2829|5.4(2)]] ::''used'' [[Guide:95lrm/RM-5-1#I2788|5.1(5)]], [[Guide:95lrm/RM-P#I7611|P]] :case_statement_alternative [[Guide:95lrm/RM-5-4#I2833|5.4(3)]] ::''used'' [[Guide:95lrm/RM-5-4#I2831|5.4(2)]], [[Guide:95lrm/RM-P#I7628|P]] :cast ::''See'' type conversion [[Guide:95lrm/RM-4-6#I2607|4.6(1)]] ::''See'' unchecked type conversion [[Guide:95lrm/RM-13-9#I4369|13.9(1)]] :catch (an exception) ::''See'' handle [[Guide:95lrm/RM-11#I3833|11(1)]] :categorization pragma [[Guide:95lrm/RM-E-2#I6705|E.2(2)]] ::Remote_Call_Interface [[Guide:95lrm/RM-E-2-3#I6735|E.2.3(2)]] ::Remote_Types [[Guide:95lrm/RM-E-2-2#I6726|E.2.2(2)]] ::Shared_Passive [[Guide:95lrm/RM-E-2-1#I6714|E.2.1(2)]] :categorized library unit [[Guide:95lrm/RM-E-2#I6709|E.2(2)]] :catenation operator ::''See'' concatenation operator [[Guide:95lrm/RM-4-4#I2383|4.4(1)]] ::''See'' concatenation operator [[Guide:95lrm/RM-4-5-3#I2547|4.5.3(3)]] :CCH ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4768|A.3.3(18)]] :Cedilla ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4807|A.3.3(22)]] :Ceiling attribute [[Guide:95lrm/RM-A-5-3#I5430|A.5.3(33)]] :ceiling priority ::of a protected object [[Guide:95lrm/RM-D-3#I6563|D.3(8)]] :Ceiling_Check ::[''partial''] [[Guide:95lrm/RM-C-3-1#I6396|C.3.1(11)]], [[Guide:95lrm/RM-D-3#I6566|D.3(13)]] :Cent_Sign ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4783|A.3.3(21)]] :change of representation [[Guide:95lrm/RM-13-6#I4298|13.6(1)]] :char ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6130|B.3(19)]] :char_array ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6137|B.3(23)]] :char_array_access ::''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6174|B.3.1(4)]] :CHAR_BIT ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6097|B.3(6)]] :character [[Guide:95lrm/RM-2-1#I1115|2.1(2)]], [[Guide:95lrm/RM-3-5-2#I1591|3.5.2(2)]] ::''used'' [[Guide:95lrm/RM-2-7#I1235|2.7(2)]], [[Guide:95lrm/RM-P#I7324|P]] ::''in'' Standard [[Guide:95lrm/RM-A-1#I4558|A.1(35)]] :character set [[Guide:95lrm/RM-2-1#I1114|2.1(1)]] :character set standard ::16-bit [[Guide:95lrm/RM-1-2#I1108|1.2(8/1)]] ::7-bit [[Guide:95lrm/RM-1-2#I1090|1.2(2)]] ::8-bit [[Guide:95lrm/RM-1-2#I1102|1.2(6)]] :control functions [[Guide:95lrm/RM-1-2#I1099|1.2(5)]] :character type [[Guide:95lrm/RM-3-5-2#I1587|3.5.2(1)]] :character_literal [[Guide:95lrm/RM-2-5#I1225|2.5(2)]] ::''used'' [[Guide:95lrm/RM-3-5-1#I1580|3.5.1(4)]], [[Guide:95lrm/RM-4-1#I2165|4.1(2)]], [[Guide:95lrm/RM-4-1-3#I2215|4.1.3(3)]], [[Guide:95lrm/RM-P#I7512|P]] :Character_Mapping ::''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4926|A.4.2(20)]] :Character_Mapping_Function ::''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4937|A.4.2(25)]] :Character_Range ::''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4905|A.4.2(6)]] :Character_Ranges ::''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4907|A.4.2(7)]] :Character_Sequence ::''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4918|A.4.2(16)]] :Character_Set ::''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4902|A.4.2(4)]] ::''in'' Ada.Strings.Wide_Maps.Wide_Constants [[Guide:95lrm/RM-A-4-7#I5258|A.4.7(46)]] ::''in'' Interfaces.Fortran [[Guide:95lrm/RM-B-5#I6345|B.5(11)]] :characteristics [[Guide:95lrm/RM-7-3#I3098|7.3(15)]] :Characters ::''child of'' Ada [[Guide:95lrm/RM-A-3-1#I4575|A.3.1(2)]] :chars_ptr ::''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6176|B.3.1(5)]] :chars_ptr_array ::''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6178|B.3.1(6)]] :check ::language-defined [[Guide:95lrm/RM-11-5#I3915|11.5(2)]], [[Guide:95lrm/RM-11-6#I3947|11.6(1)]] :check, language-defined ::Access_Check [[Guide:95lrm/RM-4-1#I2185|4.1(13)]], [[Guide:95lrm/RM-4-6#I2680|4.6(49)]] ::Accessibility_Check [[Guide:95lrm/RM-3-10-2#I2116|3.10.2(29)]], [[Guide:95lrm/RM-4-6#I2678|4.6(48)]], [[Guide:95lrm/RM-6-5#I3046|6.5(17)]], [[Guide:95lrm/RM-E-4#I6777|E.4(18/1)]] ::Ceiling_Check [[Guide:95lrm/RM-C-3-1#I6397|C.3.1(11)]], [[Guide:95lrm/RM-D-3#I6567|D.3(13)]] ::Discriminant_Check [[Guide:95lrm/RM-4-1-3#I2220|4.1.3(15)]], [[Guide:95lrm/RM-4-3#I2264|4.3(6)]], [[Guide:95lrm/RM-4-3-2#I2297|4.3.2(8)]], [[Guide:95lrm/RM-4-6#I2670|4.6(43)]], [[Guide:95lrm/RM-4-6#I2672|4.6(45)]], [[Guide:95lrm/RM-4-6#I2684|4.6(51)]], [[Guide:95lrm/RM-4-6#I2693|4.6(52)]], [[Guide:95lrm/RM-4-7#I2712|4.7(4)]], [[Guide:95lrm/RM-4-8#I2738|4.8(10/1)]] ::Division_Check [[Guide:95lrm/RM-3-5-4#I1641|3.5.4(20)]], [[Guide:95lrm/RM-4-5-5#I2582|4.5.5(22)]], [[Guide:95lrm/RM-A-5-1#I5330|A.5.1(28)]], [[Guide:95lrm/RM-A-5-3#I5441|A.5.3(47)]], [[Guide:95lrm/RM-G-1-1#I6915|G.1.1(40)]], [[Guide:95lrm/RM-G-1-2#I6967|G.1.2(28)]], [[Guide:95lrm/RM-K#I7130|K(202)]] ::Elaboration_Check [[Guide:95lrm/RM-3-11#I2148|3.11(9)]] ::Index_Check [[Guide:95lrm/RM-4-1-1#I2197|4.1.1(7)]], [[Guide:95lrm/RM-4-1-2#I2206|4.1.2(7)]], [[Guide:95lrm/RM-4-3-3#I2330|4.3.3(29)]], [[Guide:95lrm/RM-4-3-3#I2332|4.3.3(30)]], [[Guide:95lrm/RM-4-5-3#I2550|4.5.3(8)]], [[Guide:95lrm/RM-4-6#I2686|4.6(51)]], [[Guide:95lrm/RM-4-7#I2714|4.7(4)]], [[Guide:95lrm/RM-4-8#I2736|4.8(10/1)]] ::Length_Check [[Guide:95lrm/RM-4-5-1#I2484|4.5.1(8)]], [[Guide:95lrm/RM-4-6#I2661|4.6(37)]], [[Guide:95lrm/RM-4-6#I2689|4.6(52)]] ::Overflow_Check [[Guide:95lrm/RM-3-5-4#I1638|3.5.4(20)]], [[Guide:95lrm/RM-4-4#I2450|4.4(11)]], [[Guide:95lrm/RM-5-4#I2840|5.4(13)]], [[Guide:95lrm/RM-G-2-1#I7004|G.2.1(11)]], [[Guide:95lrm/RM-G-2-2#I7018|G.2.2(7)]], [[Guide:95lrm/RM-G-2-3#I7022|G.2.3(25)]], [[Guide:95lrm/RM-G-2-4#I7027|G.2.4(2)]], [[Guide:95lrm/RM-G-2-6#I7034|G.2.6(3)]] ::Partition_Check [[Guide:95lrm/RM-E-4#I6780|E.4(19)]] ::Range_Check [[Guide:95lrm/RM-3-2-2#I1374|3.2.2(11)]], [[Guide:95lrm/RM-3-5#I1536|3.5(24)]], [[Guide:95lrm/RM-3-5#I1541|3.5(27)]], [[Guide:95lrm/RM-3-5#I1559|3.5(43)]], [[Guide:95lrm/RM-3-5#I1562|3.5(44)]], [[Guide:95lrm/RM-3-5#I1565|3.5(51)]], [[Guide:95lrm/RM-3-5#I1571|3.5(55)]], [[Guide:95lrm/RM-3-5-5#I1660|3.5.5(7)]], [[Guide:95lrm/RM-3-5-9#I1740|3.5.9(19)]], [[Guide:95lrm/RM-4-2#I2252|4.2(11)]], [[Guide:95lrm/RM-4-3-3#I2328|4.3.3(28)]], [[Guide:95lrm/RM-4-5-1#I2486|4.5.1(8)]], [[Guide:95lrm/RM-4-5-6#I2593|4.5.6(6)]], [[Guide:95lrm/RM-4-5-6#I2602|4.5.6(13)]], [[Guide:95lrm/RM-4-6#I2651|4.6(28)]], [[Guide:95lrm/RM-4-6#I2663|4.6(38)]], [[Guide:95lrm/RM-4-6#I2674|4.6(46)]], [[Guide:95lrm/RM-4-6#I2682|4.6(51)]], [[Guide:95lrm/RM-4-7#I2710|4.7(4)]], [[Guide:95lrm/RM-13-13-2#I4506|13.13.2(35)]], [[Guide:95lrm/RM-A-5-2#I5385|A.5.2(39)]], [[Guide:95lrm/RM-A-5-3#I5421|A.5.3(26)]], [[Guide:95lrm/RM-A-5-3#I5426|A.5.3(29)]], [[Guide:95lrm/RM-A-5-3#I5446|A.5.3(50)]], [[Guide:95lrm/RM-A-5-3#I5451|A.5.3(53)]], [[Guide:95lrm/RM-A-5-3#I5456|A.5.3(59)]], [[Guide:95lrm/RM-A-5-3#I5461|A.5.3(62)]], [[Guide:95lrm/RM-K#I7106|K(11)]], [[Guide:95lrm/RM-K#I7119|K(114)]], [[Guide:95lrm/RM-K#I7122|K(122)]], [[Guide:95lrm/RM-K#I7125|K(184)]], [[Guide:95lrm/RM-K#I7134|K(220)]], [[Guide:95lrm/RM-K#I7139|K(241)]], [[Guide:95lrm/RM-K#I7111|K(41)]], [[Guide:95lrm/RM-K#I7114|K(47)]] ::Reserved_Check [[Guide:95lrm/RM-C-3-1#I6393|C.3.1(10)]] ::Storage_Check [[Guide:95lrm/RM-11-1#I3847|11.1(6)]], [[Guide:95lrm/RM-13-3#I4228|13.3(67)]], [[Guide:95lrm/RM-13-11#I4427|13.11(17)]], [[Guide:95lrm/RM-D-7#I6604|D.7(17/1)]], [[Guide:95lrm/RM-D-7#I6608|D.7(18/1)]], [[Guide:95lrm/RM-D-7#I6612|D.7(19/1)]] ::Tag_Check [[Guide:95lrm/RM-3-9-2#I2028|3.9.2(16)]], [[Guide:95lrm/RM-4-6#I2668|4.6(42)]], [[Guide:95lrm/RM-4-6#I2691|4.6(52)]], [[Guide:95lrm/RM-5-2#I2813|5.2(10)]], [[Guide:95lrm/RM-6-5#I3042|6.5(9)]] :child ::of a library unit [[Guide:95lrm/RM-10-1-1#I3676|10.1.1(1)]] :choice parameter [[Guide:95lrm/RM-11-2#I3864|11.2(9)]] :choice_parameter_specification [[Guide:95lrm/RM-11-2#I3859|11.2(4)]] ::''used'' [[Guide:95lrm/RM-11-2#I3855|11.2(3)]], [[Guide:95lrm/RM-P#I7862|P]] :Circumflex ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4709|A.3.3(12)]] :class ::of types [[Guide:95lrm/RM-3-2#I1299|3.2(2)]] ::''See also'' package [[Guide:95lrm/RM-7#I3056|7(1)]] ::''See also'' tag [[Guide:95lrm/RM-3-9#I1963|3.9(3)]] :Class attribute [[Guide:95lrm/RM-3-9#I1977|3.9(14)]], [[Guide:95lrm/RM-7-3-1#I3106|7.3.1(9)]] :class determined for a formal type [[Guide:95lrm/RM-12-5#I4069|12.5(6)]] :class-wide type [[Guide:95lrm/RM-3-4-1#I1477|3.4.1(4)]], [[Guide:95lrm/RM-3-7#I1868|3.7(26)]] :cleanup ::''See'' finalization [[Guide:95lrm/RM-7-6-1#I3152|7.6.1(1)]] :clock [[Guide:95lrm/RM-9-6#I3536|9.6(6)]] ::''in'' Ada.Calendar [[Guide:95lrm/RM-9-6#I3547|9.6(12)]] ::''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6630|D.8(6)]] :clock jump [[Guide:95lrm/RM-D-8#I6651|D.8(32)]] :clock tick [[Guide:95lrm/RM-D-8#I6650|D.8(23)]] :Close ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5558|A.8.4(8)]] ::''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5515|A.8.1(8)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5931|A.12.1(10)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5639|A.10.1(11)]] :close result set [[Guide:95lrm/RM-G-2-3#I7020|G.2.3(5)]] :closed entry [[Guide:95lrm/RM-9-5-3#I3489|9.5.3(5)]] ::of a protected object [[Guide:95lrm/RM-9-5-3#I3494|9.5.3(7)]] ::of a task [[Guide:95lrm/RM-9-5-3#I3492|9.5.3(6)]] :closed under derivation [[Guide:95lrm/RM-3-4#I1470|3.4(28)]], [[Guide:95lrm/RM-N#I7275|N(6)]], [[Guide:95lrm/RM-N#I7284|N(41)]] :closure ::downward [[Guide:95lrm/RM-3-10-2#I2127|3.10.2(37)]] :COBOL ::''child of'' Interfaces [[Guide:95lrm/RM-B-4#I6238|B.4(7)]] :COBOL interface [[Guide:95lrm/RM-B-4#I6237|B.4(1)]] :COBOL standard [[Guide:95lrm/RM-1-2#I1096|1.2(4)]] :COBOL_Character ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6256|B.4(13)]] :COBOL_To_Ada ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6258|B.4(15)]] :code_statement [[Guide:95lrm/RM-13-8#I4358|13.8(2)]] ::''used'' [[Guide:95lrm/RM-5-1#I2785|5.1(4)]], [[Guide:95lrm/RM-P#I7609|P]] :coding ::aspect of representation [[Guide:95lrm/RM-13-4#I4246|13.4(7)]] :Col ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5743|A.10.1(37)]] :colon [[Guide:95lrm/RM-2-1#I1155|2.1(15)]] ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4699|A.3.3(10)]] :column number [[Guide:95lrm/RM-A-10#I5613|A.10(9)]] :comma [[Guide:95lrm/RM-2-1#I1147|2.1(15)]] ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4694|A.3.3(8)]] :Command_Line ::''child of'' Ada [[Guide:95lrm/RM-A-15#I6005|A.15(3)]] :Command_Name ::''in'' Ada.Command_Line [[Guide:95lrm/RM-A-15#I6013|A.15(6)]] :comment [[Guide:95lrm/RM-2-7#I1234|2.7(2)]] :comments, instructions for submission [[Guide:95lrm/RM-0-3#I1004|0.3(58/1)]] :Commercial_At ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4705|A.3.3(10)]] :Communication_Error ::''in'' System.RPC [[Guide:95lrm/RM-E-5#I6796|E.5(5)]] :comparison operator ::''See'' relational operator [[Guide:95lrm/RM-4-5-2#I2490|4.5.2(1)]] :compatibility ::composite_constraint with an access subtype [[Guide:95lrm/RM-3-10#I2083|3.10(15)]] ::constraint with a subtype [[Guide:95lrm/RM-3-2-2#I1375|3.2.2(12)]] ::delta_constraint with an ordinary fixed point subtype [[Guide:95lrm/RM-J-3#I7082|J.3(9)]] ::digits_constraint with a decimal fixed point subtype [[Guide:95lrm/RM-3-5-9#I1737|3.5.9(18)]] ::digits_constraint with a floating point subtype [[Guide:95lrm/RM-J-3#I7083|J.3(10)]] ::discriminant constraint with a subtype [[Guide:95lrm/RM-3-7-1#I1884|3.7.1(10)]] ::index constraint with a subtype [[Guide:95lrm/RM-3-6-1#I1812|3.6.1(7)]] ::range with a scalar subtype [[Guide:95lrm/RM-3-5#I1512|3.5(8)]] ::range_constraint with a scalar subtype [[Guide:95lrm/RM-3-5#I1513|3.5(8)]] :compatible ::a type, with a convention [[Guide:95lrm/RM-B-1#I6057|B.1(12)]] :compilation [[Guide:95lrm/RM-10-1-1#I3677|10.1.1(2)]] ::separate [[Guide:95lrm/RM-10-1#I3671|10.1(1)]] :Compilation unit [[Guide:95lrm/RM-10-1#I3673|10.1(2)]], [[Guide:95lrm/RM-10-1-1#I3703|10.1.1(9)]] :compilation units needed ::by a compilation unit [[Guide:95lrm/RM-10-2#I3784|10.2(2)]] ::remote call interface [[Guide:95lrm/RM-E-2-3#I6750|E.2.3(18)]] ::shared passive library unit [[Guide:95lrm/RM-E-2-1#I6723|E.2.1(11)]] :compilation_unit [[Guide:95lrm/RM-10-1-1#I3679|10.1.1(3)]] ::''used'' [[Guide:95lrm/RM-10-1-1#I3678|10.1.1(2)]], [[Guide:95lrm/RM-P#I7825|P]] :compile-time error [[Guide:95lrm/RM-1-1-2#I1023|1.1.2(27)]], [[Guide:95lrm/RM-1-1-5#I1072|1.1.5(4)]] :compile-time semantics [[Guide:95lrm/RM-1-1-2#I1028|1.1.2(28)]] :complete context [[Guide:95lrm/RM-8-6#I3282|8.6(4)]] :completely defined [[Guide:95lrm/RM-3-11-1#I2155|3.11.1(8)]] :completion ::abnormal [[Guide:95lrm/RM-7-6-1#I3159|7.6.1(2)]] ::compile-time concept [[Guide:95lrm/RM-3-11-1#I2151|3.11.1(1/1)]] ::normal [[Guide:95lrm/RM-7-6-1#I3157|7.6.1(2)]] ::run-time concept [[Guide:95lrm/RM-7-6-1#I3155|7.6.1(2)]] :completion and leaving (completed and left) [[Guide:95lrm/RM-7-6-1#I3154|7.6.1(2)]] :completion legality ::[''partial''] [[Guide:95lrm/RM-3-10-1#I2094|3.10.1(13)]] ::entry_body [[Guide:95lrm/RM-9-5-2#I3465|9.5.2(16)]] :Complex ::''in'' Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6873|G.1.1(3)]] ::''in'' Interfaces.Fortran [[Guide:95lrm/RM-B-5#I6340|B.5(9)]] :Complex_Elementary_Functions ::''child of'' Ada.Numerics [[Guide:95lrm/RM-G-1-2#I6963|G.1.2(9/1)]] :Complex_Types ::''child of'' Ada.Numerics [[Guide:95lrm/RM-G-1-1#I6911|G.1.1(25/1)]] :Complex_IO ::''child of'' Ada.Text_IO [[Guide:95lrm/RM-G-1-3#I6973|G.1.3(3)]] ::''child of'' Ada.Wide_Text_IO [[Guide:95lrm/RM-G-1-4#I6992|G.1.4(1)]] :component [[Guide:95lrm/RM-3-2#I1303|3.2(2)]] :component subtype [[Guide:95lrm/RM-3-6#I1784|3.6(10)]] :component_choice_list [[Guide:95lrm/RM-4-3-1#I2274|4.3.1(5)]] ::''used'' [[Guide:95lrm/RM-4-3-1#I2272|4.3.1(4)]], [[Guide:95lrm/RM-P#I7527|P]] :component_clause [[Guide:95lrm/RM-13-5-1#I4260|13.5.1(3)]] ::''used'' [[Guide:95lrm/RM-13-5-1#I4259|13.5.1(2)]], [[Guide:95lrm/RM-P#I7947|P]] :component_declaration [[Guide:95lrm/RM-3-8#I1906|3.8(6)]] ::''used'' [[Guide:95lrm/RM-3-8#I1904|3.8(5/1)]], [[Guide:95lrm/RM-9-4#I3391|9.4(6)]], [[Guide:95lrm/RM-P#I7453|P]] :component_definition [[Guide:95lrm/RM-3-6#I1779|3.6(7)]] ::''used'' [[Guide:95lrm/RM-3-6#I1769|3.6(3)]], [[Guide:95lrm/RM-3-6#I1775|3.6(5)]], [[Guide:95lrm/RM-3-8#I1908|3.8(6)]], [[Guide:95lrm/RM-P#I7419|P]] :component_item [[Guide:95lrm/RM-3-8#I1903|3.8(5/1)]] ::''used'' [[Guide:95lrm/RM-3-8#I1899|3.8(4)]], [[Guide:95lrm/RM-P#I7449|P]] :component_list [[Guide:95lrm/RM-3-8#I1898|3.8(4)]] ::''used'' [[Guide:95lrm/RM-3-8#I1897|3.8(3)]], [[Guide:95lrm/RM-3-8-1#I1930|3.8.1(3)]], [[Guide:95lrm/RM-P#I7462|P]] :Component_Size attribute [[Guide:95lrm/RM-13-3#I4231|13.3(69)]] :Component_Size clause [[Guide:95lrm/RM-13-3#I4181|13.3(7)]], [[Guide:95lrm/RM-13-3#I4233|13.3(70)]] :components ::of a record type [[Guide:95lrm/RM-3-8#I1911|3.8(9)]] :Compose attribute [[Guide:95lrm/RM-A-5-3#I5418|A.5.3(24)]] :Compose_From_Cartesian ::''in'' Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6891|G.1.1(8)]] :Compose_From_Polar ::''in'' Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6903|G.1.1(11)]] :composite type [[Guide:95lrm/RM-3-2#I1302|3.2(2)]] :composite_constraint [[Guide:95lrm/RM-3-2-2#I1367|3.2.2(7)]] ::''used'' [[Guide:95lrm/RM-3-2-2#I1362|3.2.2(5)]], [[Guide:95lrm/RM-P#I7366|P]] :compound delimiter [[Guide:95lrm/RM-2-2#I1174|2.2(10)]] :compound_statement [[Guide:95lrm/RM-5-1#I2786|5.1(5)]] ::''used'' [[Guide:95lrm/RM-5-1#I2772|5.1(3)]], [[Guide:95lrm/RM-P#I7597|P]] :concatenation operator [[Guide:95lrm/RM-4-4#I2381|4.4(1)]], [[Guide:95lrm/RM-4-5-3#I2545|4.5.3(3)]] :concrete subprogram ::''See'' nonabstract subprogram [[Guide:95lrm/RM-3-9-3#I2036|3.9.3(1)]] :concrete type ::''See'' nonabstract type [[Guide:95lrm/RM-3-9-3#I2034|3.9.3(1)]] :concurrent processing ::''See'' task [[Guide:95lrm/RM-9#I3310|9(1)]] :condition [[Guide:95lrm/RM-5-3#I2825|5.3(3)]] ::''used'' [[Guide:95lrm/RM-5-3#I2822|5.3(2)]], [[Guide:95lrm/RM-5-5#I2848|5.5(3)]], [[Guide:95lrm/RM-5-7#I2868|5.7(2)]], [[Guide:95lrm/RM-9-5-2#I3456|9.5.2(7)]], [[Guide:95lrm/RM-9-7-1#I3584|9.7.1(3)]], [[Guide:95lrm/RM-P#I7644|P]] ::''See also'' exception [[Guide:95lrm/RM-11#I3830|11(1)]] :conditional_entry_call [[Guide:95lrm/RM-9-7-3#I3609|9.7.3(2)]] ::''used'' [[Guide:95lrm/RM-9-7#I3574|9.7(2)]], [[Guide:95lrm/RM-P#I7795|P]] :configuration ::of the partitions of a program [[Guide:95lrm/RM-E#I6692|E(4)]] :configuration pragma [[Guide:95lrm/RM-10-1-5#I3762|10.1.5(8)]] ::Locking_Policy [[Guide:95lrm/RM-D-3#I6560|D.3(5)]] ::Normalize_Scalars [[Guide:95lrm/RM-H-1#I7043|H.1(4)]] ::Queuing_Policy [[Guide:95lrm/RM-D-4#I6575|D.4(5)]] ::Restrictions [[Guide:95lrm/RM-13-12#I4468|13.12(8)]] ::Reviewable [[Guide:95lrm/RM-H-3-1#I7048|H.3.1(4)]] ::Suppress [[Guide:95lrm/RM-11-5#I3924|11.5(5)]] ::Task_Dispatching_Policy [[Guide:95lrm/RM-D-2-2#I6548|D.2.2(4)]] :conformance [[Guide:95lrm/RM-6-3-1#I2957|6.3.1(1)]] ::of an implementation with the Standard [[Guide:95lrm/RM-1-1-3#I1050|1.1.3(1)]] ::''See also'' full conformance, mode conformance, subtype conformance, type conformance :Conjugate ::''in'' Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6907|G.1.1(12)]], [[Guide:95lrm/RM-G-1-1#I6909|G.1.1(15)]] :consistency ::among compilation units [[Guide:95lrm/RM-10-1-4#I3752|10.1.4(5)]] :constant [[Guide:95lrm/RM-3-3#I1385|3.3(13)]] ::result of a function_call [[Guide:95lrm/RM-6-4#I3016|6.4(12)]] ::''See also'' literal [[Guide:95lrm/RM-4-2#I2241|4.2(1)]] ::''See also'' static [[Guide:95lrm/RM-4-9#I2742|4.9(1)]] :constant object [[Guide:95lrm/RM-3-3#I1387|3.3(13)]] :constant view [[Guide:95lrm/RM-3-3#I1389|3.3(13)]] :Constants ::''child of'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-6#I5189|A.4.6(3)]] :constituent ::of a construct [[Guide:95lrm/RM-1-1-4#I1068|1.1.4(17)]] :constrained [[Guide:95lrm/RM-3-2#I1318|3.2(9)]] ::object [[Guide:95lrm/RM-3-3-1#I1427|3.3.1(9)]], [[Guide:95lrm/RM-3-10#I2067|3.10(9)]] ::object [[Guide:95lrm/RM-6-4-1#I3025|6.4.1(16)]] ::subtype [[Guide:95lrm/RM-3-2#I1320|3.2(9)]], [[Guide:95lrm/RM-3-4#I1453|3.4(6)]], [[Guide:95lrm/RM-3-5#I1509|3.5(7)]], [[Guide:95lrm/RM-3-5-1#I1585|3.5.1(10)]], [[Guide:95lrm/RM-3-5-4#I1620|3.5.4(9)]], [[Guide:95lrm/RM-3-5-4#I1623|3.5.4(10)]], [[Guide:95lrm/RM-3-5-7#I1692|3.5.7(11)]], [[Guide:95lrm/RM-3-5-9#I1729|3.5.9(13)]], [[Guide:95lrm/RM-3-5-9#I1733|3.5.9(16)]], [[Guide:95lrm/RM-3-6#I1792|3.6(15)]], [[Guide:95lrm/RM-3-6#I1795|3.6(16)]], [[Guide:95lrm/RM-3-7#I1864|3.7(26)]], [[Guide:95lrm/RM-3-9#I1979|3.9(15)]] ::subtype [[Guide:95lrm/RM-3-10#I2081|3.10(14/1)]] ::subtype [[Guide:95lrm/RM-K#I7108|K(35)]] :Constrained attribute [[Guide:95lrm/RM-3-7-2#I1889|3.7.2(3)]], [[Guide:95lrm/RM-J-4#I7086|J.4(2)]] :constrained by its initial value [[Guide:95lrm/RM-3-3-1#I1424|3.3.1(9)]], [[Guide:95lrm/RM-3-10#I2069|3.10(9)]] ::[''partial''] [[Guide:95lrm/RM-4-8#I2727|4.8(6)]] :constrained_array_definition [[Guide:95lrm/RM-3-6#I1772|3.6(5)]] ::''used'' [[Guide:95lrm/RM-3-6#I1765|3.6(2)]], [[Guide:95lrm/RM-P#I7416|P]] :constraint [[Guide:95lrm/RM-3-2-2#I1360|3.2.2(5)]] ::[''partial''] [[Guide:95lrm/RM-3-2#I1314|3.2(7)]] ::of a first array subtype [[Guide:95lrm/RM-3-6#I1797|3.6(16)]] ::of an object [[Guide:95lrm/RM-3-3-1#I1423|3.3.1(9)]] ::''used'' [[Guide:95lrm/RM-3-2-2#I1357|3.2.2(3)]], [[Guide:95lrm/RM-P#I7363|P]] :Constraint_Error ::raised by failure of run-time check [[Guide:95lrm/RM-3-2-2#I1376|3.2.2(12)]], [[Guide:95lrm/RM-3-5#I1532|3.5(24)]], [[Guide:95lrm/RM-3-5#I1539|3.5(27)]], [[Guide:95lrm/RM-3-5#I1557|3.5(43)]], [[Guide:95lrm/RM-3-5#I1560|3.5(44)]], [[Guide:95lrm/RM-3-5#I1563|3.5(51)]], [[Guide:95lrm/RM-3-5#I1569|3.5(55)]], [[Guide:95lrm/RM-3-5-4#I1642|3.5.4(20)]], [[Guide:95lrm/RM-3-5-5#I1658|3.5.5(7)]], [[Guide:95lrm/RM-3-5-9#I1741|3.5.9(19)]], [[Guide:95lrm/RM-3-9-2#I2029|3.9.2(16)]], [[Guide:95lrm/RM-4-1#I2186|4.1(13)]], [[Guide:95lrm/RM-4-1-1#I2198|4.1.1(7)]], [[Guide:95lrm/RM-4-1-2#I2208|4.1.2(7)]], [[Guide:95lrm/RM-4-1-3#I2222|4.1.3(15)]], [[Guide:95lrm/RM-4-2#I2253|4.2(11)]], [[Guide:95lrm/RM-4-3#I2265|4.3(6)]], [[Guide:95lrm/RM-4-3-2#I2298|4.3.2(8)]], [[Guide:95lrm/RM-4-3-3#I2333|4.3.3(31)]], [[Guide:95lrm/RM-4-4#I2451|4.4(11)]], [[Guide:95lrm/RM-4-5#I2466|4.5(10)]], [[Guide:95lrm/RM-4-5#I2467|4.5(11)]], [[Guide:95lrm/RM-4-5#I2468|4.5(12)]], [[Guide:95lrm/RM-4-5-1#I2487|4.5.1(8)]], [[Guide:95lrm/RM-4-5-3#I2551|4.5.3(8)]], [[Guide:95lrm/RM-4-5-5#I2583|4.5.5(22)]], [[Guide:95lrm/RM-4-5-6#I2594|4.5.6(6)]], [[Guide:95lrm/RM-4-5-6#I2600|4.5.6(12)]], [[Guide:95lrm/RM-4-5-6#I2603|4.5.6(13)]], [[Guide:95lrm/RM-4-6#I2652|4.6(28)]], [[Guide:95lrm/RM-4-6#I2697|4.6(57)]], [[Guide:95lrm/RM-4-6#I2700|4.6(60)]], [[Guide:95lrm/RM-4-7#I2716|4.7(4)]], [[Guide:95lrm/RM-4-8#I2739|4.8(10/1)]], [[Guide:95lrm/RM-5-2#I2814|5.2(10)]], [[Guide:95lrm/RM-5-4#I2841|5.4(13)]], [[Guide:95lrm/RM-6-5#I3043|6.5(9)]], [[Guide:95lrm/RM-11-1#I3841|11.1(4)]], [[Guide:95lrm/RM-11-4-1#I3913|11.4.1(14)]], [[Guide:95lrm/RM-11-5#I3927|11.5(10)]], [[Guide:95lrm/RM-13-9-1#I4387|13.9.1(9)]], [[Guide:95lrm/RM-13-13-2#I4507|13.13.2(35)]], [[Guide:95lrm/RM-A-4-3#I5003|A.4.3(109)]], [[Guide:95lrm/RM-A-4-3#I5002|A.4.3(68/1)]], [[Guide:95lrm/RM-A-4-7#I5259|A.4.7(47)]], [[Guide:95lrm/RM-A-5-1#I5331|A.5.1(28)]], [[Guide:95lrm/RM-A-5-1#I5332|A.5.1(34)]], [[Guide:95lrm/RM-A-5-2#I5386|A.5.2(39)]], [[Guide:95lrm/RM-A-5-2#I5388|A.5.2(40.1/1)]], [[Guide:95lrm/RM-A-5-3#I5419|A.5.3(26)]], [[Guide:95lrm/RM-A-5-3#I5424|A.5.3(29)]], [[Guide:95lrm/RM-A-5-3#I5439|A.5.3(47)]], [[Guide:95lrm/RM-A-5-3#I5444|A.5.3(50)]], [[Guide:95lrm/RM-A-5-3#I5449|A.5.3(53)]], [[Guide:95lrm/RM-A-5-3#I5454|A.5.3(59)]], [[Guide:95lrm/RM-A-5-3#I5459|A.5.3(62)]], [[Guide:95lrm/RM-A-15#I6020|A.15(14)]], [[Guide:95lrm/RM-B-3#I6168|B.3(53)]], [[Guide:95lrm/RM-B-3#I6169|B.3(54)]], [[Guide:95lrm/RM-B-4#I6324|B.4(58)]], [[Guide:95lrm/RM-E-4#I6781|E.4(19)]], [[Guide:95lrm/RM-G-1-1#I6916|G.1.1(40)]], [[Guide:95lrm/RM-G-1-2#I6968|G.1.2(28)]], [[Guide:95lrm/RM-G-2-1#I7005|G.2.1(12)]], [[Guide:95lrm/RM-G-2-2#I7014|G.2.2(7)]], [[Guide:95lrm/RM-G-2-3#I7023|G.2.3(26)]], [[Guide:95lrm/RM-G-2-4#I7028|G.2.4(3)]], [[Guide:95lrm/RM-G-2-6#I7035|G.2.6(4)]], [[Guide:95lrm/RM-K#I7104|K(11)]], [[Guide:95lrm/RM-K#I7117|K(114)]], [[Guide:95lrm/RM-K#I7120|K(122)]], [[Guide:95lrm/RM-K#I7123|K(184)]], [[Guide:95lrm/RM-K#I7128|K(202)]], [[Guide:95lrm/RM-K#I7132|K(220)]], [[Guide:95lrm/RM-K#I7135|K(241)]], [[Guide:95lrm/RM-K#I7141|K(261)]], [[Guide:95lrm/RM-K#I7109|K(41)]], [[Guide:95lrm/RM-K#I7112|K(47)]] ::''in'' Standard [[Guide:95lrm/RM-A-1#I4568|A.1(46)]] :Construct [[Guide:95lrm/RM-1-1-4#I1067|1.1.4(16)]], [[Guide:95lrm/RM-N#I7274|N(2)]] :constructor ::''See'' initialization [[Guide:95lrm/RM-3-3-1#I1435|3.3.1(19)]] ::''See'' initialization [[Guide:95lrm/RM-7-6#I3120|7.6(1)]] ::''See'' initialization expression [[Guide:95lrm/RM-3-3-1#I1419|3.3.1(4)]] ::''See'' Initialize [[Guide:95lrm/RM-7-6#I3121|7.6(1)]] ::''See'' initialized allocator [[Guide:95lrm/RM-4-8#I2726|4.8(4)]] :context free grammar ::complete listing [[Guide:95lrm/RM-P#I7287|P]] ::cross reference [[Guide:95lrm/RM-P#I7966|P]] ::notation [[Guide:95lrm/RM-1-1-4#I1062|1.1.4(3)]] ::under Syntax heading [[Guide:95lrm/RM-1-1-2#I1016|1.1.2(25)]] :context_clause [[Guide:95lrm/RM-10-1-2#I3718|10.1.2(2)]] ::''used'' [[Guide:95lrm/RM-10-1-1#I3680|10.1.1(3)]], [[Guide:95lrm/RM-P#I7826|P]] :context_item [[Guide:95lrm/RM-10-1-2#I3720|10.1.2(3)]] ::''used'' [[Guide:95lrm/RM-10-1-2#I3719|10.1.2(2)]], [[Guide:95lrm/RM-P#I7843|P]] :contiguous representation ::[''partial''] [[Guide:95lrm/RM-13-5-2#I4283|13.5.2(5)]], [[Guide:95lrm/RM-13-7-1#I4346|13.7.1(12)]], [[Guide:95lrm/RM-13-9#I4373|13.9(9)]], [[Guide:95lrm/RM-13-9#I4376|13.9(17)]], [[Guide:95lrm/RM-13-11#I4423|13.11(16)]] :Continue ::''in'' Ada.Asynchronous_Task_Control [[Guide:95lrm/RM-D-11#I6679|D.11(3)]] :control character ::a category of Character [[Guide:95lrm/RM-A-3-2#I4636|A.3.2(22)]] ::a category of Character [[Guide:95lrm/RM-A-3-3#I4649|A.3.3(4)]], [[Guide:95lrm/RM-A-3-3#I4743|A.3.3(15)]] ::''See also'' format_effector [[Guide:95lrm/RM-2-1#I1132|2.1(13)]] ::''See also'' other_control_function [[Guide:95lrm/RM-2-1#I1134|2.1(14)]] :Control_Set ::''in'' Ada.Strings.Maps.Constants [[Guide:95lrm/RM-A-4-6#I5192|A.4.6(4)]] :controlled ::aspect of representation [[Guide:95lrm/RM-13-11-3#I4457|13.11.3(5)]] ::''in'' Ada.Finalization [[Guide:95lrm/RM-7-6#I3131|7.6(5)]] :Controlled pragma [[Guide:95lrm/RM-13-11-3#I4452|13.11.3(3)]], [[Guide:95lrm/RM-L#I7161|L(7)]] :controlled type [[Guide:95lrm/RM-7-6#I3123|7.6(2)]], [[Guide:95lrm/RM-7-6#I3144|7.6(9)]] :controlling formal parameter [[Guide:95lrm/RM-3-9-2#I2017|3.9.2(2)]] :controlling operand [[Guide:95lrm/RM-3-9-2#I2016|3.9.2(2)]] :controlling result [[Guide:95lrm/RM-3-9-2#I2018|3.9.2(2)]] :controlling tag ::for a call on a dispatching operation [[Guide:95lrm/RM-3-9-2#I2008|3.9.2(1)]] :controlling tag value [[Guide:95lrm/RM-3-9-2#I2025|3.9.2(14)]] ::for the expression in an assignment_statement [[Guide:95lrm/RM-5-2#I2811|5.2(9)]] :convention [[Guide:95lrm/RM-6-3-1#I2962|6.3.1(2/1)]], [[Guide:95lrm/RM-B-1#I6055|B.1(11)]] ::aspect of representation [[Guide:95lrm/RM-B-1#I6069|B.1(28)]] :Convention pragma [[Guide:95lrm/RM-B-1#I6047|B.1(7)]], [[Guide:95lrm/RM-L#I7164|L(8)]] :conversion [[Guide:95lrm/RM-4-6#I2606|4.6(1)]], [[Guide:95lrm/RM-4-6#I2649|4.6(28)]] ::access [[Guide:95lrm/RM-4-6#I2632|4.6(13)]], [[Guide:95lrm/RM-4-6#I2638|4.6(18)]], [[Guide:95lrm/RM-4-6#I2676|4.6(47)]] ::arbitrary order [[Guide:95lrm/RM-1-1-4#I1071|1.1.4(18)]] ::array [[Guide:95lrm/RM-4-6#I2628|4.6(9)]], [[Guide:95lrm/RM-4-6#I2659|4.6(36)]] ::composite (non-array) [[Guide:95lrm/RM-4-6#I2645|4.6(21)]], [[Guide:95lrm/RM-4-6#I2666|4.6(40)]] ::enumeration [[Guide:95lrm/RM-4-6#I2643|4.6(21)]], [[Guide:95lrm/RM-4-6#I2657|4.6(34)]] ::numeric [[Guide:95lrm/RM-4-6#I2626|4.6(8)]], [[Guide:95lrm/RM-4-6#I2654|4.6(29)]] ::unchecked [[Guide:95lrm/RM-13-9#I4367|13.9(1)]] ::value [[Guide:95lrm/RM-4-6#I2622|4.6(5/1)]] ::view [[Guide:95lrm/RM-4-6#I2620|4.6(5/1)]] :Conversion_Error ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6291|B.4(30)]] :convertible [[Guide:95lrm/RM-4-6#I2618|4.6(4)]] ::required [[Guide:95lrm/RM-3-7#I1857|3.7(16)]], [[Guide:95lrm/RM-3-7-1#I1883|3.7.1(9)]], [[Guide:95lrm/RM-4-6#I2629|4.6(11/1)]], [[Guide:95lrm/RM-4-6#I2633|4.6(15)]], [[Guide:95lrm/RM-6-4-1#I3020|6.4.1(6)]] :copy back of parameters [[Guide:95lrm/RM-6-4-1#I3028|6.4.1(17)]] :copy parameter passing [[Guide:95lrm/RM-6-2#I2936|6.2(2)]] :Copy_Array ::''in'' Interfaces.C.Pointers [[Guide:95lrm/RM-B-3-2#I6229|B.3.2(15)]] :Copy_Sign attribute [[Guide:95lrm/RM-A-5-3#I5448|A.5.3(51)]] :Copy_Terminated_Array ::''in'' Interfaces.C.Pointers [[Guide:95lrm/RM-B-3-2#I6227|B.3.2(14)]] :Copyright_Sign ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4790|A.3.3(21)]] :core language [[Guide:95lrm/RM-1-1-2#I1005|1.1.2(2)]] :corresponding constraint [[Guide:95lrm/RM-3-4#I1455|3.4(6)]] :corresponding discriminants [[Guide:95lrm/RM-3-7#I1858|3.7(18)]] :corresponding index ::for an array_aggregate [[Guide:95lrm/RM-4-3-3#I2321|4.3.3(8)]] :corresponding subtype [[Guide:95lrm/RM-3-4#I1464|3.4(18)]] :corresponding value ::of the target type of a conversion [[Guide:95lrm/RM-4-6#I2648|4.6(28)]] :Cos ::''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6933|G.1.2(4)]] ::''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5284|A.5.1(5)]] :Cosh ::''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6949|G.1.2(6)]] ::''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5312|A.5.1(7)]] :Cot ::''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6937|G.1.2(4)]] ::''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5292|A.5.1(5)]] :Coth ::''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6953|G.1.2(6)]] ::''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5316|A.5.1(7)]] :Count ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5551|A.8.4(4)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5924|A.12.1(7)]] ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5050|A.4.4(48)]], [[Guide:95lrm/RM-A-4-4#I5052|A.4.4(49)]], [[Guide:95lrm/RM-A-4-4#I5054|A.4.4(50)]] ::''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4955|A.4.3(13)]], [[Guide:95lrm/RM-A-4-3#I4957|A.4.3(14)]], [[Guide:95lrm/RM-A-4-3#I4959|A.4.3(15)]] ::''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5142|A.4.5(43)]], [[Guide:95lrm/RM-A-4-5#I5144|A.4.5(44)]], [[Guide:95lrm/RM-A-4-5#I5146|A.4.5(45)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5627|A.10.1(5)]] :Count attribute [[Guide:95lrm/RM-9-9#I3660|9.9(5)]] :cover ::a type [[Guide:95lrm/RM-3-4-1#I1482|3.4.1(9)]] ::of a choice and an exception [[Guide:95lrm/RM-11-2#I3863|11.2(6)]] :cover a value ::by a discrete_choice [[Guide:95lrm/RM-3-8-1#I1939|3.8.1(9)]] ::by a discrete_choice_list [[Guide:95lrm/RM-3-8-1#I1940|3.8.1(13)]] :CR ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4663|A.3.3(5)]] :create [[Guide:95lrm/RM-3-1#I1295|3.1(12)]] ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5554|A.8.4(6)]] ::''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5511|A.8.1(6)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5927|A.12.1(8)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5635|A.10.1(9)]] :creation ::of a protected object [[Guide:95lrm/RM-C-3-1#I6390|C.3.1(10)]] ::of a task object [[Guide:95lrm/RM-D-1#I6524|D.1(17)]] ::of an object [[Guide:95lrm/RM-3-3#I1383|3.3(1)]] :critical section ::''See'' intertask communication [[Guide:95lrm/RM-9-5#I3413|9.5(1)]] :CSI ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4775|A.3.3(19)]] :Currency_Sign ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4785|A.3.3(21)]] :current column number [[Guide:95lrm/RM-A-10#I5614|A.10(9)]] :current index ::of an open direct file [[Guide:95lrm/RM-A-8#I5502|A.8(4)]] ::of an open stream file [[Guide:95lrm/RM-A-12-1#I5912|A.12.1(1.1/1)]] :current instance ::of a generic unit [[Guide:95lrm/RM-8-6#I3292|8.6(18)]] ::of a type [[Guide:95lrm/RM-8-6#I3291|8.6(17)]] :current line number [[Guide:95lrm/RM-A-10#I5615|A.10(9)]] :current mode ::of an open file [[Guide:95lrm/RM-A-7#I5493|A.7(7)]] :current page number [[Guide:95lrm/RM-A-10#I5616|A.10(9)]] :Current size ::of a stream file [[Guide:95lrm/RM-A-12-1#I5913|A.12.1(1.1/1)]] ::of an external file [[Guide:95lrm/RM-A-8#I5501|A.8(3)]] :Current_Error ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5671|A.10.1(17)]], [[Guide:95lrm/RM-A-10-1#I5685|A.10.1(20)]] :Current_Handler ::''in'' Ada.Interrupts [[Guide:95lrm/RM-C-3-2#I6415|C.3.2(6)]] :Current_Input ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5667|A.10.1(17)]], [[Guide:95lrm/RM-A-10-1#I5681|A.10.1(20)]] :Current_Output ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5669|A.10.1(17)]], [[Guide:95lrm/RM-A-10-1#I5683|A.10.1(20)]] :Current_State ::''in'' Ada.Synchronous_Task_Control [[Guide:95lrm/RM-D-10#I6667|D.10(4)]] :Current_Task ::''in'' Ada.Task_Identification [[Guide:95lrm/RM-C-7-1#I6473|C.7.1(3/1)]] == D == :dangling references ::prevention via accessibility rules [[Guide:95lrm/RM-3-10-2#I2101|3.10.2(3)]] :Data_Error ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5595|A.8.4(18)]] ::''in'' Ada.IO_Exceptions [[Guide:95lrm/RM-A-13#I5999|A.13(4)]] ::''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5542|A.8.1(15)]] ::''in'' Ada.Storage_IO [[Guide:95lrm/RM-A-9#I5605|A.9(9)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5974|A.12.1(26)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5889|A.10.1(85)]] :Day ::''in'' Ada.Calendar [[Guide:95lrm/RM-9-6#I3553|9.6(13)]] :Day_Duration ::''in'' Ada.Calendar [[Guide:95lrm/RM-9-6#I3545|9.6(11)]] :Day_Number ::''in'' Ada.Calendar [[Guide:95lrm/RM-9-6#I3544|9.6(11)]] :DC1 ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4667|A.3.3(6)]] :DC2 ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4668|A.3.3(6)]] :DC3 ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4669|A.3.3(6)]] :DC4 ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4670|A.3.3(6)]] :DCS ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4764|A.3.3(18)]] :Deallocate ::''in'' System.Storage_Pools [[Guide:95lrm/RM-13-11#I4407|13.11(8)]] :deallocation of storage [[Guide:95lrm/RM-13-11-2#I4436|13.11.2(1)]] :Decimal ::''child of'' Ada [[Guide:95lrm/RM-F-2#I6818|F.2(2)]] :decimal digit ::a category of Character [[Guide:95lrm/RM-A-3-2#I4642|A.3.2(28)]] :decimal fixed point type [[Guide:95lrm/RM-3-5-9#I1706|3.5.9(1)]], [[Guide:95lrm/RM-3-5-9#I1724|3.5.9(6)]] :Decimal_Digit_Set ::''in'' Ada.Strings.Maps.Constants [[Guide:95lrm/RM-A-4-6#I5198|A.4.6(4)]] :Decimal_Element ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6252|B.4(12)]] :decimal_fixed_point_definition [[Guide:95lrm/RM-3-5-9#I1714|3.5.9(4)]] ::''used'' [[Guide:95lrm/RM-3-5-9#I1710|3.5.9(2)]], [[Guide:95lrm/RM-P#I7407|P]] :Decimal_IO ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5852|A.10.1(73)]] :decimal_literal [[Guide:95lrm/RM-2-4-1#I1190|2.4.1(2)]] ::''used'' [[Guide:95lrm/RM-2-4#I1187|2.4(2)]], [[Guide:95lrm/RM-P#I7302|P]] :Decimal_Output ::''in'' Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6851|F.3.3(11)]] :Declaration [[Guide:95lrm/RM-3-1#I1279|3.1(5)]], [[Guide:95lrm/RM-3-1#I1282|3.1(6)]] :declarative region ::of a construct [[Guide:95lrm/RM-8-1#I3174|8.1(1)]] :declarative_item [[Guide:95lrm/RM-3-11#I2130|3.11(3)]] ::''used'' [[Guide:95lrm/RM-3-11#I2129|3.11(2)]], [[Guide:95lrm/RM-P#I7477|P]] :declarative_part [[Guide:95lrm/RM-3-11#I2128|3.11(2)]] ::''used'' [[Guide:95lrm/RM-5-6#I2862|5.6(2)]], [[Guide:95lrm/RM-6-3#I2951|6.3(2)]], [[Guide:95lrm/RM-7-2#I3072|7.2(2)]], [[Guide:95lrm/RM-9-1#I3340|9.1(6)]], [[Guide:95lrm/RM-9-5-2#I3449|9.5.2(5)]], [[Guide:95lrm/RM-P#I7743|P]] :declare [[Guide:95lrm/RM-3-1#I1288|3.1(8)]], [[Guide:95lrm/RM-3-1#I1294|3.1(12)]] :declared pure [[Guide:95lrm/RM-10-2-1#I3814|10.2.1(17)]] :Decrement ::''in'' Interfaces.C.Pointers [[Guide:95lrm/RM-B-3-2#I6223|B.3.2(11)]] :deeper ::accessibility level [[Guide:95lrm/RM-3-10-2#I2099|3.10.2(3)]] ::statically [[Guide:95lrm/RM-3-10-2#I2104|3.10.2(4)]], [[Guide:95lrm/RM-3-10-2#I2106|3.10.2(17)]] :default entry queuing policy [[Guide:95lrm/RM-9-5-3#I3504|9.5.3(17)]] :default treatment [[Guide:95lrm/RM-C-3#I6382|C.3(5)]] :Default_Aft ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5822|A.10.1(64)]], [[Guide:95lrm/RM-A-10-1#I5838|A.10.1(69)]], [[Guide:95lrm/RM-A-10-1#I5854|A.10.1(74)]] ::''in'' Ada.Text_IO.Complex_IO [[Guide:95lrm/RM-G-1-3#I6977|G.1.3(5)]] :Default_Base ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5792|A.10.1(53)]], [[Guide:95lrm/RM-A-10-1#I5807|A.10.1(58)]] :Default_Bit_Order ::''in'' System [[Guide:95lrm/RM-13-7#I4323|13.7(15)]] :Default_Currency ::''in'' Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6847|F.3.3(10)]] :Default_Exp ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5823|A.10.1(64)]], [[Guide:95lrm/RM-A-10-1#I5839|A.10.1(69)]], [[Guide:95lrm/RM-A-10-1#I5855|A.10.1(74)]] ::''in'' Ada.Text_IO.Complex_IO [[Guide:95lrm/RM-G-1-3#I6978|G.1.3(5)]] :default_expression [[Guide:95lrm/RM-3-7#I1852|3.7(6)]] ::''used'' [[Guide:95lrm/RM-3-7#I1848|3.7(5)]], [[Guide:95lrm/RM-3-8#I1909|3.8(6)]], [[Guide:95lrm/RM-6-1#I2916|6.1(15)]], [[Guide:95lrm/RM-12-4#I4036|12.4(2)]], [[Guide:95lrm/RM-P#I7437|P]] :Default_Fill ::''in'' Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6848|F.3.3(10)]] :Default_Fore ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5821|A.10.1(64)]], [[Guide:95lrm/RM-A-10-1#I5837|A.10.1(69)]], [[Guide:95lrm/RM-A-10-1#I5853|A.10.1(74)]] ::''in'' Ada.Text_IO.Complex_IO [[Guide:95lrm/RM-G-1-3#I6976|G.1.3(5)]] :default_name [[Guide:95lrm/RM-12-6#I4098|12.6(4)]] ::''used'' [[Guide:95lrm/RM-12-6#I4097|12.6(3)]], [[Guide:95lrm/RM-P#I7922|P]] :Default_Priority ::''in'' System [[Guide:95lrm/RM-13-7#I4327|13.7(17)]] :Default_Radix_Mark ::''in'' Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6850|F.3.3(10)]] :Default_Separator ::''in'' Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6849|F.3.3(10)]] :Default_Setting ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5870|A.10.1(80)]] :Default_Width ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5791|A.10.1(53)]], [[Guide:95lrm/RM-A-10-1#I5806|A.10.1(58)]], [[Guide:95lrm/RM-A-10-1#I5869|A.10.1(80)]] :deferred constant [[Guide:95lrm/RM-7-4#I3108|7.4(2)]] :deferred constant declaration [[Guide:95lrm/RM-3-3-1#I1421|3.3.1(6)]], [[Guide:95lrm/RM-7-4#I3107|7.4(2)]] :defining name [[Guide:95lrm/RM-3-1#I1289|3.1(10)]] :defining_character_literal [[Guide:95lrm/RM-3-5-1#I1579|3.5.1(4)]] ::''used'' [[Guide:95lrm/RM-3-5-1#I1578|3.5.1(3)]], [[Guide:95lrm/RM-P#I7393|P]] :defining_designator [[Guide:95lrm/RM-6-1#I2894|6.1(6)]] ::''used'' [[Guide:95lrm/RM-6-1#I2888|6.1(4)]], [[Guide:95lrm/RM-12-3#I3998|12.3(2)]], [[Guide:95lrm/RM-P#I7887|P]] :defining_identifier [[Guide:95lrm/RM-3-1#I1277|3.1(4)]] ::''used'' [[Guide:95lrm/RM-3-2-1#I1329|3.2.1(3)]], [[Guide:95lrm/RM-3-2-2#I1353|3.2.2(2)]], [[Guide:95lrm/RM-3-3-1#I1415|3.3.1(3)]], [[Guide:95lrm/RM-3-5-1#I1577|3.5.1(3)]], [[Guide:95lrm/RM-3-10-1#I2088|3.10.1(2)]], [[Guide:95lrm/RM-5-5#I2851|5.5(4)]], [[Guide:95lrm/RM-6-1#I2899|6.1(7)]], [[Guide:95lrm/RM-7-3#I3084|7.3(2)]], [[Guide:95lrm/RM-7-3#I3087|7.3(3)]], [[Guide:95lrm/RM-8-5-1#I3251|8.5.1(2)]], [[Guide:95lrm/RM-8-5-2#I3255|8.5.2(2)]], [[Guide:95lrm/RM-9-1#I3325|9.1(2)]], [[Guide:95lrm/RM-9-1#I3329|9.1(3)]], [[Guide:95lrm/RM-9-1#I3339|9.1(6)]], [[Guide:95lrm/RM-9-4#I3375|9.4(2)]], [[Guide:95lrm/RM-9-4#I3379|9.4(3)]], [[Guide:95lrm/RM-9-4#I3393|9.4(7)]], [[Guide:95lrm/RM-9-5-2#I3434|9.5.2(2)]], [[Guide:95lrm/RM-9-5-2#I3446|9.5.2(5)]], [[Guide:95lrm/RM-9-5-2#I3458|9.5.2(8)]], [[Guide:95lrm/RM-10-1-3#I3737|10.1.3(4)]], [[Guide:95lrm/RM-10-1-3#I3739|10.1.3(5)]], [[Guide:95lrm/RM-10-1-3#I3741|10.1.3(6)]], [[Guide:95lrm/RM-11-2#I3860|11.2(4)]], [[Guide:95lrm/RM-12-5#I4046|12.5(2)]], [[Guide:95lrm/RM-12-7#I4107|12.7(2)]], [[Guide:95lrm/RM-P#I7732|P]] :defining_identifier_list [[Guide:95lrm/RM-3-3-1#I1414|3.3.1(3)]] ::''used'' [[Guide:95lrm/RM-3-3-1#I1409|3.3.1(2)]], [[Guide:95lrm/RM-3-3-2#I1440|3.3.2(2)]], [[Guide:95lrm/RM-3-7#I1846|3.7(5)]], [[Guide:95lrm/RM-3-8#I1907|3.8(6)]], [[Guide:95lrm/RM-6-1#I2917|6.1(15)]], [[Guide:95lrm/RM-11-1#I3839|11.1(2)]], [[Guide:95lrm/RM-12-4#I4033|12.4(2)]], [[Guide:95lrm/RM-P#I7382|P]] :defining_operator_symbol [[Guide:95lrm/RM-6-1#I2902|6.1(11)]] ::''used'' [[Guide:95lrm/RM-6-1#I2896|6.1(6)]], [[Guide:95lrm/RM-P#I7656|P]] :defining_program_unit_name [[Guide:95lrm/RM-6-1#I2897|6.1(7)]] ::''used'' [[Guide:95lrm/RM-6-1#I2886|6.1(4)]], [[Guide:95lrm/RM-6-1#I2895|6.1(6)]], [[Guide:95lrm/RM-7-1#I3060|7.1(3)]], [[Guide:95lrm/RM-7-2#I3071|7.2(2)]], [[Guide:95lrm/RM-8-5-3#I3258|8.5.3(2)]], [[Guide:95lrm/RM-8-5-5#I3273|8.5.5(2)]], [[Guide:95lrm/RM-12-3#I3992|12.3(2)]], [[Guide:95lrm/RM-P#I7655|P]] :Definite attribute [[Guide:95lrm/RM-12-5-1#I4076|12.5.1(23)]] :definite subtype [[Guide:95lrm/RM-3-3#I1397|3.3(23)]] :Definition [[Guide:95lrm/RM-3-1#I1283|3.1(7)]] :Degree_Sign ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4797|A.3.3(22)]] :DEL ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4742|A.3.3(14)]] :delay_alternative [[Guide:95lrm/RM-9-7-1#I3592|9.7.1(6)]] ::''used'' [[Guide:95lrm/RM-9-7-1#I3587|9.7.1(4)]], [[Guide:95lrm/RM-9-7-2#I3604|9.7.2(2)]], [[Guide:95lrm/RM-P#I7811|P]] :delay_relative_statement [[Guide:95lrm/RM-9-6#I3530|9.6(4)]] ::''used'' [[Guide:95lrm/RM-9-6#I3527|9.6(2)]], [[Guide:95lrm/RM-P#I7790|P]] :delay_statement [[Guide:95lrm/RM-9-6#I3525|9.6(2)]] ::''used'' [[Guide:95lrm/RM-5-1#I2782|5.1(4)]], [[Guide:95lrm/RM-9-7-1#I3593|9.7.1(6)]], [[Guide:95lrm/RM-9-7-4#I3621|9.7.4(4)]], [[Guide:95lrm/RM-P#I7821|P]] :delay_until_statement [[Guide:95lrm/RM-9-6#I3528|9.6(3)]] ::''used'' [[Guide:95lrm/RM-9-6#I3526|9.6(2)]], [[Guide:95lrm/RM-P#I7789|P]] :Delete ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5560|A.8.4(8)]] ::''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5517|A.8.1(8)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5933|A.12.1(10)]] ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5078|A.4.4(64)]], [[Guide:95lrm/RM-A-4-4#I5080|A.4.4(65)]] ::''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4983|A.4.3(29)]], [[Guide:95lrm/RM-A-4-3#I4985|A.4.3(30)]] ::''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5170|A.4.5(59)]], [[Guide:95lrm/RM-A-4-5#I5172|A.4.5(60)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5641|A.10.1(11)]] :delimiter [[Guide:95lrm/RM-2-2#I1173|2.2(8)]] :delivery ::of an interrupt [[Guide:95lrm/RM-C-3#I6376|C.3(2)]] :delta ::of a fixed point type [[Guide:95lrm/RM-3-5-9#I1707|3.5.9(1)]] :Delta attribute [[Guide:95lrm/RM-3-5-10#I1747|3.5.10(3)]] :delta_constraint [[Guide:95lrm/RM-J-3#I7077|J.3(2)]] ::''used'' [[Guide:95lrm/RM-3-2-2#I1366|3.2.2(6)]], [[Guide:95lrm/RM-P#I7369|P]] :Denorm attribute [[Guide:95lrm/RM-A-5-3#I5400|A.5.3(9)]] :denormalized number [[Guide:95lrm/RM-A-5-3#I5401|A.5.3(10)]] :denote [[Guide:95lrm/RM-8-6#I3290|8.6(16)]] ::informal definition [[Guide:95lrm/RM-3-1#I1287|3.1(8)]] ::name used as a pragma argument [[Guide:95lrm/RM-8-6#I3304|8.6(32)]] :depend on a discriminant ::for a component [[Guide:95lrm/RM-3-7#I1861|3.7(20)]] ::for a constraint or component_definition [[Guide:95lrm/RM-3-7#I1860|3.7(19)]] :dependence ::elaboration [[Guide:95lrm/RM-10-2#I3789|10.2(9)]] ::of a task on a master [[Guide:95lrm/RM-9-3#I3360|9.3(1)]] ::of a task on another task [[Guide:95lrm/RM-9-3#I3364|9.3(4)]] ::semantic [[Guide:95lrm/RM-10-1-1#I3717|10.1.1(26)]] :depth ::accessibility level [[Guide:95lrm/RM-3-10-2#I2100|3.10.2(3)]] :dereference [[Guide:95lrm/RM-4-1#I2176|4.1(8)]] :Dereference_Error ::''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6189|B.3.1(12)]] :derivation class ::for a type [[Guide:95lrm/RM-3-4-1#I1473|3.4.1(2)]] :derived from ::directly or indirectly [[Guide:95lrm/RM-3-4-1#I1472|3.4.1(2)]] :derived type [[Guide:95lrm/RM-3-4#I1445|3.4(1)]] ::[''partial''] [[Guide:95lrm/RM-3-4#I1466|3.4(24)]] :derived_type_definition [[Guide:95lrm/RM-3-4#I1447|3.4(2)]] ::''used'' [[Guide:95lrm/RM-3-2-1#I1341|3.2.1(4)]], [[Guide:95lrm/RM-P#I7359|P]] :descendant [[Guide:95lrm/RM-10-1-1#I3709|10.1.1(11)]] ::of a type [[Guide:95lrm/RM-3-4-1#I1483|3.4.1(10)]] ::relationship with scope [[Guide:95lrm/RM-8-2#I3183|8.2(4)]] :designate [[Guide:95lrm/RM-3-10#I2043|3.10(1)]] :designated profile ::of an access-to-subprogram type [[Guide:95lrm/RM-3-10#I2075|3.10(11)]] :designated subtype ::of a named access type [[Guide:95lrm/RM-3-10#I2070|3.10(10)]] ::of an anonymous access type [[Guide:95lrm/RM-3-10#I2078|3.10(12)]] :designated type ::of a named access type [[Guide:95lrm/RM-3-10#I2071|3.10(10)]] ::of an anonymous access type [[Guide:95lrm/RM-3-10#I2079|3.10(12)]] :designator [[Guide:95lrm/RM-6-1#I2890|6.1(5)]] ::''used'' [[Guide:95lrm/RM-6-3#I2953|6.3(2)]], [[Guide:95lrm/RM-P#I7676|P]] :destructor ::''See'' finalization [[Guide:95lrm/RM-7-6#I3122|7.6(1)]] ::''See'' finalization [[Guide:95lrm/RM-7-6-1#I3153|7.6.1(1)]] :Detach_Handler ::''in'' Ada.Interrupts [[Guide:95lrm/RM-C-3-2#I6421|C.3.2(9)]] :determined class for a formal type [[Guide:95lrm/RM-12-5#I4068|12.5(6)]] :determines ::a type by a subtype_mark [[Guide:95lrm/RM-3-2-2#I1370|3.2.2(8)]] :Device_Error ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5593|A.8.4(18)]] ::''in'' Ada.IO_Exceptions [[Guide:95lrm/RM-A-13#I5997|A.13(4)]] ::''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5540|A.8.1(15)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5972|A.12.1(26)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5887|A.10.1(85)]] :Diaeresis ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4789|A.3.3(21)]] :digit [[Guide:95lrm/RM-2-1#I1128|2.1(10)]] ::''used'' [[Guide:95lrm/RM-2-1#I1121|2.1(3)]], [[Guide:95lrm/RM-2-3#I1181|2.3(3)]], [[Guide:95lrm/RM-2-4-1#I1195|2.4.1(3)]], [[Guide:95lrm/RM-2-4-2#I1223|2.4.2(5)]], [[Guide:95lrm/RM-P#I7294|P]] :digits ::of a decimal fixed point subtype [[Guide:95lrm/RM-3-5-9#I1723|3.5.9(6)]], [[Guide:95lrm/RM-3-5-10#I1754|3.5.10(7)]] :Digits attribute [[Guide:95lrm/RM-3-5-8#I1702|3.5.8(2/1)]], [[Guide:95lrm/RM-3-5-10#I1753|3.5.10(7)]] :digits_constraint [[Guide:95lrm/RM-3-5-9#I1718|3.5.9(5)]] ::''used'' [[Guide:95lrm/RM-3-2-2#I1365|3.2.2(6)]], [[Guide:95lrm/RM-P#I7368|P]] :dimensionality ::of an array [[Guide:95lrm/RM-3-6#I1785|3.6(12)]] :direct access [[Guide:95lrm/RM-A-8#I5499|A.8(3)]] :direct file [[Guide:95lrm/RM-A-8#I5497|A.8(1)]] :Direct_IO ::''child of'' Ada [[Guide:95lrm/RM-A-8-4#I5543|A.8.4(2)]] :direct_name [[Guide:95lrm/RM-4-1#I2166|4.1(3)]] ::''used'' [[Guide:95lrm/RM-3-8-1#I1925|3.8.1(2)]], [[Guide:95lrm/RM-4-1#I2157|4.1(2)]], [[Guide:95lrm/RM-5-1#I2797|5.1(8)]], [[Guide:95lrm/RM-9-5-2#I3438|9.5.2(3)]], [[Guide:95lrm/RM-13-1#I4126|13.1(3)]], [[Guide:95lrm/RM-J-7#I7088|J.7(1)]], [[Guide:95lrm/RM-P#I7933|P]] :Direction ::''in'' Ada.Strings [[Guide:95lrm/RM-A-4-1#I4895|A.4.1(6)]] :directly specified ::of an aspect of representation of an entity [[Guide:95lrm/RM-13-1#I4136|13.1(8)]] ::of an operational aspect of an entity [[Guide:95lrm/RM-13-1#I4142|13.1(8.1/1)]] :directly visible [[Guide:95lrm/RM-8-3#I3195|8.3(2)]], [[Guide:95lrm/RM-8-3#I3216|8.3(21)]] ::within a pragma in a context_clause [[Guide:95lrm/RM-10-1-6#I3771|10.1.6(3)]] ::within a pragma that appears at the place of a compilation unit [[Guide:95lrm/RM-10-1-6#I3775|10.1.6(5)]] ::within a use_clause in a context_clause [[Guide:95lrm/RM-10-1-6#I3769|10.1.6(3)]] ::within a with_clause [[Guide:95lrm/RM-10-1-6#I3766|10.1.6(2)]] ::within the parent_unit_name of a library unit [[Guide:95lrm/RM-10-1-6#I3764|10.1.6(2)]] ::within the parent_unit_name of a subunit [[Guide:95lrm/RM-10-1-6#I3773|10.1.6(4)]] :Discard_Names pragma [[Guide:95lrm/RM-C-5#I6433|C.5(3)]], [[Guide:95lrm/RM-L#I7168|L(9)]] :discontiguous representation ::[''partial''] [[Guide:95lrm/RM-13-5-2#I4284|13.5.2(5)]], [[Guide:95lrm/RM-13-7-1#I4347|13.7.1(12)]], [[Guide:95lrm/RM-13-9#I4374|13.9(9)]], [[Guide:95lrm/RM-13-9#I4377|13.9(17)]], [[Guide:95lrm/RM-13-11#I4424|13.11(16)]] :discrete array type [[Guide:95lrm/RM-4-5-2#I2519|4.5.2(1)]] :discrete type [[Guide:95lrm/RM-3-2#I1306|3.2(3)]], [[Guide:95lrm/RM-3-5#I1489|3.5(1)]] :Discrete_Random ::''child of'' Ada.Numerics [[Guide:95lrm/RM-A-5-2#I5359|A.5.2(17)]] :discrete_choice [[Guide:95lrm/RM-3-8-1#I1934|3.8.1(5)]] ::''used'' [[Guide:95lrm/RM-3-8-1#I1933|3.8.1(4)]], [[Guide:95lrm/RM-P#I7464|P]] :discrete_choice_list [[Guide:95lrm/RM-3-8-1#I1931|3.8.1(4)]] ::''used'' [[Guide:95lrm/RM-3-8-1#I1929|3.8.1(3)]], [[Guide:95lrm/RM-4-3-3#I2313|4.3.3(5)]], [[Guide:95lrm/RM-5-4#I2834|5.4(3)]], [[Guide:95lrm/RM-P#I7461|P]] :discrete_range [[Guide:95lrm/RM-3-6-1#I1806|3.6.1(3)]] ::''used'' [[Guide:95lrm/RM-3-6-1#I1805|3.6.1(2)]], [[Guide:95lrm/RM-3-8-1#I1936|3.8.1(5)]], [[Guide:95lrm/RM-4-1-2#I2202|4.1.2(2)]], [[Guide:95lrm/RM-P#I7466|P]] :discrete_subtype_definition [[Guide:95lrm/RM-3-6#I1776|3.6(6)]] ::''used'' [[Guide:95lrm/RM-3-6#I1773|3.6(5)]], [[Guide:95lrm/RM-5-5#I2852|5.5(4)]], [[Guide:95lrm/RM-9-5-2#I3435|9.5.2(2)]], [[Guide:95lrm/RM-9-5-2#I3459|9.5.2(8)]], [[Guide:95lrm/RM-P#I7638|P]] :discriminant [[Guide:95lrm/RM-3-2#I1311|3.2(5)]], [[Guide:95lrm/RM-3-7#I1835|3.7(1)]] ::of a variant_part [[Guide:95lrm/RM-3-8-1#I1937|3.8.1(6)]] :discriminant_association [[Guide:95lrm/RM-3-7-1#I1874|3.7.1(3)]] ::''used'' [[Guide:95lrm/RM-3-7-1#I1873|3.7.1(2)]], [[Guide:95lrm/RM-P#I7442|P]] :Discriminant_Check [[Guide:95lrm/RM-11-5#I3929|11.5(12)]] ::[''partial''] [[Guide:95lrm/RM-4-1-3#I2219|4.1.3(15)]], [[Guide:95lrm/RM-4-3#I2263|4.3(6)]], [[Guide:95lrm/RM-4-3-2#I2296|4.3.2(8)]], [[Guide:95lrm/RM-4-6#I2669|4.6(43)]], [[Guide:95lrm/RM-4-6#I2671|4.6(45)]], [[Guide:95lrm/RM-4-6#I2683|4.6(51)]], [[Guide:95lrm/RM-4-6#I2692|4.6(52)]], [[Guide:95lrm/RM-4-7#I2711|4.7(4)]], [[Guide:95lrm/RM-4-8#I2737|4.8(10/1)]] :discriminant_constraint [[Guide:95lrm/RM-3-7-1#I1871|3.7.1(2)]] ::''used'' [[Guide:95lrm/RM-3-2-2#I1369|3.2.2(7)]], [[Guide:95lrm/RM-P#I7371|P]] :discriminant_part [[Guide:95lrm/RM-3-7#I1838|3.7(2)]] ::''used'' [[Guide:95lrm/RM-3-10-1#I2089|3.10.1(2)]], [[Guide:95lrm/RM-7-3#I3085|7.3(2)]], [[Guide:95lrm/RM-7-3#I3088|7.3(3)]], [[Guide:95lrm/RM-12-5#I4047|12.5(2)]], [[Guide:95lrm/RM-P#I7702|P]] :discriminant_specification [[Guide:95lrm/RM-3-7#I1845|3.7(5)]] ::''used'' [[Guide:95lrm/RM-3-7#I1843|3.7(4)]], [[Guide:95lrm/RM-P#I7434|P]] :discriminants ::known [[Guide:95lrm/RM-3-7#I1863|3.7(26)]] ::unknown [[Guide:95lrm/RM-3-7#I1867|3.7(26)]] :discriminated type [[Guide:95lrm/RM-3-7#I1855|3.7(8/1)]] :dispatching [[Guide:95lrm/RM-3-9#I1959|3.9(3)]] :dispatching call ::on a dispatching operation [[Guide:95lrm/RM-3-9-2#I2002|3.9.2(1)]] :dispatching operation [[Guide:95lrm/RM-3-9-2#I2001|3.9.2(1)]], [[Guide:95lrm/RM-3-9-2#I2015|3.9.2(2)]] ::[''partial''] [[Guide:95lrm/RM-3-9#I1944|3.9(1)]] :dispatching point [[Guide:95lrm/RM-D-2-1#I6530|D.2.1(4)]] ::[''partial''] [[Guide:95lrm/RM-D-2-1#I6541|D.2.1(8)]], [[Guide:95lrm/RM-D-2-2#I6553|D.2.2(12)]] :dispatching policy for tasks ::[''partial''] [[Guide:95lrm/RM-D-2-1#I6536|D.2.1(5)]] :dispatching, task [[Guide:95lrm/RM-D-2-1#I6528|D.2.1(4)]] :Display_Format ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6272|B.4(22)]] :displayed magnitude (of a decimal value) [[Guide:95lrm/RM-F-3-2#I6831|F.3.2(14)]] :disruption of an assignment [[Guide:95lrm/RM-9-8#I3651|9.8(21)]], [[Guide:95lrm/RM-13-9-1#I4381|13.9.1(5)]] ::[''partial''] [[Guide:95lrm/RM-11-6#I3959|11.6(6)]] :distinct access paths [[Guide:95lrm/RM-6-2#I2944|6.2(12)]] :distributed program [[Guide:95lrm/RM-E#I6691|E(3)]] :distributed system [[Guide:95lrm/RM-E#I6690|E(2)]] :distributed systems [[Guide:95lrm/RM-C#I6364|C(1)]] :divide [[Guide:95lrm/RM-2-1#I1154|2.1(15)]] ::''in'' Ada.Decimal [[Guide:95lrm/RM-F-2#I6827|F.2(6)]] :divide operator [[Guide:95lrm/RM-4-4#I2392|4.4(1)]], [[Guide:95lrm/RM-4-5-5#I2574|4.5.5(1)]] :Division_Check [[Guide:95lrm/RM-11-5#I3930|11.5(13)]] ::[''partial''] [[Guide:95lrm/RM-3-5-4#I1640|3.5.4(20)]], [[Guide:95lrm/RM-4-5-5#I2581|4.5.5(22)]], [[Guide:95lrm/RM-A-5-1#I5329|A.5.1(28)]], [[Guide:95lrm/RM-A-5-3#I5440|A.5.3(47)]], [[Guide:95lrm/RM-G-1-1#I6914|G.1.1(40)]], [[Guide:95lrm/RM-G-1-2#I6966|G.1.2(28)]], [[Guide:95lrm/RM-K#I7129|K(202)]] :Division_Sign ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4870|A.3.3(26)]] :DLE ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4666|A.3.3(6)]] :Do_APC ::''in'' System.RPC [[Guide:95lrm/RM-E-5#I6806|E.5(10)]] :Do_RPC ::''in'' System.RPC [[Guide:95lrm/RM-E-5#I6804|E.5(9)]] :documentation (required of an implementation) [[Guide:95lrm/RM-1-1-3#I1058|1.1.3(18)]], [[Guide:95lrm/RM-M#I7270|M(1)]] :documentation requirements [[Guide:95lrm/RM-1-1-2#I1044|1.1.2(34)]] :Dollar_Sign ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4686|A.3.3(8)]] :dot [[Guide:95lrm/RM-2-1#I1151|2.1(15)]] :dot selection ::''See'' selected_component [[Guide:95lrm/RM-4-1-3#I2209|4.1.3(1)]] :double ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6126|B.3(16)]] :Double_Precision ::''in'' Interfaces.Fortran [[Guide:95lrm/RM-B-5#I6335|B.5(6)]] :downward closure [[Guide:95lrm/RM-3-10-2#I2126|3.10.2(37)]] :drift rate [[Guide:95lrm/RM-D-8#I6652|D.8(41)]] :Duration ::''in'' Standard [[Guide:95lrm/RM-A-1#I4567|A.1(43)]] :dynamic binding ::''See'' dispatching operation [[Guide:95lrm/RM-3-9#I1946|3.9(1)]] :dynamic semantics [[Guide:95lrm/RM-1-1-2#I1035|1.1.2(30)]] :Dynamic_Priorities ::''child of'' Ada [[Guide:95lrm/RM-D-5#I6579|D.5(3)]] :dynamically determined tag [[Guide:95lrm/RM-3-9-2#I2005|3.9.2(1)]] :dynamically enclosing ::of one execution by another [[Guide:95lrm/RM-11-4#I3874|11.4(2)]] :dynamically tagged [[Guide:95lrm/RM-3-9-2#I2020|3.9.2(5)]] == E == :e ::''in'' Ada.Numerics [[Guide:95lrm/RM-A-5#I5265|A.5(3)]] :edited output [[Guide:95lrm/RM-F-3#I6828|F.3(1)]] :Editing ::''child of'' Ada.Text_IO [[Guide:95lrm/RM-F-3-3#I6832|F.3.3(3)]] ::''child of'' Ada.Wide_Text_IO [[Guide:95lrm/RM-F-3-4#I6865|F.3.4(1)]] :effect ::external [[Guide:95lrm/RM-1-1-3#I1052|1.1.3(8)]] :efficiency [[Guide:95lrm/RM-11-5#I3945|11.5(29)]], [[Guide:95lrm/RM-11-6#I3951|11.6(1)]] :Elaborate pragma [[Guide:95lrm/RM-10-2-1#I3816|10.2.1(20)]], [[Guide:95lrm/RM-L#I7171|L(10)]] :Elaborate_All pragma [[Guide:95lrm/RM-10-2-1#I3820|10.2.1(21)]], [[Guide:95lrm/RM-L#I7175|L(11)]] :Elaborate_Body pragma [[Guide:95lrm/RM-10-2-1#I3824|10.2.1(22)]], [[Guide:95lrm/RM-L#I7179|L(12)]] :elaborated [[Guide:95lrm/RM-3-11#I2146|3.11(8)]] :elaboration [[Guide:95lrm/RM-3-1#I1292|3.1(11)]], [[Guide:95lrm/RM-N#I7281|N(19)]] ::abstract_subprogram_declaration [[Guide:95lrm/RM-6-1#I2933|6.1(31)]] ::access_definition [[Guide:95lrm/RM-3-10#I2086|3.10(17)]] ::access_type_definition [[Guide:95lrm/RM-3-10#I2085|3.10(16)]] ::array_type_definition [[Guide:95lrm/RM-3-6#I1800|3.6(21)]] ::aspect_clause [[Guide:95lrm/RM-13-1#I4149|13.1(19/1)]] ::choice_parameter_specification [[Guide:95lrm/RM-11-4#I3881|11.4(7)]] ::component_declaration [[Guide:95lrm/RM-3-8#I1917|3.8(17)]] ::component_definition [[Guide:95lrm/RM-3-6#I1802|3.6(22/1)]], [[Guide:95lrm/RM-3-8#I1921|3.8(18/1)]] ::component_list [[Guide:95lrm/RM-3-8#I1916|3.8(17)]] ::declaration named by a pragma Import [[Guide:95lrm/RM-B-1#I6082|B.1(38)]] ::declarative_part [[Guide:95lrm/RM-3-11#I2145|3.11(7)]] ::deferred constant declaration [[Guide:95lrm/RM-7-4#I3111|7.4(10)]] ::delta_constraint [[Guide:95lrm/RM-J-3#I7084|J.3(11)]] ::derived_type_definition [[Guide:95lrm/RM-3-4#I1467|3.4(26)]] ::digits_constraint [[Guide:95lrm/RM-3-5-9#I1738|3.5.9(19)]] ::discrete_subtype_definition [[Guide:95lrm/RM-3-6#I1801|3.6(22/1)]] ::discriminant_constraint [[Guide:95lrm/RM-3-7-1#I1886|3.7.1(12)]] ::entry_declaration [[Guide:95lrm/RM-9-5-2#I3474|9.5.2(22/1)]] ::enumeration_type_definition [[Guide:95lrm/RM-3-5-1#I1584|3.5.1(10)]] ::exception_declaration [[Guide:95lrm/RM-11-1#I3845|11.1(5)]] ::fixed_point_definition [[Guide:95lrm/RM-3-5-9#I1736|3.5.9(17)]] ::floating_point_definition [[Guide:95lrm/RM-3-5-7#I1695|3.5.7(13)]] ::full type definition [[Guide:95lrm/RM-3-2-1#I1351|3.2.1(11)]] ::full_type_declaration [[Guide:95lrm/RM-3-2-1#I1350|3.2.1(11)]] ::generic body [[Guide:95lrm/RM-12-2#I3989|12.2(2)]] ::generic_declaration [[Guide:95lrm/RM-12-1#I3987|12.1(10)]] ::generic_instantiation [[Guide:95lrm/RM-12-3#I4028|12.3(20)]] ::incomplete_type_declaration [[Guide:95lrm/RM-3-10-1#I2093|3.10.1(12)]] ::index_constraint [[Guide:95lrm/RM-3-6-1#I1815|3.6.1(8)]] ::integer_type_definition [[Guide:95lrm/RM-3-5-4#I1636|3.5.4(18)]] ::loop_parameter_specification [[Guide:95lrm/RM-5-5#I2858|5.5(9)]] ::non-generic subprogram_body [[Guide:95lrm/RM-6-3#I2955|6.3(6)]] ::nongeneric package_body [[Guide:95lrm/RM-7-2#I3077|7.2(6)]] ::number_declaration [[Guide:95lrm/RM-3-3-2#I1444|3.3.2(7)]] ::object_declaration [[Guide:95lrm/RM-3-3-1#I1431|3.3.1(15)]], [[Guide:95lrm/RM-7-6#I3145|7.6(10)]] ::of library units for a foreign language main subprogram [[Guide:95lrm/RM-B-1#I6086|B.1(39)]] ::package_body of Standard [[Guide:95lrm/RM-A-1#I4572|A.1(50)]] ::package_declaration [[Guide:95lrm/RM-7-1#I3069|7.1(8)]] ::partition [[Guide:95lrm/RM-E-1#I6696|E.1(6)]] ::partition [[Guide:95lrm/RM-E-5#I6811|E.5(21)]] ::per-object constraint [[Guide:95lrm/RM-3-8#I1922|3.8(18.1/1)]] ::pragma [[Guide:95lrm/RM-2-8#I1253|2.8(12)]] ::private_extension_declaration [[Guide:95lrm/RM-7-3#I3100|7.3(17)]] ::private_type_declaration [[Guide:95lrm/RM-7-3#I3099|7.3(17)]] ::protected declaration [[Guide:95lrm/RM-9-4#I3404|9.4(12)]] ::protected_body [[Guide:95lrm/RM-9-4#I3408|9.4(15)]] ::protected_definition [[Guide:95lrm/RM-9-4#I3406|9.4(13)]] ::range_constraint [[Guide:95lrm/RM-3-5#I1514|3.5(9)]] ::real_type_definition [[Guide:95lrm/RM-3-5-6#I1671|3.5.6(5)]] ::record_definition [[Guide:95lrm/RM-3-8#I1915|3.8(16)]] ::record_extension_part [[Guide:95lrm/RM-3-9-1#I2000|3.9.1(5)]] ::record_type_definition [[Guide:95lrm/RM-3-8#I1914|3.8(16)]] ::renaming_declaration [[Guide:95lrm/RM-8-5#I3247|8.5(3)]] ::single_protected_declaration [[Guide:95lrm/RM-9-4#I3405|9.4(12)]] ::single_task_declaration [[Guide:95lrm/RM-9-1#I3347|9.1(10)]] ::Storage_Size pragma [[Guide:95lrm/RM-13-3#I4226|13.3(66)]] ::subprogram_declaration [[Guide:95lrm/RM-6-1#I2932|6.1(31)]] ::subtype_declaration [[Guide:95lrm/RM-3-2-2#I1371|3.2.2(9)]] ::subtype_indication [[Guide:95lrm/RM-3-2-2#I1372|3.2.2(9)]] ::task declaration [[Guide:95lrm/RM-9-1#I3346|9.1(10)]] ::task_body [[Guide:95lrm/RM-9-1#I3350|9.1(13)]] ::task_definition [[Guide:95lrm/RM-9-1#I3348|9.1(11)]] ::use_clause [[Guide:95lrm/RM-8-4#I3240|8.4(12)]] ::variant_part [[Guide:95lrm/RM-3-8-1#I1943|3.8.1(22)]] :elaboration control [[Guide:95lrm/RM-10-2-1#I3797|10.2.1(1)]] :elaboration dependence ::library_item on another [[Guide:95lrm/RM-10-2#I3788|10.2(9)]] :Elaboration_Check [[Guide:95lrm/RM-11-5#I3937|11.5(20)]] ::[''partial''] [[Guide:95lrm/RM-3-11#I2147|3.11(9)]] :element ::of a storage pool [[Guide:95lrm/RM-13-11#I4414|13.11(11)]] ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5036|A.4.4(26)]] ::''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5128|A.4.5(20)]] :elementary type [[Guide:95lrm/RM-3-2#I1301|3.2(2)]] :Elementary_Functions ::''child of'' Ada.Numerics [[Guide:95lrm/RM-A-5-1#I5326|A.5.1(9/1)]] :eligible ::a type, for a convention [[Guide:95lrm/RM-B-1#I6058|B.1(14)]] :else part ::of a selective_accept [[Guide:95lrm/RM-9-7-1#I3596|9.7.1(11)]] :EM ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4675|A.3.3(6)]] :embedded systems [[Guide:95lrm/RM-C#I6363|C(1)]], [[Guide:95lrm/RM-D#I6510|D(1)]] :encapsulation ::''See'' package [[Guide:95lrm/RM-7#I3054|7(1)]] :enclosing ::immediately [[Guide:95lrm/RM-8-1#I3179|8.1(13)]] :end of a line [[Guide:95lrm/RM-2-2#I1171|2.2(2)]] :End_Error ::raised by failure of run-time check [[Guide:95lrm/RM-13-13-2#I4508|13.13.2(35.1/1)]] ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5594|A.8.4(18)]] ::''in'' Ada.IO_Exceptions [[Guide:95lrm/RM-A-13#I5998|A.13(4)]] ::''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5541|A.8.1(15)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5973|A.12.1(26)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5888|A.10.1(85)]] :End_Of_File ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5588|A.8.4(16)]] ::''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5535|A.8.1(13)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5947|A.12.1(12)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5731|A.10.1(34)]] :End_Of_Line ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5717|A.10.1(30)]] :End_Of_Page ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5727|A.10.1(33)]] :endian ::big [[Guide:95lrm/RM-13-5-3#I4288|13.5.3(2)]] ::little [[Guide:95lrm/RM-13-5-3#I4291|13.5.3(2)]] :ENQ ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4655|A.3.3(5)]] :entity ::[''partial''] [[Guide:95lrm/RM-3-1#I1263|3.1(1)]] :entry ::closed [[Guide:95lrm/RM-9-5-3#I3490|9.5.3(5)]] ::open [[Guide:95lrm/RM-9-5-3#I3488|9.5.3(5)]] ::single [[Guide:95lrm/RM-9-5-2#I3472|9.5.2(20)]] :entry call [[Guide:95lrm/RM-9-5-3#I3481|9.5.3(1)]] ::simple [[Guide:95lrm/RM-9-5-3#I3483|9.5.3(1)]] :entry calling convention [[Guide:95lrm/RM-6-3-1#I2970|6.3.1(13)]] :entry family [[Guide:95lrm/RM-9-5-2#I3469|9.5.2(20)]] :entry index subtype [[Guide:95lrm/RM-3-8#I1920|3.8(18/1)]], [[Guide:95lrm/RM-9-5-2#I3470|9.5.2(20)]] :entry queue [[Guide:95lrm/RM-9-5-3#I3499|9.5.3(12)]] :entry queuing policy [[Guide:95lrm/RM-9-5-3#I3503|9.5.3(17)]] ::default policy [[Guide:95lrm/RM-9-5-3#I3505|9.5.3(17)]] :entry_barrier [[Guide:95lrm/RM-9-5-2#I3455|9.5.2(7)]] ::''used'' [[Guide:95lrm/RM-9-5-2#I3448|9.5.2(5)]], [[Guide:95lrm/RM-P#I7777|P]] :entry_body [[Guide:95lrm/RM-9-5-2#I3445|9.5.2(5)]] ::''used'' [[Guide:95lrm/RM-9-4#I3399|9.4(8/1)]], [[Guide:95lrm/RM-P#I7764|P]] :entry_body_formal_part [[Guide:95lrm/RM-9-5-2#I3452|9.5.2(6)]] ::''used'' [[Guide:95lrm/RM-9-5-2#I3447|9.5.2(5)]], [[Guide:95lrm/RM-P#I7776|P]] :entry_call_alternative [[Guide:95lrm/RM-9-7-2#I3605|9.7.2(3)]] ::''used'' [[Guide:95lrm/RM-9-7-2#I3603|9.7.2(2)]], [[Guide:95lrm/RM-9-7-3#I3610|9.7.3(2)]], [[Guide:95lrm/RM-P#I7810|P]] :entry_call_statement [[Guide:95lrm/RM-9-5-3#I3484|9.5.3(2)]] ::''used'' [[Guide:95lrm/RM-5-1#I2780|5.1(4)]], [[Guide:95lrm/RM-9-7-2#I3606|9.7.2(3)]], [[Guide:95lrm/RM-9-7-4#I3620|9.7.4(4)]], [[Guide:95lrm/RM-P#I7604|P]] :entry_declaration [[Guide:95lrm/RM-9-5-2#I3433|9.5.2(2)]] ::''used'' [[Guide:95lrm/RM-9-1#I3336|9.1(5/1)]], [[Guide:95lrm/RM-9-4#I3387|9.4(5/1)]], [[Guide:95lrm/RM-P#I7755|P]] :entry_index [[Guide:95lrm/RM-9-5-2#I3443|9.5.2(4)]] ::''used'' [[Guide:95lrm/RM-9-5-2#I3439|9.5.2(3)]], [[Guide:95lrm/RM-P#I7770|P]] :entry_index_specification [[Guide:95lrm/RM-9-5-2#I3457|9.5.2(8)]] ::''used'' [[Guide:95lrm/RM-9-5-2#I3453|9.5.2(6)]], [[Guide:95lrm/RM-P#I7781|P]] :enumeration literal [[Guide:95lrm/RM-3-5-1#I1581|3.5.1(6)]] :enumeration type [[Guide:95lrm/RM-3-2#I1307|3.2(3)]], [[Guide:95lrm/RM-3-5-1#I1572|3.5.1(1)]] :enumeration_aggregate [[Guide:95lrm/RM-13-4#I4242|13.4(3)]] ::''used'' [[Guide:95lrm/RM-13-4#I4241|13.4(2)]], [[Guide:95lrm/RM-P#I7943|P]] :Enumeration_IO ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5868|A.10.1(79)]] :enumeration_literal_specification [[Guide:95lrm/RM-3-5-1#I1576|3.5.1(3)]] ::''used'' [[Guide:95lrm/RM-3-5-1#I1574|3.5.1(2)]], [[Guide:95lrm/RM-P#I7391|P]] :enumeration_representation_clause [[Guide:95lrm/RM-13-4#I4239|13.4(2)]] ::''used'' [[Guide:95lrm/RM-13-1#I4121|13.1(2/1)]], [[Guide:95lrm/RM-P#I7929|P]] :enumeration_type_definition [[Guide:95lrm/RM-3-5-1#I1573|3.5.1(2)]] ::''used'' [[Guide:95lrm/RM-3-2-1#I1335|3.2.1(4)]], [[Guide:95lrm/RM-P#I7353|P]] :environment [[Guide:95lrm/RM-10-1-4#I3749|10.1.4(1)]] :environment declarative_part [[Guide:95lrm/RM-10-1-4#I3750|10.1.4(1)]] ::for the environment task of a partition [[Guide:95lrm/RM-10-2#I3790|10.2(13)]] :environment task [[Guide:95lrm/RM-10-2#I3787|10.2(8)]] :EOT ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4654|A.3.3(5)]] :EPA ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4771|A.3.3(18)]] :epoch [[Guide:95lrm/RM-D-8#I6648|D.8(19)]] :equal operator [[Guide:95lrm/RM-4-4#I2345|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2497|4.5.2(1)]] :equality operator [[Guide:95lrm/RM-4-5-2#I2491|4.5.2(1)]] ::special inheritance rule for tagged types [[Guide:95lrm/RM-3-4#I1462|3.4(17)]], [[Guide:95lrm/RM-4-5-2#I2526|4.5.2(14)]] :equals sign [[Guide:95lrm/RM-2-1#I1158|2.1(15)]] :Equals_Sign ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4702|A.3.3(10)]] :erroneous execution [[Guide:95lrm/RM-1-1-2#I1041|1.1.2(32)]], [[Guide:95lrm/RM-1-1-5#I1080|1.1.5(10)]] ::cause [[Guide:95lrm/RM-3-7-2#I1890|3.7.2(4)]], [[Guide:95lrm/RM-9-8#I3652|9.8(21)]], [[Guide:95lrm/RM-9-10#I3664|9.10(11)]], [[Guide:95lrm/RM-11-5#I3942|11.5(26)]], [[Guide:95lrm/RM-13-3#I4199|13.3(13)]], [[Guide:95lrm/RM-13-3#I4205|13.3(27)]], [[Guide:95lrm/RM-13-3#I4206|13.3(28)]], [[Guide:95lrm/RM-13-9-1#I4383|13.9.1(8)]], [[Guide:95lrm/RM-13-9-1#I4388|13.9.1(12)]], [[Guide:95lrm/RM-13-9-1#I4389|13.9.1(13)]], [[Guide:95lrm/RM-13-11#I4431|13.11(21)]], [[Guide:95lrm/RM-13-11-2#I4450|13.11.2(16)]], [[Guide:95lrm/RM-A-10-3#I5891|A.10.3(22/1)]], [[Guide:95lrm/RM-A-12-1#I5975|A.12.1(36.1/1)]], [[Guide:95lrm/RM-A-13#I6001|A.13(17)]], [[Guide:95lrm/RM-B-3-1#I6206|B.3.1(51)]], [[Guide:95lrm/RM-B-3-1#I6207|B.3.1(55)]], [[Guide:95lrm/RM-B-3-1#I6208|B.3.1(56)]], [[Guide:95lrm/RM-B-3-1#I6209|B.3.1(57)]], [[Guide:95lrm/RM-B-3-2#I6230|B.3.2(35)]], [[Guide:95lrm/RM-B-3-2#I6231|B.3.2(36)]], [[Guide:95lrm/RM-B-3-2#I6232|B.3.2(37)]], [[Guide:95lrm/RM-B-3-2#I6233|B.3.2(38)]], [[Guide:95lrm/RM-B-3-2#I6234|B.3.2(39)]], [[Guide:95lrm/RM-B-3-2#I6235|B.3.2(42)]], [[Guide:95lrm/RM-C-3-1#I6400|C.3.1(14)]], [[Guide:95lrm/RM-C-3-1#I6401|C.3.1(14.1/1)]], [[Guide:95lrm/RM-C-7-1#I6489|C.7.1(18)]], [[Guide:95lrm/RM-C-7-2#I6506|C.7.2(14)]], [[Guide:95lrm/RM-C-7-2#I6507|C.7.2(15)]], [[Guide:95lrm/RM-C-7-2#I6508|C.7.2(15.1/1)]], [[Guide:95lrm/RM-D-5#I6590|D.5(12)]], [[Guide:95lrm/RM-D-11#I6687|D.11(9)]], [[Guide:95lrm/RM-H-4#I7074|H.4(26)]], [[Guide:95lrm/RM-H-4#I7075|H.4(27)]] :error ::compile-time [[Guide:95lrm/RM-1-1-2#I1024|1.1.2(27)]], [[Guide:95lrm/RM-1-1-5#I1073|1.1.5(4)]] ::link-time [[Guide:95lrm/RM-1-1-2#I1032|1.1.2(29)]], [[Guide:95lrm/RM-1-1-5#I1075|1.1.5(4)]] ::run-time [[Guide:95lrm/RM-1-1-2#I1038|1.1.2(30)]], [[Guide:95lrm/RM-1-1-5#I1077|1.1.5(6)]], [[Guide:95lrm/RM-11-5#I3918|11.5(2)]], [[Guide:95lrm/RM-11-6#I3949|11.6(1)]] ::''See also'' bounded error, erroneous execution :ESA ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4755|A.3.3(17)]] :ESC ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4677|A.3.3(6)]] :Establish_RPC_Receiver ::''in'' System.RPC [[Guide:95lrm/RM-E-5#I6810|E.5(12)]] :ETB ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4673|A.3.3(6)]] :ETX ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4653|A.3.3(5)]] :evaluation [[Guide:95lrm/RM-3-1#I1293|3.1(11)]], [[Guide:95lrm/RM-N#I7282|N(19)]] ::aggregate [[Guide:95lrm/RM-4-3#I2261|4.3(5)]] ::allocator [[Guide:95lrm/RM-4-8#I2728|4.8(7)]] ::array_aggregate [[Guide:95lrm/RM-4-3-3#I2323|4.3.3(21)]] ::attribute_reference [[Guide:95lrm/RM-4-1-4#I2237|4.1.4(11)]] ::concatenation [[Guide:95lrm/RM-4-5-3#I2548|4.5.3(5)]] ::dereference [[Guide:95lrm/RM-4-1#I2183|4.1(13)]] ::discrete_range [[Guide:95lrm/RM-3-6-1#I1816|3.6.1(8)]] ::extension_aggregate [[Guide:95lrm/RM-4-3-2#I2295|4.3.2(7)]] ::generic_association [[Guide:95lrm/RM-12-3#I4029|12.3(21)]] ::generic_association for a formal object of mode in [[Guide:95lrm/RM-12-4#I4042|12.4(11)]] ::indexed_component [[Guide:95lrm/RM-4-1-1#I2194|4.1.1(7)]] ::initialized allocator [[Guide:95lrm/RM-4-8#I2729|4.8(7)]] ::membership test [[Guide:95lrm/RM-4-5-2#I2530|4.5.2(27)]] ::name [[Guide:95lrm/RM-4-1#I2180|4.1(11)]] ::name that has a prefix [[Guide:95lrm/RM-4-1#I2181|4.1(12)]] ::null literal [[Guide:95lrm/RM-4-2#I2247|4.2(9)]] ::numeric literal [[Guide:95lrm/RM-4-2#I2246|4.2(9)]] ::parameter_association [[Guide:95lrm/RM-6-4-1#I3021|6.4.1(7)]] ::prefix [[Guide:95lrm/RM-4-1#I2182|4.1(12)]] ::primary that is a name [[Guide:95lrm/RM-4-4#I2448|4.4(10)]] ::qualified_expression [[Guide:95lrm/RM-4-7#I2708|4.7(4)]] ::range [[Guide:95lrm/RM-3-5#I1515|3.5(9)]] ::range_attribute_reference [[Guide:95lrm/RM-4-1-4#I2238|4.1.4(11)]] ::record_aggregate [[Guide:95lrm/RM-4-3-1#I2283|4.3.1(18)]] ::record_component_association_list [[Guide:95lrm/RM-4-3-1#I2284|4.3.1(19)]] ::selected_component [[Guide:95lrm/RM-4-1-3#I2218|4.1.3(14)]] ::short-circuit control form [[Guide:95lrm/RM-4-5-1#I2482|4.5.1(7)]] ::slice [[Guide:95lrm/RM-4-1-2#I2204|4.1.2(7)]] ::string_literal [[Guide:95lrm/RM-4-2#I2250|4.2(10)]] ::uninitialized allocator [[Guide:95lrm/RM-4-8#I2732|4.8(8)]] ::Val [[Guide:95lrm/RM-3-5-5#I1657|3.5.5(7)]], [[Guide:95lrm/RM-K#I7140|K(261)]] ::Value [[Guide:95lrm/RM-3-5#I1568|3.5(55)]] ::value conversion [[Guide:95lrm/RM-4-6#I2647|4.6(28)]] ::view conversion [[Guide:95lrm/RM-4-6#I2687|4.6(52)]] ::Wide_Value [[Guide:95lrm/RM-3-5#I1556|3.5(43)]] :Exception [[Guide:95lrm/RM-11#I3834|11(1)]], [[Guide:95lrm/RM-11-1#I3837|11.1(1)]] :exception occurrence [[Guide:95lrm/RM-11#I3829|11(1)]] :exception_choice [[Guide:95lrm/RM-11-2#I3861|11.2(5)]] ::''used'' [[Guide:95lrm/RM-11-2#I3856|11.2(3)]], [[Guide:95lrm/RM-P#I7863|P]] :exception_declaration [[Guide:95lrm/RM-11-1#I3838|11.1(2)]] ::''used'' [[Guide:95lrm/RM-3-1#I1274|3.1(3)]], [[Guide:95lrm/RM-P#I7340|P]] :exception_handler [[Guide:95lrm/RM-11-2#I3854|11.2(3)]] ::''used'' [[Guide:95lrm/RM-11-2#I3853|11.2(2)]], [[Guide:95lrm/RM-P#I7860|P]] :Exception_Id ::''in'' Ada.Exceptions [[Guide:95lrm/RM-11-4-1#I3886|11.4.1(2)]] :Exception_Identity ::''in'' Ada.Exceptions [[Guide:95lrm/RM-11-4-1#I3902|11.4.1(5)]] :Exception_Information ::''in'' Ada.Exceptions [[Guide:95lrm/RM-11-4-1#I3906|11.4.1(5)]] :Exception_Message ::''in'' Ada.Exceptions [[Guide:95lrm/RM-11-4-1#I3898|11.4.1(4)]] :Exception_Name ::''in'' Ada.Exceptions [[Guide:95lrm/RM-11-4-1#I3889|11.4.1(2)]], [[Guide:95lrm/RM-11-4-1#I3904|11.4.1(5)]] :Exception_Occurrence ::''in'' Ada.Exceptions [[Guide:95lrm/RM-11-4-1#I3891|11.4.1(3)]] :Exception_Occurrence_Access ::''in'' Ada.Exceptions [[Guide:95lrm/RM-11-4-1#I3893|11.4.1(3)]] :exception_renaming_declaration [[Guide:95lrm/RM-8-5-2#I3254|8.5.2(2)]] ::''used'' [[Guide:95lrm/RM-8-5#I3243|8.5(2)]], [[Guide:95lrm/RM-P#I7713|P]] :Exceptions ::''child of'' Ada [[Guide:95lrm/RM-11-4-1#I3882|11.4.1(2)]] :Exchange_Handler ::''in'' Ada.Interrupts [[Guide:95lrm/RM-C-3-2#I6419|C.3.2(8)]] :Exclamation ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4683|A.3.3(8)]] :execution [[Guide:95lrm/RM-3-1#I1291|3.1(11)]] ::abort_statement [[Guide:95lrm/RM-9-8#I3638|9.8(4)]] ::aborting the execution of a construct [[Guide:95lrm/RM-9-8#I3642|9.8(5)]] ::accept_statement [[Guide:95lrm/RM-9-5-2#I3475|9.5.2(24)]] ::Ada program [[Guide:95lrm/RM-9#I3305|9(1)]] ::assignment_statement [[Guide:95lrm/RM-5-2#I2810|5.2(7)]], [[Guide:95lrm/RM-7-6#I3151|7.6(17)]], [[Guide:95lrm/RM-7-6-1#I3166|7.6.1(12)]] ::asynchronous_select with a delay_statement trigger [[Guide:95lrm/RM-9-7-4#I3625|9.7.4(7)]] ::asynchronous_select with an entry call trigger [[Guide:95lrm/RM-9-7-4#I3624|9.7.4(6)]] ::block_statement [[Guide:95lrm/RM-5-6#I2865|5.6(5)]] ::call on a dispatching operation [[Guide:95lrm/RM-3-9-2#I2024|3.9.2(14)]] ::call on an inherited subprogram [[Guide:95lrm/RM-3-4#I1468|3.4(27)]] ::case_statement [[Guide:95lrm/RM-5-4#I2838|5.4(11)]] ::conditional_entry_call [[Guide:95lrm/RM-9-7-3#I3612|9.7.3(3)]] ::delay_statement [[Guide:95lrm/RM-9-6#I3561|9.6(20)]] ::dynamically enclosing [[Guide:95lrm/RM-11-4#I3875|11.4(2)]] ::entry_body [[Guide:95lrm/RM-9-5-2#I3480|9.5.2(26)]] ::entry_call_statement [[Guide:95lrm/RM-9-5-3#I3496|9.5.3(8)]] ::exit_statement [[Guide:95lrm/RM-5-7#I2870|5.7(5)]] ::goto_statement [[Guide:95lrm/RM-5-8#I2874|5.8(5)]] ::handled_sequence_of_statements [[Guide:95lrm/RM-11-2#I3865|11.2(10)]] ::handler [[Guide:95lrm/RM-11-4#I3880|11.4(7)]] ::if_statement [[Guide:95lrm/RM-5-3#I2828|5.3(5)]] ::instance of Unchecked_Deallocation [[Guide:95lrm/RM-7-6-1#I3165|7.6.1(10)]] ::loop_statement [[Guide:95lrm/RM-5-5#I2855|5.5(7)]] ::loop_statement with a for iteration_scheme [[Guide:95lrm/RM-5-5#I2857|5.5(9)]] ::loop_statement with a while iteration_scheme [[Guide:95lrm/RM-5-5#I2856|5.5(8)]] ::null_statement [[Guide:95lrm/RM-5-1#I2798|5.1(13)]] ::partition [[Guide:95lrm/RM-10-2#I3792|10.2(25)]] ::pragma [[Guide:95lrm/RM-2-8#I1252|2.8(12)]] ::program [[Guide:95lrm/RM-10-2#I3791|10.2(25)]] ::protected subprogram call [[Guide:95lrm/RM-9-5-1#I3423|9.5.1(3)]] ::raise_statement with an exception_name [[Guide:95lrm/RM-11-3#I3870|11.3(4)]] ::re-raise statement [[Guide:95lrm/RM-11-3#I3871|11.3(4)]] ::remote subprogram call [[Guide:95lrm/RM-E-4#I6769|E.4(9)]] ::requeue protected entry [[Guide:95lrm/RM-9-5-4#I3520|9.5.4(9)]] ::requeue task entry [[Guide:95lrm/RM-9-5-4#I3519|9.5.4(8)]] ::requeue_statement [[Guide:95lrm/RM-9-5-4#I3518|9.5.4(7)]] ::return_statement [[Guide:95lrm/RM-6-5#I3039|6.5(6)]] ::selective_accept [[Guide:95lrm/RM-9-7-1#I3598|9.7.1(15)]] ::sequence_of_statements [[Guide:95lrm/RM-5-1#I2800|5.1(15)]] ::subprogram call [[Guide:95lrm/RM-6-4#I3013|6.4(10)]] ::subprogram_body [[Guide:95lrm/RM-6-3#I2956|6.3(7)]] ::task [[Guide:95lrm/RM-9-2#I3351|9.2(1)]] ::task_body [[Guide:95lrm/RM-9-2#I3352|9.2(1)]] ::timed_entry_call [[Guide:95lrm/RM-9-7-2#I3608|9.7.2(4)]] :execution resource ::associated with a protected object [[Guide:95lrm/RM-9-4#I3409|9.4(18)]] ::required for a task to run [[Guide:95lrm/RM-9#I3322|9(10)]] :exit_statement [[Guide:95lrm/RM-5-7#I2866|5.7(2)]] ::''used'' [[Guide:95lrm/RM-5-1#I2776|5.1(4)]], [[Guide:95lrm/RM-P#I7600|P]] :Exit_Status ::''in'' Ada.Command_Line [[Guide:95lrm/RM-A-15#I6015|A.15(7)]], [[Guide:95lrm/RM-A-15#I6022|A.15(16.1/1)]] :Exp ::''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6927|G.1.2(3)]] ::''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5276|A.5.1(4)]] :expanded name [[Guide:95lrm/RM-4-1-3#I2217|4.1.3(4)]] :Expanded_Name ::''in'' Ada.Tags [[Guide:95lrm/RM-3-9#I1970|3.9(7)]] :expected profile [[Guide:95lrm/RM-8-6#I3298|8.6(26)]] ::accept_statement entry_direct_name [[Guide:95lrm/RM-9-5-2#I3460|9.5.2(11)]] ::Access attribute_reference prefix [[Guide:95lrm/RM-3-10-2#I2096|3.10.2(2)]] ::attribute_definition_clause name [[Guide:95lrm/RM-13-3#I4172|13.3(4)]] ::character_literal [[Guide:95lrm/RM-4-2#I2244|4.2(3)]] ::formal subprogram actual [[Guide:95lrm/RM-12-6#I4101|12.6(6)]] ::formal subprogram default_name [[Guide:95lrm/RM-12-6#I4100|12.6(5)]] ::subprogram_renaming_declaration [[Guide:95lrm/RM-8-5-4#I3265|8.5.4(3)]] :expected type [[Guide:95lrm/RM-8-6#I3293|8.6(20)]] ::abort_statement task_name [[Guide:95lrm/RM-9-8#I3637|9.8(3)]] ::access attribute_reference [[Guide:95lrm/RM-3-10-2#I2095|3.10.2(2)]] ::actual parameter [[Guide:95lrm/RM-6-4-1#I3019|6.4.1(3)]] ::aggregate [[Guide:95lrm/RM-4-3#I2260|4.3(3)]] ::allocator [[Guide:95lrm/RM-4-8#I2723|4.8(3/1)]] ::array_aggregate [[Guide:95lrm/RM-4-3-3#I2318|4.3.3(7)]] ::array_aggregate component expression [[Guide:95lrm/RM-4-3-3#I2319|4.3.3(7)]] ::array_aggregate discrete_choice [[Guide:95lrm/RM-4-3-3#I2320|4.3.3(8)]] ::assignment_statement expression [[Guide:95lrm/RM-5-2#I2809|5.2(4)]] ::assignment_statement variable_name [[Guide:95lrm/RM-5-2#I2808|5.2(4)]] ::attribute_definition_clause expression or name [[Guide:95lrm/RM-13-3#I4171|13.3(4)]] ::attribute_designator expression [[Guide:95lrm/RM-4-1-4#I2235|4.1.4(7)]] ::case expression [[Guide:95lrm/RM-5-4#I2836|5.4(4)]] ::case_statement_alternative discrete_choice [[Guide:95lrm/RM-5-4#I2837|5.4(4)]] ::character_literal [[Guide:95lrm/RM-4-2#I2243|4.2(3)]] ::code_statement [[Guide:95lrm/RM-13-8#I4360|13.8(4)]] ::component_clause expressions [[Guide:95lrm/RM-13-5-1#I4271|13.5.1(7)]] ::component_declaration default_expression [[Guide:95lrm/RM-3-8#I1910|3.8(7)]] ::condition [[Guide:95lrm/RM-5-3#I2827|5.3(4)]] ::decimal fixed point type digits [[Guide:95lrm/RM-3-5-9#I1722|3.5.9(6)]] ::delay_relative_statement expression [[Guide:95lrm/RM-9-6#I3532|9.6(5)]] ::delay_until_statement expression [[Guide:95lrm/RM-9-6#I3533|9.6(5)]] ::delta_constraint expression [[Guide:95lrm/RM-J-3#I7080|J.3(3)]] ::dereference name [[Guide:95lrm/RM-4-1#I2177|4.1(8)]] ::discrete_subtype_definition range [[Guide:95lrm/RM-3-6#I1781|3.6(8)]] ::discriminant default_expression [[Guide:95lrm/RM-3-7#I1854|3.7(7)]] ::discriminant_association expression [[Guide:95lrm/RM-3-7-1#I1882|3.7.1(6)]] ::entry_index [[Guide:95lrm/RM-9-5-2#I3461|9.5.2(11)]] ::enumeration_representation_clause expressions [[Guide:95lrm/RM-13-4#I4244|13.4(4)]] ::extension_aggregate [[Guide:95lrm/RM-4-3-2#I2292|4.3.2(4)]] ::extension_aggregate ancestor expression [[Guide:95lrm/RM-4-3-2#I2293|4.3.2(4)]] ::first_bit [[Guide:95lrm/RM-13-5-1#I4273|13.5.1(7)]] ::fixed point type delta [[Guide:95lrm/RM-3-5-9#I1721|3.5.9(6)]] ::generic formal in object actual [[Guide:95lrm/RM-12-4#I4038|12.4(4)]] ::generic formal object default_expression [[Guide:95lrm/RM-12-4#I4037|12.4(3)]] ::index_constraint discrete_range [[Guide:95lrm/RM-3-6-1#I1810|3.6.1(4)]] ::indexed_component expression [[Guide:95lrm/RM-4-1-1#I2192|4.1.1(4)]] ::Interrupt_Priority pragma argument [[Guide:95lrm/RM-D-1#I6518|D.1(6)]] ::last_bit [[Guide:95lrm/RM-13-5-1#I4274|13.5.1(7)]] ::link name [[Guide:95lrm/RM-B-1#I6053|B.1(10)]] ::membership test simple_expression [[Guide:95lrm/RM-4-5-2#I2523|4.5.2(3)]] ::modular_type_definition expression [[Guide:95lrm/RM-3-5-4#I1615|3.5.4(5)]] ::null literal [[Guide:95lrm/RM-4-2#I2242|4.2(2)]] ::number_declaration expression [[Guide:95lrm/RM-3-3-2#I1442|3.3.2(3)]] ::object_declaration initialization expression [[Guide:95lrm/RM-3-3-1#I1417|3.3.1(4)]] ::parameter default_expression [[Guide:95lrm/RM-6-1#I2922|6.1(17)]] ::position [[Guide:95lrm/RM-13-5-1#I4272|13.5.1(7)]] ::Priority pragma argument [[Guide:95lrm/RM-D-1#I6517|D.1(6)]] ::range simple_expressions [[Guide:95lrm/RM-3-5#I1507|3.5(5)]] ::range_attribute_designator expression [[Guide:95lrm/RM-4-1-4#I2236|4.1.4(7)]] ::range_constraint range [[Guide:95lrm/RM-3-5#I1506|3.5(5)]] ::real_range_specification bounds [[Guide:95lrm/RM-3-5-7#I1682|3.5.7(5)]] ::record_aggregate [[Guide:95lrm/RM-4-3-1#I2279|4.3.1(8)]] ::record_component_association expression [[Guide:95lrm/RM-4-3-1#I2281|4.3.1(10)]] ::requested decimal precision [[Guide:95lrm/RM-3-5-7#I1681|3.5.7(4)]] ::restriction parameter expression [[Guide:95lrm/RM-13-12#I4467|13.12(5)]] ::return expression [[Guide:95lrm/RM-6-5#I3037|6.5(3)]] ::short-circuit control form relation [[Guide:95lrm/RM-4-5-1#I2472|4.5.1(1)]] ::signed_integer_type_definition simple_expression [[Guide:95lrm/RM-3-5-4#I1614|3.5.4(5)]] ::slice discrete_range [[Guide:95lrm/RM-4-1-2#I2203|4.1.2(4)]] ::Storage_Size pragma argument [[Guide:95lrm/RM-13-3#I4225|13.3(65)]] ::string_literal [[Guide:95lrm/RM-4-2#I2245|4.2(4)]] ::type_conversion operand [[Guide:95lrm/RM-4-6#I2624|4.6(6)]] ::variant_part discrete_choice [[Guide:95lrm/RM-3-8-1#I1938|3.8.1(6)]] :expiration time ::[''partial''] [[Guide:95lrm/RM-9-6#I3523|9.6(1)]] ::for a delay_relative_statement [[Guide:95lrm/RM-9-6#I3563|9.6(20)]] ::for a delay_until_statement [[Guide:95lrm/RM-9-6#I3562|9.6(20)]] :explicit declaration [[Guide:95lrm/RM-3-1#I1280|3.1(5)]], [[Guide:95lrm/RM-N#I7276|N(11)]] :explicit initial value [[Guide:95lrm/RM-3-3-1#I1400|3.3.1(1)]] :explicit_actual_parameter [[Guide:95lrm/RM-6-4#I3008|6.4(6)]] ::''used'' [[Guide:95lrm/RM-6-4#I3007|6.4(5)]], [[Guide:95lrm/RM-P#I7686|P]] :explicit_dereference [[Guide:95lrm/RM-4-1#I2172|4.1(5)]] ::''used'' [[Guide:95lrm/RM-4-1#I2158|4.1(2)]], [[Guide:95lrm/RM-P#I7490|P]] :explicit_generic_actual_parameter [[Guide:95lrm/RM-12-3#I4007|12.3(5)]] ::''used'' [[Guide:95lrm/RM-12-3#I4006|12.3(4)]], [[Guide:95lrm/RM-P#I7893|P]] :explicitly assign [[Guide:95lrm/RM-10-2#I3782|10.2(2)]] :exponent [[Guide:95lrm/RM-2-4-1#I1198|2.4.1(4)]], [[Guide:95lrm/RM-4-5-6#I2599|4.5.6(11)]] ::''used'' [[Guide:95lrm/RM-2-4-1#I1193|2.4.1(2)]], [[Guide:95lrm/RM-2-4-2#I1215|2.4.2(2)]], [[Guide:95lrm/RM-P#I7306|P]] :Exponent attribute [[Guide:95lrm/RM-A-5-3#I5414|A.5.3(18)]] :exponentiation operator [[Guide:95lrm/RM-4-4#I2400|4.4(1)]], [[Guide:95lrm/RM-4-5-6#I2595|4.5.6(7)]] :Export pragma [[Guide:95lrm/RM-B-1#I6041|B.1(6)]], [[Guide:95lrm/RM-L#I7182|L(13)]] :exported ::aspect of representation [[Guide:95lrm/RM-B-1#I6073|B.1(28)]] :exported entity [[Guide:95lrm/RM-B-1#I6061|B.1(23)]] :expression [[Guide:95lrm/RM-4-4#I2334|4.4(1)]], [[Guide:95lrm/RM-4-4#I2407|4.4(2)]] ::''used'' [[Guide:95lrm/RM-2-8#I1245|2.8(3)]], [[Guide:95lrm/RM-3-3-1#I1411|3.3.1(2)]], [[Guide:95lrm/RM-3-3-2#I1441|3.3.2(2)]], [[Guide:95lrm/RM-3-5-4#I1613|3.5.4(4)]], [[Guide:95lrm/RM-3-5-7#I1675|3.5.7(2)]], [[Guide:95lrm/RM-3-5-9#I1712|3.5.9(3)]], [[Guide:95lrm/RM-3-5-9#I1715|3.5.9(4)]], [[Guide:95lrm/RM-3-5-9#I1719|3.5.9(5)]], [[Guide:95lrm/RM-3-7#I1853|3.7(6)]], [[Guide:95lrm/RM-3-7-1#I1877|3.7.1(3)]], [[Guide:95lrm/RM-3-8-1#I1935|3.8.1(5)]], [[Guide:95lrm/RM-4-1-1#I2191|4.1.1(2)]], [[Guide:95lrm/RM-4-1-4#I2229|4.1.4(3)]], [[Guide:95lrm/RM-4-1-4#I2234|4.1.4(5)]], [[Guide:95lrm/RM-4-3-1#I2273|4.3.1(4)]], [[Guide:95lrm/RM-4-3-2#I2290|4.3.2(3)]], [[Guide:95lrm/RM-4-3-3#I2303|4.3.3(3)]], [[Guide:95lrm/RM-4-3-3#I2314|4.3.3(5)]], [[Guide:95lrm/RM-4-4#I2447|4.4(7)]], [[Guide:95lrm/RM-4-6#I2612|4.6(2)]], [[Guide:95lrm/RM-4-7#I2704|4.7(2)]], [[Guide:95lrm/RM-5-2#I2803|5.2(2)]], [[Guide:95lrm/RM-5-3#I2826|5.3(3)]], [[Guide:95lrm/RM-5-4#I2830|5.4(2)]], [[Guide:95lrm/RM-6-4#I3009|6.4(6)]], [[Guide:95lrm/RM-6-5#I3034|6.5(2)]], [[Guide:95lrm/RM-9-5-2#I3444|9.5.2(4)]], [[Guide:95lrm/RM-9-6#I3529|9.6(3)]], [[Guide:95lrm/RM-9-6#I3531|9.6(4)]], [[Guide:95lrm/RM-12-3#I4008|12.3(5)]], [[Guide:95lrm/RM-13-3#I4167|13.3(2)]], [[Guide:95lrm/RM-13-3#I4224|13.3(63)]], [[Guide:95lrm/RM-13-5-1#I4266|13.5.1(4)]], [[Guide:95lrm/RM-13-12#I4466|13.12(4)]], [[Guide:95lrm/RM-B-1#I6038|B.1(5)]], [[Guide:95lrm/RM-B-1#I6044|B.1(6)]], [[Guide:95lrm/RM-B-1#I6052|B.1(8)]], [[Guide:95lrm/RM-B-1#I6054|B.1(10)]], [[Guide:95lrm/RM-C-3-1#I6389|C.3.1(4)]], [[Guide:95lrm/RM-D-1#I6513|D.1(3)]], [[Guide:95lrm/RM-D-1#I6516|D.1(5)]], [[Guide:95lrm/RM-J-3#I7078|J.3(2)]], [[Guide:95lrm/RM-J-7#I7089|J.7(1)]], [[Guide:95lrm/RM-J-8#I7099|J.8(1)]], [[Guide:95lrm/RM-L#I7159|L(6)]], [[Guide:95lrm/RM-L#I7185|L(13)]], [[Guide:95lrm/RM-L#I7191|L(14)]], [[Guide:95lrm/RM-L#I7206|L(18)]], [[Guide:95lrm/RM-L#I7209|L(19)]], [[Guide:95lrm/RM-L#I7231|L(27)]], [[Guide:95lrm/RM-L#I7255|L(35)]], [[Guide:95lrm/RM-P#I7408|P]] :extended_digit [[Guide:95lrm/RM-2-4-2#I1222|2.4.2(5)]] ::''used'' [[Guide:95lrm/RM-2-4-2#I1221|2.4.2(4)]], [[Guide:95lrm/RM-P#I7319|P]] :extension ::of a private type [[Guide:95lrm/RM-3-9#I1957|3.9(2)]], [[Guide:95lrm/RM-3-9-1#I1995|3.9.1(1)]] ::of a record type [[Guide:95lrm/RM-3-9#I1955|3.9(2)]], [[Guide:95lrm/RM-3-9-1#I1993|3.9.1(1)]] ::of a type [[Guide:95lrm/RM-3-9#I1954|3.9(2)]], [[Guide:95lrm/RM-3-9-1#I1991|3.9.1(1)]] :extension_aggregate [[Guide:95lrm/RM-4-3-2#I2286|4.3.2(2)]] ::''used'' [[Guide:95lrm/RM-4-3#I2258|4.3(2)]], [[Guide:95lrm/RM-P#I7522|P]] :external call [[Guide:95lrm/RM-9-5#I3416|9.5(4)]] :external effect ::of the execution of an Ada program [[Guide:95lrm/RM-1-1-3#I1051|1.1.3(8)]] ::volatile/atomic objects [[Guide:95lrm/RM-C-6#I6462|C.6(20)]] :external file [[Guide:95lrm/RM-A-7#I5486|A.7(1)]] :external interaction [[Guide:95lrm/RM-1-1-3#I1053|1.1.3(8)]] :external name [[Guide:95lrm/RM-B-1#I6080|B.1(34)]] :external requeue [[Guide:95lrm/RM-9-5#I3419|9.5(7)]] :External_Tag ::''in'' Ada.Tags [[Guide:95lrm/RM-3-9#I1972|3.9(7)]] :External_Tag attribute [[Guide:95lrm/RM-13-3#I4236|13.3(75/1)]] :External_Tag clause [[Guide:95lrm/RM-13-3#I4182|13.3(7)]], [[Guide:95lrm/RM-13-3#I4237|13.3(75/1)]], [[Guide:95lrm/RM-K#I7115|K(65)]] :extra permission to avoid raising exceptions [[Guide:95lrm/RM-11-6#I3953|11.6(5)]] :extra permission to reorder actions [[Guide:95lrm/RM-11-6#I3955|11.6(6)]] == F == :factor [[Guide:95lrm/RM-4-4#I2435|4.4(6)]] ::''used'' [[Guide:95lrm/RM-4-4#I2432|4.4(5)]], [[Guide:95lrm/RM-P#I7568|P]] :failure ::of a language-defined check [[Guide:95lrm/RM-11-5#I3919|11.5(2)]] ::''in'' Ada.Command_Line [[Guide:95lrm/RM-A-15#I6017|A.15(8)]] :False [[Guide:95lrm/RM-3-5-3#I1599|3.5.3(1)]] :family ::entry [[Guide:95lrm/RM-9-5-2#I3468|9.5.2(20)]] :Feminine_Ordinal_Indicator ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4791|A.3.3(21)]] :FF ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4662|A.3.3(5)]] :Field ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5630|A.10.1(6)]] :file ::as file object [[Guide:95lrm/RM-A-7#I5489|A.7(2)]] :file terminator [[Guide:95lrm/RM-A-10#I5611|A.10(7)]] :File_Access ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5673|A.10.1(18)]] :File_Mode ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5549|A.8.4(4)]] ::''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5509|A.8.1(4)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5922|A.12.1(6)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5625|A.10.1(4)]] :File_Type ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5547|A.8.4(3)]] ::''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5507|A.8.1(3)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5920|A.12.1(5)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5623|A.10.1(3)]] :finalization ::of a master [[Guide:95lrm/RM-7-6-1#I3163|7.6.1(4)]] ::of a protected object [[Guide:95lrm/RM-9-4#I3410|9.4(20)]] ::of a protected object [[Guide:95lrm/RM-C-3-1#I6399|C.3.1(12/1)]] ::of a task object [[Guide:95lrm/RM-J-7-1#I7096|J.7.1(8)]] ::of an object [[Guide:95lrm/RM-7-6-1#I3164|7.6.1(5)]] ::of environment task for a foreign language main subprogram [[Guide:95lrm/RM-B-1#I6087|B.1(39)]] ::''child of'' Ada [[Guide:95lrm/RM-7-6#I3127|7.6(4/1)]] :Finalize [[Guide:95lrm/RM-7-6#I3125|7.6(2)]] ::''in'' Ada.Finalization [[Guide:95lrm/RM-7-6#I3137|7.6(6)]], [[Guide:95lrm/RM-7-6#I3143|7.6(8)]] :Find_Token ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5056|A.4.4(51)]] ::''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4961|A.4.3(16)]] ::''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5148|A.4.5(46)]] :Fine_Delta ::''in'' System [[Guide:95lrm/RM-13-7#I4312|13.7(9)]] :First attribute [[Guide:95lrm/RM-3-5#I1518|3.5(12)]], [[Guide:95lrm/RM-3-6-2#I1818|3.6.2(3)]] :first subtype [[Guide:95lrm/RM-3-2-1#I1342|3.2.1(6)]], [[Guide:95lrm/RM-3-4-1#I1478|3.4.1(5)]] :First(N) attribute [[Guide:95lrm/RM-3-6-2#I1820|3.6.2(4)]] :first_bit [[Guide:95lrm/RM-13-5-1#I4267|13.5.1(5)]] ::''used'' [[Guide:95lrm/RM-13-5-1#I4263|13.5.1(3)]], [[Guide:95lrm/RM-P#I7950|P]] :First_Bit attribute [[Guide:95lrm/RM-13-5-2#I4280|13.5.2(3)]] :Fixed ::''child of'' Ada.Strings [[Guide:95lrm/RM-A-4-3#I4941|A.4.3(5)]] :fixed point type [[Guide:95lrm/RM-3-5-9#I1704|3.5.9(1)]] :Fixed_IO ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5836|A.10.1(68)]] :fixed_point_definition [[Guide:95lrm/RM-3-5-9#I1708|3.5.9(2)]] ::''used'' [[Guide:95lrm/RM-3-5-6#I1666|3.5.6(2)]], [[Guide:95lrm/RM-P#I7401|P]] :Float [[Guide:95lrm/RM-3-5-7#I1694|3.5.7(12)]], [[Guide:95lrm/RM-3-5-7#I1696|3.5.7(14)]] ::''in'' Standard [[Guide:95lrm/RM-A-1#I4556|A.1(21)]] :Float_Random ::''child of'' Ada.Numerics [[Guide:95lrm/RM-A-5-2#I5336|A.5.2(5)]] :Float_Text_IO ::''child of'' Ada [[Guide:95lrm/RM-A-10-9#I5899|A.10.9(33)]] :Float_Wide_Text_IO ::''child of'' Ada [[Guide:95lrm/RM-A-11#I5908|A.11(3)]] :Float_IO ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5820|A.10.1(63)]] :Floating ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6242|B.4(9)]] :floating point type [[Guide:95lrm/RM-3-5-7#I1673|3.5.7(1)]] :floating_point_definition [[Guide:95lrm/RM-3-5-7#I1674|3.5.7(2)]] ::''used'' [[Guide:95lrm/RM-3-5-6#I1665|3.5.6(2)]], [[Guide:95lrm/RM-P#I7400|P]] :Floor attribute [[Guide:95lrm/RM-A-5-3#I5428|A.5.3(30)]] :Flush ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5967|A.12.1(25/1)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5689|A.10.1(21/1)]] :Fore attribute [[Guide:95lrm/RM-3-5-10#I1749|3.5.10(4)]] :form ::of an external file [[Guide:95lrm/RM-A-7#I5488|A.7(1)]] ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5570|A.8.4(9)]] ::''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5527|A.8.1(9)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5943|A.12.1(11)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5651|A.10.1(12)]] :formal object, generic [[Guide:95lrm/RM-12-4#I4031|12.4(1)]] :formal package, generic [[Guide:95lrm/RM-12-7#I4105|12.7(1)]] :formal parameter ::of a subprogram [[Guide:95lrm/RM-6-1#I2921|6.1(17)]] :formal subprogram, generic [[Guide:95lrm/RM-12-6#I4092|12.6(1)]] :formal subtype [[Guide:95lrm/RM-12-5#I4067|12.5(5)]] :formal type [[Guide:95lrm/RM-12-5#I4065|12.5(5)]] :formal_access_type_definition [[Guide:95lrm/RM-12-5-4#I4087|12.5.4(2)]] ::''used'' [[Guide:95lrm/RM-12-5#I4059|12.5(3)]], [[Guide:95lrm/RM-P#I7916|P]] :formal_array_type_definition [[Guide:95lrm/RM-12-5-3#I4083|12.5.3(2)]] ::''used'' [[Guide:95lrm/RM-12-5#I4058|12.5(3)]], [[Guide:95lrm/RM-P#I7915|P]] :formal_decimal_fixed_point_definition [[Guide:95lrm/RM-12-5-2#I4082|12.5.2(7)]] ::''used'' [[Guide:95lrm/RM-12-5#I4057|12.5(3)]], [[Guide:95lrm/RM-P#I7914|P]] :formal_derived_type_definition [[Guide:95lrm/RM-12-5-1#I4071|12.5.1(3)]] ::''used'' [[Guide:95lrm/RM-12-5#I4051|12.5(3)]], [[Guide:95lrm/RM-P#I7908|P]] :formal_discrete_type_definition [[Guide:95lrm/RM-12-5-2#I4077|12.5.2(2)]] ::''used'' [[Guide:95lrm/RM-12-5#I4052|12.5(3)]], [[Guide:95lrm/RM-P#I7909|P]] :formal_floating_point_definition [[Guide:95lrm/RM-12-5-2#I4080|12.5.2(5)]] ::''used'' [[Guide:95lrm/RM-12-5#I4055|12.5(3)]], [[Guide:95lrm/RM-P#I7912|P]] :formal_modular_type_definition [[Guide:95lrm/RM-12-5-2#I4079|12.5.2(4)]] ::''used'' [[Guide:95lrm/RM-12-5#I4054|12.5(3)]], [[Guide:95lrm/RM-P#I7911|P]] :formal_object_declaration [[Guide:95lrm/RM-12-4#I4032|12.4(2)]] ::''used'' [[Guide:95lrm/RM-12-1#I3978|12.1(6)]], [[Guide:95lrm/RM-P#I7877|P]] :formal_ordinary_fixed_point_definition [[Guide:95lrm/RM-12-5-2#I4081|12.5.2(6)]] ::''used'' [[Guide:95lrm/RM-12-5#I4056|12.5(3)]], [[Guide:95lrm/RM-P#I7913|P]] :formal_package_actual_part [[Guide:95lrm/RM-12-7#I4110|12.7(3)]] ::''used'' [[Guide:95lrm/RM-12-7#I4109|12.7(2)]], [[Guide:95lrm/RM-P#I7926|P]] :formal_package_declaration [[Guide:95lrm/RM-12-7#I4106|12.7(2)]] ::''used'' [[Guide:95lrm/RM-12-1#I3981|12.1(6)]], [[Guide:95lrm/RM-P#I7880|P]] :formal_part [[Guide:95lrm/RM-6-1#I2909|6.1(14)]] ::''used'' [[Guide:95lrm/RM-6-1#I2905|6.1(12)]], [[Guide:95lrm/RM-6-1#I2907|6.1(13)]], [[Guide:95lrm/RM-P#I7661|P]] :formal_private_type_definition [[Guide:95lrm/RM-12-5-1#I4070|12.5.1(2)]] ::''used'' [[Guide:95lrm/RM-12-5#I4050|12.5(3)]], [[Guide:95lrm/RM-P#I7907|P]] :formal_signed_integer_type_definition [[Guide:95lrm/RM-12-5-2#I4078|12.5.2(3)]] ::''used'' [[Guide:95lrm/RM-12-5#I4053|12.5(3)]], [[Guide:95lrm/RM-P#I7910|P]] :formal_subprogram_declaration [[Guide:95lrm/RM-12-6#I4093|12.6(2)]] ::''used'' [[Guide:95lrm/RM-12-1#I3980|12.1(6)]], [[Guide:95lrm/RM-P#I7879|P]] :formal_type_declaration [[Guide:95lrm/RM-12-5#I4045|12.5(2)]] ::''used'' [[Guide:95lrm/RM-12-1#I3979|12.1(6)]], [[Guide:95lrm/RM-P#I7878|P]] :formal_type_definition [[Guide:95lrm/RM-12-5#I4049|12.5(3)]] ::''used'' [[Guide:95lrm/RM-12-5#I4048|12.5(2)]], [[Guide:95lrm/RM-P#I7906|P]] :format_effector [[Guide:95lrm/RM-2-1#I1131|2.1(13)]] ::''used'' [[Guide:95lrm/RM-2-1#I1117|2.1(2)]], [[Guide:95lrm/RM-P#I7291|P]] :Fortran ::''child of'' Interfaces [[Guide:95lrm/RM-B-5#I6327|B.5(4)]] :Fortran interface [[Guide:95lrm/RM-B-5#I6326|B.5(1)]] :FORTRAN standard [[Guide:95lrm/RM-1-2#I1093|1.2(3)]] :Fortran_Character ::''in'' Interfaces.Fortran [[Guide:95lrm/RM-B-5#I6347|B.5(12)]] :Fortran_Integer ::''in'' Interfaces.Fortran [[Guide:95lrm/RM-B-5#I6331|B.5(5)]] :Fraction attribute [[Guide:95lrm/RM-A-5-3#I5416|A.5.3(21)]] :Fraction_One_Half ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4812|A.3.3(22)]] :Fraction_One_Quarter ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4811|A.3.3(22)]] :Fraction_Three_Quarters ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4813|A.3.3(22)]] :Free ::''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5114|A.4.5(7)]] ::''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6187|B.3.1(11)]] :freed ::''See'' nonexistent [[Guide:95lrm/RM-13-11-2#I4442|13.11.2(10)]] :freeing storage [[Guide:95lrm/RM-13-11-2#I4438|13.11.2(1)]] :freezing :::by a constituent of a construct [[Guide:95lrm/RM-13-14#I4522|13.14(4/1)]] ::by an expression [[Guide:95lrm/RM-13-14#I4526|13.14(8/1)]] ::by an implicit call [[Guide:95lrm/RM-13-14#I4528|13.14(8.1/1)]] ::by an object name [[Guide:95lrm/RM-13-14#I4527|13.14(8/1)]] ::class-wide type caused by the freezing of the specific type [[Guide:95lrm/RM-13-14#I4541|13.14(15)]] ::constituents of a full type definition [[Guide:95lrm/RM-13-14#I4539|13.14(15)]] ::designated subtype caused by an allocator [[Guide:95lrm/RM-13-14#I4535|13.14(13)]] ::entity [[Guide:95lrm/RM-13-14#I4517|13.14(2)]] ::entity caused by a body [[Guide:95lrm/RM-13-14#I4520|13.14(3/1)]] ::entity caused by a construct [[Guide:95lrm/RM-13-14#I4521|13.14(4/1)]] ::entity caused by a name [[Guide:95lrm/RM-13-14#I4531|13.14(11)]] ::entity caused by the end of an enclosing construct [[Guide:95lrm/RM-13-14#I4519|13.14(3/1)]] ::first subtype caused by the freezing of the type [[Guide:95lrm/RM-13-14#I4540|13.14(15)]] ::function call [[Guide:95lrm/RM-13-14#I4537|13.14(14)]] ::generic_instantiation [[Guide:95lrm/RM-13-14#I4523|13.14(5)]] ::nominal subtype caused by a name [[Guide:95lrm/RM-13-14#I4532|13.14(11)]] ::object_declaration [[Guide:95lrm/RM-13-14#I4524|13.14(6)]] ::specific type caused by the freezing of the class-wide type [[Guide:95lrm/RM-13-14#I4542|13.14(15)]] ::subtype caused by a record extension [[Guide:95lrm/RM-13-14#I4525|13.14(7)]] ::subtype caused by an implicit conversion [[Guide:95lrm/RM-13-14#I4529|13.14(8.2/1)]] ::subtype caused by an implicit dereference [[Guide:95lrm/RM-13-14#I4533|13.14(11.1/1)]] ::subtypes of the profile of a callable entity [[Guide:95lrm/RM-13-14#I4536|13.14(14)]] ::type caused by a range [[Guide:95lrm/RM-13-14#I4534|13.14(12)]] ::type caused by an expression [[Guide:95lrm/RM-13-14#I4530|13.14(10)]] ::type caused by the freezing of a subtype [[Guide:95lrm/RM-13-14#I4538|13.14(15)]] :freezing points ::entity [[Guide:95lrm/RM-13-14#I4518|13.14(2)]] :FS ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4678|A.3.3(6)]] :full conformance ::for discrete_subtype_definitions [[Guide:95lrm/RM-6-3-1#I2986|6.3.1(24)]] ::for expressions [[Guide:95lrm/RM-6-3-1#I2983|6.3.1(19)]] ::for known_discriminant_parts [[Guide:95lrm/RM-6-3-1#I2984|6.3.1(23)]] ::for profiles [[Guide:95lrm/RM-6-3-1#I2981|6.3.1(18)]] ::required [[Guide:95lrm/RM-3-10-1#I2091|3.10.1(4)]], [[Guide:95lrm/RM-6-3#I2954|6.3(4)]], [[Guide:95lrm/RM-7-3#I3094|7.3(9)]], [[Guide:95lrm/RM-8-5-4#I3267|8.5.4(5/1)]], [[Guide:95lrm/RM-9-5-2#I3462|9.5.2(14)]], [[Guide:95lrm/RM-9-5-2#I3466|9.5.2(16)]], [[Guide:95lrm/RM-9-5-2#I3467|9.5.2(17)]], [[Guide:95lrm/RM-10-1-3#I3747|10.1.3(11)]], [[Guide:95lrm/RM-10-1-3#I3748|10.1.3(12)]] :full constant declaration [[Guide:95lrm/RM-3-3-1#I1420|3.3.1(6)]] :full declaration [[Guide:95lrm/RM-7-4#I3110|7.4(2)]] :full stop [[Guide:95lrm/RM-2-1#I1150|2.1(15)]] :full type [[Guide:95lrm/RM-3-2-1#I1346|3.2.1(8)]] :full type definition [[Guide:95lrm/RM-3-2-1#I1347|3.2.1(8)]] :full view ::of a type [[Guide:95lrm/RM-7-3#I3092|7.3(4)]] :Full_Stop ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4697|A.3.3(8)]] :full_type_declaration [[Guide:95lrm/RM-3-2-1#I1328|3.2.1(3)]] ::''used'' [[Guide:95lrm/RM-3-2-1#I1324|3.2.1(2)]], [[Guide:95lrm/RM-P#I7344|P]] :function [[Guide:95lrm/RM-6#I2877|6(1)]] :function instance [[Guide:95lrm/RM-12-3#I4022|12.3(13)]] :function_call [[Guide:95lrm/RM-6-4#I2998|6.4(3)]] ::''used'' [[Guide:95lrm/RM-4-1#I2164|4.1(2)]], [[Guide:95lrm/RM-P#I7496|P]] == G == :gaps [[Guide:95lrm/RM-13-1#I4132|13.1(7)]] :garbage collection [[Guide:95lrm/RM-13-11-3#I4458|13.11.3(6)]] :general access type [[Guide:95lrm/RM-3-10#I2061|3.10(7/1)]], [[Guide:95lrm/RM-3-10#I2065|3.10(8)]] :general_access_modifier [[Guide:95lrm/RM-3-10#I2052|3.10(4)]] ::''used'' [[Guide:95lrm/RM-3-10#I2050|3.10(3)]], [[Guide:95lrm/RM-P#I7470|P]] :generation ::of an interrupt [[Guide:95lrm/RM-C-3#I6375|C.3(2)]] :Generator ::''in'' Ada.Numerics.Discrete_Random [[Guide:95lrm/RM-A-5-2#I5363|A.5.2(19)]] ::''in'' Ada.Numerics.Float_Random [[Guide:95lrm/RM-A-5-2#I5340|A.5.2(7)]] :generic actual [[Guide:95lrm/RM-12-3#I4017|12.3(7)]] :generic actual parameter [[Guide:95lrm/RM-12-3#I4016|12.3(7)]] :generic actual subtype [[Guide:95lrm/RM-12-5#I4060|12.5(4)]] :generic actual type [[Guide:95lrm/RM-12-5#I4062|12.5(4)]] :generic body [[Guide:95lrm/RM-12-2#I3988|12.2(1)]] :generic contract issue [[Guide:95lrm/RM-10-2-1#I3804|10.2.1(10)]] ::[''partial''] [[Guide:95lrm/RM-3-9-1#I1999|3.9.1(3)]], [[Guide:95lrm/RM-3-10-2#I2114|3.10.2(28)]], [[Guide:95lrm/RM-3-10-2#I2122|3.10.2(32)]], [[Guide:95lrm/RM-4-6#I2636|4.6(17)]], [[Guide:95lrm/RM-4-6#I2641|4.6(20)]], [[Guide:95lrm/RM-8-3#I3225|8.3(26/1)]], [[Guide:95lrm/RM-10-2-1#I3807|10.2.1(11/1)]] :generic formal [[Guide:95lrm/RM-12-1#I3986|12.1(9)]] :generic formal object [[Guide:95lrm/RM-12-4#I4030|12.4(1)]] :generic formal package [[Guide:95lrm/RM-12-7#I4104|12.7(1)]] :generic formal subprogram [[Guide:95lrm/RM-12-6#I4091|12.6(1)]] :generic formal subtype [[Guide:95lrm/RM-12-5#I4066|12.5(5)]] :generic formal type [[Guide:95lrm/RM-12-5#I4064|12.5(5)]] :generic function [[Guide:95lrm/RM-12-1#I3985|12.1(8)]] :generic package [[Guide:95lrm/RM-12-1#I3982|12.1(8)]] :generic procedure [[Guide:95lrm/RM-12-1#I3984|12.1(8)]] :generic subprogram [[Guide:95lrm/RM-12-1#I3983|12.1(8)]] :generic unit [[Guide:95lrm/RM-12#I3960|12(1)]] ::''See also'' dispatching operation [[Guide:95lrm/RM-3-9#I1947|3.9(1)]] :Generic_Complex_Elementary_Functions ::''child of'' Ada.Numerics [[Guide:95lrm/RM-G-1-2#I6919|G.1.2(2)]] :Generic_Complex_Types ::''child of'' Ada.Numerics [[Guide:95lrm/RM-G-1-1#I6869|G.1.1(2/1)]] :Generic_Elementary_Functions ::''child of'' Ada.Numerics [[Guide:95lrm/RM-A-5-1#I5266|A.5.1(3)]] :generic_actual_part [[Guide:95lrm/RM-12-3#I4001|12.3(3)]] ::''used'' [[Guide:95lrm/RM-12-3#I4000|12.3(2)]], [[Guide:95lrm/RM-12-7#I4111|12.7(3)]], [[Guide:95lrm/RM-P#I7886|P]] :generic_association [[Guide:95lrm/RM-12-3#I4004|12.3(4)]] ::''used'' [[Guide:95lrm/RM-12-3#I4003|12.3(3)]], [[Guide:95lrm/RM-P#I7890|P]] :Generic_Bounded_Length ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5007|A.4.4(4)]] :generic_declaration [[Guide:95lrm/RM-12-1#I3965|12.1(2)]] ::''used'' [[Guide:95lrm/RM-3-1#I1275|3.1(3)]], [[Guide:95lrm/RM-10-1-1#I3691|10.1.1(5)]], [[Guide:95lrm/RM-P#I7835|P]] :generic_formal_parameter_declaration [[Guide:95lrm/RM-12-1#I3977|12.1(6)]] ::''used'' [[Guide:95lrm/RM-12-1#I3975|12.1(5)]], [[Guide:95lrm/RM-P#I7875|P]] :generic_formal_part [[Guide:95lrm/RM-12-1#I3974|12.1(5)]] ::''used'' [[Guide:95lrm/RM-12-1#I3969|12.1(3)]], [[Guide:95lrm/RM-12-1#I3972|12.1(4)]], [[Guide:95lrm/RM-P#I7873|P]] :generic_instantiation [[Guide:95lrm/RM-12-3#I3991|12.3(2)]] ::''used'' [[Guide:95lrm/RM-3-1#I1276|3.1(3)]], [[Guide:95lrm/RM-10-1-1#I3692|10.1.1(5)]], [[Guide:95lrm/RM-P#I7342|P]] :generic_package_declaration [[Guide:95lrm/RM-12-1#I3971|12.1(4)]] ::''used'' [[Guide:95lrm/RM-12-1#I3967|12.1(2)]], [[Guide:95lrm/RM-P#I7870|P]] :generic_renaming_declaration [[Guide:95lrm/RM-8-5-5#I3272|8.5.5(2)]] ::''used'' [[Guide:95lrm/RM-8-5#I3246|8.5(2)]], [[Guide:95lrm/RM-10-1-1#I3695|10.1.1(6)]], [[Guide:95lrm/RM-P#I7838|P]] :generic_subprogram_declaration [[Guide:95lrm/RM-12-1#I3968|12.1(3)]] ::''used'' [[Guide:95lrm/RM-12-1#I3966|12.1(2)]], [[Guide:95lrm/RM-P#I7869|P]] :Get ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5755|A.10.1(41)]], [[Guide:95lrm/RM-A-10-1#I5777|A.10.1(47)]], [[Guide:95lrm/RM-A-10-1#I5796|A.10.1(54)]], [[Guide:95lrm/RM-A-10-1#I5802|A.10.1(55)]], [[Guide:95lrm/RM-A-10-1#I5811|A.10.1(59)]], [[Guide:95lrm/RM-A-10-1#I5817|A.10.1(60)]], [[Guide:95lrm/RM-A-10-1#I5827|A.10.1(65)]], [[Guide:95lrm/RM-A-10-1#I5833|A.10.1(67)]], [[Guide:95lrm/RM-A-10-1#I5841|A.10.1(70)]], [[Guide:95lrm/RM-A-10-1#I5849|A.10.1(72)]], [[Guide:95lrm/RM-A-10-1#I5857|A.10.1(75)]], [[Guide:95lrm/RM-A-10-1#I5865|A.10.1(77)]], [[Guide:95lrm/RM-A-10-1#I5874|A.10.1(81)]], [[Guide:95lrm/RM-A-10-1#I5880|A.10.1(83)]] ::''in'' Ada.Text_IO.Complex_IO [[Guide:95lrm/RM-G-1-3#I6980|G.1.3(6)]], [[Guide:95lrm/RM-G-1-3#I6988|G.1.3(8)]] :Get_Immediate ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5769|A.10.1(44)]], [[Guide:95lrm/RM-A-10-1#I5771|A.10.1(45)]] :Get_Line ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5785|A.10.1(49)]] :Get_Priority ::''in'' Ada.Dynamic_Priorities [[Guide:95lrm/RM-D-5#I6585|D.5(5)]] :global to [[Guide:95lrm/RM-8-1#I3181|8.1(15)]] :Glossary [[Guide:95lrm/RM-N#I7273|N(1)]] :goto_statement [[Guide:95lrm/RM-5-8#I2871|5.8(2)]] ::''used'' [[Guide:95lrm/RM-5-1#I2777|5.1(4)]], [[Guide:95lrm/RM-P#I7601|P]] :govern a variant [[Guide:95lrm/RM-3-8-1#I1942|3.8.1(20)]] :govern a variant_part [[Guide:95lrm/RM-3-8-1#I1941|3.8.1(20)]] :grammar ::complete listing [[Guide:95lrm/RM-P#I7286|P]] ::cross reference [[Guide:95lrm/RM-P#I7965|P]] ::notation [[Guide:95lrm/RM-1-1-4#I1061|1.1.4(3)]] ::resolution of ambiguity [[Guide:95lrm/RM-8-6#I3281|8.6(3)]] ::under Syntax heading [[Guide:95lrm/RM-1-1-2#I1015|1.1.2(25)]] :graphic character ::a category of Character [[Guide:95lrm/RM-A-3-2#I4637|A.3.2(23)]] :graphic_character [[Guide:95lrm/RM-2-1#I1119|2.1(3)]] ::''used'' [[Guide:95lrm/RM-2-1#I1116|2.1(2)]], [[Guide:95lrm/RM-2-5#I1226|2.5(2)]], [[Guide:95lrm/RM-2-6#I1231|2.6(3)]], [[Guide:95lrm/RM-P#I7290|P]] :Graphic_Set ::''in'' Ada.Strings.Maps.Constants [[Guide:95lrm/RM-A-4-6#I5193|A.4.6(4)]] :Grave ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4711|A.3.3(13)]] :greater than operator [[Guide:95lrm/RM-4-4#I2361|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2513|4.5.2(1)]] :greater than or equal operator [[Guide:95lrm/RM-4-4#I2365|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2517|4.5.2(1)]] :greater-than sign [[Guide:95lrm/RM-2-1#I1159|2.1(15)]] :Greater_Than_Sign ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4703|A.3.3(10)]] :GS ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4679|A.3.3(6)]] :guard [[Guide:95lrm/RM-9-7-1#I3583|9.7.1(3)]] ::''used'' [[Guide:95lrm/RM-9-7-1#I3578|9.7.1(2)]], [[Guide:95lrm/RM-P#I7797|P]] == H == :handle ::an exception [[Guide:95lrm/RM-11#I3836|11(1)]], [[Guide:95lrm/RM-N#I7280|N(18)]] ::an exception occurrence [[Guide:95lrm/RM-11-4#I3872|11.4(1)]], [[Guide:95lrm/RM-11-4#I3879|11.4(7)]] :handled_sequence_of_statements [[Guide:95lrm/RM-11-2#I3850|11.2(2)]] ::''used'' [[Guide:95lrm/RM-5-6#I2863|5.6(2)]], [[Guide:95lrm/RM-6-3#I2952|6.3(2)]], [[Guide:95lrm/RM-7-2#I3073|7.2(2)]], [[Guide:95lrm/RM-9-1#I3341|9.1(6)]], [[Guide:95lrm/RM-9-5-2#I3441|9.5.2(3)]], [[Guide:95lrm/RM-9-5-2#I3450|9.5.2(5)]], [[Guide:95lrm/RM-P#I7698|P]] :Handling ::''child of'' Ada.Characters [[Guide:95lrm/RM-A-3-2#I4578|A.3.2(2)]] :Head ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5090|A.4.4(70)]], [[Guide:95lrm/RM-A-4-4#I5092|A.4.4(71)]] ::''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4995|A.4.3(35)]], [[Guide:95lrm/RM-A-4-3#I4997|A.4.3(36)]] ::''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5182|A.4.5(65)]], [[Guide:95lrm/RM-A-4-5#I5184|A.4.5(66)]] :head (of a queue) [[Guide:95lrm/RM-D-2-1#I6532|D.2.1(5)]] :heap management ::user-defined [[Guide:95lrm/RM-13-11#I4398|13.11(1)]] ::''See also'' allocator [[Guide:95lrm/RM-4-8#I2719|4.8(1)]] :held priority [[Guide:95lrm/RM-D-11#I6683|D.11(4)]] :heterogeneous input-output [[Guide:95lrm/RM-A-12-1#I5911|A.12.1(1)]] :hexadecimal ::literal [[Guide:95lrm/RM-2-4-2#I1210|2.4.2(1)]] :hexadecimal digit ::a category of Character [[Guide:95lrm/RM-A-3-2#I4643|A.3.2(30)]] :hexadecimal literal [[Guide:95lrm/RM-2-4-2#I1208|2.4.2(1)]] :Hexadecimal_Digit_Set ::''in'' Ada.Strings.Maps.Constants [[Guide:95lrm/RM-A-4-6#I5199|A.4.6(4)]] :hidden from all visibility [[Guide:95lrm/RM-8-3#I3202|8.3(5)]], [[Guide:95lrm/RM-8-3#I3211|8.3(14)]] ::by lack of a with_clause [[Guide:95lrm/RM-8-3#I3215|8.3(20)]] ::for a declaration completed by a subsequent declaration [[Guide:95lrm/RM-8-3#I3214|8.3(19)]] ::for overridden declaration [[Guide:95lrm/RM-8-3#I3212|8.3(15)]] ::within the declaration itself [[Guide:95lrm/RM-8-3#I3213|8.3(16)]] :hidden from direct visibility [[Guide:95lrm/RM-8-3#I3203|8.3(5)]], [[Guide:95lrm/RM-8-3#I3220|8.3(21)]] ::by an inner homograph [[Guide:95lrm/RM-8-3#I3221|8.3(22)]] ::where hidden from all visibility [[Guide:95lrm/RM-8-3#I3222|8.3(23)]] :hiding [[Guide:95lrm/RM-8-3#I3201|8.3(5)]] :High_Order_First [[Guide:95lrm/RM-13-5-3#I4286|13.5.3(2)]] ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6280|B.4(25)]] :highest precedence operator [[Guide:95lrm/RM-4-5-6#I2584|4.5.6(1)]] :highest_precedence_operator [[Guide:95lrm/RM-4-5#I2459|4.5(7)]] :Hold ::''in'' Ada.Asynchronous_Task_Control [[Guide:95lrm/RM-D-11#I6677|D.11(3)]] :homograph [[Guide:95lrm/RM-8-3#I3206|8.3(8)]] :HT ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4659|A.3.3(5)]] :HTJ ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4757|A.3.3(17)]] :HTS ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4756|A.3.3(17)]] :Hyphen ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4695|A.3.3(8)]] :hyphen-minus [[Guide:95lrm/RM-2-1#I1148|2.1(15)]] == I == :i ::''in'' Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6876|G.1.1(5)]] ::''in'' Interfaces.Fortran [[Guide:95lrm/RM-B-5#I6342|B.5(10)]] :identifier [[Guide:95lrm/RM-2-3#I1175|2.3(2)]] ::''used'' [[Guide:95lrm/RM-2-8#I1238|2.8(2)]], [[Guide:95lrm/RM-2-8#I1244|2.8(3)]], [[Guide:95lrm/RM-2-8#I1256|2.8(21)]], [[Guide:95lrm/RM-2-8#I1261|2.8(23)]], [[Guide:95lrm/RM-3-1#I1278|3.1(4)]], [[Guide:95lrm/RM-4-1#I2167|4.1(3)]], [[Guide:95lrm/RM-4-1-3#I2214|4.1.3(3)]], [[Guide:95lrm/RM-4-1-4#I2228|4.1.4(3)]], [[Guide:95lrm/RM-5-5#I2846|5.5(2)]], [[Guide:95lrm/RM-5-6#I2864|5.6(2)]], [[Guide:95lrm/RM-6-1#I2892|6.1(5)]], [[Guide:95lrm/RM-7-1#I3064|7.1(3)]], [[Guide:95lrm/RM-7-2#I3075|7.2(2)]], [[Guide:95lrm/RM-9-1#I3334|9.1(4)]], [[Guide:95lrm/RM-9-1#I3342|9.1(6)]], [[Guide:95lrm/RM-9-4#I3384|9.4(4)]], [[Guide:95lrm/RM-9-4#I3395|9.4(7)]], [[Guide:95lrm/RM-9-5-2#I3442|9.5.2(3)]], [[Guide:95lrm/RM-9-5-2#I3451|9.5.2(5)]], [[Guide:95lrm/RM-11-5#I3922|11.5(4)]], [[Guide:95lrm/RM-13-12#I4465|13.12(4)]], [[Guide:95lrm/RM-B-1#I6036|B.1(5)]], [[Guide:95lrm/RM-B-1#I6042|B.1(6)]], [[Guide:95lrm/RM-B-1#I6048|B.1(7)]], [[Guide:95lrm/RM-D-2-2#I6545|D.2.2(2)]], [[Guide:95lrm/RM-D-2-2#I6546|D.2.2(3)]], [[Guide:95lrm/RM-D-3#I6557|D.3(3)]], [[Guide:95lrm/RM-D-3#I6559|D.3(4)]], [[Guide:95lrm/RM-D-4#I6572|D.4(3)]], [[Guide:95lrm/RM-D-4#I6573|D.4(4)]], [[Guide:95lrm/RM-L#I7165|L(8)]], [[Guide:95lrm/RM-L#I7183|L(13)]], [[Guide:95lrm/RM-L#I7189|L(14)]], [[Guide:95lrm/RM-L#I7212|L(20)]], [[Guide:95lrm/RM-L#I7215|L(21)]], [[Guide:95lrm/RM-L#I7220|L(23)]], [[Guide:95lrm/RM-L#I7237|L(29)]], [[Guide:95lrm/RM-L#I7258|L(36)]], [[Guide:95lrm/RM-L#I7262|L(37)]], [[Guide:95lrm/RM-M#I7271|M(95)]], [[Guide:95lrm/RM-M#I7272|M(98)]], [[Guide:95lrm/RM-P#I7330|P]] :identifier specific to a pragma [[Guide:95lrm/RM-2-8#I1250|2.8(10)]] :identifier_letter [[Guide:95lrm/RM-2-1#I1125|2.1(7)]] ::''used'' [[Guide:95lrm/RM-2-1#I1120|2.1(3)]], [[Guide:95lrm/RM-2-3#I1176|2.3(2)]], [[Guide:95lrm/RM-2-3#I1180|2.3(3)]], [[Guide:95lrm/RM-P#I7293|P]] :Identity ::''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4929|A.4.2(22)]] ::''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5246|A.4.7(22)]] :Identity attribute [[Guide:95lrm/RM-11-4-1#I3912|11.4.1(9)]], [[Guide:95lrm/RM-C-7-1#I6481|C.7.1(12)]] :idle task [[Guide:95lrm/RM-D-11#I6684|D.11(4)]] :if_statement [[Guide:95lrm/RM-5-3#I2819|5.3(2)]] ::''used'' [[Guide:95lrm/RM-5-1#I2787|5.1(5)]], [[Guide:95lrm/RM-P#I7610|P]] :illegal ::construct [[Guide:95lrm/RM-1-1-2#I1026|1.1.2(27)]] ::partition [[Guide:95lrm/RM-1-1-2#I1034|1.1.2(29)]] :Im ::''in'' Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6881|G.1.1(6)]] :image ::of a value [[Guide:95lrm/RM-3-5#I1546|3.5(30)]], [[Guide:95lrm/RM-K#I7142|K(273)]] ::''in'' Ada.Numerics.Discrete_Random [[Guide:95lrm/RM-A-5-2#I5378|A.5.2(26)]] ::''in'' Ada.Numerics.Float_Random [[Guide:95lrm/RM-A-5-2#I5356|A.5.2(14)]] ::''in'' Ada.Task_Identification [[Guide:95lrm/RM-C-7-1#I6471|C.7.1(3/1)]] ::''in'' Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6857|F.3.3(13)]] :Image attribute [[Guide:95lrm/RM-3-5#I1549|3.5(35)]] :Imaginary ::''in'' Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6875|G.1.1(4)]] ::''in'' Interfaces.Fortran [[Guide:95lrm/RM-B-5#I6341|B.5(10)]] :immediate scope ::of (a view of) an entity [[Guide:95lrm/RM-8-2#I3190|8.2(11)]] ::of a declaration [[Guide:95lrm/RM-8-2#I3182|8.2(2)]] :immediately enclosing [[Guide:95lrm/RM-8-1#I3178|8.1(13)]] :immediately visible [[Guide:95lrm/RM-8-3#I3199|8.3(4)]], [[Guide:95lrm/RM-8-3#I3217|8.3(21)]] :immediately within [[Guide:95lrm/RM-8-1#I3176|8.1(13)]] :implementation advice [[Guide:95lrm/RM-1-1-2#I1047|1.1.2(37)]] :implementation defined [[Guide:95lrm/RM-1-1-3#I1054|1.1.3(18)]] ::summary of characteristics [[Guide:95lrm/RM-M#I7269|M(1)]] :implementation permissions [[Guide:95lrm/RM-1-1-2#I1046|1.1.2(36)]] :implementation requirements [[Guide:95lrm/RM-1-1-2#I1043|1.1.2(33)]] :implementation-dependent ::''See'' unspecified [[Guide:95lrm/RM-1-1-3#I1057|1.1.3(18)]] :implicit declaration [[Guide:95lrm/RM-3-1#I1281|3.1(5)]], [[Guide:95lrm/RM-N#I7277|N(11)]] :implicit initial values ::for a subtype [[Guide:95lrm/RM-3-3-1#I1429|3.3.1(10)]] :implicit subtype conversion [[Guide:95lrm/RM-4-6#I2698|4.6(59)]], [[Guide:95lrm/RM-4-6#I2699|4.6(60)]] ::Access attribute [[Guide:95lrm/RM-3-10-2#I2118|3.10.2(30)]] ::access discriminant [[Guide:95lrm/RM-3-7#I1870|3.7(27)]] ::array bounds [[Guide:95lrm/RM-4-6#I2664|4.6(38)]] ::array index [[Guide:95lrm/RM-4-1-1#I2195|4.1.1(7)]] ::assignment to view conversion [[Guide:95lrm/RM-4-6#I2694|4.6(55)]] ::assignment_statement [[Guide:95lrm/RM-5-2#I2815|5.2(11)]] ::bounds of a decimal fixed point type [[Guide:95lrm/RM-3-5-9#I1735|3.5.9(16)]] ::bounds of a fixed point type [[Guide:95lrm/RM-3-5-9#I1731|3.5.9(14)]] ::bounds of a range [[Guide:95lrm/RM-3-5#I1516|3.5(9)]], [[Guide:95lrm/RM-3-6#I1798|3.6(18)]] ::choices of aggregate [[Guide:95lrm/RM-4-3-3#I2324|4.3.3(22)]] ::component defaults [[Guide:95lrm/RM-3-3-1#I1430|3.3.1(13)]] ::delay expression [[Guide:95lrm/RM-9-6#I3564|9.6(20)]] ::derived type discriminants [[Guide:95lrm/RM-3-4#I1465|3.4(21)]] ::discriminant values [[Guide:95lrm/RM-3-7-1#I1887|3.7.1(12)]] ::entry index [[Guide:95lrm/RM-9-5-2#I3476|9.5.2(24)]] ::expressions in aggregate [[Guide:95lrm/RM-4-3-1#I2285|4.3.1(19)]] ::expressions of aggregate [[Guide:95lrm/RM-4-3-3#I2325|4.3.3(23)]] ::function return [[Guide:95lrm/RM-6-5#I3040|6.5(6)]] ::generic formal object of mode in [[Guide:95lrm/RM-12-4#I4044|12.4(11)]] ::inherited enumeration literal [[Guide:95lrm/RM-3-4#I1471|3.4(29)]] ::initialization expression [[Guide:95lrm/RM-3-3-1#I1432|3.3.1(17)]] ::initialization expression of allocator [[Guide:95lrm/RM-4-8#I2731|4.8(7)]] ::named number value [[Guide:95lrm/RM-3-3-2#I1443|3.3.2(6)]] ::operand of concatenation [[Guide:95lrm/RM-4-5-3#I2552|4.5.3(9)]] ::parameter passing [[Guide:95lrm/RM-6-4-1#I3022|6.4.1(10)]], [[Guide:95lrm/RM-6-4-1#I3024|6.4.1(11)]], [[Guide:95lrm/RM-6-4-1#I3032|6.4.1(17)]] ::pragma Interrupt_Priority [[Guide:95lrm/RM-D-1#I6526|D.1(17)]], [[Guide:95lrm/RM-D-3#I6565|D.3(9)]] ::pragma Priority [[Guide:95lrm/RM-D-1#I6525|D.1(17)]], [[Guide:95lrm/RM-D-3#I6564|D.3(9)]] ::qualified_expression [[Guide:95lrm/RM-4-7#I2715|4.7(4)]] ::reading a view conversion [[Guide:95lrm/RM-4-6#I2695|4.6(56)]] ::result of inherited function [[Guide:95lrm/RM-3-4#I1469|3.4(27)]] :implicit_dereference [[Guide:95lrm/RM-4-1#I2174|4.1(6)]] ::''used'' [[Guide:95lrm/RM-4-1#I2171|4.1(4)]], [[Guide:95lrm/RM-P#I7501|P]] :Import pragma [[Guide:95lrm/RM-B-1#I6035|B.1(5)]], [[Guide:95lrm/RM-L#I7188|L(14)]] :imported ::aspect of representation [[Guide:95lrm/RM-B-1#I6071|B.1(28)]] :imported entity [[Guide:95lrm/RM-B-1#I6060|B.1(23)]] :in (membership test) [[Guide:95lrm/RM-4-4#I2367|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2521|4.5.2(2)]] :inaccessible partition [[Guide:95lrm/RM-E-1#I6699|E.1(7)]] :inactive ::a task state [[Guide:95lrm/RM-9#I3315|9(10)]] :included ::one range in another [[Guide:95lrm/RM-3-5#I1505|3.5(4)]] :incomplete type [[Guide:95lrm/RM-3-10-1#I2092|3.10.1(11)]] :incomplete_type_declaration [[Guide:95lrm/RM-3-10-1#I2087|3.10.1(2)]] ::''used'' [[Guide:95lrm/RM-3-2-1#I1325|3.2.1(2)]], [[Guide:95lrm/RM-P#I7345|P]] :Increment ::''in'' Interfaces.C.Pointers [[Guide:95lrm/RM-B-3-2#I6221|B.3.2(11)]] :indefinite subtype [[Guide:95lrm/RM-3-3#I1396|3.3(23)]], [[Guide:95lrm/RM-3-7#I1869|3.7(26)]] :independent subprogram [[Guide:95lrm/RM-11-6#I3956|11.6(6)]] :independently addressable [[Guide:95lrm/RM-9-10#I3662|9.10(1)]] :index ::of an element of an open direct file [[Guide:95lrm/RM-A-8#I5500|A.8(3)]] ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5584|A.8.4(15)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5961|A.12.1(23)]] ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5042|A.4.4(44)]], [[Guide:95lrm/RM-A-4-4#I5044|A.4.4(45)]], [[Guide:95lrm/RM-A-4-4#I5046|A.4.4(46)]] ::''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4947|A.4.3(9)]], [[Guide:95lrm/RM-A-4-3#I4949|A.4.3(10)]], [[Guide:95lrm/RM-A-4-3#I4951|A.4.3(11)]] ::''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5134|A.4.5(39)]], [[Guide:95lrm/RM-A-4-5#I5136|A.4.5(40)]], [[Guide:95lrm/RM-A-4-5#I5138|A.4.5(41)]] :index range [[Guide:95lrm/RM-3-6#I1788|3.6(13)]] :index subtype [[Guide:95lrm/RM-3-6#I1782|3.6(9)]] :index type [[Guide:95lrm/RM-3-6#I1783|3.6(9)]] :Index_Check [[Guide:95lrm/RM-11-5#I3931|11.5(14)]] ::[''partial''] [[Guide:95lrm/RM-4-1-1#I2196|4.1.1(7)]], [[Guide:95lrm/RM-4-1-2#I2205|4.1.2(7)]], [[Guide:95lrm/RM-4-3-3#I2329|4.3.3(29)]], [[Guide:95lrm/RM-4-3-3#I2331|4.3.3(30)]], [[Guide:95lrm/RM-4-5-3#I2549|4.5.3(8)]], [[Guide:95lrm/RM-4-6#I2685|4.6(51)]], [[Guide:95lrm/RM-4-7#I2713|4.7(4)]], [[Guide:95lrm/RM-4-8#I2735|4.8(10/1)]] :index_constraint [[Guide:95lrm/RM-3-6-1#I1803|3.6.1(2)]] ::''used'' [[Guide:95lrm/RM-3-2-2#I1368|3.2.2(7)]], [[Guide:95lrm/RM-P#I7370|P]] :Index_Error ::''in'' Ada.Strings [[Guide:95lrm/RM-A-4-1#I4886|A.4.1(5)]] :Index_Non_Blank ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5048|A.4.4(47)]] ::''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4953|A.4.3(12)]] ::''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5140|A.4.5(42)]] :index_subtype_definition [[Guide:95lrm/RM-3-6#I1770|3.6(4)]] ::''used'' [[Guide:95lrm/RM-3-6#I1768|3.6(3)]], [[Guide:95lrm/RM-P#I7417|P]] :indexed_component [[Guide:95lrm/RM-4-1-1#I2188|4.1.1(2)]] ::''used'' [[Guide:95lrm/RM-4-1#I2159|4.1(2)]], [[Guide:95lrm/RM-P#I7491|P]] :indivisible [[Guide:95lrm/RM-C-6#I6451|C.6(10)]] :information hiding ::''See'' package [[Guide:95lrm/RM-7#I3053|7(1)]] ::''See'' private types and private extensions [[Guide:95lrm/RM-7-3#I3079|7.3(1)]] :information systems [[Guide:95lrm/RM-C#I6365|C(1)]], [[Guide:95lrm/RM-F#I6815|F(1)]] :informative [[Guide:95lrm/RM-1-1-2#I1011|1.1.2(18)]] :inheritance ::''See'' derived types and classes [[Guide:95lrm/RM-3-4#I1446|3.4(1)]] ::''See also'' tagged types and type extension [[Guide:95lrm/RM-3-9#I1951|3.9(1)]] :inherited ::from an ancestor type [[Guide:95lrm/RM-3-4-1#I1487|3.4.1(11)]] :inherited component [[Guide:95lrm/RM-3-4#I1457|3.4(11)]], [[Guide:95lrm/RM-3-4#I1458|3.4(12)]] :inherited discriminant [[Guide:95lrm/RM-3-4#I1456|3.4(11)]] :inherited entry [[Guide:95lrm/RM-3-4#I1460|3.4(12)]] :inherited protected subprogram [[Guide:95lrm/RM-3-4#I1459|3.4(12)]] :inherited subprogram [[Guide:95lrm/RM-3-4#I1461|3.4(17)]] :initialization ::of a protected object [[Guide:95lrm/RM-9-4#I3407|9.4(14)]] ::of a protected object [[Guide:95lrm/RM-C-3-1#I6391|C.3.1(10)]], [[Guide:95lrm/RM-C-3-1#I6395|C.3.1(11)]] ::of a task object [[Guide:95lrm/RM-9-1#I3349|9.1(12/1)]], [[Guide:95lrm/RM-J-7-1#I7094|J.7.1(7)]] ::of an object [[Guide:95lrm/RM-3-3-1#I1433|3.3.1(19)]] :initialization expression [[Guide:95lrm/RM-3-3-1#I1401|3.3.1(1)]], [[Guide:95lrm/RM-3-3-1#I1418|3.3.1(4)]] :Initialize [[Guide:95lrm/RM-7-6#I3124|7.6(2)]] ::''in'' Ada.Finalization [[Guide:95lrm/RM-7-6#I3133|7.6(6)]], [[Guide:95lrm/RM-7-6#I3141|7.6(8)]] :initialized allocator [[Guide:95lrm/RM-4-8#I2724|4.8(4)]] :Inline pragma [[Guide:95lrm/RM-6-3-2#I2990|6.3.2(3)]], [[Guide:95lrm/RM-L#I7194|L(15)]] :innermost dynamically enclosing [[Guide:95lrm/RM-11-4#I3876|11.4(2)]] :input [[Guide:95lrm/RM-A-6#I5484|A.6(1)]] :Input attribute [[Guide:95lrm/RM-13-13-2#I4500|13.13.2(22)]], [[Guide:95lrm/RM-13-13-2#I4504|13.13.2(32)]] :Input clause [[Guide:95lrm/RM-13-3#I4189|13.3(7)]], [[Guide:95lrm/RM-13-13-2#I4515|13.13.2(36/1)]] :input-output ::unspecified for access types [[Guide:95lrm/RM-A-7#I5491|A.7(6)]] :Insert ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5070|A.4.4(60)]], [[Guide:95lrm/RM-A-4-4#I5072|A.4.4(61)]] ::''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4975|A.4.3(25)]], [[Guide:95lrm/RM-A-4-3#I4977|A.4.3(26)]] ::''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5162|A.4.5(55)]], [[Guide:95lrm/RM-A-4-5#I5164|A.4.5(56)]] :inspectable object [[Guide:95lrm/RM-H-3-2#I7055|H.3.2(5/1)]] :inspection point [[Guide:95lrm/RM-H-3-2#I7054|H.3.2(5/1)]] :Inspection_Point pragma [[Guide:95lrm/RM-H-3-2#I7051|H.3.2(3)]], [[Guide:95lrm/RM-L#I7198|L(16)]] :instance ::of a generic function [[Guide:95lrm/RM-12-3#I4026|12.3(13)]] ::of a generic package [[Guide:95lrm/RM-12-3#I4023|12.3(13)]] ::of a generic procedure [[Guide:95lrm/RM-12-3#I4025|12.3(13)]] ::of a generic subprogram [[Guide:95lrm/RM-12-3#I4024|12.3(13)]] ::of a generic unit [[Guide:95lrm/RM-12-3#I3990|12.3(1)]] :instructions for comment submission [[Guide:95lrm/RM-0-3#I1003|0.3(58/1)]] :int ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6102|B.3(7)]] :Integer [[Guide:95lrm/RM-3-5-4#I1625|3.5.4(11)]], [[Guide:95lrm/RM-3-5-4#I1643|3.5.4(21)]] ::''in'' Standard [[Guide:95lrm/RM-A-1#I4552|A.1(12)]] :integer literal [[Guide:95lrm/RM-2-4#I1185|2.4(1)]] :integer literals [[Guide:95lrm/RM-3-5-4#I1632|3.5.4(14)]], [[Guide:95lrm/RM-3-5-4#I1652|3.5.4(30)]] :integer type [[Guide:95lrm/RM-3-5-4#I1602|3.5.4(1)]] :Integer_Text_IO ::''child of'' Ada [[Guide:95lrm/RM-A-10-8#I5896|A.10.8(21)]] :Integer_Wide_Text_IO ::''child of'' Ada [[Guide:95lrm/RM-A-11#I5905|A.11(3)]] :Integer_Address ::''in'' System.Storage_Elements [[Guide:95lrm/RM-13-7-1#I4341|13.7.1(10)]] :Integer_IO ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5790|A.10.1(52)]] :integer_type_definition [[Guide:95lrm/RM-3-5-4#I1606|3.5.4(2)]] ::''used'' [[Guide:95lrm/RM-3-2-1#I1336|3.2.1(4)]], [[Guide:95lrm/RM-P#I7354|P]] :interaction ::between tasks [[Guide:95lrm/RM-9#I3307|9(1)]] :interface to assembly language [[Guide:95lrm/RM-C-1#I6367|C.1(4)]] :interface to C [[Guide:95lrm/RM-B-3#I6092|B.3(1/1)]] :interface to COBOL [[Guide:95lrm/RM-B-4#I6236|B.4(1)]] :interface to Fortran [[Guide:95lrm/RM-B-5#I6325|B.5(1)]] :interface to other languages [[Guide:95lrm/RM-B#I6023|B(1)]] :Interfaces [[Guide:95lrm/RM-B-2#I6089|B.2(3)]] :Interfaces.C [[Guide:95lrm/RM-B-3#I6096|B.3(4)]] :Interfaces.C.Pointers [[Guide:95lrm/RM-B-3-2#I6212|B.3.2(4)]] :Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6172|B.3.1(3)]] :Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6240|B.4(7)]] :Interfaces.Fortran [[Guide:95lrm/RM-B-5#I6329|B.5(4)]] :interfacing pragma [[Guide:95lrm/RM-B-1#I6026|B.1(4)]] ::Convention [[Guide:95lrm/RM-B-1#I6031|B.1(4)]] ::Export [[Guide:95lrm/RM-B-1#I6029|B.1(4)]] ::Import [[Guide:95lrm/RM-B-1#I6027|B.1(4)]] :internal call [[Guide:95lrm/RM-9-5#I3415|9.5(3)]] :internal code [[Guide:95lrm/RM-13-4#I4247|13.4(7)]] :internal requeue [[Guide:95lrm/RM-9-5#I3418|9.5(7)]] :Internal_Tag ::''in'' Ada.Tags [[Guide:95lrm/RM-3-9#I1974|3.9(7)]] :interpretation ::of a complete context [[Guide:95lrm/RM-8-6#I3283|8.6(10)]] ::of a constituent of a complete context [[Guide:95lrm/RM-8-6#I3289|8.6(15)]] ::overload resolution [[Guide:95lrm/RM-8-6#I3288|8.6(14)]] :interrupt [[Guide:95lrm/RM-C-3#I6373|C.3(2)]] ::example using asynchronous_select [[Guide:95lrm/RM-9-7-4#I3627|9.7.4(10)]], [[Guide:95lrm/RM-9-7-4#I3632|9.7.4(12)]] :interrupt entry [[Guide:95lrm/RM-J-7-1#I7090|J.7.1(5)]] :interrupt handler [[Guide:95lrm/RM-C-3#I6381|C.3(2)]] :Interrupt_Handler pragma [[Guide:95lrm/RM-C-3-1#I6384|C.3.1(2)]], [[Guide:95lrm/RM-L#I7202|L(17)]] :Interrupt_ID ::''in'' Ada.Interrupts [[Guide:95lrm/RM-C-3-2#I6407|C.3.2(2)]] :Interrupt_Priority ::''in'' System [[Guide:95lrm/RM-13-7#I4326|13.7(16)]] :Interrupt_Priority pragma [[Guide:95lrm/RM-D-1#I6515|D.1(5)]], [[Guide:95lrm/RM-L#I7205|L(18)]] :Interrupts ::''child of'' Ada [[Guide:95lrm/RM-C-3-2#I6403|C.3.2(2)]] :intertask communication [[Guide:95lrm/RM-9-5#I3412|9.5(1)]] ::''See also'' task [[Guide:95lrm/RM-9#I3311|9(1)]] :Intrinsic calling convention [[Guide:95lrm/RM-6-3-1#I2966|6.3.1(4)]] :invalid representation [[Guide:95lrm/RM-13-9-1#I4384|13.9.1(9)]] :Inverted_Exclamation ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4782|A.3.3(21)]] :Inverted_Question ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4814|A.3.3(22)]] :IO_Exceptions ::''child of'' Ada [[Guide:95lrm/RM-A-13#I5990|A.13(3)]] :IS1 ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4747|A.3.3(16)]] :IS2 ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4746|A.3.3(16)]] :IS3 ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4745|A.3.3(16)]] :IS4 ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4744|A.3.3(16)]] :Is_Alphanumeric ::''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4600|A.3.2(4)]] :Is_Attached ::''in'' Ada.Interrupts [[Guide:95lrm/RM-C-3-2#I6413|C.3.2(5)]] :Is_Basic ::''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4592|A.3.2(4)]] :Is_Callable ::''in'' Ada.Task_Identification [[Guide:95lrm/RM-C-7-1#I6479|C.7.1(4)]] :Is_Character ::''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4625|A.3.2(14)]] :Is_Control ::''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4582|A.3.2(4)]] :Is_Decimal_Digit ::''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4596|A.3.2(4)]] :Is_Digit ::''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4594|A.3.2(4)]] :Is_Graphic ::''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4584|A.3.2(4)]] :Is_Held ::''in'' Ada.Asynchronous_Task_Control [[Guide:95lrm/RM-D-11#I6681|D.11(3)]] :Is_Hexadecimal_Digit ::''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4598|A.3.2(4)]] :Is_In ::''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4915|A.4.2(13)]] ::''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5232|A.4.7(13)]] :Is_ISO_646 ::''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4617|A.3.2(10)]] :Is_Letter ::''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4586|A.3.2(4)]] :Is_Lower ::''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4588|A.3.2(4)]] :Is_Nul_Terminated ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6139|B.3(24)]], [[Guide:95lrm/RM-B-3#I6158|B.3(35)]] :Is_Open ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5572|A.8.4(10)]] ::''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5529|A.8.1(10)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5945|A.12.1(12)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5653|A.10.1(13)]] :Is_Reserved ::''in'' Ada.Interrupts [[Guide:95lrm/RM-C-3-2#I6411|C.3.2(4)]] :Is_Special ::''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4602|A.3.2(4)]] :Is_String ::''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4627|A.3.2(14)]] :Is_Subset ::''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4917|A.4.2(14)]] ::''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5234|A.4.7(14)]] :Is_Terminated ::''in'' Ada.Task_Identification [[Guide:95lrm/RM-C-7-1#I6477|C.7.1(4)]] :Is_Upper ::''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4590|A.3.2(4)]] :ISO 10646 [[Guide:95lrm/RM-3-5-2#I1590|3.5.2(2)]], [[Guide:95lrm/RM-3-5-2#I1595|3.5.2(3)]] :ISO 1989:1985 [[Guide:95lrm/RM-1-2#I1094|1.2(4)]] :ISO/IEC 10646-1:1993 [[Guide:95lrm/RM-1-2#I1106|1.2(8/1)]] :ISO/IEC 1539:1991 [[Guide:95lrm/RM-1-2#I1091|1.2(3)]] :ISO/IEC 6429:1992 [[Guide:95lrm/RM-1-2#I1097|1.2(5)]] :ISO/IEC 646:1991 [[Guide:95lrm/RM-1-2#I1088|1.2(2)]] :ISO/IEC 8859-1:1987 [[Guide:95lrm/RM-1-2#I1100|1.2(6)]] :ISO/IEC 9899:1990 [[Guide:95lrm/RM-1-2#I1103|1.2(7)]] :ISO_646 ::''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4615|A.3.2(9)]] :ISO_646_Set ::''in'' Ada.Strings.Maps.Constants [[Guide:95lrm/RM-A-4-6#I5202|A.4.6(4)]] :issue ::an entry call [[Guide:95lrm/RM-9-5-3#I3497|9.5.3(8)]] :italics ::nongraphic characters [[Guide:95lrm/RM-3-5-2#I1592|3.5.2(2)]] ::pseudo-names of anonymous types [[Guide:95lrm/RM-3-2-1#I1345|3.2.1(7)]], [[Guide:95lrm/RM-A-1#I4546|A.1(2)]] ::syntax rules [[Guide:95lrm/RM-1-1-4#I1065|1.1.4(14)]] ::terms introduced or defined [[Guide:95lrm/RM-1-3#I1109|1.3(1)]] :iteration_scheme [[Guide:95lrm/RM-5-5#I2847|5.5(3)]] ::''used'' [[Guide:95lrm/RM-5-5#I2844|5.5(2)]], [[Guide:95lrm/RM-P#I7632|P]] == J == :j ::''in'' Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6877|G.1.1(5)]] ::''in'' Interfaces.Fortran [[Guide:95lrm/RM-B-5#I6343|B.5(10)]] == K == :known discriminants [[Guide:95lrm/RM-3-7#I1862|3.7(26)]] :known_discriminant_part [[Guide:95lrm/RM-3-7#I1842|3.7(4)]] ::''used'' [[Guide:95lrm/RM-3-2-1#I1330|3.2.1(3)]], [[Guide:95lrm/RM-3-7#I1840|3.7(2)]], [[Guide:95lrm/RM-9-1#I3326|9.1(2)]], [[Guide:95lrm/RM-9-4#I3376|9.4(2)]], [[Guide:95lrm/RM-P#I7733|P]] == L == :label [[Guide:95lrm/RM-5-1#I2794|5.1(7)]] ::''used'' [[Guide:95lrm/RM-5-1#I2769|5.1(3)]], [[Guide:95lrm/RM-P#I7594|P]] :language ::interface to assembly [[Guide:95lrm/RM-C-1#I6368|C.1(4)]] ::interface to non-Ada [[Guide:95lrm/RM-B#I6024|B(1)]] :language-defined check [[Guide:95lrm/RM-11-5#I3914|11.5(2)]], [[Guide:95lrm/RM-11-6#I3946|11.6(1)]] :language-defined class ::[''partial''] [[Guide:95lrm/RM-3-2#I1322|3.2(10)]] ::of types [[Guide:95lrm/RM-3-2#I1300|3.2(2)]] :Language-Defined Library Units [[Guide:95lrm/RM-A#I4543|A(1)]] ::Ada [[Guide:95lrm/RM-A-2#I4573|A.2(2)]] ::Ada.Asynchronous_Task_Control [[Guide:95lrm/RM-D-11#I6674|D.11(3)]] ::Ada.Calendar [[Guide:95lrm/RM-9-6#I3538|9.6(10)]] ::Ada.Characters [[Guide:95lrm/RM-A-3-1#I4576|A.3.1(2)]] ::Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4579|A.3.2(2)]] ::Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4647|A.3.3(3)]] ::Ada.Command_Line [[Guide:95lrm/RM-A-15#I6006|A.15(3)]] ::Ada.Decimal [[Guide:95lrm/RM-F-2#I6819|F.2(2)]] ::Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5544|A.8.4(2)]] ::Ada.Dynamic_Priorities [[Guide:95lrm/RM-D-5#I6580|D.5(3)]] ::Ada.Exceptions [[Guide:95lrm/RM-11-4-1#I3883|11.4.1(2)]] ::Ada.Finalization [[Guide:95lrm/RM-7-6#I3128|7.6(4/1)]] ::Ada.Float_Text_IO [[Guide:95lrm/RM-A-10-9#I5900|A.10.9(33)]] ::Ada.Float_Wide_Text_IO [[Guide:95lrm/RM-A-11#I5909|A.11(3)]] ::Ada.Integer_Text_IO [[Guide:95lrm/RM-A-10-8#I5897|A.10.8(21)]] ::Ada.Integer_Wide_Text_IO [[Guide:95lrm/RM-A-11#I5906|A.11(3)]] ::Ada.Interrupts [[Guide:95lrm/RM-C-3-2#I6404|C.3.2(2)]] ::Ada.Interrupts.Names [[Guide:95lrm/RM-C-3-2#I6425|C.3.2(12)]] ::Ada.IO_Exceptions [[Guide:95lrm/RM-A-13#I5991|A.13(3)]] ::Ada.Numerics [[Guide:95lrm/RM-A-5#I5261|A.5(3)]] ::Ada.Numerics.Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6964|G.1.2(9/1)]] ::Ada.Numerics.Complex_Types [[Guide:95lrm/RM-G-1-1#I6912|G.1.1(25/1)]] ::Ada.Numerics.Discrete_Random [[Guide:95lrm/RM-A-5-2#I5360|A.5.2(17)]] ::Ada.Numerics.Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5327|A.5.1(9/1)]] ::Ada.Numerics.Float_Random [[Guide:95lrm/RM-A-5-2#I5337|A.5.2(5)]] ::Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6920|G.1.2(2)]] ::Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6870|G.1.1(2/1)]] ::Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5267|A.5.1(3)]] ::Ada.Real_Time [[Guide:95lrm/RM-D-8#I6615|D.8(3)]] ::Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5504|A.8.1(2)]] ::Ada.Storage_IO [[Guide:95lrm/RM-A-9#I5597|A.9(3)]] ::Ada.Streams [[Guide:95lrm/RM-13-13-1#I4473|13.13.1(2)]] ::Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5915|A.12.1(3)]] ::Ada.Strings [[Guide:95lrm/RM-A-4-1#I4880|A.4.1(3)]] ::Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5005|A.4.4(3)]] ::Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4942|A.4.3(5)]] ::Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4899|A.4.2(3)]] ::Ada.Strings.Maps.Constants [[Guide:95lrm/RM-A-4-6#I5190|A.4.6(3)]] ::Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5104|A.4.5(3)]] ::Ada.Strings.Wide_Bounded [[Guide:95lrm/RM-A-4-7#I5210|A.4.7(1)]] ::Ada.Strings.Wide_Fixed [[Guide:95lrm/RM-A-4-7#I5207|A.4.7(1)]] ::Ada.Strings.Wide_Maps.Wide_Constants [[Guide:95lrm/RM-A-4-7#I5256|A.4.7(28)]] ::Ada.Strings.Wide_Unbounded [[Guide:95lrm/RM-A-4-7#I5213|A.4.7(1)]] ::Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5216|A.4.7(3)]] ::Ada.Synchronous_Task_Control [[Guide:95lrm/RM-D-10#I6658|D.10(3)]] ::Ada.Tags [[Guide:95lrm/RM-3-9#I1965|3.9(6)]] ::Ada.Task_Attributes [[Guide:95lrm/RM-C-7-2#I6491|C.7.2(2)]] ::Ada.Task_Identification [[Guide:95lrm/RM-C-7-1#I6464|C.7.1(2)]] ::Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5620|A.10.1(2)]] ::Ada.Text_IO.Complex_IO [[Guide:95lrm/RM-G-1-3#I6974|G.1.3(3)]] ::Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6833|F.3.3(3)]] ::Ada.Text_IO.Text_Streams [[Guide:95lrm/RM-A-12-2#I5977|A.12.2(3)]] ::Ada.Unchecked_Conversion [[Guide:95lrm/RM-13-9#I4371|13.9(3)]] ::Ada.Unchecked_Deallocation [[Guide:95lrm/RM-13-11-2#I4440|13.11.2(3)]] ::Ada.Wide_Text_IO [[Guide:95lrm/RM-A-11#I5903|A.11(2)]] ::Ada.Wide_Text_IO.Complex_IO [[Guide:95lrm/RM-G-1-4#I6993|G.1.4(1)]] ::Ada.Wide_Text_IO.Editing [[Guide:95lrm/RM-F-3-4#I6866|F.3.4(1)]] ::Ada.Wide_Text_IO.Text_Streams [[Guide:95lrm/RM-A-12-3#I5984|A.12.3(3)]] ::Interfaces [[Guide:95lrm/RM-B-2#I6088|B.2(3)]] ::Interfaces.C [[Guide:95lrm/RM-B-3#I6095|B.3(4)]] ::Interfaces.C.Pointers [[Guide:95lrm/RM-B-3-2#I6211|B.3.2(4)]] ::Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6171|B.3.1(3)]] ::Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6239|B.4(7)]] ::Interfaces.Fortran [[Guide:95lrm/RM-B-5#I6328|B.5(4)]] ::Standard [[Guide:95lrm/RM-A-1#I4547|A.1(4)]] ::System [[Guide:95lrm/RM-13-7#I4300|13.7(3)]] ::System.Address_To_Access_Conversions [[Guide:95lrm/RM-13-7-2#I4350|13.7.2(2)]] ::System.Machine_Code [[Guide:95lrm/RM-13-8#I4363|13.8(7)]] ::System.RPC [[Guide:95lrm/RM-E-5#I6792|E.5(3)]] ::System.Storage_Elements [[Guide:95lrm/RM-13-7-1#I4330|13.7.1(2)]] ::System.Storage_Pools [[Guide:95lrm/RM-13-11#I4400|13.11(5)]] :Language-Defined Subprogram :::Abort_Task ''in'' Ada.Task_Identification [[Guide:95lrm/RM-C-7-1#I6474|C.7.1(3/1)]] ::Adjust ''in'' Ada.Finalization [[Guide:95lrm/RM-7-6#I3134|7.6(6)]] ::Allocate ''in'' System.Storage_Pools [[Guide:95lrm/RM-13-11#I4404|13.11(7)]] ::Append ''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5019|A.4.4(13)]], [[Guide:95lrm/RM-A-4-4#I5021|A.4.4(14)]], [[Guide:95lrm/RM-A-4-4#I5023|A.4.4(15)]], [[Guide:95lrm/RM-A-4-4#I5025|A.4.4(16)]], [[Guide:95lrm/RM-A-4-4#I5027|A.4.4(17)]], [[Guide:95lrm/RM-A-4-4#I5029|A.4.4(18)]], [[Guide:95lrm/RM-A-4-4#I5031|A.4.4(19)]], [[Guide:95lrm/RM-A-4-4#I5033|A.4.4(20)]] ::Append ''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5121|A.4.5(12)]], [[Guide:95lrm/RM-A-4-5#I5123|A.4.5(13)]], [[Guide:95lrm/RM-A-4-5#I5125|A.4.5(14)]] ::Arccos ''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6940|G.1.2(5)]] ::Arccos ''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5299|A.5.1(6)]] ::Arccosh ''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6956|G.1.2(7)]] ::Arccosh ''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5319|A.5.1(7)]] ::Arccot ''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6944|G.1.2(5)]] ::Arccot ''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5307|A.5.1(6)]] ::Arccoth ''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6960|G.1.2(7)]] ::Arccoth ''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5323|A.5.1(7)]] ::Arcsin ''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6938|G.1.2(5)]] ::Arcsin ''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5293|A.5.1(6)]] ::Arcsinh ''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6954|G.1.2(7)]] ::Arcsinh ''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5317|A.5.1(7)]] ::Arctan ''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6942|G.1.2(5)]] ::Arctan ''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5301|A.5.1(6)]] ::Arctanh ''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6958|G.1.2(7)]] ::Arctanh ''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5321|A.5.1(7)]] ::Argument ''in'' Ada.Command_Line [[Guide:95lrm/RM-A-15#I6010|A.15(5)]] ::Argument ''in'' Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6898|G.1.1(10)]] ::Argument_Count ''in'' Ada.Command_Line [[Guide:95lrm/RM-A-15#I6008|A.15(4)]] ::Attach_Handler ''in'' Ada.Interrupts [[Guide:95lrm/RM-C-3-2#I6416|C.3.2(7)]] ::Blank_When_Zero ''in'' Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6843|F.3.3(7)]] ::Clock ''in'' Ada.Calendar [[Guide:95lrm/RM-9-6#I3546|9.6(12)]] ::Clock ''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6629|D.8(6)]] ::Close ''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5557|A.8.4(8)]] ::Close ''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5514|A.8.1(8)]] ::Close ''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5930|A.12.1(10)]] ::Close ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5638|A.10.1(11)]] ::Col ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5742|A.10.1(37)]] ::Command_Name ''in'' Ada.Command_Line [[Guide:95lrm/RM-A-15#I6012|A.15(6)]] ::Compose_From_Cartesian ''in'' Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6894|G.1.1(8)]] ::Compose_From_Polar ''in'' Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6904|G.1.1(11)]] ::Conjugate ''in'' Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6906|G.1.1(12)]], [[Guide:95lrm/RM-G-1-1#I6908|G.1.1(15)]] ::Continue ''in'' Ada.Asynchronous_Task_Control [[Guide:95lrm/RM-D-11#I6678|D.11(3)]] ::Copy_Array ''in'' Interfaces.C.Pointers [[Guide:95lrm/RM-B-3-2#I6228|B.3.2(15)]] ::Copy_Terminated_Array ''in'' Interfaces.C.Pointers [[Guide:95lrm/RM-B-3-2#I6226|B.3.2(14)]] ::Cos ''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6932|G.1.2(4)]] ::Cos ''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5283|A.5.1(5)]] ::Cosh ''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6948|G.1.2(6)]] ::Cosh ''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5311|A.5.1(7)]] ::Cot ''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6936|G.1.2(4)]] ::Cot ''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5289|A.5.1(5)]] ::Coth ''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6952|G.1.2(6)]] ::Coth ''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5315|A.5.1(7)]] ::Count ''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5049|A.4.4(48)]], [[Guide:95lrm/RM-A-4-4#I5051|A.4.4(49)]], [[Guide:95lrm/RM-A-4-4#I5053|A.4.4(50)]] ::Count ''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4954|A.4.3(13)]], [[Guide:95lrm/RM-A-4-3#I4956|A.4.3(14)]], [[Guide:95lrm/RM-A-4-3#I4958|A.4.3(15)]] ::Count ''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5141|A.4.5(43)]], [[Guide:95lrm/RM-A-4-5#I5143|A.4.5(44)]], [[Guide:95lrm/RM-A-4-5#I5145|A.4.5(45)]] ::Create ''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5553|A.8.4(6)]] ::Create ''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5510|A.8.1(6)]] ::Create ''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5926|A.12.1(8)]] ::Create ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5634|A.10.1(9)]] ::Current_Error ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5670|A.10.1(17)]], [[Guide:95lrm/RM-A-10-1#I5684|A.10.1(20)]] ::Current_Handler ''in'' Ada.Interrupts [[Guide:95lrm/RM-C-3-2#I6414|C.3.2(6)]] ::Current_Input ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5666|A.10.1(17)]], [[Guide:95lrm/RM-A-10-1#I5680|A.10.1(20)]] ::Current_Output ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5668|A.10.1(17)]], [[Guide:95lrm/RM-A-10-1#I5682|A.10.1(20)]] ::Current_State ''in'' Ada.Synchronous_Task_Control [[Guide:95lrm/RM-D-10#I6666|D.10(4)]] ::Current_Task ''in'' Ada.Task_Identification [[Guide:95lrm/RM-C-7-1#I6472|C.7.1(3/1)]] ::Day ''in'' Ada.Calendar [[Guide:95lrm/RM-9-6#I3552|9.6(13)]] ::Deallocate ''in'' System.Storage_Pools [[Guide:95lrm/RM-13-11#I4406|13.11(8)]] ::Decrement ''in'' Interfaces.C.Pointers [[Guide:95lrm/RM-B-3-2#I6222|B.3.2(11)]] ::Delete ''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5559|A.8.4(8)]] ::Delete ''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5516|A.8.1(8)]] ::Delete ''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5932|A.12.1(10)]] ::Delete ''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5077|A.4.4(64)]], [[Guide:95lrm/RM-A-4-4#I5079|A.4.4(65)]] ::Delete ''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4982|A.4.3(29)]], [[Guide:95lrm/RM-A-4-3#I4984|A.4.3(30)]] ::Delete ''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5169|A.4.5(59)]], [[Guide:95lrm/RM-A-4-5#I5171|A.4.5(60)]] ::Delete ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5640|A.10.1(11)]] ::Dereference_Error ''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6188|B.3.1(12)]] ::Detach_Handler ''in'' Ada.Interrupts [[Guide:95lrm/RM-C-3-2#I6420|C.3.2(9)]] ::Divide ''in'' Ada.Decimal [[Guide:95lrm/RM-F-2#I6826|F.2(6)]] ::Do_APC ''in'' System.RPC [[Guide:95lrm/RM-E-5#I6805|E.5(10)]] ::Do_RPC ''in'' System.RPC [[Guide:95lrm/RM-E-5#I6803|E.5(9)]] ::Element ''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5035|A.4.4(26)]] ::Element ''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5127|A.4.5(20)]] ::End_Of_File ''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5587|A.8.4(16)]] ::End_Of_File ''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5534|A.8.1(13)]] ::End_Of_File ''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5946|A.12.1(12)]] ::End_Of_File ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5730|A.10.1(34)]] ::End_Of_Line ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5714|A.10.1(30)]] ::End_Of_Page ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5728|A.10.1(33)]] ::Establish_RPC_Receiver ''in'' System.RPC [[Guide:95lrm/RM-E-5#I6809|E.5(12)]] ::Exception_Identity ''in'' Ada.Exceptions [[Guide:95lrm/RM-11-4-1#I3901|11.4.1(5)]] ::Exception_Information ''in'' Ada.Exceptions [[Guide:95lrm/RM-11-4-1#I3905|11.4.1(5)]] ::Exception_Message ''in'' Ada.Exceptions [[Guide:95lrm/RM-11-4-1#I3897|11.4.1(4)]] ::Exception_Name ''in'' Ada.Exceptions [[Guide:95lrm/RM-11-4-1#I3888|11.4.1(2)]], [[Guide:95lrm/RM-11-4-1#I3903|11.4.1(5)]] ::Exchange_Handler ''in'' Ada.Interrupts [[Guide:95lrm/RM-C-3-2#I6418|C.3.2(8)]] ::Exp ''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6926|G.1.2(3)]] ::Exp ''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5275|A.5.1(4)]] ::Expanded_Name ''in'' Ada.Tags [[Guide:95lrm/RM-3-9#I1969|3.9(7)]] ::External_Tag ''in'' Ada.Tags [[Guide:95lrm/RM-3-9#I1971|3.9(7)]] ::Finalize ''in'' Ada.Finalization [[Guide:95lrm/RM-7-6#I3136|7.6(6)]], [[Guide:95lrm/RM-7-6#I3142|7.6(8)]] ::Find_Token ''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5055|A.4.4(51)]] ::Find_Token ''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4960|A.4.3(16)]] ::Find_Token ''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5147|A.4.5(46)]] ::Flush ''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5966|A.12.1(25/1)]] ::Flush ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5686|A.10.1(21/1)]] ::Form ''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5569|A.8.4(9)]] ::Form ''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5526|A.8.1(9)]] ::Form ''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5942|A.12.1(11)]] ::Form ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5650|A.10.1(12)]] ::Free ''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5113|A.4.5(7)]] ::Free ''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6186|B.3.1(11)]] ::Get ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5756|A.10.1(41)]], [[Guide:95lrm/RM-A-10-1#I5774|A.10.1(47)]], [[Guide:95lrm/RM-A-10-1#I5793|A.10.1(54)]], [[Guide:95lrm/RM-A-10-1#I5801|A.10.1(55)]], [[Guide:95lrm/RM-A-10-1#I5808|A.10.1(59)]], [[Guide:95lrm/RM-A-10-1#I5816|A.10.1(60)]], [[Guide:95lrm/RM-A-10-1#I5824|A.10.1(65)]], [[Guide:95lrm/RM-A-10-1#I5832|A.10.1(67)]], [[Guide:95lrm/RM-A-10-1#I5842|A.10.1(70)]], [[Guide:95lrm/RM-A-10-1#I5848|A.10.1(72)]], [[Guide:95lrm/RM-A-10-1#I5856|A.10.1(75)]], [[Guide:95lrm/RM-A-10-1#I5864|A.10.1(77)]], [[Guide:95lrm/RM-A-10-1#I5871|A.10.1(81)]], [[Guide:95lrm/RM-A-10-1#I5879|A.10.1(83)]] ::Get ''in'' Ada.Text_IO.Complex_IO [[Guide:95lrm/RM-G-1-3#I6981|G.1.3(6)]], [[Guide:95lrm/RM-G-1-3#I6987|G.1.3(8)]] ::Get_Immediate ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5768|A.10.1(44)]], [[Guide:95lrm/RM-A-10-1#I5770|A.10.1(45)]] ::Get_Line ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5784|A.10.1(49)]] ::Get_Priority ''in'' Ada.Dynamic_Priorities [[Guide:95lrm/RM-D-5#I6584|D.5(5)]] ::Head ''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5089|A.4.4(70)]], [[Guide:95lrm/RM-A-4-4#I5091|A.4.4(71)]] ::Head ''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4994|A.4.3(35)]], [[Guide:95lrm/RM-A-4-3#I4996|A.4.3(36)]] ::Head ''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5181|A.4.5(65)]], [[Guide:95lrm/RM-A-4-5#I5183|A.4.5(66)]] ::Hold ''in'' Ada.Asynchronous_Task_Control [[Guide:95lrm/RM-D-11#I6676|D.11(3)]] ::Im ''in'' Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6882|G.1.1(6)]] ::Image ''in'' Ada.Numerics.Discrete_Random [[Guide:95lrm/RM-A-5-2#I5377|A.5.2(26)]] ::Image ''in'' Ada.Numerics.Float_Random [[Guide:95lrm/RM-A-5-2#I5355|A.5.2(14)]] ::Image ''in'' Ada.Task_Identification [[Guide:95lrm/RM-C-7-1#I6470|C.7.1(3/1)]] ::Image ''in'' Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6856|F.3.3(13)]] ::Increment ''in'' Interfaces.C.Pointers [[Guide:95lrm/RM-B-3-2#I6220|B.3.2(11)]] ::Index ''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5583|A.8.4(15)]] ::Index ''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5960|A.12.1(23)]] ::Index ''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5041|A.4.4(44)]], [[Guide:95lrm/RM-A-4-4#I5043|A.4.4(45)]], [[Guide:95lrm/RM-A-4-4#I5045|A.4.4(46)]] ::Index ''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4946|A.4.3(9)]], [[Guide:95lrm/RM-A-4-3#I4948|A.4.3(10)]], [[Guide:95lrm/RM-A-4-3#I4950|A.4.3(11)]] ::Index ''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5133|A.4.5(39)]], [[Guide:95lrm/RM-A-4-5#I5135|A.4.5(40)]], [[Guide:95lrm/RM-A-4-5#I5137|A.4.5(41)]] ::Index_Non_Blank ''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5047|A.4.4(47)]] ::Index_Non_Blank ''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4952|A.4.3(12)]] ::Index_Non_Blank ''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5139|A.4.5(42)]] ::Initialize ''in'' Ada.Finalization [[Guide:95lrm/RM-7-6#I3132|7.6(6)]], [[Guide:95lrm/RM-7-6#I3140|7.6(8)]] ::Insert ''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5069|A.4.4(60)]], [[Guide:95lrm/RM-A-4-4#I5071|A.4.4(61)]] ::Insert ''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4974|A.4.3(25)]], [[Guide:95lrm/RM-A-4-3#I4976|A.4.3(26)]] ::Insert ''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5161|A.4.5(55)]], [[Guide:95lrm/RM-A-4-5#I5163|A.4.5(56)]] ::Internal_Tag ''in'' Ada.Tags [[Guide:95lrm/RM-3-9#I1973|3.9(7)]] ::Is_Alphanumeric ''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4599|A.3.2(4)]] ::Is_Attached ''in'' Ada.Interrupts [[Guide:95lrm/RM-C-3-2#I6412|C.3.2(5)]] ::Is_Basic ''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4591|A.3.2(4)]] ::Is_Callable ''in'' Ada.Task_Identification [[Guide:95lrm/RM-C-7-1#I6478|C.7.1(4)]] ::Is_Character ''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4624|A.3.2(14)]] ::Is_Control ''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4581|A.3.2(4)]] ::Is_Decimal_Digit ''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4595|A.3.2(4)]] ::Is_Digit ''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4593|A.3.2(4)]] ::Is_Graphic ''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4583|A.3.2(4)]] ::Is_Held ''in'' Ada.Asynchronous_Task_Control [[Guide:95lrm/RM-D-11#I6680|D.11(3)]] ::Is_Hexadecimal_Digit ''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4597|A.3.2(4)]] ::Is_In ''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4914|A.4.2(13)]] ::Is_In ''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5231|A.4.7(13)]] ::Is_ISO_646 ''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4618|A.3.2(10)]] ::Is_Letter ''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4585|A.3.2(4)]] ::Is_Lower ''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4587|A.3.2(4)]] ::Is_Nul_Terminated ''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6138|B.3(24)]], [[Guide:95lrm/RM-B-3#I6157|B.3(35)]] ::Is_Open ''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5571|A.8.4(10)]] ::Is_Open ''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5528|A.8.1(10)]] ::Is_Open ''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5944|A.12.1(12)]] ::Is_Open ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5652|A.10.1(13)]] ::Is_Reserved ''in'' Ada.Interrupts [[Guide:95lrm/RM-C-3-2#I6410|C.3.2(4)]] ::Is_Special ''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4601|A.3.2(4)]] ::Is_String ''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4626|A.3.2(14)]] ::Is_Subset ''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4916|A.4.2(14)]] ::Is_Subset ''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5233|A.4.7(14)]] ::Is_Terminated ''in'' Ada.Task_Identification [[Guide:95lrm/RM-C-7-1#I6476|C.7.1(4)]] ::Is_Upper ''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4589|A.3.2(4)]] ::Length ''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5013|A.4.4(9)]] ::Length ''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5109|A.4.5(6)]] ::Length ''in'' Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6852|F.3.3(11)]] ::Length ''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6294|B.4(34)]], [[Guide:95lrm/RM-B-4#I6302|B.4(39)]], [[Guide:95lrm/RM-B-4#I6310|B.4(44)]] ::Line ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5748|A.10.1(38)]] ::Line_Length ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5698|A.10.1(25)]] ::Log ''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6924|G.1.2(3)]] ::Log ''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5271|A.5.1(4)]] ::Look_Ahead ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5762|A.10.1(43)]] ::Microseconds ''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6637|D.8(14)]] ::Milliseconds ''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6639|D.8(14)]] ::Mode ''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5565|A.8.4(9)]] ::Mode ''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5522|A.8.1(9)]] ::Mode ''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5938|A.12.1(11)]] ::Mode ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5646|A.10.1(12)]] ::Modulus ''in'' Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6896|G.1.1(9)]] ::Month ''in'' Ada.Calendar [[Guide:95lrm/RM-9-6#I3550|9.6(13)]] ::Move ''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4944|A.4.3(7)]] ::Name ''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5567|A.8.4(9)]] ::Name ''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5524|A.8.1(9)]] ::Name ''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5940|A.12.1(11)]] ::Name ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5648|A.10.1(12)]] ::Nanoseconds ''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6635|D.8(14)]] ::New_Char_Array ''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6182|B.3.1(9)]] ::New_Line ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5706|A.10.1(28)]] ::New_Page ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5718|A.10.1(31)]] ::New_String ''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6184|B.3.1(10)]] ::Null_Task_ID ''in'' Ada.Task_Identification [[Guide:95lrm/RM-C-7-1#I6468|C.7.1(2)]] ::Open ''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5555|A.8.4(7)]] ::Open ''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5512|A.8.1(7)]] ::Open ''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5928|A.12.1(9)]] ::Open ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5636|A.10.1(10)]] ::Overwrite ''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5073|A.4.4(62)]], [[Guide:95lrm/RM-A-4-4#I5075|A.4.4(63)]] ::Overwrite ''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4978|A.4.3(27)]], [[Guide:95lrm/RM-A-4-3#I4980|A.4.3(28)]] ::Overwrite ''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5165|A.4.5(57)]], [[Guide:95lrm/RM-A-4-5#I5167|A.4.5(58)]] ::Page ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5750|A.10.1(39)]] ::Page_Length ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5702|A.10.1(26)]] ::Pic_String ''in'' Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6841|F.3.3(7)]] ::Put ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5758|A.10.1(42)]], [[Guide:95lrm/RM-A-10-1#I5778|A.10.1(48)]], [[Guide:95lrm/RM-A-10-1#I5797|A.10.1(55)]], [[Guide:95lrm/RM-A-10-1#I5814|A.10.1(60)]], [[Guide:95lrm/RM-A-10-1#I5828|A.10.1(66)]], [[Guide:95lrm/RM-A-10-1#I5834|A.10.1(67)]], [[Guide:95lrm/RM-A-10-1#I5844|A.10.1(71)]], [[Guide:95lrm/RM-A-10-1#I5850|A.10.1(72)]], [[Guide:95lrm/RM-A-10-1#I5862|A.10.1(76)]], [[Guide:95lrm/RM-A-10-1#I5866|A.10.1(77)]], [[Guide:95lrm/RM-A-10-1#I5875|A.10.1(82)]], [[Guide:95lrm/RM-A-10-1#I5881|A.10.1(83)]] ::Put ''in'' Ada.Text_IO.Complex_IO [[Guide:95lrm/RM-G-1-3#I6983|G.1.3(7)]], [[Guide:95lrm/RM-G-1-3#I6989|G.1.3(8)]] ::Put ''in'' Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6858|F.3.3(14)]], [[Guide:95lrm/RM-F-3-3#I6860|F.3.3(15)]], [[Guide:95lrm/RM-F-3-3#I6862|F.3.3(16)]] ::Put_Line ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5786|A.10.1(50)]] ::Raise_Exception ''in'' Ada.Exceptions [[Guide:95lrm/RM-11-4-1#I3895|11.4.1(4)]] ::Random ''in'' Ada.Numerics.Discrete_Random [[Guide:95lrm/RM-A-5-2#I5364|A.5.2(20)]] ::Random ''in'' Ada.Numerics.Float_Random [[Guide:95lrm/RM-A-5-2#I5342|A.5.2(8)]] ::Re ''in'' Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6878|G.1.1(6)]] ::Read ''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5575|A.8.4(12)]] ::Read ''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5530|A.8.1(12)]] ::Read ''in'' Ada.Storage_IO [[Guide:95lrm/RM-A-9#I5601|A.9(6)]] ::Read ''in'' Ada.Streams [[Guide:95lrm/RM-13-13-1#I4485|13.13.1(5)]] ::Read ''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5950|A.12.1(15)]], [[Guide:95lrm/RM-A-12-1#I5952|A.12.1(16)]] ::Read ''in'' System.RPC [[Guide:95lrm/RM-E-5#I6799|E.5(7)]] ::Reference ''in'' Ada.Interrupts [[Guide:95lrm/RM-C-3-2#I6422|C.3.2(10)]] ::Reference ''in'' Ada.Task_Attributes [[Guide:95lrm/RM-C-7-2#I6497|C.7.2(5)]] ::Reinitialize ''in'' Ada.Task_Attributes [[Guide:95lrm/RM-C-7-2#I6501|C.7.2(6)]] ::Replace_Element ''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5037|A.4.4(27)]] ::Replace_Element ''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5129|A.4.5(21)]] ::Replace_Slice ''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5065|A.4.4(58)]], [[Guide:95lrm/RM-A-4-4#I5067|A.4.4(59)]] ::Replace_Slice ''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4970|A.4.3(23)]], [[Guide:95lrm/RM-A-4-3#I4972|A.4.3(24)]] ::Replace_Slice ''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5157|A.4.5(53)]], [[Guide:95lrm/RM-A-4-5#I5159|A.4.5(54)]] ::Replicate ''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5097|A.4.4(78)]], [[Guide:95lrm/RM-A-4-4#I5099|A.4.4(79)]], [[Guide:95lrm/RM-A-4-4#I5101|A.4.4(80)]] ::Reraise_Occurrence ''in'' Ada.Exceptions [[Guide:95lrm/RM-11-4-1#I3899|11.4.1(4)]] ::Reset ''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5561|A.8.4(8)]] ::Reset ''in'' Ada.Numerics.Discrete_Random [[Guide:95lrm/RM-A-5-2#I5368|A.5.2(21)]], [[Guide:95lrm/RM-A-5-2#I5374|A.5.2(24)]] ::Reset ''in'' Ada.Numerics.Float_Random [[Guide:95lrm/RM-A-5-2#I5346|A.5.2(9)]], [[Guide:95lrm/RM-A-5-2#I5352|A.5.2(12)]] ::Reset ''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5520|A.8.1(8)]] ::Reset ''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5934|A.12.1(10)]] ::Reset ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5644|A.10.1(11)]] ::Save ''in'' Ada.Numerics.Discrete_Random [[Guide:95lrm/RM-A-5-2#I5372|A.5.2(24)]] ::Save ''in'' Ada.Numerics.Float_Random [[Guide:95lrm/RM-A-5-2#I5350|A.5.2(12)]] ::Save_Occurrence ''in'' Ada.Exceptions [[Guide:95lrm/RM-11-4-1#I3907|11.4.1(6)]] ::Seconds ''in'' Ada.Calendar [[Guide:95lrm/RM-9-6#I3554|9.6(13)]] ::Set_Col ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5736|A.10.1(35)]] ::Set_Error ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5658|A.10.1(15)]] ::Set_Exit_Status ''in'' Ada.Command_Line [[Guide:95lrm/RM-A-15#I6018|A.15(9)]] ::Set_False ''in'' Ada.Synchronous_Task_Control [[Guide:95lrm/RM-D-10#I6664|D.10(4)]] ::Set_Im ''in'' Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6886|G.1.1(7)]] ::Set_Index ''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5581|A.8.4(14)]] ::Set_Index ''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5958|A.12.1(22)]] ::Set_Input ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5654|A.10.1(15)]] ::Set_Line ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5740|A.10.1(36)]] ::Set_Line_Length ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5692|A.10.1(23)]] ::Set_Mode ''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5964|A.12.1(24)]] ::Set_Output ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5656|A.10.1(15)]] ::Set_Page_Length ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5696|A.10.1(24)]] ::Set_Priority ''in'' Ada.Dynamic_Priorities [[Guide:95lrm/RM-D-5#I6582|D.5(4)]] ::Set_Re ''in'' Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6884|G.1.1(7)]] ::Set_True ''in'' Ada.Synchronous_Task_Control [[Guide:95lrm/RM-D-10#I6662|D.10(4)]] ::Set_Value ''in'' Ada.Task_Attributes [[Guide:95lrm/RM-C-7-2#I6499|C.7.2(6)]] ::Sin ''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6930|G.1.2(4)]] ::Sin ''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5279|A.5.1(5)]] ::Sinh ''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6946|G.1.2(6)]] ::Sinh ''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5309|A.5.1(7)]] ::Size ''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5585|A.8.4(15)]] ::Size ''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5962|A.12.1(23)]] ::Skip_Line ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5710|A.10.1(29)]] ::Skip_Page ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5724|A.10.1(32)]] ::Slice ''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5039|A.4.4(28)]] ::Slice ''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5131|A.4.5(22)]] ::Split ''in'' Ada.Calendar [[Guide:95lrm/RM-9-6#I3556|9.6(14)]] ::Split ''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6643|D.8(16)]] ::Sqrt ''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6922|G.1.2(3)]] ::Sqrt ''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5269|A.5.1(4)]] ::Standard_Error ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5664|A.10.1(16)]], [[Guide:95lrm/RM-A-10-1#I5678|A.10.1(19)]] ::Standard_Input ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5660|A.10.1(16)]], [[Guide:95lrm/RM-A-10-1#I5674|A.10.1(19)]] ::Standard_Output ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5662|A.10.1(16)]], [[Guide:95lrm/RM-A-10-1#I5676|A.10.1(19)]] ::Storage_Size ''in'' System.Storage_Pools [[Guide:95lrm/RM-13-11#I4408|13.11(9)]] ::Stream ''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5948|A.12.1(13)]] ::Stream ''in'' Ada.Text_IO.Text_Streams [[Guide:95lrm/RM-A-12-2#I5981|A.12.2(4)]] ::Stream ''in'' Ada.Wide_Text_IO.Text_Streams [[Guide:95lrm/RM-A-12-3#I5988|A.12.3(4)]] ::Strlen ''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6198|B.3.1(17)]] ::Suspend_Until_True ''in'' Ada.Synchronous_Task_Control [[Guide:95lrm/RM-D-10#I6668|D.10(4)]] ::Tail ''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5093|A.4.4(72)]], [[Guide:95lrm/RM-A-4-4#I5095|A.4.4(73)]] ::Tail ''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4998|A.4.3(37)]], [[Guide:95lrm/RM-A-4-3#I5000|A.4.3(38)]] ::Tail ''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5185|A.4.5(67)]], [[Guide:95lrm/RM-A-4-5#I5187|A.4.5(68)]] ::Tan ''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6934|G.1.2(4)]] ::Tan ''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5287|A.5.1(5)]] ::Tanh ''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6950|G.1.2(6)]] ::Tanh ''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5313|A.5.1(7)]] ::Time_Of ''in'' Ada.Calendar [[Guide:95lrm/RM-9-6#I3558|9.6(15)]] ::Time_Of ''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6645|D.8(16)]] ::To_Ada ''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6134|B.3(22)]], [[Guide:95lrm/RM-B-3#I6142|B.3(26)]], [[Guide:95lrm/RM-B-3#I6146|B.3(28)]], [[Guide:95lrm/RM-B-3#I6153|B.3(32)]], [[Guide:95lrm/RM-B-3#I6161|B.3(37)]], [[Guide:95lrm/RM-B-3#I6165|B.3(39)]] ::To_Ada ''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6263|B.4(17)]], [[Guide:95lrm/RM-B-4#I6267|B.4(19)]] ::To_Ada ''in'' Interfaces.Fortran [[Guide:95lrm/RM-B-5#I6350|B.5(13)]], [[Guide:95lrm/RM-B-5#I6354|B.5(14)]], [[Guide:95lrm/RM-B-5#I6358|B.5(16)]] ::To_Address ''in'' System.Address_To_Access_Conversions [[Guide:95lrm/RM-13-7-2#I4354|13.7.2(3)]] ::To_Address ''in'' System.Storage_Elements [[Guide:95lrm/RM-13-7-1#I4342|13.7.1(10)]] ::To_Basic ''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4607|A.3.2(6)]], [[Guide:95lrm/RM-A-3-2#I4613|A.3.2(7)]] ::To_Binary ''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6314|B.4(45)]], [[Guide:95lrm/RM-B-4#I6320|B.4(48)]] ::To_Bounded_String ''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5015|A.4.4(11)]] ::To_C ''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6132|B.3(21)]], [[Guide:95lrm/RM-B-3#I6140|B.3(25)]], [[Guide:95lrm/RM-B-3#I6144|B.3(27)]], [[Guide:95lrm/RM-B-3#I6151|B.3(32)]], [[Guide:95lrm/RM-B-3#I6159|B.3(36)]], [[Guide:95lrm/RM-B-3#I6163|B.3(38)]] ::To_Character ''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4628|A.3.2(15)]] ::To_Chars_Ptr ''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6180|B.3.1(8)]] ::To_COBOL ''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6261|B.4(17)]], [[Guide:95lrm/RM-B-4#I6265|B.4(18)]] ::To_Decimal ''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6296|B.4(35)]], [[Guide:95lrm/RM-B-4#I6304|B.4(40)]], [[Guide:95lrm/RM-B-4#I6312|B.4(44)]], [[Guide:95lrm/RM-B-4#I6318|B.4(47)]] ::To_Display ''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6298|B.4(36)]] ::To_Domain ''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4932|A.4.2(24)]] ::To_Domain ''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5249|A.4.7(24)]] ::To_Duration ''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6631|D.8(13)]] ::To_Fortran ''in'' Interfaces.Fortran [[Guide:95lrm/RM-B-5#I6348|B.5(13)]], [[Guide:95lrm/RM-B-5#I6352|B.5(14)]], [[Guide:95lrm/RM-B-5#I6356|B.5(15)]] ::To_Integer ''in'' System.Storage_Elements [[Guide:95lrm/RM-13-7-1#I4344|13.7.1(10)]] ::To_ISO_646 ''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4620|A.3.2(11)]], [[Guide:95lrm/RM-A-3-2#I4622|A.3.2(12)]] ::To_Long_Binary ''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6322|B.4(48)]] ::To_Lower ''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4603|A.3.2(6)]], [[Guide:95lrm/RM-A-3-2#I4609|A.3.2(7)]] ::To_Mapping ''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4930|A.4.2(23)]] ::To_Mapping ''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5247|A.4.7(23)]] ::To_Packed ''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6306|B.4(41)]] ::To_Picture ''in'' Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6839|F.3.3(6)]] ::To_Pointer ''in'' System.Address_To_Access_Conversions [[Guide:95lrm/RM-13-7-2#I4352|13.7.2(3)]] ::To_Range ''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4934|A.4.2(24)]] ::To_Range ''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5251|A.4.7(25)]] ::To_Ranges ''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4912|A.4.2(10)]] ::To_Ranges ''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5229|A.4.7(10)]] ::To_Sequence ''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4923|A.4.2(19)]] ::To_Sequence ''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5240|A.4.7(19)]] ::To_Set ''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4908|A.4.2(8)]], [[Guide:95lrm/RM-A-4-2#I4910|A.4.2(9)]], [[Guide:95lrm/RM-A-4-2#I4919|A.4.2(17)]], [[Guide:95lrm/RM-A-4-2#I4921|A.4.2(18)]] ::To_Set ''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5225|A.4.7(8)]], [[Guide:95lrm/RM-A-4-7#I5227|A.4.7(9)]], [[Guide:95lrm/RM-A-4-7#I5236|A.4.7(17)]], [[Guide:95lrm/RM-A-4-7#I5238|A.4.7(18)]] ::To_String ''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4630|A.3.2(16)]] ::To_String ''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5017|A.4.4(12)]] ::To_String ''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5119|A.4.5(11)]] ::To_Time_Span ''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6633|D.8(13)]] ::To_Unbounded_String ''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5115|A.4.5(9)]], [[Guide:95lrm/RM-A-4-5#I5117|A.4.5(10)]] ::To_Upper ''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4605|A.3.2(6)]], [[Guide:95lrm/RM-A-3-2#I4611|A.3.2(7)]] ::To_Wide_Character ''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4632|A.3.2(17)]] ::To_Wide_String ''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4634|A.3.2(18)]] ::Translate ''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5057|A.4.4(53)]], [[Guide:95lrm/RM-A-4-4#I5059|A.4.4(54)]], [[Guide:95lrm/RM-A-4-4#I5061|A.4.4(55)]], [[Guide:95lrm/RM-A-4-4#I5063|A.4.4(56)]] ::Translate ''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4962|A.4.3(18)]], [[Guide:95lrm/RM-A-4-3#I4964|A.4.3(19)]], [[Guide:95lrm/RM-A-4-3#I4966|A.4.3(20)]], [[Guide:95lrm/RM-A-4-3#I4968|A.4.3(21)]] ::Translate ''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5149|A.4.5(48)]], [[Guide:95lrm/RM-A-4-5#I5151|A.4.5(49)]], [[Guide:95lrm/RM-A-4-5#I5153|A.4.5(50)]], [[Guide:95lrm/RM-A-4-5#I5155|A.4.5(51)]] ::Trim ''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5083|A.4.4(67)]], [[Guide:95lrm/RM-A-4-4#I5085|A.4.4(68)]], [[Guide:95lrm/RM-A-4-4#I5087|A.4.4(69)]] ::Trim ''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4986|A.4.3(31)]], [[Guide:95lrm/RM-A-4-3#I4988|A.4.3(32)]], [[Guide:95lrm/RM-A-4-3#I4990|A.4.3(33)]], [[Guide:95lrm/RM-A-4-3#I4992|A.4.3(34)]] ::Trim ''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5173|A.4.5(61)]], [[Guide:95lrm/RM-A-4-5#I5175|A.4.5(62)]], [[Guide:95lrm/RM-A-4-5#I5177|A.4.5(63)]], [[Guide:95lrm/RM-A-4-5#I5179|A.4.5(64)]] ::Update ''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6200|B.3.1(18)]], [[Guide:95lrm/RM-B-3-1#I6202|B.3.1(19)]] ::Update_Error ''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6204|B.3.1(20)]] ::Valid ''in'' Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6837|F.3.3(5)]], [[Guide:95lrm/RM-F-3-3#I6854|F.3.3(12)]] ::Valid ''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6292|B.4(33)]], [[Guide:95lrm/RM-B-4#I6300|B.4(38)]], [[Guide:95lrm/RM-B-4#I6308|B.4(43)]] ::Value ''in'' Ada.Numerics.Discrete_Random [[Guide:95lrm/RM-A-5-2#I5379|A.5.2(26)]] ::Value ''in'' Ada.Numerics.Float_Random [[Guide:95lrm/RM-A-5-2#I5357|A.5.2(14)]] ::Value ''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4927|A.4.2(21)]] ::Value ''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5244|A.4.7(21)]] ::Value ''in'' Ada.Task_Attributes [[Guide:95lrm/RM-C-7-2#I6495|C.7.2(4)]] ::Value ''in'' Interfaces.C.Pointers [[Guide:95lrm/RM-B-3-2#I6215|B.3.2(6)]], [[Guide:95lrm/RM-B-3-2#I6217|B.3.2(7)]] ::Value ''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6190|B.3.1(13)]], [[Guide:95lrm/RM-B-3-1#I6192|B.3.1(14)]], [[Guide:95lrm/RM-B-3-1#I6194|B.3.1(15)]], [[Guide:95lrm/RM-B-3-1#I6196|B.3.1(16)]] ::Virtual_Length ''in'' Interfaces.C.Pointers [[Guide:95lrm/RM-B-3-2#I6224|B.3.2(13)]] ::Write ''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5579|A.8.4(13)]] ::Write ''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5532|A.8.1(12)]] ::Write ''in'' Ada.Storage_IO [[Guide:95lrm/RM-A-9#I5603|A.9(7)]] ::Write ''in'' Ada.Streams [[Guide:95lrm/RM-13-13-1#I4487|13.13.1(6)]] ::Write ''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5954|A.12.1(18)]], [[Guide:95lrm/RM-A-12-1#I5956|A.12.1(19)]] ::Write ''in'' System.RPC [[Guide:95lrm/RM-E-5#I6801|E.5(8)]] ::Year ''in'' Ada.Calendar [[Guide:95lrm/RM-9-6#I3548|9.6(13)]] :Language-Defined Type :Address ''in'' System [[Guide:95lrm/RM-13-7#I4314|13.7(12)]] ::Alignment ''in'' Ada.Strings [[Guide:95lrm/RM-A-4-1#I4888|A.4.1(6)]] ::Alphanumeric ''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6259|B.4(16)]] ::Attribute_Handle ''in'' Ada.Task_Attributes [[Guide:95lrm/RM-C-7-2#I6493|C.7.2(3)]] ::Binary ''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6245|B.4(10)]] ::Binary_Format ''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6278|B.4(24)]] ::Bit_Order ''in'' System [[Guide:95lrm/RM-13-7#I4321|13.7(15)]] ::Boolean ''in'' Standard [[Guide:95lrm/RM-A-1#I4549|A.1(5)]] ::Bounded_String ''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5009|A.4.4(6)]] ::Byte ''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6287|B.4(29)]] ::Byte_Array ''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6289|B.4(29)]] ::C_float ''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6123|B.3(15)]] ::char ''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6129|B.3(19)]] ::char_array ''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6136|B.3(23)]] ::char_array_access ''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6173|B.3.1(4)]] ::Character ''in'' Standard [[Guide:95lrm/RM-A-1#I4557|A.1(35)]] ::Character_Mapping ''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4925|A.4.2(20)]] ::Character_Mapping_Function ''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4936|A.4.2(25)]] ::Character_Range ''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4904|A.4.2(6)]] ::Character_Ranges ''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4906|A.4.2(7)]] ::Character_Set ''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4901|A.4.2(4)]] ::Character_Set ''in'' Interfaces.Fortran [[Guide:95lrm/RM-B-5#I6344|B.5(11)]] ::chars_ptr ''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6175|B.3.1(5)]] ::chars_ptr_array ''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6177|B.3.1(6)]] ::COBOL_Character ''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6255|B.4(13)]] ::Complex ''in'' Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6872|G.1.1(3)]] ::Complex ''in'' Interfaces.Fortran [[Guide:95lrm/RM-B-5#I6339|B.5(9)]] ::Controlled ''in'' Ada.Finalization [[Guide:95lrm/RM-7-6#I3130|7.6(5)]] ::Count ''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5550|A.8.4(4)]] ::Count ''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5923|A.12.1(7)]] ::Count ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5626|A.10.1(5)]] ::Decimal_Element ''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6251|B.4(12)]] ::Direction ''in'' Ada.Strings [[Guide:95lrm/RM-A-4-1#I4894|A.4.1(6)]] ::Display_Format ''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6271|B.4(22)]] ::double ''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6125|B.3(16)]] ::Double_Precision ''in'' Interfaces.Fortran [[Guide:95lrm/RM-B-5#I6334|B.5(6)]] ::Duration ''in'' Standard [[Guide:95lrm/RM-A-1#I4566|A.1(43)]] ::Exception_Id ''in'' Ada.Exceptions [[Guide:95lrm/RM-11-4-1#I3885|11.4.1(2)]] ::Exception_Occurrence ''in'' Ada.Exceptions [[Guide:95lrm/RM-11-4-1#I3890|11.4.1(3)]] ::Exception_Occurrence_Access ''in'' Ada.Exceptions [[Guide:95lrm/RM-11-4-1#I3892|11.4.1(3)]] ::Exit_Status ''in'' Ada.Command_Line [[Guide:95lrm/RM-A-15#I6014|A.15(7)]], [[Guide:95lrm/RM-A-15#I6021|A.15(16.1/1)]] ::File_Access ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5672|A.10.1(18)]] ::File_Mode ''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5548|A.8.4(4)]] ::File_Mode ''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5508|A.8.1(4)]] ::File_Mode ''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5921|A.12.1(6)]] ::File_Mode ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5624|A.10.1(4)]] ::File_Type ''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5546|A.8.4(3)]] ::File_Type ''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5506|A.8.1(3)]] ::File_Type ''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5919|A.12.1(5)]] ::File_Type ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5622|A.10.1(3)]] ::Float ''in'' Standard [[Guide:95lrm/RM-A-1#I4555|A.1(21)]] ::Floating ''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6241|B.4(9)]] ::Fortran_Character ''in'' Interfaces.Fortran [[Guide:95lrm/RM-B-5#I6346|B.5(12)]] ::Fortran_Integer ''in'' Interfaces.Fortran [[Guide:95lrm/RM-B-5#I6330|B.5(5)]] ::Generator ''in'' Ada.Numerics.Discrete_Random [[Guide:95lrm/RM-A-5-2#I5362|A.5.2(19)]] ::Generator ''in'' Ada.Numerics.Float_Random [[Guide:95lrm/RM-A-5-2#I5339|A.5.2(7)]] ::Imaginary ''in'' Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6874|G.1.1(4)]] ::int ''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6101|B.3(7)]] ::Integer ''in'' Standard [[Guide:95lrm/RM-A-1#I4551|A.1(12)]] ::Integer_Address ''in'' System.Storage_Elements [[Guide:95lrm/RM-13-7-1#I4340|13.7.1(10)]] ::Interrupt_ID ''in'' Ada.Interrupts [[Guide:95lrm/RM-C-3-2#I6406|C.3.2(2)]] ::Limited_Controlled ''in'' Ada.Finalization [[Guide:95lrm/RM-7-6#I3138|7.6(7)]] ::Logical ''in'' Interfaces.Fortran [[Guide:95lrm/RM-B-5#I6336|B.5(7)]] ::long ''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6105|B.3(7)]] ::Long_Binary ''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6247|B.4(10)]] ::long_double ''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6127|B.3(17)]] ::Long_Floating ''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6243|B.4(9)]] ::Membership ''in'' Ada.Strings [[Guide:95lrm/RM-A-4-1#I4892|A.4.1(6)]] ::Name ''in'' System [[Guide:95lrm/RM-13-7#I4302|13.7(4)]] ::Numeric ''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6269|B.4(20)]] ::Packed_Decimal ''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6253|B.4(12)]] ::Packed_Format ''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6283|B.4(26)]] ::Parameterless_Handler ''in'' Ada.Interrupts [[Guide:95lrm/RM-C-3-2#I6408|C.3.2(2)]] ::Params_Stream_Type ''in'' System.RPC [[Guide:95lrm/RM-E-5#I6797|E.5(6)]] ::Partition_ID ''in'' System.RPC [[Guide:95lrm/RM-E-5#I6794|E.5(4)]] ::Picture ''in'' Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6835|F.3.3(4)]] ::plain_char ''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6117|B.3(11)]] ::Pointer ''in'' Interfaces.C.Pointers [[Guide:95lrm/RM-B-3-2#I6213|B.3.2(5)]] ::ptrdiff_t ''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6119|B.3(12)]] ::Real ''in'' Interfaces.Fortran [[Guide:95lrm/RM-B-5#I6332|B.5(6)]] ::Root_Storage_Pool ''in'' System.Storage_Pools [[Guide:95lrm/RM-13-11#I4402|13.11(6)]] ::Root_Stream_Type ''in'' Ada.Streams [[Guide:95lrm/RM-13-13-1#I4476|13.13.1(3)]] ::RPC_Receiver ''in'' System.RPC [[Guide:95lrm/RM-E-5#I6807|E.5(11)]] ::Seconds_Count ''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6641|D.8(15)]] ::short ''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6103|B.3(7)]] ::signed_char ''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6107|B.3(8)]] ::size_t ''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6121|B.3(13)]] ::State ''in'' Ada.Numerics.Discrete_Random [[Guide:95lrm/RM-A-5-2#I5370|A.5.2(23)]] ::State ''in'' Ada.Numerics.Float_Random [[Guide:95lrm/RM-A-5-2#I5348|A.5.2(11)]] ::Storage_Array ''in'' System.Storage_Elements [[Guide:95lrm/RM-13-7-1#I4337|13.7.1(5)]] ::Storage_Element ''in'' System.Storage_Elements [[Guide:95lrm/RM-13-7-1#I4335|13.7.1(5)]] ::Storage_Offset ''in'' System.Storage_Elements [[Guide:95lrm/RM-13-7-1#I4332|13.7.1(3)]] ::Stream_Access ''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5917|A.12.1(4)]] ::Stream_Access ''in'' Ada.Text_IO.Text_Streams [[Guide:95lrm/RM-A-12-2#I5979|A.12.2(3)]] ::Stream_Access ''in'' Ada.Wide_Text_IO.Text_Streams [[Guide:95lrm/RM-A-12-3#I5986|A.12.3(3)]] ::Stream_Element ''in'' Ada.Streams [[Guide:95lrm/RM-13-13-1#I4478|13.13.1(4/1)]] ::Stream_Element_Array ''in'' Ada.Streams [[Guide:95lrm/RM-13-13-1#I4483|13.13.1(4/1)]] ::Stream_Element_Offset ''in'' Ada.Streams [[Guide:95lrm/RM-13-13-1#I4480|13.13.1(4/1)]] ::String ''in'' Standard [[Guide:95lrm/RM-A-1#I4562|A.1(37)]] ::String_Access ''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5111|A.4.5(7)]] ::Suspension_Object ''in'' Ada.Synchronous_Task_Control [[Guide:95lrm/RM-D-10#I6660|D.10(4)]] ::Tag ''in'' Ada.Tags [[Guide:95lrm/RM-3-9#I1967|3.9(6)]] ::Task_ID ''in'' Ada.Task_Identification [[Guide:95lrm/RM-C-7-1#I6466|C.7.1(2)]] ::Time ''in'' Ada.Calendar [[Guide:95lrm/RM-9-6#I3540|9.6(10)]] ::Time ''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6617|D.8(4)]] ::Time_Span ''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6622|D.8(5)]] ::Trim_End ''in'' Ada.Strings [[Guide:95lrm/RM-A-4-1#I4896|A.4.1(6)]] ::Truncation ''in'' Ada.Strings [[Guide:95lrm/RM-A-4-1#I4890|A.4.1(6)]] ::Type_Set ''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5632|A.10.1(7)]] ::Unbounded_String ''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5106|A.4.5(4)]] ::unsigned ''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6109|B.3(9)]] ::unsigned_char ''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6115|B.3(10)]] ::unsigned_long ''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6113|B.3(9)]] ::unsigned_short ''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6111|B.3(9)]] ::wchar_array ''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6155|B.3(33)]] ::wchar_t ''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6148|B.3(30/1)]] ::Wide_Character ''in'' Standard [[Guide:95lrm/RM-A-1#I4559|A.1(36)]] ::Wide_Character_Mapping ''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5242|A.4.7(20)]] ::Wide_Character_Mapping_Function ''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5253|A.4.7(26)]] ::Wide_Character_Range ''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5221|A.4.7(6)]] ::Wide_Character_Ranges ''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5223|A.4.7(7)]] ::Wide_Character_Set ''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5218|A.4.7(4)]] ::Wide_String ''in'' Standard [[Guide:95lrm/RM-A-1#I4564|A.1(41)]] :Last attribute [[Guide:95lrm/RM-3-5#I1520|3.5(13)]], [[Guide:95lrm/RM-3-6-2#I1822|3.6.2(5)]] :Last(N) attribute [[Guide:95lrm/RM-3-6-2#I1824|3.6.2(6)]] :last_bit [[Guide:95lrm/RM-13-5-1#I4269|13.5.1(6)]] ::''used'' [[Guide:95lrm/RM-13-5-1#I4264|13.5.1(3)]], [[Guide:95lrm/RM-P#I7951|P]] :Last_Bit attribute [[Guide:95lrm/RM-13-5-2#I4282|13.5.2(4)]] :lateness [[Guide:95lrm/RM-D-9#I6655|D.9(12)]] :Latin-1 [[Guide:95lrm/RM-3-5-2#I1588|3.5.2(2)]] :Latin_1 ::''child of'' Ada.Characters [[Guide:95lrm/RM-A-3-3#I4646|A.3.3(3)]] :layout ::aspect of representation [[Guide:95lrm/RM-13-5#I4250|13.5(1)]] :Layout_Error ::''in'' Ada.IO_Exceptions [[Guide:95lrm/RM-A-13#I6000|A.13(4)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5890|A.10.1(85)]] :LC_A ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4712|A.3.3(13)]] :LC_A_Acute ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4848|A.3.3(25)]] :LC_A_Circumflex ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4849|A.3.3(25)]] :LC_A_Diaeresis ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4851|A.3.3(25)]] :LC_A_Grave ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4847|A.3.3(25)]] :LC_A_Ring ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4852|A.3.3(25)]] :LC_A_Tilde ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4850|A.3.3(25)]] :LC_AE_Diphthong ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4853|A.3.3(25)]] :LC_B ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4713|A.3.3(13)]] :LC_C ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4714|A.3.3(13)]] :LC_C_Cedilla ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4854|A.3.3(25)]] :LC_D ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4715|A.3.3(13)]] :LC_E ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4716|A.3.3(13)]] :LC_E_Acute ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4856|A.3.3(25)]] :LC_E_Circumflex ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4857|A.3.3(25)]] :LC_E_Diaeresis ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4858|A.3.3(25)]] :LC_E_Grave ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4855|A.3.3(25)]] :LC_F ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4717|A.3.3(13)]] :LC_G ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4718|A.3.3(13)]] :LC_German_Sharp_S ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4846|A.3.3(24)]] :LC_H ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4719|A.3.3(13)]] :LC_I ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4720|A.3.3(13)]] :LC_I_Acute ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4860|A.3.3(25)]] :LC_I_Circumflex ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4861|A.3.3(25)]] :LC_I_Diaeresis ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4862|A.3.3(25)]] :LC_I_Grave ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4859|A.3.3(25)]] :LC_Icelandic_Eth ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4863|A.3.3(26)]] :LC_Icelandic_Thorn ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4877|A.3.3(26)]] :LC_J ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4721|A.3.3(13)]] :LC_K ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4722|A.3.3(13)]] :LC_L ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4723|A.3.3(13)]] :LC_M ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4724|A.3.3(13)]] :LC_N ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4725|A.3.3(13)]] :LC_N_Tilde ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4864|A.3.3(26)]] :LC_O ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4726|A.3.3(13)]] :LC_O_Acute ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4866|A.3.3(26)]] :LC_O_Circumflex ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4867|A.3.3(26)]] :LC_O_Diaeresis ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4869|A.3.3(26)]] :LC_O_Grave ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4865|A.3.3(26)]] :LC_O_Oblique_Stroke ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4871|A.3.3(26)]] :LC_O_Tilde ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4868|A.3.3(26)]] :LC_P ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4727|A.3.3(14)]] :LC_Q ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4728|A.3.3(14)]] :LC_R ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4729|A.3.3(14)]] :LC_S ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4730|A.3.3(14)]] :LC_T ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4731|A.3.3(14)]] :LC_U ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4732|A.3.3(14)]] :LC_U_Acute ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4873|A.3.3(26)]] :LC_U_Circumflex ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4874|A.3.3(26)]] :LC_U_Diaeresis ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4875|A.3.3(26)]] :LC_U_Grave ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4872|A.3.3(26)]] :LC_V ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4733|A.3.3(14)]] :LC_W ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4734|A.3.3(14)]] :LC_X ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4735|A.3.3(14)]] :LC_Y ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4736|A.3.3(14)]] :LC_Y_Acute ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4876|A.3.3(26)]] :LC_Y_Diaeresis ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4878|A.3.3(26)]] :LC_Z ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4737|A.3.3(14)]] :Leading_Nonseparate ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6276|B.4(23)]] :Leading_Part attribute [[Guide:95lrm/RM-A-5-3#I5453|A.5.3(54)]] :Leading_Separate ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6274|B.4(23)]] :leaving [[Guide:95lrm/RM-7-6-1#I3160|7.6.1(3)]] :left [[Guide:95lrm/RM-7-6-1#I3161|7.6.1(3)]] :left curly bracket [[Guide:95lrm/RM-2-1#I1165|2.1(15)]] :left parenthesis [[Guide:95lrm/RM-2-1#I1142|2.1(15)]] :left square bracket [[Guide:95lrm/RM-2-1#I1163|2.1(15)]] :Left_Angle_Quotation ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4792|A.3.3(21)]] :Left_Curly_Bracket ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4738|A.3.3(14)]] :Left_Parenthesis ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4690|A.3.3(8)]] :Left_Square_Bracket ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4706|A.3.3(12)]] :legal ::construct [[Guide:95lrm/RM-1-1-2#I1025|1.1.2(27)]] ::partition [[Guide:95lrm/RM-1-1-2#I1033|1.1.2(29)]] :legality rules [[Guide:95lrm/RM-1-1-2#I1022|1.1.2(27)]] :length ::of a dimension of an array [[Guide:95lrm/RM-3-6#I1790|3.6(13)]] ::of a one-dimensional array [[Guide:95lrm/RM-3-6#I1791|3.6(13)]] ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5014|A.4.4(9)]] ::''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5110|A.4.5(6)]] ::''in'' Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6853|F.3.3(11)]] ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6295|B.4(34)]], [[Guide:95lrm/RM-B-4#I6303|B.4(39)]], [[Guide:95lrm/RM-B-4#I6311|B.4(44)]] :Length attribute [[Guide:95lrm/RM-3-6-2#I1830|3.6.2(9)]] :Length(N) attribute [[Guide:95lrm/RM-3-6-2#I1832|3.6.2(10)]] :Length_Check [[Guide:95lrm/RM-11-5#I3932|11.5(15)]] :::[''partial''] [[Guide:95lrm/RM-4-5-1#I2483|4.5.1(8)]], [[Guide:95lrm/RM-4-6#I2660|4.6(37)]], [[Guide:95lrm/RM-4-6#I2688|4.6(52)]] :Length_Error ::''in'' Ada.Strings [[Guide:95lrm/RM-A-4-1#I4884|A.4.1(5)]] :Length_Range ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5012|A.4.4(8)]] :less than operator [[Guide:95lrm/RM-4-4#I2353|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2505|4.5.2(1)]] :less than or equal operator [[Guide:95lrm/RM-4-4#I2357|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2509|4.5.2(1)]] :less-than sign [[Guide:95lrm/RM-2-1#I1157|2.1(15)]] :Less_Than_Sign ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4701|A.3.3(10)]] :letter ::a category of Character [[Guide:95lrm/RM-A-3-2#I4638|A.3.2(24)]] :letter_or_digit [[Guide:95lrm/RM-2-3#I1179|2.3(3)]] ::''used'' [[Guide:95lrm/RM-2-3#I1178|2.3(2)]], [[Guide:95lrm/RM-P#I7299|P]] :Letter_Set ::''in'' Ada.Strings.Maps.Constants [[Guide:95lrm/RM-A-4-6#I5194|A.4.6(4)]] :level ::accessibility [[Guide:95lrm/RM-3-10-2#I2098|3.10.2(3)]] ::library [[Guide:95lrm/RM-3-10-2#I2108|3.10.2(22)]] :lexical element [[Guide:95lrm/RM-2-2#I1168|2.2(1)]] :lexicographic order [[Guide:95lrm/RM-4-5-2#I2529|4.5.2(26)]] :LF ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4660|A.3.3(5)]] :library [[Guide:95lrm/RM-10-1-4#I3753|10.1.4(9)]] ::informal introduction [[Guide:95lrm/RM-10#I3668|10(2)]] :library level [[Guide:95lrm/RM-3-10-2#I2107|3.10.2(22)]] :Library unit [[Guide:95lrm/RM-10-1#I3674|10.1(3)]], [[Guide:95lrm/RM-10-1-1#I3702|10.1.1(9)]] ::informal introduction [[Guide:95lrm/RM-10#I3666|10(2)]] ::''See also'' language-defined library units :library unit pragma [[Guide:95lrm/RM-10-1-5#I3758|10.1.5(7)]] ::All_Calls_Remote [[Guide:95lrm/RM-E-2-3#I6743|E.2.3(6)]] ::categorization pragmas [[Guide:95lrm/RM-E-2#I6707|E.2(2)]] ::Elaborate_Body [[Guide:95lrm/RM-10-2-1#I3826|10.2.1(24)]] ::Preelaborate [[Guide:95lrm/RM-10-2-1#I3801|10.2.1(4)]] ::Pure [[Guide:95lrm/RM-10-2-1#I3811|10.2.1(15)]] :library_item [[Guide:95lrm/RM-10-1-1#I3684|10.1.1(4)]] ::informal introduction [[Guide:95lrm/RM-10#I3667|10(2)]] ::''used'' [[Guide:95lrm/RM-10-1-1#I3681|10.1.1(3)]], [[Guide:95lrm/RM-P#I7827|P]] :library_unit_body [[Guide:95lrm/RM-10-1-1#I3697|10.1.1(7)]] ::''used'' [[Guide:95lrm/RM-10-1-1#I3686|10.1.1(4)]], [[Guide:95lrm/RM-P#I7831|P]] :library_unit_declaration [[Guide:95lrm/RM-10-1-1#I3688|10.1.1(5)]] ::''used'' [[Guide:95lrm/RM-10-1-1#I3685|10.1.1(4)]], [[Guide:95lrm/RM-P#I7830|P]] :library_unit_renaming_declaration [[Guide:95lrm/RM-10-1-1#I3693|10.1.1(6)]] ::''used'' [[Guide:95lrm/RM-10-1-1#I3687|10.1.1(4)]], [[Guide:95lrm/RM-P#I7832|P]] :lifetime [[Guide:95lrm/RM-3-10-2#I2102|3.10.2(3)]] :Limited type [[Guide:95lrm/RM-7-5#I3112|7.5(1)]], [[Guide:95lrm/RM-7-5#I3113|7.5(3)]] ::becoming nonlimited [[Guide:95lrm/RM-7-3-1#I3104|7.3.1(5/1)]], [[Guide:95lrm/RM-7-5#I3117|7.5(16)]] :Limited_Controlled ::''in'' Ada.Finalization [[Guide:95lrm/RM-7-6#I3139|7.6(7)]] :line [[Guide:95lrm/RM-2-2#I1170|2.2(2)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5749|A.10.1(38)]] :line terminator [[Guide:95lrm/RM-A-10#I5609|A.10(7)]] :Line_Length ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5699|A.10.1(25)]] :link name [[Guide:95lrm/RM-B-1#I6081|B.1(35)]] :link-time error ::''See'' post-compilation error [[Guide:95lrm/RM-1-1-2#I1031|1.1.2(29)]] ::''See'' post-compilation error [[Guide:95lrm/RM-1-1-5#I1074|1.1.5(4)]] :Linker_Options pragma [[Guide:95lrm/RM-B-1#I6051|B.1(8)]], [[Guide:95lrm/RM-L#I7208|L(19)]] :linking ::''See'' partition building [[Guide:95lrm/RM-10-2#I3783|10.2(2)]] :List pragma [[Guide:95lrm/RM-2-8#I1255|2.8(21)]], [[Guide:95lrm/RM-L#I7211|L(20)]] :literal [[Guide:95lrm/RM-4-2#I2240|4.2(1)]] ::based [[Guide:95lrm/RM-2-4-2#I1201|2.4.2(1)]] ::decimal [[Guide:95lrm/RM-2-4-1#I1189|2.4.1(1)]] ::numeric [[Guide:95lrm/RM-2-4#I1183|2.4(1)]] ::''See also'' aggregate [[Guide:95lrm/RM-4-3#I2255|4.3(1)]] :little endian [[Guide:95lrm/RM-13-5-3#I4290|13.5.3(2)]] :load time [[Guide:95lrm/RM-C-4#I6431|C.4(3)]] :local to [[Guide:95lrm/RM-8-1#I3180|8.1(14)]] :local_name [[Guide:95lrm/RM-13-1#I4124|13.1(3)]] ::''used'' [[Guide:95lrm/RM-13-2#I4154|13.2(3)]], [[Guide:95lrm/RM-13-3#I4168|13.3(2)]], [[Guide:95lrm/RM-13-4#I4240|13.4(2)]], [[Guide:95lrm/RM-13-5-1#I4257|13.5.1(2)]], [[Guide:95lrm/RM-13-5-1#I4261|13.5.1(3)]], [[Guide:95lrm/RM-13-11-3#I4453|13.11.3(3)]], [[Guide:95lrm/RM-B-1#I6037|B.1(5)]], [[Guide:95lrm/RM-B-1#I6043|B.1(6)]], [[Guide:95lrm/RM-B-1#I6049|B.1(7)]], [[Guide:95lrm/RM-C-5#I6434|C.5(3)]], [[Guide:95lrm/RM-C-6#I6439|C.6(3)]], [[Guide:95lrm/RM-C-6#I6442|C.6(4)]], [[Guide:95lrm/RM-C-6#I6445|C.6(5)]], [[Guide:95lrm/RM-C-6#I6448|C.6(6)]], [[Guide:95lrm/RM-E-4-1#I6784|E.4.1(3)]], [[Guide:95lrm/RM-L#I7149|L(3)]], [[Guide:95lrm/RM-L#I7152|L(4)]], [[Guide:95lrm/RM-L#I7155|L(5)]], [[Guide:95lrm/RM-L#I7162|L(7)]], [[Guide:95lrm/RM-L#I7166|L(8)]], [[Guide:95lrm/RM-L#I7169|L(9)]], [[Guide:95lrm/RM-L#I7184|L(13)]], [[Guide:95lrm/RM-L#I7190|L(14)]], [[Guide:95lrm/RM-L#I7223|L(24)]], [[Guide:95lrm/RM-L#I7265|L(38)]], [[Guide:95lrm/RM-L#I7268|L(39)]], [[Guide:95lrm/RM-P#I7948|P]] :localization [[Guide:95lrm/RM-3-5-2#I1596|3.5.2(4)]], [[Guide:95lrm/RM-3-5-2#I1597|3.5.2(5)]] :locking policy [[Guide:95lrm/RM-D-3#I6562|D.3(6/1)]] :Locking_Policy pragma [[Guide:95lrm/RM-D-3#I6556|D.3(3)]], [[Guide:95lrm/RM-L#I7214|L(21)]] :Log ::''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6925|G.1.2(3)]] ::''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5272|A.5.1(4)]] :Logical ::''in'' Interfaces.Fortran [[Guide:95lrm/RM-B-5#I6337|B.5(7)]] :logical operator [[Guide:95lrm/RM-4-5-1#I2473|4.5.1(2)]] ::''See also'' not operator [[Guide:95lrm/RM-4-5-6#I2591|4.5.6(3)]] :logical_operator [[Guide:95lrm/RM-4-5#I2454|4.5(2)]] :long ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6106|B.3(7)]] :Long_Binary ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6248|B.4(10)]] :long_double ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6128|B.3(17)]] :Long_Float [[Guide:95lrm/RM-3-5-7#I1697|3.5.7(15)]], [[Guide:95lrm/RM-3-5-7#I1699|3.5.7(16)]], [[Guide:95lrm/RM-3-5-7#I1700|3.5.7(17)]] :Long_Floating ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6244|B.4(9)]] :Long_Integer [[Guide:95lrm/RM-3-5-4#I1644|3.5.4(22)]], [[Guide:95lrm/RM-3-5-4#I1645|3.5.4(25)]], [[Guide:95lrm/RM-3-5-4#I1649|3.5.4(28)]] :Look_Ahead ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5765|A.10.1(43)]] :loop parameter [[Guide:95lrm/RM-5-5#I2853|5.5(6)]] :loop_parameter_specification [[Guide:95lrm/RM-5-5#I2850|5.5(4)]] ::''used'' [[Guide:95lrm/RM-5-5#I2849|5.5(3)]], [[Guide:95lrm/RM-P#I7636|P]] :loop_statement [[Guide:95lrm/RM-5-5#I2842|5.5(2)]] ::''used'' [[Guide:95lrm/RM-5-1#I2789|5.1(5)]], [[Guide:95lrm/RM-P#I7612|P]] :low line [[Guide:95lrm/RM-2-1#I1160|2.1(15)]] :low-level programming [[Guide:95lrm/RM-C#I6361|C(1)]] :Low_Line ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4710|A.3.3(12)]] :Low_Order_First [[Guide:95lrm/RM-13-5-3#I4289|13.5.3(2)]] ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6281|B.4(25)]] :lower bound ::of a range [[Guide:95lrm/RM-3-5#I1499|3.5(4)]] :lower-case letter ::a category of Character [[Guide:95lrm/RM-A-3-2#I4639|A.3.2(25)]] :lower_case_identifier_letter [[Guide:95lrm/RM-2-1#I1127|2.1(9)]] :Lower_Case_Map ::''in'' Ada.Strings.Maps.Constants [[Guide:95lrm/RM-A-4-6#I5203|A.4.6(5)]] :Lower_Set ::''in'' Ada.Strings.Maps.Constants [[Guide:95lrm/RM-A-4-6#I5195|A.4.6(4)]] == M == :Machine attribute [[Guide:95lrm/RM-A-5-3#I5458|A.5.3(60)]] :machine code insertion [[Guide:95lrm/RM-13-8#I4357|13.8(1)]], [[Guide:95lrm/RM-C-1#I6366|C.1(2)]] :machine numbers ::of a floating point type [[Guide:95lrm/RM-3-5-7#I1685|3.5.7(8)]] :Machine_Code ::''child of'' System [[Guide:95lrm/RM-13-8#I4362|13.8(7)]] :Machine_Emax attribute [[Guide:95lrm/RM-A-5-3#I5398|A.5.3(8)]] :Machine_Emin attribute [[Guide:95lrm/RM-A-5-3#I5396|A.5.3(7)]] :Machine_Mantissa attribute [[Guide:95lrm/RM-A-5-3#I5394|A.5.3(6)]] :Machine_Overflows attribute [[Guide:95lrm/RM-A-5-3#I5408|A.5.3(12)]], [[Guide:95lrm/RM-A-5-4#I5483|A.5.4(4)]] :Machine_Radix attribute [[Guide:95lrm/RM-A-5-3#I5391|A.5.3(2)]], [[Guide:95lrm/RM-A-5-4#I5479|A.5.4(2)]] :Machine_Radix clause [[Guide:95lrm/RM-13-3#I4191|13.3(7)]], [[Guide:95lrm/RM-F-1#I6817|F.1(1)]] :Machine_Rounds attribute [[Guide:95lrm/RM-A-5-3#I5406|A.5.3(11)]], [[Guide:95lrm/RM-A-5-4#I5481|A.5.4(3)]] :macro ::''See'' generic unit [[Guide:95lrm/RM-12#I3963|12(1)]] :Macron ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4796|A.3.3(21)]] :main subprogram ::for a partition [[Guide:95lrm/RM-10-2#I3786|10.2(7)]] :malloc ::''See'' allocator [[Guide:95lrm/RM-4-8#I2718|4.8(1)]] :Maps ::''child of'' Ada.Strings [[Guide:95lrm/RM-A-4-2#I4898|A.4.2(3)]] :marshalling [[Guide:95lrm/RM-E-4#I6767|E.4(9)]] :Masculine_Ordinal_Indicator ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4809|A.3.3(22)]] :master [[Guide:95lrm/RM-7-6-1#I3162|7.6.1(3)]] :match ::a character to a pattern character [[Guide:95lrm/RM-A-4-2#I4938|A.4.2(54)]] ::a character to a pattern character, with respect to a character mapping function [[Guide:95lrm/RM-A-4-2#I4940|A.4.2(64)]] ::a string to a pattern string [[Guide:95lrm/RM-A-4-2#I4939|A.4.2(54)]] :matching components [[Guide:95lrm/RM-4-5-2#I2527|4.5.2(16)]] :Max attribute [[Guide:95lrm/RM-3-5#I1529|3.5(19)]] :Max_Base_Digits [[Guide:95lrm/RM-3-5-7#I1683|3.5.7(6)]] ::''in'' System [[Guide:95lrm/RM-13-7#I4309|13.7(8)]] :Max_Binary_Modulus [[Guide:95lrm/RM-3-5-4#I1617|3.5.4(7)]] ::''in'' System [[Guide:95lrm/RM-13-7#I4307|13.7(7)]] :Max_Decimal_Digits ::''in'' Ada.Decimal [[Guide:95lrm/RM-F-2#I6825|F.2(5)]] :Max_Delta ::''in'' Ada.Decimal [[Guide:95lrm/RM-F-2#I6824|F.2(4)]] :Max_Digits [[Guide:95lrm/RM-3-5-7#I1684|3.5.7(6)]] ::''in'' System [[Guide:95lrm/RM-13-7#I4310|13.7(8)]] :Max_Digits_Binary ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6249|B.4(11)]] :Max_Digits_Long_Binary ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6250|B.4(11)]] :Max_Image_Width ::''in'' Ada.Numerics.Discrete_Random [[Guide:95lrm/RM-A-5-2#I5376|A.5.2(25)]] ::''in'' Ada.Numerics.Float_Random [[Guide:95lrm/RM-A-5-2#I5354|A.5.2(13)]] :Max_Int [[Guide:95lrm/RM-3-5-4#I1630|3.5.4(14)]] ::''in'' System [[Guide:95lrm/RM-13-7#I4306|13.7(6)]] :Max_Length ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5008|A.4.4(5)]] :Max_Mantissa ::''in'' System [[Guide:95lrm/RM-13-7#I4311|13.7(9)]] :Max_Nonbinary_Modulus [[Guide:95lrm/RM-3-5-4#I1618|3.5.4(7)]] ::''in'' System [[Guide:95lrm/RM-13-7#I4308|13.7(7)]] :Max_Picture_Length ::''in'' Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6845|F.3.3(8)]] :Max_Scale ::''in'' Ada.Decimal [[Guide:95lrm/RM-F-2#I6821|F.2(3)]] :Max_Size_In_Storage_Elements attribute [[Guide:95lrm/RM-13-11-1#I4433|13.11.1(3)]] :maximum box error ::for a component of the result of evaluating a complex function [[Guide:95lrm/RM-G-2-6#I7032|G.2.6(3)]] :maximum line length [[Guide:95lrm/RM-A-10#I5617|A.10(11)]] :maximum page length [[Guide:95lrm/RM-A-10#I5618|A.10(11)]] :maximum relative error ::for a component of the result of evaluating a complex function [[Guide:95lrm/RM-G-2-6#I7031|G.2.6(3)]] ::for the evaluation of an elementary function [[Guide:95lrm/RM-G-2-4#I7025|G.2.4(2)]] :Membership ::''in'' Ada.Strings [[Guide:95lrm/RM-A-4-1#I4893|A.4.1(6)]] :membership test [[Guide:95lrm/RM-4-5-2#I2520|4.5.2(2)]] :Memory_Size ::''in'' System [[Guide:95lrm/RM-13-7#I4319|13.7(13)]] :mentioned in a with_clause [[Guide:95lrm/RM-10-1-2#I3727|10.1.2(6)]] :message ::''See'' dispatching call [[Guide:95lrm/RM-3-9-2#I2011|3.9.2(1)]] :method ::''See'' dispatching subprogram [[Guide:95lrm/RM-3-9-2#I2012|3.9.2(1)]] :metrics [[Guide:95lrm/RM-1-1-2#I1045|1.1.2(35)]] :Micro_Sign ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4803|A.3.3(22)]] :Microseconds ::''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6638|D.8(14)]] :Middle_Dot ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4806|A.3.3(22)]] :Milliseconds ::''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6640|D.8(14)]] :Min attribute [[Guide:95lrm/RM-3-5#I1527|3.5(16)]] :Min_Delta ::''in'' Ada.Decimal [[Guide:95lrm/RM-F-2#I6823|F.2(4)]] :Min_Int [[Guide:95lrm/RM-3-5-4#I1629|3.5.4(14)]] ::''in'' System [[Guide:95lrm/RM-13-7#I4305|13.7(6)]] :Min_Scale ::''in'' Ada.Decimal [[Guide:95lrm/RM-F-2#I6822|F.2(3)]] :minus [[Guide:95lrm/RM-2-1#I1149|2.1(15)]] :minus operator [[Guide:95lrm/RM-4-4#I2375|4.4(1)]], [[Guide:95lrm/RM-4-5-3#I2539|4.5.3(1)]], [[Guide:95lrm/RM-4-5-4#I2562|4.5.4(1)]] :Minus_Sign ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4696|A.3.3(8)]] :mixed-language programs [[Guide:95lrm/RM-B#I6025|B(1)]], [[Guide:95lrm/RM-C-1#I6369|C.1(4)]] :mod operator [[Guide:95lrm/RM-4-4#I2394|4.4(1)]], [[Guide:95lrm/RM-4-5-5#I2576|4.5.5(1)]] :mod_clause [[Guide:95lrm/RM-J-8#I7098|J.8(1)]] ::''used'' [[Guide:95lrm/RM-13-5-1#I4258|13.5.1(2)]], [[Guide:95lrm/RM-P#I7946|P]] :mode [[Guide:95lrm/RM-6-1#I2920|6.1(16)]] ::''used'' [[Guide:95lrm/RM-6-1#I2914|6.1(15)]], [[Guide:95lrm/RM-12-4#I4034|12.4(2)]], [[Guide:95lrm/RM-P#I7667|P]] ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5566|A.8.4(9)]] ::''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5523|A.8.1(9)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5939|A.12.1(11)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5647|A.10.1(12)]] :mode conformance [[Guide:95lrm/RM-6-3-1#I2975|6.3.1(16)]] ::required [[Guide:95lrm/RM-8-5-4#I3266|8.5.4(4)]], [[Guide:95lrm/RM-8-5-4#I3268|8.5.4(5/1)]], [[Guide:95lrm/RM-12-5-4#I4090|12.5.4(5)]], [[Guide:95lrm/RM-12-6#I4102|12.6(7)]], [[Guide:95lrm/RM-12-6#I4103|12.6(8)]] :mode of operation ::nonstandard [[Guide:95lrm/RM-1-1-5#I1081|1.1.5(11)]] ::standard [[Guide:95lrm/RM-1-1-5#I1083|1.1.5(11)]] :Mode_Error ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5590|A.8.4(18)]] ::''in'' Ada.IO_Exceptions [[Guide:95lrm/RM-A-13#I5994|A.13(4)]] ::''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5537|A.8.1(15)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5969|A.12.1(26)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5884|A.10.1(85)]] :Model attribute [[Guide:95lrm/RM-A-5-3#I5472|A.5.3(68)]], [[Guide:95lrm/RM-G-2-2#I7016|G.2.2(7)]] :model interval [[Guide:95lrm/RM-G-2-1#I6999|G.2.1(4)]] ::associated with a value [[Guide:95lrm/RM-G-2-1#I7000|G.2.1(4)]] :model number [[Guide:95lrm/RM-G-2-1#I6998|G.2.1(3)]] :model-oriented attributes ::of a floating point subtype [[Guide:95lrm/RM-A-5-3#I5462|A.5.3(63)]] :Model_Emin attribute [[Guide:95lrm/RM-A-5-3#I5466|A.5.3(65)]], [[Guide:95lrm/RM-G-2-2#I7009|G.2.2(4)]] :Model_Epsilon attribute [[Guide:95lrm/RM-A-5-3#I5468|A.5.3(66)]] :Model_Mantissa attribute [[Guide:95lrm/RM-A-5-3#I5464|A.5.3(64)]], [[Guide:95lrm/RM-G-2-2#I7007|G.2.2(3)]] :Model_Small attribute [[Guide:95lrm/RM-A-5-3#I5470|A.5.3(67)]] :modular type [[Guide:95lrm/RM-3-5-4#I1604|3.5.4(1)]] :Modular_IO ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5805|A.10.1(57)]] :modular_type_definition [[Guide:95lrm/RM-3-5-4#I1612|3.5.4(4)]] ::''used'' [[Guide:95lrm/RM-3-5-4#I1608|3.5.4(2)]], [[Guide:95lrm/RM-P#I7396|P]] :module ::''See'' package [[Guide:95lrm/RM-7#I3055|7(1)]] :modulus :of a modular type [[Guide:95lrm/RM-3-5-4#I1616|3.5.4(7)]] ::''in'' Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6897|G.1.1(9)]] :Modulus attribute [[Guide:95lrm/RM-3-5-4#I1635|3.5.4(17)]] :Month ::''in'' Ada.Calendar [[Guide:95lrm/RM-9-6#I3551|9.6(13)]] :Month_Number ::''in'' Ada.Calendar [[Guide:95lrm/RM-9-6#I3543|9.6(11)]] :Move ::''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4945|A.4.3(7)]] :multi-dimensional array [[Guide:95lrm/RM-3-6#I1787|3.6(12)]] :Multiplication_Sign ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4838|A.3.3(24)]] :multiply [[Guide:95lrm/RM-2-1#I1145|2.1(15)]] :multiply operator [[Guide:95lrm/RM-4-4#I2386|4.4(1)]], [[Guide:95lrm/RM-4-5-5#I2568|4.5.5(1)]] :multiplying operator [[Guide:95lrm/RM-4-5-5#I2564|4.5.5(1)]] :multiplying_operator [[Guide:95lrm/RM-4-5#I2458|4.5(6)]] ::''used'' [[Guide:95lrm/RM-4-4#I2433|4.4(5)]], [[Guide:95lrm/RM-P#I7569|P]] :MW ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4769|A.3.3(18)]] == N == :n-dimensional array_aggregate [[Guide:95lrm/RM-4-3-3#I2315|4.3.3(6)]] :NAK ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4671|A.3.3(6)]] :name [[Guide:95lrm/RM-4-1#I2156|4.1(2)]] ::[''partial''] [[Guide:95lrm/RM-3-1#I1264|3.1(1)]] ::of (a view of) an entity [[Guide:95lrm/RM-3-1#I1286|3.1(8)]] ::of a pragma [[Guide:95lrm/RM-2-8#I1246|2.8(9)]] ::of an external file [[Guide:95lrm/RM-A-7#I5487|A.7(1)]] ::''used'' [[Guide:95lrm/RM-2-8#I1243|2.8(3)]], [[Guide:95lrm/RM-3-2-2#I1359|3.2.2(4)]], [[Guide:95lrm/RM-4-1#I2170|4.1(4)]], [[Guide:95lrm/RM-4-1#I2173|4.1(5)]], [[Guide:95lrm/RM-4-1#I2175|4.1(6)]], [[Guide:95lrm/RM-4-4#I2444|4.4(7)]], [[Guide:95lrm/RM-4-6#I2614|4.6(2)]], [[Guide:95lrm/RM-5-2#I2802|5.2(2)]], [[Guide:95lrm/RM-5-7#I2867|5.7(2)]], [[Guide:95lrm/RM-5-8#I2872|5.8(2)]], [[Guide:95lrm/RM-6-3-2#I2992|6.3.2(3)]], [[Guide:95lrm/RM-6-4#I2995|6.4(2)]], [[Guide:95lrm/RM-6-4#I2999|6.4(3)]], [[Guide:95lrm/RM-6-4#I3010|6.4(6)]], [[Guide:95lrm/RM-8-4#I3231|8.4(3)]], [[Guide:95lrm/RM-8-5-1#I3253|8.5.1(2)]], [[Guide:95lrm/RM-8-5-2#I3256|8.5.2(2)]], [[Guide:95lrm/RM-8-5-3#I3259|8.5.3(2)]], [[Guide:95lrm/RM-8-5-4#I3264|8.5.4(2)]], [[Guide:95lrm/RM-8-5-5#I3274|8.5.5(2)]], [[Guide:95lrm/RM-9-5-3#I3485|9.5.3(2)]], [[Guide:95lrm/RM-9-5-4#I3513|9.5.4(2)]], [[Guide:95lrm/RM-9-8#I3636|9.8(2)]], [[Guide:95lrm/RM-10-1-1#I3701|10.1.1(8)]], [[Guide:95lrm/RM-10-1-2#I3724|10.1.2(4)]], [[Guide:95lrm/RM-10-2-1#I3800|10.2.1(3)]], [[Guide:95lrm/RM-10-2-1#I3810|10.2.1(14)]], [[Guide:95lrm/RM-10-2-1#I3818|10.2.1(20)]], [[Guide:95lrm/RM-10-2-1#I3822|10.2.1(21)]], [[Guide:95lrm/RM-10-2-1#I3825|10.2.1(22)]], [[Guide:95lrm/RM-11-2#I3862|11.2(5)]], [[Guide:95lrm/RM-11-3#I3867|11.3(2)]], [[Guide:95lrm/RM-11-5#I3923|11.5(4)]], [[Guide:95lrm/RM-12-3#I3999|12.3(2)]], [[Guide:95lrm/RM-12-3#I4009|12.3(5)]], [[Guide:95lrm/RM-12-6#I4099|12.6(4)]], [[Guide:95lrm/RM-12-7#I4108|12.7(2)]], [[Guide:95lrm/RM-13-1#I4128|13.1(3)]], [[Guide:95lrm/RM-13-3#I4170|13.3(2)]], [[Guide:95lrm/RM-C-3-1#I6385|C.3.1(2)]], [[Guide:95lrm/RM-C-3-1#I6388|C.3.1(4)]], [[Guide:95lrm/RM-E-2-1#I6718|E.2.1(3)]], [[Guide:95lrm/RM-E-2-2#I6730|E.2.2(3)]], [[Guide:95lrm/RM-E-2-3#I6739|E.2.3(3)]], [[Guide:95lrm/RM-E-2-3#I6742|E.2.3(5)]], [[Guide:95lrm/RM-H-3-2#I7052|H.3.2(3)]], [[Guide:95lrm/RM-L#I7146|L(2)]], [[Guide:95lrm/RM-L#I7158|L(6)]], [[Guide:95lrm/RM-L#I7172|L(10)]], [[Guide:95lrm/RM-L#I7176|L(11)]], [[Guide:95lrm/RM-L#I7180|L(12)]], [[Guide:95lrm/RM-L#I7196|L(15)]], [[Guide:95lrm/RM-L#I7200|L(16)]], [[Guide:95lrm/RM-L#I7203|L(17)]], [[Guide:95lrm/RM-L#I7228|L(26)]], [[Guide:95lrm/RM-L#I7234|L(28)]], [[Guide:95lrm/RM-L#I7240|L(30)]], [[Guide:95lrm/RM-L#I7243|L(31)]], [[Guide:95lrm/RM-L#I7252|L(34)]], [[Guide:95lrm/RM-L#I7259|L(36)]], [[Guide:95lrm/RM-P#I7885|P]] ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5568|A.8.4(9)]] ::''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5525|A.8.1(9)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5941|A.12.1(11)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5649|A.10.1(12)]] ::''in'' System [[Guide:95lrm/RM-13-7#I4303|13.7(4)]] :name resolution rules [[Guide:95lrm/RM-1-1-2#I1019|1.1.2(26)]] :Name_Error ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5591|A.8.4(18)]] ::''in'' Ada.IO_Exceptions [[Guide:95lrm/RM-A-13#I5995|A.13(4)]] ::''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5538|A.8.1(15)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5970|A.12.1(26)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5885|A.10.1(85)]] :named association [[Guide:95lrm/RM-6-4#I3011|6.4(7)]], [[Guide:95lrm/RM-12-3#I4014|12.3(6)]] :named component association [[Guide:95lrm/RM-4-3-1#I2277|4.3.1(6)]] :named discriminant association [[Guide:95lrm/RM-3-7-1#I1878|3.7.1(4)]] :named entry index [[Guide:95lrm/RM-9-5-2#I3473|9.5.2(21)]] :named number [[Guide:95lrm/RM-3-3#I1398|3.3(24)]] :named type [[Guide:95lrm/RM-3-2-1#I1343|3.2.1(7)]] :named_array_aggregate [[Guide:95lrm/RM-4-3-3#I2309|4.3.3(4)]] ::''used'' [[Guide:95lrm/RM-4-3-3#I2301|4.3.3(2)]], [[Guide:95lrm/RM-P#I7536|P]] :Names ::''child of'' Ada.Interrupts [[Guide:95lrm/RM-C-3-2#I6424|C.3.2(12)]] :names of special_characters [[Guide:95lrm/RM-2-1#I1135|2.1(15)]] :Nanoseconds ::''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6636|D.8(14)]] :Native_Binary ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6282|B.4(25)]] :Natural [[Guide:95lrm/RM-3-5-4#I1626|3.5.4(12)]] ::''in'' Standard [[Guide:95lrm/RM-A-1#I4553|A.1(13)]] :NBH ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4751|A.3.3(17)]] :NBSP ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4781|A.3.3(21)]] :needed ::of a compilation unit by another [[Guide:95lrm/RM-10-2#I3785|10.2(2)]] ::remote call interface [[Guide:95lrm/RM-E-2-3#I6751|E.2.3(18)]] ::shared passive library unit [[Guide:95lrm/RM-E-2-1#I6724|E.2.1(11)]] :needed component ::extension_aggregate record_component_association_list [[Guide:95lrm/RM-4-3-2#I2294|4.3.2(6)]] ::record_aggregate record_component_association_list [[Guide:95lrm/RM-4-3-1#I2280|4.3.1(9)]] :NEL ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4753|A.3.3(17)]] :new ::''See'' allocator [[Guide:95lrm/RM-4-8#I2717|4.8(1)]] :New_Char_Array ::''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6183|B.3.1(9)]] :New_Line ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5707|A.10.1(28)]] :New_Page ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5719|A.10.1(31)]] :New_String ::''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6185|B.3.1(10)]] :No_Break_Space ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4780|A.3.3(21)]] :nominal subtype [[Guide:95lrm/RM-3-3#I1393|3.3(23)]], [[Guide:95lrm/RM-3-3-1#I1422|3.3.1(8)]] ::associated with a dereference [[Guide:95lrm/RM-4-1#I2178|4.1(9)]] ::associated with a type_conversion [[Guide:95lrm/RM-4-6#I2646|4.6(27)]] ::associated with an indexed_component [[Guide:95lrm/RM-4-1-1#I2193|4.1.1(5)]] ::of a component [[Guide:95lrm/RM-3-6#I1799|3.6(20)]] ::of a formal parameter [[Guide:95lrm/RM-6-1#I2928|6.1(23)]] ::of a generic formal object [[Guide:95lrm/RM-12-4#I4039|12.4(9)]] ::of a record component [[Guide:95lrm/RM-3-8#I1912|3.8(14)]] ::of the result of a function_call [[Guide:95lrm/RM-6-4#I3015|6.4(12)]] :non-normative ::''See'' informative [[Guide:95lrm/RM-1-1-2#I1012|1.1.2(18)]] :nondispatching call ::on a dispatching operation [[Guide:95lrm/RM-3-9-2#I2003|3.9.2(1)]] :nonexistent [[Guide:95lrm/RM-13-11-2#I4443|13.11.2(10)]], [[Guide:95lrm/RM-13-11-2#I4449|13.11.2(16)]] :nongraphic character [[Guide:95lrm/RM-3-5#I1547|3.5(32)]] :nonlimited type [[Guide:95lrm/RM-7-5#I3114|7.5(7)]] ::becoming nonlimited [[Guide:95lrm/RM-7-3-1#I3103|7.3.1(5/1)]], [[Guide:95lrm/RM-7-5#I3116|7.5(16)]] :nonstandard integer type [[Guide:95lrm/RM-3-5-4#I1647|3.5.4(26)]] :nonstandard mode [[Guide:95lrm/RM-1-1-5#I1082|1.1.5(11)]] :nonstandard real type [[Guide:95lrm/RM-3-5-6#I1672|3.5.6(8)]] :normal completion [[Guide:95lrm/RM-7-6-1#I3156|7.6.1(2)]] :normal library unit [[Guide:95lrm/RM-E-2#I6713|E.2(4/1)]] :normal state of an object [[Guide:95lrm/RM-11-6#I3957|11.6(6)]], [[Guide:95lrm/RM-13-9-1#I4379|13.9.1(4)]] ::[''partial''] [[Guide:95lrm/RM-9-8#I3649|9.8(21)]], [[Guide:95lrm/RM-A-13#I6002|A.13(17)]] :Normalize_Scalars pragma [[Guide:95lrm/RM-H-1#I7042|H.1(3)]], [[Guide:95lrm/RM-L#I7217|L(22)]] :normalized exponent [[Guide:95lrm/RM-A-5-3#I5411|A.5.3(14)]] :normalized number [[Guide:95lrm/RM-A-5-3#I5402|A.5.3(10)]] :normative [[Guide:95lrm/RM-1-1-2#I1009|1.1.2(14)]] :not equal operator [[Guide:95lrm/RM-4-4#I2349|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2501|4.5.2(1)]] :not in (membership test) [[Guide:95lrm/RM-4-4#I2368|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2522|4.5.2(2)]] :not operator [[Guide:95lrm/RM-4-4#I2405|4.4(1)]], [[Guide:95lrm/RM-4-5-6#I2589|4.5.6(3)]] :Not_Sign ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4793|A.3.3(21)]] :notes [[Guide:95lrm/RM-1-1-2#I1049|1.1.2(38)]] :notwithstanding [[Guide:95lrm/RM-10-1-6#I3768|10.1.6(2)]], [[Guide:95lrm/RM-B-1#I6059|B.1(22)]], [[Guide:95lrm/RM-B-1#I6083|B.1(38)]], [[Guide:95lrm/RM-C-3-1#I6402|C.3.1(19)]], [[Guide:95lrm/RM-E-2-1#I6721|E.2.1(8)]], [[Guide:95lrm/RM-E-2-1#I6725|E.2.1(11)]], [[Guide:95lrm/RM-E-2-3#I6752|E.2.3(18)]], [[Guide:95lrm/RM-J-3#I7081|J.3(6)]] :NUL ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4650|A.3.3(5)]] ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6131|B.3(20/1)]] :null access value [[Guide:95lrm/RM-4-2#I2248|4.2(9)]] :null array [[Guide:95lrm/RM-3-6-1#I1813|3.6.1(7)]] :null constraint [[Guide:95lrm/RM-3-2#I1315|3.2(7)]] :null pointer ::''See'' null access value [[Guide:95lrm/RM-4-2#I2249|4.2(9)]] :null range [[Guide:95lrm/RM-3-5#I1502|3.5(4)]] :null record [[Guide:95lrm/RM-3-8#I1913|3.8(15)]] :null slice [[Guide:95lrm/RM-4-1-2#I2207|4.1.2(7)]] :null string literal [[Guide:95lrm/RM-2-6#I1233|2.6(6)]] :null value ::of an access type [[Guide:95lrm/RM-3-10#I2080|3.10(13)]] :Null_Address ::''in'' System [[Guide:95lrm/RM-13-7#I4316|13.7(12)]] :Null_Bounded_String ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5011|A.4.4(7)]] :Null_Id ::''in'' Ada.Exceptions [[Guide:95lrm/RM-11-4-1#I3887|11.4.1(2)]] :Null_Occurrence ::''in'' Ada.Exceptions [[Guide:95lrm/RM-11-4-1#I3894|11.4.1(3)]] :Null_Ptr ::''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6179|B.3.1(7)]] :Null_Set ::''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4903|A.4.2(5)]] ::''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5220|A.4.7(5)]] :null_statement [[Guide:95lrm/RM-5-1#I2793|5.1(6)]] ::''used'' [[Guide:95lrm/RM-5-1#I2774|5.1(4)]], [[Guide:95lrm/RM-P#I7598|P]] :Null_Task_ID ::''in'' Ada.Task_Identification [[Guide:95lrm/RM-C-7-1#I6469|C.7.1(2)]] :Null_Unbounded_String ::''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5108|A.4.5(5)]] :number sign [[Guide:95lrm/RM-2-1#I1138|2.1(15)]] :Number_Base ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5631|A.10.1(6)]] :number_declaration [[Guide:95lrm/RM-3-3-2#I1439|3.3.2(2)]] ::''used'' [[Guide:95lrm/RM-3-1#I1269|3.1(3)]], [[Guide:95lrm/RM-P#I7335|P]] :Number_Sign ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4685|A.3.3(8)]] :numeral [[Guide:95lrm/RM-2-4-1#I1194|2.4.1(3)]] ::''used'' [[Guide:95lrm/RM-2-4-1#I1192|2.4.1(2)]], [[Guide:95lrm/RM-2-4-1#I1200|2.4.1(4)]], [[Guide:95lrm/RM-2-4-2#I1217|2.4.2(3)]], [[Guide:95lrm/RM-P#I7304|P]] :Numeric ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6270|B.4(20)]] :numeric type [[Guide:95lrm/RM-3-5#I1491|3.5(1)]] :numeric_literal [[Guide:95lrm/RM-2-4#I1186|2.4(2)]] ::''used'' [[Guide:95lrm/RM-4-4#I2441|4.4(7)]], [[Guide:95lrm/RM-P#I7575|P]] :numerics [[Guide:95lrm/RM-G#I6868|G(1)]] ::''child of'' Ada [[Guide:95lrm/RM-A-5#I5260|A.5(3)]] == O == :object [[Guide:95lrm/RM-3-3#I1384|3.3(2)]] ::[''partial''] [[Guide:95lrm/RM-3-2#I1298|3.2(1)]] :object-oriented programming (OOP) ::''See'' dispatching operations of tagged types [[Guide:95lrm/RM-3-9-2#I2009|3.9.2(1)]] ::''See'' tagged types and type extensions [[Guide:95lrm/RM-3-9#I1949|3.9(1)]] :object_declaration [[Guide:95lrm/RM-3-3-1#I1405|3.3.1(2)]] ::''used'' [[Guide:95lrm/RM-3-1#I1268|3.1(3)]], [[Guide:95lrm/RM-P#I7334|P]] :object_renaming_declaration [[Guide:95lrm/RM-8-5-1#I3250|8.5.1(2)]] ::''used'' [[Guide:95lrm/RM-8-5#I3242|8.5(2)]], [[Guide:95lrm/RM-P#I7712|P]] :obsolescent feature [[Guide:95lrm/RM-J#I7076|J(1)]] :occur immediately within [[Guide:95lrm/RM-8-1#I3175|8.1(13)]] :occurrence ::of an interrupt [[Guide:95lrm/RM-C-3#I6374|C.3(2)]] :octal ::literal [[Guide:95lrm/RM-2-4-2#I1207|2.4.2(1)]] :octal literal [[Guide:95lrm/RM-2-4-2#I1205|2.4.2(1)]] :one's complement ::modular types [[Guide:95lrm/RM-3-5-4#I1648|3.5.4(27)]] :one-dimensional array [[Guide:95lrm/RM-3-6#I1786|3.6(12)]] :only as a completion ::entry_body [[Guide:95lrm/RM-9-5-2#I3464|9.5.2(16)]] :OOP (object-oriented programming) ::''See'' dispatching operations of tagged types [[Guide:95lrm/RM-3-9-2#I2010|3.9.2(1)]] ::''See'' tagged types and type extensions [[Guide:95lrm/RM-3-9#I1950|3.9(1)]] :opaque type ::''See'' private types and private extensions [[Guide:95lrm/RM-7-3#I3080|7.3(1)]] :Open ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5556|A.8.4(7)]] ::''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5513|A.8.1(7)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5929|A.12.1(9)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5637|A.10.1(10)]] :open alternative [[Guide:95lrm/RM-9-7-1#I3597|9.7.1(14)]] :open entry [[Guide:95lrm/RM-9-5-3#I3487|9.5.3(5)]] ::of a protected object [[Guide:95lrm/RM-9-5-3#I3493|9.5.3(7)]] ::of a task [[Guide:95lrm/RM-9-5-3#I3491|9.5.3(6)]] :operand ::of a qualified_expression [[Guide:95lrm/RM-4-7#I2707|4.7(3)]] ::of a type_conversion [[Guide:95lrm/RM-4-6#I2616|4.6(3)]] :operand interval [[Guide:95lrm/RM-G-2-1#I7001|G.2.1(6)]] :operand type ::of a type_conversion [[Guide:95lrm/RM-4-6#I2617|4.6(3)]] :operates on a type [[Guide:95lrm/RM-3-2-3#I1377|3.2.3(1)]] :operational aspect [[Guide:95lrm/RM-13-1#I4141|13.1(8.1/1)]] ::specifiable attributes [[Guide:95lrm/RM-13-3#I4176|13.3(5/1)]] :operational item [[Guide:95lrm/RM-13-1#I4118|13.1(1.1/1)]] :operator [[Guide:95lrm/RM-6-6#I3049|6.6(1)]] ::& [[Guide:95lrm/RM-4-4#I2378|4.4(1)]], [[Guide:95lrm/RM-4-5-3#I2542|4.5.3(3)]] ::<nowiki>*</nowiki> [[Guide:95lrm/RM-4-4#I2385|4.4(1)]], [[Guide:95lrm/RM-4-5-5#I2567|4.5.5(1)]] ::<nowiki>**</nowiki> [[Guide:95lrm/RM-4-4#I2399|4.4(1)]], [[Guide:95lrm/RM-4-5-6#I2598|4.5.6(7)]] ::+ [[Guide:95lrm/RM-4-4#I2370|4.4(1)]], [[Guide:95lrm/RM-4-5-3#I2534|4.5.3(1)]], [[Guide:95lrm/RM-4-5-4#I2557|4.5.4(1)]] ::- [[Guide:95lrm/RM-4-4#I2374|4.4(1)]], [[Guide:95lrm/RM-4-5-3#I2538|4.5.3(1)]], [[Guide:95lrm/RM-4-5-4#I2561|4.5.4(1)]] ::/ [[Guide:95lrm/RM-4-4#I2391|4.4(1)]], [[Guide:95lrm/RM-4-5-5#I2573|4.5.5(1)]] ::/= [[Guide:95lrm/RM-4-4#I2348|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2500|4.5.2(1)]] ::< [[Guide:95lrm/RM-4-4#I2352|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2504|4.5.2(1)]] ::<= [[Guide:95lrm/RM-4-4#I2356|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2508|4.5.2(1)]] ::<nowiki>=</nowiki> [[Guide:95lrm/RM-4-4#I2344|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2496|4.5.2(1)]] ::> [[Guide:95lrm/RM-4-4#I2360|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2512|4.5.2(1)]] ::>= [[Guide:95lrm/RM-4-4#I2364|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2516|4.5.2(1)]] ::abs [[Guide:95lrm/RM-4-4#I2403|4.4(1)]], [[Guide:95lrm/RM-4-5-6#I2587|4.5.6(1)]] ::ampersand [[Guide:95lrm/RM-4-4#I2380|4.4(1)]], [[Guide:95lrm/RM-4-5-3#I2544|4.5.3(3)]] ::and [[Guide:95lrm/RM-4-4#I2336|4.4(1)]], [[Guide:95lrm/RM-4-5-1#I2476|4.5.1(2)]] ::binary [[Guide:95lrm/RM-4-5#I2463|4.5(9)]] ::binary adding [[Guide:95lrm/RM-4-5-3#I2532|4.5.3(1)]] ::concatenation [[Guide:95lrm/RM-4-4#I2382|4.4(1)]], [[Guide:95lrm/RM-4-5-3#I2546|4.5.3(3)]] ::divide [[Guide:95lrm/RM-4-4#I2393|4.4(1)]], [[Guide:95lrm/RM-4-5-5#I2575|4.5.5(1)]] ::equal [[Guide:95lrm/RM-4-4#I2346|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2498|4.5.2(1)]] ::equality [[Guide:95lrm/RM-4-5-2#I2492|4.5.2(1)]] ::exponentiation [[Guide:95lrm/RM-4-4#I2401|4.4(1)]], [[Guide:95lrm/RM-4-5-6#I2596|4.5.6(7)]] ::greater than [[Guide:95lrm/RM-4-4#I2362|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2514|4.5.2(1)]] ::greater than or equal [[Guide:95lrm/RM-4-4#I2366|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2518|4.5.2(1)]] ::highest precedence [[Guide:95lrm/RM-4-5-6#I2585|4.5.6(1)]] ::less than [[Guide:95lrm/RM-4-4#I2354|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2506|4.5.2(1)]] ::less than or equal [[Guide:95lrm/RM-4-4#I2358|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2510|4.5.2(1)]] ::logical [[Guide:95lrm/RM-4-5-1#I2474|4.5.1(2)]] ::minus [[Guide:95lrm/RM-4-4#I2376|4.4(1)]], [[Guide:95lrm/RM-4-5-3#I2540|4.5.3(1)]], [[Guide:95lrm/RM-4-5-4#I2563|4.5.4(1)]] ::mod [[Guide:95lrm/RM-4-4#I2395|4.4(1)]], [[Guide:95lrm/RM-4-5-5#I2577|4.5.5(1)]] ::multiply [[Guide:95lrm/RM-4-4#I2387|4.4(1)]], [[Guide:95lrm/RM-4-5-5#I2569|4.5.5(1)]] ::multiplying [[Guide:95lrm/RM-4-5-5#I2565|4.5.5(1)]] ::not [[Guide:95lrm/RM-4-4#I2406|4.4(1)]], [[Guide:95lrm/RM-4-5-6#I2590|4.5.6(3)]] ::not equal [[Guide:95lrm/RM-4-4#I2350|4.4(1)]], [[Guide:95lrm/RM-4-5-2#I2502|4.5.2(1)]] ::or [[Guide:95lrm/RM-4-4#I2338|4.4(1)]], [[Guide:95lrm/RM-4-5-1#I2478|4.5.1(2)]] ::ordering [[Guide:95lrm/RM-4-5-2#I2494|4.5.2(1)]] ::plus [[Guide:95lrm/RM-4-4#I2372|4.4(1)]], [[Guide:95lrm/RM-4-5-3#I2536|4.5.3(1)]], [[Guide:95lrm/RM-4-5-4#I2559|4.5.4(1)]] ::predefined [[Guide:95lrm/RM-4-5#I2461|4.5(9)]] ::relational [[Guide:95lrm/RM-4-5-2#I2489|4.5.2(1)]] ::rem [[Guide:95lrm/RM-4-4#I2397|4.4(1)]], [[Guide:95lrm/RM-4-5-5#I2579|4.5.5(1)]] ::times [[Guide:95lrm/RM-4-4#I2389|4.4(1)]], [[Guide:95lrm/RM-4-5-5#I2571|4.5.5(1)]] ::unary [[Guide:95lrm/RM-4-5#I2465|4.5(9)]] ::unary adding [[Guide:95lrm/RM-4-5-4#I2555|4.5.4(1)]] ::user-defined [[Guide:95lrm/RM-6-6#I3051|6.6(1)]] ::xor [[Guide:95lrm/RM-4-4#I2340|4.4(1)]], [[Guide:95lrm/RM-4-5-1#I2480|4.5.1(2)]] :operator precedence [[Guide:95lrm/RM-4-5#I2453|4.5(1)]] :operator_symbol [[Guide:95lrm/RM-6-1#I2900|6.1(9)]] ::''used'' [[Guide:95lrm/RM-4-1#I2168|4.1(3)]], [[Guide:95lrm/RM-4-1-3#I2216|4.1.3(3)]], [[Guide:95lrm/RM-6-1#I2893|6.1(5)]], [[Guide:95lrm/RM-6-1#I2903|6.1(11)]], [[Guide:95lrm/RM-P#I7499|P]] :optimization [[Guide:95lrm/RM-11-5#I3944|11.5(29)]], [[Guide:95lrm/RM-11-6#I3950|11.6(1)]] :Optimize pragma [[Guide:95lrm/RM-2-8#I1260|2.8(23)]], [[Guide:95lrm/RM-L#I7219|L(23)]] :or else (short-circuit control form) [[Guide:95lrm/RM-4-4#I2342|4.4(1)]], [[Guide:95lrm/RM-4-5-1#I2471|4.5.1(1)]] :or operator [[Guide:95lrm/RM-4-4#I2337|4.4(1)]], [[Guide:95lrm/RM-4-5-1#I2477|4.5.1(2)]] :ordering operator [[Guide:95lrm/RM-4-5-2#I2493|4.5.2(1)]] :ordinary fixed point type [[Guide:95lrm/RM-3-5-9#I1705|3.5.9(1)]], [[Guide:95lrm/RM-3-5-9#I1726|3.5.9(8)]] :ordinary_fixed_point_definition [[Guide:95lrm/RM-3-5-9#I1711|3.5.9(3)]] ::''used'' [[Guide:95lrm/RM-3-5-9#I1709|3.5.9(2)]], [[Guide:95lrm/RM-P#I7406|P]] :OSC ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4777|A.3.3(19)]] :other_control_function [[Guide:95lrm/RM-2-1#I1133|2.1(14)]] ::''used'' [[Guide:95lrm/RM-2-1#I1118|2.1(2)]], [[Guide:95lrm/RM-P#I7292|P]] :output [[Guide:95lrm/RM-A-6#I5485|A.6(1)]] :Output attribute [[Guide:95lrm/RM-13-13-2#I4498|13.13.2(19)]], [[Guide:95lrm/RM-13-13-2#I4502|13.13.2(29)]] :Output clause [[Guide:95lrm/RM-13-3#I4190|13.3(7)]], [[Guide:95lrm/RM-13-13-2#I4516|13.13.2(36/1)]] :overall interpretation ::of a complete context [[Guide:95lrm/RM-8-6#I3284|8.6(10)]] :Overflow_Check [[Guide:95lrm/RM-11-5#I3933|11.5(16)]] ::[''partial''] [[Guide:95lrm/RM-3-5-4#I1637|3.5.4(20)]], [[Guide:95lrm/RM-4-4#I2449|4.4(11)]], [[Guide:95lrm/RM-5-4#I2839|5.4(13)]], [[Guide:95lrm/RM-G-2-1#I7003|G.2.1(11)]], [[Guide:95lrm/RM-G-2-2#I7017|G.2.2(7)]], [[Guide:95lrm/RM-G-2-3#I7021|G.2.3(25)]], [[Guide:95lrm/RM-G-2-4#I7026|G.2.4(2)]], [[Guide:95lrm/RM-G-2-6#I7033|G.2.6(3)]] :overload resolution [[Guide:95lrm/RM-8-6#I3279|8.6(1)]] :overloadable [[Guide:95lrm/RM-8-3#I3205|8.3(7)]] :overloaded [[Guide:95lrm/RM-8-3#I3204|8.3(6)]] ::enumeration literal [[Guide:95lrm/RM-3-5-1#I1583|3.5.1(9)]] :overloading rules [[Guide:95lrm/RM-1-1-2#I1020|1.1.2(26)]], [[Guide:95lrm/RM-8-6#I3280|8.6(2)]] :overridable [[Guide:95lrm/RM-8-3#I3209|8.3(9/1)]] :override [[Guide:95lrm/RM-8-3#I3208|8.3(9/1)]], [[Guide:95lrm/RM-12-3#I4027|12.3(17)]] ::a primitive subprogram [[Guide:95lrm/RM-3-2-3#I1381|3.2.3(7)]] :Overwrite ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5074|A.4.4(62)]], [[Guide:95lrm/RM-A-4-4#I5076|A.4.4(63)]] ::''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4979|A.4.3(27)]], [[Guide:95lrm/RM-A-4-3#I4981|A.4.3(28)]] ::''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5166|A.4.5(57)]], [[Guide:95lrm/RM-A-4-5#I5168|A.4.5(58)]] == P == :Pack pragma [[Guide:95lrm/RM-13-2#I4153|13.2(3)]], [[Guide:95lrm/RM-L#I7222|L(24)]] :Package [[Guide:95lrm/RM-7#I3052|7(1)]] :package instance [[Guide:95lrm/RM-12-3#I4019|12.3(13)]] :package_body [[Guide:95lrm/RM-7-2#I3070|7.2(2)]] ::''used'' [[Guide:95lrm/RM-3-11#I2142|3.11(6)]], [[Guide:95lrm/RM-10-1-1#I3699|10.1.1(7)]], [[Guide:95lrm/RM-P#I7841|P]] :package_body_stub [[Guide:95lrm/RM-10-1-3#I3736|10.1.3(4)]] ::''used'' [[Guide:95lrm/RM-10-1-3#I3731|10.1.3(2)]], [[Guide:95lrm/RM-P#I7849|P]] :package_declaration [[Guide:95lrm/RM-7-1#I3057|7.1(2)]] ::''used'' [[Guide:95lrm/RM-3-1#I1272|3.1(3)]], [[Guide:95lrm/RM-10-1-1#I3690|10.1.1(5)]], [[Guide:95lrm/RM-P#I7338|P]] :package_renaming_declaration [[Guide:95lrm/RM-8-5-3#I3257|8.5.3(2)]] ::''used'' [[Guide:95lrm/RM-8-5#I3244|8.5(2)]], [[Guide:95lrm/RM-10-1-1#I3694|10.1.1(6)]], [[Guide:95lrm/RM-P#I7837|P]] :package_specification [[Guide:95lrm/RM-7-1#I3059|7.1(3)]] ::''used'' [[Guide:95lrm/RM-7-1#I3058|7.1(2)]], [[Guide:95lrm/RM-12-1#I3973|12.1(4)]], [[Guide:95lrm/RM-P#I7690|P]] :packed [[Guide:95lrm/RM-13-2#I4159|13.2(5)]] :Packed_Decimal ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6254|B.4(12)]] :Packed_Format ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6284|B.4(26)]] :Packed_Signed ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6286|B.4(27)]] :Packed_Unsigned ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6285|B.4(27)]] :packing ::aspect of representation [[Guide:95lrm/RM-13-2#I4158|13.2(5)]] :padding bits [[Guide:95lrm/RM-13-1#I4133|13.1(7)]] :Page ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5753|A.10.1(39)]] :Page pragma [[Guide:95lrm/RM-2-8#I1258|2.8(22)]], [[Guide:95lrm/RM-L#I7225|L(25)]] :page terminator [[Guide:95lrm/RM-A-10#I5610|A.10(7)]] :Page_Length ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5703|A.10.1(26)]] :Paragraph_Sign ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4805|A.3.3(22)]] :parallel processing ::''See'' task [[Guide:95lrm/RM-9#I3308|9(1)]] :parameter ::''See'' formal parameter [[Guide:95lrm/RM-6-1#I2923|6.1(17)]] ::''See'' generic formal parameter [[Guide:95lrm/RM-12#I3964|12(1)]] ::''See also'' discriminant [[Guide:95lrm/RM-3-7#I1837|3.7(1)]] ::''See also'' loop parameter [[Guide:95lrm/RM-5-5#I2854|5.5(6)]] :parameter assigning back [[Guide:95lrm/RM-6-4-1#I3029|6.4.1(17)]] :parameter copy back [[Guide:95lrm/RM-6-4-1#I3027|6.4.1(17)]] :parameter mode [[Guide:95lrm/RM-6-1#I2924|6.1(18)]] :parameter passing [[Guide:95lrm/RM-6-4-1#I3017|6.4.1(1)]] :parameter_and_result_profile [[Guide:95lrm/RM-6-1#I2906|6.1(13)]] ::''used'' [[Guide:95lrm/RM-3-10#I2055|3.10(5)]], [[Guide:95lrm/RM-6-1#I2889|6.1(4)]], [[Guide:95lrm/RM-P#I7651|P]] :parameter_association [[Guide:95lrm/RM-6-4#I3005|6.4(5)]] ::''used'' [[Guide:95lrm/RM-6-4#I3003|6.4(4)]], [[Guide:95lrm/RM-P#I7684|P]] :parameter_profile [[Guide:95lrm/RM-6-1#I2904|6.1(12)]] ::''used'' [[Guide:95lrm/RM-3-10#I2054|3.10(5)]], [[Guide:95lrm/RM-6-1#I2887|6.1(4)]], [[Guide:95lrm/RM-9-5-2#I3436|9.5.2(2)]], [[Guide:95lrm/RM-9-5-2#I3440|9.5.2(3)]], [[Guide:95lrm/RM-9-5-2#I3454|9.5.2(6)]], [[Guide:95lrm/RM-P#I7472|P]] :parameter_specification [[Guide:95lrm/RM-6-1#I2912|6.1(15)]] ::''used'' [[Guide:95lrm/RM-6-1#I2910|6.1(14)]], [[Guide:95lrm/RM-P#I7664|P]] :Parameterless_Handler ::''in'' Ada.Interrupts [[Guide:95lrm/RM-C-3-2#I6409|C.3.2(2)]] :Params_Stream_Type ::''in'' System.RPC [[Guide:95lrm/RM-E-5#I6798|E.5(6)]] :parent body ::of a subunit [[Guide:95lrm/RM-10-1-3#I3745|10.1.3(8)]] :parent declaration ::of a library unit [[Guide:95lrm/RM-10-1-1#I3705|10.1.1(10)]] ::of a library_item [[Guide:95lrm/RM-10-1-1#I3704|10.1.1(10)]] :parent subtype [[Guide:95lrm/RM-3-4#I1450|3.4(3)]] :parent type [[Guide:95lrm/RM-3-4#I1451|3.4(3)]] :parent unit ::of a library unit [[Guide:95lrm/RM-10-1-1#I3707|10.1.1(10)]] :parent_unit_name [[Guide:95lrm/RM-10-1-1#I3700|10.1.1(8)]] ::''used'' [[Guide:95lrm/RM-6-1#I2891|6.1(5)]], [[Guide:95lrm/RM-6-1#I2898|6.1(7)]], [[Guide:95lrm/RM-7-1#I3063|7.1(3)]], [[Guide:95lrm/RM-7-2#I3074|7.2(2)]], [[Guide:95lrm/RM-10-1-3#I3743|10.1.3(7)]], [[Guide:95lrm/RM-P#I7856|P]] :part ::of an object or value [[Guide:95lrm/RM-3-2#I1313|3.2(6)]] :partial view ::of a type [[Guide:95lrm/RM-7-3#I3090|7.3(4)]] :partition [[Guide:95lrm/RM-10-2#I3780|10.2(2)]] :partition building [[Guide:95lrm/RM-10-2#I3781|10.2(2)]] :partition communication subsystem (PCS) [[Guide:95lrm/RM-E-5#I6789|E.5(1)]] :Partition_Check ::[''partial''] [[Guide:95lrm/RM-E-4#I6779|E.4(19)]] :Partition_ID ::''in'' System.RPC [[Guide:95lrm/RM-E-5#I6795|E.5(4)]] :Partition_ID attribute [[Guide:95lrm/RM-E-1#I6702|E.1(9)]] :pass by copy [[Guide:95lrm/RM-6-2#I2934|6.2(2)]] :pass by reference [[Guide:95lrm/RM-6-2#I2937|6.2(2)]] :passive partition [[Guide:95lrm/RM-E-1#I6694|E.1(2)]] :Pattern_Error ::''in'' Ada.Strings [[Guide:95lrm/RM-A-4-1#I4885|A.4.1(5)]] :PCS (partition communication subsystem) [[Guide:95lrm/RM-E-5#I6790|E.5(1)]] :pending interrupt occurrence [[Guide:95lrm/RM-C-3#I6377|C.3(2)]] :per-object constraint [[Guide:95lrm/RM-3-8#I1919|3.8(18/1)]] :per-object expression [[Guide:95lrm/RM-3-8#I1918|3.8(18/1)]] :Percent_Sign ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4687|A.3.3(8)]] :perfect result set [[Guide:95lrm/RM-G-2-3#I7019|G.2.3(5)]] :periodic task ::example [[Guide:95lrm/RM-9-6#I3569|9.6(39)]] ::''See'' delay_until_statement [[Guide:95lrm/RM-9-6#I3570|9.6(39)]] :Pi ::''in'' Ada.Numerics [[Guide:95lrm/RM-A-5#I5264|A.5(3)]] :Pic_String ::''in'' Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6842|F.3.3(7)]] :Picture ::''in'' Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6836|F.3.3(4)]] :picture String ::for edited output [[Guide:95lrm/RM-F-3-1#I6829|F.3.1(1)]] :Picture_Error ::''in'' Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6846|F.3.3(9)]] :Pilcrow_Sign ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4804|A.3.3(22)]] :plain_char ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6118|B.3(11)]] :PLD ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4759|A.3.3(17)]] :PLU ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4760|A.3.3(17)]] :plus operator [[Guide:95lrm/RM-4-4#I2371|4.4(1)]], [[Guide:95lrm/RM-4-5-3#I2535|4.5.3(1)]], [[Guide:95lrm/RM-4-5-4#I2558|4.5.4(1)]] :plus sign [[Guide:95lrm/RM-2-1#I1146|2.1(15)]] :Plus_Minus_Sign ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4799|A.3.3(22)]] :Plus_Sign ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4693|A.3.3(8)]] :PM ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4778|A.3.3(19)]] :point [[Guide:95lrm/RM-2-1#I1152|2.1(15)]] :Pointer ::''in'' Interfaces.C.Pointers [[Guide:95lrm/RM-B-3-2#I6214|B.3.2(5)]] ::''See'' access value [[Guide:95lrm/RM-3-10#I2044|3.10(1)]] ::''See'' type System.Address [[Guide:95lrm/RM-13-7#I4328|13.7(34)]] :pointer type ::''See'' access type [[Guide:95lrm/RM-3-10#I2045|3.10(1)]] :Pointer_Error ::''in'' Interfaces.C.Pointers [[Guide:95lrm/RM-B-3-2#I6219|B.3.2(8)]] :Pointers ::''child of'' Interfaces.C [[Guide:95lrm/RM-B-3-2#I6210|B.3.2(4)]] :polymorphism [[Guide:95lrm/RM-3-9#I1945|3.9(1)]], [[Guide:95lrm/RM-3-9-2#I2006|3.9.2(1)]] :pool element [[Guide:95lrm/RM-3-10#I2063|3.10(7/1)]], [[Guide:95lrm/RM-13-11#I4413|13.11(11)]] :pool type [[Guide:95lrm/RM-13-11#I4411|13.11(11)]] :pool-specific access type [[Guide:95lrm/RM-3-10#I2060|3.10(7/1)]], [[Guide:95lrm/RM-3-10#I2064|3.10(8)]] :Pos attribute [[Guide:95lrm/RM-3-5-5#I1654|3.5.5(2)]] :position [[Guide:95lrm/RM-13-5-1#I4265|13.5.1(4)]] ::''used'' [[Guide:95lrm/RM-13-5-1#I4262|13.5.1(3)]], [[Guide:95lrm/RM-P#I7949|P]] :Position attribute [[Guide:95lrm/RM-13-5-2#I4278|13.5.2(2)]] :position number [[Guide:95lrm/RM-3-5#I1490|3.5(1)]] :of an enumeration value [[Guide:95lrm/RM-3-5-1#I1582|3.5.1(7)]] :of an integer value [[Guide:95lrm/RM-3-5-4#I1633|3.5.4(15)]] :positional association [[Guide:95lrm/RM-6-4#I3012|6.4(7)]], [[Guide:95lrm/RM-12-3#I4015|12.3(6)]] :positional component association [[Guide:95lrm/RM-4-3-1#I2278|4.3.1(6)]] :positional discriminant association [[Guide:95lrm/RM-3-7-1#I1879|3.7.1(4)]] :positional_array_aggregate [[Guide:95lrm/RM-4-3-3#I2302|4.3.3(3)]] ::''used'' [[Guide:95lrm/RM-4-3-3#I2300|4.3.3(2)]], [[Guide:95lrm/RM-P#I7535|P]] :Positive [[Guide:95lrm/RM-3-5-4#I1627|3.5.4(12)]] ::''in'' Standard [[Guide:95lrm/RM-A-1#I4554|A.1(13)]] :Positive_Count ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5552|A.8.4(4)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5925|A.12.1(7)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5628|A.10.1(5)]] :possible interpretation [[Guide:95lrm/RM-8-6#I3285|8.6(14)]] ::for direct_names [[Guide:95lrm/RM-8-3#I3223|8.3(24)]] ::for selector_names [[Guide:95lrm/RM-8-3#I3224|8.3(24)]] :post-compilation error [[Guide:95lrm/RM-1-1-2#I1029|1.1.2(29)]] :post-compilation rules [[Guide:95lrm/RM-1-1-2#I1030|1.1.2(29)]] :potentially blocking operation [[Guide:95lrm/RM-9-5-1#I3430|9.5.1(8)]] ::Abort_Task [[Guide:95lrm/RM-C-7-1#I6485|C.7.1(16)]] ::delay_statement [[Guide:95lrm/RM-9-6#I3567|9.6(34)]], [[Guide:95lrm/RM-D-9#I6653|D.9(5)]] ::remote subprogram call [[Guide:95lrm/RM-E-4#I6774|E.4(17)]] ::RPC operations [[Guide:95lrm/RM-E-5#I6813|E.5(23)]] ::Suspend_Until_True [[Guide:95lrm/RM-D-10#I6670|D.10(10)]] :potentially use-visible [[Guide:95lrm/RM-8-4#I3237|8.4(8)]] :Pound_Sign ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4784|A.3.3(21)]] :Pragma [[Guide:95lrm/RM-2-8#I1236|2.8(1)]], [[Guide:95lrm/RM-2-8#I1237|2.8(2)]], [[Guide:95lrm/RM-L#I7143|L(1)]] :pragma argument [[Guide:95lrm/RM-2-8#I1248|2.8(9)]] :pragma name [[Guide:95lrm/RM-2-8#I1247|2.8(9)]] :pragma, categorization [[Guide:95lrm/RM-E-2#I6706|E.2(2)]] ::Remote_Call_Interface [[Guide:95lrm/RM-E-2-3#I6736|E.2.3(2)]] ::Remote_Types [[Guide:95lrm/RM-E-2-2#I6727|E.2.2(2)]] ::Shared_Passive [[Guide:95lrm/RM-E-2-1#I6715|E.2.1(2)]] :pragma, configuration [[Guide:95lrm/RM-10-1-5#I3763|10.1.5(8)]] ::Locking_Policy [[Guide:95lrm/RM-D-3#I6561|D.3(5)]] ::Normalize_Scalars [[Guide:95lrm/RM-H-1#I7044|H.1(4)]] ::Queuing_Policy [[Guide:95lrm/RM-D-4#I6576|D.4(5)]] ::Restrictions [[Guide:95lrm/RM-13-12#I4469|13.12(8)]] ::Reviewable [[Guide:95lrm/RM-H-3-1#I7049|H.3.1(4)]] ::Suppress [[Guide:95lrm/RM-11-5#I3925|11.5(5)]] ::Task_Dispatching_Policy [[Guide:95lrm/RM-D-2-2#I6549|D.2.2(4)]] :pragma, identifier specific to [[Guide:95lrm/RM-2-8#I1251|2.8(10)]] :pragma, interfacing ::Convention [[Guide:95lrm/RM-B-1#I6032|B.1(4)]] ::Export [[Guide:95lrm/RM-B-1#I6030|B.1(4)]] ::Import [[Guide:95lrm/RM-B-1#I6028|B.1(4)]] ::Linker_Options [[Guide:95lrm/RM-B-1#I6033|B.1(4)]] :pragma, library unit [[Guide:95lrm/RM-10-1-5#I3759|10.1.5(7)]] ::All_Calls_Remote [[Guide:95lrm/RM-E-2-3#I6744|E.2.3(6)]] ::categorization pragmas [[Guide:95lrm/RM-E-2#I6708|E.2(2)]] ::Elaborate_Body [[Guide:95lrm/RM-10-2-1#I3827|10.2.1(24)]] ::Preelaborate [[Guide:95lrm/RM-10-2-1#I3802|10.2.1(4)]] ::Pure [[Guide:95lrm/RM-10-2-1#I3812|10.2.1(15)]] :pragma, program unit [[Guide:95lrm/RM-10-1-5#I3756|10.1.5(2)]] ::Convention [[Guide:95lrm/RM-B-1#I6079|B.1(29)]] ::Export [[Guide:95lrm/RM-B-1#I6077|B.1(29)]] ::Import [[Guide:95lrm/RM-B-1#I6075|B.1(29)]] ::Inline [[Guide:95lrm/RM-6-3-2#I2988|6.3.2(2)]] ::library unit pragmas [[Guide:95lrm/RM-10-1-5#I3761|10.1.5(7)]] :pragma, representation [[Guide:95lrm/RM-13-1#I4117|13.1(1/1)]] ::Asynchronous [[Guide:95lrm/RM-E-4-1#I6786|E.4.1(8)]] ::Atomic [[Guide:95lrm/RM-C-6#I6453|C.6(14)]] ::Atomic_Components [[Guide:95lrm/RM-C-6#I6457|C.6(14)]] ::Controlled [[Guide:95lrm/RM-13-11-3#I4455|13.11.3(5)]] ::Convention [[Guide:95lrm/RM-B-1#I6067|B.1(28)]] ::Discard_Names [[Guide:95lrm/RM-C-5#I6436|C.5(6)]] ::Export [[Guide:95lrm/RM-B-1#I6065|B.1(28)]] ::Import [[Guide:95lrm/RM-B-1#I6063|B.1(28)]] ::Pack [[Guide:95lrm/RM-13-2#I4156|13.2(5)]] ::Volatile [[Guide:95lrm/RM-C-6#I6455|C.6(14)]] ::Volatile_Components [[Guide:95lrm/RM-C-6#I6459|C.6(14)]] :pragma_argument_association [[Guide:95lrm/RM-2-8#I1241|2.8(3)]] ::''used'' [[Guide:95lrm/RM-2-8#I1240|2.8(2)]], [[Guide:95lrm/RM-P#I7327|P]] :pragmas ::All_Calls_Remote [[Guide:95lrm/RM-E-2-3#I6740|E.2.3(5)]], [[Guide:95lrm/RM-L#I7144|L(2)]] ::Asynchronous [[Guide:95lrm/RM-E-4-1#I6782|E.4.1(3)]], [[Guide:95lrm/RM-L#I7147|L(3)]] ::Atomic [[Guide:95lrm/RM-C-6#I6437|C.6(3)]], [[Guide:95lrm/RM-L#I7150|L(4)]] ::Atomic_Components [[Guide:95lrm/RM-C-6#I6443|C.6(5)]], [[Guide:95lrm/RM-L#I7153|L(5)]] ::Attach_Handler [[Guide:95lrm/RM-C-3-1#I6386|C.3.1(4)]], [[Guide:95lrm/RM-L#I7156|L(6)]] ::Controlled [[Guide:95lrm/RM-13-11-3#I4451|13.11.3(3)]], [[Guide:95lrm/RM-L#I7160|L(7)]] ::Convention [[Guide:95lrm/RM-B-1#I6046|B.1(7)]], [[Guide:95lrm/RM-L#I7163|L(8)]] ::Discard_Names [[Guide:95lrm/RM-C-5#I6432|C.5(3)]], [[Guide:95lrm/RM-L#I7167|L(9)]] ::Elaborate [[Guide:95lrm/RM-10-2-1#I3815|10.2.1(20)]], [[Guide:95lrm/RM-L#I7170|L(10)]] ::Elaborate_All [[Guide:95lrm/RM-10-2-1#I3819|10.2.1(21)]], [[Guide:95lrm/RM-L#I7174|L(11)]] ::Elaborate_Body [[Guide:95lrm/RM-10-2-1#I3823|10.2.1(22)]], [[Guide:95lrm/RM-L#I7178|L(12)]] ::Export [[Guide:95lrm/RM-B-1#I6040|B.1(6)]], [[Guide:95lrm/RM-L#I7181|L(13)]] ::Import [[Guide:95lrm/RM-B-1#I6034|B.1(5)]], [[Guide:95lrm/RM-L#I7187|L(14)]] ::Inline [[Guide:95lrm/RM-6-3-2#I2989|6.3.2(3)]], [[Guide:95lrm/RM-L#I7193|L(15)]] ::Inspection_Point [[Guide:95lrm/RM-H-3-2#I7050|H.3.2(3)]], [[Guide:95lrm/RM-L#I7197|L(16)]] ::Interrupt_Handler [[Guide:95lrm/RM-C-3-1#I6383|C.3.1(2)]], [[Guide:95lrm/RM-L#I7201|L(17)]] ::Interrupt_Priority [[Guide:95lrm/RM-D-1#I6514|D.1(5)]], [[Guide:95lrm/RM-L#I7204|L(18)]] ::Linker_Options [[Guide:95lrm/RM-B-1#I6050|B.1(8)]], [[Guide:95lrm/RM-L#I7207|L(19)]] ::List [[Guide:95lrm/RM-2-8#I1254|2.8(21)]], [[Guide:95lrm/RM-L#I7210|L(20)]] ::Locking_Policy [[Guide:95lrm/RM-D-3#I6555|D.3(3)]], [[Guide:95lrm/RM-L#I7213|L(21)]] ::Normalize_Scalars [[Guide:95lrm/RM-H-1#I7041|H.1(3)]], [[Guide:95lrm/RM-L#I7216|L(22)]] ::Optimize [[Guide:95lrm/RM-2-8#I1259|2.8(23)]], [[Guide:95lrm/RM-L#I7218|L(23)]] ::Pack [[Guide:95lrm/RM-13-2#I4152|13.2(3)]], [[Guide:95lrm/RM-L#I7221|L(24)]] ::Page [[Guide:95lrm/RM-2-8#I1257|2.8(22)]], [[Guide:95lrm/RM-L#I7224|L(25)]] ::Preelaborate [[Guide:95lrm/RM-10-2-1#I3798|10.2.1(3)]], [[Guide:95lrm/RM-L#I7226|L(26)]] ::Priority [[Guide:95lrm/RM-D-1#I6511|D.1(3)]], [[Guide:95lrm/RM-L#I7229|L(27)]] ::Pure [[Guide:95lrm/RM-10-2-1#I3808|10.2.1(14)]], [[Guide:95lrm/RM-L#I7232|L(28)]] ::Queuing_Policy [[Guide:95lrm/RM-D-4#I6570|D.4(3)]], [[Guide:95lrm/RM-L#I7235|L(29)]] ::Remote_Call_Interface [[Guide:95lrm/RM-E-2-3#I6737|E.2.3(3)]], [[Guide:95lrm/RM-L#I7238|L(30)]] ::Remote_Types [[Guide:95lrm/RM-E-2-2#I6728|E.2.2(3)]], [[Guide:95lrm/RM-L#I7241|L(31)]] ::Restrictions [[Guide:95lrm/RM-13-12#I4459|13.12(3)]], [[Guide:95lrm/RM-L#I7244|L(32)]] ::Reviewable [[Guide:95lrm/RM-H-3-1#I7046|H.3.1(3)]], [[Guide:95lrm/RM-L#I7248|L(33)]] ::Shared_Passive [[Guide:95lrm/RM-E-2-1#I6716|E.2.1(3)]], [[Guide:95lrm/RM-L#I7250|L(34)]] ::Storage_Size [[Guide:95lrm/RM-13-3#I4222|13.3(63)]], [[Guide:95lrm/RM-L#I7253|L(35)]] ::Suppress [[Guide:95lrm/RM-11-5#I3920|11.5(4)]], [[Guide:95lrm/RM-L#I7256|L(36)]] ::Task_Dispatching_Policy [[Guide:95lrm/RM-D-2-2#I6543|D.2.2(2)]], [[Guide:95lrm/RM-L#I7260|L(37)]] ::Volatile [[Guide:95lrm/RM-C-6#I6440|C.6(4)]], [[Guide:95lrm/RM-L#I7263|L(38)]] ::Volatile_Components [[Guide:95lrm/RM-C-6#I6446|C.6(6)]], [[Guide:95lrm/RM-L#I7266|L(39)]] :precedence of operators [[Guide:95lrm/RM-4-5#I2452|4.5(1)]] :Pred attribute [[Guide:95lrm/RM-3-5#I1538|3.5(25)]] :predefined environment [[Guide:95lrm/RM-A#I4544|A(1)]] :predefined exception [[Guide:95lrm/RM-11-1#I3840|11.1(4)]] :predefined library unit ::''See'' language-defined library units :predefined operation ::of a type [[Guide:95lrm/RM-3-2-3#I1378|3.2.3(1)]] :predefined operations ::of a discrete type [[Guide:95lrm/RM-3-5-5#I1662|3.5.5(10)]] ::of a fixed point type [[Guide:95lrm/RM-3-5-10#I1760|3.5.10(17)]] ::of a floating point type [[Guide:95lrm/RM-3-5-8#I1703|3.5.8(3)]] ::of a record type [[Guide:95lrm/RM-3-8#I1923|3.8(24)]] ::of an access type [[Guide:95lrm/RM-3-10-2#I2124|3.10.2(34)]] ::of an array type [[Guide:95lrm/RM-3-6-2#I1833|3.6.2(15)]] :predefined operator [[Guide:95lrm/RM-4-5#I2460|4.5(9)]] :::[''partial''] [[Guide:95lrm/RM-3-2-1#I1348|3.2.1(9)]] :predefined type [[Guide:95lrm/RM-3-2-1#I1349|3.2.1(10)]] ::''See'' language-defined types :preelaborable ::of an elaborable construct [[Guide:95lrm/RM-10-2-1#I3803|10.2.1(5)]] :Preelaborate pragma [[Guide:95lrm/RM-10-2-1#I3799|10.2.1(3)]], [[Guide:95lrm/RM-L#I7227|L(26)]] :preelaborated [[Guide:95lrm/RM-10-2-1#I3806|10.2.1(11/1)]] ::[''partial''] [[Guide:95lrm/RM-10-2-1#I3805|10.2.1(11/1)]], [[Guide:95lrm/RM-E-2-1#I6722|E.2.1(9)]] :preempted task [[Guide:95lrm/RM-D-2-1#I6539|D.2.1(7)]] :preemptible resource [[Guide:95lrm/RM-D-2-1#I6538|D.2.1(7)]] :preference ::for root numeric operators and ranges [[Guide:95lrm/RM-8-6#I3302|8.6(29)]] :preference control ::''See'' requeue [[Guide:95lrm/RM-9-5-4#I3510|9.5.4(1)]] :prefix [[Guide:95lrm/RM-4-1#I2169|4.1(4)]] ::''used'' [[Guide:95lrm/RM-4-1-1#I2189|4.1.1(2)]], [[Guide:95lrm/RM-4-1-2#I2201|4.1.2(2)]], [[Guide:95lrm/RM-4-1-3#I2211|4.1.3(2)]], [[Guide:95lrm/RM-4-1-4#I2225|4.1.4(2)]], [[Guide:95lrm/RM-4-1-4#I2231|4.1.4(4)]], [[Guide:95lrm/RM-6-4#I2996|6.4(2)]], [[Guide:95lrm/RM-6-4#I3000|6.4(3)]], [[Guide:95lrm/RM-P#I7509|P]] :prescribed result ::for the evaluation of a complex arithmetic operation [[Guide:95lrm/RM-G-1-1#I6918|G.1.1(42)]] ::for the evaluation of a complex elementary function [[Guide:95lrm/RM-G-1-2#I6970|G.1.2(35)]] ::for the evaluation of an elementary function [[Guide:95lrm/RM-A-5-1#I5334|A.5.1(37)]] :primary [[Guide:95lrm/RM-4-4#I2440|4.4(7)]] ::''used'' [[Guide:95lrm/RM-4-4#I2436|4.4(6)]], [[Guide:95lrm/RM-P#I7571|P]] :primitive function [[Guide:95lrm/RM-A-5-3#I5412|A.5.3(17)]] :primitive operation ::[''partial''] [[Guide:95lrm/RM-3-2#I1297|3.2(1)]] :primitive operations ::of a type [[Guide:95lrm/RM-3-2-3#I1379|3.2.3(1)]] :primitive operator ::of a type [[Guide:95lrm/RM-3-2-3#I1382|3.2.3(8)]] :primitive subprograms ::of a type [[Guide:95lrm/RM-3-2-3#I1380|3.2.3(2)]] :priority [[Guide:95lrm/RM-D-1#I6520|D.1(15)]] ::''in'' System [[Guide:95lrm/RM-13-7#I4325|13.7(16)]] :priority inheritance [[Guide:95lrm/RM-D-1#I6521|D.1(15)]] :priority inversion [[Guide:95lrm/RM-D-2-2#I6554|D.2.2(14)]] :priority of an entry call [[Guide:95lrm/RM-D-4#I6578|D.4(9)]] :Priority pragma [[Guide:95lrm/RM-D-1#I6512|D.1(3)]], [[Guide:95lrm/RM-L#I7230|L(27)]] :private declaration of a library unit [[Guide:95lrm/RM-10-1-1#I3713|10.1.1(12)]] :private descendant ::of a library unit [[Guide:95lrm/RM-10-1-1#I3715|10.1.1(12)]] :private extension [[Guide:95lrm/RM-3-2#I1310|3.2(4)]], [[Guide:95lrm/RM-3-9#I1956|3.9(2)]], [[Guide:95lrm/RM-3-9-1#I1994|3.9.1(1)]] ::[''partial''] [[Guide:95lrm/RM-7-3#I3097|7.3(14)]] :private library unit [[Guide:95lrm/RM-10-1-1#I3712|10.1.1(12)]] :private operations [[Guide:95lrm/RM-7-3-1#I3101|7.3.1(1)]] :private part [[Guide:95lrm/RM-8-2#I3185|8.2(5)]] ::of a package [[Guide:95lrm/RM-7-1#I3068|7.1(6)]] ::of a protected unit [[Guide:95lrm/RM-9-4#I3403|9.4(11)]] ::of a task unit [[Guide:95lrm/RM-9-1#I3345|9.1(9)]] :private type [[Guide:95lrm/RM-3-2#I1309|3.2(4)]] ::[''partial''] [[Guide:95lrm/RM-7-3#I3096|7.3(14)]] :private types and private extensions [[Guide:95lrm/RM-7-3#I3078|7.3(1)]] :private_extension_declaration [[Guide:95lrm/RM-7-3#I3086|7.3(3)]] ::''used'' [[Guide:95lrm/RM-3-2-1#I1327|3.2.1(2)]], [[Guide:95lrm/RM-P#I7347|P]] :private_type_declaration [[Guide:95lrm/RM-7-3#I3083|7.3(2)]] ::''used'' [[Guide:95lrm/RM-3-2-1#I1326|3.2.1(2)]], [[Guide:95lrm/RM-P#I7346|P]] :procedure [[Guide:95lrm/RM-6#I2876|6(1)]] :procedure instance [[Guide:95lrm/RM-12-3#I4021|12.3(13)]] :procedure_call_statement [[Guide:95lrm/RM-6-4#I2994|6.4(2)]] ::''used'' [[Guide:95lrm/RM-5-1#I2778|5.1(4)]], [[Guide:95lrm/RM-P#I7602|P]] :processing node [[Guide:95lrm/RM-E#I6688|E(2)]] :profile [[Guide:95lrm/RM-6-1#I2927|6.1(22)]] ::associated with a dereference [[Guide:95lrm/RM-4-1#I2179|4.1(10)]] ::fully conformant [[Guide:95lrm/RM-6-3-1#I2982|6.3.1(18)]] ::mode conformant [[Guide:95lrm/RM-6-3-1#I2976|6.3.1(16)]] ::subtype conformant [[Guide:95lrm/RM-6-3-1#I2979|6.3.1(17)]] ::type conformant [[Guide:95lrm/RM-6-3-1#I2973|6.3.1(15)]] :profile resolution rule ::name with a given expected profile [[Guide:95lrm/RM-8-6#I3299|8.6(26)]] :program [[Guide:95lrm/RM-10-2#I3777|10.2(1)]] :program execution [[Guide:95lrm/RM-10-2#I3778|10.2(1)]] :program library ::''See'' library [[Guide:95lrm/RM-10#I3669|10(2)]] ::''See'' library [[Guide:95lrm/RM-10-1-4#I3754|10.1.4(9)]] :Program unit [[Guide:95lrm/RM-10-1#I3672|10.1(1)]] :program unit pragma [[Guide:95lrm/RM-10-1-5#I3755|10.1.5(2)]] ::Convention [[Guide:95lrm/RM-B-1#I6078|B.1(29)]] ::Export [[Guide:95lrm/RM-B-1#I6076|B.1(29)]] ::Import [[Guide:95lrm/RM-B-1#I6074|B.1(29)]] ::Inline [[Guide:95lrm/RM-6-3-2#I2987|6.3.2(2)]] ::library unit pragmas [[Guide:95lrm/RM-10-1-5#I3760|10.1.5(7)]] :Program_Error ::raised by failure of run-time check [[Guide:95lrm/RM-1-1-3#I1059|1.1.3(20)]], [[Guide:95lrm/RM-1-1-5#I1079|1.1.5(8)]], [[Guide:95lrm/RM-1-1-5#I1085|1.1.5(12)]], [[Guide:95lrm/RM-3-5-5#I1661|3.5.5(8)]], [[Guide:95lrm/RM-3-10-2#I2117|3.10.2(29)]], [[Guide:95lrm/RM-3-11#I2149|3.11(14)]], [[Guide:95lrm/RM-4-6#I2696|4.6(57)]], [[Guide:95lrm/RM-6-2#I2948|6.2(12)]], [[Guide:95lrm/RM-6-4#I3014|6.4(11)]], [[Guide:95lrm/RM-6-5#I3047|6.5(20)]], [[Guide:95lrm/RM-7-6-1#I3168|7.6.1(15)]], [[Guide:95lrm/RM-7-6-1#I3169|7.6.1(16/1)]], [[Guide:95lrm/RM-7-6-1#I3170|7.6.1(17)]], [[Guide:95lrm/RM-7-6-1#I3171|7.6.1(17.1/1)]], [[Guide:95lrm/RM-7-6-1#I3172|7.6.1(17.2/1)]], [[Guide:95lrm/RM-7-6-1#I3173|7.6.1(18)]], [[Guide:95lrm/RM-8-5-4#I3270|8.5.4(8.1/1)]], [[Guide:95lrm/RM-9-4#I3411|9.4(20)]], [[Guide:95lrm/RM-9-5-1#I3432|9.5.1(17)]], [[Guide:95lrm/RM-9-5-3#I3495|9.5.3(7)]], [[Guide:95lrm/RM-9-7-1#I3600|9.7.1(21)]], [[Guide:95lrm/RM-9-8#I3648|9.8(20)]], [[Guide:95lrm/RM-10-2#I3794|10.2(26)]], [[Guide:95lrm/RM-11-1#I3842|11.1(4)]], [[Guide:95lrm/RM-11-5#I3936|11.5(19)]], [[Guide:95lrm/RM-13-7-1#I4348|13.7.1(16)]], [[Guide:95lrm/RM-13-9-1#I4386|13.9.1(9)]], [[Guide:95lrm/RM-13-11-2#I4445|13.11.2(13)]], [[Guide:95lrm/RM-13-11-2#I4447|13.11.2(14)]], [[Guide:95lrm/RM-A-5-2#I5387|A.5.2(40.1/1)]], [[Guide:95lrm/RM-A-7#I5495|A.7(14)]], [[Guide:95lrm/RM-C-3-1#I6394|C.3.1(10)]], [[Guide:95lrm/RM-C-3-1#I6398|C.3.1(11)]], [[Guide:95lrm/RM-C-3-2#I6427|C.3.2(17)]], [[Guide:95lrm/RM-C-3-2#I6428|C.3.2(20)]], [[Guide:95lrm/RM-C-3-2#I6429|C.3.2(21)]], [[Guide:95lrm/RM-C-3-2#I6430|C.3.2(22)]], [[Guide:95lrm/RM-C-7-1#I6484|C.7.1(15)]], [[Guide:95lrm/RM-C-7-1#I6488|C.7.1(17)]], [[Guide:95lrm/RM-C-7-2#I6504|C.7.2(13)]], [[Guide:95lrm/RM-D-3#I6568|D.3(13)]], [[Guide:95lrm/RM-D-5#I6587|D.5(9)]], [[Guide:95lrm/RM-D-5#I6589|D.5(11)]], [[Guide:95lrm/RM-D-10#I6672|D.10(10)]], [[Guide:95lrm/RM-D-11#I6686|D.11(8)]], [[Guide:95lrm/RM-E-1#I6704|E.1(10)]], [[Guide:95lrm/RM-E-3#I6761|E.3(6)]], [[Guide:95lrm/RM-E-4#I6778|E.4(18/1)]], [[Guide:95lrm/RM-J-7-1#I7095|J.7.1(7)]] ::''in'' Standard [[Guide:95lrm/RM-A-1#I4569|A.1(46)]] :propagate [[Guide:95lrm/RM-11-4#I3873|11.4(1)]] ::an exception occurrence by an execution, to a dynamically enclosing execution [[Guide:95lrm/RM-11-4#I3878|11.4(6)]] :proper_body [[Guide:95lrm/RM-3-11#I2140|3.11(6)]] ::''used'' [[Guide:95lrm/RM-3-11#I2138|3.11(5)]], [[Guide:95lrm/RM-10-1-3#I3744|10.1.3(7)]], [[Guide:95lrm/RM-P#I7857|P]] :protected action [[Guide:95lrm/RM-9-5-1#I3424|9.5.1(4)]] ::complete [[Guide:95lrm/RM-9-5-1#I3427|9.5.1(6)]] ::start [[Guide:95lrm/RM-9-5-1#I3425|9.5.1(5)]] :protected calling convention [[Guide:95lrm/RM-6-3-1#I2968|6.3.1(12)]] :protected declaration [[Guide:95lrm/RM-9-4#I3372|9.4(1)]] :protected entry [[Guide:95lrm/RM-9-4#I3369|9.4(1)]] :protected function [[Guide:95lrm/RM-9-5-1#I3422|9.5.1(1)]] :protected object [[Guide:95lrm/RM-9#I3312|9(3)]], [[Guide:95lrm/RM-9-4#I3366|9.4(1)]] :protected operation [[Guide:95lrm/RM-9-4#I3367|9.4(1)]] :protected procedure [[Guide:95lrm/RM-9-5-1#I3421|9.5.1(1)]] :protected subprogram [[Guide:95lrm/RM-9-4#I3368|9.4(1)]], [[Guide:95lrm/RM-9-5-1#I3420|9.5.1(1)]] :protected unit [[Guide:95lrm/RM-9-4#I3371|9.4(1)]] :protected_body [[Guide:95lrm/RM-9-4#I3392|9.4(7)]] ::''used'' [[Guide:95lrm/RM-3-11#I2144|3.11(6)]], [[Guide:95lrm/RM-P#I7488|P]] :protected_body_stub [[Guide:95lrm/RM-10-1-3#I3740|10.1.3(6)]] ::''used'' [[Guide:95lrm/RM-10-1-3#I3733|10.1.3(2)]], [[Guide:95lrm/RM-P#I7851|P]] :protected_definition [[Guide:95lrm/RM-9-4#I3381|9.4(4)]] ::''used'' [[Guide:95lrm/RM-9-4#I3377|9.4(2)]], [[Guide:95lrm/RM-9-4#I3380|9.4(3)]], [[Guide:95lrm/RM-P#I7750|P]] :protected_element_declaration [[Guide:95lrm/RM-9-4#I3389|9.4(6)]] ::''used'' [[Guide:95lrm/RM-9-4#I3383|9.4(4)]], [[Guide:95lrm/RM-P#I7752|P]] :protected_operation_declaration [[Guide:95lrm/RM-9-4#I3385|9.4(5/1)]] ::''used'' [[Guide:95lrm/RM-9-4#I3382|9.4(4)]], [[Guide:95lrm/RM-9-4#I3390|9.4(6)]], [[Guide:95lrm/RM-P#I7757|P]] :protected_operation_item [[Guide:95lrm/RM-9-4#I3396|9.4(8/1)]] ::''used'' [[Guide:95lrm/RM-9-4#I3394|9.4(7)]], [[Guide:95lrm/RM-P#I7760|P]] :protected_type_declaration [[Guide:95lrm/RM-9-4#I3374|9.4(2)]] ::''used'' [[Guide:95lrm/RM-3-2-1#I1333|3.2.1(3)]], [[Guide:95lrm/RM-P#I7352|P]] :ptrdiff_t ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6120|B.3(12)]] :PU1 ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4765|A.3.3(18)]] :PU2 ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4766|A.3.3(18)]] :public declaration of a library unit [[Guide:95lrm/RM-10-1-1#I3711|10.1.1(12)]] :public descendant ::of a library unit [[Guide:95lrm/RM-10-1-1#I3714|10.1.1(12)]] :public library unit [[Guide:95lrm/RM-10-1-1#I3710|10.1.1(12)]] :pure [[Guide:95lrm/RM-10-2-1#I3813|10.2.1(16)]] :Pure pragma [[Guide:95lrm/RM-10-2-1#I3809|10.2.1(14)]], [[Guide:95lrm/RM-L#I7233|L(28)]] :Put ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5759|A.10.1(42)]], [[Guide:95lrm/RM-A-10-1#I5781|A.10.1(48)]], [[Guide:95lrm/RM-A-10-1#I5798|A.10.1(55)]], [[Guide:95lrm/RM-A-10-1#I5819|A.10.1(60)]], [[Guide:95lrm/RM-A-10-1#I5829|A.10.1(66)]], [[Guide:95lrm/RM-A-10-1#I5835|A.10.1(67)]], [[Guide:95lrm/RM-A-10-1#I5847|A.10.1(71)]], [[Guide:95lrm/RM-A-10-1#I5851|A.10.1(72)]], [[Guide:95lrm/RM-A-10-1#I5861|A.10.1(76)]], [[Guide:95lrm/RM-A-10-1#I5867|A.10.1(77)]], [[Guide:95lrm/RM-A-10-1#I5878|A.10.1(82)]], [[Guide:95lrm/RM-A-10-1#I5882|A.10.1(83)]] ::''in'' Ada.Text_IO.Complex_IO [[Guide:95lrm/RM-G-1-3#I6984|G.1.3(7)]], [[Guide:95lrm/RM-G-1-3#I6990|G.1.3(8)]] ::''in'' Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6859|F.3.3(14)]], [[Guide:95lrm/RM-F-3-3#I6861|F.3.3(15)]], [[Guide:95lrm/RM-F-3-3#I6863|F.3.3(16)]] :Put_Line ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5789|A.10.1(50)]] == Q == :qualified_expression [[Guide:95lrm/RM-4-7#I2702|4.7(2)]] ::''used'' [[Guide:95lrm/RM-4-4#I2445|4.4(7)]], [[Guide:95lrm/RM-4-8#I2722|4.8(2)]], [[Guide:95lrm/RM-13-8#I4359|13.8(2)]], [[Guide:95lrm/RM-P#I7955|P]] :Question ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4704|A.3.3(10)]] :queuing policy [[Guide:95lrm/RM-D-4#I6569|D.4(1/1)]], [[Guide:95lrm/RM-D-4#I6577|D.4(6)]] :Queuing_Policy pragma [[Guide:95lrm/RM-D-4#I6571|D.4(3)]], [[Guide:95lrm/RM-L#I7236|L(29)]] :Quotation ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4684|A.3.3(8)]] :quotation mark [[Guide:95lrm/RM-2-1#I1137|2.1(15)]] :quoted string ::''See'' string_literal [[Guide:95lrm/RM-2-6#I1227|2.6(1)]] == R == :raise ::an exception [[Guide:95lrm/RM-11#I3835|11(1)]] ::an exception [[Guide:95lrm/RM-11-3#I3869|11.3(4)]] ::an exception [[Guide:95lrm/RM-N#I7279|N(18)]] ::an exception occurrence [[Guide:95lrm/RM-11-4#I3877|11.4(3)]] :Raise_Exception ::''in'' Ada.Exceptions [[Guide:95lrm/RM-11-4-1#I3896|11.4.1(4)]] :raise_statement [[Guide:95lrm/RM-11-3#I3866|11.3(2)]] ::''used'' [[Guide:95lrm/RM-5-1#I2784|5.1(4)]], [[Guide:95lrm/RM-P#I7608|P]] :Random ::''in'' Ada.Numerics.Discrete_Random [[Guide:95lrm/RM-A-5-2#I5365|A.5.2(20)]] ::''in'' Ada.Numerics.Float_Random [[Guide:95lrm/RM-A-5-2#I5343|A.5.2(8)]] :random number [[Guide:95lrm/RM-A-5-2#I5335|A.5.2(1)]] :range [[Guide:95lrm/RM-3-5#I1494|3.5(3)]], [[Guide:95lrm/RM-3-5#I1498|3.5(4)]] ::of a scalar subtype [[Guide:95lrm/RM-3-5#I1511|3.5(7)]] ::''used'' [[Guide:95lrm/RM-3-5#I1493|3.5(2)]], [[Guide:95lrm/RM-3-6#I1778|3.6(6)]], [[Guide:95lrm/RM-3-6-1#I1808|3.6.1(3)]], [[Guide:95lrm/RM-4-4#I2423|4.4(3)]], [[Guide:95lrm/RM-P#I7425|P]] :Range attribute [[Guide:95lrm/RM-3-5#I1522|3.5(14)]], [[Guide:95lrm/RM-3-6-2#I1826|3.6.2(7)]] :Range(N) attribute [[Guide:95lrm/RM-3-6-2#I1828|3.6.2(8)]] :range_attribute_designator [[Guide:95lrm/RM-4-1-4#I2233|4.1.4(5)]] ::''used'' [[Guide:95lrm/RM-4-1-4#I2232|4.1.4(4)]], [[Guide:95lrm/RM-P#I7519|P]] :range_attribute_reference [[Guide:95lrm/RM-4-1-4#I2230|4.1.4(4)]] ::''used'' [[Guide:95lrm/RM-3-5#I1495|3.5(3)]], [[Guide:95lrm/RM-P#I7387|P]] :Range_Check [[Guide:95lrm/RM-11-5#I3934|11.5(17)]] ::[''partial''] [[Guide:95lrm/RM-3-2-2#I1373|3.2.2(11)]], [[Guide:95lrm/RM-3-5#I1535|3.5(24)]], [[Guide:95lrm/RM-3-5#I1540|3.5(27)]], [[Guide:95lrm/RM-3-5#I1558|3.5(43)]], [[Guide:95lrm/RM-3-5#I1561|3.5(44)]], [[Guide:95lrm/RM-3-5#I1564|3.5(51)]], [[Guide:95lrm/RM-3-5#I1570|3.5(55)]], [[Guide:95lrm/RM-3-5-5#I1659|3.5.5(7)]], [[Guide:95lrm/RM-3-5-9#I1739|3.5.9(19)]], [[Guide:95lrm/RM-4-2#I2251|4.2(11)]], [[Guide:95lrm/RM-4-3-3#I2327|4.3.3(28)]], [[Guide:95lrm/RM-4-5-1#I2485|4.5.1(8)]], [[Guide:95lrm/RM-4-5-6#I2592|4.5.6(6)]], [[Guide:95lrm/RM-4-5-6#I2601|4.5.6(13)]], [[Guide:95lrm/RM-4-6#I2650|4.6(28)]], [[Guide:95lrm/RM-4-6#I2662|4.6(38)]], [[Guide:95lrm/RM-4-6#I2673|4.6(46)]], [[Guide:95lrm/RM-4-6#I2681|4.6(51)]], [[Guide:95lrm/RM-4-7#I2709|4.7(4)]], [[Guide:95lrm/RM-13-13-2#I4505|13.13.2(35)]], [[Guide:95lrm/RM-A-5-2#I5384|A.5.2(39)]], [[Guide:95lrm/RM-A-5-3#I5420|A.5.3(26)]], [[Guide:95lrm/RM-A-5-3#I5425|A.5.3(29)]], [[Guide:95lrm/RM-A-5-3#I5445|A.5.3(50)]], [[Guide:95lrm/RM-A-5-3#I5450|A.5.3(53)]], [[Guide:95lrm/RM-A-5-3#I5455|A.5.3(59)]], [[Guide:95lrm/RM-A-5-3#I5460|A.5.3(62)]], [[Guide:95lrm/RM-K#I7105|K(11)]], [[Guide:95lrm/RM-K#I7118|K(114)]], [[Guide:95lrm/RM-K#I7121|K(122)]], [[Guide:95lrm/RM-K#I7124|K(184)]], [[Guide:95lrm/RM-K#I7133|K(220)]], [[Guide:95lrm/RM-K#I7138|K(241)]], [[Guide:95lrm/RM-K#I7110|K(41)]], [[Guide:95lrm/RM-K#I7113|K(47)]] :range_constraint [[Guide:95lrm/RM-3-5#I1492|3.5(2)]] ::''used'' [[Guide:95lrm/RM-3-2-2#I1364|3.2.2(6)]], [[Guide:95lrm/RM-3-5-9#I1720|3.5.9(5)]], [[Guide:95lrm/RM-J-3#I7079|J.3(2)]], [[Guide:95lrm/RM-P#I7414|P]] :RCI ::generic [[Guide:95lrm/RM-E-2-3#I6748|E.2.3(7/1)]] ::library unit [[Guide:95lrm/RM-E-2-3#I6746|E.2.3(7/1)]] ::package [[Guide:95lrm/RM-E-2-3#I6747|E.2.3(7/1)]] :Re ::''in'' Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6879|G.1.1(6)]] :re-raise statement [[Guide:95lrm/RM-11-3#I3868|11.3(3)]] :read ::the value of an object [[Guide:95lrm/RM-3-3#I1391|3.3(14)]] ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5576|A.8.4(12)]] ::''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5531|A.8.1(12)]] ::''in'' Ada.Storage_IO [[Guide:95lrm/RM-A-9#I5602|A.9(6)]] ::''in'' Ada.Streams [[Guide:95lrm/RM-13-13-1#I4486|13.13.1(5)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5951|A.12.1(15)]], [[Guide:95lrm/RM-A-12-1#I5953|A.12.1(16)]] ::''in'' System.RPC [[Guide:95lrm/RM-E-5#I6800|E.5(7)]] :Read attribute [[Guide:95lrm/RM-13-13-2#I4492|13.13.2(6)]], [[Guide:95lrm/RM-13-13-2#I4496|13.13.2(14)]] :Read clause [[Guide:95lrm/RM-13-3#I4187|13.3(7)]], [[Guide:95lrm/RM-13-13-2#I4513|13.13.2(36/1)]] :ready ::a task state [[Guide:95lrm/RM-9#I3319|9(10)]] :ready queue [[Guide:95lrm/RM-D-2-1#I6531|D.2.1(5)]] :ready task [[Guide:95lrm/RM-D-2-1#I6534|D.2.1(5)]] :Real ::''in'' Interfaces.Fortran [[Guide:95lrm/RM-B-5#I6333|B.5(6)]] :real literal [[Guide:95lrm/RM-2-4#I1184|2.4(1)]] :real literals [[Guide:95lrm/RM-3-5-6#I1669|3.5.6(4)]] :real time [[Guide:95lrm/RM-D-8#I6647|D.8(18)]] :real type [[Guide:95lrm/RM-3-2#I1308|3.2(3)]], [[Guide:95lrm/RM-3-5-6#I1663|3.5.6(1)]] :real-time systems [[Guide:95lrm/RM-C#I6362|C(1)]], [[Guide:95lrm/RM-D#I6509|D(1)]] :real_range_specification [[Guide:95lrm/RM-3-5-7#I1677|3.5.7(3)]] ::''used'' [[Guide:95lrm/RM-3-5-7#I1676|3.5.7(2)]], [[Guide:95lrm/RM-3-5-9#I1713|3.5.9(3)]], [[Guide:95lrm/RM-3-5-9#I1717|3.5.9(4)]], [[Guide:95lrm/RM-P#I7412|P]] :Real_Time ::''child of'' Ada [[Guide:95lrm/RM-D-8#I6614|D.8(3)]] :real_type_definition [[Guide:95lrm/RM-3-5-6#I1664|3.5.6(2)]] ::''used'' [[Guide:95lrm/RM-3-2-1#I1337|3.2.1(4)]], [[Guide:95lrm/RM-P#I7355|P]] :receiving stub [[Guide:95lrm/RM-E-4#I6771|E.4(10)]] :reclamation of storage [[Guide:95lrm/RM-13-11-2#I4437|13.11.2(1)]] :recommended level of support [[Guide:95lrm/RM-13-1#I4150|13.1(20)]] ::Address attribute [[Guide:95lrm/RM-13-3#I4200|13.3(15)]] ::Alignment attribute for objects [[Guide:95lrm/RM-13-3#I4208|13.3(33)]] ::Alignment attribute for subtypes [[Guide:95lrm/RM-13-3#I4207|13.3(29)]] ::bit ordering [[Guide:95lrm/RM-13-5-3#I4297|13.5.3(7)]] ::Component_Size attribute [[Guide:95lrm/RM-13-3#I4234|13.3(71)]] ::enumeration_representation_clause [[Guide:95lrm/RM-13-4#I4248|13.4(9)]] ::pragma Pack [[Guide:95lrm/RM-13-2#I4160|13.2(7)]] ::record_representation_clause [[Guide:95lrm/RM-13-5-1#I4275|13.5.1(17)]] ::required in Systems Programming Annex [[Guide:95lrm/RM-C-2#I6371|C.2(2)]] ::Size attribute [[Guide:95lrm/RM-13-3#I4213|13.3(42)]], [[Guide:95lrm/RM-13-3#I4218|13.3(54)]] ::unchecked conversion [[Guide:95lrm/RM-13-9#I4375|13.9(16)]] ::with respect to nonstatic expressions [[Guide:95lrm/RM-13-1#I4151|13.1(21)]] :record [[Guide:95lrm/RM-3-8#I1891|3.8(1)]] :record extension [[Guide:95lrm/RM-3-4#I1452|3.4(5)]], [[Guide:95lrm/RM-3-9-1#I1992|3.9.1(1)]] :record layout ::aspect of representation [[Guide:95lrm/RM-13-5#I4252|13.5(1)]] :record type [[Guide:95lrm/RM-3-8#I1892|3.8(1)]] :record_aggregate [[Guide:95lrm/RM-4-3-1#I2266|4.3.1(2)]] ::''used'' [[Guide:95lrm/RM-4-3#I2257|4.3(2)]], [[Guide:95lrm/RM-P#I7521|P]] :record_component_association [[Guide:95lrm/RM-4-3-1#I2271|4.3.1(4)]] ::''used'' [[Guide:95lrm/RM-4-3-1#I2270|4.3.1(3)]], [[Guide:95lrm/RM-P#I7525|P]] :record_component_association_list [[Guide:95lrm/RM-4-3-1#I2268|4.3.1(3)]] ::''used'' [[Guide:95lrm/RM-4-3-1#I2267|4.3.1(2)]], [[Guide:95lrm/RM-4-3-2#I2288|4.3.2(2)]], [[Guide:95lrm/RM-P#I7532|P]] :record_definition [[Guide:95lrm/RM-3-8#I1896|3.8(3)]] ::''used'' [[Guide:95lrm/RM-3-8#I1895|3.8(2)]], [[Guide:95lrm/RM-3-9-1#I1997|3.9.1(2)]], [[Guide:95lrm/RM-P#I7467|P]] :record_extension_part [[Guide:95lrm/RM-3-9-1#I1996|3.9.1(2)]] ::''used'' [[Guide:95lrm/RM-3-4#I1449|3.4(2)]], [[Guide:95lrm/RM-P#I7385|P]] :record_representation_clause [[Guide:95lrm/RM-13-5-1#I4256|13.5.1(2)]] ::''used'' [[Guide:95lrm/RM-13-1#I4122|13.1(2/1)]], [[Guide:95lrm/RM-P#I7930|P]] :record_type_definition [[Guide:95lrm/RM-3-8#I1894|3.8(2)]] ::''used'' [[Guide:95lrm/RM-3-2-1#I1339|3.2.1(4)]], [[Guide:95lrm/RM-P#I7357|P]] :Reference ::''in'' Ada.Interrupts [[Guide:95lrm/RM-C-3-2#I6423|C.3.2(10)]] ::''in'' Ada.Task_Attributes [[Guide:95lrm/RM-C-7-2#I6498|C.7.2(5)]] :reference parameter passing [[Guide:95lrm/RM-6-2#I2939|6.2(2)]] :references [[Guide:95lrm/RM-1-2#I1086|1.2(1)]] :Registered_Trade_Mark_Sign ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4795|A.3.3(21)]] :Reinitialize ::''in'' Ada.Task_Attributes [[Guide:95lrm/RM-C-7-2#I6502|C.7.2(6)]] :relation [[Guide:95lrm/RM-4-4#I2418|4.4(3)]] ::''used'' [[Guide:95lrm/RM-4-4#I2417|4.4(2)]], [[Guide:95lrm/RM-P#I7553|P]] :relational operator [[Guide:95lrm/RM-4-5-2#I2488|4.5.2(1)]] :relational_operator [[Guide:95lrm/RM-4-5#I2455|4.5(3)]] ::''used'' [[Guide:95lrm/RM-4-4#I2420|4.4(3)]], [[Guide:95lrm/RM-P#I7558|P]] :relaxed mode [[Guide:95lrm/RM-G-2#I6997|G.2(1)]] :release ::execution resource associated with protected object [[Guide:95lrm/RM-9-5-1#I3428|9.5.1(6)]] :rem operator [[Guide:95lrm/RM-4-4#I2396|4.4(1)]], [[Guide:95lrm/RM-4-5-5#I2578|4.5.5(1)]] :Remainder attribute [[Guide:95lrm/RM-A-5-3#I5438|A.5.3(45)]] :remote access [[Guide:95lrm/RM-E-1#I6695|E.1(5)]] :remote access type [[Guide:95lrm/RM-E-2-2#I6732|E.2.2(9/1)]] :remote access-to-class-wide type [[Guide:95lrm/RM-E-2-2#I6734|E.2.2(9/1)]] :remote access-to-subprogram type [[Guide:95lrm/RM-E-2-2#I6733|E.2.2(9/1)]] :remote call interface [[Guide:95lrm/RM-E-2#I6712|E.2(4/1)]], [[Guide:95lrm/RM-E-2-3#I6745|E.2.3(7/1)]] :remote procedure call ::asynchronous [[Guide:95lrm/RM-E-4-1#I6787|E.4.1(9)]] :remote subprogram [[Guide:95lrm/RM-E-2-3#I6749|E.2.3(7/1)]] :remote subprogram binding [[Guide:95lrm/RM-E-4#I6766|E.4(1)]] :remote subprogram call [[Guide:95lrm/RM-E-4#I6762|E.4(1)]] :remote types library unit [[Guide:95lrm/RM-E-2#I6711|E.2(4/1)]], [[Guide:95lrm/RM-E-2-2#I6731|E.2.2(4)]] :Remote_Call_Interface pragma [[Guide:95lrm/RM-E-2-3#I6738|E.2.3(3)]], [[Guide:95lrm/RM-L#I7239|L(30)]] :Remote_Types pragma [[Guide:95lrm/RM-E-2-2#I6729|E.2.2(3)]], [[Guide:95lrm/RM-L#I7242|L(31)]] :renamed entity [[Guide:95lrm/RM-8-5#I3249|8.5(3)]] :renamed view [[Guide:95lrm/RM-8-5#I3248|8.5(3)]] :renaming-as-body [[Guide:95lrm/RM-8-5-4#I3260|8.5.4(1)]] :renaming-as-declaration [[Guide:95lrm/RM-8-5-4#I3261|8.5.4(1)]] :renaming_declaration [[Guide:95lrm/RM-8-5#I3241|8.5(2)]] ::''used'' [[Guide:95lrm/RM-3-1#I1273|3.1(3)]], [[Guide:95lrm/RM-P#I7339|P]] :rendezvous [[Guide:95lrm/RM-9-5-2#I3479|9.5.2(25)]] :Replace_Element ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5038|A.4.4(27)]] ::''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5130|A.4.5(21)]] :Replace_Slice ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5066|A.4.4(58)]], [[Guide:95lrm/RM-A-4-4#I5068|A.4.4(59)]] ::''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4971|A.4.3(23)]], [[Guide:95lrm/RM-A-4-3#I4973|A.4.3(24)]] ::''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5158|A.4.5(53)]], [[Guide:95lrm/RM-A-4-5#I5160|A.4.5(54)]] :Replicate ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5098|A.4.4(78)]], [[Guide:95lrm/RM-A-4-4#I5100|A.4.4(79)]], [[Guide:95lrm/RM-A-4-4#I5102|A.4.4(80)]] :representation ::change of [[Guide:95lrm/RM-13-6#I4299|13.6(1)]] :representation aspect [[Guide:95lrm/RM-13-1#I4135|13.1(8)]] :representation attribute [[Guide:95lrm/RM-13-3#I4161|13.3(1/1)]] :representation item [[Guide:95lrm/RM-13-1#I4115|13.1(1/1)]] :representation of an object [[Guide:95lrm/RM-13-1#I4130|13.1(7)]] :representation pragma [[Guide:95lrm/RM-13-1#I4116|13.1(1/1)]] ::Asynchronous [[Guide:95lrm/RM-E-4-1#I6785|E.4.1(8)]] ::Atomic [[Guide:95lrm/RM-C-6#I6452|C.6(14)]] ::Atomic_Components [[Guide:95lrm/RM-C-6#I6456|C.6(14)]] ::Controlled [[Guide:95lrm/RM-13-11-3#I4454|13.11.3(5)]] ::Convention [[Guide:95lrm/RM-B-1#I6066|B.1(28)]] ::Discard_Names [[Guide:95lrm/RM-C-5#I6435|C.5(6)]] ::Export [[Guide:95lrm/RM-B-1#I6064|B.1(28)]] ::Import [[Guide:95lrm/RM-B-1#I6062|B.1(28)]] ::Pack [[Guide:95lrm/RM-13-2#I4155|13.2(5)]] ::Volatile [[Guide:95lrm/RM-C-6#I6454|C.6(14)]] ::Volatile_Components [[Guide:95lrm/RM-C-6#I6458|C.6(14)]] :representation-oriented attributes ::of a fixed point subtype [[Guide:95lrm/RM-A-5-4#I5477|A.5.4(1)]] ::of a floating point subtype [[Guide:95lrm/RM-A-5-3#I5389|A.5.3(1)]] :representation_clause ::''See'' aspect_clause [[Guide:95lrm/RM-13-1#I4129|13.1(4/1)]] :represented in canonical form [[Guide:95lrm/RM-A-5-3#I5403|A.5.3(10)]] :requested decimal precision ::of a floating point type [[Guide:95lrm/RM-3-5-7#I1680|3.5.7(4)]] :requeue [[Guide:95lrm/RM-9-5-4#I3509|9.5.4(1)]] :requeue-with-abort [[Guide:95lrm/RM-9-5-4#I3521|9.5.4(13)]] :requeue_statement [[Guide:95lrm/RM-9-5-4#I3512|9.5.4(2)]] ::''used'' [[Guide:95lrm/RM-5-1#I2781|5.1(4)]], [[Guide:95lrm/RM-P#I7605|P]] :requires a completion [[Guide:95lrm/RM-3-11-1#I2150|3.11.1(1/1)]], [[Guide:95lrm/RM-3-11-1#I2154|3.11.1(6)]] ::declaration of a partial view [[Guide:95lrm/RM-7-3#I3091|7.3(4)]] ::declaration to which a pragma Elaborate_Body applies [[Guide:95lrm/RM-10-2-1#I3828|10.2.1(25)]] ::deferred constant declaration [[Guide:95lrm/RM-7-4#I3109|7.4(2)]] ::generic_package_declaration [[Guide:95lrm/RM-7-1#I3066|7.1(5)]] ::generic_subprogram_declaration [[Guide:95lrm/RM-6-1#I2926|6.1(20)]] ::incomplete_type_declaration [[Guide:95lrm/RM-3-10-1#I2090|3.10.1(3)]] ::package_declaration [[Guide:95lrm/RM-7-1#I3065|7.1(5)]] ::protected entry_declaration [[Guide:95lrm/RM-9-5-2#I3463|9.5.2(16)]] ::protected_declaration} [[Guide:95lrm/RM-9-4#I3401|9.4(10)]] ::subprogram_declaration [[Guide:95lrm/RM-6-1#I2925|6.1(20)]] ::task_declaration} [[Guide:95lrm/RM-9-1#I3343|9.1(8)]] :Reraise_Occurrence ::''in'' Ada.Exceptions [[Guide:95lrm/RM-11-4-1#I3900|11.4.1(4)]] :reserved interrupt [[Guide:95lrm/RM-C-3#I6380|C.3(2)]] :reserved word [[Guide:95lrm/RM-2-9#I1262|2.9(2)]] :Reserved_128 ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4748|A.3.3(17)]] :Reserved_129 ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4749|A.3.3(17)]] :Reserved_132 ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4752|A.3.3(17)]] :Reserved_153 ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4773|A.3.3(19)]] :Reserved_Check ::[''partial''] [[Guide:95lrm/RM-C-3-1#I6392|C.3.1(10)]] :Reset ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5562|A.8.4(8)]] ::''in'' Ada.Numerics.Discrete_Random [[Guide:95lrm/RM-A-5-2#I5367|A.5.2(21)]], [[Guide:95lrm/RM-A-5-2#I5375|A.5.2(24)]] ::''in'' Ada.Numerics.Float_Random [[Guide:95lrm/RM-A-5-2#I5345|A.5.2(9)]], [[Guide:95lrm/RM-A-5-2#I5353|A.5.2(12)]] ::''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5521|A.8.1(8)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5937|A.12.1(10)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5643|A.10.1(11)]] :resolution rules [[Guide:95lrm/RM-1-1-2#I1021|1.1.2(26)]] :resolve ::overload resolution [[Guide:95lrm/RM-8-6#I3287|8.6(14)]] :restriction [[Guide:95lrm/RM-13-12#I4463|13.12(4)]] ::''used'' [[Guide:95lrm/RM-13-12#I4462|13.12(3)]], [[Guide:95lrm/RM-L#I7246|L(32)]] :Restrictions ::Immediate_Reclamation [[Guide:95lrm/RM-H-4#I7060|H.4(10)]] ::Max_Asynchronous_Select_Nesting [[Guide:95lrm/RM-D-7#I6606|D.7(18/1)]] ::Max_Protected_Entries [[Guide:95lrm/RM-D-7#I6601|D.7(14)]] ::Max_Select_Alternatives [[Guide:95lrm/RM-D-7#I6599|D.7(12)]] ::Max_Storage_At_Blocking [[Guide:95lrm/RM-D-7#I6602|D.7(17/1)]] ::Max_Task_Entries [[Guide:95lrm/RM-D-7#I6600|D.7(13)]] ::Max_Tasks [[Guide:95lrm/RM-D-7#I6610|D.7(19/1)]] ::No_Abort_Statements [[Guide:95lrm/RM-D-7#I6593|D.7(5)]] ::No_Access_Subprograms [[Guide:95lrm/RM-H-4#I7065|H.4(17)]] ::No_Allocators [[Guide:95lrm/RM-H-4#I7057|H.4(7)]] ::No_Asynchronous_Control [[Guide:95lrm/RM-D-7#I6598|D.7(10)]] ::No_Delay [[Guide:95lrm/RM-H-4#I7071|H.4(21)]] ::No_Dispatch [[Guide:95lrm/RM-H-4#I7069|H.4(19)]] ::No_Dynamic_Priorities [[Guide:95lrm/RM-D-7#I6597|D.7(9)]] ::No_Exceptions [[Guide:95lrm/RM-H-4#I7061|H.4(12)]] ::No_Fixed_Point [[Guide:95lrm/RM-H-4#I7063|H.4(15)]] ::No_Floating_Point [[Guide:95lrm/RM-H-4#I7062|H.4(14)]] ::No_Implicit_Heap_Allocations [[Guide:95lrm/RM-D-7#I6596|D.7(8)]] ::No_IO [[Guide:95lrm/RM-H-4#I7070|H.4(20)]] ::No_Local_Allocators [[Guide:95lrm/RM-H-4#I7058|H.4(8/1)]] ::No_Nested_Finalization [[Guide:95lrm/RM-D-7#I6592|D.7(4/1)]] ::No_Protected_Types [[Guide:95lrm/RM-H-4#I7056|H.4(5)]] ::No_Recursion [[Guide:95lrm/RM-H-4#I7072|H.4(22)]] ::No_Reentrancy [[Guide:95lrm/RM-H-4#I7073|H.4(23)]] ::No_Task_Allocators [[Guide:95lrm/RM-D-7#I6595|D.7(7)]] ::No_Task_Hierarchy [[Guide:95lrm/RM-D-7#I6591|D.7(3)]] ::No_Terminate_Alternatives [[Guide:95lrm/RM-D-7#I6594|D.7(6)]] ::No_Unchecked_Access [[Guide:95lrm/RM-H-4#I7066|H.4(18)]] ::No_Unchecked_Conversion [[Guide:95lrm/RM-H-4#I7064|H.4(16)]] ::No_Unchecked_Deallocation [[Guide:95lrm/RM-H-4#I7059|H.4(9)]] :Restrictions pragma [[Guide:95lrm/RM-13-12#I4460|13.12(3)]], [[Guide:95lrm/RM-L#I7245|L(32)]] :result interval ::for a component of the result of evaluating a complex function [[Guide:95lrm/RM-G-2-6#I7030|G.2.6(3)]] ::for the evaluation of a predefined arithmetic operation [[Guide:95lrm/RM-G-2-1#I7002|G.2.1(8)]] ::for the evaluation of an elementary function [[Guide:95lrm/RM-G-2-4#I7024|G.2.4(2)]] :result subtype ::of a function [[Guide:95lrm/RM-6-5#I3036|6.5(3)]] :return expression [[Guide:95lrm/RM-6-5#I3035|6.5(3)]] :return-by-reference type [[Guide:95lrm/RM-6-5#I3044|6.5(11)]] :return_statement [[Guide:95lrm/RM-6-5#I3033|6.5(2)]] ::''used'' [[Guide:95lrm/RM-5-1#I2779|5.1(4)]], [[Guide:95lrm/RM-P#I7603|P]] :Reverse_Solidus ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4707|A.3.3(12)]] :Reviewable pragma [[Guide:95lrm/RM-H-3-1#I7047|H.3.1(3)]], [[Guide:95lrm/RM-L#I7249|L(33)]] :RI ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4761|A.3.3(17)]] :right curly bracket [[Guide:95lrm/RM-2-1#I1166|2.1(15)]] :right parenthesis [[Guide:95lrm/RM-2-1#I1143|2.1(15)]] :right square bracket [[Guide:95lrm/RM-2-1#I1164|2.1(15)]] :Right_Angle_Quotation ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4810|A.3.3(22)]] :Right_Curly_Bracket ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4740|A.3.3(14)]] :Right_Parenthesis ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4691|A.3.3(8)]] :Right_Square_Bracket ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4708|A.3.3(12)]] :Ring_Above ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4798|A.3.3(22)]] :root library unit [[Guide:95lrm/RM-10-1-1#I3706|10.1.1(10)]] :root type ::of a class [[Guide:95lrm/RM-3-4-1#I1474|3.4.1(2)]] :root_integer [[Guide:95lrm/RM-3-5-4#I1628|3.5.4(14)]] ::[''partial''] [[Guide:95lrm/RM-3-4-1#I1480|3.4.1(8)]] :root_real [[Guide:95lrm/RM-3-5-6#I1667|3.5.6(3)]] ::[''partial''] [[Guide:95lrm/RM-3-4-1#I1481|3.4.1(8)]] :Root_Storage_Pool ::''in'' System.Storage_Pools [[Guide:95lrm/RM-13-11#I4403|13.11(6)]] :Root_Stream_Type ::''in'' Ada.Streams [[Guide:95lrm/RM-13-13-1#I4477|13.13.1(3)]] :rooted at a type [[Guide:95lrm/RM-3-4-1#I1475|3.4.1(2)]] :rotate [[Guide:95lrm/RM-B-2#I6091|B.2(9)]] :Round attribute [[Guide:95lrm/RM-3-5-10#I1759|3.5.10(12)]] :Rounding attribute [[Guide:95lrm/RM-A-5-3#I5432|A.5.3(36)]] :RPC ::''child of'' System [[Guide:95lrm/RM-E-5#I6791|E.5(3)]] :RPC-receiver [[Guide:95lrm/RM-E-5#I6812|E.5(21)]] :RPC_Receiver ::''in'' System.RPC [[Guide:95lrm/RM-E-5#I6808|E.5(11)]] :RS ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4680|A.3.3(6)]] :run-time check ::''See'' language-defined check [[Guide:95lrm/RM-11-5#I3916|11.5(2)]] :run-time error [[Guide:95lrm/RM-1-1-2#I1037|1.1.2(30)]], [[Guide:95lrm/RM-1-1-5#I1076|1.1.5(6)]], [[Guide:95lrm/RM-11-5#I3917|11.5(2)]], [[Guide:95lrm/RM-11-6#I3948|11.6(1)]] :run-time polymorphism [[Guide:95lrm/RM-3-9-2#I2007|3.9.2(1)]] :run-time semantics [[Guide:95lrm/RM-1-1-2#I1036|1.1.2(30)]] :run-time type ::''See'' tag [[Guide:95lrm/RM-3-9#I1961|3.9(3)]] :running a program ::''See'' program execution [[Guide:95lrm/RM-10-2#I3779|10.2(1)]] :running task [[Guide:95lrm/RM-D-2-1#I6537|D.2.1(6)]] == S == :safe range ::of a floating point type [[Guide:95lrm/RM-3-5-7#I1688|3.5.7(9)]] ::of a floating point type [[Guide:95lrm/RM-3-5-7#I1690|3.5.7(10)]] :Safe_First attribute [[Guide:95lrm/RM-A-5-3#I5474|A.5.3(71)]], [[Guide:95lrm/RM-G-2-2#I7011|G.2.2(5)]] :Safe_Last attribute [[Guide:95lrm/RM-A-5-3#I5476|A.5.3(72)]], [[Guide:95lrm/RM-G-2-2#I7013|G.2.2(6)]] :safety-critical systems [[Guide:95lrm/RM-H#I7036|H(1)]] :satisfies ::a discriminant constraint [[Guide:95lrm/RM-3-7-1#I1885|3.7.1(11)]] ::a range constraint [[Guide:95lrm/RM-3-5#I1504|3.5(4)]] ::an index constraint [[Guide:95lrm/RM-3-6-1#I1814|3.6.1(7)]] ::for an access value [[Guide:95lrm/RM-3-10#I2084|3.10(15)]] :Save ::''in'' Ada.Numerics.Discrete_Random [[Guide:95lrm/RM-A-5-2#I5373|A.5.2(24)]] ::''in'' Ada.Numerics.Float_Random [[Guide:95lrm/RM-A-5-2#I5351|A.5.2(12)]] :Save_Occurrence ::''in'' Ada.Exceptions [[Guide:95lrm/RM-11-4-1#I3908|11.4.1(6)]] :scalar type [[Guide:95lrm/RM-3-2#I1305|3.2(3)]], [[Guide:95lrm/RM-3-5#I1488|3.5(1)]] :scalar_constraint [[Guide:95lrm/RM-3-2-2#I1363|3.2.2(6)]] ::''used'' [[Guide:95lrm/RM-3-2-2#I1361|3.2.2(5)]], [[Guide:95lrm/RM-P#I7365|P]] :scale ::of a decimal fixed point subtype [[Guide:95lrm/RM-3-5-10#I1757|3.5.10(11)]], [[Guide:95lrm/RM-K#I7131|K(216)]] :Scale attribute [[Guide:95lrm/RM-3-5-10#I1756|3.5.10(11)]] :Scaling attribute [[Guide:95lrm/RM-A-5-3#I5423|A.5.3(27)]] :SCHAR_MAX ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6099|B.3(6)]] :SCHAR_MIN ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6098|B.3(6)]] :SCI ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4774|A.3.3(19)]] :scope ::informal definition [[Guide:95lrm/RM-3-1#I1285|3.1(8)]] ::of (a view of) an entity [[Guide:95lrm/RM-8-2#I3191|8.2(11)]] ::of a declaration [[Guide:95lrm/RM-8-2#I3189|8.2(10)]] ::of a use_clause [[Guide:95lrm/RM-8-4#I3236|8.4(6)]] ::of a with_clause [[Guide:95lrm/RM-10-1-2#I3726|10.1.2(5)]] :Seconds ::''in'' Ada.Calendar [[Guide:95lrm/RM-9-6#I3555|9.6(13)]] :Seconds_Count ::''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6642|D.8(15)]] :Section_Sign ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4788|A.3.3(21)]] :secure systems [[Guide:95lrm/RM-H#I7037|H(1)]] :select an entry call ::from an entry queue [[Guide:95lrm/RM-9-5-3#I3501|9.5.3(13)]], [[Guide:95lrm/RM-9-5-3#I3502|9.5.3(16)]] ::immediately [[Guide:95lrm/RM-9-5-3#I3498|9.5.3(8)]] :select_alternative [[Guide:95lrm/RM-9-7-1#I3585|9.7.1(4)]] ::''used'' [[Guide:95lrm/RM-9-7-1#I3581|9.7.1(2)]], [[Guide:95lrm/RM-P#I7800|P]] :select_statement [[Guide:95lrm/RM-9-7#I3571|9.7(2)]] ::''used'' [[Guide:95lrm/RM-5-1#I2792|5.1(5)]], [[Guide:95lrm/RM-P#I7615|P]] :selected_component [[Guide:95lrm/RM-4-1-3#I2210|4.1.3(2)]] ::''used'' [[Guide:95lrm/RM-4-1#I2161|4.1(2)]], [[Guide:95lrm/RM-P#I7493|P]] :selection ::of an entry caller [[Guide:95lrm/RM-9-5-2#I3478|9.5.2(24)]] :selective_accept [[Guide:95lrm/RM-9-7-1#I3577|9.7.1(2)]] ::''used'' [[Guide:95lrm/RM-9-7#I3572|9.7(2)]], [[Guide:95lrm/RM-P#I7793|P]] :selector_name [[Guide:95lrm/RM-4-1-3#I2213|4.1.3(3)]] ::''used'' [[Guide:95lrm/RM-3-7-1#I1875|3.7.1(3)]], [[Guide:95lrm/RM-4-1-3#I2212|4.1.3(2)]], [[Guide:95lrm/RM-4-3-1#I2275|4.3.1(5)]], [[Guide:95lrm/RM-6-4#I3006|6.4(5)]], [[Guide:95lrm/RM-12-3#I4005|12.3(4)]], [[Guide:95lrm/RM-P#I7685|P]] :semantic dependence ::of one compilation unit upon another [[Guide:95lrm/RM-10-1-1#I3716|10.1.1(26)]] :semicolon [[Guide:95lrm/RM-2-1#I1156|2.1(15)]] ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4700|A.3.3(10)]] :separate compilation [[Guide:95lrm/RM-10-1#I3670|10.1(1)]] :separator [[Guide:95lrm/RM-2-2#I1172|2.2(3)]] :sequence of characters ::of a string_literal [[Guide:95lrm/RM-2-6#I1232|2.6(5)]] :sequence_of_statements [[Guide:95lrm/RM-5-1#I2765|5.1(2)]] ::''used'' [[Guide:95lrm/RM-5-3#I2823|5.3(2)]], [[Guide:95lrm/RM-5-4#I2835|5.4(3)]], [[Guide:95lrm/RM-5-5#I2845|5.5(2)]], [[Guide:95lrm/RM-9-7-1#I3582|9.7.1(2)]], [[Guide:95lrm/RM-9-7-1#I3591|9.7.1(5)]], [[Guide:95lrm/RM-9-7-1#I3594|9.7.1(6)]], [[Guide:95lrm/RM-9-7-2#I3607|9.7.2(3)]], [[Guide:95lrm/RM-9-7-3#I3611|9.7.3(2)]], [[Guide:95lrm/RM-9-7-4#I3618|9.7.4(3)]], [[Guide:95lrm/RM-9-7-4#I3623|9.7.4(5)]], [[Guide:95lrm/RM-11-2#I3851|11.2(2)]], [[Guide:95lrm/RM-11-2#I3858|11.2(3)]], [[Guide:95lrm/RM-P#I7815|P]] :sequential ::actions [[Guide:95lrm/RM-9-10#I3665|9.10(11)]], [[Guide:95lrm/RM-C-6#I6460|C.6(17)]] :sequential access [[Guide:95lrm/RM-A-8#I5498|A.8(2)]] :sequential file [[Guide:95lrm/RM-A-8#I5496|A.8(1)]] :Sequential_IO ::''child of'' Ada [[Guide:95lrm/RM-A-8-1#I5503|A.8.1(2)]] :service ::an entry queue [[Guide:95lrm/RM-9-5-3#I3500|9.5.3(13)]] :Set_Col ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5737|A.10.1(35)]] :Set_Error ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5659|A.10.1(15)]] :Set_Exit_Status ::''in'' Ada.Command_Line [[Guide:95lrm/RM-A-15#I6019|A.15(9)]] :Set_False ::''in'' Ada.Synchronous_Task_Control [[Guide:95lrm/RM-D-10#I6665|D.10(4)]] :Set_Im ::''in'' Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6889|G.1.1(7)]] :Set_Index ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5582|A.8.4(14)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5959|A.12.1(22)]] :Set_Input ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5655|A.10.1(15)]] :Set_Line ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5741|A.10.1(36)]] :Set_Line_Length ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5691|A.10.1(23)]] :Set_Mode ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5965|A.12.1(24)]] :Set_Output ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5657|A.10.1(15)]] :Set_Page_Length ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5697|A.10.1(24)]] :Set_Priority ::''in'' Ada.Dynamic_Priorities [[Guide:95lrm/RM-D-5#I6583|D.5(4)]] :Set_Re ::''in'' Ada.Numerics.Generic_Complex_Types [[Guide:95lrm/RM-G-1-1#I6885|G.1.1(7)]] :Set_True ::''in'' Ada.Synchronous_Task_Control [[Guide:95lrm/RM-D-10#I6663|D.10(4)]] :Set_Value ::''in'' Ada.Task_Attributes [[Guide:95lrm/RM-C-7-2#I6500|C.7.2(6)]] :shared passive library unit [[Guide:95lrm/RM-E-2#I6710|E.2(4/1)]], [[Guide:95lrm/RM-E-2-1#I6719|E.2.1(4)]] :shared variable ::protection of [[Guide:95lrm/RM-9-10#I3661|9.10(1)]] :Shared_Passive pragma [[Guide:95lrm/RM-E-2-1#I6717|E.2.1(3)]], [[Guide:95lrm/RM-L#I7251|L(34)]] :shift [[Guide:95lrm/RM-B-2#I6090|B.2(9)]] :short ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6104|B.3(7)]] :short-circuit control form [[Guide:95lrm/RM-4-5-1#I2469|4.5.1(1)]] :Short_Float [[Guide:95lrm/RM-3-5-7#I1698|3.5.7(16)]] :Short_Integer [[Guide:95lrm/RM-3-5-4#I1646|3.5.4(25)]] :SI ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4665|A.3.3(5)]] :signal ::as defined between actions [[Guide:95lrm/RM-9-10#I3663|9.10(2)]] ::''See'' interrupt [[Guide:95lrm/RM-C-3#I6372|C.3(1)]] :signal (an exception) ::''See'' raise [[Guide:95lrm/RM-11#I3831|11(1)]] :signal handling ::example [[Guide:95lrm/RM-9-7-4#I3626|9.7.4(10)]] :signed integer type [[Guide:95lrm/RM-3-5-4#I1603|3.5.4(1)]] :signed_char ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6108|B.3(8)]] :signed_integer_type_definition [[Guide:95lrm/RM-3-5-4#I1609|3.5.4(3)]] ::''used'' [[Guide:95lrm/RM-3-5-4#I1607|3.5.4(2)]], [[Guide:95lrm/RM-P#I7395|P]] :Signed_Zeros attribute [[Guide:95lrm/RM-A-5-3#I5410|A.5.3(13)]] :simple entry call [[Guide:95lrm/RM-9-5-3#I3482|9.5.3(1)]] :simple_expression [[Guide:95lrm/RM-4-4#I2426|4.4(4)]] ::''used'' [[Guide:95lrm/RM-3-5#I1497|3.5(3)]], [[Guide:95lrm/RM-3-5-4#I1611|3.5.4(3)]], [[Guide:95lrm/RM-3-5-7#I1679|3.5.7(3)]], [[Guide:95lrm/RM-4-4#I2424|4.4(3)]], [[Guide:95lrm/RM-13-5-1#I4268|13.5.1(5)]], [[Guide:95lrm/RM-13-5-1#I4270|13.5.1(6)]], [[Guide:95lrm/RM-P#I7405|P]] :simple_statement [[Guide:95lrm/RM-5-1#I2773|5.1(4)]] ::''used'' [[Guide:95lrm/RM-5-1#I2770|5.1(3)]], [[Guide:95lrm/RM-P#I7595|P]] :Sin ::''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6931|G.1.2(4)]] ::''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5280|A.5.1(5)]] :single ::class expected type [[Guide:95lrm/RM-8-6#I3301|8.6(27)]] :single entry [[Guide:95lrm/RM-9-5-2#I3471|9.5.2(20)]] :Single_Precision_Complex_Types ::''in'' Interfaces.Fortran [[Guide:95lrm/RM-B-5#I6338|B.5(8)]] :single_protected_declaration [[Guide:95lrm/RM-9-4#I3378|9.4(3)]] ::''used'' [[Guide:95lrm/RM-3-3-1#I1413|3.3.1(2)]], [[Guide:95lrm/RM-P#I7379|P]] :single_task_declaration [[Guide:95lrm/RM-9-1#I3328|9.1(3)]] ::''used'' [[Guide:95lrm/RM-3-3-1#I1412|3.3.1(2)]], [[Guide:95lrm/RM-P#I7378|P]] :Sinh ::''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6947|G.1.2(6)]] ::''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5310|A.5.1(7)]] :size ::of an object [[Guide:95lrm/RM-13-1#I4131|13.1(7)]] ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5586|A.8.4(15)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5963|A.12.1(23)]] :Size attribute [[Guide:95lrm/RM-13-3#I4210|13.3(40)]], [[Guide:95lrm/RM-13-3#I4215|13.3(45)]] :Size clause [[Guide:95lrm/RM-13-3#I4180|13.3(7)]], [[Guide:95lrm/RM-13-3#I4212|13.3(41)]], [[Guide:95lrm/RM-13-3#I4217|13.3(48)]] :size_t ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6122|B.3(13)]] :Skip_Line ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5713|A.10.1(29)]] :Skip_Page ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5723|A.10.1(32)]] :slice [[Guide:95lrm/RM-4-1-2#I2200|4.1.2(2)]] ::''used'' [[Guide:95lrm/RM-4-1#I2160|4.1(2)]], [[Guide:95lrm/RM-P#I7492|P]] ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5040|A.4.4(28)]] ::''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5132|A.4.5(22)]] :small ::of a fixed point type [[Guide:95lrm/RM-3-5-9#I1725|3.5.9(8)]] :Small attribute [[Guide:95lrm/RM-3-5-10#I1743|3.5.10(2/1)]] :Small clause [[Guide:95lrm/RM-3-5-10#I1745|3.5.10(2/1)]], [[Guide:95lrm/RM-13-3#I4183|13.3(7)]] :SO ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4664|A.3.3(5)]] :Soft_Hyphen ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4794|A.3.3(21)]] :SOH ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4651|A.3.3(5)]] :solidus [[Guide:95lrm/RM-2-1#I1153|2.1(15)]] ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4698|A.3.3(8)]] :SOS ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4772|A.3.3(19)]] :SPA ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4770|A.3.3(18)]] :Space ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4682|A.3.3(8)]] ::''in'' Ada.Strings [[Guide:95lrm/RM-A-4-1#I4882|A.4.1(4)]] :space_character [[Guide:95lrm/RM-2-1#I1129|2.1(11)]] ::''used'' [[Guide:95lrm/RM-2-1#I1122|2.1(3)]], [[Guide:95lrm/RM-P#I7295|P]] :special graphic character ::a category of Character [[Guide:95lrm/RM-A-3-2#I4645|A.3.2(32)]] :special_character [[Guide:95lrm/RM-2-1#I1130|2.1(12)]] ::names [[Guide:95lrm/RM-2-1#I1136|2.1(15)]] ::''used'' [[Guide:95lrm/RM-2-1#I1123|2.1(3)]], [[Guide:95lrm/RM-P#I7296|P]] :Special_Set ::''in'' Ada.Strings.Maps.Constants [[Guide:95lrm/RM-A-4-6#I5201|A.4.6(4)]] :Specialized Needs Annexes [[Guide:95lrm/RM-1-1-2#I1006|1.1.2(7)]] :specifiable ::of Address for entries [[Guide:95lrm/RM-J-7-1#I7093|J.7.1(6)]] ::of Address for stand-alone objects and for program units [[Guide:95lrm/RM-13-3#I4197|13.3(12)]] ::of Alignment for first subtypes and objects [[Guide:95lrm/RM-13-3#I4203|13.3(25)]] ::of Bit_Order for record types and record extensions [[Guide:95lrm/RM-13-5-3#I4294|13.5.3(4)]] ::of Component_Size for array types [[Guide:95lrm/RM-13-3#I4232|13.3(70)]] ::of External_Tag for a tagged type [[Guide:95lrm/RM-13-3#I4238|13.3(75/1)]], [[Guide:95lrm/RM-K#I7116|K(65)]] ::of Input for a type [[Guide:95lrm/RM-13-13-2#I4511|13.13.2(36/1)]] ::of Machine_Radix for decimal first subtypes [[Guide:95lrm/RM-F-1#I6816|F.1(1)]] ::of Output for a type [[Guide:95lrm/RM-13-13-2#I4512|13.13.2(36/1)]] ::of Read for a type [[Guide:95lrm/RM-13-13-2#I4509|13.13.2(36/1)]] ::of Size for first subtypes [[Guide:95lrm/RM-13-3#I4216|13.3(48)]] ::of Size for stand-alone objects [[Guide:95lrm/RM-13-3#I4211|13.3(41)]] ::of Small for fixed point types [[Guide:95lrm/RM-3-5-10#I1744|3.5.10(2/1)]] ::of Storage_Pool for a non-derived access-to-object type [[Guide:95lrm/RM-13-11#I4420|13.11(15)]] ::of Storage_Size for a non-derived access-to-object type [[Guide:95lrm/RM-13-11#I4419|13.11(15)]] ::of Storage_Size for a task first subtype [[Guide:95lrm/RM-J-9#I7102|J.9(3)]] ::of Write for a type [[Guide:95lrm/RM-13-13-2#I4510|13.13.2(36/1)]] :specifiable (of an attribute and for an entity) [[Guide:95lrm/RM-13-3#I4173|13.3(5/1)]] :specific type [[Guide:95lrm/RM-3-4-1#I1476|3.4.1(3)]] :specified ::of an aspect of representation of an entity [[Guide:95lrm/RM-13-1#I4146|13.1(17)]] ::of an operational aspect of an entity [[Guide:95lrm/RM-13-1#I4148|13.1(18.1/1)]] :specified (not!) [[Guide:95lrm/RM-1-1-3#I1056|1.1.3(18)]] :specified discriminant [[Guide:95lrm/RM-3-7#I1859|3.7(18)]] :Split ::''in'' Ada.Calendar [[Guide:95lrm/RM-9-6#I3557|9.6(14)]] ::''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6644|D.8(16)]] :Sqrt ::''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6923|G.1.2(3)]] ::''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5270|A.5.1(4)]] :SS2 ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4762|A.3.3(17)]] :SS3 ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4763|A.3.3(17)]] :SSA ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4754|A.3.3(17)]] :ST ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4776|A.3.3(19)]] :stand-alone constant [[Guide:95lrm/RM-3-3-1#I1437|3.3.1(23)]] ::corresponding to a formal object of mode in [[Guide:95lrm/RM-12-4#I4041|12.4(10)]] :stand-alone object [[Guide:95lrm/RM-3-3-1#I1399|3.3.1(1)]] :stand-alone variable [[Guide:95lrm/RM-3-3-1#I1438|3.3.1(23)]] :Standard [[Guide:95lrm/RM-A-1#I4548|A.1(4)]] :standard error file [[Guide:95lrm/RM-A-10#I5608|A.10(6)]] :standard input file [[Guide:95lrm/RM-A-10#I5606|A.10(5)]] :standard mode [[Guide:95lrm/RM-1-1-5#I1084|1.1.5(11)]] :standard output file [[Guide:95lrm/RM-A-10#I5607|A.10(5)]] :standard storage pool [[Guide:95lrm/RM-13-11#I4425|13.11(17)]] :Standard_Error ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5665|A.10.1(16)]], [[Guide:95lrm/RM-A-10-1#I5679|A.10.1(19)]] :Standard_Input ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5661|A.10.1(16)]], [[Guide:95lrm/RM-A-10-1#I5675|A.10.1(19)]] :Standard_Output ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5663|A.10.1(16)]], [[Guide:95lrm/RM-A-10-1#I5677|A.10.1(19)]] :State ::''in'' Ada.Numerics.Discrete_Random [[Guide:95lrm/RM-A-5-2#I5371|A.5.2(23)]] ::''in'' Ada.Numerics.Float_Random [[Guide:95lrm/RM-A-5-2#I5349|A.5.2(11)]] :statement [[Guide:95lrm/RM-5-1#I2768|5.1(3)]] ::''used'' [[Guide:95lrm/RM-5-1#I2767|5.1(2)]], [[Guide:95lrm/RM-P#I7593|P]] :statement_identifier [[Guide:95lrm/RM-5-1#I2796|5.1(8)]] ::''used'' [[Guide:95lrm/RM-5-1#I2795|5.1(7)]], [[Guide:95lrm/RM-5-5#I2843|5.5(2)]], [[Guide:95lrm/RM-5-6#I2861|5.6(2)]], [[Guide:95lrm/RM-P#I7616|P]] :static [[Guide:95lrm/RM-4-9#I2741|4.9(1)]] :::constant [[Guide:95lrm/RM-4-9#I2746|4.9(24)]] ::constraint [[Guide:95lrm/RM-4-9#I2752|4.9(27)]] ::delta constraint [[Guide:95lrm/RM-4-9#I2755|4.9(29)]] ::digits constraint [[Guide:95lrm/RM-4-9#I2754|4.9(29)]] ::discrete_range [[Guide:95lrm/RM-4-9#I2748|4.9(25)]] ::discriminant constraint [[Guide:95lrm/RM-4-9#I2757|4.9(31)]] ::expression [[Guide:95lrm/RM-4-9#I2743|4.9(2)]] ::function [[Guide:95lrm/RM-4-9#I2745|4.9(18)]] ::index constraint [[Guide:95lrm/RM-4-9#I2756|4.9(30)]] ::range [[Guide:95lrm/RM-4-9#I2747|4.9(25)]] ::range constraint [[Guide:95lrm/RM-4-9#I2753|4.9(29)]] ::scalar subtype [[Guide:95lrm/RM-4-9#I2750|4.9(26)]] ::string subtype [[Guide:95lrm/RM-4-9#I2751|4.9(26)]] ::subtype [[Guide:95lrm/RM-4-9#I2749|4.9(26)]] ::subtype [[Guide:95lrm/RM-12-4#I4040|12.4(9)]] :static semantics [[Guide:95lrm/RM-1-1-2#I1027|1.1.2(28)]] :statically ::constrained [[Guide:95lrm/RM-4-9#I2758|4.9(32)]] ::denote [[Guide:95lrm/RM-4-9#I2744|4.9(14)]] :statically compatible ::for a constraint and a scalar subtype [[Guide:95lrm/RM-4-9-1#I2762|4.9.1(4)]] ::for a constraint and an access or composite subtype [[Guide:95lrm/RM-4-9-1#I2763|4.9.1(4)]] ::for two subtypes [[Guide:95lrm/RM-4-9-1#I2764|4.9.1(4)]] :statically deeper [[Guide:95lrm/RM-3-10-2#I2103|3.10.2(4)]], [[Guide:95lrm/RM-3-10-2#I2105|3.10.2(17)]] :statically determined tag [[Guide:95lrm/RM-3-9-2#I2004|3.9.2(1)]] ::[''partial''] [[Guide:95lrm/RM-3-9-2#I2026|3.9.2(15)]], [[Guide:95lrm/RM-3-9-2#I2030|3.9.2(19)]] :statically matching ::effect on subtype-specific aspects [[Guide:95lrm/RM-13-1#I4145|13.1(14)]] ::for constraints [[Guide:95lrm/RM-4-9-1#I2759|4.9.1(1)]] ::for ranges [[Guide:95lrm/RM-4-9-1#I2761|4.9.1(3)]] ::for subtypes [[Guide:95lrm/RM-4-9-1#I2760|4.9.1(2)]] ::required [[Guide:95lrm/RM-3-9-2#I2022|3.9.2(10/1)]], [[Guide:95lrm/RM-3-10-2#I2112|3.10.2(27/1)]], [[Guide:95lrm/RM-4-6#I2630|4.6(12/1)]], [[Guide:95lrm/RM-4-6#I2634|4.6(16)]], [[Guide:95lrm/RM-6-3-1#I2977|6.3.1(16)]], [[Guide:95lrm/RM-6-3-1#I2980|6.3.1(17)]], [[Guide:95lrm/RM-6-3-1#I2985|6.3.1(23)]], [[Guide:95lrm/RM-7-3#I3095|7.3(13)]], [[Guide:95lrm/RM-12-5-1#I4074|12.5.1(14)]], [[Guide:95lrm/RM-12-5-3#I4085|12.5.3(6)]], [[Guide:95lrm/RM-12-5-3#I4086|12.5.3(7)]], [[Guide:95lrm/RM-12-5-4#I4089|12.5.4(3)]], [[Guide:95lrm/RM-12-7#I4113|12.7(7)]] :statically tagged [[Guide:95lrm/RM-3-9-2#I2019|3.9.2(4)]] :Status_Error ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5589|A.8.4(18)]] ::''in'' Ada.IO_Exceptions [[Guide:95lrm/RM-A-13#I5993|A.13(4)]] ::''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5536|A.8.1(15)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5968|A.12.1(26)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5883|A.10.1(85)]] :storage deallocation ::unchecked [[Guide:95lrm/RM-13-11-2#I4435|13.11.2(1)]] :storage element [[Guide:95lrm/RM-13-3#I4192|13.3(8)]] :storage management ::user-defined [[Guide:95lrm/RM-13-11#I4396|13.11(1)]] :storage node [[Guide:95lrm/RM-E#I6689|E(2)]] :storage place ::of a component [[Guide:95lrm/RM-13-5#I4254|13.5(1)]] :storage place attributes ::of a component [[Guide:95lrm/RM-13-5-2#I4276|13.5.2(1)]] :storage pool [[Guide:95lrm/RM-3-10#I2062|3.10(7/1)]] :storage pool element [[Guide:95lrm/RM-13-11#I4412|13.11(11)]] :storage pool type [[Guide:95lrm/RM-13-11#I4410|13.11(11)]] :Storage_Array ::''in'' System.Storage_Elements [[Guide:95lrm/RM-13-7-1#I4338|13.7.1(5)]] :Storage_Check [[Guide:95lrm/RM-11-5#I3939|11.5(23)]] ::[''partial''] [[Guide:95lrm/RM-11-1#I3846|11.1(6)]], [[Guide:95lrm/RM-13-3#I4227|13.3(67)]], [[Guide:95lrm/RM-13-11#I4426|13.11(17)]], [[Guide:95lrm/RM-D-7#I6603|D.7(17/1)]], [[Guide:95lrm/RM-D-7#I6607|D.7(18/1)]], [[Guide:95lrm/RM-D-7#I6611|D.7(19/1)]] :Storage_Count ::''in'' System.Storage_Elements [[Guide:95lrm/RM-13-7-1#I4334|13.7.1(4)]] :Storage_Element ::''in'' System.Storage_Elements [[Guide:95lrm/RM-13-7-1#I4336|13.7.1(5)]] :Storage_Elements ::''child of'' System [[Guide:95lrm/RM-13-7-1#I4329|13.7.1(2)]] :Storage_Error ::raised by failure of run-time check [[Guide:95lrm/RM-4-8#I2740|4.8(14)]], [[Guide:95lrm/RM-8-5-4#I3271|8.5.4(8.1/1)]], [[Guide:95lrm/RM-11-1#I3843|11.1(4)]], [[Guide:95lrm/RM-11-1#I3848|11.1(6)]], [[Guide:95lrm/RM-11-5#I3940|11.5(23)]], [[Guide:95lrm/RM-13-3#I4229|13.3(67)]], [[Guide:95lrm/RM-13-11#I4428|13.11(17)]], [[Guide:95lrm/RM-13-11#I4429|13.11(18)]], [[Guide:95lrm/RM-A-7#I5494|A.7(14)]], [[Guide:95lrm/RM-D-7#I6605|D.7(17/1)]], [[Guide:95lrm/RM-D-7#I6609|D.7(18/1)]], [[Guide:95lrm/RM-D-7#I6613|D.7(19/1)]] ::''in'' Standard [[Guide:95lrm/RM-A-1#I4570|A.1(46)]] :Storage_IO ::''child of'' Ada [[Guide:95lrm/RM-A-9#I5596|A.9(3)]] :Storage_Offset ::''in'' System.Storage_Elements [[Guide:95lrm/RM-13-7-1#I4333|13.7.1(3)]] :Storage_Pool attribute [[Guide:95lrm/RM-13-11#I4416|13.11(13)]] :Storage_Pool clause [[Guide:95lrm/RM-13-3#I4185|13.3(7)]], [[Guide:95lrm/RM-13-11#I4421|13.11(15)]] :Storage_Pools ::''child of'' System [[Guide:95lrm/RM-13-11#I4399|13.11(5)]] :Storage_Size ::''in'' System.Storage_Pools [[Guide:95lrm/RM-13-11#I4409|13.11(9)]] :Storage_Size attribute [[Guide:95lrm/RM-13-3#I4220|13.3(60)]], [[Guide:95lrm/RM-13-11#I4418|13.11(14)]], [[Guide:95lrm/RM-J-9#I7101|J.9(2)]] :Storage_Size clause [[Guide:95lrm/RM-13-3#I4186|13.3(7)]], [[Guide:95lrm/RM-13-11#I4422|13.11(15)]] ::''See also'' pragma Storage_Size [[Guide:95lrm/RM-13-3#I4221|13.3(61)]] :Storage_Size pragma [[Guide:95lrm/RM-13-3#I4223|13.3(63)]], [[Guide:95lrm/RM-L#I7254|L(35)]] :Storage_Unit ::''in'' System [[Guide:95lrm/RM-13-7#I4317|13.7(13)]] :stream [[Guide:95lrm/RM-13-13#I4470|13.13(1)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5949|A.12.1(13)]] ::''in'' Ada.Text_IO.Text_Streams [[Guide:95lrm/RM-A-12-2#I5982|A.12.2(4)]] ::''in'' Ada.Wide_Text_IO.Text_Streams [[Guide:95lrm/RM-A-12-3#I5989|A.12.3(4)]] :stream type [[Guide:95lrm/RM-13-13#I4471|13.13(1)]] :Stream_IO ::''child of'' Ada.Streams [[Guide:95lrm/RM-A-12-1#I5914|A.12.1(3)]] :Stream_Access ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5918|A.12.1(4)]] ::''in'' Ada.Text_IO.Text_Streams [[Guide:95lrm/RM-A-12-2#I5980|A.12.2(3)]] ::''in'' Ada.Wide_Text_IO.Text_Streams [[Guide:95lrm/RM-A-12-3#I5987|A.12.3(3)]] :Stream_Element ::''in'' Ada.Streams [[Guide:95lrm/RM-13-13-1#I4479|13.13.1(4/1)]] :Stream_Element_Array ::''in'' Ada.Streams [[Guide:95lrm/RM-13-13-1#I4484|13.13.1(4/1)]] :Stream_Element_Count ::''in'' Ada.Streams [[Guide:95lrm/RM-13-13-1#I4482|13.13.1(4/1)]] :Stream_Element_Offset ::''in'' Ada.Streams [[Guide:95lrm/RM-13-13-1#I4481|13.13.1(4/1)]] :Streams ::''child of'' Ada [[Guide:95lrm/RM-13-13-1#I4472|13.13.1(2)]] :strict mode [[Guide:95lrm/RM-G-2#I6996|G.2(1)]] :String ::''in'' Standard [[Guide:95lrm/RM-A-1#I4563|A.1(37)]] :string type [[Guide:95lrm/RM-3-6-3#I1834|3.6.3(1)]] :String_Access ::''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5112|A.4.5(7)]] :string_element [[Guide:95lrm/RM-2-6#I1230|2.6(3)]] ::''used'' [[Guide:95lrm/RM-2-6#I1229|2.6(2)]], [[Guide:95lrm/RM-P#I7322|P]] :string_literal [[Guide:95lrm/RM-2-6#I1228|2.6(2)]] ::''used'' [[Guide:95lrm/RM-4-4#I2442|4.4(7)]], [[Guide:95lrm/RM-6-1#I2901|6.1(9)]], [[Guide:95lrm/RM-P#I7659|P]] :Strings ::''child of'' Ada [[Guide:95lrm/RM-A-4-1#I4879|A.4.1(3)]] ::''child of'' Interfaces.C [[Guide:95lrm/RM-B-3-1#I6170|B.3.1(3)]] :Strlen ::''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6199|B.3.1(17)]] :structure ::''See'' record type [[Guide:95lrm/RM-3-8#I1893|3.8(1)]] :STS ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4767|A.3.3(18)]] :STX ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4652|A.3.3(5)]] :SUB ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4676|A.3.3(6)]] :subaggregate ::of an array_aggregate [[Guide:95lrm/RM-4-3-3#I2316|4.3.3(6)]] :subcomponent [[Guide:95lrm/RM-3-2#I1312|3.2(6)]] :subprogram [[Guide:95lrm/RM-6#I2875|6(1)]] ::abstract [[Guide:95lrm/RM-3-9-3#I2040|3.9.3(3)]] :subprogram call [[Guide:95lrm/RM-6-4#I2993|6.4(1)]] :subprogram instance [[Guide:95lrm/RM-12-3#I4020|12.3(13)]] :subprogram_body [[Guide:95lrm/RM-6-3#I2949|6.3(2)]] ::''used'' [[Guide:95lrm/RM-3-11#I2141|3.11(6)]], [[Guide:95lrm/RM-9-4#I3398|9.4(8/1)]], [[Guide:95lrm/RM-10-1-1#I3698|10.1.1(7)]], [[Guide:95lrm/RM-P#I7840|P]] :subprogram_body_stub [[Guide:95lrm/RM-10-1-3#I3734|10.1.3(3)]] ::''used'' [[Guide:95lrm/RM-10-1-3#I3730|10.1.3(2)]], [[Guide:95lrm/RM-P#I7848|P]] :subprogram_declaration [[Guide:95lrm/RM-6-1#I2881|6.1(2)]] ::''used'' [[Guide:95lrm/RM-3-1#I1270|3.1(3)]], [[Guide:95lrm/RM-9-4#I3386|9.4(5/1)]], [[Guide:95lrm/RM-9-4#I3397|9.4(8/1)]], [[Guide:95lrm/RM-10-1-1#I3689|10.1.1(5)]], [[Guide:95lrm/RM-P#I7762|P]] :subprogram_default [[Guide:95lrm/RM-12-6#I4096|12.6(3)]] ::''used'' [[Guide:95lrm/RM-12-6#I4095|12.6(2)]], [[Guide:95lrm/RM-P#I7921|P]] :subprogram_renaming_declaration [[Guide:95lrm/RM-8-5-4#I3262|8.5.4(2)]] ::''used'' [[Guide:95lrm/RM-8-5#I3245|8.5(2)]], [[Guide:95lrm/RM-10-1-1#I3696|10.1.1(6)]], [[Guide:95lrm/RM-P#I7715|P]] :subprogram_specification [[Guide:95lrm/RM-6-1#I2885|6.1(4)]] ::''used'' [[Guide:95lrm/RM-6-1#I2882|6.1(2)]], [[Guide:95lrm/RM-6-1#I2884|6.1(3)]], [[Guide:95lrm/RM-6-3#I2950|6.3(2)]], [[Guide:95lrm/RM-8-5-4#I3263|8.5.4(2)]], [[Guide:95lrm/RM-10-1-3#I3735|10.1.3(3)]], [[Guide:95lrm/RM-12-1#I3970|12.1(3)]], [[Guide:95lrm/RM-12-6#I4094|12.6(2)]], [[Guide:95lrm/RM-P#I7852|P]] :subsystem [[Guide:95lrm/RM-10-1#I3675|10.1(3)]], [[Guide:95lrm/RM-N#I7283|N(22)]] :subtype [[Guide:95lrm/RM-3-2#I1316|3.2(8)]] :subtype (of an object) ::''See'' actual subtype of an object [[Guide:95lrm/RM-3-3#I1395|3.3(23)]] ::''See'' actual subtype of an object [[Guide:95lrm/RM-3-3-1#I1426|3.3.1(9)]] :subtype conformance [[Guide:95lrm/RM-6-3-1#I2978|6.3.1(17)]] ::[''partial''] [[Guide:95lrm/RM-3-10-2#I2125|3.10.2(34)]], [[Guide:95lrm/RM-9-5-4#I3522|9.5.4(17)]] ::required [[Guide:95lrm/RM-3-9-2#I2023|3.9.2(10/1)]], [[Guide:95lrm/RM-3-10-2#I2123|3.10.2(32)]], [[Guide:95lrm/RM-4-6#I2639|4.6(19)]], [[Guide:95lrm/RM-8-5-4#I3269|8.5.4(5/1)]], [[Guide:95lrm/RM-9-5-4#I3516|9.5.4(5)]], [[Guide:95lrm/RM-13-3#I4177|13.3(6)]] :subtype conversion ::''See'' type conversion [[Guide:95lrm/RM-4-6#I2604|4.6(1)]] ::''See also'' implicit subtype conversion [[Guide:95lrm/RM-4-6#I2608|4.6(1)]] :subtype-specific ::of a representation item [[Guide:95lrm/RM-13-1#I4138|13.1(8)]] ::of an aspect [[Guide:95lrm/RM-13-1#I4140|13.1(8)]] :subtype_declaration [[Guide:95lrm/RM-3-2-2#I1352|3.2.2(2)]] ::''used'' [[Guide:95lrm/RM-3-1#I1267|3.1(3)]], [[Guide:95lrm/RM-P#I7333|P]] :subtype_indication [[Guide:95lrm/RM-3-2-2#I1355|3.2.2(3)]] ::''used'' [[Guide:95lrm/RM-3-2-2#I1354|3.2.2(2)]], [[Guide:95lrm/RM-3-3-1#I1407|3.3.1(2)]], [[Guide:95lrm/RM-3-4#I1448|3.4(2)]], [[Guide:95lrm/RM-3-6#I1777|3.6(6)]], [[Guide:95lrm/RM-3-6#I1780|3.6(7)]], [[Guide:95lrm/RM-3-6-1#I1807|3.6.1(3)]], [[Guide:95lrm/RM-3-10#I2051|3.10(3)]], [[Guide:95lrm/RM-4-8#I2721|4.8(2)]], [[Guide:95lrm/RM-7-3#I3089|7.3(3)]], [[Guide:95lrm/RM-P#I7705|P]] :subtype_mark [[Guide:95lrm/RM-3-2-2#I1358|3.2.2(4)]] ::''used'' [[Guide:95lrm/RM-3-2-2#I1356|3.2.2(3)]], [[Guide:95lrm/RM-3-6#I1771|3.6(4)]], [[Guide:95lrm/RM-3-7#I1847|3.7(5)]], [[Guide:95lrm/RM-3-10#I2057|3.10(6)]], [[Guide:95lrm/RM-4-3-2#I2291|4.3.2(3)]], [[Guide:95lrm/RM-4-4#I2425|4.4(3)]], [[Guide:95lrm/RM-4-6#I2611|4.6(2)]], [[Guide:95lrm/RM-4-7#I2703|4.7(2)]], [[Guide:95lrm/RM-6-1#I2908|6.1(13)]], [[Guide:95lrm/RM-6-1#I2915|6.1(15)]], [[Guide:95lrm/RM-8-4#I3234|8.4(4)]], [[Guide:95lrm/RM-8-5-1#I3252|8.5.1(2)]], [[Guide:95lrm/RM-12-3#I4012|12.3(5)]], [[Guide:95lrm/RM-12-4#I4035|12.4(2)]], [[Guide:95lrm/RM-12-5-1#I4072|12.5.1(3)]], [[Guide:95lrm/RM-P#I7582|P]] :subtypes ::of a profile [[Guide:95lrm/RM-6-1#I2930|6.1(25)]] :subunit [[Guide:95lrm/RM-10-1-3#I3742|10.1.3(7)]], [[Guide:95lrm/RM-10-1-3#I3746|10.1.3(8)]] ::''used'' [[Guide:95lrm/RM-10-1-1#I3683|10.1.1(3)]], [[Guide:95lrm/RM-P#I7829|P]] :Succ attribute [[Guide:95lrm/RM-3-5#I1531|3.5(22)]] :Success ::''in'' Ada.Command_Line [[Guide:95lrm/RM-A-15#I6016|A.15(8)]] :super ::''See'' view conversion [[Guide:95lrm/RM-4-6#I2623|4.6(5/1)]] :Superscript_One ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4808|A.3.3(22)]] :Superscript_Three ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4801|A.3.3(22)]] :Superscript_Two ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4800|A.3.3(22)]] :Suppress pragma [[Guide:95lrm/RM-11-5#I3921|11.5(4)]], [[Guide:95lrm/RM-L#I7257|L(36)]] :suppressed check [[Guide:95lrm/RM-11-5#I3926|11.5(8)]] :Suspend_Until_True ::''in'' Ada.Synchronous_Task_Control [[Guide:95lrm/RM-D-10#I6669|D.10(4)]] :Suspension_Object ::''in'' Ada.Synchronous_Task_Control [[Guide:95lrm/RM-D-10#I6661|D.10(4)]] :SYN ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4672|A.3.3(6)]] :synchronization [[Guide:95lrm/RM-9#I3309|9(1)]] :Synchronous_Task_Control ::''child of'' Ada [[Guide:95lrm/RM-D-10#I6657|D.10(3)]] :syntactic category [[Guide:95lrm/RM-1-1-4#I1066|1.1.4(15)]] :syntax ::complete listing [[Guide:95lrm/RM-P#I7285|P(1)]] ::cross reference [[Guide:95lrm/RM-P#I7964|P(1)]] ::notation [[Guide:95lrm/RM-1-1-4#I1060|1.1.4(3)]] ::under Syntax heading [[Guide:95lrm/RM-1-1-2#I1014|1.1.2(25)]] :System [[Guide:95lrm/RM-13-7#I4301|13.7(3)]] :System.Address_To_Access_Conversions [[Guide:95lrm/RM-13-7-2#I4351|13.7.2(2)]] :System.Machine_Code [[Guide:95lrm/RM-13-8#I4361|13.8(7)]] :System.RPC [[Guide:95lrm/RM-E-5#I6793|E.5(3)]] :System.Storage_Elements [[Guide:95lrm/RM-13-7-1#I4331|13.7.1(2)]] :System.Storage_Pools [[Guide:95lrm/RM-13-11#I4401|13.11(5)]] :System_Name ::''in'' System [[Guide:95lrm/RM-13-7#I4304|13.7(4)]] :systems programming [[Guide:95lrm/RM-C#I6360|C(1)]] == T == :Tag ::''in'' Ada.Tags [[Guide:95lrm/RM-3-9#I1968|3.9(6)]] :Tag attribute [[Guide:95lrm/RM-3-9#I1981|3.9(16)]], [[Guide:95lrm/RM-3-9#I1983|3.9(18)]] :tag indeterminate [[Guide:95lrm/RM-3-9-2#I2021|3.9.2(6)]] :tag of an object [[Guide:95lrm/RM-3-9#I1958|3.9(3)]] ::class-wide object [[Guide:95lrm/RM-3-9#I1986|3.9(22)]] ::object created by an allocator [[Guide:95lrm/RM-3-9#I1985|3.9(21)]] ::preserved by type conversion and parameter passing [[Guide:95lrm/RM-3-9#I1989|3.9(25)]] ::returned by a function [[Guide:95lrm/RM-3-9#I1987|3.9(23)]], [[Guide:95lrm/RM-3-9#I1988|3.9(24)]] ::stand-alone object, component, or aggregate [[Guide:95lrm/RM-3-9#I1984|3.9(20)]] :Tag_Check [[Guide:95lrm/RM-11-5#I3935|11.5(18)]] ::[''partial''] [[Guide:95lrm/RM-3-9-2#I2027|3.9.2(16)]], [[Guide:95lrm/RM-4-6#I2667|4.6(42)]], [[Guide:95lrm/RM-4-6#I2690|4.6(52)]], [[Guide:95lrm/RM-5-2#I2812|5.2(10)]], [[Guide:95lrm/RM-6-5#I3041|6.5(9)]] :Tag_Error ::''in'' Ada.Tags [[Guide:95lrm/RM-3-9#I1975|3.9(8)]] :tagged type [[Guide:95lrm/RM-3-9#I1952|3.9(2)]] :Tags ::''child of'' Ada [[Guide:95lrm/RM-3-9#I1964|3.9(6)]] :Tail ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5094|A.4.4(72)]], [[Guide:95lrm/RM-A-4-4#I5096|A.4.4(73)]] ::''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4999|A.4.3(37)]], [[Guide:95lrm/RM-A-4-3#I5001|A.4.3(38)]] ::''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5186|A.4.5(67)]], [[Guide:95lrm/RM-A-4-5#I5188|A.4.5(68)]] :tail (of a queue) [[Guide:95lrm/RM-D-2-1#I6533|D.2.1(5)]] :Tan ::''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6935|G.1.2(4)]] ::''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5288|A.5.1(5)]] :Tanh ::''in'' Ada.Numerics.Generic_Complex_Elementary_Functions [[Guide:95lrm/RM-G-1-2#I6951|G.1.2(6)]] ::''in'' Ada.Numerics.Generic_Elementary_Functions [[Guide:95lrm/RM-A-5-1#I5314|A.5.1(7)]] :target ::of an assignment operation [[Guide:95lrm/RM-5-2#I2806|5.2(3)]] ::of an assignment_statement [[Guide:95lrm/RM-5-2#I2807|5.2(3)]] :target entry ::of a requeue_statement [[Guide:95lrm/RM-9-5-4#I3514|9.5.4(3)]] :target object ::of a call on an entry or a protected subprogram [[Guide:95lrm/RM-9-5#I3414|9.5(2)]] ::of a requeue_statement [[Guide:95lrm/RM-9-5#I3417|9.5(7)]] :target statement ::of a goto_statement [[Guide:95lrm/RM-5-8#I2873|5.8(3)]] :target subtype ::of a type_conversion [[Guide:95lrm/RM-4-6#I2615|4.6(3)]] :task [[Guide:95lrm/RM-9#I3306|9(1)]] ::activation [[Guide:95lrm/RM-9-2#I3355|9.2(1)]] ::completion [[Guide:95lrm/RM-9-3#I3362|9.3(1)]] ::dependence [[Guide:95lrm/RM-9-3#I3361|9.3(1)]] ::execution [[Guide:95lrm/RM-9-2#I3353|9.2(1)]] ::termination [[Guide:95lrm/RM-9-3#I3363|9.3(1)]] :task declaration [[Guide:95lrm/RM-9-1#I3323|9.1(1)]] :task dispatching [[Guide:95lrm/RM-D-2-1#I6527|D.2.1(4)]] :task dispatching point [[Guide:95lrm/RM-D-2-1#I6529|D.2.1(4)]] ::[''partial''] [[Guide:95lrm/RM-D-2-1#I6540|D.2.1(8)]], [[Guide:95lrm/RM-D-2-2#I6552|D.2.2(12)]] :task dispatching policy [[Guide:95lrm/RM-D-2-2#I6550|D.2.2(6)]] ::[''partial''] [[Guide:95lrm/RM-D-2-1#I6535|D.2.1(5)]] :task priority [[Guide:95lrm/RM-D-1#I6519|D.1(15)]] :task state ::abnormal [[Guide:95lrm/RM-9-8#I3641|9.8(4)]] ::blocked [[Guide:95lrm/RM-9#I3316|9(10)]] ::callable [[Guide:95lrm/RM-9-9#I3655|9.9(2)]] ::held [[Guide:95lrm/RM-D-11#I6682|D.11(4)]] ::inactive [[Guide:95lrm/RM-9#I3314|9(10)]] ::ready [[Guide:95lrm/RM-9#I3318|9(10)]] ::terminated [[Guide:95lrm/RM-9#I3320|9(10)]] :task unit [[Guide:95lrm/RM-9#I3313|9(9)]] :Task_Attributes ::''child of'' Ada [[Guide:95lrm/RM-C-7-2#I6490|C.7.2(2)]] :task_body [[Guide:95lrm/RM-9-1#I3338|9.1(6)]] ::''used'' [[Guide:95lrm/RM-3-11#I2143|3.11(6)]], [[Guide:95lrm/RM-P#I7487|P]] :task_body_stub [[Guide:95lrm/RM-10-1-3#I3738|10.1.3(5)]] ::''used'' [[Guide:95lrm/RM-10-1-3#I3732|10.1.3(2)]], [[Guide:95lrm/RM-P#I7850|P]] :task_definition [[Guide:95lrm/RM-9-1#I3331|9.1(4)]] ::''used'' [[Guide:95lrm/RM-9-1#I3327|9.1(2)]], [[Guide:95lrm/RM-9-1#I3330|9.1(3)]], [[Guide:95lrm/RM-P#I7734|P]] :Task_Dispatching_Policy pragma [[Guide:95lrm/RM-D-2-2#I6544|D.2.2(2)]], [[Guide:95lrm/RM-L#I7261|L(37)]] :Task_ID ::''in'' Ada.Task_Identification [[Guide:95lrm/RM-C-7-1#I6467|C.7.1(2)]] :Task_Identification ::''child of'' Ada [[Guide:95lrm/RM-C-7-1#I6463|C.7.1(2)]] :task_item [[Guide:95lrm/RM-9-1#I3335|9.1(5/1)]] ::''used'' [[Guide:95lrm/RM-9-1#I3333|9.1(4)]], [[Guide:95lrm/RM-P#I7738|P]] :task_type_declaration [[Guide:95lrm/RM-9-1#I3324|9.1(2)]] ::''used'' [[Guide:95lrm/RM-3-2-1#I1332|3.2.1(3)]], [[Guide:95lrm/RM-P#I7351|P]] :Tasking_Error ::raised by failure of run-time check [[Guide:95lrm/RM-9-2#I3359|9.2(5)]], [[Guide:95lrm/RM-9-5-3#I3508|9.5.3(21)]], [[Guide:95lrm/RM-11-1#I3844|11.1(4)]], [[Guide:95lrm/RM-13-11-2#I4446|13.11.2(13)]], [[Guide:95lrm/RM-13-11-2#I4448|13.11.2(14)]], [[Guide:95lrm/RM-C-7-2#I6503|C.7.2(13)]], [[Guide:95lrm/RM-D-5#I6586|D.5(8)]], [[Guide:95lrm/RM-D-11#I6685|D.11(8)]] ::''in'' Standard [[Guide:95lrm/RM-A-1#I4571|A.1(46)]] :template [[Guide:95lrm/RM-12#I3961|12(1)]] ::for a formal package [[Guide:95lrm/RM-12-7#I4112|12.7(4)]] ::''See'' generic unit [[Guide:95lrm/RM-12#I3962|12(1)]] :term [[Guide:95lrm/RM-4-4#I2431|4.4(5)]] ::''used'' [[Guide:95lrm/RM-4-4#I2428|4.4(4)]], [[Guide:95lrm/RM-P#I7567|P]] :terminal interrupt ::example [[Guide:95lrm/RM-9-7-4#I3628|9.7.4(10)]] :terminate_alternative [[Guide:95lrm/RM-9-7-1#I3595|9.7.1(7)]] ::''used'' [[Guide:95lrm/RM-9-7-1#I3588|9.7.1(4)]], [[Guide:95lrm/RM-P#I7805|P]] :terminated ::a task state [[Guide:95lrm/RM-9#I3321|9(10)]] :Terminated attribute [[Guide:95lrm/RM-9-9#I3658|9.9(3)]] :termination ::of a partition [[Guide:95lrm/RM-E-1#I6697|E.1(7)]] :Terminator_Error ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6167|B.3(40)]] :tested type ::of a membership test [[Guide:95lrm/RM-4-5-2#I2524|4.5.2(3)]] :text of a program [[Guide:95lrm/RM-2-2#I1167|2.2(1)]] :Text_Streams ::''child of'' Ada.Text_IO [[Guide:95lrm/RM-A-12-2#I5976|A.12.2(3)]] ::''child of'' Ada.Wide_Text_IO [[Guide:95lrm/RM-A-12-3#I5983|A.12.3(3)]] :Text_IO ::''child of'' Ada [[Guide:95lrm/RM-A-10-1#I5619|A.10.1(2)]] :throw (an exception) ::''See'' raise [[Guide:95lrm/RM-11#I3832|11(1)]] :tick [[Guide:95lrm/RM-2-1#I1141|2.1(15)]] ::''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6628|D.8(6)]] ::''in'' System [[Guide:95lrm/RM-13-7#I4313|13.7(10)]] :Tilde ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4741|A.3.3(14)]] :Time ::''in'' Ada.Calendar [[Guide:95lrm/RM-9-6#I3541|9.6(10)]] ::''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6618|D.8(4)]] :time base [[Guide:95lrm/RM-9-6#I3535|9.6(6)]] :time limit ::example [[Guide:95lrm/RM-9-7-4#I3631|9.7.4(12)]] :time type [[Guide:95lrm/RM-9-6#I3534|9.6(6)]] :Time-dependent Reset procedure ::of the random number generator [[Guide:95lrm/RM-A-5-2#I5383|A.5.2(34)]] :time-out ::example [[Guide:95lrm/RM-9-7-4#I3630|9.7.4(12)]] ::''See'' asynchronous_select [[Guide:95lrm/RM-9-7-4#I3629|9.7.4(12)]] ::''See'' selective_accept [[Guide:95lrm/RM-9-7-1#I3576|9.7.1(1)]] ::''See'' timed_entry_call [[Guide:95lrm/RM-9-7-2#I3601|9.7.2(1)]] :Time_Error ::''in'' Ada.Calendar [[Guide:95lrm/RM-9-6#I3560|9.6(18)]] :Time_First ::''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6619|D.8(4)]] :Time_Last ::''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6620|D.8(4)]] :Time_Of ::''in'' Ada.Calendar [[Guide:95lrm/RM-9-6#I3559|9.6(15)]] ::''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6646|D.8(16)]] :Time_Span ::''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6623|D.8(5)]] :Time_Span_First ::''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6624|D.8(5)]] :Time_Span_Last ::''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6625|D.8(5)]] :Time_Span_Unit ::''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6627|D.8(5)]] :Time_Span_Zero ::''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6626|D.8(5)]] :Time_Unit ::''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6621|D.8(4)]] :timed_entry_call [[Guide:95lrm/RM-9-7-2#I3602|9.7.2(2)]] ::''used'' [[Guide:95lrm/RM-9-7#I3573|9.7(2)]], [[Guide:95lrm/RM-P#I7794|P]] :timer interrupt ::example [[Guide:95lrm/RM-9-7-4#I3633|9.7.4(12)]] :times operator [[Guide:95lrm/RM-4-4#I2388|4.4(1)]], [[Guide:95lrm/RM-4-5-5#I2570|4.5.5(1)]] :timing ::''See'' delay_statement [[Guide:95lrm/RM-9-6#I3524|9.6(1)]] :To_Ada ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6135|B.3(22)]], [[Guide:95lrm/RM-B-3#I6143|B.3(26)]], [[Guide:95lrm/RM-B-3#I6147|B.3(28)]], [[Guide:95lrm/RM-B-3#I6154|B.3(32)]], [[Guide:95lrm/RM-B-3#I6162|B.3(37)]], [[Guide:95lrm/RM-B-3#I6166|B.3(39)]] ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6264|B.4(17)]], [[Guide:95lrm/RM-B-4#I6268|B.4(19)]] ::''in'' Interfaces.Fortran [[Guide:95lrm/RM-B-5#I6351|B.5(13)]], [[Guide:95lrm/RM-B-5#I6355|B.5(14)]], [[Guide:95lrm/RM-B-5#I6359|B.5(16)]] :To_Address ::''in'' System.Address_To_Access_Conversions [[Guide:95lrm/RM-13-7-2#I4355|13.7.2(3)]] ::''in'' System.Storage_Elements [[Guide:95lrm/RM-13-7-1#I4343|13.7.1(10)]] :To_Basic ::''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4608|A.3.2(6)]], [[Guide:95lrm/RM-A-3-2#I4614|A.3.2(7)]] :To_Binary ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6315|B.4(45)]], [[Guide:95lrm/RM-B-4#I6321|B.4(48)]] :To_Bounded_String ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5016|A.4.4(11)]] :To_C ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6133|B.3(21)]], [[Guide:95lrm/RM-B-3#I6141|B.3(25)]], [[Guide:95lrm/RM-B-3#I6145|B.3(27)]], [[Guide:95lrm/RM-B-3#I6152|B.3(32)]], [[Guide:95lrm/RM-B-3#I6160|B.3(36)]], [[Guide:95lrm/RM-B-3#I6164|B.3(38)]] :To_Character ::''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4629|A.3.2(15)]] :To_Chars_Ptr ::''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6181|B.3.1(8)]] :To_COBOL ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6262|B.4(17)]], [[Guide:95lrm/RM-B-4#I6266|B.4(18)]] :To_Decimal ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6297|B.4(35)]], [[Guide:95lrm/RM-B-4#I6305|B.4(40)]], [[Guide:95lrm/RM-B-4#I6313|B.4(44)]], [[Guide:95lrm/RM-B-4#I6317|B.4(47)]] :To_Display ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6299|B.4(36)]] :To_Domain ::''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4933|A.4.2(24)]] ::''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5250|A.4.7(24)]] :To_Duration ::''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6632|D.8(13)]] :To_Fortran ::''in'' Interfaces.Fortran [[Guide:95lrm/RM-B-5#I6349|B.5(13)]], [[Guide:95lrm/RM-B-5#I6353|B.5(14)]], [[Guide:95lrm/RM-B-5#I6357|B.5(15)]] :To_Integer ::''in'' System.Storage_Elements [[Guide:95lrm/RM-13-7-1#I4345|13.7.1(10)]] :To_ISO_646 ::''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4621|A.3.2(11)]], [[Guide:95lrm/RM-A-3-2#I4623|A.3.2(12)]] :To_Long_Binary ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6323|B.4(48)]] :To_Lower ::''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4604|A.3.2(6)]], [[Guide:95lrm/RM-A-3-2#I4610|A.3.2(7)]] :To_Mapping ::''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4931|A.4.2(23)]] ::''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5248|A.4.7(23)]] :To_Packed ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6307|B.4(41)]] :To_Picture ::''in'' Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6840|F.3.3(6)]] :To_Pointer ::''in'' System.Address_To_Access_Conversions [[Guide:95lrm/RM-13-7-2#I4353|13.7.2(3)]] :To_Range ::''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4935|A.4.2(24)]] ::''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5252|A.4.7(25)]] :To_Ranges ::''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4913|A.4.2(10)]] ::''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5230|A.4.7(10)]] :To_Sequence ::''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4924|A.4.2(19)]] ::''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5241|A.4.7(19)]] :To_Set ::''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4909|A.4.2(8)]], [[Guide:95lrm/RM-A-4-2#I4911|A.4.2(9)]], [[Guide:95lrm/RM-A-4-2#I4920|A.4.2(17)]], [[Guide:95lrm/RM-A-4-2#I4922|A.4.2(18)]] ::''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5226|A.4.7(8)]], [[Guide:95lrm/RM-A-4-7#I5228|A.4.7(9)]], [[Guide:95lrm/RM-A-4-7#I5237|A.4.7(17)]], [[Guide:95lrm/RM-A-4-7#I5239|A.4.7(18)]] :To_String ::''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4631|A.3.2(16)]] ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5018|A.4.4(12)]] ::''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5120|A.4.5(11)]] :To_Time_Span ::''in'' Ada.Real_Time [[Guide:95lrm/RM-D-8#I6634|D.8(13)]] :To_Unbounded_String ::''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5116|A.4.5(9)]], [[Guide:95lrm/RM-A-4-5#I5118|A.4.5(10)]] :To_Upper ::''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4606|A.3.2(6)]], [[Guide:95lrm/RM-A-3-2#I4612|A.3.2(7)]] :To_Wide_Character ::''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4633|A.3.2(17)]] :To_Wide_String ::''in'' Ada.Characters.Handling [[Guide:95lrm/RM-A-3-2#I4635|A.3.2(18)]] :token ::''See'' lexical element [[Guide:95lrm/RM-2-2#I1169|2.2(1)]] :Trailing_Nonseparate ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6277|B.4(23)]] :Trailing_Separate ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6275|B.4(23)]] :transfer of control [[Guide:95lrm/RM-5-1#I2799|5.1(14)]] :Translate ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5058|A.4.4(53)]], [[Guide:95lrm/RM-A-4-4#I5060|A.4.4(54)]], [[Guide:95lrm/RM-A-4-4#I5062|A.4.4(55)]], [[Guide:95lrm/RM-A-4-4#I5064|A.4.4(56)]] ::''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4963|A.4.3(18)]], [[Guide:95lrm/RM-A-4-3#I4965|A.4.3(19)]], [[Guide:95lrm/RM-A-4-3#I4967|A.4.3(20)]], [[Guide:95lrm/RM-A-4-3#I4969|A.4.3(21)]] ::''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5150|A.4.5(48)]], [[Guide:95lrm/RM-A-4-5#I5152|A.4.5(49)]], [[Guide:95lrm/RM-A-4-5#I5154|A.4.5(50)]], [[Guide:95lrm/RM-A-4-5#I5156|A.4.5(51)]] :Translation_Error ::''in'' Ada.Strings [[Guide:95lrm/RM-A-4-1#I4887|A.4.1(5)]] :triggering_alternative [[Guide:95lrm/RM-9-7-4#I3616|9.7.4(3)]] ::''used'' [[Guide:95lrm/RM-9-7-4#I3614|9.7.4(2)]], [[Guide:95lrm/RM-P#I7816|P]] :triggering_statement [[Guide:95lrm/RM-9-7-4#I3619|9.7.4(4)]] ::''used'' [[Guide:95lrm/RM-9-7-4#I3617|9.7.4(3)]], [[Guide:95lrm/RM-P#I7818|P]] :Trim ::''in'' Ada.Strings.Bounded [[Guide:95lrm/RM-A-4-4#I5084|A.4.4(67)]], [[Guide:95lrm/RM-A-4-4#I5086|A.4.4(68)]], [[Guide:95lrm/RM-A-4-4#I5088|A.4.4(69)]] ::''in'' Ada.Strings.Fixed [[Guide:95lrm/RM-A-4-3#I4987|A.4.3(31)]], [[Guide:95lrm/RM-A-4-3#I4989|A.4.3(32)]], [[Guide:95lrm/RM-A-4-3#I4991|A.4.3(33)]], [[Guide:95lrm/RM-A-4-3#I4993|A.4.3(34)]] ::''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5174|A.4.5(61)]], [[Guide:95lrm/RM-A-4-5#I5176|A.4.5(62)]], [[Guide:95lrm/RM-A-4-5#I5178|A.4.5(63)]], [[Guide:95lrm/RM-A-4-5#I5180|A.4.5(64)]] :Trim_End ::''in'' Ada.Strings [[Guide:95lrm/RM-A-4-1#I4897|A.4.1(6)]] :True [[Guide:95lrm/RM-3-5-3#I1600|3.5.3(1)]] :Truncation ::''in'' Ada.Strings [[Guide:95lrm/RM-A-4-1#I4891|A.4.1(6)]] :Truncation attribute [[Guide:95lrm/RM-A-5-3#I5436|A.5.3(42)]] :two's complement ::modular types [[Guide:95lrm/RM-3-5-4#I1650|3.5.4(29)]] :type [[Guide:95lrm/RM-3-2#I1296|3.2(1)]] ::abstract [[Guide:95lrm/RM-3-9-3#I2038|3.9.3(2)]] ::''See also'' tag [[Guide:95lrm/RM-3-9#I1962|3.9(3)]] ::''See also'' language-defined types :type conformance [[Guide:95lrm/RM-6-3-1#I2972|6.3.1(15)]] ::[''partial''] [[Guide:95lrm/RM-3-4#I1463|3.4(17)]], [[Guide:95lrm/RM-8-3#I3207|8.3(8)]], [[Guide:95lrm/RM-8-3#I3226|8.3(26/1)]], [[Guide:95lrm/RM-10-1-4#I3751|10.1.4(4/1)]] ::required [[Guide:95lrm/RM-3-11-1#I2153|3.11.1(5)]], [[Guide:95lrm/RM-4-1-4#I2239|4.1.4(14/1)]], [[Guide:95lrm/RM-8-6#I3300|8.6(26)]], [[Guide:95lrm/RM-9-5-4#I3515|9.5.4(3)]] :type conversion [[Guide:95lrm/RM-4-6#I2605|4.6(1)]] ::access [[Guide:95lrm/RM-4-6#I2631|4.6(13)]], [[Guide:95lrm/RM-4-6#I2637|4.6(18)]], [[Guide:95lrm/RM-4-6#I2675|4.6(47)]] ::arbitrary order [[Guide:95lrm/RM-1-1-4#I1070|1.1.4(18)]] ::array [[Guide:95lrm/RM-4-6#I2627|4.6(9)]], [[Guide:95lrm/RM-4-6#I2658|4.6(36)]] ::composite (non-array) [[Guide:95lrm/RM-4-6#I2644|4.6(21)]], [[Guide:95lrm/RM-4-6#I2665|4.6(40)]] ::enumeration [[Guide:95lrm/RM-4-6#I2642|4.6(21)]], [[Guide:95lrm/RM-4-6#I2656|4.6(34)]] ::numeric [[Guide:95lrm/RM-4-6#I2625|4.6(8)]], [[Guide:95lrm/RM-4-6#I2653|4.6(29)]] ::unchecked [[Guide:95lrm/RM-13-9#I4366|13.9(1)]] ::''See also'' qualified_expression [[Guide:95lrm/RM-4-7#I2701|4.7(1)]] :type conversion, implicit ::''See'' implicit subtype conversion [[Guide:95lrm/RM-4-6#I2609|4.6(1)]] :type extension [[Guide:95lrm/RM-3-9#I1953|3.9(2)]], [[Guide:95lrm/RM-3-9-1#I1990|3.9.1(1)]] :type of a discrete_range [[Guide:95lrm/RM-3-6-1#I1809|3.6.1(4)]] :type of a range [[Guide:95lrm/RM-3-5#I1501|3.5(4)]] :type parameter ::''See'' discriminant [[Guide:95lrm/RM-3-7#I1836|3.7(1)]] :type profile ::''See'' profile, type conformant [[Guide:95lrm/RM-6-3-1#I2974|6.3.1(15)]] :type resolution rules [[Guide:95lrm/RM-8-6#I3294|8.6(20)]] ::if any type in a specified class of types is expected [[Guide:95lrm/RM-8-6#I3295|8.6(21)]] ::if expected type is specific [[Guide:95lrm/RM-8-6#I3297|8.6(22)]] ::if expected type is universal or class-wide [[Guide:95lrm/RM-8-6#I3296|8.6(21)]] :type tag ::''See'' tag [[Guide:95lrm/RM-3-9#I1960|3.9(3)]] :type-related ::aspect [[Guide:95lrm/RM-13-1#I4139|13.1(8)]] ::aspect [[Guide:95lrm/RM-13-1#I4144|13.1(8.1/1)]] ::operational item [[Guide:95lrm/RM-13-1#I4143|13.1(8.1/1)]] ::representation item [[Guide:95lrm/RM-13-1#I4137|13.1(8)]] :type_conversion [[Guide:95lrm/RM-4-6#I2610|4.6(2)]] ::''used'' [[Guide:95lrm/RM-4-1#I2163|4.1(2)]], [[Guide:95lrm/RM-P#I7495|P]] ::''See also'' unchecked type conversion [[Guide:95lrm/RM-13-9#I4368|13.9(1)]] :type_declaration [[Guide:95lrm/RM-3-2-1#I1323|3.2.1(2)]] ::''used'' [[Guide:95lrm/RM-3-1#I1266|3.1(3)]], [[Guide:95lrm/RM-P#I7332|P]] :type_definition [[Guide:95lrm/RM-3-2-1#I1334|3.2.1(4)]] ::''used'' [[Guide:95lrm/RM-3-2-1#I1331|3.2.1(3)]], [[Guide:95lrm/RM-P#I7350|P]] :Type_Set ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5633|A.10.1(7)]] :types ::of a profile [[Guide:95lrm/RM-6-1#I2931|6.1(29)]] == U == :UC_A_Acute ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4816|A.3.3(23)]] :UC_A_Circumflex ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4817|A.3.3(23)]] :UC_A_Diaeresis ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4819|A.3.3(23)]] :UC_A_Grave ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4815|A.3.3(23)]] :UC_A_Ring ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4820|A.3.3(23)]] :UC_A_Tilde ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4818|A.3.3(23)]] :UC_AE_Diphthong ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4821|A.3.3(23)]] :UC_C_Cedilla ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4822|A.3.3(23)]] :UC_E_Acute ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4824|A.3.3(23)]] :UC_E_Circumflex ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4825|A.3.3(23)]] :UC_E_Diaeresis ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4826|A.3.3(23)]] :UC_E_Grave ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4823|A.3.3(23)]] :UC_I_Acute ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4828|A.3.3(23)]] :UC_I_Circumflex ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4829|A.3.3(23)]] :UC_I_Diaeresis ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4830|A.3.3(23)]] :UC_I_Grave ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4827|A.3.3(23)]] :UC_Icelandic_Eth ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4831|A.3.3(24)]] :UC_Icelandic_Thorn ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4845|A.3.3(24)]] :UC_N_Tilde ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4832|A.3.3(24)]] :UC_O_Acute ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4834|A.3.3(24)]] :UC_O_Circumflex ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4835|A.3.3(24)]] :UC_O_Diaeresis ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4837|A.3.3(24)]] :UC_O_Grave ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4833|A.3.3(24)]] :UC_O_Oblique_Stroke ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4839|A.3.3(24)]] :UC_O_Tilde ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4836|A.3.3(24)]] :UC_U_Acute ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4841|A.3.3(24)]] :UC_U_Circumflex ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4842|A.3.3(24)]] :UC_U_Diaeresis ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4843|A.3.3(24)]] :UC_U_Grave ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4840|A.3.3(24)]] :UC_Y_Acute ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4844|A.3.3(24)]] :UCHAR_MAX ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6100|B.3(6)]] :ultimate ancestor ::of a type [[Guide:95lrm/RM-3-4-1#I1485|3.4.1(10)]] :unary adding operator [[Guide:95lrm/RM-4-5-4#I2554|4.5.4(1)]] :unary operator [[Guide:95lrm/RM-4-5#I2464|4.5(9)]] :unary_adding_operator [[Guide:95lrm/RM-4-5#I2457|4.5(5)]] ::''used'' [[Guide:95lrm/RM-4-4#I2427|4.4(4)]], [[Guide:95lrm/RM-P#I7564|P]] :Unbiased_Rounding attribute [[Guide:95lrm/RM-A-5-3#I5434|A.5.3(39)]] :Unbounded ::''child of'' Ada.Strings [[Guide:95lrm/RM-A-4-5#I5103|A.4.5(3)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5629|A.10.1(5)]] :Unbounded_String ::''in'' Ada.Strings.Unbounded [[Guide:95lrm/RM-A-4-5#I5107|A.4.5(4)]] :unchecked storage deallocation [[Guide:95lrm/RM-13-11-2#I4434|13.11.2(1)]] :unchecked type conversion [[Guide:95lrm/RM-13-9#I4365|13.9(1)]] :Unchecked_Access attribute [[Guide:95lrm/RM-13-10#I4393|13.10(3)]], [[Guide:95lrm/RM-H-4#I7068|H.4(18)]] ::''See also'' Access attribute [[Guide:95lrm/RM-3-10-2#I2111|3.10.2(24/1)]] :Unchecked_Conversion ::''child of'' Ada [[Guide:95lrm/RM-13-9#I4370|13.9(3)]] :Unchecked_Deallocation ::''child of'' Ada [[Guide:95lrm/RM-13-11-2#I4439|13.11.2(3)]] :unconstrained [[Guide:95lrm/RM-3-2#I1319|3.2(9)]] ::object [[Guide:95lrm/RM-3-3-1#I1428|3.3.1(9)]], [[Guide:95lrm/RM-3-10#I2068|3.10(9)]] ::object [[Guide:95lrm/RM-6-4-1#I3026|6.4.1(16)]] ::subtype [[Guide:95lrm/RM-3-2#I1321|3.2(9)]], [[Guide:95lrm/RM-3-4#I1454|3.4(6)]], [[Guide:95lrm/RM-3-5#I1510|3.5(7)]], [[Guide:95lrm/RM-3-5-1#I1586|3.5.1(10)]], [[Guide:95lrm/RM-3-5-4#I1621|3.5.4(9)]], [[Guide:95lrm/RM-3-5-4#I1624|3.5.4(10)]], [[Guide:95lrm/RM-3-5-7#I1693|3.5.7(11)]], [[Guide:95lrm/RM-3-5-9#I1730|3.5.9(13)]], [[Guide:95lrm/RM-3-5-9#I1734|3.5.9(16)]], [[Guide:95lrm/RM-3-6#I1793|3.6(15)]], [[Guide:95lrm/RM-3-6#I1796|3.6(16)]], [[Guide:95lrm/RM-3-7#I1865|3.7(26)]], [[Guide:95lrm/RM-3-9#I1978|3.9(15)]] ::subtype [[Guide:95lrm/RM-3-10#I2082|3.10(14/1)]] ::subtype [[Guide:95lrm/RM-K#I7107|K(35)]] :unconstrained_array_definition [[Guide:95lrm/RM-3-6#I1766|3.6(3)]] ::''used'' [[Guide:95lrm/RM-3-6#I1764|3.6(2)]], [[Guide:95lrm/RM-P#I7415|P]] :undefined result [[Guide:95lrm/RM-11-6#I3954|11.6(5)]] :underline [[Guide:95lrm/RM-2-1#I1161|2.1(15)]] ::''used'' [[Guide:95lrm/RM-2-3#I1177|2.3(2)]], [[Guide:95lrm/RM-2-4-1#I1196|2.4.1(3)]], [[Guide:95lrm/RM-2-4-2#I1220|2.4.2(4)]], [[Guide:95lrm/RM-P#I7298|P]] :Uniformly_Distributed ::''in'' Ada.Numerics.Float_Random [[Guide:95lrm/RM-A-5-2#I5341|A.5.2(8)]] :uninitialized allocator [[Guide:95lrm/RM-4-8#I2725|4.8(4)]] :uninitialized variables [[Guide:95lrm/RM-13-9-1#I4378|13.9.1(2)]] ::[''partial''] [[Guide:95lrm/RM-3-3-1#I1436|3.3.1(21)]] :unit consistency [[Guide:95lrm/RM-E-3#I6760|E.3(6)]] :universal type [[Guide:95lrm/RM-3-4-1#I1479|3.4.1(6)]] :universal_fixed ::[''partial''] [[Guide:95lrm/RM-3-5-6#I1670|3.5.6(4)]] :universal_integer [[Guide:95lrm/RM-3-5-4#I1651|3.5.4(30)]] ::[''partial''] [[Guide:95lrm/RM-3-5-4#I1631|3.5.4(14)]] :universal_real ::[''partial''] [[Guide:95lrm/RM-3-5-6#I1668|3.5.6(4)]] :unknown discriminants [[Guide:95lrm/RM-3-7#I1866|3.7(26)]] :unknown_discriminant_part [[Guide:95lrm/RM-3-7#I1841|3.7(3)]] ::''used'' [[Guide:95lrm/RM-3-7#I1839|3.7(2)]], [[Guide:95lrm/RM-P#I7431|P]] :unmarshalling [[Guide:95lrm/RM-E-4#I6768|E.4(9)]] :unpolluted [[Guide:95lrm/RM-13-13-1#I4475|13.13.1(2)]] :unsigned ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6110|B.3(9)]] ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6273|B.4(23)]] :unsigned type ::''See'' modular type [[Guide:95lrm/RM-3-5-4#I1605|3.5.4(1)]] :unsigned_char ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6116|B.3(10)]] :unsigned_long ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6114|B.3(9)]] :unsigned_short ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6112|B.3(9)]] :unspecified [[Guide:95lrm/RM-1-1-3#I1055|1.1.3(18)]] ::[''partial''] [[Guide:95lrm/RM-2-1#I1124|2.1(5)]], [[Guide:95lrm/RM-4-5-2#I2525|4.5.2(13)]], [[Guide:95lrm/RM-4-5-2#I2528|4.5.2(24.1/1)]], [[Guide:95lrm/RM-4-5-5#I2580|4.5.5(21)]], [[Guide:95lrm/RM-6-2#I2943|6.2(11)]], [[Guide:95lrm/RM-7-2#I3076|7.2(5)]], [[Guide:95lrm/RM-9-8#I3645|9.8(14)]], [[Guide:95lrm/RM-10-2#I3795|10.2(26)]], [[Guide:95lrm/RM-11-1#I3849|11.1(6)]], [[Guide:95lrm/RM-11-5#I3943|11.5(27)]], [[Guide:95lrm/RM-13-1#I4147|13.1(18)]], [[Guide:95lrm/RM-13-7-2#I4356|13.7.2(5)]], [[Guide:95lrm/RM-13-9-1#I4382|13.9.1(7)]], [[Guide:95lrm/RM-13-11#I4430|13.11(20)]], [[Guide:95lrm/RM-A-1#I4545|A.1(1)]], [[Guide:95lrm/RM-A-5-1#I5333|A.5.1(34)]], [[Guide:95lrm/RM-A-5-2#I5381|A.5.2(28)]], [[Guide:95lrm/RM-A-5-2#I5382|A.5.2(34)]], [[Guide:95lrm/RM-A-7#I5492|A.7(6)]], [[Guide:95lrm/RM-A-10#I5612|A.10(8)]], [[Guide:95lrm/RM-A-10-7#I5893|A.10.7(8/1)]], [[Guide:95lrm/RM-A-10-7#I5894|A.10.7(12)]], [[Guide:95lrm/RM-A-10-7#I5895|A.10.7(19)]], [[Guide:95lrm/RM-A-14#I6004|A.14(1)]], [[Guide:95lrm/RM-D-2-2#I6551|D.2.2(6)]], [[Guide:95lrm/RM-D-8#I6649|D.8(19)]], [[Guide:95lrm/RM-E-3#I6758|E.3(5/1)]], [[Guide:95lrm/RM-G-1-1#I6917|G.1.1(40)]], [[Guide:95lrm/RM-G-1-2#I6969|G.1.2(33)]], [[Guide:95lrm/RM-G-1-2#I6971|G.1.2(48)]], [[Guide:95lrm/RM-H#I7038|H(4.1)]], [[Guide:95lrm/RM-H-2#I7045|H.2(1)]] :update ::the value of an object [[Guide:95lrm/RM-3-3#I1392|3.3(14)]] ::''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6201|B.3.1(18)]], [[Guide:95lrm/RM-B-3-1#I6203|B.3.1(19)]] :Update_Error ::''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6205|B.3.1(20)]] :upper bound ::of a range [[Guide:95lrm/RM-3-5#I1500|3.5(4)]] :upper-case letter ::a category of Character [[Guide:95lrm/RM-A-3-2#I4640|A.3.2(26)]] :upper_case_identifier_letter [[Guide:95lrm/RM-2-1#I1126|2.1(8)]] :Upper_Case_Map ::''in'' Ada.Strings.Maps.Constants [[Guide:95lrm/RM-A-4-6#I5204|A.4.6(5)]] :Upper_Set ::''in'' Ada.Strings.Maps.Constants [[Guide:95lrm/RM-A-4-6#I5196|A.4.6(4)]] :US ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4681|A.3.3(6)]] :usage name [[Guide:95lrm/RM-3-1#I1290|3.1(10)]] :use-visible [[Guide:95lrm/RM-8-3#I3200|8.3(4)]], [[Guide:95lrm/RM-8-4#I3238|8.4(9)]] :use_clause [[Guide:95lrm/RM-8-4#I3227|8.4(2)]] ::''used'' [[Guide:95lrm/RM-3-11#I2136|3.11(4/1)]], [[Guide:95lrm/RM-10-1-2#I3722|10.1.2(3)]], [[Guide:95lrm/RM-12-1#I3976|12.1(5)]], [[Guide:95lrm/RM-P#I7876|P]] :Use_Error ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5592|A.8.4(18)]] ::''in'' Ada.IO_Exceptions [[Guide:95lrm/RM-A-13#I5996|A.13(4)]] ::''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5539|A.8.1(15)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5971|A.12.1(26)]] ::''in'' Ada.Text_IO [[Guide:95lrm/RM-A-10-1#I5886|A.10.1(85)]] :use_package_clause [[Guide:95lrm/RM-8-4#I3230|8.4(3)]] ::''used'' [[Guide:95lrm/RM-8-4#I3228|8.4(2)]], [[Guide:95lrm/RM-P#I7706|P]] :use_type_clause [[Guide:95lrm/RM-8-4#I3233|8.4(4)]] ::''used'' [[Guide:95lrm/RM-8-4#I3229|8.4(2)]], [[Guide:95lrm/RM-P#I7707|P]] :user-defined assignment [[Guide:95lrm/RM-7-6#I3118|7.6(1)]] :user-defined heap management [[Guide:95lrm/RM-13-11#I4397|13.11(1)]] :user-defined operator [[Guide:95lrm/RM-6-6#I3050|6.6(1)]] :user-defined storage management [[Guide:95lrm/RM-13-11#I4395|13.11(1)]] == V == :Val attribute [[Guide:95lrm/RM-3-5-5#I1656|3.5.5(5)]] :Valid ::''in'' Ada.Text_IO.Editing [[Guide:95lrm/RM-F-3-3#I6838|F.3.3(5)]], [[Guide:95lrm/RM-F-3-3#I6855|F.3.3(12)]] ::''in'' Interfaces.COBOL [[Guide:95lrm/RM-B-4#I6293|B.4(33)]], [[Guide:95lrm/RM-B-4#I6301|B.4(38)]], [[Guide:95lrm/RM-B-4#I6309|B.4(43)]] :Valid attribute [[Guide:95lrm/RM-13-9-2#I4391|13.9.2(3)]], [[Guide:95lrm/RM-H#I7040|H(6)]] :Value ::''in'' Ada.Numerics.Discrete_Random [[Guide:95lrm/RM-A-5-2#I5380|A.5.2(26)]] ::''in'' Ada.Numerics.Float_Random [[Guide:95lrm/RM-A-5-2#I5358|A.5.2(14)]] ::''in'' Ada.Strings.Maps [[Guide:95lrm/RM-A-4-2#I4928|A.4.2(21)]] ::''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5245|A.4.7(21)]] ::''in'' Ada.Task_Attributes [[Guide:95lrm/RM-C-7-2#I6496|C.7.2(4)]] ::''in'' Interfaces.C.Pointers [[Guide:95lrm/RM-B-3-2#I6216|B.3.2(6)]], [[Guide:95lrm/RM-B-3-2#I6218|B.3.2(7)]] ::''in'' Interfaces.C.Strings [[Guide:95lrm/RM-B-3-1#I6191|B.3.1(13)]], [[Guide:95lrm/RM-B-3-1#I6193|B.3.1(14)]], [[Guide:95lrm/RM-B-3-1#I6195|B.3.1(15)]], [[Guide:95lrm/RM-B-3-1#I6197|B.3.1(16)]] :Value attribute [[Guide:95lrm/RM-3-5#I1567|3.5(52)]] :value conversion [[Guide:95lrm/RM-4-6#I2621|4.6(5/1)]] :variable [[Guide:95lrm/RM-3-3#I1386|3.3(13)]] :variable object [[Guide:95lrm/RM-3-3#I1388|3.3(13)]] :variable view [[Guide:95lrm/RM-3-3#I1390|3.3(13)]] :variant [[Guide:95lrm/RM-3-8-1#I1928|3.8.1(3)]] ::''used'' [[Guide:95lrm/RM-3-8-1#I1927|3.8.1(2)]], [[Guide:95lrm/RM-P#I7460|P]] ::''See also'' tagged type [[Guide:95lrm/RM-3-9#I1948|3.9(1)]] :variant_part [[Guide:95lrm/RM-3-8-1#I1924|3.8.1(2)]] ::''used'' [[Guide:95lrm/RM-3-8#I1902|3.8(4)]], [[Guide:95lrm/RM-P#I7452|P]] :version ::of a compilation unit [[Guide:95lrm/RM-E-3#I6757|E.3(5/1)]] :Version attribute [[Guide:95lrm/RM-E-3#I6754|E.3(3)]] :vertical line [[Guide:95lrm/RM-2-1#I1162|2.1(15)]] :Vertical_Line ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4739|A.3.3(14)]] :view [[Guide:95lrm/RM-3-1#I1284|3.1(7)]], [[Guide:95lrm/RM-N#I7278|N(12)]] :view conversion [[Guide:95lrm/RM-4-6#I2619|4.6(5/1)]] :virtual function ::''See'' dispatching subprogram [[Guide:95lrm/RM-3-9-2#I2013|3.9.2(1)]] :Virtual_Length ::''in'' Interfaces.C.Pointers [[Guide:95lrm/RM-B-3-2#I6225|B.3.2(13)]] :visibility ::direct [[Guide:95lrm/RM-8-3#I3193|8.3(2)]], [[Guide:95lrm/RM-8-3#I3218|8.3(21)]] ::immediate [[Guide:95lrm/RM-8-3#I3197|8.3(4)]], [[Guide:95lrm/RM-8-3#I3219|8.3(21)]] ::use clause [[Guide:95lrm/RM-8-3#I3198|8.3(4)]], [[Guide:95lrm/RM-8-4#I3239|8.4(9)]] :visibility rules [[Guide:95lrm/RM-8-3#I3192|8.3(1)]] :visible [[Guide:95lrm/RM-8-3#I3196|8.3(2)]], [[Guide:95lrm/RM-8-3#I3210|8.3(14)]] ::within a use_clause in a context_clause [[Guide:95lrm/RM-10-1-6#I3770|10.1.6(3)]] ::within a pragma in a context_clause [[Guide:95lrm/RM-10-1-6#I3772|10.1.6(3)]] ::within a pragma that appears at the place of a compilation unit [[Guide:95lrm/RM-10-1-6#I3776|10.1.6(5)]] ::within a with_clause [[Guide:95lrm/RM-10-1-6#I3767|10.1.6(2)]] ::within the parent_unit_name of a library unit [[Guide:95lrm/RM-10-1-6#I3765|10.1.6(2)]] ::within the parent_unit_name of a subunit [[Guide:95lrm/RM-10-1-6#I3774|10.1.6(4)]] :visible part [[Guide:95lrm/RM-8-2#I3184|8.2(5)]] ::of a formal package [[Guide:95lrm/RM-12-7#I4114|12.7(10)]] ::of a generic unit [[Guide:95lrm/RM-8-2#I3188|8.2(8)]] ::of a package (other than a generic formal package) [[Guide:95lrm/RM-7-1#I3067|7.1(6)]] ::of a protected unit [[Guide:95lrm/RM-9-4#I3402|9.4(11)]] ::of a task unit [[Guide:95lrm/RM-9-1#I3344|9.1(9)]] ::of a view of a callable entity [[Guide:95lrm/RM-8-2#I3186|8.2(6)]] ::of a view of a composite type [[Guide:95lrm/RM-8-2#I3187|8.2(7)]] :volatile [[Guide:95lrm/RM-C-6#I6450|C.6(8)]] :Volatile pragma [[Guide:95lrm/RM-C-6#I6441|C.6(4)]], [[Guide:95lrm/RM-L#I7264|L(38)]] :Volatile_Components pragma [[Guide:95lrm/RM-C-6#I6447|C.6(6)]], [[Guide:95lrm/RM-L#I7267|L(39)]] :VT ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4661|A.3.3(5)]] :VTS ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4758|A.3.3(17)]] == W == :wchar_array ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6156|B.3(33)]] :wchar_t ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6149|B.3(30/1)]] :well-formed picture String :for edited output [[Guide:95lrm/RM-F-3-1#I6830|F.3.1(1)]] :Wide_Bounded ::''child of'' Ada.Strings [[Guide:95lrm/RM-A-4-7#I5209|A.4.7(1)]] :Wide_Constants ::''child of'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5255|A.4.7(28)]] :Wide_Fixed ::''child of'' Ada.Strings [[Guide:95lrm/RM-A-4-7#I5206|A.4.7(1)]] :Wide_Text_IO ::''child of'' Ada [[Guide:95lrm/RM-A-11#I5902|A.11(2)]] :Wide_Unbounded ::''child of'' Ada.Strings [[Guide:95lrm/RM-A-4-7#I5212|A.4.7(1)]] :Wide_Character [[Guide:95lrm/RM-3-5-2#I1593|3.5.2(3)]] ::''in'' Standard [[Guide:95lrm/RM-A-1#I4560|A.1(36)]] :Wide_Character_Mapping ::''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5243|A.4.7(20)]] :Wide_Character_Mapping_Function ::''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5254|A.4.7(26)]] :Wide_Character_Range ::''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5222|A.4.7(6)]] :Wide_Character_Ranges ::''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5224|A.4.7(7)]] :Wide_Character_Sequence ::''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5235|A.4.7(16)]] :Wide_Character_Set ::''in'' Ada.Strings.Wide_Maps [[Guide:95lrm/RM-A-4-7#I5219|A.4.7(4)]] :Wide_Image attribute [[Guide:95lrm/RM-3-5#I1545|3.5(28)]] :Wide_Maps ::''child of'' Ada.Strings [[Guide:95lrm/RM-A-4-7#I5215|A.4.7(3)]] :wide_nul ::''in'' Interfaces.C [[Guide:95lrm/RM-B-3#I6150|B.3(31/1)]] :Wide_Space ::''in'' Ada.Strings [[Guide:95lrm/RM-A-4-1#I4883|A.4.1(4)]] :Wide_String ::''in'' Standard [[Guide:95lrm/RM-A-1#I4565|A.1(41)]] :Wide_Value attribute [[Guide:95lrm/RM-3-5#I1555|3.5(40)]] :Wide_Width attribute [[Guide:95lrm/RM-3-5#I1551|3.5(38)]] :Width attribute [[Guide:95lrm/RM-3-5#I1553|3.5(39)]] :with_clause [[Guide:95lrm/RM-10-1-2#I3723|10.1.2(4)]] ::mentioned in [[Guide:95lrm/RM-10-1-2#I3728|10.1.2(6)]] ::''used'' [[Guide:95lrm/RM-10-1-2#I3721|10.1.2(3)]], [[Guide:95lrm/RM-P#I7844|P]] :within ::immediately [[Guide:95lrm/RM-8-1#I3177|8.1(13)]] :word [[Guide:95lrm/RM-13-3#I4194|13.3(8)]] :Word_Size ::''in'' System [[Guide:95lrm/RM-13-7#I4318|13.7(13)]] :Write ::''in'' Ada.Direct_IO [[Guide:95lrm/RM-A-8-4#I5578|A.8.4(13)]] ::''in'' Ada.Sequential_IO [[Guide:95lrm/RM-A-8-1#I5533|A.8.1(12)]] ::''in'' Ada.Storage_IO [[Guide:95lrm/RM-A-9#I5604|A.9(7)]] ::''in'' Ada.Streams [[Guide:95lrm/RM-13-13-1#I4488|13.13.1(6)]] ::''in'' Ada.Streams.Stream_IO [[Guide:95lrm/RM-A-12-1#I5955|A.12.1(18)]], [[Guide:95lrm/RM-A-12-1#I5957|A.12.1(19)]] ::''in'' System.RPC [[Guide:95lrm/RM-E-5#I6802|E.5(8)]] :Write attribute [[Guide:95lrm/RM-13-13-2#I4490|13.13.2(3)]], [[Guide:95lrm/RM-13-13-2#I4494|13.13.2(11)]] :Write clause [[Guide:95lrm/RM-13-3#I4188|13.3(7)]], [[Guide:95lrm/RM-13-13-2#I4514|13.13.2(36/1)]] == X == :xor operator [[Guide:95lrm/RM-4-4#I2339|4.4(1)]], [[Guide:95lrm/RM-4-5-1#I2479|4.5.1(2)]] == Y == :Year ::''in'' Ada.Calendar [[Guide:95lrm/RM-9-6#I3549|9.6(13)]] :Year_Number ::''in'' Ada.Calendar [[Guide:95lrm/RM-9-6#I3542|9.6(11)]] :Yen_Sign ::''in'' Ada.Characters.Latin_1 [[Guide:95lrm/RM-A-3-3#I4786|A.3.3(21)]] </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-P|Previous]] | [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} mgbrl1c9z20ro26k2feops8rugw5t0a Guide:95lrm/RM-0-3 4200 859 3586 3585 2019-05-04T23:35:07Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-0-2|Previous]] | [[Guide:95lrm/RM-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Introduction}} This is the Ada Reference Manual. Other available Ada documents include: * Rationale for the Ada Programming Language -- 1995 edition, which gives an introduction to the new features of Ada, and explains the rationale behind them. Programmers should read this first. * ''This paragraph was deleted.'' * The Annotated Ada Reference Manual (AARM).<span id="I1001"></span> <span id="I1002"></span>The AARM contains all of the text in the RM95, plus various annotations. It is intended primarily for compiler writers, validation test writers, and others who wish to study the fine details. The annotations include detailed rationale for individual rules and explanations of some of the more arcane interactions among the rules. == Design Goals == Ada was originally designed with three overriding concerns: program reliability and maintenance, programming as a human activity, and efficiency. This revision to the language was designed to provide greater flexibility and extensibility, additional control over storage management and synchronization, and standardized packages oriented toward supporting important application areas, while at the same time retaining the original emphasis on reliability, maintainability, and efficiency. The need for languages that promote reliability and simplify maintenance is well established. Hence emphasis was placed on program readability over ease of writing. For example, the rules of the language require that program variables be explicitly declared and that their type be specified. Since the type of a variable is invariant, compilers can ensure that operations on variables are compatible with the properties intended for objects of the type. Furthermore, error-prone notations have been avoided, and the syntax of the language avoids the use of encoded forms in favor of more English-like constructs. Finally, the language offers support for separate compilation of program units in a way that facilitates program development and maintenance, and which provides the same degree of checking between units as within a unit. Concern for the human programmer was also stressed during the design. Above all, an attempt was made to keep to a relatively small number of underlying concepts integrated in a consistent and systematic way while continuing to avoid the pitfalls of excessive involution. The design especially aims to provide language constructs that correspond intuitively to the normal expectations of users. Like many other human activities, the development of programs is becoming ever more decentralized and distributed. Consequently, the ability to assemble a program from independently produced software components continues to be a central idea in the design. The concepts of packages, of private types, and of generic units are directly related to this idea, which has ramifications in many other aspects of the language. An allied concern is the maintenance of programs to match changing requirements; type extension and the hierarchical library enable a program to be modified while minimizing disturbance to existing tested and trusted components. No language can avoid the problem of efficiency. Languages that require over-elaborate compilers, or that lead to the inefficient use of storage or execution time, force these inefficiencies on all machines and on all programs. Every construct of the language was examined in the light of present implementation techniques. Any proposed construct whose implementation was unclear or that required excessive machine resources was rejected. == Language Summary == An Ada program is composed of one or more program units. Program units may be subprograms (which define executable algorithms), packages (which define collections of entities), task units (which define concurrent computations), protected units (which define operations for the coordinated sharing of data between tasks), or generic units (which define parameterized forms of packages and subprograms). Each program unit normally consists of two parts: a specification, containing the information that must be visible to other units, and a body, containing the implementation details, which need not be visible to other units. Most program units can be compiled separately. This distinction of the specification and body, and the ability to compile units separately, allows a program to be designed, written, and tested as a set of largely independent software components. An Ada program will normally make use of a library of program units of general utility. The language provides means whereby individual organizations can construct their own libraries. All libraries are structured in a hierarchical manner; this enables the logical decomposition of a subsystem into individual components. The text of a separately compiled program unit must name the library units it requires. ''Program Units'' A subprogram is the basic unit for expressing an algorithm. There are two kinds of subprograms: procedures and functions. A procedure is the means of invoking a series of actions. For example, it may read data, update variables, or produce some output. It may have parameters, to provide a controlled means of passing information between the procedure and the point of call. A function is the means of invoking the computation of a value. It is similar to a procedure, but in addition will return a result. A package is the basic unit for defining a collection of logically related entities. For example, a package can be used to define a set of type declarations and associated operations. Portions of a package can be hidden from the user, thus allowing access only to the logical properties expressed by the package specification. Subprogram and package units may be compiled separately and arranged in hierarchies of parent and child units giving fine control over visibility of the logical properties and their detailed implementation. A task unit is the basic unit for defining a task whose sequence of actions may be executed concurrently with those of other tasks. Such tasks may be implemented on multicomputers, multiprocessors, or with interleaved execution on a single processor. A task unit may define either a single executing task or a task type permitting the creation of any number of similar tasks. A protected unit is the basic unit for defining protected operations for the coordinated use of data shared between tasks. Simple mutual exclusion is provided automatically, and more elaborate sharing protocols can be defined. A protected operation can either be a subprogram or an entry. A protected entry specifies a Boolean expression (an entry barrier) that must be true before the body of the entry is executed. A protected unit may define a single protected object or a protected type permitting the creation of several similar objects. ''Declarations and Statements'' The body of a program unit generally contains two parts: a declarative part, which defines the logical entities to be used in the program unit, and a sequence of statements, which defines the execution of the program unit. The declarative part associates names with declared entities. For example, a name may denote a type, a constant, a variable, or an exception. A declarative part also introduces the names and parameters of other nested subprograms, packages, task units, protected units, and generic units to be used in the program unit. The sequence of statements describes a sequence of actions that are to be performed. The statements are executed in succession (unless a transfer of control causes execution to continue from another place). An assignment statement changes the value of a variable. A procedure call invokes execution of a procedure after associating any actual parameters provided at the call with the corresponding formal parameters. Case statements and if statements allow the selection of an enclosed sequence of statements based on the value of an expression or on the value of a condition. The loop statement provides the basic iterative mechanism in the language. A loop statement specifies that a sequence of statements is to be executed repeatedly as directed by an iteration scheme, or until an exit statement is encountered. A block statement comprises a sequence of statements preceded by the declaration of local entities used by the statements. Certain statements are associated with concurrent execution. A delay statement delays the execution of a task for a specified duration or until a specified time. An entry call statement is written as a procedure call statement; it requests an operation on a task or on a protected object, blocking the caller until the operation can be performed. A called task may accept an entry call by executing a corresponding accept statement, which specifies the actions then to be performed as part of the rendezvous with the calling task. An entry call on a protected object is processed when the corresponding entry barrier evaluates to true, whereupon the body of the entry is executed. The requeue statement permits the provision of a service as a number of related activities with preference control. One form of the select statement allows a selective wait for one of several alternative rendezvous. Other forms of the select statement allow conditional or timed entry calls and the asynchronous transfer of control in response to some triggering event. Execution of a program unit may encounter error situations in which normal program execution cannot continue. For example, an arithmetic computation may exceed the maximum allowed value of a number, or an attempt may be made to access an array component by using an incorrect index value. To deal with such error situations, the statements of a program unit can be textually followed by exception handlers that specify the actions to be taken when the error situation arises. Exceptions can be raised explicitly by a raise statement. ''Data Types'' Every object in the language has a type, which characterizes a set of values and a set of applicable operations. The main classes of types are elementary types (comprising enumeration, numeric, and access types) and composite types (including array and record types). An enumeration type defines an ordered set of distinct enumeration literals, for example a list of states or an alphabet of characters. The enumeration types Boolean, Character, and Wide_Character are predefined. Numeric types provide a means of performing exact or approximate numerical computations. Exact computations use integer types, which denote sets of consecutive integers. Approximate computations use either fixed point types, with absolute bounds on the error, or floating point types, with relative bounds on the error. The numeric types Integer, Float, and Duration are predefined. Composite types allow definitions of structured objects with related components. The composite types in the language include arrays and records. An array is an object with indexed components of the same type. A record is an object with named components of possibly different types. Task and protected types are also forms of composite types. The array types String and Wide_String are predefined. Record, task, and protected types may have special components called discriminants which parameterize the type. Variant record structures that depend on the values of discriminants can be defined within a record type. Access types allow the construction of linked data structures. A value of an access type represents a reference to an object declared as aliased or to an object created by the evaluation of an allocator. Several variables of an access type may designate the same object, and components of one object may designate the same or other objects. Both the elements in such linked data structures and their relation to other elements can be altered during program execution. Access types also permit references to subprograms to be stored, passed as parameters, and ultimately dereferenced as part of an indirect call. Private types permit restricted views of a type. A private type can be defined in a package so that only the logically necessary properties are made visible to the users of the type. The full structural details that are externally irrelevant are then only available within the package and any child units. From any type a new type may be defined by derivation. A type, together with its derivatives (both direct and indirect) form a derivation class. Class-wide operations may be defined that accept as a parameter an operand of any type in a derivation class. For record and private types, the derivatives may be extensions of the parent type. Types that support these object-oriented capabilities of class-wide operations and type extension must be tagged, so that the specific type of an operand within a derivation class can be identified at run time. When an operation of a tagged type is applied to an operand whose specific type is not known until run time, implicit dispatching is performed based on the tag of the operand. The concept of a type is further refined by the concept of a subtype, whereby a user can constrain the set of allowed values of a type. Subtypes can be used to define subranges of scalar types, arrays with a limited set of index values, and records and private types with particular discriminant values. ''Other Facilities'' Representation clauses can be used to specify the mapping between types and features of an underlying machine. For example, the user can specify that objects of a given type must be represented with a given number of bits, or that the components of a record are to be represented using a given storage layout. Other features allow the controlled use of low level, nonportable, or implementation-dependent aspects, including the direct insertion of machine code. The predefined environment of the language provides for input-output and other capabilities (such as string manipulation and random number generation) by means of standard library packages. Input-output is supported for values of user-defined as well as of predefined types. Standard means of representing values in display form are also provided. Other standard library packages are defined in annexes of the standard to support systems with specialized requirements. Finally, the language provides a powerful means of parameterization of program units, called generic program units. The generic parameters can be types and subprograms (as well as objects and packages) and so allow general algorithms and data structures to be defined that are applicable to all types of a given class. == Language Changes == This International Standard replaces the first edition of 1987. In this edition, the following major language changes have been incorporated: * Support for standard 8-bit and 16-bit character sets. See Section 2, [[Guide:95lrm/RM-3-5-2|3.5.2]], [[Guide:95lrm/RM-3-6-3|3.6.3]], [[Guide:95lrm/RM-A-1|A.1]], [[Guide:95lrm/RM-A-3|A.3]], and [[Guide:95lrm/RM-A-4|A.4]]. * Object-oriented programming with run-time polymorphism. See the discussions of classes, derived types, tagged types, record extensions, and private extensions in clauses [[Guide:95lrm/RM-3-4|3.4]], [[Guide:95lrm/RM-3-9|3.9]], and [[Guide:95lrm/RM-7-3|7.3]]. See also the new forms of generic formal parameters that are allowed by [[Guide:95lrm/RM-12-5-1|12.5.1]], ''[[Guide:95lrm/RM-12-5-1|Formal Private and Derived Types]]'' and [[Guide:95lrm/RM-12-7|12.7]], ''[[Guide:95lrm/RM-12-7|Formal Packages]]''. * Access types have been extended to allow an access value to designate a subprogram or an object declared by an object declaration (as opposed to just a heap-allocated object). See [[Guide:95lrm/RM-3-10|3.10]]. * Efficient data-oriented synchronization is provided via protected types. See Section 9. * The library units of a library may be organized into a hierarchy of parent and child units. See Section 10. * Additional support has been added for interfacing to other languages. See [[Guide:95lrm/RM-B|Annex B]]. * The Specialized Needs Annexes have been added to provide specific support for certain application areas: <p><span></span></p> :* [[Guide:95lrm/RM-C|Annex C]], ''[[Guide:95lrm/RM-C|Systems Programming]]'' <p><span></span></p> :* [[Guide:95lrm/RM-D|Annex D]], ''[[Guide:95lrm/RM-D|Real-Time Systems]]'' <p><span></span></p> :* [[Guide:95lrm/RM-E|Annex E]], ''[[Guide:95lrm/RM-E|Distributed Systems]]'' <p><span></span></p> :* [[Guide:95lrm/RM-F|Annex F]], ''[[Guide:95lrm/RM-F|Information Systems]]'' <p><span></span></p> :* [[Guide:95lrm/RM-G|Annex G]], ''[[Guide:95lrm/RM-G|Numerics]]'' <p><span></span></p> :* [[Guide:95lrm/RM-H|Annex H]], ''[[Guide:95lrm/RM-H|Safety and Security]]'' == Instructions for Comment Submission == <span id="I1003"></span><span id="I1004"></span>Informal comments on this International Standard may be sent via e-mail to '''ada-comment@ada-auth.org'''. If appropriate, the Project Editor will initiate the defect correction procedure. Comments should use the following format: <p><span></span></p> '''!topic''' ''Title summarizing comment'' '''!reference''' RM95-''ss.ss(pp)'' '''!from''' ''Author Name yy-mm-dd'' '''!keywords''' ''keywords related to topic'' '''!discussion'''<br><br> ''text of discussion'' where ''ss.ss'' is the section, clause or subclause number, ''pp'' is the paragraph number where applicable, and ''yy-mm-dd'' is the date the comment was sent. The date is optional, as is the '''!keywords''' line. Please use a descriptive ''Subject'' in your e-mail message, and limit each message to a single comment. When correcting typographical errors or making minor wording suggestions, please put the correction directly as the topic of the comment; use square brackets [ ] to indicate text to be omitted and curly braces { } to indicate text to be added, and provide enough context to make the nature of the suggestion self-evident or put additional information in the body of the comment, for example: <p><span></span></p> '''!topic''' [c]{C}haracter '''!topic''' it[']s meaning is not defined Formal requests for interpretations and for reporting defects in this International Standard may be made in accordance with the ISO/IEC JTC1 Directives and the ISO/IEC JTC1/SC22 policy for interpretations. National Bodies may submit a Defect Report to ISO/IEC JTC1/SC22 for resolution under the JTC1 procedures. A response will be provided and, if appropriate, a Technical Corrigendum will be issued in accordance with the procedures. == Acknowledgements == This International Standard was prepared by the Ada 9X Mapping/Revision Team based at Intermetrics, Inc., which has included: W. Carlson, Program Manager; T. Taft, Technical Director; J. Barnes (consultant); B. Brosgol (consultant); R. Duff (Oak Tree Software); M. Edwards; C. Garrity; R. Hilliard; O. Pazy (consultant); D. Rosenfeld; L. Shafer; W. White; M. Woodger. The following consultants to the Ada 9X Project contributed to the Specialized Needs Annexes: T. Baker (Real-Time/Systems Programming -- SEI, FSU); K. Dritz (Numerics -- Argonne National Laboratory); A. Gargaro (Distributed Systems -- Computer Sciences); J. Goodenough (Real-Time/Systems Programming -- SEI); J. McHugh (Secure Systems -- consultant); B. Wichmann (Safety-Critical Systems -- NPL: UK). This work was regularly reviewed by the Ada 9X Distinguished Reviewers and the members of the Ada 9X Rapporteur Group (XRG): E. Ploedereder, Chairman of DRs and XRG (University of Stuttgart: Germany); B. Bardin (Hughes); J. Barnes (consultant: UK); B. Brett (DEC); B. Brosgol (consultant); R. Brukardt (RR Software); N. Cohen (IBM); R. Dewar (NYU); G. Dismukes (TeleSoft); A. Evans (consultant); A. Gargaro (Computer Sciences); M. Gerhardt (ESL); J. Goodenough (SEI); S. Heilbrunner (University of Salzburg: Austria); P. Hilfinger (UC/Berkeley); B. Källberg (CelsiusTech: Sweden); M. Kamrad II (Unisys); J. van Katwijk (Delft University of Technology: The Netherlands); V. Kaufman (Russia); P. Kruchten (Rational); R. Landwehr (CCI: Germany); C. Lester (Portsmouth Polytechnic: UK); L. Månsson (TELIA Research: Sweden); S. Michell (Multiprocessor Toolsmiths: Canada); M. Mills (US Air Force); D. Pogge (US Navy); K. Power (Boeing); O. Roubine (Verdix: France); A. Strohmeier (Swiss Fed Inst of Technology: Switzerland); W. Taylor (consultant: UK); J. Tokar (Tartan); E. Vasilescu (Grumman); J. Vladik (Prospeks s.r.o.: Czech Republic); S. Van Vlierberghe (OFFIS: Belgium). Other valuable feedback influencing the revision process was provided by the Ada 9X Language Precision Team (Odyssey Research Associates), the Ada 9X User/Implementer Teams (AETECH, Tartan, TeleSoft), the Ada 9X Implementation Analysis Team (New York University) and the Ada community-at-large. Special thanks go to R. Mathis, Convenor of ISO/IEC JTC1/SC22 Working Group 9. The Ada 9X Project was sponsored by the Ada Joint Program Office. Christine M. Anderson at the Air Force Phillips Laboratory (Kirtland AFB, NM) was the project manager. == Changes == The International Standard is the same as this version of the Reference Manual, except: * This list of Changes is not included in the International Standard. * The ''Acknowledgements'' page is not included in the International Standard. * The text in the running headers and footers on each page is slightly different in the International Standard. * The title page(s) are different in the International Standard. * This document is formatted for 8.5-by-11-inch paper, whereas the International Standard is formatted for A4 paper (210-by-297mm); thus, the page breaks are in different places. * The ''Foreword to this version of the Ada Reference Manual'' clause is not included in the International Standard. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-0-9|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} t0opjozsrjpkwvlktf5do4btv9bc9w4 Guide:95lrm/RM-0-9 4200 860 3588 3587 2019-05-04T23:35:07Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-SRCH|Search]] '''INTERNATIONAL STANDARD ISO/IEC 8652:1995(E) with COR.1:2000''' '''Information technology -- Programming''' '''Languages -- Ada''' </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-0-2|Previous]] | [[Guide:95lrm/RM-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} trz2kmgcren052jakmggij1yztrvpeo Guide:95lrm/RM-1 4200 861 3590 3589 2019-05-04T23:35:07Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-0-3|Previous]] | [[Guide:95lrm/RM-1-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Section 1: General}} 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. 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. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-0-3|Previous]] | [[Guide:95lrm/RM-1-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} e45yefv8ycy0bk04402mv11wiv2jyb6 Guide:95lrm/RM-1-1 4200 862 3592 3591 2019-05-04T23:35:07Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-1|Previous]] | [[Guide:95lrm/RM-1-1-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 1.1 Scope}} 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. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-1|Previous]] | [[Guide:95lrm/RM-1-1-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} p8q19bfyddgw0lo2ndpftnanarx6une Guide:95lrm/RM-1-1-1 4200 863 3594 3593 2019-05-04T23:35:07Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-1-1|Previous]] | [[Guide:95lrm/RM-1-1-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 1.1.1 Extent}} This International Standard specifies: * The form of a program written in Ada; * The effect of translating and executing such a program; * The manner in which program units may be combined to form Ada programs; * The language-defined library units that a conforming implementation is required to supply; * The permissible variations within the standard, and the manner in which they are to be documented; * 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; * Those violations of the standard that a conforming implementation is not required to detect. This International Standard does not specify: * The means whereby a program written in Ada is transformed into object code executable by a processor; * The means whereby translation or execution of programs is invoked and the executing units are controlled; * The size or speed of the object code, or the relative execution speed of different language constructs; * The form or contents of any listings produced by implementations; in particular, the form or contents of error or warning messages; * The effect of unspecified execution. * The size of a program or program unit that will exceed the capacity of a particular conforming implementation. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-1-1|Previous]] | [[Guide:95lrm/RM-1-1-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} h2n5sk206q5uj73n72twvpdc80ghf9h Guide:95lrm/RM-1-1-2 4200 864 3596 3595 2019-05-04T23:35:07Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-1-1-1|Previous]] | [[Guide:95lrm/RM-1-1-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 1.1.2 Structure}} This International Standard contains thirteen sections, fourteen annexes, and an index. <span id="I1005"></span>The ''core'' of the Ada language consists of: * Sections 1 through 13 * [[Guide:95lrm/RM-A|Annex A]], ''[[Guide:95lrm/RM-A|Predefined Language Environment]]'' * [[Guide:95lrm/RM-B|Annex B]], ''[[Guide:95lrm/RM-B|Interface to Other Languages]]'' * [[Guide:95lrm/RM-J|Annex J]], ''[[Guide:95lrm/RM-J|Obsolescent Features]]'' <span id="I1006"></span><span id="I1007"></span><span id="I1008"></span>The following ''Specialized Needs Annexes'' define features that are needed by certain application areas: * [[Guide:95lrm/RM-C|Annex C]], ''[[Guide:95lrm/RM-C|Systems Programming]]'' * [[Guide:95lrm/RM-D|Annex D]], ''[[Guide:95lrm/RM-D|Real-Time Systems]]'' * [[Guide:95lrm/RM-E|Annex E]], ''[[Guide:95lrm/RM-E|Distributed Systems]]'' * [[Guide:95lrm/RM-F|Annex F]], ''[[Guide:95lrm/RM-F|Information Systems]]'' * [[Guide:95lrm/RM-G|Annex G]], ''[[Guide:95lrm/RM-G|Numerics]]'' * [[Guide:95lrm/RM-H|Annex H]], ''[[Guide:95lrm/RM-H|Safety and Security]]'' <span id="I1009"></span><span id="I1010"></span>The core language and the Specialized Needs Annexes are normative, except that the material in each of the items listed below is informative: * Text under a NOTES or Examples heading. * Each clause or subclause whose title starts with the word ''Example'' or ''Examples''. All implementations shall conform to the core language. In addition, an implementation may conform separately to one or more Specialized Needs Annexes. <span id="I1011"></span><span id="I1012"></span><span id="I1013"></span>The following Annexes are informative: * [[Guide:95lrm/RM-K|Annex K]], ''[[Guide:95lrm/RM-K|Language-Defined Attributes]]'' * [[Guide:95lrm/RM-L|Annex L]], ''[[Guide:95lrm/RM-L|Language-Defined Pragmas]]'' * [[Guide:95lrm/RM-M|Annex M]], ''[[Guide:95lrm/RM-M|Implementation-Defined Characteristics]]'' * [[Guide:95lrm/RM-N|Annex N]], ''[[Guide:95lrm/RM-N|Glossary]]'' * [[Guide:95lrm/RM-P|Annex P]], ''[[Guide:95lrm/RM-P|Syntax Summary]]'' 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 == <span id="I1014"></span><span id="I1015"></span><span id="I1016"></span><span id="I1017"></span><span id="I1018"></span>Syntax rules (indented). == Name Resolution Rules == <span id="I1019"></span><span id="I1020"></span><span id="I1021"></span>Compile-time rules that are used in name resolution, including overload resolution. == Legality Rules == <span id="I1022"></span><span id="I1023"></span><span id="I1024"></span>Rules that are enforced at compile time. <span id="I1025"></span><span id="I1026"></span>A construct is ''legal'' if it obeys all of the Legality Rules. == Static Semantics == <span id="I1027"></span><span id="I1028"></span>A definition of the compile-time effect of each construct. == Post-Compilation Rules == <span id="I1029"></span><span id="I1030"></span><span id="I1031"></span><span id="I1032"></span>Rules that are enforced before running a partition. <span id="I1033"></span><span id="I1034"></span>A partition is legal if its compilation units are legal and it obeys all of the Post-Compilation Rules. == Dynamic Semantics == <span id="I1035"></span><span id="I1036"></span><span id="I1037"></span><span id="I1038"></span>A definition of the run-time effect of each construct. == Bounded (Run-Time) Errors == <span id="I1039"></span><span id="I1040"></span>Situations that result in bounded (run-time) errors (see [[Guide:95lrm/RM-1-1-5|1.1.5]]). == Erroneous Execution == <span id="I1041"></span><span id="I1042"></span>Situations that result in erroneous execution (see [[Guide:95lrm/RM-1-1-5|1.1.5]]). == Implementation Requirements == <span id="I1043"></span>Additional requirements for conforming implementations. == Documentation Requirements == <span id="I1044"></span>Documentation requirements for conforming implementations. == Metrics == <span id="I1045"></span>Metrics that are specified for the time/space properties of the execution of certain language constructs. == Implementation Permissions == <span id="I1046"></span>Additional permissions given to the implementer. == Implementation Advice == <span id="I1047"></span><span id="I1048"></span>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 == 1  <span id="I1049"></span>Notes emphasize consequences of the rules described in the (sub)clause or elsewhere. This material is informative. == Examples == Examples illustrate the possible forms of the constructs described. This material is informative. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-1-1-1|Previous]] | [[Guide:95lrm/RM-1-1-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 1nl45pv5v4odyuejx3bp125g690nt7l Guide:95lrm/RM-1-1-3 4200 865 3598 3597 2019-05-04T23:35:07Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-1-1-2|Previous]] | [[Guide:95lrm/RM-1-1-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 1.1.3 Conformity of an Implementation with the Standard}} == Implementation Requirements == <span id="I1050"></span>A conforming implementation shall: * Translate and correctly execute legal programs written in Ada, provided that they are not so large as to exceed the capacity of the implementation; * 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); * Identify all programs or program units that contain errors whose detection is required by this International Standard; * Supply all language-defined library units required by this International Standard; * 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; * Specify all such variations in the manner prescribed by this International Standard. <span id="I1051"></span><span id="I1052"></span>The ''external effect'' of the execution of an Ada program is defined in terms of its interactions with its external environment. <span id="I1053"></span>The following are defined as ''external interactions'': * Any interaction with an external file (see [[Guide:95lrm/RM-A-7|A.7]]); * The execution of certain code_statements (see [[Guide:95lrm/RM-13-8|13.8]]); which code_statements cause external interactions is implementation defined. * Any call on an imported subprogram (see [[Guide:95lrm/RM-B|Annex B]]), including any parameters passed to it; * Any result returned or exception propagated from a main subprogram (see [[Guide:95lrm/RM-10-2|10.2]]) or an exported subprogram (see [[Guide:95lrm/RM-B|Annex B]]) to an external caller; * Any read or update of an atomic or volatile object (see [[Guide:95lrm/RM-C-6|C.6]]); * The values of imported and exported objects (see [[Guide:95lrm/RM-B|Annex B]]) at the time of any other interaction with the external environment. 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. 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. 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 == <span id="I1054"></span><span id="I1055"></span><span id="I1056"></span><span id="I1057"></span><span id="I1058"></span>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 [[Guide:95lrm/RM-M|Annex M]]. 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 == <span id="I1059"></span>If an implementation detects the use of an unsupported Specialized Needs Annex feature at run time, it should raise Program_Error if feasible. 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 == 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. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-1-1-2|Previous]] | [[Guide:95lrm/RM-1-1-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} t02ilumklujnopdmg5axxrhmdcjdkky Guide:95lrm/RM-1-1-4 4200 866 3600 3599 2019-05-04T23:35:08Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-1-1-3|Previous]] | [[Guide:95lrm/RM-1-1-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 1.1.4 Method of Description and Syntax Notation}} The form of an Ada program is described by means of a context-free syntax together with context-dependent requirements expressed by narrative rules. 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. <span id="I1060"></span><span id="I1061"></span><span id="I1062"></span><span id="I1063"></span><span id="I1064"></span>The context-free syntax of the language is described using a simple variant of Backus-Naur Form. In particular: * Lower case words in a sans-serif font, some containing embedded underlines, are used to denote syntactic categories, for example: <p><span></span></p> case_statement * Boldface words are used to denote reserved words, for example: <p><span></span></p> '''array''' * Square brackets enclose optional items. Thus the two following rules are equivalent. <p><span></span></p> return_statement ::= '''return''' [expression]; return_statement ::= '''return'''; | '''return''' expression; * 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. <p><span></span></p> term ::= factor {multiplying_operator factor} term ::= factor | term multiplying_operator factor * A vertical line separates alternative items unless it occurs immediately after an opening curly bracket, in which case it stands for itself: <p><span></span></p> constraint ::= scalar_constraint | composite_constraint discrete_choice_list ::= discrete_choice {| discrete_choice} * <span id="I1065"></span>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. <span id="I1066"></span>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. <span id="I1067"></span>A ''construct'' is a piece of text (explicit or implicit) that is an instance of a syntactic category defined under ''Syntax.'' <span id="I1068"></span>A ''constituent'' of a construct is the construct itself, or any construct appearing within it. <span id="I1069"></span>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. <span id="I1070"></span><span id="I1071"></span>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 == 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: <p><syntaxhighlight lang="Ada"> if_statement ::=   if condition then sequence_of_statements {elsif condition then    sequence_of_statements} [else    sequence_of_statements]  end if;</syntaxhighlight></p> 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. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-1-1-3|Previous]] | [[Guide:95lrm/RM-1-1-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} tl8grtb30zbnnmtf840ved7ug2k0hof Guide:95lrm/RM-1-1-5 4200 867 3602 3601 2019-05-04T23:35:08Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-1-1-4|Previous]] | [[Guide:95lrm/RM-1-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 1.1.5 Classification of Errors}} == Implementation Requirements == The language definition classifies errors into several different categories: * Errors that are required to be detected prior to run time by every Ada implementation; <p><span></span></p> ::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. <p><span></span></p> ::<span id="I1072"></span><span id="I1073"></span><span id="I1074"></span><span id="I1075"></span>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. * Errors that are required to be detected at run time by the execution of an Ada program; <p><span></span></p> ::<span id="I1076"></span><span id="I1077"></span>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. * Bounded errors; <p><span></span></p> ::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. <span id="I1078"></span>The errors of this category are called ''bounded errors''. <span id="I1079"></span>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. * Erroneous execution. <p><span></span></p> ::<span id="I1080"></span>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 == <span id="I1081"></span><span id="I1082"></span>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. <span id="I1083"></span><span id="I1084"></span>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 == <span id="I1085"></span>If an implementation detects a bounded error or erroneous execution, it should raise Program_Error. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-1-1-4|Previous]] | [[Guide:95lrm/RM-1-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 5i8t2f2aprlfgvzki5iz57qcbn2xd9z Guide:95lrm/RM-1-2 4200 868 3604 3603 2019-05-04T23:35:08Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-1-1-5|Previous]] | [[Guide:95lrm/RM-1-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 1.2 Normative References}} <span id="I1086"></span><span id="I1087"></span>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. <span id="I1088"></span><span id="I1089"></span><span id="I1090"></span>ISO/IEC 646:1991, ''Information technology -- ISO 7-bit coded character set for information interchange.'' <span id="I1091"></span><span id="I1092"></span><span id="I1093"></span>ISO/IEC 1539:1991, ''Information technology -- Programming languages -- FORTRAN.'' <span id="I1094"></span><span id="I1095"></span><span id="I1096"></span>ISO 1989:1985, ''Programming languages -- COBOL.'' <span id="I1097"></span><span id="I1098"></span><span id="I1099"></span>ISO/IEC 6429:1992, ''Information technology -- Control functions for coded graphic character sets.'' <span id="I1100"></span><span id="I1101"></span><span id="I1102"></span>ISO/IEC 8859-1:1987, ''Information processing -- 8-bit single-byte coded character sets -- Part 1: Latin alphabet No. 1.'' <span id="I1103"></span><span id="I1104"></span><span id="I1105"></span>ISO/IEC 9899:1990, ''Programming languages -- C.'' <span id="I1106"></span><span id="I1107"></span><span id="I1108"></span>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. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-1-1-5|Previous]] | [[Guide:95lrm/RM-1-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} fx1jtzzc5oo2220fngs1geax4bmgrnv Guide:95lrm/RM-1-3 4200 869 3606 3605 2019-05-04T23:35:08Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-1-2|Previous]] | [[Guide:95lrm/RM-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 1.3 Definitions}} <span id="I1109"></span>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 [[Guide:95lrm/RM-N|Annex N]], ''[[Guide:95lrm/RM-N|Glossary]]''. <span id="I1110"></span><span id="I1111"></span><span id="I1112"></span><span id="I1113"></span> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-1-2|Previous]] | [[Guide:95lrm/RM-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} rslm2tuhen2s47y44fi3q9aso0f3txu Guide:95lrm/RM-10 4200 870 3608 3607 2019-05-04T23:35:08Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-11|Previous]] | [[Guide:95lrm/RM-10-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Section 10: Program Structure and Compilation Issues}} The overall structure of programs and the facilities for separate compilation are described in this section. A ''program'' is a set of ''partitions'', each of which may execute in a separate address space, possibly on a separate computer. <span id="I3666"></span><span id="I3667"></span><span id="I3668"></span>As explained below, a partition is constructed from ''library units''. Syntactically, the declaration of a library unit is a library_item, as is the body of a library unit. An implementation may support a concept of a ''program library'' (or simply, a ''library''), which contains library_items and their subunits. <span id="I3669"></span>Library units may be organized into a hierarchy of children, grandchildren, and so on. This section has two clauses: [[Guide:95lrm/RM-10-1|10.1]], ''[[Guide:95lrm/RM-10-1|Separate Compilation]]'' discusses compile-time issues related to separate compilation. [[Guide:95lrm/RM-10-2|10.2]], ''[[Guide:95lrm/RM-10-2|Program Execution]]'' discusses issues related to what is traditionally known as ''link time'' and ''run time'' -- building and executing partitions. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-11|Previous]] | [[Guide:95lrm/RM-10-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} ikh2wo3jydnss3q9r6ow99n2ll15bpc Guide:95lrm/RM-10-1 4200 871 3610 3609 2019-05-04T23:35:08Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-10|Previous]] | [[Guide:95lrm/RM-10-1-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 10.1 Separate Compilation}} <span id="I3670"></span><span id="I3671"></span><span id="I3672"></span>A ''program unit'' is either a package, a task unit, a protected unit, a protected entry, a generic unit, or an explicitly declared subprogram other than an enumeration literal. Certain kinds of program units can be separately compiled. Alternatively, they can appear physically nested within other program units. <span id="I3673"></span>The text of a program can be submitted to the compiler in one or more compilations. Each compilation is a succession of compilation_units. A compilation_unit contains either the declaration, the body, or a renaming of a program unit. The representation for a compilation is implementation-defined. <span id="I3674"></span>A library unit is a separately compiled program unit, and is always a package, subprogram, or generic unit. Library units may have other (logically nested) library units as children, and may have other program units physically nested within them. <span id="I3675"></span>A root library unit, together with its children and grandchildren and so on, form a ''subsystem''. == Implementation Permissions == An implementation may impose implementation-defined restrictions on compilations that contain multiple compilation_units. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-10|Previous]] | [[Guide:95lrm/RM-10-1-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 7pfditizhvzjmvesg3sro3961ry3ey7 Guide:95lrm/RM-10-1-1 4200 872 3612 3611 2019-05-04T23:35:10Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-10-1|Previous]] | [[Guide:95lrm/RM-10-1-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 10.1.1 Compilation Units - Library Units}} A library_item is a compilation unit that is the declaration, body, or renaming of a library unit. Each library unit (except Standard) has a ''parent unit'', which is a library package or generic library package. <span id="I3676"></span>A library unit is a ''child'' of its parent unit. The ''root'' library units are the children of the predefined library package Standard. == Syntax == <p><span></span></p> compilation<span id="I3677"></span> ::= {<span id="I3678"></span>compilation_unit} <p><span></span></p> compilation_unit<span id="I3679"></span> ::= <span id="I3680"></span>context_clause <span id="I3681"></span>library_item | <span id="I3682"></span>context_clause <span id="I3683"></span>subunit <p><span></span></p> library_item<span id="I3684"></span> ::= ['''private'''] <span id="I3685"></span>library_unit_declaration | <span id="I3686"></span>library_unit_body | ['''private'''] <span id="I3687"></span>library_unit_renaming_declaration <p><span></span></p> library_unit_declaration<span id="I3688"></span> ::= <span id="I3689"></span>subprogram_declaration | <span id="I3690"></span>package_declaration | <span id="I3691"></span>generic_declaration | <span id="I3692"></span>generic_instantiation <p><span></span></p> library_unit_renaming_declaration<span id="I3693"></span> ::= <span id="I3694"></span>package_renaming_declaration | <span id="I3695"></span>generic_renaming_declaration | <span id="I3696"></span>subprogram_renaming_declaration <p><span></span></p> library_unit_body<span id="I3697"></span> ::= <span id="I3698"></span>subprogram_body | <span id="I3699"></span>package_body <p><span></span></p> parent_unit_name<span id="I3700"></span> ::= <span id="I3701"></span>name <span id="I3702"></span>A ''library unit'' is a program unit that is declared by a library_item. When a program unit is a library unit, the prefix ''library'' is used to refer to it (or ''generic library'' if generic), as well as to its declaration and body, as in ''library procedure'', ''library package_body'', or ''generic library package''. <span id="I3703"></span>The term ''compilation unit'' is used to refer to a compilation_unit. When the meaning is clear from context, the term is also used to refer to the library_item of a compilation_unit or to the proper_body of a subunit (that is, the compilation_unit without the context_clause and the '''separate''' (parent_unit_name)). <span id="I3704"></span><span id="I3705"></span>The ''parent declaration'' of a library_item (and of the library unit) is the declaration denoted by the parent_unit_name, if any, of the defining_program_unit_name of the library_item. <span id="I3706"></span>If there is no parent_unit_name, the parent declaration is the declaration of Standard, the library_item is a ''root'' library_item, and the library unit (renaming) is a ''root'' library unit (renaming). The declaration and body of Standard itself have no parent declaration. <span id="I3707"></span>The ''parent unit'' of a library_item or library unit is the library unit declared by its parent declaration. The children of a library unit occur immediately within the declarative region of the declaration of the library unit. <span id="I3708"></span>The ''ancestors'' of a library unit are itself, its parent, its parent's parent, and so on. (Standard is an ancestor of every library unit.) <span id="I3709"></span>The ''descendant'' relation is the inverse of the ancestor relation. <span id="I3710"></span><span id="I3711"></span><span id="I3712"></span><span id="I3713"></span>A library_unit_declaration or a library_unit_renaming_declaration is ''private'' if the declaration is immediately preceded by the reserved word '''private'''; it is otherwise ''public''. A library unit is private or public according to its declaration. <span id="I3714"></span>The ''public descendants'' of a library unit are the library unit itself, and the public descendants of its public children. <span id="I3715"></span>Its other descendants are ''private descendants''. == Legality Rules == The parent unit of a library_item shall be a library package or generic library package. If a defining_program_unit_name of a given declaration or body has a parent_unit_name, then the given declaration or body shall be a library_item. The body of a program unit shall be a library_item if and only if the declaration of the program unit is a library_item. In a library_unit_renaming_declaration, the (old) name shall denote a library_item. A parent_unit_name (which can be used within a defining_program_unit_name of a library_item and in the '''separate''' clause of a subunit), and each of its prefixes, shall not denote a renaming_declaration. On the other hand, a name that denotes a library_unit_renaming_declaration is allowed in a with_clause and other places where the name of a library unit is allowed. If a library package is an instance of a generic package, then every child of the library package shall either be itself an instance or be a renaming of a library unit. A child of a generic library package shall either be itself a generic unit or be a renaming of some other child of the same generic unit. The renaming of a child of a generic package shall occur only within the declarative region of the generic package. A child of a parent generic package shall be instantiated or renamed only within the declarative region of the parent generic. For each declaration or renaming of a generic unit as a child of some parent generic package, there is a corresponding declaration nested immediately within each instance of the parent. This declaration is visible only within the scope of a with_clause that mentions the child generic unit. A library subprogram shall not override a primitive subprogram. The defining name of a function that is a compilation unit shall not be an operator_symbol. == Static Semantics == A subprogram_renaming_declaration that is a library_unit_renaming_declaration is a renaming-as-declaration, not a renaming-as-body. There are two kinds of dependences among compilation units: * The ''semantic dependences'' (see below) are the ones needed to check the compile-time rules across compilation unit boundaries; a compilation unit depends semantically on the other compilation units needed to determine its legality. The visibility rules are based on the semantic dependences. * The ''elaboration dependences'' (see [[Guide:95lrm/RM-10-2|10.2]]) determine the order of elaboration of library_items. <span id="I3716"></span><span id="I3717"></span>A library_item depends semantically upon its parent declaration. A subunit depends semantically upon its parent body. A library_unit_body depends semantically upon the corresponding library_unit_declaration, if any. A compilation unit depends semantically upon each library_item mentioned in a with_clause of the compilation unit. In addition, if a given compilation unit contains an attribute_reference of a type defined in another compilation unit, then the given compilation unit depends semantically upon the other compilation unit. The semantic dependence relationship is transitive. == Notes == 1  A simple program may consist of a single compilation unit. A compilation need not have any compilation units; for example, its text can consist of pragmas. 2  The designator of a library function cannot be an operator_symbol, but a nonlibrary renaming_declaration is allowed to rename a library function as an operator. Within a partition, two library subprograms are required to have distinct names and hence cannot overload each other. However, renaming_declarations are allowed to define overloaded names for such subprograms, and a locally declared subprogram is allowed to overload a library subprogram. The expanded name Standard.L can be used to denote a root library unit L (unless the declaration of Standard is hidden) since root library unit declarations occur immediately within the declarative region of package Standard. == Examples == ''Examples of library units:'' <p><syntaxhighlight lang="Ada"> package Rational_Numbers.IO is  -- public child of Rational_Numbers, see 7.1 procedure Put(R : in  Rational); procedure Get(R : out Rational); end Rational_Numbers.IO;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> private procedure Rational_Numbers.Reduce(R : in out Rational);                              -- private child of Rational_Numbers</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> with Rational_Numbers.Reduce;   -- refer to a private child package body Rational_Numbers is ... end Rational_Numbers;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> with Rational_Numbers.IO; use Rational_Numbers; with Ada.Text_io;               -- see A.10 procedure Main is               -- a root library procedure R : Rational; begin R := 5/3;                    -- construct a rational number, see 7.1 Ada.Text_IO.Put("The answer is: "); IO.Put(R); Ada.Text_IO.New_Line; end Main;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> with Rational_Numbers.IO; package Rational_IO renames Rational_Numbers.IO;                              -- a library unit renaming declaration</syntaxhighlight></p> Each of the above library_items can be submitted to the compiler separately. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-10-1|Previous]] | [[Guide:95lrm/RM-10-1-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} p8kn2z6j76b5y8at5xxvh53faw54y3e Guide:95lrm/RM-10-1-2 4200 873 3614 3613 2019-05-04T23:35:11Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-10-1-1|Previous]] | [[Guide:95lrm/RM-10-1-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 10.1.2 Context Clauses - With Clauses}} A context_clause is used to specify the library_items whose names are needed within a compilation unit. == Syntax == <p><span></span></p> context_clause<span id="I3718"></span> ::= {<span id="I3719"></span>context_item} <p><span></span></p> context_item<span id="I3720"></span> ::= <span id="I3721"></span>with_clause | <span id="I3722"></span>use_clause <p><span></span></p> with_clause<span id="I3723"></span> ::= '''with''' ''library_unit_''<span id="I3724"></span>name {, ''library_unit_''<span id="I3725"></span>name}; == Name Resolution Rules == <span id="I3726"></span>The ''scope'' of a with_clause that appears on a library_unit_declaration or library_unit_renaming_declaration consists of the entire declarative region of the declaration, which includes all children and subunits. The scope of a with_clause that appears on a body consists of the body, which includes all subunits. <span id="I3727"></span><span id="I3728"></span>A library_item is ''mentioned'' in a with_clause if it is denoted by a ''library_unit_''name or a prefix in the with_clause. Outside its own declarative region, the declaration or renaming of a library unit can be visible only within the scope of a with_clause that mentions it. The visibility of the declaration or renaming of a library unit otherwise follows from its placement in the environment. == Legality Rules == If a with_clause of a given compilation_unit mentions a private child of some library unit, then the given compilation_unit shall be either the declaration of a private descendant of that library unit or the body or subunit of a (public or private) descendant of that library unit. == Notes == 3  A library_item mentioned in a with_clause of a compilation unit is visible within the compilation unit and hence acts just like an ordinary declaration. Thus, within a compilation unit that mentions its declaration, the name of a library package can be given in use_clauses and can be used to form expanded names, a library subprogram can be called, and instances of a generic library unit can be declared. If a child of a parent generic package is mentioned in a with_clause, then the corresponding declaration nested within each visible instance is visible within the compilation unit. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-10-1-1|Previous]] | [[Guide:95lrm/RM-10-1-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 58ltzvg6fa14ywxka62hwztopgdm39n Guide:95lrm/RM-10-1-3 4200 874 3616 3615 2019-05-04T23:35:12Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-10-1-2|Previous]] | [[Guide:95lrm/RM-10-1-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 10.1.3 Subunits of Compilation Units}} Subunits are like child units, with these (important) differences: subunits support the separate compilation of bodies only (not declarations); the parent contains a body_stub to indicate the existence and place of each of its subunits; declarations appearing in the parent's body can be visible within the subunits. == Syntax == <p><span></span></p> body_stub<span id="I3729"></span> ::= <span id="I3730"></span>subprogram_body_stub | <span id="I3731"></span>package_body_stub | <span id="I3732"></span>task_body_stub | <span id="I3733"></span>protected_body_stub <p><span></span></p> subprogram_body_stub<span id="I3734"></span> ::= <span id="I3735"></span>subprogram_specification '''is''' '''separate'''; <p><span></span></p> package_body_stub<span id="I3736"></span> ::= '''package''' '''body''' <span id="I3737"></span>defining_identifier '''is''' '''separate'''; <p><span></span></p> task_body_stub<span id="I3738"></span> ::= '''task''' '''body''' <span id="I3739"></span>defining_identifier '''is''' '''separate'''; <p><span></span></p> protected_body_stub<span id="I3740"></span> ::= '''protected''' '''body''' <span id="I3741"></span>defining_identifier '''is''' '''separate'''; <p><span></span></p> subunit<span id="I3742"></span> ::= '''separate''' (<span id="I3743"></span>parent_unit_name) <span id="I3744"></span>proper_body == Legality Rules == <span id="I3745"></span>The ''parent body'' of a subunit is the body of the program unit denoted by its parent_unit_name. <span id="I3746"></span> The term ''subunit'' is used to refer to a subunit and also to the proper_body of a subunit. The parent body of a subunit shall be present in the current environment, and shall contain a corresponding body_stub with the same defining_identifier as the subunit. A package_body_stub shall be the completion of a package_declaration or generic_package_declaration; a task_body_stub shall be the completion of a task_declaration; a protected_body_stub shall be the completion of a protected_declaration. In contrast, a subprogram_body_stub need not be the completion of a previous declaration, in which case the _stub declares the subprogram. If the _stub is a completion, it shall be the completion of a subprogram_declaration or generic_subprogram_declaration. The profile of a subprogram_body_stub that completes a declaration shall conform fully to that of the declaration. <span id="I3747"></span> A subunit that corresponds to a body_stub shall be of the same kind (package_, subprogram_, task_, or protected_) as the body_stub. The profile of a subprogram_body subunit shall be fully conformant to that of the corresponding body_stub. <span id="I3748"></span> A body_stub shall appear immediately within the declarative_part of a compilation unit body. This rule does not apply within an instance of a generic unit. The defining_identifiers of all body_stubs that appear immediately within a particular declarative_part shall be distinct. == Post-Compilation Rules == For each body_stub, there shall be a subunit containing the corresponding proper_body. == Notes == 4  The rules in [[Guide:95lrm/RM-10-1-4|10.1.4]], ''[[Guide:95lrm/RM-10-1-4|The Compilation Process]]'' say that a body_stub is equivalent to the corresponding proper_body. This implies: * Visibility within a subunit is the visibility that would be obtained at the place of the corresponding body_stub (within the parent body) if the context_clause of the subunit were appended to that of the parent body. * The effect of the elaboration of a body_stub is to elaborate the subunit. == Examples == The package Parent is first written without subunits: <p><syntaxhighlight lang="Ada"> package Parent is  procedure Inner; end Parent;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> with Ada.Text_IO; package body Parent is  Variable : String := "Hello, there.";  procedure Inner is  begin      Ada.Text_IO.Put_Line(Variable);  end Inner; end Parent;</syntaxhighlight></p> The body of procedure Inner may be turned into a subunit by rewriting the package body as follows (with the declaration of Parent remaining the same): <p><syntaxhighlight lang="Ada"> package body Parent is   Variable : String := "Hello, there.";  procedure Inner is separate; end Parent;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> with Ada.Text_IO; separate(Parent) procedure Inner is begin  Ada.Text_IO.Put_Line(Variable); end Inner;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-10-1-2|Previous]] | [[Guide:95lrm/RM-10-1-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 94rxxwchtg1jy5iuicuq0ak3tb2y1qo Guide:95lrm/RM-10-1-4 4200 875 3618 3617 2019-05-04T23:35:12Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-10-1-3|Previous]] | [[Guide:95lrm/RM-10-1-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 10.1.4 The Compilation Process}} <span id="I3749"></span><span id="I3750"></span>Each compilation unit submitted to the compiler is compiled in the context of an ''environment'' declarative_part (or simply, an ''environment''), which is a conceptual declarative_part that forms the outermost declarative region of the context of any compilation. At run time, an environment forms the declarative_part of the body of the environment task of a partition (see [[Guide:95lrm/RM-10-2|10.2]], ''[[Guide:95lrm/RM-10-2|Program Execution]]''). The declarative_items of the environment are library_items appearing in an order such that there are no forward semantic dependences. Each included subunit occurs in place of the corresponding stub. The visibility rules apply as if the environment were the outermost declarative region, except that with_clauses are needed to make declarations of library units visible (see [[Guide:95lrm/RM-10-1-2|10.1.2]]). The mechanisms for creating an environment and for adding and replacing compilation units within an environment are implementation defined. == Name Resolution Rules == If a library_unit_body that is a subprogram_body is submitted to the compiler, it is interpreted only as a completion if a library_unit_declaration with the same defining_program_unit_name already exists in the environment for a subprogram other than an instance of a generic subprogram or for a generic subprogram (even if the profile of the body is not type conformant with that of the declaration); otherwise the subprogram_body is interpreted as both the declaration and body of a library subprogram. <span id="I3751"></span> == Legality Rules == When a compilation unit is compiled, all compilation units upon which it depends semantically shall already exist in the environment; <span id="I3752"></span>the set of these compilation units shall be ''consistent'' in the sense that the new compilation unit shall not semantically depend (directly or indirectly) on two different versions of the same compilation unit, nor on an earlier version of itself. == Implementation Permissions == The implementation may require that a compilation unit be legal before inserting it into the environment. When a compilation unit that declares or renames a library unit is added to the environment, the implementation may remove from the environment any preexisting library_item with the same defining_program_unit_name. When a compilation unit that is a subunit or the body of a library unit is added to the environment, the implementation may remove from the environment any preexisting version of the same compilation unit. When a given compilation unit is removed from the environment, the implementation may also remove any compilation unit that depends semantically upon the given one. If the given compilation unit contains the body of a subprogram to which a pragma Inline applies, the implementation may also remove any compilation unit containing a call to that subprogram. == Notes == 5  The rules of the language are enforced across compilation and compilation unit boundaries, just as they are enforced within a single compilation unit. 6  <span id="I3753"></span>An implementation may support a concept of a ''library'', which contains library_items. If multiple libraries are supported, the implementation has to define how a single environment is constructed when a compilation unit is submitted to the compiler. Naming conflicts between different libraries might be resolved by treating each library as the root of a hierarchy of child library units. <span id="I3754"></span> 7  A compilation unit containing an instantiation of a separately compiled generic unit does not semantically depend on the body of the generic unit. Therefore, replacing the generic body in the environment does not result in the removal of the compilation unit containing the instantiation. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-10-1-3|Previous]] | [[Guide:95lrm/RM-10-1-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} ioyh8oxf8vhcf1llo3nefx8qi5svuyj Guide:95lrm/RM-10-1-5 4200 876 3620 3619 2019-05-04T23:35:12Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-10-1-4|Previous]] | [[Guide:95lrm/RM-10-1-6|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 10.1.5 Pragmas and Program Units}} This subclause discusses pragmas related to program units, library units, and compilations. == Name Resolution Rules == <span id="I3755"></span><span id="I3756"></span>Certain pragmas are defined to be ''program unit pragmas''. <span id="I3757"></span>A name given as the argument of a program unit pragma shall resolve to denote the declarations or renamings of one or more program units that occur immediately within the declarative region or compilation in which the pragma immediately occurs, or it shall resolve to denote the declaration of the immediately enclosing program unit (if any); the pragma applies to the denoted program unit(s). If there are no names given as arguments, the pragma applies to the immediately enclosing program unit. == Legality Rules == A program unit pragma shall appear in one of these places: * At the place of a compilation_unit, in which case the pragma shall immediately follow in the same compilation (except for other pragmas) a library_unit_declaration that is a subprogram_declaration, generic_subprogram_declaration, or generic_instantiation, and the pragma shall have an argument that is a name denoting that declaration. * Immediately within the declaration of a program unit and before any nested declaration (but not within a generic formal part), in which case the argument, if any, shall be a direct_name that denotes the immediately enclosing program unit declaration. * At the place of a declaration other than the first, of a declarative_part or program unit declaration, in which case the pragma shall have an argument, which shall be a direct_name that denotes one or more of the following (and nothing else): a subprogram_declaration, a generic_subprogram_declaration, or a generic_instantiation, of the same declarative_part or program unit declaration. <span id="I3758"></span><span id="I3759"></span><span id="I3760"></span><span id="I3761"></span>Certain program unit pragmas are defined to be ''library unit pragmas''. The name, if any, in a library unit pragma shall denote the declaration of a library unit. == Static Semantics == <div> A library unit pragma that applies to a generic unit does not apply to its instances, unless a specific rule for the pragma specifies the contrary. </div> == Post-Compilation Rules == <span id="I3762"></span><span id="I3763"></span>Certain pragmas are defined to be ''configuration pragmas''; they shall appear before the first compilation_unit of a compilation. They are generally used to select a partition-wide or system-wide option. The pragma applies to all compilation_units appearing in the compilation, unless there are none, in which case it applies to all future compilation_units compiled into the same environment. == Implementation Permissions == An implementation may place restrictions on configuration pragmas, so long as it allows them when the environment contains no library_items other than those of the predefined environment. == Implementation Advice == <div> When applied to a generic unit, a program unit pragma that is not a library unit pragma should apply to each instance of the generic unit for which there is not an overriding pragma applied directly to the instance. </div> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-10-1-4|Previous]] | [[Guide:95lrm/RM-10-1-6|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 9uhrkmgjuoqoqf9u2auhs1leqhhedlf Guide:95lrm/RM-10-1-6 4200 877 3622 3621 2019-05-04T23:35:13Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-10-1-5|Previous]] | [[Guide:95lrm/RM-10-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 10.1.6 Environment-Level Visibility Rules}} The normal visibility rules do not apply within a parent_unit_name or a context_clause, nor within a pragma that appears at the place of a compilation unit. The special visibility rules for those contexts are given here. == Static Semantics == <span id="I3764"></span><span id="I3765"></span><span id="I3766"></span><span id="I3767"></span>Within the parent_unit_name at the beginning of a library_item, and within a with_clause, the only declarations that are visible are those that are library_items of the environment, and the only declarations that are directly visible are those that are root library_items of the environment. <span id="I3768"></span>Notwithstanding the rules of [[Guide:95lrm/RM-4-1-3|4.1.3]], an expanded name in a with_clause may consist of a prefix that denotes a generic package and a selector_name that denotes a child of that generic package. (The child is necessarily a generic unit; see [[Guide:95lrm/RM-10-1-1|10.1.1]].) <span id="I3769"></span><span id="I3770"></span><span id="I3771"></span><span id="I3772"></span>Within a use_clause or pragma that is within a context_clause, each library_item mentioned in a previous with_clause of the same context_clause is visible, and each root library_item so mentioned is directly visible. In addition, within such a use_clause, if a given declaration is visible or directly visible, each declaration that occurs immediately within the given declaration's visible part is also visible. No other declarations are visible or directly visible. <span id="I3773"></span><span id="I3774"></span>Within the parent_unit_name of a subunit, library_items are visible as they are in the parent_unit_name of a library_item; in addition, the declaration corresponding to each body_stub in the environment is also visible. <span id="I3775"></span><span id="I3776"></span>Within a pragma that appears at the place of a compilation unit, the immediately preceding library_item and each of its ancestors is visible. The ancestor root library_item is directly visible. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-10-1-5|Previous]] | [[Guide:95lrm/RM-10-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} cyl8h09bo205yp5k0pgfxswzkp8l9ux Guide:95lrm/RM-10-2 4200 878 3624 3623 2019-05-04T23:35:13Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-10-1-6|Previous]] | [[Guide:95lrm/RM-10-2-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 10.2 Program Execution}} <span id="I3777"></span><span id="I3778"></span><span id="I3779"></span>An Ada ''program'' consists of a set of ''partitions'', which can execute in parallel with one another, possibly in a separate address space, and possibly on a separate computer. == Post-Compilation Rules == <span id="I3780"></span><span id="I3781"></span>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. <span id="I3782"></span>The user can ''explicitly assign'' 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 ''needed by'' those library units. The compilation units needed by a given compilation unit are determined as follows (unless specified otherwise via an implementation-defined pragma, or by some other implementation-defined means): <span id="I3783"></span><span id="I3784"></span><span id="I3785"></span> * A compilation unit needs itself; * If a compilation unit is needed, then so are any compilation units upon which it depends semantically; * If a library_unit_declaration is needed, then so is any corresponding library_unit_body; * If a compilation unit with stubs is needed, then so are any corresponding subunits. <span id="I3786"></span>The user can optionally designate (in an implementation-defined manner) one subprogram as the ''main subprogram'' for the partition. A main subprogram, if specified, shall be a subprogram. <span id="I3787"></span>Each partition has an anonymous ''environment task'', which is an implicit outermost task whose execution elaborates the library_items of the environment declarative_part, and then calls the main subprogram, if there is one. A partition's execution is that of its tasks. The order of elaboration of library units is determined primarily by the ''elaboration dependences''. <span id="I3788"></span><span id="I3789"></span>There is an elaboration dependence of a given library_item upon another if the given library_item or any of its subunits depends semantically on the other library_item. In addition, if a given library_item or any of its subunits has a pragma Elaborate or Elaborate_All that mentions another library unit, then there is an elaboration dependence of the given library_item upon the body of the other library unit, and, for Elaborate_All only, upon each library_item needed by the declaration of the other library unit. The environment task for a partition has the following structure: <p><syntaxhighlight lang="Ada"> task Environment_Task;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> task body Environment_Task is  ... (1) -- The environment declarative_part          -- (that is, the sequence of library_items) goes here. begin  ... (2) -- Call the main subprogram, if there is one. end Environment_Task;</syntaxhighlight></p> <span id="I3790"></span>The environment declarative_part at (1) is a sequence of declarative_items consisting of copies of the library_items included in the partition. The order of elaboration of library_items is the order in which they appear in the environment declarative_part: * The order of all included library_items is such that there are no forward elaboration dependences. * Any included library_unit_declaration to which a pragma Elaborate_Body applies is immediately followed by its library_unit_body, if included. * All library_items declared pure occur before any that are not declared pure. * All preelaborated library_items occur before any that are not preelaborated. There shall be a total order of the library_items that obeys the above rules. The order is otherwise implementation defined. The full expanded names of the library units and subunits included in a given partition shall be distinct. The sequence_of_statements of the environment task (see (2) above) consists of either: * 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. or: * A null_statement, if there is no main subprogram. 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. == Dynamic Semantics == <span id="I3791"></span>The execution of a program consists of the execution of a set of partitions. Further details are implementation defined. <span id="I3792"></span>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) task_body 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. == Bounded (Run-Time) Errors == <span id="I3793"></span><span id="I3794"></span>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. <span id="I3795"></span>If such a task is activated, it is not specified whether the task is awaited prior to termination of the environment task. == Implementation Requirements == 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. == Implementation Permissions == <span id="I3796"></span>The kind of partition described in this clause is known as an ''active'' partition. An implementation is allowed to support other kinds of partitions, with implementation-defined semantics. 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. If the environment task completes abnormally, the implementation may abort any dependent tasks. == Notes == 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 [[Guide:95lrm/RM-E|Annex E]], ''[[Guide:95lrm/RM-E|Distributed Systems]]''. If no such mechanisms are provided, then each partition is isolated from all others, and behaves as a program in and of itself. 9  Partitions are not required to run in separate address spaces. For example, an implementation might support dynamic linking via the partition concept. 10  An order of elaboration of library_items that is consistent with the partial ordering defined above does not always ensure that each library_unit_body is elaborated before any other compilation unit whose elaboration necessitates that the library_unit_body be already elaborated. (In particular, there is no requirement that the body of a library unit be elaborated as soon as possible after the library_unit_declaration is elaborated, unless the pragmas in subclause [[Guide:95lrm/RM-10-2-1|10.2.1]] are used.) 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 library_items, and by tasks created by that elaboration. Passive partitions, which cannot have main subprograms, are defined in [[Guide:95lrm/RM-E|Annex E]], ''[[Guide:95lrm/RM-E|Distributed Systems]]''. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-10-1-6|Previous]] | [[Guide:95lrm/RM-10-2-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 5zbxhesb0q2wrd6380zmag0i1tenqvd Guide:95lrm/RM-10-2-1 4200 879 3626 3625 2019-05-04T23:35:14Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-10-2|Previous]] | [[Guide:95lrm/RM-11|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 10.2.1 Elaboration Control}} <span id="I3797"></span>This subclause defines pragmas that help control the elaboration order of library_items. == Syntax == The form of a pragma Preelaborate is as follows: <p><span></span></p> '''pragma''' <span id="I3798"></span><span id="I3799"></span>Preelaborate[(''library_unit_''<span id="I3800"></span>name)]; <span id="I3801"></span><span id="I3802"></span>A pragma Preelaborate is a library unit pragma. == Legality Rules == <span id="I3803"></span>An elaborable construct is preelaborable unless its elaboration performs any of the following actions: * The execution of a statement other than a null_statement. * A call to a subprogram other than a static function. * The evaluation of a primary that is a name of an object, unless the name is a static expression, or statically denotes a discriminant of an enclosing type. * The creation of a default-initialized object (including a component) of a descendant of a private type, private extension, controlled type, task type, or protected type with entry_declarations; similarly the evaluation of an extension_aggregate with an ancestor subtype_mark denoting a subtype of such a type. A generic body is preelaborable only if elaboration of a corresponding instance body would not perform any such actions, presuming that the actual for each formal private type (or extension) is a private type (or extension), and the actual for each formal subprogram is a user-defined subprogram. <span id="I3804"></span> <span id="I3805"></span>If a pragma Preelaborate (or pragma Pure -- see below) applies to a library unit, then it is ''preelaborated''. <span id="I3806"></span>If a library unit is preelaborated, then its declaration, if any, and body, if any, are elaborated prior to all non-preelaborated library_items of the partition. The declaration and body of a preelaborated library unit, and all subunits that are elaborated as part of elaborating the library unit, shall be preelaborable. <span id="I3807"></span>In addition to the places where Legality Rules normally apply (see [[Guide:95lrm/RM-12-3|12.3]]), this rule applies also in the private part of an instance of a generic unit. In addition, all compilation units of a preelaborated library unit shall depend semantically only on compilation units of other preelaborated library units. == Implementation Advice == In an implementation, a type declared in a preelaborated package should have the same representation in every elaboration of a given version of the package, whether the elaborations occur in distinct executions of the same program, or in executions of distinct programs or partitions that include the given version. == Syntax == The form of a pragma Pure is as follows: <p><span></span></p> '''pragma''' <span id="I3808"></span><span id="I3809"></span>Pure[(''library_unit_''<span id="I3810"></span>name)]; <p><span></span></p> <span id="I3811"></span><span id="I3812"></span>A pragma Pure is a library unit pragma. == Legality Rules == <span id="I3813"></span>A ''pure'' library_item is a preelaborable library_item that does not contain the declaration of any variable or named access type, except within a subprogram, generic subprogram, task unit, or protected unit. <span id="I3814"></span>A pragma Pure is used to declare that a library unit is pure. If a pragma Pure applies to a library unit, then its compilation units shall be pure, and they shall depend semantically only on compilation units of other library units that are declared pure. == Implementation Permissions == If a library unit is declared pure, then the implementation is permitted to omit a call on a library-level subprogram of the library unit if the results are not needed after the call. Similarly, it may omit such a call and simply reuse the results produced by an earlier call on the same subprogram, provided that none of the parameters are of a limited type, and the addresses and values of all by-reference actual parameters, and the values of all by-copy-in actual parameters, are the same as they were at the earlier call. This permission applies even if the subprogram produces other side effects when called. == Syntax == The form of a pragma Elaborate, Elaborate_All, or Elaborate_Body is as follows: <p><span></span></p> '''pragma''' <span id="I3815"></span><span id="I3816"></span>Elaborate(''library_unit_''<span id="I3817"></span>name{, ''library_unit_''<span id="I3818"></span>name}); <p><span></span></p> '''pragma''' <span id="I3819"></span><span id="I3820"></span>Elaborate_All(''library_unit_''<span id="I3821"></span>name{, ''library_unit_''<span id="I3822"></span>name}); <p><span></span></p> '''pragma''' <span id="I3823"></span><span id="I3824"></span>Elaborate_Body[(''library_unit_''<span id="I3825"></span>name)]; A pragma Elaborate or Elaborate_All is only allowed within a context_clause. <span id="I3826"></span><span id="I3827"></span>A pragma Elaborate_Body is a library unit pragma. == Legality Rules == <span id="I3828"></span>If a pragma Elaborate_Body applies to a declaration, then the declaration requires a completion (a body). == Static Semantics == A pragma Elaborate specifies that the body of the named library unit is elaborated before the current library_item. A pragma Elaborate_All specifies that each library_item that is needed by the named library unit declaration is elaborated before the current library_item. A pragma Elaborate_Body specifies that the body of the library unit is elaborated immediately after its declaration. == Notes == 12  A preelaborated library unit is allowed to have non-preelaborable children. 13  A library unit that is declared pure is allowed to have impure children. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-10-2|Previous]] | [[Guide:95lrm/RM-11|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} rkoqkwtpkqhgydu3ugfnwgikaa8ro8r Guide:95lrm/RM-11 4200 880 3628 3627 2019-05-04T23:35:14Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-10-2-1|Previous]] | [[Guide:95lrm/RM-11-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Section 11: Exceptions}} This section defines the facilities for dealing with errors or other exceptional situations that arise during program execution. <span id="I3829"></span><span id="I3830"></span><span id="I3831"></span><span id="I3832"></span><span id="I3833"></span><span id="I3834"></span>An ''exception'' represents a kind of exceptional situation; an occurrence of such a situation (at run time) is called an ''exception occurrence''. <span id="I3835"></span>To ''raise'' an exception is to abandon normal program execution so as to draw attention to the fact that the corresponding situation has arisen. <span id="I3836"></span>Performing some actions in response to the arising of an exception is called ''handling'' the exception. An exception_declaration declares a name for an exception. An exception is raised initially either by a raise_statement or by the failure of a language-defined check. When an exception arises, control can be transferred to a user-provided exception_handler at the end of a handled_sequence_of_statements, or it can be propagated to a dynamically enclosing execution. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-10-2-1|Previous]] | [[Guide:95lrm/RM-11-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 606uq0w0x9cx3f1ideqtrm2dz4uuv07 Guide:95lrm/RM-11-1 4200 881 3630 3629 2019-05-04T23:35:14Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-11|Previous]] | [[Guide:95lrm/RM-11-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 11.1 Exception Declarations}} <span id="I3837"></span>An exception_declaration declares a name for an exception. == Syntax == <p><span></span></p> exception_declaration<span id="I3838"></span> ::= <span id="I3839"></span>defining_identifier_list : '''exception'''; == Static Semantics == Each single exception_declaration declares a name for a different exception. If a generic unit includes an exception_declaration, the exception_declarations implicitly generated by different instantiations of the generic unit refer to distinct exceptions (but all have the same defining_identifier). The particular exception denoted by an exception name is determined at compilation time and is the same regardless of how many times the exception_declaration is elaborated. <span id="I3840"></span><span id="I3841"></span><span id="I3842"></span><span id="I3843"></span><span id="I3844"></span>The ''predefined'' exceptions are the ones declared in the declaration of package Standard: Constraint_Error, Program_Error, Storage_Error, and Tasking_Error; one of them is raised when a language-defined check fails. == Dynamic Semantics == <span id="I3845"></span>The elaboration of an exception_declaration has no effect. <span id="I3846"></span><span id="I3847"></span><span id="I3848"></span>The execution of any construct raises Storage_Error if there is insufficient storage for that execution. <span id="I3849"></span>The amount of storage needed for the execution of constructs is unspecified. == Examples == ''Examples of user-defined exception declarations:'' <p><syntaxhighlight lang="Ada"> Singular : exception; Error    : exception; Overflow, Underflow : exception;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-11|Previous]] | [[Guide:95lrm/RM-11-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} k8g60xb2ys1clis6owvx40caru9n8rg Guide:95lrm/RM-11-2 4200 882 3632 3631 2019-05-04T23:35:14Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-11-1|Previous]] | [[Guide:95lrm/RM-11-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 11.2 Exception Handlers}} The response to one or more exceptions is specified by an exception_handler. == Syntax == <p><span></span></p> handled_sequence_of_statements<span id="I3850"></span> ::= <span id="I3851"></span>sequence_of_statements ['''exception''' <span id="I3852"></span>exception_handler {<span id="I3853"></span>exception_handler}] <p><span></span></p> exception_handler<span id="I3854"></span> ::= '''when''' [<span id="I3855"></span>choice_parameter_specification:] <span id="I3856"></span>exception_choice {| <span id="I3857"></span>exception_choice} => <span id="I3858"></span>sequence_of_statements <p><span></span></p> choice_parameter_specification<span id="I3859"></span> ::= <span id="I3860"></span>defining_identifier <p><span></span></p> exception_choice<span id="I3861"></span> ::= ''exception_''<span id="I3862"></span>name | '''others''' == Legality Rules == <span id="I3863"></span>A choice with an ''exception_''name ''covers'' the named exception. A choice with '''others''' covers all exceptions not named by previous choices of the same handled_sequence_of_statements. Two choices in different exception_handlers of the same handled_sequence_of_statements shall not cover the same exception. A choice with '''others''' is allowed only for the last handler of a handled_sequence_of_statements and as the only choice of that handler. An ''exception_''name of a choice shall not denote an exception declared in a generic formal package. == Static Semantics == <span id="I3864"></span>A choice_parameter_specification declares a ''choice parameter'', which is a constant object of type Exception_Occurrence (see [[Guide:95lrm/RM-11-4-1|11.4.1]]). During the handling of an exception occurrence, the choice parameter, if any, of the handler represents the exception occurrence that is being handled. == Dynamic Semantics == <span id="I3865"></span>The execution of a handled_sequence_of_statements consists of the execution of the sequence_of_statements. The optional handlers are used to handle any exceptions that are propagated by the sequence_of_statements. == Examples == ''Example of an exception handler:'' <p><syntaxhighlight lang="Ada"> begin Open(File, In_File, "input.txt");   -- see A.8.2 exception when E : Name_Error =>    Put("Cannot open input file : ");    Put_Line(Exception_Message(E));  -- see 11.4.1    raise; end;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-11-1|Previous]] | [[Guide:95lrm/RM-11-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 2bbfccvez3rpkjy612y6d2203r4purz Guide:95lrm/RM-11-3 4200 883 3634 3633 2019-05-04T23:35:15Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-11-2|Previous]] | [[Guide:95lrm/RM-11-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 11.3 Raise Statements}} A raise_statement raises an exception. == Syntax == <p><span></span></p> raise_statement<span id="I3866"></span> ::= '''raise''' [''exception_''<span id="I3867"></span>name]; == Legality Rules == The name, if any, in a raise_statement shall denote an exception. <span id="I3868"></span>A raise_statement with no ''exception_''name (that is, a ''re-raise statement'') shall be within a handler, but not within a body enclosed by that handler. == Dynamic Semantics == <span id="I3869"></span>To ''raise an exception'' is to raise a new occurrence of that exception, as explained in [[Guide:95lrm/RM-11-4|11.4]]. <span id="I3870"></span>For the execution of a raise_statement with an ''exception_''name, the named exception is raised. <span id="I3871"></span>For the execution of a re-raise statement, the exception occurrence that caused transfer of control to the innermost enclosing handler is raised again. == Examples == ''Examples of raise statements:'' <p><syntaxhighlight lang="Ada"> raise Ada.IO_Exceptions.Name_Error;   -- see A.13</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> raise;                                -- re-raise the current exception</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-11-2|Previous]] | [[Guide:95lrm/RM-11-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 2vkpfyvvizhduh48cicd65h7wftolph Guide:95lrm/RM-11-4 4200 884 3636 3635 2019-05-04T23:35:16Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-11-3|Previous]] | [[Guide:95lrm/RM-11-4-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 11.4 Exception Handling}} When an exception occurrence is raised, normal program execution is abandoned and control is transferred to an applicable exception_handler, if any. <span id="I3872"></span>To ''handle'' an exception occurrence is to respond to the exceptional event. <span id="I3873"></span>To ''propagate'' an exception occurrence is to raise it again in another context; that is, to fail to respond to the exceptional event in the present context. == Dynamic Semantics == <span id="I3874"></span><span id="I3875"></span>Within a given task, if the execution of construct ''a'' is defined by this International Standard to consist (in part) of the execution of construct ''b'', then while ''b'' is executing, the execution of ''a'' is said to ''dynamically enclose'' the execution of ''b''. <span id="I3876"></span>The ''innermost dynamically enclosing'' execution of a given execution is the dynamically enclosing execution that started most recently. <span id="I3877"></span>When an exception occurrence is raised by the execution of a given construct, the rest of the execution of that construct is ''abandoned''; that is, any portions of the execution that have not yet taken place are not performed. The construct is first completed, and then left, as explained in [[Guide:95lrm/RM-7-6-1|7.6.1]]. Then: * If the construct is a task_body, the exception does not propagate further; * If the construct is the sequence_of_statements of a handled_sequence_of_statements that has a handler with a choice covering the exception, the occurrence is handled by that handler; * <span id="I3878"></span>Otherwise, the occurrence is ''propagated'' to the innermost dynamically enclosing execution, which means that the occurrence is raised again in that context. <span id="I3879"></span><span id="I3880"></span><span id="I3881"></span>When an occurrence is ''handled'' by a given handler, the choice_parameter_specification, if any, is first elaborated, which creates the choice parameter and initializes it to the occurrence. Then, the sequence_of_statements of the handler is executed; this execution replaces the abandoned portion of the execution of the sequence_of_statements. == Notes == 1  Note that exceptions raised in a declarative_part of a body are not handled by the handlers of the handled_sequence_of_statements of that body. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-11-3|Previous]] | [[Guide:95lrm/RM-11-4-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 96ymiic15r95p4nohifir3hha6yhl1s Guide:95lrm/RM-11-4-1 4200 885 3638 3637 2019-05-04T23:35:17Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-11-4|Previous]] | [[Guide:95lrm/RM-11-4-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 11.4.1 The Package Exceptions}} == Static Semantics == The following language-defined library package exists: <p><syntaxhighlight lang="Ada"> package Ada.Exceptions is  type Exception_Id is private;  Null_Id : constant Exception_Id;  function Exception_Name(Id : Exception_Id) return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   type Exception_Occurrence is limited private;  type Exception_Occurrence_Access is access all Exception_Occurrence;  Null_Occurrence : constant Exception_Occurrence;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     procedure Raise_Exception(E : in Exception_Id;                            Message : in String := "");  function Exception_Message(X : Exception_Occurrence) return String;  procedure Reraise_Occurrence(X : in Exception_Occurrence);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     function Exception_Identity(X : Exception_Occurrence)                              return Exception_Id;  function Exception_Name(X : Exception_Occurrence) return String;      -- Same as Exception_Name(Exception_Identity(X)).  function Exception_Information(X : Exception_Occurrence) return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     procedure Save_Occurrence(Target : out Exception_Occurrence;                            Source : in Exception_Occurrence);  function Save_Occurrence(Source : Exception_Occurrence)                           return Exception_Occurrence_Access; private ... -- not specified by the language end Ada.Exceptions;</syntaxhighlight></p> Each distinct exception is represented by a distinct value of type Exception_Id. Null_Id does not represent any exception, and is the default initial value of type Exception_Id. Each occurrence of an exception is represented by a value of type Exception_Occurrence. Null_Occurrence does not represent any exception occurrence, and is the default initial value of type Exception_Occurrence. For a prefix E that denotes an exception, the following attribute is defined: ; E'Identity : <span id="I3911"></span><span id="I3912"></span>E'Identity returns the unique identity of the exception. The type of this attribute is Exception_Id. Raise_Exception raises a new occurrence of the identified exception. In this case, Exception_Message returns the Message parameter of Raise_Exception. For a raise_statement with an ''exception_''name, Exception_Message returns implementation-defined information about the exception occurrence. Reraise_Occurrence reraises the specified exception occurrence. Exception_Identity returns the identity of the exception of the occurrence. The Exception_Name functions return the full expanded name of the exception, in upper case, starting with a root library unit. For an exception declared immediately within package Standard, the defining_identifier is returned. The result is implementation defined if the exception is declared within an unnamed block_statement. Exception_Information returns implementation-defined information about the exception occurrence. Raise_Exception and Reraise_Occurrence have no effect in the case of Null_Id or Null_Occurrence. <span id="I3913"></span>Exception_Message, Exception_Identity, Exception_Name, and Exception_Information raise Constraint_Error for a Null_Id or Null_Occurrence. The Save_Occurrence procedure copies the Source to the Target. The Save_Occurrence function uses an allocator of type Exception_Occurrence_Access to create a new object, copies the Source to this new object, and returns an access value designating this new object; the result may be deallocated using an instance of Unchecked_Deallocation. == Implementation Requirements == The implementation of the Write attribute (see [[Guide:95lrm/RM-13-13-2|13.13.2]]) of Exception_Occurrence shall support writing a representation of an exception occurrence to a stream; the implementation of the Read attribute of Exception_Occurrence shall support reconstructing an exception occurrence from a stream (including one written in a different partition). == Implementation Permissions == An implementation of Exception_Name in a space-constrained environment may return the defining_identifier instead of the full expanded name. The string returned by Exception_Message may be truncated (to no less than 200 characters) by the Save_Occurrence procedure (not the function), the Reraise_Occurrence procedure, and the re-raise statement. == Implementation Advice == Exception_Message (by default) and Exception_Information should produce information useful for debugging. Exception_Message should be short (about one line), whereas Exception_Information can be long. Exception_Message should not include the Exception_Name. Exception_Information should include both the Exception_Name and the Exception_Message. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-11-4|Previous]] | [[Guide:95lrm/RM-11-4-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 6fq36d07oi7p2wy9ky5fo9ftbptutwg Guide:95lrm/RM-11-4-2 4200 886 3640 3639 2019-05-04T23:35:20Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-11-4-1|Previous]] | [[Guide:95lrm/RM-11-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 11.4.2 Example of Exception Handling}} == Examples == Exception handling may be used to separate the detection of an error from the response to that error: <p><syntaxhighlight lang="Ada"> with Ada.Exceptions; use Ada; package File_System is  type File_Handle is limited private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     File_Not_Found : exception;  procedure Open(F : in out File_Handle; Name : String);      -- raises File_Not_Found if named file does not exist</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     End_Of_File : exception;  procedure Read(F : in out File_Handle; Data : out Data_Type);      -- raises End_Of_File if the file is not open</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     ... end File_System;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> package body File_System is  procedure Open(F : in out File_Handle; Name : String) is   begin      if File_Exists(Name) then          ...      else          Exceptions.Raise_Exception(File_Not_Found'Identity,                                    "File not found: " & Name & ".");      end if;  end Open;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     procedure Read(F : in out File_Handle; Data : out Data_Type) is  begin      if F.Current_Position <= F.Last_Position then          ...      else          raise End_Of_File;      end if;  end Read;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     ...</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> end File_System;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> with Ada.Text_IO; with Ada.Exceptions; with File_System;  use File_System; use Ada; procedure Main is begin   ... -- call operations in File_System exception  when End_Of_File =>      Close(Some_File);  when Not_Found_Error : File_Not_Found =>      Text_IO.Put_Line(Exceptions.Exception_Message(Not_Found_Error));  when The_Error : others =>      Text_IO.Put_Line("Unknown error:");      if Verbosity_Desired then           Text_IO.Put_Line(Exceptions.Exception_Information(The_Error));      else          Text_IO.Put_Line(Exceptions.Exception_Name(The_Error));           Text_IO.Put_Line(Exceptions.Exception_Message(The_Error));      end if;      raise; end Main;</syntaxhighlight></p> In the above example, the File_System package contains information about detecting certain exceptional situations, but it does not specify how to handle those situations. Procedure Main specifies how to handle them; other clients of File_System might have different handlers, even though the exceptional situations arise from the same basic causes. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-11-4-1|Previous]] | [[Guide:95lrm/RM-11-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} nctps7z7y5vomme6q45svtoejcku6ff Guide:95lrm/RM-11-5 4200 887 3642 3641 2019-05-04T23:35:22Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-11-4-2|Previous]] | [[Guide:95lrm/RM-11-6|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 11.5 Suppressing Checks}} A pragma Suppress gives permission to an implementation to omit certain language-defined checks. <span id="I3914"></span><span id="I3915"></span><span id="I3916"></span><span id="I3917"></span><span id="I3918"></span>A ''language-defined check'' (or simply, a ''check'') is one of the situations defined by this International Standard that requires a check to be made at run time to determine whether some condition is true. <span id="I3919"></span>A check ''fails'' when the condition being checked is false, causing an exception to be raised. == Syntax == The form of a pragma Suppress is as follows: <p><span></span></p> '''pragma''' <span id="I3920"></span><span id="I3921"></span>Suppress(<span id="I3922"></span>identifier [, [On =>] <span id="I3923"></span>name]); <span id="I3924"></span><span id="I3925"></span>A pragma Suppress is allowed only immediately within a declarative_part, immediately within a package_specification, or as a configuration pragma. == Legality Rules == The identifier shall be the name of a check. The name (if present) shall statically denote some entity. For a pragma Suppress that is immediately within a package_specification and includes a name, the name shall denote an entity (or several overloaded subprograms) declared immediately within the package_specification. == Static Semantics == A pragma Suppress gives permission to an implementation to omit the named check from the place of the pragma to the end of the innermost enclosing declarative region, or, if the pragma is given in a package_specification and includes a name, to the end of the scope of the named entity. If the pragma includes a name, the permission applies only to checks performed on the named entity, or, for a subtype, on objects and values of its type. Otherwise, the permission applies to all entities. <span id="I3926"></span>If permission has been given to suppress a given check, the check is said to be ''suppressed''. The following are the language-defined checks: * <span id="I3927"></span>The following checks correspond to situations in which the exception Constraint_Error is raised upon failure. ; <span id="I3928"></span>Access_Check : When evaluating a dereference (explicit or implicit), check that the value of the name is not '''null'''. When passing an actual parameter to a formal access parameter, check that the value of the actual parameter is not '''null'''. When evaluating a discriminant_association for an access discriminant, check that the value of the discriminant is not '''null'''. ; <span id="I3929"></span>Discriminant_Check : Check that the discriminants of a composite value have the values imposed by a discriminant constraint. Also, when accessing a record component, check that it exists for the current discriminant values. ; <span id="I3930"></span>Division_Check : Check that the second operand is not zero for the operations /, rem and mod. ; <span id="I3931"></span>Index_Check : Check that the bounds of an array value are equal to the corresponding bounds of an index constraint. Also, when accessing a component of an array object, check for each dimension that the given index value belongs to the range defined by the bounds of the array object. Also, when accessing a slice of an array object, check that the given discrete range is compatible with the range defined by the bounds of the array object. ; <span id="I3932"></span>Length_Check : Check that two arrays have matching components, in the case of array subtype conversions, and logical operators for arrays of boolean components. ; <span id="I3933"></span>Overflow_Check : Check that a scalar value is within the base range of its type, in cases where the implementation chooses to raise an exception instead of returning the correct mathematical result. ; <span id="I3934"></span>Range_Check : Check that a scalar value satisfies a range constraint. Also, for the elaboration of a subtype_indication, check that the constraint (if present) is compatible with the subtype denoted by the subtype_mark. Also, for an aggregate, check that an index or discriminant value belongs to the corresponding subtype. Also, check that when the result of an operation yields an array, the value of each component belongs to the component subtype. ; <span id="I3935"></span>Tag_Check : Check that operand tags in a dispatching call are all equal. Check for the correct tag on tagged type conversions, for an assignment_statement, and when returning a tagged limited object from a function. * <span id="I3936"></span>The following checks correspond to situations in which the exception Program_Error is raised upon failure. ; <span id="I3937"></span>Elaboration_Check : When a subprogram or protected entry is called, a task activation is accomplished, or a generic instantiation is elaborated, check that the body of the corresponding unit has already been elaborated. ; <span id="I3938"></span>Accessibility_Check : Check the accessibility level of an entity or view. * The following check corresponds to situations in which the exception Storage_Error is raised upon failure. ; <span id="I3939"></span><span id="I3940"></span>Storage_Check : Check that evaluation of an allocator does not require more space than is available for a storage pool. Check that the space available for a task or subprogram has not been exceeded. * The following check corresponds to all situations in which any predefined exception is raised. ; <span id="I3941"></span>All_Checks : Represents the union of all checks; suppressing All_Checks suppresses all checks. == Erroneous Execution == <span id="I3942"></span>If a given check has been suppressed, and the corresponding error situation occurs, the execution of the program is erroneous. == Implementation Permissions == An implementation is allowed to place restrictions on Suppress pragmas. An implementation is allowed to add additional check names, with implementation-defined semantics. <span id="I3943"></span>When Overflow_Check has been suppressed, an implementation may also suppress an unspecified subset of the Range_Checks. == Implementation Advice == The implementation should minimize the code executed for checks that have been suppressed. == Notes == 2  <span id="I3944"></span><span id="I3945"></span>There is no guarantee that a suppressed check is actually removed; hence a pragma Suppress should be used only for efficiency reasons. == Examples == ''Examples of suppressing checks:'' <p><syntaxhighlight lang="Ada"> pragma Suppress(Range_Check); pragma Suppress(Index_Check, On => Table);</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-11-4-2|Previous]] | [[Guide:95lrm/RM-11-6|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} fw2z63xmze00brthl41j9ao5ndquss6 Guide:95lrm/RM-11-6 4200 888 3644 3643 2019-05-04T23:35:22Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-11-5|Previous]] | [[Guide:95lrm/RM-12|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 11.6 Exceptions and Optimization}} <span id="I3946"></span><span id="I3947"></span><span id="I3948"></span><span id="I3949"></span><span id="I3950"></span><span id="I3951"></span>This clause gives permission to the implementation to perform certain ''optimizations'' that do not necessarily preserve the canonical semantics. == Dynamic Semantics == <span id="I3952"></span>The rest of this International Standard (outside this clause) defines the ''canonical semantics'' of the language. The canonical semantics of a given (legal) program determines a set of possible external effects that can result from the execution of the program with given inputs. As explained in [[Guide:95lrm/RM-1-1-3|1.1.3]], ''[[Guide:95lrm/RM-1-1-3|Conformity of an Implementation with the Standard]]'', the external effect of a program is defined in terms of its interactions with its external environment. Hence, the implementation can perform any internal actions whatsoever, in any order or in parallel, so long as the external effect of the execution of the program is one that is allowed by the canonical semantics, or by the rules of this clause. == Implementation Permissions == The following additional permissions are granted to the implementation: * <span id="I3953"></span><span id="I3954"></span>An implementation need not always raise an exception when a language-defined check fails. Instead, the operation that failed the check can simply yield an ''undefined result''. The exception need be raised by the implementation only if, in the absence of raising it, the value of this undefined result would have some effect on the external interactions of the program. In determining this, the implementation shall not presume that an undefined result has a value that belongs to its subtype, nor even to the base range of its type, if scalar. Having removed the raise of the exception, the canonical semantics will in general allow the implementation to omit the code for the check, and some or all of the operation itself. * <span id="I3955"></span>If an exception is raised due to the failure of a language-defined check, then upon reaching the corresponding exception_handler (or the termination of the task, if none), the external interactions that have occurred need reflect only that the exception was raised somewhere within the execution of the sequence_of_statements with the handler (or the task_body), possibly earlier (or later if the interactions are independent of the result of the checked operation) than that defined by the canonical semantics, but not within the execution of some abort-deferred operation or ''independent'' subprogram that does not dynamically enclose the execution of the construct whose check failed. <span id="I3956"></span>An independent subprogram is one that is defined outside the library unit containing the construct whose check failed, and has no Inline pragma applied to it. <span id="I3957"></span><span id="I3958"></span><span id="I3959"></span>Any assignment that occurred outside of such abort-deferred operations or independent subprograms can be disrupted by the raising of the exception, causing the object or its parts to become abnormal, and certain subsequent uses of the object to be erroneous, as explained in [[Guide:95lrm/RM-13-9-1|13.9.1]]. == Notes == 3  The permissions granted by this clause can have an effect on the semantics of a program only if the program fails a language-defined check. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-11-5|Previous]] | [[Guide:95lrm/RM-12|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} gc3mwhda6bmwnxo022cvwy9mf6ds9vu Guide:95lrm/RM-12 4200 889 3646 3645 2019-05-04T23:35:22Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-11-6|Previous]] | [[Guide:95lrm/RM-12-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Section 12: Generic Units}} <span id="I3960"></span>A ''generic unit'' is a program unit that is either a generic subprogram or a generic package. <span id="I3961"></span>A generic unit is a ''template'', which can be parameterized, and from which corresponding (nongeneric) subprograms or packages can be obtained. The resulting program units are said to be ''instances'' of the original generic unit. <span id="I3962"></span><span id="I3963"></span><span id="I3964"></span> A generic unit is declared by a generic_declaration. This form of declaration has a generic_formal_part declaring any generic formal parameters. An instance of a generic unit is obtained as the result of a generic_instantiation with appropriate generic actual parameters for the generic formal parameters. An instance of a generic subprogram is a subprogram. An instance of a generic package is a package. Generic units are templates. As templates they do not have the properties that are specific to their nongeneric counterparts. For example, a generic subprogram can be instantiated but it cannot be called. In contrast, an instance of a generic subprogram is a (nongeneric) subprogram; hence, this instance can be called but it cannot be used to produce further instances. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-11-6|Previous]] | [[Guide:95lrm/RM-12-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} rs0kfdnszbv7054416rz3qvfvece59z Guide:95lrm/RM-12-1 4200 890 3648 3647 2019-05-04T23:35:25Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12|Previous]] | [[Guide:95lrm/RM-12-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 12.1 Generic Declarations}} A generic_declaration declares a generic unit, which is either a generic subprogram or a generic package. A generic_declaration includes a generic_formal_part declaring any generic formal parameters. A generic formal parameter can be an object; alternatively (unlike a parameter of a subprogram), it can be a type, a subprogram, or a package. == Syntax == <p><span></span></p> generic_declaration<span id="I3965"></span> ::= <span id="I3966"></span>generic_subprogram_declaration | <span id="I3967"></span>generic_package_declaration <p><span></span></p> generic_subprogram_declaration<span id="I3968"></span> ::= <span id="I3969"></span>generic_formal_part  <span id="I3970"></span>subprogram_specification; <p><span></span></p> generic_package_declaration<span id="I3971"></span> ::= <span id="I3972"></span>generic_formal_part  <span id="I3973"></span>package_specification; <p><span></span></p> generic_formal_part<span id="I3974"></span> ::= '''generic''' {<span id="I3975"></span>generic_formal_parameter_declaration | <span id="I3976"></span>use_clause} <p><span></span></p> generic_formal_parameter_declaration<span id="I3977"></span> ::= <span id="I3978"></span>formal_object_declaration | <span id="I3979"></span>formal_type_declaration | <span id="I3980"></span>formal_subprogram_declaration | <span id="I3981"></span>formal_package_declaration The only form of subtype_indication allowed within a generic_formal_part is a subtype_mark (that is, the subtype_indication shall not include an explicit constraint). The defining name of a generic subprogram shall be an identifier (not an operator_symbol). == Static Semantics == <span id="I3982"></span><span id="I3983"></span><span id="I3984"></span><span id="I3985"></span>A generic_declaration declares a generic unit -- a generic package, generic procedure or generic function, as appropriate. <span id="I3986"></span>An entity is a ''generic formal'' entity if it is declared by a generic_formal_parameter_declaration. ''Generic formal,'' or simply ''formal,'' is used as a prefix in referring to objects, subtypes (and types), functions, procedures and packages, that are generic formal entities, as well as to their respective declarations. Examples: ''generic formal procedure'' or a ''formal integer type declaration.'' == Dynamic Semantics == <span id="I3987"></span>The elaboration of a generic_declaration has no effect. == Notes == 1  Outside a generic unit a name that denotes the generic_declaration denotes the generic unit. In contrast, within the declarative region of the generic unit, a name that denotes the generic_declaration denotes the current instance. 2  Within a generic subprogram_body, the name of this program unit acts as the name of a subprogram. Hence this name can be overloaded, and it can appear in a recursive call of the current instance. For the same reason, this name cannot appear after the reserved word '''new''' in a (recursive) generic_instantiation. 3  A default_expression or default_name appearing in a generic_formal_part is not evaluated during elaboration of the generic_formal_part; instead, it is evaluated when used. (The usual visibility rules apply to any name used in a default: the denoted declaration therefore has to be visible at the place of the expression.) == Examples == ''Examples of generic formal parts:'' <p><syntaxhighlight lang="Ada"> generic     --  parameterless </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> generic Size : Natural;  --  formal object </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> generic Length : Integer := 200;          -- formal object with a default expression </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Area   : Integer := Length*Length; -- formal object with a default expression </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> generic type Item  is private;                       -- formal type type Index is (<>);                          -- formal type type Row   is array(Index range <>) of Item; -- formal type with function "<"(X, Y : Item) return Boolean;    -- formal subprogram  </syntaxhighlight></p> ''Examples of generic declarations declaring generic subprograms Exchange and Squaring:'' <p><syntaxhighlight lang="Ada"> generic type Elem is private; procedure Exchange(U, V : in out Elem);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> generic type Item is private; with function "*"(U, V : Item) return Item is <>; function Squaring(X : Item) return Item;</syntaxhighlight></p> ''Example of a generic declaration declaring a generic package:'' <p><syntaxhighlight lang="Ada"> generic type Item   is private; type Vector is array (Positive range <>) of Item; with function Sum(X, Y : Item) return Item; package On_Vectors is function Sum  (A, B : Vector) return Vector; function Sigma(A    : Vector) return Item; Length_Error : exception; end On_Vectors;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12|Previous]] | [[Guide:95lrm/RM-12-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} stv2ie6ky5h393bqti5skt8hrznqt03 Guide:95lrm/RM-12-2 4200 891 3650 3649 2019-05-04T23:35:28Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12-1|Previous]] | [[Guide:95lrm/RM-12-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 12.2 Generic Bodies}} <span id="I3988"></span>The body of a generic unit (a ''generic body'') is a template for the instance bodies. The syntax of a generic body is identical to that of a nongeneric body. == Dynamic Semantics == <span id="I3989"></span>The elaboration of a generic body has no other effect than to establish that the generic unit can from then on be instantiated without failing the Elaboration_Check. If the generic body is a child of a generic package, then its elaboration establishes that each corresponding declaration nested in an instance of the parent (see [[Guide:95lrm/RM-10-1-1|10.1.1]]) can from then on be instantiated without failing the Elaboration_Check. == Notes == 4  The syntax of generic subprograms implies that a generic subprogram body is always the completion of a declaration. == Examples == ''Example of a generic procedure body:'' <p><syntaxhighlight lang="Ada"> procedure Exchange(U, V : in out Elem) is  -- see 12.1 T : Elem;  --  the generic formal type begin T := U; U := V; V := T; end Exchange;</syntaxhighlight></p> ''Example of a generic function body:'' <p><syntaxhighlight lang="Ada"> function Squaring(X : Item) return Item is  --  see 12.1 begin return X*X;  --  the formal operator "*" end Squaring;</syntaxhighlight></p> ''Example of a generic package body:'' <p><syntaxhighlight lang="Ada"> package body On_Vectors is  --  see 12.1</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Sum(A, B : Vector) return Vector is    Result : Vector(A'Range); --  the formal type Vector    Bias   : constant Integer := B'First - A'First; begin    if A'Length /= B'Length then       raise Length_Error;    end if;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       for N in A'Range loop       Result(N) := Sum(A(N), B(N + Bias)); -- the formal function Sum     end loop;    return Result; end Sum;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Sigma(A : Vector) return Item is    Total : Item := A(A'First); --  the formal type Item begin    for N in A'First + 1 .. A'Last loop       Total := Sum(Total, A(N)); --  the formal function Sum    end loop;    return Total; end Sigma; end On_Vectors;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12-1|Previous]] | [[Guide:95lrm/RM-12-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 3drxhywfdhjdotpxpy2wrqwq5r99bqs Guide:95lrm/RM-12-3 4200 892 3652 3651 2019-05-04T23:35:30Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12-2|Previous]] | [[Guide:95lrm/RM-12-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 12.3 Generic Instantiation}} <span id="I3990"></span>An instance of a generic unit is declared by a generic_instantiation. == Syntax == <p><span></span></p> generic_instantiation<span id="I3991"></span> ::= '''package''' <span id="I3992"></span>defining_program_unit_name '''is''' '''new''' ''generic_package_''<span id="I3993"></span>name [<span id="I3994"></span>generic_actual_part]; | '''procedure''' <span id="I3995"></span>defining_program_unit_name '''is''' '''new''' ''generic_procedure_''<span id="I3996"></span>name [<span id="I3997"></span>generic_actual_part]; | '''function''' <span id="I3998"></span>defining_designator '''is''' '''new''' ''generic_function_''<span id="I3999"></span>name [<span id="I4000"></span>generic_actual_part]; <p><span></span></p> generic_actual_part<span id="I4001"></span> ::= (<span id="I4002"></span>generic_association {, <span id="I4003"></span>generic_association}) <p><span></span></p> generic_association<span id="I4004"></span> ::= [''generic_formal_parameter_''<span id="I4005"></span>selector_name =>] <span id="I4006"></span>explicit_generic_actual_parameter <p><span></span></p> explicit_generic_actual_parameter<span id="I4007"></span> ::= <span id="I4008"></span>expression | ''variable_''<span id="I4009"></span>name | ''subprogram_''<span id="I4010"></span>name | ''entry_''<span id="I4011"></span>name | <span id="I4012"></span>subtype_mark | ''package_instance_''<span id="I4013"></span>name <span id="I4014"></span><span id="I4015"></span>A generic_association is ''named'' or ''positional'' according to whether or not the ''generic_formal_parameter_''selector_name is specified. Any positional associations shall precede any named associations. <span id="I4016"></span><span id="I4017"></span><span id="I4018"></span>The ''generic actual parameter'' is either the explicit_generic_actual_parameter given in a generic_parameter_association for each formal, or the corresponding default_expression or default_name if no generic_parameter_association is given for the formal. When the meaning is clear from context, the term ''generic actual,'' or simply ''actual,'' is used as a synonym for ''generic actual parameter'' and also for the view denoted by one, or the value of one. == Legality Rules == In a generic_instantiation for a particular kind of program unit (package, procedure, or function), the name shall denote a generic unit of the corresponding kind (generic package, generic procedure, or generic function, respectively). The ''generic_formal_parameter_''selector_name of a generic_association shall denote a generic_formal_parameter_declaration of the generic unit being instantiated. If two or more formal subprograms have the same defining name, then named associations are not allowed for the corresponding actuals. A generic_instantiation shall contain at most one generic_association for each formal. Each formal without an association shall have a default_expression or subprogram_default. In a generic unit Legality Rules are enforced at compile time of the generic_declaration and generic body, given the properties of the formals. In the visible part and formal part of an instance, Legality Rules are enforced at compile time of the generic_instantiation, given the properties of the actuals. In other parts of an instance, Legality Rules are not enforced; this rule does not apply when a given rule explicitly specifies otherwise. == Static Semantics == A generic_instantiation declares an instance; it is equivalent to the instance declaration (a package_declaration or subprogram_declaration) immediately followed by the instance body, both at the place of the instantiation. The instance is a copy of the text of the template. Each use of a formal parameter becomes (in the copy) a use of the actual, as explained below. <span id="I4019"></span><span id="I4020"></span><span id="I4021"></span><span id="I4022"></span><span id="I4023"></span><span id="I4024"></span><span id="I4025"></span><span id="I4026"></span>An instance of a generic package is a package, that of a generic procedure is a procedure, and that of a generic function is a function. The interpretation of each construct within a generic declaration or body is determined using the overloading rules when that generic declaration or body is compiled. In an instance, the interpretation of each (copied) construct is the same, except in the case of a name that denotes the generic_declaration or some declaration within the generic unit; the corresponding name in the instance then denotes the corresponding copy of the denoted declaration. The overloading rules do not apply in the instance. In an instance, a generic_formal_parameter_declaration declares a view whose properties are identical to those of the actual, except as specified in [[Guide:95lrm/RM-12-4|12.4]], ''[[Guide:95lrm/RM-12-4|Formal Objects]]'' and [[Guide:95lrm/RM-12-6|12.6]], ''[[Guide:95lrm/RM-12-6|Formal Subprograms]]''. Similarly, for a declaration within a generic_formal_parameter_declaration, the corresponding declaration in an instance declares a view whose properties are identical to the corresponding declaration within the declaration of the actual. Implicit declarations are also copied, and a name that denotes an implicit declaration in the generic denotes the corresponding copy in the instance. However, for a type declared within the visible part of the generic, a whole new set of primitive subprograms is implicitly declared for use outside the instance, and may differ from the copied set if the properties of the type in some way depend on the properties of some actual type specified in the instantiation. For example, if the type in the generic is derived from a formal private type, then in the instance the type will inherit subprograms from the corresponding actual type. <span id="I4027"></span>These new implicit declarations occur immediately after the type declaration in the instance, and override the copied ones. The copied ones can be called only from within the instance; the new ones can be called only from outside the instance, although for tagged types, the body of a new one can be executed by a call to an old one. In the visible part of an instance, an explicit declaration overrides an implicit declaration if they are homographs, as described in [[Guide:95lrm/RM-8-3|8.3]]. On the other hand, an explicit declaration in the private part of an instance overrides an implicit declaration in the instance, only if the corresponding explicit declaration in the generic overrides a corresponding implicit declaration in the generic. Corresponding rules apply to the other kinds of overriding described in [[Guide:95lrm/RM-8-3|8.3]]. == Post-Compilation Rules == Recursive generic instantiation is not allowed in the following sense: if a given generic unit includes an instantiation of a second generic unit, then the instance generated by this instantiation shall not include an instance of the first generic unit (whether this instance is generated directly, or indirectly by intermediate instantiations). == Dynamic Semantics == <span id="I4028"></span>For the elaboration of a generic_instantiation, each generic_association is first evaluated. If a default is used, an implicit generic_association is assumed for this rule. These evaluations are done in an arbitrary order, except that the evaluation for a default actual takes place after the evaluation for another actual if the default includes a name that denotes the other one. Finally, the instance declaration and body are elaborated. <span id="I4029"></span>For the evaluation of a generic_association the generic actual parameter is evaluated. Additional actions are performed in the case of a formal object of mode '''in''' (see [[Guide:95lrm/RM-12-4|12.4]]). == Notes == 5  If a formal type is not tagged, then the type is treated as an untagged type within the generic body. Deriving from such a type in a generic body is permitted; the new type does not get a new tag value, even if the actual is tagged. Overriding operations for such a derived type cannot be dispatched to from outside the instance. == Examples == ''Examples of generic instantiations (see [[Guide:95lrm/RM-12-1|12.1]]):'' <p><syntaxhighlight lang="Ada"> procedure Swap is new Exchange(Elem => Integer); procedure Swap is new Exchange(Character);           --  Swap is overloaded  function Square is new Squaring(Integer);            --  "*" of Integer used by default function Square is new Squaring(Item => Matrix, "*" => Matrix_Product); function Square is new Squaring(Matrix, Matrix_Product); -- same as previous </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> package Int_Vectors is new On_Vectors(Integer, Table, "+");</syntaxhighlight></p> ''Examples of uses of instantiated units:'' <p><syntaxhighlight lang="Ada"> Swap(A, B); A := Square(A);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> T : Table(1 .. 5) := (10, 20, 30, 40, 50); N : Integer := Int_Vectors.Sigma(T);  --  150 (see 12.2, ''Generic Bodies'' for the body of Sigma)</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> use Int_Vectors; M : Integer := Sigma(T);  --  150</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12-2|Previous]] | [[Guide:95lrm/RM-12-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 61g10ge2tvng6owhktfr61hnay9p71x Guide:95lrm/RM-12-4 4200 893 3654 3653 2019-05-04T23:35:31Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12-3|Previous]] | [[Guide:95lrm/RM-12-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 12.4 Formal Objects}} <span id="I4030"></span><span id="I4031"></span>A generic formal object can be used to pass a value or variable to a generic unit. == Syntax == <p><span></span></p> formal_object_declaration<span id="I4032"></span> ::= <span id="I4033"></span>defining_identifier_list : <span id="I4034"></span>mode <span id="I4035"></span>subtype_mark [:= <span id="I4036"></span>default_expression]; == Name Resolution Rules == <span id="I4037"></span>The expected type for the default_expression, if any, of a formal object is the type of the formal object. <span id="I4038"></span>For a generic formal object of mode '''in''', the expected type for the actual is the type of the formal. For a generic formal object of mode '''in out''', the type of the actual shall resolve to the type of the formal. == Legality Rules == If a generic formal object has a default_expression, then the mode shall be '''in''' (either explicitly or by default); otherwise, its mode shall be either '''in''' or '''in out'''. For a generic formal object of mode '''in''', the actual shall be an expression. For a generic formal object of mode '''in out''', the actual shall be a name that denotes a variable for which renaming is allowed (see [[Guide:95lrm/RM-8-5-1|8.5.1]]). The type of a generic formal object of mode '''in''' shall be nonlimited. == Static Semantics == A formal_object_declaration declares a generic formal object. The default mode is '''in'''. <span id="I4039"></span>For a formal object of mode '''in''', the nominal subtype is the one denoted by the subtype_mark in the declaration of the formal. <span id="I4040"></span>For a formal object of mode '''in out''', its type is determined by the subtype_mark in the declaration; its nominal subtype is nonstatic, even if the subtype_mark denotes a static subtype. <span id="I4041"></span>In an instance, a formal_object_declaration of mode '''in''' declares a new stand-alone constant object whose initialization expression is the actual, whereas a formal_object_declaration of mode '''in out''' declares a view whose properties are identical to those of the actual. == Dynamic Semantics == <span id="I4042"></span><span id="I4043"></span>For the evaluation of a generic_association for a formal object of mode '''in''', a constant object is created, the value of the actual parameter is converted to the nominal subtype of the formal object, and assigned to the object, including any value adjustment -- see [[Guide:95lrm/RM-7-6|7.6]]. <span id="I4044"></span> == Notes == 6  The constraints that apply to a generic formal object of mode '''in out''' are those of the corresponding generic actual parameter (not those implied by the subtype_mark that appears in the formal_object_declaration). Therefore, to avoid confusion, it is recommended that the name of a first subtype be used for the declaration of such a formal object. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12-3|Previous]] | [[Guide:95lrm/RM-12-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} adcrug1n9ufqjg5lv95ov7onk0xdqra Guide:95lrm/RM-12-5 4200 894 3656 3655 2019-05-04T23:35:32Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12-4|Previous]] | [[Guide:95lrm/RM-12-5-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 12.5 Formal Types}} A generic formal subtype can be used to pass to a generic unit a subtype whose type is in a certain class of types. == Syntax == <p><span></span></p> formal_type_declaration<span id="I4045"></span> ::= '''type''' <span id="I4046"></span>defining_identifier[<span id="I4047"></span>discriminant_part] '''is''' <span id="I4048"></span>formal_type_definition; <p><span></span></p> formal_type_definition<span id="I4049"></span> ::= <span id="I4050"></span>formal_private_type_definition | <span id="I4051"></span>formal_derived_type_definition | <span id="I4052"></span>formal_discrete_type_definition | <span id="I4053"></span>formal_signed_integer_type_definition | <span id="I4054"></span>formal_modular_type_definition | <span id="I4055"></span>formal_floating_point_definition | <span id="I4056"></span>formal_ordinary_fixed_point_definition | <span id="I4057"></span>formal_decimal_fixed_point_definition | <span id="I4058"></span>formal_array_type_definition | <span id="I4059"></span>formal_access_type_definition == Legality Rules == <span id="I4060"></span><span id="I4061"></span><span id="I4062"></span><span id="I4063"></span>For a generic formal subtype, the actual shall be a subtype_mark; it denotes the ''(generic) actual subtype''. == Static Semantics == <span id="I4064"></span><span id="I4065"></span><span id="I4066"></span><span id="I4067"></span>A formal_type_declaration declares a ''(generic) formal type'', and its first subtype, the ''(generic) formal subtype''. <span id="I4068"></span><span id="I4069"></span>The form of a formal_type_definition ''determines a class'' to which the formal type belongs. For a formal_private_type_definition the reserved words '''tagged''' and '''limited''' indicate the class (see [[Guide:95lrm/RM-12-5-1|12.5.1]]). For a formal_derived_type_definition the class is the derivation class rooted at the ancestor type. For other formal types, the name of the syntactic category indicates the class; a formal_discrete_type_definition defines a discrete type, and so on. == Legality Rules == The actual type shall be in the class determined for the formal. == Static Semantics == The formal type also belongs to each class that contains the determined class. The primitive subprograms of the type are as for any type in the determined class. For a formal type other than a formal derived type, these are the predefined operators of the type. For an elementary formal type, the predefined operators are implicitly declared immediately after the declaration of the formal type. For a composite formal type, the predefined operators are implicitly declared either immediately after the declaration of the formal type, or later in its immediate scope according to the rules of [[Guide:95lrm/RM-7-3-1|7.3.1]]. In an instance, the copy of such an implicit declaration declares a view of the predefined operator of the actual type, even if this operator has been overridden for the actual type. The rules specific to formal derived types are given in [[Guide:95lrm/RM-12-5-1|12.5.1]]. == Notes == 7  Generic formal types, like all types, are not named. Instead, a name can denote a generic formal subtype. Within a generic unit, a generic formal type is considered as being distinct from all other (formal or nonformal) types. 8  A discriminant_part is allowed only for certain kinds of types, and therefore only for certain kinds of generic formal types. See [[Guide:95lrm/RM-3-7|3.7]]. == Examples == ''Examples of generic formal types:'' <p><syntaxhighlight lang="Ada"> type Item is private; type Buffer(Length : Natural) is limited private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Enum  is (<>); type Int   is range <>; type Angle is delta <>; type Mass  is digits <>; </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Table is array (Enum) of Item;</syntaxhighlight></p> ''Example of a generic formal part declaring a formal integer type:'' <p><syntaxhighlight lang="Ada"> generic type Rank is range <>; First  : Rank := Rank'First; Second : Rank := First + 1;  --  the operator "+" of the type Rank </syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12-4|Previous]] | [[Guide:95lrm/RM-12-5-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} tgbgjazipr7rssqfms9k1gvpq2do4kz Guide:95lrm/RM-12-5-1 4200 895 3658 3657 2019-05-04T23:35:33Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12-5|Previous]] | [[Guide:95lrm/RM-12-5-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 12.5.1 Formal Private and Derived Types}} The class determined for a formal private type can be either limited or nonlimited, and either tagged or untagged; no more specific class is known for such a type. The class determined for a formal derived type is the derivation class rooted at the ancestor type. == Syntax == <p><span></span></p> formal_private_type_definition<span id="I4070"></span> ::= [['''abstract'''] '''tagged'''] ['''limited'''] '''private''' <p><span></span></p> formal_derived_type_definition<span id="I4071"></span> ::= ['''abstract'''] '''new''' <span id="I4072"></span>subtype_mark ['''with''' '''private'''] == Legality Rules == If a generic formal type declaration has a known_discriminant_part, then it shall not include a default_expression for a discriminant. <span id="I4073"></span>The ''ancestor subtype'' of a formal derived type is the subtype denoted by the subtype_mark of the formal_derived_type_definition. For a formal derived type declaration, the reserved words '''with private''' shall appear if and only if the ancestor type is a tagged type; in this case the formal derived type is a private extension of the ancestor type and the ancestor shall not be a class-wide type. Similarly, the optional reserved word '''abstract''' shall appear only if the ancestor type is a tagged type. If the formal subtype is definite, then the actual subtype shall also be definite. For a generic formal derived type with no discriminant_part: * If the ancestor subtype is constrained, the actual subtype shall be constrained, and shall be statically compatible with the ancestor; * If the ancestor subtype is an unconstrained access or composite subtype, the actual subtype shall be unconstrained. * If the ancestor subtype is an unconstrained discriminated subtype, then the actual shall have the same number of discriminants, and each discriminant of the actual shall correspond to a discriminant of the ancestor, in the sense of [[Guide:95lrm/RM-3-7|3.7]]. The declaration of a formal derived type shall not have a known_discriminant_part. For a generic formal private type with a known_discriminant_part: * The actual type shall be a type with the same number of discriminants. * The actual subtype shall be unconstrained. * The subtype of each discriminant of the actual type shall statically match the subtype of the corresponding discriminant of the formal type. <span id="I4074"></span> For a generic formal type with an unknown_discriminant_part, the actual may, but need not, have discriminants, and may be definite or indefinite. == Static Semantics == The class determined for a formal private type is as follows: <p><span></span></p> ''Type Definition''  ''Determined Class'' '''limited private'''  the class of all types '''private'''  the class of all nonlimited types '''tagged limited private'''  the class of all tagged types '''tagged private'''  the class of all nonlimited tagged types The presence of the reserved word '''abstract''' determines whether the actual type may be abstract. A formal private or derived type is a private or derived type, respectively. A formal derived tagged type is a private extension. A formal private or derived type is abstract if the reserved word '''abstract''' appears in its declaration. If the ancestor type is a composite type that is not an array type, the formal type inherits components from the ancestor type (including discriminants if a new discriminant_part is not specified), as for a derived type defined by a derived_type_definition (see [[Guide:95lrm/RM-3-4|3.4]]). For a formal derived type, the predefined operators and inherited user-defined subprograms are determined by the ancestor type, and are implicitly declared at the earliest place, if any, within the immediate scope of the formal type, where the corresponding primitive subprogram of the ancestor is visible (see [[Guide:95lrm/RM-7-3-1|7.3.1]]). In an instance, the copy of such an implicit declaration declares a view of the corresponding primitive subprogram of the ancestor of the formal derived type, even if this primitive has been overridden for the actual type. When the ancestor of the formal derived type is itself a formal type, the copy of the implicit declaration declares a view of the corresponding copied operation of the ancestor. In the case of a formal private extension, however, the tag of the formal type is that of the actual type, so if the tag in a call is statically determined to be that of the formal type, the body executed will be that corresponding to the actual type. For a prefix S that denotes a formal indefinite subtype, the following attribute is defined: ;  S'Definite : <span id="I4075"></span><span id="I4076"></span>S'Definite yields True if the actual subtype corresponding to S is definite; otherwise it yields False. The value of this attribute is of the predefined type Boolean. == Notes == 9  In accordance with the general rule that the actual type shall belong to the class determined for the formal (see [[Guide:95lrm/RM-12-5|12.5]], ''[[Guide:95lrm/RM-12-5|Formal Types]]''): * If the formal type is nonlimited, then so shall be the actual; * For a formal derived type, the actual shall be in the class rooted at the ancestor subtype. 10  The actual type can be abstract only if the formal type is abstract (see [[Guide:95lrm/RM-3-9-3|3.9.3]]). 11  If the formal has a discriminant_part, the actual can be either definite or indefinite. Otherwise, the actual has to be definite. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12-5|Previous]] | [[Guide:95lrm/RM-12-5-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 5i0m28ioemu48jw6ghuf8m07jumd9kp Guide:95lrm/RM-12-5-2 4200 896 3660 3659 2019-05-04T23:35:33Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12-5-1|Previous]] | [[Guide:95lrm/RM-12-5-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 12.5.2 Formal Scalar Types}} A ''formal scalar type'' is one defined by any of the formal_type_definitions in this subclause. The class determined for a formal scalar type is discrete, signed integer, modular, floating point, ordinary fixed point, or decimal. == Syntax == <p><span></span></p> formal_discrete_type_definition<span id="I4077"></span> ::= (<>) <p><span></span></p> formal_signed_integer_type_definition<span id="I4078"></span> ::= '''range''' <> <p><span></span></p> formal_modular_type_definition<span id="I4079"></span> ::= '''mod''' <> <p><span></span></p> formal_floating_point_definition<span id="I4080"></span> ::= '''digits''' <> <p><span></span></p> formal_ordinary_fixed_point_definition<span id="I4081"></span> ::= '''delta''' <> <p><span></span></p> formal_decimal_fixed_point_definition<span id="I4082"></span> ::= '''delta''' <> '''digits''' <> == Legality Rules == The actual type for a formal scalar type shall not be a nonstandard numeric type. == Notes == 12  The actual type shall be in the class of types implied by the syntactic category of the formal type definition (see [[Guide:95lrm/RM-12-5|12.5]], ''[[Guide:95lrm/RM-12-5|Formal Types]]''). For example, the actual for a formal_modular_type_definition shall be a modular type. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12-5-1|Previous]] | [[Guide:95lrm/RM-12-5-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} gk6wdre802wm7gv77nqyoz7qjg5nn6s Guide:95lrm/RM-12-5-3 4200 897 3662 3661 2019-05-04T23:35:35Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12-5-2|Previous]] | [[Guide:95lrm/RM-12-5-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 12.5.3 Formal Array Types}} The class determined for a formal array type is the class of all array types. == Syntax == <p><span></span></p> formal_array_type_definition<span id="I4083"></span> ::= <span id="I4084"></span>array_type_definition == Legality Rules == The only form of discrete_subtype_definition that is allowed within the declaration of a generic formal (constrained) array subtype is a subtype_mark. For a formal array subtype, the actual subtype shall satisfy the following conditions: * The formal array type and the actual array type shall have the same dimensionality; the formal subtype and the actual subtype shall be either both constrained or both unconstrained. * For each index position, the index types shall be the same, and the index subtypes (if unconstrained), or the index ranges (if constrained), shall statically match (see [[Guide:95lrm/RM-4-9-1|4.9.1]]). <span id="I4085"></span> * The component subtypes of the formal and actual array types shall statically match. <span id="I4086"></span> * If the formal type has aliased components, then so shall the actual. == Examples == ''Example of formal array types:'' <p><syntaxhighlight lang="Ada"> --  given the generic package </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> generic type Item   is private; type Index  is (<>); type Vector is array (Index range <>) of Item; type Table  is array (Index) of Item; package P is ... end P;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> --  and the types </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Mix    is array (Color range <>) of Boolean; type Option is array (Color) of Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> --  then Mix can match Vector and Option can match Table </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> package R is new P(Item   => Boolean, Index => Color,                 Vector => Mix,     Table => Option);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> --  Note that Mix cannot match Table and Option cannot match Vector</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12-5-2|Previous]] | [[Guide:95lrm/RM-12-5-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} f7qqqp5l22jelsanbjqfuvirpehqc8w Guide:95lrm/RM-12-5-4 4200 898 3664 3663 2019-05-04T23:35:38Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12-5-3|Previous]] | [[Guide:95lrm/RM-12-6|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 12.5.4 Formal Access Types}} The class determined for a formal access type is the class of all access types. == Syntax == <p><span></span></p> formal_access_type_definition<span id="I4087"></span> ::= <span id="I4088"></span>access_type_definition == Legality Rules == For a formal access-to-object type, the designated subtypes of the formal and actual types shall statically match. <span id="I4089"></span> If and only if the general_access_modifier '''constant''' applies to the formal, the actual shall be an access-to-constant type. If the general_access_modifier '''all''' applies to the formal, then the actual shall be a general access-to-variable type (see [[Guide:95lrm/RM-3-10|3.10]]). For a formal access-to-subprogram subtype, the designated profiles of the formal and the actual shall be mode-conformant, and the calling convention of the actual shall be ''protected'' if and only if that of the formal is ''protected''. <span id="I4090"></span> == Examples == ''Example of formal access types:'' <p><syntaxhighlight lang="Ada"> --  the formal types of the generic package </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> generic type Node is private; type Link is access Node; package P is ... end P;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> --  can be matched by the actual types </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Car; type Car_Name is access Car;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Car is record    Pred, Succ : Car_Name;    Number     : License_Number;    Owner      : Person; end record;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> --  in the following generic instantiation </syntaxhighlight></p> <p><syntaxhighlight lang="Ada">package R is new P(Node => Car, Link => Car_Name);</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12-5-3|Previous]] | [[Guide:95lrm/RM-12-6|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} mm5uibvymgxzcfgjwlwqzhjt73h4dla Guide:95lrm/RM-12-6 4200 899 3666 3665 2019-05-04T23:35:41Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12-5-4|Previous]] | [[Guide:95lrm/RM-12-7|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 12.6 Formal Subprograms}} <span id="I4091"></span><span id="I4092"></span>Formal subprograms can be used to pass callable entities to a generic unit. == Syntax == <p><span></span></p> formal_subprogram_declaration<span id="I4093"></span> ::= '''with''' <span id="I4094"></span>subprogram_specification ['''is''' <span id="I4095"></span>subprogram_default]; <p><span></span></p> subprogram_default<span id="I4096"></span> ::= <span id="I4097"></span>default_name | <> <p><span></span></p> default_name<span id="I4098"></span> ::= <span id="I4099"></span>name == Name Resolution Rules == <span id="I4100"></span>The expected profile for the default_name, if any, is that of the formal subprogram. <span id="I4101"></span>For a generic formal subprogram, the expected profile for the actual is that of the formal subprogram. == Legality Rules == The profiles of the formal and any named default shall be mode-conformant. <span id="I4102"></span> The profiles of the formal and actual shall be mode-conformant. <span id="I4103"></span> == Static Semantics == A formal_subprogram_declaration declares a generic formal subprogram. The types of the formal parameters and result, if any, of the formal subprogram are those determined by the subtype_marks given in the formal_subprogram_declaration; however, independent of the particular subtypes that are denoted by the subtype_marks, the nominal subtypes of the formal parameters and result, if any, are defined to be nonstatic, and unconstrained if of an array type (no applicable index constraint is provided in a call on a formal subprogram). In an instance, a formal_subprogram_declaration declares a view of the actual. The profile of this view takes its subtypes and calling convention from the original profile of the actual entity, while taking the formal parameter names and default_expressions from the profile given in the formal_subprogram_declaration. The view is a function or procedure, never an entry. If a generic unit has a subprogram_default specified by a box, and the corresponding actual parameter is omitted, then it is equivalent to an explicit actual parameter that is a usage name identical to the defining name of the formal. == Notes == 13  The matching rules for formal subprograms state requirements that are similar to those applying to subprogram_renaming_declarations (see [[Guide:95lrm/RM-8-5-4|8.5.4]]). In particular, the name of a parameter of the formal subprogram need not be the same as that of the corresponding parameter of the actual subprogram; similarly, for these parameters, default_expressions need not correspond. 14  The constraints that apply to a parameter of a formal subprogram are those of the corresponding formal parameter of the matching actual subprogram (not those implied by the corresponding subtype_mark in the _specification of the formal subprogram). A similar remark applies to the result of a function. Therefore, to avoid confusion, it is recommended that the name of a first subtype be used in any declaration of a formal subprogram. 15  The subtype specified for a formal parameter of a generic formal subprogram can be any visible subtype, including a generic formal subtype of the same generic_formal_part. 16  A formal subprogram is matched by an attribute of a type if the attribute is a function with a matching specification. An enumeration literal of a given type matches a parameterless formal function whose result type is the given type. 17  A default_name denotes an entity that is visible or directly visible at the place of the generic_declaration; a box used as a default is equivalent to a name that denotes an entity that is directly visible at the place of the _instantiation. 18  The actual subprogram cannot be abstract (see [[Guide:95lrm/RM-3-9-3|3.9.3]]). == Examples == ''Examples of generic formal subprograms:'' <p><syntaxhighlight lang="Ada"> with function "+"(X, Y : Item) return Item is <>; with function Image(X : Enum) return String is Enum'Image; with procedure Update is Default_Update;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> --  given the generic procedure declaration </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> generic with procedure Action (X : in Item); procedure Iterate(Seq : in Item_Sequence);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> --  and the procedure </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> procedure Put_Item(X : in Item);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> --  the following instantiation is possible </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> procedure Put_List is new Iterate(Action => Put_Item);</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12-5-4|Previous]] | [[Guide:95lrm/RM-12-7|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} s96gx7kqsx4fiwv57te5bw7oo6sz4xw Guide:95lrm/RM-12-7 4200 900 3668 3667 2019-05-04T23:35:42Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12-6|Previous]] | [[Guide:95lrm/RM-12-8|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 12.7 Formal Packages}} <span id="I4104"></span><span id="I4105"></span>Formal packages can be used to pass packages to a generic unit. The formal_package_declaration declares that the formal package is an instance of a given generic package. Upon instantiation, the actual package has to be an instance of that generic package. == Syntax == <p><span></span></p> formal_package_declaration<span id="I4106"></span> ::= '''with''' '''package''' <span id="I4107"></span>defining_identifier '''is''' '''new''' ''generic_package_''<span id="I4108"></span>name  <span id="I4109"></span>formal_package_actual_part; <p><span></span></p> formal_package_actual_part<span id="I4110"></span> ::= (<>) | [<span id="I4111"></span>generic_actual_part] == Legality Rules == <span id="I4112"></span>The ''generic_package_''name shall denote a generic package (the ''template'' for the formal package); the formal package is an instance of the template. The actual shall be an instance of the template. If the formal_package_actual_part is (<>), then the actual may be any instance of the template; otherwise, each actual parameter of the actual instance shall match the corresponding actual parameter of the formal package (whether the actual parameter is given explicitly or by default), as follows: * For a formal object of mode '''in''' the actuals match if they are static expressions with the same value, or if they statically denote the same constant, or if they are both the literal '''null'''. * For a formal subtype, the actuals match if they denote statically matching subtypes. <span id="I4113"></span> * For other kinds of formals, the actuals match if they statically denote the same entity. <div> For the purposes of matching, any actual parameter that is the name of a formal object of mode '''in''' is replaced by the formal object's actual expression (recursively). </div> == Static Semantics == A formal_package_declaration declares a generic formal package. <span id="I4114"></span>The visible part of a formal package includes the first list of basic_declarative_items of the package_specification. In addition, if the formal_package_actual_part is (<>), it also includes the generic_formal_part of the template for the formal package. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12-6|Previous]] | [[Guide:95lrm/RM-12-8|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 1r5bq55tj2b6aynpzjabuwju2dc9etg Guide:95lrm/RM-12-8 4200 901 3670 3669 2019-05-04T23:35:45Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12-7|Previous]] | [[Guide:95lrm/RM-13|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 12.8 Example of a Generic Package}} The following example provides a possible formulation of stacks by means of a generic package. The size of each stack and the type of the stack elements are provided as generic formal parameters. == Examples == ''This paragraph was deleted.'' <p><syntaxhighlight lang="Ada"> generic Size : Positive; type Item is private; package Stack is procedure Push(E : in  Item); procedure Pop (E : out Item); Overflow, Underflow : exception; end Stack;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> package body Stack is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Table is array (Positive range <>) of Item; Space : Table(1 .. Size); Index : Natural := 0;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Push(E : in Item) is begin    if Index >= Size then       raise Overflow;    end if;    Index := Index + 1;    Space(Index) := E; end Push;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Pop(E : out Item) is begin    if Index = 0 then       raise Underflow;    end if;    E := Space(Index);    Index := Index - 1; end Pop;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> end Stack;</syntaxhighlight></p> Instances of this generic package can be obtained as follows: <p><syntaxhighlight lang="Ada"> package Stack_Int  is new Stack(Size => 200, Item => Integer); package Stack_Bool is new Stack(100, Boolean);</syntaxhighlight></p> Thereafter, the procedures of the instantiated packages can be called as follows: <p><syntaxhighlight lang="Ada"> Stack_Int.Push(N); Stack_Bool.Push(True);</syntaxhighlight></p> Alternatively, a generic formulation of the type Stack can be given as follows (package body omitted): <p><syntaxhighlight lang="Ada"> generic type Item is private; package On_Stacks is type Stack(Size : Positive) is limited private; procedure Push(S : in out Stack; E : in  Item); procedure Pop (S : in out Stack; E : out Item); Overflow, Underflow : exception; private type Table is array (Positive range <>) of Item; type Stack(Size : Positive) is    record       Space : Table(1 .. Size);       Index : Natural := 0;    end record; end On_Stacks;</syntaxhighlight></p> In order to use such a package, an instance has to be created and thereafter stacks of the corresponding type can be declared: <p><syntaxhighlight lang="Ada"> declare package Stack_Real is new On_Stacks(Real); use Stack_Real; S : Stack(100); begin ... Push(S, 2.54); ... end;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12-7|Previous]] | [[Guide:95lrm/RM-13|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 2nbk3j81fqbju0g2zgwpdppbxyj82si Guide:95lrm/RM-13 4200 902 3672 3671 2019-05-04T23:35:47Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12-8|Previous]] | [[Guide:95lrm/RM-13-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Section 13: Representation Issues}} This section describes features for querying and controlling certain aspects of entities and for interfacing to hardware. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-12-8|Previous]] | [[Guide:95lrm/RM-13-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} boopo3rohhs3nakar0e3sdwbvy6m2cp Guide:95lrm/RM-13-1 4200 903 3674 3673 2019-05-04T23:35:47Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13|Previous]] | [[Guide:95lrm/RM-13-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.1 Operational and Representation Items}} <p><span></span></p> <div> Representation and operational items can be used to specify aspects of entities. Two kinds of aspects of entities can be specified: aspects of representation and operational aspects. Representation items specify how the types and other entities of the language are to be mapped onto the underlying machine. Operational items specify other properties of entities. <span id="I4115"></span><span id="I4116"></span><span id="I4117"></span>There are six kinds of ''representation items'': attribute_definition_clauses for representation attributes, enumeration_representation_clauses, record_representation_clauses, at_clauses, component_clauses, and ''representation pragmas''. They can be provided to give more efficient representation or to interface with features that are outside the domain of the language (for example, peripheral hardware). An <span id="I4118"></span>''operational item'' is an attribute_definition_clause for an operational attribute. An operational item or a representation item applies to an entity identified by a local_name, which denotes an entity declared local to the current declarative region, or a library unit declared immediately preceding a representation pragma in a compilation. </div> == Syntax == <p><span></span></p> aspect_clause<span id="I4119"></span> ::= <span id="I4120"></span>attribute_definition_clause | <span id="I4121"></span>enumeration_representation_clause | <span id="I4122"></span>record_representation_clause | <span id="I4123"></span>at_clause <p><span></span></p> local_name<span id="I4124"></span> ::= <span id="I4125"></span>direct_name | <span id="I4126"></span>direct_name'<span id="I4127"></span>attribute_designator | ''library_unit_''<span id="I4128"></span>name A representation pragma is allowed only at places where an aspect_clause or compilation_unit is allowed. <span id="I4129"></span> == Name Resolution Rules == In an operational item or representation item, if the local_name is a direct_name, then it shall resolve to denote a declaration (or, in the case of a pragma, one or more declarations) that occurs immediately within the same declarative_region as the item. If the local_name has an attribute_designator, then it shall resolve to denote an implementation-defined component (see [[Guide:95lrm/RM-13-5-1|13.5.1]]) or a class-wide type implicitly declared immediately within the same declarative_region as the item. A local_name that is a ''library_unit_''name (only permitted in a representation pragma) shall resolve to denote the library_item that immediately precedes (except for other pragmas) the representation pragma. == Legality Rules == The local_name of an aspect_clause or representation pragma shall statically denote an entity (or, in the case of a pragma, one or more entities) declared immediately preceding it in a compilation, or within the same declarative_part, package_specification, task_definition, protected_definition, or record_definition as the representation or operational item. If a local_name denotes a local callable entity, it may do so through a local subprogram_renaming_declaration (as a way to resolve ambiguity in the presence of overloading); otherwise, the local_name shall not denote a renaming_declaration. <span id="I4130"></span><span id="I4131"></span>The ''representation'' of an object consists of a certain number of bits (the ''size'' of the object). These are the bits that are normally read or updated by the machine code when loading, storing, or operating-on the value of the object. This includes some padding bits, when the size of the object is greater than the size of its subtype. <span id="I4132"></span><span id="I4133"></span>Such padding bits are considered to be part of the representation of the object, rather than being gaps between objects, if these bits are normally read and updated. <span id="I4134"></span><span id="I4135"></span><span id="I4136"></span>A representation item ''directly specifies'' an ''aspect of representation'' of the entity denoted by the local_name, except in the case of a type-related representation item, whose local_name shall denote a first subtype, and which directly specifies an aspect of the subtype's type. <span id="I4137"></span><span id="I4138"></span><span id="I4139"></span><span id="I4140"></span>A representation item that names a subtype is either ''subtype-specific'' (Size and Alignment clauses) or ''type-related'' (all others). Subtype-specific aspects may differ for different subtypes of the same type. <div> An operational item ''directly specifies'' an ''operational aspect'' of the type of the subtype denoted by the local_name. The local_name of an operational item shall denote a first subtype. An operational item that names a subtype is type-related. <span id="I4141"></span><span id="I4142"></span><span id="I4143"></span><span id="I4144"></span> </div> A representation item that directly specifies an aspect of a subtype or type shall appear after the type is completely defined (see [[Guide:95lrm/RM-3-11-1|3.11.1]]), and before the subtype or type is frozen (see [[Guide:95lrm/RM-13-14|13.14]]). If a representation item is given that directly specifies an aspect of an entity, then it is illegal to give another representation item that directly specifies the same aspect of the entity. <div> An operational item that directly specifies an aspect of a type shall appear before the type is frozen (see [[Guide:95lrm/RM-13-14|13.14]]). If an operational item is given that directly specifies an aspect of a type, then it is illegal to give another operational item that directly specifies the same aspect of the type. </div> For an untagged derived type, no type-related representation items are allowed if the parent type is a by-reference type, or has any user-defined primitive subprograms. Operational and representation aspects of a generic formal parameter are the same as those of the actual. Operational and representation aspects of a partial view are the same as those of the full view. A type-related representation item is not allowed for a descendant of a generic formal untagged type. A representation item that specifies the Size for a given subtype, or the size or storage place for an object (including a component) of a given subtype, shall allow for enough storage space to accommodate any value of the subtype. A representation or operational item that is not supported by the implementation is illegal, or raises an exception at run time. == Static Semantics == If two subtypes statically match, then their subtype-specific aspects (Size and Alignment) are the same. <span id="I4145"></span> A derived type inherits each type-related aspect of representation of its parent type that was directly specified before the declaration of the derived type, or (in the case where the parent is derived) that was inherited by the parent type from the grandparent type. A derived subtype inherits each subtype-specific aspect of representation of its parent subtype that was directly specified before the declaration of the derived type, or (in the case where the parent is derived) that was inherited by the parent subtype from the grandparent subtype, but only if the parent subtype statically matches the first subtype of the parent type. An inherited aspect of representation is overridden by a subsequent representation item that specifies the same aspect of the type or subtype. <div> In contrast, whether operational aspects are inherited by a derived type depends on each specific aspect. When operational aspects are inherited by a derived type, aspects that were directly specified before the declaration of the derived type, or (in the case where the parent is derived) that were inherited by the parent type from the grandparent type are inherited. An inherited operational aspect is overridden by a subsequent operational item that specifies the same aspect of the type. </div> Each aspect of representation of an entity is as follows: * <span id="I4146"></span>If the aspect is ''specified'' for the entity, meaning that it is either directly specified or inherited, then that aspect of the entity is as specified, except in the case of Storage_Size, which specifies a minimum. * <span id="I4147"></span>If an aspect of representation of an entity is not specified, it is chosen by default in an unspecified manner. <div> <span id="I4148"></span>If an operational aspect is ''specified'' for an entity (meaning that it is either directly specified or inherited), then that aspect of the entity is as specified. Otherwise, the aspect of the entity has the default value for that aspect. </div> == Dynamic Semantics == <span id="I4149"></span>For the elaboration of a aspect_clause, any evaluable constructs within it are evaluated. == Implementation Permissions == An implementation may interpret aspects of representation in an implementation-defined manner. An implementation may place implementation-defined restrictions on representation items. <span id="I4150"></span>A ''recommended level of support'' is specified for representation items and related features in each subclause. These recommendations are changed to requirements for implementations that support the Systems Programming Annex (see [[Guide:95lrm/RM-C-2|C.2]], ''[[Guide:95lrm/RM-C-2|Required Representation Support]]''). == Implementation Advice == <span id="I4151"></span>The recommended level of support for all representation items is qualified as follows: * An implementation need not support representation items containing nonstatic expressions, except that an implementation should support a representation item for a given entity if each nonstatic expression in the representation item is a name that statically denotes a constant declared before the entity. * An implementation need not support a specification for the Size for a given composite subtype, nor the size or storage place for an object (including a component) of a given composite subtype, unless the constraints on the subtype and its composite subcomponents (if any) are all static constraints. * An aliased component, or a component whose type is by-reference, should always be allocated at an addressable location. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13|Previous]] | [[Guide:95lrm/RM-13-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 9jgvo9ern3gshb2buxevqxsk9xgr6nu Guide:95lrm/RM-13-10 4200 904 3676 3675 2019-05-04T23:35:47Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-9-2|Previous]] | [[Guide:95lrm/RM-13-11|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.10 Unchecked Access Value Creation}} The attribute Unchecked_Access is used to create access values in an unsafe manner -- the programmer is responsible for preventing ''dangling references.'' == Static Semantics == The following attribute is defined for a prefix X that denotes an aliased view of an object: ; X'Unchecked_Access : <span id="I4392"></span><span id="I4393"></span>All rules and semantics that apply to X'Access (see [[Guide:95lrm/RM-3-10-2|3.10.2]]) apply also to X'Unchecked_Access, except that, for the purposes of accessibility rules and checks, it is as if X were declared immediately within a library package. <span id="I4394"></span> == Notes == 21  This attribute is provided to support the situation where a local object is to be inserted into a global linked data structure, when the programmer knows that it will always be removed from the data structure prior to exiting the object's scope. The Access attribute would be illegal in this case (see [[Guide:95lrm/RM-3-10-2|3.10.2]], ''[[Guide:95lrm/RM-3-10-2|Operations of Access Types]]''). 22  There is no Unchecked_Access attribute for subprograms. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-9-2|Previous]] | [[Guide:95lrm/RM-13-11|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 45y0ho3q1j6fciynqv18e4al9as6ykr Guide:95lrm/RM-13-11 4200 905 3678 3677 2019-05-04T23:35:51Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-10|Previous]] | [[Guide:95lrm/RM-13-11-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.11 Storage Management}} <span id="I4395"></span><span id="I4396"></span><span id="I4397"></span><span id="I4398"></span>Each access-to-object type has an associated storage pool. The storage allocated by an allocator comes from the pool; instances of Unchecked_Deallocation return storage to the pool. Several access types can share the same pool. A storage pool is a variable of a type in the class rooted at Root_Storage_Pool, which is an abstract limited controlled type. By default, the implementation chooses a ''standard storage pool'' for each access type. The user may define new pool types, and may override the choice of pool for an access type by specifying Storage_Pool for the type. == Legality Rules == If Storage_Pool is specified for a given access type, Storage_Size shall not be specified for it. == Static Semantics == The following language-defined library package exists: <p><syntaxhighlight lang="Ada"> with Ada.Finalization; with System.Storage_Elements; package System.Storage_Pools is  pragma Preelaborate(System.Storage_Pools);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     type Root_Storage_Pool is      abstract new Ada.Finalization.Limited_Controlled with private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     procedure Allocate(    Pool : in out Root_Storage_Pool;    Storage_Address : out Address;    Size_In_Storage_Elements : in Storage_Elements.Storage_Count;    Alignment : in Storage_Elements.Storage_Count) is abstract;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Deallocate(    Pool : in out Root_Storage_Pool;    Storage_Address : in Address;    Size_In_Storage_Elements : in Storage_Elements.Storage_Count;    Alignment : in Storage_Elements.Storage_Count) is abstract;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     function Storage_Size(Pool : Root_Storage_Pool)      return Storage_Elements.Storage_Count is abstract;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> private ... -- not specified by the language end System.Storage_Pools;</syntaxhighlight></p> <span id="I4410"></span><span id="I4411"></span>A ''storage pool type'' (or ''pool type'') is a descendant of Root_Storage_Pool. <span id="I4412"></span><span id="I4413"></span><span id="I4414"></span>The ''elements'' of a storage pool are the objects allocated in the pool by allocators. For every access subtype S, the following representation attributes are defined: ;  S'Storage_Pool : <span id="I4415"></span><span id="I4416"></span>Denotes the storage pool of the type of S. The type of this attribute is Root_Storage_Pool'Class. ;  S'Storage_Size : <span id="I4417"></span><span id="I4418"></span>Yields the result of calling Storage_Size(S'Storage_Pool), which is intended to be a measure of the number of storage elements reserved for the pool. The type of this attribute is ''universal_integer''. <span id="I4419"></span><span id="I4420"></span><span id="I4421"></span><span id="I4422"></span>Storage_Size or Storage_Pool may be specified for a non-derived access-to-object type via an attribute_definition_clause; the name in a Storage_Pool clause shall denote a variable. An allocator of type T allocates storage from T's storage pool. If the storage pool is a user-defined object, then the storage is allocated by calling Allocate, passing T'Storage_Pool as the Pool parameter. The Size_In_Storage_Elements parameter indicates the number of storage elements to be allocated, and is no more than D'Max_Size_In_Storage_Elements, where D is the designated subtype. The Alignment parameter is D'Alignment. <span id="I4423"></span><span id="I4424"></span>The result returned in the Storage_Address parameter is used by the allocator as the address of the allocated storage, which is a contiguous block of memory of Size_In_Storage_Elements storage elements. Any exception propagated by Allocate is propagated by the allocator. <span id="I4425"></span>If Storage_Pool is not specified for a type defined by an access_to_object_definition, then the implementation chooses a standard storage pool for it in an implementation-defined manner. <span id="I4426"></span><span id="I4427"></span><span id="I4428"></span>In this case, the exception Storage_Error is raised by an allocator if there is not enough storage. It is implementation defined whether or not the implementation provides user-accessible names for the standard pool type(s). If Storage_Size is specified for an access type, then the Storage_Size of this pool is at least that requested, and the storage for the pool is reclaimed when the master containing the declaration of the access type is left. <span id="I4429"></span>If the implementation cannot satisfy the request, Storage_Error is raised at the point of the attribute_definition_clause. If neither Storage_Pool nor Storage_Size are specified, then the meaning of Storage_Size is implementation defined. If Storage_Pool is specified for an access type, then the specified pool is used. <span id="I4430"></span>The effect of calling Allocate and Deallocate for a standard storage pool directly (rather than implicitly via an allocator or an instance of Unchecked_Deallocation) is unspecified. == Erroneous Execution == <span id="I4431"></span>If Storage_Pool is specified for an access type, then if Allocate can satisfy the request, it should allocate a contiguous block of memory, and return the address of the first storage element in Storage_Address. The block should contain Size_In_Storage_Elements storage elements, and should be aligned according to Alignment. The allocated storage should not be used for any other purpose while the pool element remains in existence. If the request cannot be satisfied, then Allocate should propagate an exception (such as Storage_Error). If Allocate behaves in any other manner, then the program execution is erroneous. == Documentation Requirements == An implementation shall document the set of values that a user-defined Allocate procedure needs to accept for the Alignment parameter. An implementation shall document how the standard storage pool is chosen, and how storage is allocated by standard storage pools. == Implementation Advice == An implementation should document any cases in which it dynamically allocates heap storage for a purpose other than the evaluation of an allocator. A default (implementation-provided) storage pool for an access-to-constant type should not have overhead to support deallocation of individual objects. A storage pool for an anonymous access type should be created at the point of an allocator for the type, and be reclaimed when the designated object becomes inaccessible. == Notes == 23  A user-defined storage pool type can be obtained by extending the Root_Storage_Pool type, and overriding the primitive subprograms Allocate, Deallocate, and Storage_Size. A user-defined storage pool can then be obtained by declaring an object of the type extension. The user can override Initialize and Finalize if there is any need for non-trivial initialization and finalization for a user-defined pool type. For example, Finalize might reclaim blocks of storage that are allocated separately from the pool object itself. 24  The writer of the user-defined allocation and deallocation procedures, and users of allocators for the associated access type, are responsible for dealing with any interactions with tasking. In particular: * If the allocators are used in different tasks, they require mutual exclusion. * If they are used inside protected objects, they cannot block. * If they are used by interrupt handlers (see [[Guide:95lrm/RM-C-3|C.3]], ''[[Guide:95lrm/RM-C-3|Interrupt Support]]''), the mutual exclusion mechanism has to work properly in that context. 25  The primitives Allocate, Deallocate, and Storage_Size are declared as abstract (see [[Guide:95lrm/RM-3-9-3|3.9.3]]), and therefore they have to be overridden when a new (non-abstract) storage pool type is declared. == Examples == To associate an access type with a storage pool object, the user first declares a pool object of some type derived from Root_Storage_Pool. Then, the user defines its Storage_Pool attribute, as follows: <p><syntaxhighlight lang="Ada"> Pool_Object : Some_Storage_Pool_Type;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type T is access Designated; for T'Storage_Pool use Pool_Object;</syntaxhighlight></p> Another access type may be added to an existing storage pool, via: <p><syntaxhighlight lang="Ada"> for T2'Storage_Pool use T'Storage_Pool;</syntaxhighlight></p> The semantics of this is implementation defined for a standard storage pool. As usual, a derivative of Root_Storage_Pool may define additional operations. For example, presuming that Mark_Release_Pool_Type has two additional operations, Mark and Release, the following is a possible use: <p><syntaxhighlight lang="Ada"> type Mark_Release_Pool_Type (Pool_Size : Storage_Elements.Storage_Count;  Block_Size : Storage_Elements.Storage_Count)      is new Root_Storage_Pool with private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> ...</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> MR_Pool : Mark_Release_Pool_Type (Pool_Size => 2000,                                Block_Size => 100);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Acc is access ...; for Acc'Storage_Pool use MR_Pool; ...</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Mark(MR_Pool); ... -- Allocate objects using ''new Designated(...)''. Release(MR_Pool); -- Reclaim the storage.</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-10|Previous]] | [[Guide:95lrm/RM-13-11-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} hwvcvbr6qkigd7en3k7ly599jydrd1s Guide:95lrm/RM-13-11-1 4200 906 3680 3679 2019-05-04T23:35:53Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-11|Previous]] | [[Guide:95lrm/RM-13-11-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.11.1 The Max_Size_In_Storage_Elements Attribute}} The Max_Size_In_Storage_Elements attribute is useful in writing user-defined pool types. == Static Semantics == For every subtype S, the following attribute is defined: ; S'Max_Size_In_Storage_Elements : <span id="I4432"></span><span id="I4433"></span>Denotes the maximum value for Size_In_Storage_Elements that will be requested via Allocate for an access type whose designated subtype is S. The value of this attribute is of type ''universal_integer''. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-11|Previous]] | [[Guide:95lrm/RM-13-11-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} iw38jqbff95xqj467hjhfidwo3hso1r Guide:95lrm/RM-13-11-2 4200 907 3682 3681 2019-05-04T23:35:54Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-11-1|Previous]] | [[Guide:95lrm/RM-13-11-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.11.2 Unchecked Storage Deallocation}} <span id="I4434"></span><span id="I4435"></span><span id="I4436"></span><span id="I4437"></span><span id="I4438"></span>Unchecked storage deallocation of an object designated by a value of an access type is achieved by a call to an instance of the generic procedure Unchecked_Deallocation. == Static Semantics == The following language-defined generic library procedure exists: <p><syntaxhighlight lang="Ada"> generic type Object(<>) is limited private; type Name   is access  Object; procedure Ada.Unchecked_Deallocation(X : in out Name); pragma Convention(Intrinsic, Ada.Unchecked_Deallocation); pragma Preelaborate(Ada.Unchecked_Deallocation);</syntaxhighlight></p> == Dynamic Semantics == Given an instance of Unchecked_Deallocation declared as follows: <p><syntaxhighlight lang="Ada"> procedure Free is   new Ada.Unchecked_Deallocation(      object_subtype_name, access_to_variable_subtype_name);</syntaxhighlight></p> Procedure Free has the following effect: ; 1. : After executing Free(X), the value of X is '''null'''. ; 2. : Free(X), when X is already equal to '''null''', has no effect. ; 3. : Free(X), when X is not equal to '''null''' first performs finalization, as described in [[Guide:95lrm/RM-7-6|7.6]]. It then deallocates the storage occupied by the object designated by X. If the storage pool is a user-defined object, then the storage is deallocated by calling Deallocate, passing ''access_to_variable_subtype_name'''Storage_Pool as the Pool parameter. Storage_Address is the value returned in the Storage_Address parameter of the corresponding Allocate call. Size_In_Storage_Elements and Alignment are the same values passed to the corresponding Allocate call. There is one exception: if the object being freed contains tasks, the object might not be deallocated. <span id="I4442"></span><span id="I4443"></span>After Free(X), the object designated by X, and any subcomponents thereof, no longer exist; their storage can be reused for other purposes. == Bounded (Run-Time) Errors == <span id="I4444"></span>It is a bounded error to free a discriminated, unterminated task object. The possible consequences are: * No exception is raised. * <span id="I4445"></span><span id="I4446"></span>Program_Error or Tasking_Error is raised at the point of the deallocation. * <span id="I4447"></span><span id="I4448"></span>Program_Error or Tasking_Error is raised in the task the next time it references any of the discriminants. In the first two cases, the storage for the discriminants (and for any enclosing object if it is designated by an access discriminant of the task) is not reclaimed prior to task termination. == Erroneous Execution == <span id="I4449"></span><span id="I4450"></span>Evaluating a name that denotes a nonexistent object is erroneous. The execution of a call to an instance of Unchecked_Deallocation is erroneous if the object was created other than by an allocator for an access type whose pool is Name'Storage_Pool. == Implementation Advice == For a standard storage pool, Free should actually reclaim the storage. == Notes == 26  The rules here that refer to Free apply to any instance of Unchecked_Deallocation. 27  Unchecked_Deallocation cannot be instantiated for an access-to-constant type. This is implied by the rules of [[Guide:95lrm/RM-12-5-4|12.5.4]]. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-11-1|Previous]] | [[Guide:95lrm/RM-13-11-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} f19n9a1xjp68n7i9ekpaoa9ngialwtr Guide:95lrm/RM-13-11-3 4200 908 3684 3683 2019-05-04T23:35:54Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-11-2|Previous]] | [[Guide:95lrm/RM-13-12|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.11.3 Pragma Controlled}} Pragma Controlled is used to prevent any automatic reclamation of storage (garbage collection) for the objects created by allocators of a given access type. == Syntax == The form of a pragma Controlled is as follows: <p><span></span></p> '''pragma''' <span id="I4451"></span><span id="I4452"></span>Controlled(''first_subtype_''<span id="I4453"></span>local_name); == Legality Rules == The ''first_subtype_''local_name of a pragma Controlled shall denote a non-derived access subtype. == Static Semantics == <span id="I4454"></span><span id="I4455"></span>A pragma Controlled is a representation pragma <span id="I4456"></span><span id="I4457"></span>that specifies the ''controlled'' aspect of representation. <span id="I4458"></span>''Garbage collection'' is a process that automatically reclaims storage, or moves objects to a different address, while the objects still exist. If a pragma Controlled is specified for an access type with a standard storage pool, then garbage collection is not performed for objects in that pool. == Implementation Permissions == An implementation need not support garbage collection, in which case, a pragma Controlled has no effect. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-11-2|Previous]] | [[Guide:95lrm/RM-13-12|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} kdl836nfrbn7bjbz7re88sjy9zdt1os Guide:95lrm/RM-13-12 4200 909 3686 3685 2019-05-04T23:35:54Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-11-3|Previous]] | [[Guide:95lrm/RM-13-13|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.12 Pragma Restrictions}} A pragma Restrictions expresses the user's intent to abide by certain restrictions. This may facilitate the construction of simpler run-time environments. == Syntax == The form of a pragma Restrictions is as follows: <p><span></span></p> '''pragma''' <span id="I4459"></span><span id="I4460"></span>Restrictions(<span id="I4461"></span>restriction{, <span id="I4462"></span>restriction}); <p><span></span></p> restriction<span id="I4463"></span> ::= ''restriction_''<span id="I4464"></span>identifier | ''restriction_parameter_''<span id="I4465"></span>identifier => <span id="I4466"></span>expression == Name Resolution Rules == <span id="I4467"></span>Unless otherwise specified for a particular restriction, the expression is expected to be of any integer type. == Legality Rules == Unless otherwise specified for a particular restriction, the expression shall be static, and its value shall be nonnegative. == Static Semantics == The set of restrictions is implementation defined. == Post-Compilation Rules == <span id="I4468"></span><span id="I4469"></span>A pragma Restrictions is a configuration pragma; unless otherwise specified for a particular restriction, a partition shall obey the restriction if a pragma Restrictions applies to any compilation unit included in the partition. <div> For the purpose of checking whether a partition contains constructs that violate any restriction (unless specified otherwise for a particular restriction): * Generic instances are logically expanded at the point of instantiation; * If an object of a type is declared or allocated and not explicitly initialized, then all expressions appearing in the definition for the type and any of its ancestors are presumed to be used; * A default_expression for a formal parameter or a generic formal object is considered to be used if and only if the corresponding actual parameter is not provided in a given call or instantiation. </div> == Implementation Permissions == An implementation may place limitations on the values of the expression that are supported, and limitations on the supported combinations of restrictions. The consequences of violating such limitations are implementation defined. <div> An implementation is permitted to omit restriction checks for code that is recognized at compile time to be unreachable and for which no code is generated. Whenever enforcement of a restriction is not required prior to execution, an implementation may nevertheless enforce the restriction prior to execution of a partition to which the restriction applies, provided that every execution of the partition would violate the restriction. </div> == Notes == 28  Restrictions intended to facilitate the construction of efficient tasking run-time systems are defined in [[Guide:95lrm/RM-D-7|D.7]]. Safety- and security-related restrictions are defined in [[Guide:95lrm/RM-H-4|H.4]]. 29  An implementation has to enforce the restrictions in cases where enforcement is required, even if it chooses not to take advantage of the restrictions in terms of efficiency. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-11-3|Previous]] | [[Guide:95lrm/RM-13-13|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} jimsgpm1a9ttbua3pgtst8zteke9vj9 Guide:95lrm/RM-13-13 4200 910 3688 3687 2019-05-04T23:35:54Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-12|Previous]] | [[Guide:95lrm/RM-13-13-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.13 Streams}} <span id="I4470"></span><span id="I4471"></span>A ''stream'' is a sequence of elements comprising values from possibly different types and allowing sequential access to these values. A ''stream type'' is a type in the class whose root type is Streams.Root_Stream_Type. A stream type may be implemented in various ways, such as an external sequential file, an internal buffer, or a network channel. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-12|Previous]] | [[Guide:95lrm/RM-13-13-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 0y4yrm1y4bz9gboz6h14jyzfawkqzhz Guide:95lrm/RM-13-13-1 4200 911 3690 3689 2019-05-04T23:35:56Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-13|Previous]] | [[Guide:95lrm/RM-13-13-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.13.1 The Package Streams}} == Static Semantics == The abstract type Root_Stream_Type is the root type of the class of stream types. The types in this class represent different kinds of streams. A new stream type is defined by extending the root type (or some other stream type), overriding the Read and Write operations, and optionally defining additional primitive subprograms, according to the requirements of the particular kind of stream. The predefined stream-oriented attributes like T'Read and T'Write make dispatching calls on the Read and Write procedures of the Root_Stream_Type. (User-defined T'Read and T'Write attributes can also make such calls, or can call the Read and Write attributes of other types.) <p><syntaxhighlight lang="Ada"> package Ada.Streams is  pragma Pure(Streams);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     type Root_Stream_Type is abstract tagged limited private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     type Stream_Element is mod implementation-defined;  type Stream_Element_Offset is range implementation-defined;  subtype Stream_Element_Count is      Stream_Element_Offset range 0..Stream_Element_Offset'Last;  type Stream_Element_Array is      array(Stream_Element_Offset range <>) of aliased Stream_Element;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     procedure Read(    Stream : in out Root_Stream_Type;    Item   : out Stream_Element_Array;    Last   : out Stream_Element_Offset) is abstract;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     procedure Write(    Stream : in out Root_Stream_Type;    Item   : in Stream_Element_Array) is abstract;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> private ... -- not specified by the language end Ada.Streams;</syntaxhighlight></p> The Read operation transfers Item'Length stream elements from the specified stream to fill the array Item. The index of the last stream element transferred is returned in Last. Last is less than Item'Last only if the end of the stream is reached. The Write operation appends Item to the specified stream. == Implementation Permissions == If Stream_Element'Size is not a multiple of System.Storage_Unit, then the components of Stream_Element_Array need not be aliased. == Notes == 30  See [[Guide:95lrm/RM-A-12-1|A.12.1]], ''[[Guide:95lrm/RM-A-12-1|The Package Streams.Stream_IO]]'' for an example of extending type Root_Stream_Type. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-13|Previous]] | [[Guide:95lrm/RM-13-13-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 9pwwx2wdiiej3jn6fd5rdv4vg29rvjm Guide:95lrm/RM-13-13-2 4200 912 3692 3691 2019-05-04T23:35:59Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-13-1|Previous]] | [[Guide:95lrm/RM-13-14|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.13.2 Stream-Oriented Attributes}} The operational attributes Write, Read, Output, and Input convert values to a stream of elements and reconstruct values from a stream. == Static Semantics == For every subtype S of a specific type ''T'', the following attributes are defined. ; S'Write : <span id="I4489"></span><span id="I4490"></span>S'Write denotes a procedure with the following specification: <p><syntaxhighlight lang="Ada"> procedure S'Write( Stream : access Ada.Streams.Root_Stream_Type'Class; Item : in T)</syntaxhighlight></p> S'Write writes the value of ''Item'' to ''Stream''. ; S'Read : <span id="I4491"></span><span id="I4492"></span>S'Read denotes a procedure with the following specification: <p><syntaxhighlight lang="Ada"> procedure S'Read( Stream : access Ada.Streams.Root_Stream_Type'Class; Item : out T)</syntaxhighlight></p> <p><span></span></p> :S'Read reads the value of ''Item'' from ''Stream''. <div> For untagged derived types, the Write and Read attributes of the parent type are inherited as specified in [[Guide:95lrm/RM-13-1|13.1]]; otherwise, the default implementations of these attributes are used. The default implementations of Write and Read attributes execute as follows: </div> For elementary types, the representation in terms of stream elements is implementation defined. For composite types, the Write or Read attribute for each component is called in canonical order, which is last dimension varying fastest for an array, and positional aggregate order for a record. Bounds are not included in the stream if ''T'' is an array type. If ''T'' is a discriminated type, discriminants are included only if they have defaults. If ''T'' is a tagged type, the tag is not included. For type extensions, the Write or Read attribute for the parent type is called, followed by the Write or Read attribute of each component of the extension part, in canonical order. For a limited type extension, if the attribute of any ancestor type of ''T'' has been directly specified and the attribute of any ancestor type of the type of any of the extension components which are of a limited type has not been specified, the attribute of ''T'' shall be directly specified. For every subtype S'Class of a class-wide type ''T'''Class: ;  S'Class'Write : <span id="I4493"></span><span id="I4494"></span>S'Class'Write denotes a procedure with the following specification: <p><syntaxhighlight lang="Ada"> procedure S'Class'Write( Stream : access Ada.Streams.Root_Stream_Type'Class; Item   : in T'Class)</syntaxhighlight></p> Dispatches to the subprogram denoted by the Write attribute of the specific type identified by the tag of Item. ;  S'Class'Read : <span id="I4495"></span><span id="I4496"></span>S'Class'Read denotes a procedure with the following specification: <p><syntaxhighlight lang="Ada"> procedure S'Class'Read( Stream : access Ada.Streams.Root_Stream_Type'Class; Item : out T'Class)</syntaxhighlight></p> Dispatches to the subprogram denoted by the Read attribute of the specific type identified by the tag of Item. == Implementation Advice == If a stream element is the same size as a storage element, then the normal in-memory representation should be used by Read and Write for scalar objects. Otherwise, Read and Write should use the smallest number of stream elements needed to represent all values in the base range of the scalar type. == Static Semantics == For every subtype S of a specific type ''T'', the following attributes are defined. ;  S'Output : <span id="I4497"></span><span id="I4498"></span>S'Output denotes a procedure with the following specification: <p><syntaxhighlight lang="Ada"> procedure S'Output( Stream : access Ada.Streams.Root_Stream_Type'Class; Item : in T)</syntaxhighlight></p> <p><span></span></p> :S'Output writes the value of ''Item'' to ''Stream'', including any bounds or discriminants. ;  S'Input : <span id="I4499"></span><span id="I4500"></span>S'Input denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Input( Stream : access Ada.Streams.Root_Stream_Type'Class) return T</syntaxhighlight></p> <p><span></span></p> :S'Input reads and returns one value from ''Stream'', using any bounds or discriminants written by a corresponding S'Output to determine how much to read. For untagged derived types, the Output and Input attributes of the parent type are inherited as specified in [[Guide:95lrm/RM-13-1|13.1]]; otherwise, the default implementations of these attributes are used. The default implementations of Output and Input attributes execute as follows: * If ''T'' is an array type, S'Output first writes the bounds, and S'Input first reads the bounds. If ''T'' has discriminants without defaults, S'Output first writes the discriminants (using S'Write for each), and S'Input first reads the discriminants (using S'Read for each). * S'Output then calls S'Write to write the value of ''Item'' to the stream. S'Input then creates an object (with the bounds or discriminants, if any, taken from the stream), initializes it with S'Read, and returns the value of the object. For every subtype S'Class of a class-wide type ''T'''Class: ;  S'Class'Output : <span id="I4501"></span><span id="I4502"></span>S'Class'Output denotes a procedure with the following specification: <p><syntaxhighlight lang="Ada"> procedure S'Class'Output( Stream : access Ada.Streams.Root_Stream_Type'Class; Item   : in T'Class)</syntaxhighlight></p> <p><span></span></p> :First writes the external tag of ''Item'' to ''Stream'' (by calling String'Output(Tags.External_Tag(''Item'''Tag) -- see [[Guide:95lrm/RM-3-9|3.9]]) and then dispatches to the subprogram denoted by the Output attribute of the specific type identified by the tag. ;  S'Class'Input : <span id="I4503"></span><span id="I4504"></span>S'Class'Input denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Class'Input( Stream : access Ada.Streams.Root_Stream_Type'Class) return T'Class</syntaxhighlight></p> <p><span></span></p> :First reads the external tag from ''Stream'' and determines the corresponding internal tag (by calling Tags.Internal_Tag(String'Input(''Stream'')) -- see [[Guide:95lrm/RM-3-9|3.9]]) and then dispatches to the subprogram denoted by the Input attribute of the specific type identified by the internal tag; returns that result. <span id="I4505"></span><span id="I4506"></span>In the default implementation of Read and Input for a composite type, for each scalar component that is a discriminant or whose component_declaration includes a default_expression, a check is made that the value returned by Read for the component belongs to its subtype. <span id="I4507"></span>Constraint_Error is raised if this check fails. For other scalar components, no check is made. For each component that is of an access type, if the implementation can detect that the value returned by Read for the component is not a value of its subtype, Constraint_Error is raised. If the value is not a value of its subtype and this error is not detected, the component has an abnormal value, and erroneous execution can result (see [[Guide:95lrm/RM-13-9-1|13.9.1]]). <div> <span id="I4508"></span>In the default implementation of Read and Input for a type, End_Error is raised if the end of the stream is reached before the reading of a value of the type is completed. </div> <span id="I4509"></span><span id="I4510"></span><span id="I4511"></span><span id="I4512"></span><span id="I4513"></span><span id="I4514"></span><span id="I4515"></span><span id="I4516"></span>The stream-oriented attributes may be specified for any type via an attribute_definition_clause. All nonlimited types have default implementations for these operations. An attribute_reference for one of these attributes is illegal if the type is limited, unless the attribute has been specified by an attribute_definition_clause or (for a type extension) the attribute has been specified for an ancestor type. For an attribute_definition_clause specifying one of these attributes, the subtype of the Item parameter shall be the base subtype if scalar, and the first subtype otherwise. The same rule applies to the result of the Input function. == Implementation Requirements == <div> For every subtype ''S'' of a language-defined nonlimited specific type ''T'', the output generated by S'Output or S'Write shall be readable by S'Input or S'Read, respectively. This rule applies across partitions if the implementation conforms to the Distributed Systems Annex. </div> == Notes == 31  For a definite subtype S of a type ''T'', only ''T'''Write and ''T'''Read are needed to pass an arbitrary value of the subtype through a stream. For an indefinite subtype S of a type ''T'', ''T'''Output and ''T'''Input will normally be needed, since ''T'''Write and ''T'''Read do not pass bounds, discriminants, or tags. 32  User-specified attributes of S'Class are not inherited by other class-wide types descended from S. == Examples == ''Example of user-defined Write attribute:'' <p><syntaxhighlight lang="Ada"> procedure My_Write( Stream : access Ada.Streams.Root_Stream_Type'Class; Item : My_Integer'Base); for My_Integer'Write use My_Write;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-13-1|Previous]] | [[Guide:95lrm/RM-13-14|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 032rq7lsnhz4dgy2rc45gfego96eusc Guide:95lrm/RM-13-14 4200 913 3694 3693 2019-05-04T23:36:01Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-13-2|Previous]] | [[Guide:95lrm/RM-0-28|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.14 Freezing Rules}} 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. <span id="I4517"></span><span id="I4518"></span>The ''freezing'' of an entity occurs at one or more places (''freezing points'') 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 [[Guide:95lrm/RM-10-1-4|10.1.4]]). <span id="I4519"></span>The end of a declarative_part, protected_body, or a declaration of a library package or generic library package, causes ''freezing'' of each entity declared within it, except for incomplete types. <span id="I4520"></span>A noninstance body other than a renames-as-body causes freezing of each entity declared before it within the same declarative_part. <span id="I4521"></span>A construct that (explicitly or implicitly) references an entity can cause the ''freezing'' of the entity, as defined by subsequent paragraphs. <span id="I4522"></span>At the place where a construct causes freezing, each name, expression, implicit_dereference, or range within the construct causes freezing: * <span id="I4523"></span>The occurrence of a generic_instantiation causes freezing; also, if a parameter of the instantiation is defaulted, the default_expression or default_name for that parameter causes freezing. * <span id="I4524"></span>The occurrence of an object_declaration that has no corresponding completion causes freezing. * <span id="I4525"></span>The declaration of a record extension causes freezing of the parent subtype. <span id="I4526"></span>A static expression causes freezing where it occurs. <span id="I4527"></span>An object name or nonstatic expression causes freezing where it occurs, unless the name or expression is part of a default_expression, a default_name, or a per-object expression of a component's constraint, in which case, the freezing occurs later as part of another construct. <div> <span id="I4528"></span>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. <span id="I4529"></span>If an expression is implicitly converted to a type or subtype ''T'', then at the place where the expression causes freezing, ''T'' is frozen. </div> The following rules define which entities are frozen at the place where a construct causes freezing: * <span id="I4530"></span>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 discrete_choice of the array_aggregate of an enumeration_representation_clause. * <span id="I4531"></span>At the place where a name causes freezing, the entity denoted by the name is frozen, unless the name is a prefix of an expanded name; <span id="I4532"></span>at the place where an object name causes freezing, the nominal subtype associated with the name is frozen. <div> * <span id="I4533"></span>At the place where an implicit_dereference causes freezing, the nominal subtype associated with the implicit_dereference is frozen. </div> * <span id="I4534"></span>At the place where a range causes freezing, the type of the range is frozen. * <span id="I4535"></span>At the place where an allocator causes freezing, the designated subtype of its type is frozen. If the type of the allocator is a derived type, then all ancestor types are also frozen. * <span id="I4536"></span>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. <span id="I4537"></span>At the place where a function call causes freezing, if a parameter of the call is defaulted, the default_expression for that parameter causes freezing. * <span id="I4538"></span>At the place where a subtype is frozen, its type is frozen. <span id="I4539"></span><span id="I4540"></span>At the place where a type is frozen, any expressions or names 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. <span id="I4541"></span><span id="I4542"></span>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. == Legality Rules == The explicit declaration of a primitive subprogram of a tagged type shall occur before the type is frozen (see [[Guide:95lrm/RM-3-9-2|3.9.2]]). A type shall be completely defined before it is frozen (see [[Guide:95lrm/RM-3-11-1|3.11.1]] and [[Guide:95lrm/RM-7-3|7.3]]). The completion of a deferred constant declaration shall occur before the constant is frozen (see [[Guide:95lrm/RM-7-4|7.4]]). An operational or representation item that directly specifies an aspect of an entity shall appear before the entity is frozen (see [[Guide:95lrm/RM-13-1|13.1]]). </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-13-2|Previous]] | [[Guide:95lrm/RM-0-28|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} ftc7z829w3mwtmohbyt8ocr04i0xgy0 Guide:95lrm/RM-13-2 4200 914 3696 3695 2019-05-04T23:36:01Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-1|Previous]] | [[Guide:95lrm/RM-13-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.2 Pragma Pack}} A pragma Pack specifies that storage minimization should be the main criterion when selecting the representation of a composite type. == Syntax == The form of a pragma Pack is as follows: <p><span></span></p> '''pragma''' <span id="I4152"></span><span id="I4153"></span>Pack(''first_subtype_''<span id="I4154"></span>local_name); == Legality Rules == The ''first_subtype_''local_name of a pragma Pack shall denote a composite subtype. == Static Semantics == <span id="I4155"></span><span id="I4156"></span><span id="I4157"></span><span id="I4158"></span><span id="I4159"></span>A pragma Pack specifies the ''packing'' aspect of representation; the type (or the extension part) is said to be ''packed''. For a type extension, the parent part is packed as for the parent type, and a pragma Pack causes packing only of the extension part. == Implementation Advice == If a type is packed, then the implementation should try to minimize storage allocated to objects of the type, possibly at the expense of speed of accessing components, subject to reasonable complexity in addressing calculations. <span id="I4160"></span>The recommended level of support for pragma Pack is: * For a packed record type, the components should be packed as tightly as possible subject to the Sizes of the component subtypes, and subject to any record_representation_clause that applies to the type; the implementation may, but need not, reorder components or cross aligned word boundaries to improve the packing. A component whose Size is greater than the word size may be allocated an integral number of words. * For a packed array type, if the component subtype's Size is less than or equal to the word size, and Component_Size is not specified for the type, Component_Size should be less than or equal to the Size of the component subtype, rounded up to the nearest factor of the word size. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-1|Previous]] | [[Guide:95lrm/RM-13-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 170n718y6kjczk9egn3iap1o0cnj4mi Guide:95lrm/RM-13-3 4200 915 3698 3697 2019-05-04T23:36:02Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-2|Previous]] | [[Guide:95lrm/RM-13-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.3 Operational and Representation Attributes}} <span id="I4161"></span><span id="I4162"></span>The values of certain implementation-dependent characteristics can be obtained by interrogating appropriate operational or representation attributes. <span id="I4163"></span>Some of these attributes are specifiable via an attribute_definition_clause. == Syntax == <p><span></span></p> attribute_definition_clause<span id="I4164"></span> ::= '''for''' <span id="I4165"></span>local_name'<span id="I4166"></span>attribute_designator '''use''' <span id="I4167"></span>expression; | '''for''' <span id="I4168"></span>local_name'<span id="I4169"></span>attribute_designator '''use''' <span id="I4170"></span>name; == Name Resolution Rules == For an attribute_definition_clause that specifies an attribute that denotes a value, the form with an expression shall be used. Otherwise, the form with a name shall be used. <span id="I4171"></span>For an attribute_definition_clause that specifies an attribute that denotes a value or an object, the expected type for the expression or name is that of the attribute. <span id="I4172"></span>For an attribute_definition_clause that specifies an attribute that denotes a subprogram, the expected profile for the name is the profile required for the attribute. For an attribute_definition_clause that specifies an attribute that denotes some other kind of entity, the name shall resolve to denote an entity of the appropriate kind. == Legality Rules == <span id="I4173"></span><span id="I4174"></span>An attribute_designator is allowed in an attribute_definition_clause only if this International Standard explicitly allows it, or for an implementation-defined attribute if the implementation allows it. <span id="I4175"></span>Each specifiable attribute constitutes an <span id="I4176"></span>operational aspect or aspect of representation. For an attribute_definition_clause that specifies an attribute that denotes a subprogram, the profile shall be mode conformant with the one required for the attribute, and the convention shall be Ada. Additional requirements are defined for particular attributes. <span id="I4177"></span> == Static Semantics == <span id="I4178"></span><span id="I4179"></span><span id="I4180"></span><span id="I4181"></span><span id="I4182"></span><span id="I4183"></span><span id="I4184"></span><span id="I4185"></span><span id="I4186"></span><span id="I4187"></span><span id="I4188"></span><span id="I4189"></span><span id="I4190"></span><span id="I4191"></span>A ''Size clause'' is an attribute_definition_clause whose attribute_designator is Size. Similar definitions apply to the other specifiable attributes. <span id="I4192"></span><span id="I4193"></span>A ''storage element'' is an addressable element of storage in the machine. <span id="I4194"></span>A ''word'' is the largest amount of storage that can be conveniently and efficiently manipulated by the hardware, given the implementation's run-time model. A word consists of an integral number of storage elements. The following representation attributes are defined: Address, Alignment, Size, Storage_Size, and Component_Size. For a prefix X that denotes an object, program unit, or label: ;  X'Address : <span id="I4195"></span><span id="I4196"></span>Denotes the address of the first of the storage elements allocated to X. For a program unit or label, this value refers to the machine code associated with the corresponding body or statement. The value of this attribute is of type System.Address. <p><span></span></p> :<span id="I4197"></span><span id="I4198"></span>Address may be specified for stand-alone objects and for program units via an attribute_definition_clause. == Erroneous Execution == <span id="I4199"></span>If an Address is specified, it is the programmer's responsibility to ensure that the address is valid; otherwise, program execution is erroneous. == Implementation Advice == For an array X, X'Address should point at the first component of the array, and not at the array bounds. <span id="I4200"></span>The recommended level of support for the Address attribute is: * X'Address should produce a useful result if X is an object that is aliased or of a by-reference type, or is an entity whose Address has been specified. * An implementation should support Address clauses for imported subprograms. * Objects (including subcomponents) that are aliased or of a by-reference type should be allocated on storage element boundaries. * If the Address of an object is specified, or it is imported or exported, then the implementation should not perform optimizations based on assumptions of no aliases. == Notes == 1  The specification of a link name in a pragma Export (see [[Guide:95lrm/RM-B-1|B.1]]) for a subprogram or object is an alternative to explicit specification of its link-time address, allowing a link-time directive to place the subprogram or object within memory. 2  The rules for the Size attribute imply, for an aliased object X, that if X'Size = Storage_Unit, then X'Address points at a storage element containing all of the bits of X, and only the bits of X. == Static Semantics == For a prefix X that denotes a subtype or object: ;  X'Alignment : <span id="I4201"></span><span id="I4202"></span>The Address of an object that is allocated under control of the implementation is an integral multiple of the Alignment of the object (that is, the Address modulo the Alignment is zero). The offset of a record component is a multiple of the Alignment of the component. For an object that is not allocated under control of the implementation (that is, one that is imported, that is allocated by a user-defined allocator, whose Address has been specified, or is designated by an access value returned by an instance of Unchecked_Conversion), the implementation may assume that the Address is an integral multiple of its Alignment. The implementation shall not assume a stricter alignment. <p><span></span></p> :The value of this attribute is of type ''universal_integer'', and nonnegative; zero means that the object is not necessarily aligned on a storage element boundary. <p><span></span></p> :<span id="I4203"></span><span id="I4204"></span>Alignment may be specified for first subtypes and stand-alone objects via an attribute_definition_clause; the expression of such a clause shall be static, and its value nonnegative. If the Alignment of a subtype is specified, then the Alignment of an object of the subtype is at least as strict, unless the object's Alignment is also specified. The Alignment of an object created by an allocator is that of the designated subtype. <p><span></span></p> :If an Alignment is specified for a composite subtype or object, this Alignment shall be equal to the least common multiple of any specified Alignments of the subcomponent subtypes, or an integer multiple thereof. == Erroneous Execution == <span id="I4205"></span>Program execution is erroneous if an Address clause is given that conflicts with the Alignment. <span id="I4206"></span>If the Alignment is specified for an object that is not allocated under control of the implementation, execution is erroneous if the object is not aligned according to the Alignment. == Implementation Advice == <span id="I4207"></span>The recommended level of support for the Alignment attribute for subtypes is: * An implementation should support specified Alignments that are factors and multiples of the number of storage elements per word, subject to the following: * An implementation need not support specified Alignments for combinations of Sizes and Alignments that cannot be easily loaded and stored by available machine instructions. * An implementation need not support specified Alignments that are greater than the maximum Alignment the implementation ever returns by default. <span id="I4208"></span>The recommended level of support for the Alignment attribute for objects is: * Same as above, for subtypes, but in addition: * For stand-alone library-level objects of statically constrained subtypes, the implementation should support all Alignments supported by the target linker. For example, page alignment is likely to be supported for such objects, but not for subtypes. == Notes == 3  Alignment is a subtype-specific attribute. 4  The Alignment of a composite object is always equal to the least common multiple of the Alignments of its components, or a multiple thereof. 5  A component_clause, Component_Size clause, or a pragma Pack can override a specified Alignment. == Static Semantics == For a prefix X that denotes an object: ;  X'Size : <span id="I4209"></span><span id="I4210"></span>Denotes the size in bits of the representation of the object. The value of this attribute is of the type ''universal_integer''. <p><span></span></p> :<span id="I4211"></span><span id="I4212"></span>Size may be specified for stand-alone objects via an attribute_definition_clause; the expression of such a clause shall be static and its value nonnegative. == Implementation Advice == <span id="I4213"></span>The recommended level of support for the Size attribute of objects is: * A Size clause should be supported for an object if the specified Size is at least as large as its subtype's Size, and corresponds to a size in storage elements that is a multiple of the object's Alignment (if the Alignment is nonzero). == Static Semantics == For every subtype S: ;  S'Size : <span id="I4214"></span><span id="I4215"></span>If S is definite, denotes the size (in bits) that the implementation would choose for the following objects of subtype S: <p><span></span></p> :* A record component of subtype S when the record type is packed. <p><span></span></p> :* The formal parameter of an instance of Unchecked_Conversion that converts from subtype S to some other subtype. <p><span></span></p> :If S is indefinite, the meaning is implementation defined. The value of this attribute is of the type ''universal_integer''. <span id="I4216"></span><span id="I4217"></span>The Size of an object is at least as large as that of its subtype, unless the object's Size is determined by a Size clause, a component_clause, or a Component_Size clause. Size may be specified for first subtypes via an attribute_definition_clause; the expression of such a clause shall be static and its value nonnegative. == Implementation Requirements == In an implementation, Boolean'Size shall be 1. == Implementation Advice == If the Size of a subtype is specified, and allows for efficient independent addressability (see [[Guide:95lrm/RM-9-10|9.10]]) on the target architecture, then the Size of the following objects of the subtype should equal the Size of the subtype: * Aliased objects (including components). * Unaliased components, unless the Size of the component is determined by a component_clause or Component_Size clause. A Size clause on a composite subtype should not affect the internal layout of components. <span id="I4218"></span>The recommended level of support for the Size attribute of subtypes is: * The Size (if not specified) of a static discrete or fixed point subtype should be the number of bits needed to represent each value belonging to the subtype using an unbiased representation, leaving space for a sign bit only if the subtype contains negative values. If such a subtype is a first subtype, then an implementation should support a specified Size for it that reflects this representation. * For a subtype implemented with levels of indirection, the Size should include the size of the pointers, but not the size of what they point at. == Notes == 6  Size is a subtype-specific attribute. 7  A component_clause or Component_Size clause can override a specified Size. A pragma Pack cannot. == Static Semantics == For a prefix T that denotes a task object (after any implicit dereference): ;  T'Storage_Size : <span id="I4219"></span><span id="I4220"></span>Denotes the number of storage elements reserved for the task. The value of this attribute is of the type ''universal_integer''. The Storage_Size includes the size of the task's stack, if any. The language does not specify whether or not it includes other storage associated with the task (such as the ''task control block'' used by some implementations.) If a pragma Storage_Size is given, the value of the Storage_Size attribute is at least the value specified in the pragma. <span id="I4221"></span>A pragma Storage_Size specifies the amount of storage to be reserved for the execution of a task. == Syntax == The form of a pragma Storage_Size is as follows: <p><span></span></p> '''pragma''' <span id="I4222"></span><span id="I4223"></span>Storage_Size(<span id="I4224"></span>expression); A pragma Storage_Size is allowed only immediately within a task_definition. == Name Resolution Rules == <span id="I4225"></span>The expression of a pragma Storage_Size is expected to be of any integer type. == Dynamic Semantics == A pragma Storage_Size is elaborated when an object of the type defined by the immediately enclosing task_definition is created. <span id="I4226"></span>For the elaboration of a pragma Storage_Size, the expression is evaluated; the Storage_Size attribute of the newly created task object is at least the value of the expression. <span id="I4227"></span><span id="I4228"></span><span id="I4229"></span>At the point of task object creation, or upon task activation, Storage_Error is raised if there is insufficient free storage to accommodate the requested Storage_Size. == Static Semantics == For a prefix X that denotes an array subtype or array object (after any implicit dereference): ;  X'Component_Size : <span id="I4230"></span><span id="I4231"></span>Denotes the size in bits of components of the type of X. The value of this attribute is of type ''universal_integer''. <p><span></span></p> :<span id="I4232"></span><span id="I4233"></span>Component_Size may be specified for array types via an attribute_definition_clause; the expression of such a clause shall be static, and its value nonnegative. == Implementation Advice == <span id="I4234"></span>The recommended level of support for the Component_Size attribute is: * An implementation need not support specified Component_Sizes that are less than the Size of the component subtype. * An implementation should support specified Component_Sizes that are factors and multiples of the word size. For such Component_Sizes, the array should contain no gaps between components. For other Component_Sizes (if supported), the array should contain no gaps between components when packing is also specified; the implementation should forbid this combination in cases where it cannot support a no-gaps representation. == Static Semantics == <div> The following operational attribute is defined: External_Tag. </div> For every subtype S of a tagged type ''T'' (specific or class-wide): ;    S'External_Tag : <span id="I4235"></span><span id="I4236"></span><span id="I4237"></span><span id="I4238"></span>S'External_Tag denotes an external string representation for S'Tag; it is of the predefined type String. External_Tag may be specified for a specific tagged type via an attribute_definition_clause; the expression of such a clause shall be static. The default external tag representation is implementation defined. See [[Guide:95lrm/RM-3-9-2|3.9.2]] and [[Guide:95lrm/RM-13-13-2|13.13.2]]. The value of External_Tag is never inherited; the default value is always used unless a new value is directly specified for a type. == Implementation Requirements == In an implementation, the default external tag for each specific tagged type declared in a partition shall be distinct, so long as the type is declared outside an instance of a generic body. If the compilation unit in which a given tagged type is declared, and all compilation units on which it semantically depends, are the same in two different partitions, then the external tag for the type shall be the same in the two partitions. What it means for a compilation unit to be the same in two different partitions is implementation defined. At a minimum, if the compilation unit is not recompiled between building the two different partitions that include it, the compilation unit is considered the same in the two partitions. == Notes == 8  The following language-defined attributes are specifiable, at least for some of the kinds of entities to which they apply: Address, Size, Component_Size, Alignment, External_Tag, Small, Bit_Order, Storage_Pool, Storage_Size, Write, Output, Read, Input, and Machine_Radix. 9  It follows from the general rules in [[Guide:95lrm/RM-13-1|13.1]] that if one writes '''''for''' X'Size '''use''' Y;'' then the X'Size attribute_reference will return Y (assuming the implementation allows the Size clause). The same is true for all of the specifiable attributes except Storage_Size. == Examples == ''Examples of attribute definition clauses:'' <p><syntaxhighlight lang="Ada"> Byte : constant := 8; Page : constant := 2**12;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Medium is range 0 .. 65_000; for Medium'Size use 2*Byte; for Medium'Alignment use 2; Device_Register : Medium; for Device_Register'Size use Medium'Size; for Device_Register'Address use System.Storage_Elements.To_Address(16#FFFF_0020#);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Short is delta 0.01 range -100.0 .. 100.0; for Short'Size use 15;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> for Car_Name'Storage_Size use -- specify access type's storage pool size      2000*((Car'Size/System.Storage_Unit) +1); -- approximately 2000 cars</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> function My_Read(Stream : access Ada.Streams.Root_Stream_Type'Class)   return T; for T'Read use My_Read; -- see 13.13.2</syntaxhighlight></p> == Notes == 10  ''Notes on the examples:'' In the Size clause for Short, fifteen bits is the minimum necessary, since the type definition requires Short'Small <= 2**(-7). </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-2|Previous]] | [[Guide:95lrm/RM-13-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} pyjidebsajyb3ksllreaqiuwlde7jtu Guide:95lrm/RM-13-4 4200 916 3700 3699 2019-05-04T23:36:04Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-3|Previous]] | [[Guide:95lrm/RM-13-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.4 Enumeration Representation Clauses}} An enumeration_representation_clause specifies the internal codes for enumeration literals. == Syntax == <p><span></span></p> enumeration_representation_clause<span id="I4239"></span> ::= '''for''' ''first_subtype_''<span id="I4240"></span>local_name '''use''' <span id="I4241"></span>enumeration_aggregate; <p><span></span></p> enumeration_aggregate<span id="I4242"></span> ::= <span id="I4243"></span>array_aggregate == Name Resolution Rules == <span id="I4244"></span>The enumeration_aggregate shall be written as a one-dimensional array_aggregate, for which the index subtype is the unconstrained subtype of the enumeration type, and each component expression is expected to be of any integer type. == Legality Rules == The ''first_subtype_''local_name of an enumeration_representation_clause shall denote an enumeration subtype. The expressions given in the array_aggregate shall be static, and shall specify distinct integer codes for each value of the enumeration type; the associated integer codes shall satisfy the predefined ordering relation of the type. == Static Semantics == <span id="I4245"></span><span id="I4246"></span>An enumeration_representation_clause specifies the ''coding'' aspect of representation. <span id="I4247"></span>The coding consists of the ''internal code'' for each enumeration literal, that is, the integral value used internally to represent each literal. == Implementation Requirements == For nonboolean enumeration types, if the coding is not specified for the type, then for each value of the type, the internal code shall be equal to its position number. == Implementation Advice == <span id="I4248"></span>The recommended level of support for enumeration_representation_clauses is: * An implementation should support at least the internal codes in the range System.Min_Int..System.Max_Int. An implementation need not support enumeration_representation_clauses for boolean types. == Notes == 11  Unchecked_Conversion may be used to query the internal codes used for an enumeration type. The attributes of the type, such as Succ, Pred, and Pos, are unaffected by the enumeration_representation_clause. For example, Pos always returns the position number, ''not'' the internal integer code that might have been specified in a enumeration_representation_clause. == Examples == ''Example of an enumeration representation clause:'' <p><syntaxhighlight lang="Ada"> type Mix_Code is (ADD, SUB, MUL, LDA, STA, STZ);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> for Mix_Code use (ADD => 1, SUB => 2, MUL => 3, LDA => 8, STA => 24, STZ =>33);</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-3|Previous]] | [[Guide:95lrm/RM-13-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} h2ztivgoavq6nyss95134ds93c4an7o Guide:95lrm/RM-13-5 4200 917 3702 3701 2019-05-04T23:36:04Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-4|Previous]] | [[Guide:95lrm/RM-13-5-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.5 Record Layout}} <span id="I4249"></span><span id="I4250"></span><span id="I4251"></span><span id="I4252"></span><span id="I4253"></span><span id="I4254"></span>The ''(record) layout'' aspect of representation consists of the ''storage places'' for some or all components, that is, storage place attributes of the components. The layout can be specified with a record_representation_clause. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-4|Previous]] | [[Guide:95lrm/RM-13-5-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} i6uvqo9d98eaafsyz42zwudy2gqyty7 Guide:95lrm/RM-13-5-1 4200 918 3704 3703 2019-05-04T23:36:06Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-5|Previous]] | [[Guide:95lrm/RM-13-5-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.5.1 Record Representation Clauses}} A record_representation_clause specifies the storage representation of records and record extensions, that is, the order, position, and size of components (including discriminants, if any). <span id="I4255"></span> == Syntax == <p><span></span></p> record_representation_clause<span id="I4256"></span> ::= '''for''' ''first_subtype_''<span id="I4257"></span>local_name '''use''' '''record''' [<span id="I4258"></span>mod_clause] {<span id="I4259"></span>component_clause} '''end''' '''record'''; <p><span></span></p> component_clause<span id="I4260"></span> ::= ''component_''<span id="I4261"></span>local_name '''at''' <span id="I4262"></span>position '''range''' <span id="I4263"></span>first_bit .. <span id="I4264"></span>last_bit; <p><span></span></p> position<span id="I4265"></span> ::= ''static_''<span id="I4266"></span>expression <p><span></span></p> first_bit<span id="I4267"></span> ::= ''static_''<span id="I4268"></span>simple_expression <p><span></span></p> last_bit<span id="I4269"></span> ::= ''static_''<span id="I4270"></span>simple_expression == Name Resolution Rules == <span id="I4271"></span><span id="I4272"></span><span id="I4273"></span><span id="I4274"></span>Each position, first_bit, and last_bit is expected to be of any integer type. == Legality Rules == The ''first_subtype_''local_name of a record_representation_clause shall denote a specific nonlimited record or record extension subtype. If the ''component_''local_name is a direct_name, the local_name shall denote a component of the type. For a record extension, the component shall not be inherited, and shall not be a discriminant that corresponds to a discriminant of the parent type. If the ''component_''local_name has an attribute_designator, the direct_name of the local_name shall denote either the declaration of the type or a component of the type, and the attribute_designator shall denote an implementation-defined implicit component of the type. The position, first_bit, and last_bit shall be static expressions. The value of position and first_bit shall be nonnegative. The value of last_bit shall be no less than first_bit - 1. At most one component_clause is allowed for each component of the type, including for each discriminant (component_clauses may be given for some, all, or none of the components). Storage places within a component_list shall not overlap, unless they are for components in distinct variants of the same variant_part. A name that denotes a component of a type is not allowed within a record_representation_clause for the type, except as the ''component_''local_name of a component_clause. == Static Semantics == A record_representation_clause (without the mod_clause) specifies the layout. The storage place attributes (see [[Guide:95lrm/RM-13-5-2|13.5.2]]) are taken from the values of the position, first_bit, and last_bit expressions after normalizing those values so that first_bit is less than Storage_Unit. A record_representation_clause for a record extension does not override the layout of the parent part; if the layout was specified for the parent type, it is inherited by the record extension. == Implementation Permissions == An implementation may generate implementation-defined components (for example, one containing the offset of another component). An implementation may generate names that denote such implementation-defined components; such names shall be implementation-defined attribute_references. An implementation may allow such implementation-defined names to be used in record_representation_clauses. An implementation can restrict such component_clauses in any manner it sees fit. If a record_representation_clause is given for an untagged derived type, the storage place attributes for all of the components of the derived type may differ from those of the corresponding components of the parent type, even for components whose storage place is not specified explicitly in the record_representation_clause. == Implementation Advice == <span id="I4275"></span>The recommended level of support for record_representation_clauses is: * An implementation should support storage places that can be extracted with a load, mask, shift sequence of machine code, and set with a load, shift, mask, store sequence, given the available machine instructions and run-time model. * A storage place should be supported if its size is equal to the Size of the component subtype, and it starts and ends on a boundary that obeys the Alignment of the component subtype. * If the default bit ordering applies to the declaration of a given type, then for a component whose subtype's Size is less than the word size, any storage place that does not cross an aligned word boundary should be supported. * An implementation may reserve a storage place for the tag field of a tagged type, and disallow other components from overlapping that place. * An implementation need not support a component_clause for a component of an extension part if the storage place is not after the storage places of all components of the parent type, whether or not those storage places had been specified. == Notes == 12  If no component_clause is given for a component, then the choice of the storage place for the component is left to the implementation. If component_clauses are given for all components, the record_representation_clause completely specifies the representation of the type and will be obeyed exactly by the implementation. == Examples == ''Example of specifying the layout of a record type:'' <p><syntaxhighlight lang="Ada"> Word : constant := 4;  --  storage element is byte, 4 bytes per word</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type State         is (A,M,W,P); type Mode          is (Fix, Dec, Exp, Signif);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Byte_Mask     is array (0..7)  of Boolean; type State_Mask    is array (State) of Boolean; type Mode_Mask     is array (Mode)  of Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Program_Status_Word is    record    System_Mask        : Byte_Mask;    Protection_Key     : Integer range 0 .. 3;    Machine_State      : State_Mask;    Interrupt_Cause    : Interruption_Code;    Ilc                : Integer range 0 .. 3;    Cc                 : Integer range 0 .. 3;     Program_Mask       : Mode_Mask;     Inst_Address       : Address; end record;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> for Program_Status_Word use   record    System_Mask      at 0*Word range 0  .. 7;    Protection_Key   at 0*Word range 10 .. 11; -- bits 8,9 unused    Machine_State    at 0*Word range 12 .. 15;    Interrupt_Cause  at 0*Word range 16 .. 31;    Ilc              at 1*Word range 0  .. 1;  -- second word    Cc               at 1*Word range 2  .. 3;    Program_Mask     at 1*Word range 4  .. 7;    Inst_Address     at 1*Word range 8  .. 31;   end record;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> for Program_Status_Word'Size use 8*System.Storage_Unit; for Program_Status_Word'Alignment use 8;</syntaxhighlight></p> == Notes == 13  ''Note on the example:'' The record_representation_clause defines the record layout. The Size clause guarantees that (at least) eight storage elements are used for objects of the type. The Alignment clause guarantees that aliased, imported, or exported objects of the type will have addresses divisible by eight. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-5|Previous]] | [[Guide:95lrm/RM-13-5-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} ceusvkvu1pp03a7yvmsr2odcyi4lbnf Guide:95lrm/RM-13-5-2 4200 919 3706 3705 2019-05-04T23:36:07Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-5-1|Previous]] | [[Guide:95lrm/RM-13-5-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.5.2 Storage Place Attributes}} == Static Semantics == <span id="I4276"></span>For a component C of a composite, non-array object R, the ''storage place attributes'' are defined: ; R.C'Position : <span id="I4277"></span><span id="I4278"></span>Denotes the same value as R.C'Address - R'Address. The value of this attribute is of the type ''universal_integer''. ; R.C'First_Bit : <span id="I4279"></span><span id="I4280"></span>Denotes the offset, from the start of the first of the storage elements occupied by C, of the first bit occupied by C. This offset is measured in bits. The first bit of a storage element is numbered zero. The value of this attribute is of the type ''universal_integer''. ; R.C'Last_Bit : <span id="I4281"></span><span id="I4282"></span>Denotes the offset, from the start of the first of the storage elements occupied by C, of the last bit occupied by C. This offset is measured in bits. The value of this attribute is of the type ''universal_integer''. == Implementation Advice == <span id="I4283"></span><span id="I4284"></span>If a component is represented using some form of pointer (such as an offset) to the actual data of the component, and this data is contiguous with the rest of the object, then the storage place attributes should reflect the place of the actual data, not the pointer. If a component is allocated discontiguously from the rest of the object, then a warning should be generated upon reference to one of its storage place attributes. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-5-1|Previous]] | [[Guide:95lrm/RM-13-5-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 8wlqo2l1y0t3wf3kdo8xdpyihz8fovv Guide:95lrm/RM-13-5-3 4200 920 3708 3707 2019-05-04T23:36:07Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-5-2|Previous]] | [[Guide:95lrm/RM-13-6|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.5.3 Bit Ordering}} The Bit_Order attribute specifies the interpretation of the storage place attributes. == Static Semantics == <span id="I4285"></span>A bit ordering is a method of interpreting the meaning of the storage place attributes. <span id="I4286"></span><span id="I4287"></span><span id="I4288"></span>High_Order_First (known in the vernacular as ''big endian'') means that the first bit of a storage element (bit 0) is the most significant bit (interpreting the sequence of bits that represent a component as an unsigned integer value). <span id="I4289"></span><span id="I4290"></span><span id="I4291"></span>Low_Order_First (known in the vernacular as ''little endian'') means the opposite: the first bit is the least significant. For every specific record subtype S, the following attribute is defined: ; S'Bit_Order : <span id="I4292"></span><span id="I4293"></span>Denotes the bit ordering for the type of S. The value of this attribute is of type System.Bit_Order. <span id="I4294"></span><span id="I4295"></span>Bit_Order may be specified for specific record types via an attribute_definition_clause; the expression of such a clause shall be static. If Word_Size = Storage_Unit, the default bit ordering is implementation defined. If Word_Size > Storage_Unit, the default bit ordering is the same as the ordering of storage elements in a word, when interpreted as an integer. <span id="I4296"></span> The storage place attributes of a component of a type are interpreted according to the bit ordering of the type. == Implementation Advice == <span id="I4297"></span>The recommended level of support for the nondefault bit ordering is: * If Word_Size = Storage_Unit, then the implementation should support the nondefault bit ordering in addition to the default bit ordering. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-5-2|Previous]] | [[Guide:95lrm/RM-13-6|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} psdpdzjijo8lnfrma6uov0hx6a9okok Guide:95lrm/RM-13-6 4200 921 3710 3709 2019-05-04T23:36:09Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-5-3|Previous]] | [[Guide:95lrm/RM-13-7|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.6 Change of Representation}} <span id="I4298"></span><span id="I4299"></span>A type_conversion (see [[Guide:95lrm/RM-4-6|4.6]]) can be used to convert between two different representations of the same array or record. To convert an array from one representation to another, two array types need to be declared with matching component subtypes, and convertible index types. If one type has packing specified and the other does not, then explicit conversion can be used to pack or unpack an array. To convert a record from one representation to another, two record types with a common ancestor type need to be declared, with no inherited subprograms. Distinct representations can then be specified for the record types, and explicit conversion between the types can be used to effect a change in representation. == Examples == ''Example of change of representation:'' <p><syntaxhighlight lang="Ada"> -- Packed_Descriptor and Descriptor are two different types -- with identical characteristics, apart from their -- representation</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Descriptor is  record    -- components of a descriptor  end record;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Packed_Descriptor is new Descriptor;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> for Packed_Descriptor use  record    -- component clauses for some or for all components   end record;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- Change of representation can now be accomplished by explicit type conversions:</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> D : Descriptor; P : Packed_Descriptor;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> P := Packed_Descriptor(D);  -- pack D D := Descriptor(P);         -- unpack P</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-5-3|Previous]] | [[Guide:95lrm/RM-13-7|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} g3et46gj07rsza4kqoo0lv8pydwv2n2 Guide:95lrm/RM-13-7 4200 922 3712 3711 2019-05-04T23:36:15Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-6|Previous]] | [[Guide:95lrm/RM-13-7-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.7 The Package System}} For each implementation there is a library package called System which includes the definitions of certain configuration-dependent characteristics. == Static Semantics == The following language-defined library package exists: <p><syntaxhighlight lang="Ada"> package System is pragma Preelaborate(System);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Name is implementation-defined-enumeration-type; System_Name : constant Name := implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- System-Dependent Named Numbers:</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Min_Int               : constant := root_integer'First; Max_Int               : constant := root_integer'Last;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Max_Binary_Modulus    : constant := implementation-defined; Max_Nonbinary_Modulus : constant := implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Max_Base_Digits       : constant := root_real'Digits; Max_Digits            : constant := implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Max_Mantissa          : constant := implementation-defined; Fine_Delta            : constant := implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Tick                  : constant := implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   -- Storage-related Declarations:</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Address is implementation-defined; Null_Address : constant Address;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Storage_Unit : constant := implementation-defined; Word_Size    : constant := implementation-defined * Storage_Unit; Memory_Size  : constant := implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- Address Comparison: function "<" (Left, Right : Address) return Boolean; function "<="(Left, Right : Address) return Boolean; function ">" (Left, Right : Address) return Boolean; function ">="(Left, Right : Address) return Boolean; function "=" (Left, Right : Address) return Boolean; -- function "/=" (Left, Right : Address) return Boolean; -- "/=" is implicitly defined pragma Convention(Intrinsic, "<"); ... -- and so on for all language-defined subprograms in this package</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Other System-Dependent Declarations: type Bit_Order is (High_Order_First, Low_Order_First); Default_Bit_Order : constant Bit_Order;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Priority-related declarations (see D.1): subtype Any_Priority is Integer range implementation-defined; subtype Priority is Any_Priority range Any_Priority'First ..           implementation-defined; subtype Interrupt_Priority is Any_Priority range Priority'Last+1 ..           Any_Priority'Last;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Default_Priority : constant Priority :=           (Priority'First + Priority'Last)/2;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> private ... -- not specified by the language end System;</syntaxhighlight></p> Name is an enumeration subtype. Values of type Name are the names of alternative machine configurations handled by the implementation. System_Name represents the current machine configuration. The named numbers Fine_Delta and Tick are of the type ''universal_real''; the others are of the type ''universal_integer''. The meanings of the named numbers are: ;  Min_Int : The smallest (most negative) value allowed for the expressions of a signed_integer_type_definition. ;  Max_Int : The largest (most positive) value allowed for the expressions of a signed_integer_type_definition. ;  Max_Binary_Modulus : A power of two such that it, and all lesser positive powers of two, are allowed as the modulus of a modular_type_definition. ;  Max_Nonbinary_Modulus : A value such that it, and all lesser positive integers, are allowed as the modulus of a modular_type_definition. ;  Max_Base_Digits : The largest value allowed for the requested decimal precision in a floating_point_definition. ;  Max_Digits : The largest value allowed for the requested decimal precision in a floating_point_definition that has no real_range_specification. Max_Digits is less than or equal to Max_Base_Digits. ;  Max_Mantissa : The largest possible number of binary digits in the mantissa of machine numbers of a user-defined ordinary fixed point type. (The mantissa is defined in [[Guide:95lrm/RM-G|Annex G]].) ;  Fine_Delta : The smallest delta allowed in an ordinary_fixed_point_definition that has the real_range_specification '''range''' -1.0 .. 1.0. ;  Tick : A period in seconds approximating the real time interval during which the value of Calendar.Clock remains constant. ;  Storage_Unit : The number of bits per storage element. ;  Word_Size : The number of bits per word. ;  Memory_Size : An implementation-defined value that is intended to reflect the memory size of the configuration in storage elements. Address is of a definite, nonlimited type. Address represents machine addresses capable of addressing individual storage elements. Null_Address is an address that is distinct from the address of any object or program unit. <span id="I4328"></span> See [[Guide:95lrm/RM-13-5-3|13.5.3]] for an explanation of Bit_Order and Default_Bit_Order. == Implementation Permissions == An implementation may add additional implementation-defined declarations to package System and its children. However, it is usually better for the implementation to provide additional functionality via implementation-defined children of System. Package System may be declared pure. == Implementation Advice == Address should be a private type. == Notes == 14  There are also some language-defined child packages of System defined elsewhere. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-6|Previous]] | [[Guide:95lrm/RM-13-7-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 8wi31t3y6pzuqefwxig6d37p90o0gi0 Guide:95lrm/RM-13-7-1 4200 923 3714 3713 2019-05-04T23:36:20Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-7|Previous]] | [[Guide:95lrm/RM-13-7-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.7.1 The Package System.Storage_Elements}} == Static Semantics == The following language-defined library package exists: <p><syntaxhighlight lang="Ada"> package System.Storage_Elements is pragma Preelaborate(System.Storage_Elements);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Storage_Offset is range implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    subtype Storage_Count is Storage_Offset range 0..Storage_Offset'Last;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Storage_Element is mod implementation-defined; for Storage_Element'Size use Storage_Unit; type Storage_Array is array   (Storage_Offset range <>) of aliased Storage_Element; for Storage_Array'Component_Size use Storage_Unit;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Address Arithmetic:</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "+"(Left : Address; Right : Storage_Offset)   return Address; function "+"(Left : Storage_Offset; Right : Address)   return Address; function "-"(Left : Address; Right : Storage_Offset)   return Address; function "-"(Left, Right : Address)   return Storage_Offset;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "mod"(Left : Address; Right : Storage_Offset)   return Storage_Offset;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Conversion to/from integers:</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Integer_Address is implementation-defined; function To_Address(Value : Integer_Address) return Address; function To_Integer(Value : Address) return Integer_Address;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   pragma Convention(Intrinsic, "+");    -- ...and so on for all language-defined subprograms declared in this package. end System.Storage_Elements;</syntaxhighlight></p> Storage_Element represents a storage element. Storage_Offset represents an offset in storage elements. Storage_Count represents a number of storage elements. <span id="I4346"></span><span id="I4347"></span>Storage_Array represents a contiguous sequence of storage elements. Integer_Address is a (signed or modular) integer subtype. To_Address and To_Integer convert back and forth between this type and Address. == Implementation Requirements == Storage_Offset'Last shall be greater than or equal to Integer'Last or the largest possible storage offset, whichever is smaller. Storage_Offset'First shall be <= (-Storage_Offset'Last). == Implementation Permissions == Package System.Storage_Elements may be declared pure. == Implementation Advice == Operations in System and its children should reflect the target environment semantics as closely as is reasonable. For example, on most machines, it makes sense for address arithmetic to ''wrap around.'' <span id="I4348"></span>Operations that do not make sense should raise Program_Error. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-7|Previous]] | [[Guide:95lrm/RM-13-7-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} tkmojekhfd5kjnjxl4ippxggowytu26 Guide:95lrm/RM-13-7-2 4200 924 3716 3715 2019-05-04T23:36:22Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-7-1|Previous]] | [[Guide:95lrm/RM-13-8|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.7.2 The Package System.Address_To_Access_Conversions}} == Static Semantics == The following language-defined generic library package exists: <p><syntaxhighlight lang="Ada"> generic   type Object(<>) is limited private; package System.Address_To_Access_Conversions is pragma Preelaborate(Address_To_Access_Conversions);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Object_Pointer is access all Object; function To_Pointer(Value : Address) return Object_Pointer; function To_Address(Value : Object_Pointer) return Address;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    pragma Convention(Intrinsic, To_Pointer); pragma Convention(Intrinsic, To_Address); end System.Address_To_Access_Conversions;</syntaxhighlight></p> The To_Pointer and To_Address subprograms convert back and forth between values of types Object_Pointer and Address. To_Pointer(X'Address) is equal to X'Unchecked_Access for any X that allows Unchecked_Access. To_Pointer(Null_Address) returns '''null'''. <span id="I4356"></span>For other addresses, the behavior is unspecified. To_Address('''null''') returns Null_Address (for '''null''' of the appropriate type). To_Address(Y), where Y /= '''null''', returns Y.'''all''''Address. == Implementation Permissions == An implementation may place restrictions on instantiations of Address_To_Access_Conversions. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-7-1|Previous]] | [[Guide:95lrm/RM-13-8|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 9d18mbck5fgs9wwv8azejid25z8mfl1 Guide:95lrm/RM-13-8 4200 925 3718 3717 2019-05-04T23:36:23Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-7-2|Previous]] | [[Guide:95lrm/RM-13-9|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.8 Machine Code Insertions}} <span id="I4357"></span>A machine code insertion can be achieved by a call to a subprogram whose sequence_of_statements contains code_statements. == Syntax == <p><span></span></p> code_statement<span id="I4358"></span> ::= <span id="I4359"></span>qualified_expression; A code_statement is only allowed in the handled_sequence_of_statements of a subprogram_body. If a subprogram_body contains any code_statements, then within this subprogram_body the only allowed form of statement is a code_statement (labeled or not), the only allowed declarative_items are use_clauses, and no exception_handler is allowed (comments and pragmas are allowed as usual). == Name Resolution Rules == <span id="I4360"></span>The qualified_expression is expected to be of any type. == Legality Rules == The qualified_expression shall be of a type declared in package System.Machine_Code. A code_statement shall appear only within the scope of a with_clause that mentions package System.Machine_Code. == Static Semantics == <span id="I4361"></span><span id="I4362"></span><span id="I4363"></span><span id="I4364"></span>The contents of the library package System.Machine_Code (if provided) are implementation defined. The meaning of code_statements is implementation defined. Typically, each qualified_expression represents a machine instruction or assembly directive. == Implementation Permissions == An implementation may place restrictions on code_statements. An implementation is not required to provide package System.Machine_Code. == Notes == 15  An implementation may provide implementation-defined pragmas specifying register conventions and calling conventions. 16  Machine code functions are exempt from the rule that a return_statement is required. In fact, return_statements are forbidden, since only code_statements are allowed. 17  Intrinsic subprograms (see [[Guide:95lrm/RM-6-3-1|6.3.1]], ''[[Guide:95lrm/RM-6-3-1|Conformance Rules]]'') can also be used to achieve machine code insertions. Interface to assembly language can be achieved using the features in [[Guide:95lrm/RM-B|Annex B]], ''[[Guide:95lrm/RM-B|Interface to Other Languages]]''. == Examples == ''Example of a code statement:'' <p><syntaxhighlight lang="Ada"> M : Mask; procedure Set_Mask; pragma Inline(Set_Mask);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> procedure Set_Mask is use System.Machine_Code; -- assume ''with System.Machine_Code;'' appears somewhere above begin   SI_Format'(Code => SSM, B => M'Base_Reg, D => M'Disp);   --  Base_Reg and Disp are implementation-defined attributes end Set_Mask;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-7-2|Previous]] | [[Guide:95lrm/RM-13-9|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 4gpckomnocdpqvw5l0v3k966a777l8m Guide:95lrm/RM-13-9 4200 926 3720 3719 2019-05-04T23:36:24Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-8|Previous]] | [[Guide:95lrm/RM-13-9-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.9 Unchecked Type Conversions}} <span id="I4365"></span><span id="I4366"></span><span id="I4367"></span><span id="I4368"></span><span id="I4369"></span>An unchecked type conversion can be achieved by a call to an instance of the generic function Unchecked_Conversion. == Static Semantics == The following language-defined generic library function exists: <p><syntaxhighlight lang="Ada"> generic type Source(<>) is limited private; type Target(<>) is limited private; function Ada.Unchecked_Conversion(S : Source) return Target; pragma Convention(Intrinsic, Ada.Unchecked_Conversion); pragma Pure(Ada.Unchecked_Conversion);</syntaxhighlight></p> == Dynamic Semantics == The size of the formal parameter S in an instance of Unchecked_Conversion is that of its subtype. This is the actual subtype passed to Source, except when the actual is an unconstrained composite subtype, in which case the subtype is constrained by the bounds or discriminants of the value of the actual expression passed to S. If all of the following are true, the effect of an unchecked conversion is to return the value of an object of the target subtype whose representation is the same as that of the source object S: * S'Size = Target'Size. * S'Alignment = Target'Alignment. * The target subtype is not an unconstrained composite subtype. * <span id="I4373"></span><span id="I4374"></span>S and the target subtype both have a contiguous representation. * The representation of S is a representation of an object of the target subtype. Otherwise, the effect is implementation defined; in particular, the result can be abnormal (see [[Guide:95lrm/RM-13-9-1|13.9.1]]). == Implementation Permissions == An implementation may return the result of an unchecked conversion by reference, if the Source type is not a by-copy type. In this case, the result of the unchecked conversion represents simply a different (read-only) view of the operand of the conversion. An implementation may place restrictions on Unchecked_Conversion. == Implementation Advice == The Size of an array object should not include its bounds; hence, the bounds should not be part of the converted data. The implementation should not generate unnecessary run-time checks to ensure that the representation of S is a representation of the target type. It should take advantage of the permission to return by reference when possible. Restrictions on unchecked conversions should be avoided unless required by the target environment. <span id="I4375"></span>The recommended level of support for unchecked conversions is: * Unchecked conversions should be supported and should be reversible in the cases where this clause defines the result. <span id="I4376"></span><span id="I4377"></span>To enable meaningful use of unchecked conversion, a contiguous representation should be used for elementary subtypes, for statically constrained array subtypes whose component subtype is one of the subtypes described in this paragraph, and for record subtypes without discriminants whose component subtypes are described in this paragraph. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-8|Previous]] | [[Guide:95lrm/RM-13-9-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 8fmcsvidts3ktjaxbw2wfag5pe0b2q2 Guide:95lrm/RM-13-9-1 4200 927 3722 3721 2019-05-04T23:36:24Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-9|Previous]] | [[Guide:95lrm/RM-13-9-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.9.1 Data Validity}} Certain actions that can potentially lead to erroneous execution are not directly erroneous, but instead can cause objects to become ''abnormal''. Subsequent uses of abnormal objects can be erroneous. A scalar object can have an ''invalid representation'', which means that the object's representation does not represent any value of the object's subtype. <span id="I4378"></span>The primary cause of invalid representations is uninitialized variables. Abnormal objects and invalid representations are explained in this subclause. == Dynamic Semantics == <span id="I4379"></span><span id="I4380"></span>When an object is first created, and any explicit or default initializations have been performed, the object and all of its parts are in the ''normal'' state. Subsequent operations generally leave them normal. However, an object or part of an object can become ''abnormal'' in the following ways: * <span id="I4381"></span>An assignment to the object is disrupted due to an abort (see [[Guide:95lrm/RM-9-8|9.8]]) or due to the failure of a language-defined check (see [[Guide:95lrm/RM-11-6|11.6]]). * The object is not scalar, and is passed to an '''in out''' or '''out''' parameter of an imported procedure or language-defined input procedure, if after return from the procedure the representation of the parameter does not represent a value of the parameter's subtype. <span id="I4382"></span>Whether or not an object actually becomes abnormal in these cases is not specified. An abnormal object becomes normal again upon successful completion of an assignment to the object as a whole. == Erroneous Execution == <span id="I4383"></span>It is erroneous to evaluate a primary that is a name denoting an abnormal object, or to evaluate a prefix that denotes an abnormal object. == Bounded (Run-Time) Errors == <span id="I4384"></span><span id="I4385"></span>If the representation of a scalar object does not represent a value of the object's subtype (perhaps because the object was not initialized), the object is said to have an ''invalid representation''. It is a bounded error to evaluate the value of such an object. <span id="I4386"></span><span id="I4387"></span>If the error is detected, either Constraint_Error or Program_Error is raised. Otherwise, execution continues using the invalid representation. The rules of the language outside this subclause assume that all objects have valid representations. The semantics of operations on invalid representations are as follows: * If the representation of the object represents a value of the object's type, the value of the type is used. * If the representation of the object does not represent a value of the object's type, the semantics of operations on such representations is implementation-defined, but does not by itself lead to erroneous or unpredictable execution, or to other objects becoming abnormal. == Erroneous Execution == <span id="I4388"></span>A call to an imported function or an instance of Unchecked_Conversion is erroneous if the result is scalar, and the result object has an invalid representation. <span id="I4389"></span>The dereference of an access value is erroneous if it does not designate an object of an appropriate type or a subprogram with an appropriate profile, if it designates a nonexistent object, or if it is an access-to-variable value that designates a constant object. Such an access value can exist, for example, because of Unchecked_Deallocation, Unchecked_Access, or Unchecked_Conversion. == Notes == 18  Objects can become abnormal due to other kinds of actions that directly update the object's representation; such actions are generally considered directly erroneous, however. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-9|Previous]] | [[Guide:95lrm/RM-13-9-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} ja7bacvmin49bfw52g9eh222ily7682 Guide:95lrm/RM-13-9-2 4200 928 3724 3723 2019-05-04T23:36:24Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-9-1|Previous]] | [[Guide:95lrm/RM-13-10|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 13.9.2 The Valid Attribute}} The Valid attribute can be used to check the validity of data produced by unchecked conversion, input, interface to foreign languages, and the like. == Static Semantics == For a prefix X that denotes a scalar object (after any implicit dereference), the following attribute is defined: ; X'Valid : <span id="I4390"></span><span id="I4391"></span>Yields True if and only if the object denoted by X is normal and has a valid representation. The value of this attribute is of the predefined type Boolean. == Notes == 19  Invalid data can be created in the following cases (not counting erroneous or unpredictable execution): * an uninitialized scalar object, * the result of an unchecked conversion, * input, * interface to another language (including machine code), * aborting an assignment, * disrupting an assignment due to the failure of a language-defined check (see [[Guide:95lrm/RM-11-6|11.6]]), and * use of an object whose Address has been specified. 20  X'Valid is not considered to be a read of X; hence, it is not an error to check the validity of invalid data. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-13-9-1|Previous]] | [[Guide:95lrm/RM-13-10|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} n7iquv1mqpr1ba8g8scomklitynxq75 Guide:95lrm/RM-2 4200 929 3726 3725 2019-05-04T23:36:24Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-1-3|Previous]] | [[Guide:95lrm/RM-2-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Section 2: Lexical Elements}} The text of a program consists of the texts of one or more compilations. The text of a compilation is a sequence of lexical elements, each composed of characters; the rules of composition are given in this section. Pragmas, which provide certain information for the compiler, are also described in this section. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-1-3|Previous]] | [[Guide:95lrm/RM-2-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} avkcw547t6jsj9vjix87b4w4452bqsi Guide:95lrm/RM-2-1 4200 930 3728 3727 2019-05-04T23:36:24Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-2|Previous]] | [[Guide:95lrm/RM-2-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 2.1 Character Set}} <span id="I1114"></span>The only characters allowed outside of comments are the graphic_characters and format_effectors. == Syntax == <p><span></span></p> character<span id="I1115"></span> ::= <span id="I1116"></span>graphic_character | <span id="I1117"></span>format_effector | <span id="I1118"></span>other_control_function <p><span></span></p> graphic_character<span id="I1119"></span> ::= <span id="I1120"></span>identifier_letter | <span id="I1121"></span>digit | <span id="I1122"></span>space_character | <span id="I1123"></span>special_character</syntaxhighlight> == Static Semantics == The character repertoire for the text of an Ada program consists of the collection of characters called the Basic Multilingual Plane (BMP) of the ISO 10646 Universal Multiple-Octet Coded Character Set, plus a set of format_effectors and, in comments only, a set of other_control_functions; the coded representation for these characters is implementation defined (it need not be a representation defined within ISO-10646-1). The description of the language definition in this International Standard uses the graphic symbols defined for Row 00: Basic Latin and Row 00: Latin-1 Supplement of the ISO 10646 BMP; these correspond to the graphic symbols of ISO 8859-1 (Latin-1); no graphic symbols are used in this International Standard for characters outside of Row 00 of the BMP. The actual set of graphic symbols used by an implementation for the visual representation of the text of an Ada program is not specified. <span id="I1124"></span> The categories of characters are defined as follows: ; <span id="I1125"></span>identifier_letter : upper_case_identifier_letter | lower_case_identifier_letter ; <span id="I1126"></span>upper_case_identifier_letter : Any character of Row 00 of ISO 10646 BMP whose name begins ''Latin Capital Letter''. ; <span id="I1127"></span>lower_case_identifier_letter : Any character of Row 00 of ISO 10646 BMP whose name begins ''Latin Small Letter''. ;  <span id="I1128"></span>digit : One of the characters 0, 1, 2, 3, 4, 5, 6, 7, 8, or 9. ;  <span id="I1129"></span>space_character : The character of ISO 10646 BMP named ''Space''. ;  <span id="I1130"></span>special_character : Any character of the ISO 10646 BMP that is not reserved for a control function, and is not the space_character, an identifier_letter, or a digit. ;  <span id="I1131"></span>format_effector : The control functions of ISO 6429 called character tabulation (HT), line tabulation (VT), carriage return (CR), line feed (LF), and form feed (FF). <span id="I1132"></span> ;  <span id="I1133"></span>other_control_function : Any control function, other than a format_effector, that is allowed in a comment; the set of other_control_functions allowed in comments is implementation defined. <span id="I1134"></span> <span id="I1135"></span><span id="I1136"></span>The following names are used when referring to certain special_characters: <span id="I1137"></span><span id="I1138"></span><span id="I1139"></span><span id="I1140"></span><span id="I1141"></span><span id="I1142"></span><span id="I1143"></span><span id="I1144"></span><span id="I1145"></span><span id="I1146"></span><span id="I1147"></span><span id="I1148"></span><span id="I1149"></span><span id="I1150"></span><span id="I1151"></span><span id="I1152"></span><span id="I1153"></span><span id="I1154"></span><span id="I1155"></span><span id="I1156"></span><span id="I1157"></span><span id="I1158"></span><span id="I1159"></span><span id="I1160"></span><span id="I1161"></span><span id="I1162"></span><span id="I1163"></span><span id="I1164"></span><span id="I1165"></span><span id="I1166"></span> {| class="wikitable" !width="20%"| symbol !width="20%"| name !width="20%"| symbol !width="20%"| name !width="20%"| |- |   |   |   |   | |- |       " | quotation mark |       : | colon | |- |       # | number sign |       ; | semicolon | |- |       & | ampersand |       < | less-than sign | |- |       ' | apostrophe, tick |       = | equals sign | |- |       ( | left parenthesis |       > | greater-than sign | |- |       ) | right parenthesis |       _ | low line, underline | |- |       * | asterisk, multiply |       <nowiki>|</nowiki> | vertical line | |- |       + | plus sign |       [ | left square bracket | |- |       , | comma |       ] | right square bracket | |- |       - | hyphen-minus, minus |       { | left curly bracket | |- |       . | full stop, dot, point |       } | right curly bracket | |- |       / | solidus, divide |   |   | |} == Implementation Permissions == In a nonstandard mode, the implementation may support a different character repertoire; in particular, the set of characters that are considered identifier_letters can be extended or changed to conform to local conventions. == Notes == 1  Every code position of ISO 10646 BMP that is not reserved for a control function is defined to be a graphic_character by this International Standard. This includes all code positions other than 0000 - 001F, 007F - 009F, and FFFE - FFFF. 2  The language does not specify the source representation of programs. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-2|Previous]] | [[Guide:95lrm/RM-2-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} kbxavsiywjnbkrlfya77wdt7nu0skue Guide:95lrm/RM-2-2 4200 931 3730 3729 2019-05-04T23:36:24Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-2-1|Previous]] | [[Guide:95lrm/RM-2-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 2.2 Lexical Elements, Separators, and Delimiters}} == Static Semantics == <span id="I1167"></span>The text of a program consists of the texts of one or more compilations. <span id="I1168"></span><span id="I1169"></span>The text of each compilation is a sequence of separate ''lexical elements''. Each lexical element is formed from a sequence of characters, and is either a delimiter, an identifier, a reserved word, a numeric_literal, a character_literal, a string_literal, or a comment. The meaning of a program depends only on the particular sequences of lexical elements that form its compilations, excluding comments. The text of a compilation is divided into <span id="I1170"></span>''lines''. <span id="I1171"></span>In general, the representation for an end of line is implementation defined. However, a sequence of one or more format_effectors other than character tabulation (HT) signifies at least one end of line. <span id="I1172"></span>In some cases an explicit ''separator'' is required to separate adjacent lexical elements. A separator is any of a space character, a format effector, or the end of a line, as follows: * A space character is a separator except within a comment, a string_literal, or a character_literal. * Character tabulation (HT) is a separator except within a comment. * The end of a line is always a separator. One or more separators are allowed between any two adjacent lexical elements, before the first of each compilation, or after the last. At least one separator is required between an identifier, a reserved word, or a numeric_literal and an adjacent identifier, reserved word, or numeric_literal. <span id="I1173"></span>A ''delimiter'' is either one of the following special characters <p><span></span></p> &    '    (    )    *    +    ,    -    .    /    :    ;    <    =    >    | <span id="I1174"></span>or one of the following ''compound delimiters'' each composed of two adjacent special characters <p><span></span></p> =>    ..    **    :=    /=    >=    <=    <<    >>    <> Each of the special characters listed for single character delimiters is a single delimiter except if this character is used as a character of a compound delimiter, or as a character of a comment, string_literal, character_literal, or numeric_literal. The following names are used when referring to compound delimiters: {| class="wikitable" !delimiter !name |- |   |   |- |       => | arrow |- |       .. | double dot |- |       ** | double star, exponentiate |- |       := | assignment (pronounced: ''becomes'') |- |       /= | inequality (pronounced: ''not equal'') |- |       >= | greater than or equal |- |       <= | less than or equal |- |       << | left label bracket |- |       >> | right label bracket |- |       <> | box |} == Implementation Requirements == An implementation shall support lines of at least 200 characters in length, not counting any characters used to signify the end of a line. An implementation shall support lexical elements of at least 200 characters in length. The maximum supported line length and lexical element length are implementation defined. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-2-1|Previous]] | [[Guide:95lrm/RM-2-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} phgk4799dl6u2pktzs2mzm2b3t2j4o1 Guide:95lrm/RM-2-3 4200 932 3732 3731 2019-05-04T23:36:24Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-2-2|Previous]] | [[Guide:95lrm/RM-2-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 2.3 Identifiers}} Identifiers are used as names. == Syntax == <p><span></span></p> identifier<span id="I1175"></span> ::= <span id="I1176"></span>identifier_letter {[<span id="I1177"></span>underline] <span id="I1178"></span>letter_or_digit} <p><span></span></p> letter_or_digit<span id="I1179"></span> ::= <span id="I1180"></span> identifier_letter | <span id="I1181"></span>digit An identifier shall not be a reserved word. == Static Semantics == All characters of an identifier are significant, including any underline character. <span id="I1182"></span>Identifiers differing only in the use of corresponding upper and lower case letters are considered the same. == Implementation Permissions == In a nonstandard mode, an implementation may support other upper/lower case equivalence rules for identifiers, to accommodate local conventions. == Examples == ''Examples of identifiers:'' <p><span></span></p> Count      X    Get_Symbol   Ethelyn   Marion Snobol_4   X1   Page_Count   Store_Next_Item </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-2-2|Previous]] | [[Guide:95lrm/RM-2-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 6700ll027j1hzdgorkntmgygk4w9ym0 Guide:95lrm/RM-2-4 4200 933 3734 3733 2019-05-04T23:36:24Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-2-3|Previous]] | [[Guide:95lrm/RM-2-4-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 2.4 Numeric Literals}} <span id="I1183"></span>There are two kinds of numeric_literals, ''real literals'' and ''integer literals''. <span id="I1184"></span>A real literal is a numeric_literal that includes a point; <span id="I1185"></span>an integer literal is a numeric_literal without a point. == Syntax == <p><span></span></p> numeric_literal<span id="I1186"></span> ::= <span id="I1187"></span>decimal_literal | <span id="I1188"></span>based_literal == Notes == 3  The type of an integer literal is ''universal_integer''. The type of a real literal is ''universal_real''. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-2-3|Previous]] | [[Guide:95lrm/RM-2-4-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 92qxmank9ge3ssjsyqpi452lndub88e Guide:95lrm/RM-2-4-1 4200 934 3736 3735 2019-05-04T23:36:25Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-2-4|Previous]] | [[Guide:95lrm/RM-2-4-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 2.4.1 Decimal Literals}} <span id="I1189"></span>A decimal_literal is a numeric_literal in the conventional decimal notation (that is, the base is ten). == Syntax == <p><span></span></p> decimal_literal<span id="I1190"></span> ::= <span id="I1191"></span>numeral [.<span id="I1192"></span>numeral] [<span id="I1193"></span>exponent] <p><span></span></p> numeral<span id="I1194"></span> ::= <span id="I1195"></span>digit {[<span id="I1196"></span>underline] <span id="I1197"></span>digit} <p><span></span></p> exponent<span id="I1198"></span> ::= E [+] <span id="I1199"></span>numeral | E - <span id="I1200"></span>numeral An exponent for an integer literal shall not have a minus sign. == Static Semantics == An underline character in a numeric_literal does not affect its meaning. The letter E of an exponent can be written either in lower case or in upper case, with the same meaning. An exponent indicates the power of ten by which the value of the decimal_literal without the exponent is to be multiplied to obtain the value of the decimal_literal with the exponent. == Examples == ''Examples of decimal literals:'' <p><syntaxhighlight lang="Ada"> 12        0      1E6    123_456  --''  integer literals'' 12.0      0.0    0.456  3.14159_26  --''  real literals''</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-2-4|Previous]] | [[Guide:95lrm/RM-2-4-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} fq986gk2r19t8ugdz7qbrf9jf71tvyt Guide:95lrm/RM-2-4-2 4200 935 3738 3737 2019-05-04T23:36:25Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-2-4-1|Previous]] | [[Guide:95lrm/RM-2-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 2.4.2 Based Literals}} <span id="I1201"></span><span id="I1202"></span><span id="I1203"></span><span id="I1204"></span><span id="I1205"></span><span id="I1206"></span><span id="I1207"></span><span id="I1208"></span><span id="I1209"></span><span id="I1210"></span>A based_literal is a numeric_literal expressed in a form that specifies the base explicitly. == Syntax == <p><span></span></p> based_literal<span id="I1211"></span> ::= <span id="I1212"></span>base # <span id="I1213"></span>based_numeral [.<span id="I1214"></span>based_numeral] # [<span id="I1215"></span>exponent] <p><span></span></p> base<span id="I1216"></span> ::= <span id="I1217"></span>numeral <p><span></span></p> based_numeral<span id="I1218"></span> ::= <span id="I1219"></span>extended_digit {[<span id="I1220"></span>underline] <span id="I1221"></span>extended_digit} <p><span></span></p> extended_digit<span id="I1222"></span> ::= <span id="I1223"></span>digit | A | B | C | D | E | F == Legality Rules == <span id="I1224"></span>The ''base'' (the numeric value of the decimal numeral preceding the first #) shall be at least two and at most sixteen. The extended_digits A through F represent the digits ten through fifteen, respectively. The value of each extended_digit of a based_literal shall be less than the base. == Static Semantics == The conventional meaning of based notation is assumed. An exponent indicates the power of the base by which the value of the based_literal without the exponent is to be multiplied to obtain the value of the based_literal with the exponent. The base and the exponent, if any, are in decimal notation. The extended_digits A through F can be written either in lower case or in upper case, with the same meaning. == Examples == ''Examples of based literals:'' <p><span></span></p> 2#1111_1111#  16#FF#       016#0ff#  --''  integer literals of value 255'' 16#E#E1       2#1110_0000#       --''  integer literals of value 224'' 16#F.FF#E+2   2#1.1111_1111_1110#E11 --''  real literals of value 4095.0'' </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-2-4-1|Previous]] | [[Guide:95lrm/RM-2-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} nrjap09wm06s5z0fmf47i2cevria3xd Guide:95lrm/RM-2-5 4200 936 3740 3739 2019-05-04T23:36:25Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-2-4-2|Previous]] | [[Guide:95lrm/RM-2-6|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 2.5 Character Literals}} A character_literal is formed by enclosing a graphic character between two apostrophe characters. == Syntax == <p><span></span></p> character_literal<span id="I1225"></span> ::= '<span id="I1226"></span>graphic_character' == Notes == 4  A character_literal is an enumeration literal of a character type. See [[Guide:95lrm/RM-3-5-2|3.5.2]]. == Examples == ''Examples of character literals:'' <p><syntaxhighlight lang="Ada"> 'A'     '*'     '''     ' '</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-2-4-2|Previous]] | [[Guide:95lrm/RM-2-6|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} j4osmme0pga18ojwrn8cfdf1mutsgab Guide:95lrm/RM-2-6 4200 937 3742 3741 2019-05-04T23:36:26Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-2-5|Previous]] | [[Guide:95lrm/RM-2-7|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 2.6 String Literals}} A string_literal is formed by a sequence of graphic characters (possibly none) enclosed between two quotation marks used as string brackets. They are used to represent operator_symbols (see [[Guide:95lrm/RM-6-1|6.1]]), values of a string type (see [[Guide:95lrm/RM-4-2|4.2]]), and array subaggregates (see [[Guide:95lrm/RM-4-3-3|4.3.3]]). <span id="I1227"></span> == Syntax == <p><span></span></p> string_literal<span id="I1228"></span> ::= "{<span id="I1229"></span>string_element}" <p><span></span></p> string_element<span id="I1230"></span> ::= "" | ''non_quotation_mark_''<span id="I1231"></span>graphic_character A string_element is either a pair of quotation marks (""), or a single graphic_character other than a quotation mark. == Static Semantics == <span id="I1232"></span>The ''sequence of characters'' of a string_literal is formed from the sequence of string_elements between the bracketing quotation marks, in the given order, with a string_element that is "" becoming a single quotation mark in the sequence of characters, and any other string_element being reproduced in the sequence. <span id="I1233"></span>A ''null string literal'' is a string_literal with no string_elements between the quotation marks. == Notes == 5  An end of line cannot appear in a string_literal. == Examples == ''Examples of string literals:'' <p><syntaxhighlight lang="Ada"> "Message of the day:" ""    --  a null string literal " "   "A"   """"      --  three string literals of length 1 "Characters such as $, %, and } are allowed in string literals"</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-2-5|Previous]] | [[Guide:95lrm/RM-2-7|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} hyqo1viyu0myma9htot2sgwupzwx2nf Guide:95lrm/RM-2-7 4200 938 3744 3743 2019-05-04T23:36:26Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-2-6|Previous]] | [[Guide:95lrm/RM-2-8|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 2.7 Comments}} A comment starts with two adjacent hyphens and extends up to the end of the line. == Syntax == <p><span></span></p> comment<span id="I1234"></span> ::= --{''non_end_of_line_''<span id="I1235"></span>character} A comment may appear on any line of a program. == Static Semantics == The presence or absence of comments has no influence on whether a program is legal or illegal. Furthermore, comments do not influence the meaning of a program; their sole purpose is the enlightenment of the human reader. == Examples == ''Examples of comments:'' <p><syntaxhighlight lang="Ada"> --  the last sentence above echoes the Algol 68 report  end;  --  processing of Line is complete  --  a long comment may be split onto --  two or more consecutive lines    -----------  the first two hyphens start the comment  </syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-2-6|Previous]] | [[Guide:95lrm/RM-2-8|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 9xwbnfx1wxv1jphrwlfy6eip5cvpcuj Guide:95lrm/RM-2-8 4200 939 3746 3745 2019-05-04T23:36:27Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-2-7|Previous]] | [[Guide:95lrm/RM-2-9|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 2.8 Pragmas}} <span id="I1236"></span>A pragma is a compiler directive. There are language-defined pragmas that give instructions for optimization, listing control, etc. An implementation may support additional (implementation-defined) pragmas. == Syntax == <p><span></span></p> pragma<span id="I1237"></span> ::= '''pragma''' <span id="I1238"></span>identifier [(<span id="I1239"></span>pragma_argument_association {, <span id="I1240"></span>pragma_argument_association})]; <p><span></span></p> pragma_argument_association<span id="I1241"></span> ::= [''pragma_argument_''<span id="I1242"></span>identifier =>] <span id="I1243"></span>name | [''pragma_argument_''<span id="I1244"></span>identifier =>] <span id="I1245"></span>expression In a pragma, any pragma_argument_associations without a ''pragma_argument_''identifier shall precede any associations with a ''pragma_argument_''identifier. Pragmas are only allowed at the following places in a program: * After a semicolon delimiter, but not within a formal_part or discriminant_part. * At any place where the syntax rules allow a construct defined by a syntactic category whose name ends with "declaration", "statement", "clause", or "alternative", or one of the syntactic categories variant or exception_handler; but not in place of such a construct. Also at any place where a compilation_unit would be allowed. Additional syntax rules and placement restrictions exist for specific pragmas. <span id="I1246"></span><span id="I1247"></span>The ''name'' of a pragma is the identifier following the reserved word '''pragma'''. <span id="I1248"></span><span id="I1249"></span>The name or expression of a pragma_argument_association is a ''pragma argument''. <span id="I1250"></span><span id="I1251"></span>An ''identifier specific to a pragma'' is an identifier that is used in a pragma argument with special meaning for that pragma. == Static Semantics == If an implementation does not recognize the name of a pragma, then it has no effect on the semantics of the program. Inside such a pragma, the only rules that apply are the Syntax Rules. == Dynamic Semantics == <span id="I1252"></span><span id="I1253"></span>Any pragma that appears at the place of an executable construct is executed. Unless otherwise specified for a particular pragma, this execution consists of the evaluation of each evaluable pragma argument in an arbitrary order. == Implementation Requirements == The implementation shall give a warning message for an unrecognized pragma name. == Implementation Permissions == An implementation may provide implementation-defined pragmas; the name of an implementation-defined pragma shall differ from those of the language-defined pragmas. An implementation may ignore an unrecognized pragma even if it violates some of the Syntax Rules, if detecting the syntax error is too complex. == Implementation Advice == Normally, implementation-defined pragmas should have no semantic effect for error-free programs; that is, if the implementation-defined pragmas are removed from a working program, the program should still be legal, and should still have the same semantics. Normally, an implementation should not define pragmas that can make an illegal program legal, except as follows: * A pragma used to complete a declaration, such as a pragma Import; * A pragma used to configure the environment by adding, removing, or replacing library_items. == Syntax == The forms of List, Page, and Optimize pragmas are as follows: <p><span></span></p> '''pragma''' <span id="I1254"></span><span id="I1255"></span>List(<span id="I1256"></span>identifier); <p><span></span></p> '''pragma''' <span id="I1257"></span><span id="I1258"></span>Page; <p><span></span></p> '''pragma''' <span id="I1259"></span><span id="I1260"></span>Optimize(<span id="I1261"></span>identifier); Other pragmas are defined throughout this International Standard, and are summarized in [[Guide:95lrm/RM-L|Annex L]]. == Static Semantics == A pragma List takes one of the identifiers On or Off as the single argument. This pragma is allowed anywhere a pragma is allowed. It specifies that listing of the compilation is to be continued or suspended until a List pragma with the opposite argument is given within the same compilation. The pragma itself is always listed if the compiler is producing a listing. A pragma Page is allowed anywhere a pragma is allowed. It specifies that the program text which follows the pragma should start on a new page (if the compiler is currently producing a listing). A pragma Optimize takes one of the identifiers Time, Space, or Off as the single argument. This pragma is allowed anywhere a pragma is allowed, and it applies until the end of the immediately enclosing declarative region, or for a pragma at the place of a compilation_unit, to the end of the compilation. It gives advice to the implementation as to whether time or space is the primary optimization criterion, or that optional optimizations should be turned off. It is implementation defined how this advice is followed. == Examples == ''Examples of pragmas:'' <p><syntaxhighlight lang="Ada"> pragma List(Off); -- turn off listing generation pragma Optimize(Off); -- turn off optional optimizations pragma Inline(Set_Mask); -- generate code for Set_Mask inline pragma Suppress(Range_Check, On => Index); -- turn off range checking on Index</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-2-7|Previous]] | [[Guide:95lrm/RM-2-9|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} mynrvfn6tev3lpzm0btbg19ly44jtgw Guide:95lrm/RM-2-9 4200 940 3748 3747 2019-05-04T23:36:27Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-2-8|Previous]] | [[Guide:95lrm/RM-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 2.9 Reserved Words}} == Syntax == ''This paragraph was deleted.'' <span id="I1262"></span>The following are the ''reserved words'' (ignoring upper/lower case distinctions): {| class="wikitable" !width="20%"| '''abort''' !width="20%"| '''else''' !width="20%"| '''new''' !width="20%"| '''return''' !width="20%"| |- | '''abs''' | '''elsif''' | '''not''' | '''reverse''' | |- | '''abstract''' | '''end''' | '''null''' |   | |- | '''accept''' | '''entry''' |   | '''select''' | |- | '''access''' | '''exception''' | '''of''' | '''separate''' | |- | '''aliased''' | '''exit''' | '''or''' | '''subtype''' | |- | '''all''' |   | '''others''' |   | |- | '''and''' | '''for''' | '''out''' | '''tagged''' | |- | '''array''' | '''function''' |   | '''task''' | |- | '''at''' |   | '''package''' | '''terminate''' | |- |   | '''generic''' | '''pragma''' | '''then''' | |- | '''begin''' | '''goto''' | '''private''' | '''type''' | |- | '''body''' |   | '''procedure''' |   | |- |   | '''if''' | '''protected''' | '''until''' | |- | '''case''' | '''in''' |   | '''use''' | |- | '''constant''' | '''is''' | '''raise''' |   | |- |   |   | '''range''' | '''when''' | |- | '''declare''' | '''limited''' | '''record''' | '''while''' | |- | '''delay''' | '''loop''' | '''rem''' | '''with''' | |- | '''delta''' |   | '''renames''' |   | |- | '''digits''' | '''mod''' | '''requeue''' | '''xor''' | |- | '''do''' |   |   |   | |} == Notes == 6  The reserved words appear in '''lower case boldface''' in this International Standard, except when used in the designator of an attribute (see [[Guide:95lrm/RM-4-1-4|4.1.4]]). Lower case boldface is also used for a reserved word in a string_literal used as an operator_symbol. This is merely a convention -- programs may be written in whatever typeface is desired and available. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-2-8|Previous]] | [[Guide:95lrm/RM-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} qu9ct5jx17ywt6mnfeh8o8cc2d1zpoq Guide:95lrm/RM-3 4200 941 3750 3749 2019-05-04T23:36:27Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-2-9|Previous]] | [[Guide:95lrm/RM-3-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Section 3: Declarations and Types}} This section describes the types in the language and the rules for declaring constants, variables, and named numbers. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-2-9|Previous]] | [[Guide:95lrm/RM-3-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} rjjacydfx20ra8a8gob48j2syrnvoha Guide:95lrm/RM-3-1 4200 942 3752 3751 2019-05-04T23:36:27Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3|Previous]] | [[Guide:95lrm/RM-3-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.1 Declarations}} <span id="I1263"></span>The language defines several kinds of named ''entities'' that are declared by declarations. <span id="I1264"></span>The entity's ''name'' is defined by the declaration, usually by a defining_identifier, but sometimes by a defining_character_literal or defining_operator_symbol. There are several forms of declaration. A basic_declaration is a form of declaration defined as follows. == Syntax == <p><span></span></p> basic_declaration<span id="I1265"></span> ::= <span id="I1266"></span>type_declaration | <span id="I1267"></span>subtype_declaration | <span id="I1268"></span>object_declaration | <span id="I1269"></span>number_declaration | <span id="I1270"></span>subprogram_declaration | <span id="I1271"></span>abstract_subprogram_declaration | <span id="I1272"></span>package_declaration | <span id="I1273"></span>renaming_declaration | <span id="I1274"></span>exception_declaration | <span id="I1275"></span>generic_declaration | <span id="I1276"></span>generic_instantiation <p><span></span></p> defining_identifier<span id="I1277"></span> ::= <span id="I1278"></span>identifier == Static Semantics == <span id="I1279"></span>A ''declaration'' is a language construct that associates a name with (a view of) an entity. <span id="I1280"></span><span id="I1281"></span>A declaration may appear explicitly in the program text (an ''explicit'' declaration), or may be supposed to occur at a given place in the text as a consequence of the semantics of another construct (an ''implicit'' declaration). <span id="I1282"></span>Each of the following is defined to be a declaration: any basic_declaration; an enumeration_literal_specification; a discriminant_specification; a component_declaration; a loop_parameter_specification; a parameter_specification; a subprogram_body; an entry_declaration; an entry_index_specification; a choice_parameter_specification; a generic_formal_parameter_declaration. <span id="I1283"></span><span id="I1284"></span>All declarations contain a ''definition'' for a ''view'' of an entity. A view consists of an identification of the entity (the entity ''of'' the view), plus view-specific characteristics that affect the use of the entity through that view (such as mode of access to an object, formal parameter names and defaults for a subprogram, or visibility to components of a type). In most cases, a declaration also contains the definition for the entity itself (a renaming_declaration is an example of a declaration that does not define a new entity, but instead defines a view of an existing entity (see [[Guide:95lrm/RM-8-5|8.5]])). <span id="I1285"></span>For each declaration, the language rules define a certain region of text called the ''scope'' of the declaration (see [[Guide:95lrm/RM-8-2|8.2]]). Most declarations associate an identifier with a declared entity. Within its scope, and only there, there are places where it is possible to use the identifier to refer to the declaration, the view it defines, and the associated entity; these places are defined by the visibility rules (see [[Guide:95lrm/RM-8-3|8.3]]). <span id="I1286"></span>At such places the identifier is said to be a ''name'' of the entity (the direct_name or selector_name); <span id="I1287"></span>the name is said to ''denote'' the declaration, the view, and the associated entity (see [[Guide:95lrm/RM-8-6|8.6]]). <span id="I1288"></span>The declaration is said to ''declare'' the name, the view, and in most cases, the entity itself. As an alternative to an identifier, an enumeration literal can be declared with a character_literal as its name (see [[Guide:95lrm/RM-3-5-1|3.5.1]]), and a function can be declared with an operator_symbol as its name (see [[Guide:95lrm/RM-6-1|6.1]]). <span id="I1289"></span>The syntax rules use the terms defining_identifier, defining_character_literal, and defining_operator_symbol for the defining occurrence of a name; these are collectively called ''defining names''. <span id="I1290"></span>The terms direct_name and selector_name are used for usage occurrences of identifiers, character_literals, and operator_symbols. These are collectively called ''usage names''. == Dynamic Semantics == <span id="I1291"></span>The process by which a construct achieves its run-time effect is called ''execution''. <span id="I1292"></span><span id="I1293"></span>This process is also called ''elaboration'' for declarations and ''evaluation'' for expressions. One of the terms execution, elaboration, or evaluation is defined by this International Standard for each construct that has a run-time effect. == Notes == 1  <span id="I1294"></span>At compile time, the declaration of an entity ''declares'' the entity. <span id="I1295"></span>At run time, the elaboration of the declaration ''creates'' the entity. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3|Previous]] | [[Guide:95lrm/RM-3-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} eanrdwvf6qod9859xs6gy80cepo63vz Guide:95lrm/RM-3-10 4200 943 3754 3753 2019-05-04T23:36:28Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-9-3|Previous]] | [[Guide:95lrm/RM-3-10-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.10 Access Types}} <span id="I2041"></span><span id="I2042"></span><span id="I2043"></span>A value of an access type (an ''access value'') provides indirect access to the object or subprogram it ''designates''. Depending on its type, an access value can designate either subprograms, objects created by allocators (see [[Guide:95lrm/RM-4-8|4.8]]), or more generally ''aliased'' objects of an appropriate type. <span id="I2044"></span><span id="I2045"></span> == Syntax == <p><span></span></p> access_type_definition<span id="I2046"></span> ::= <span id="I2047"></span>access_to_object_definition | <span id="I2048"></span>access_to_subprogram_definition <p><span></span></p> access_to_object_definition<span id="I2049"></span> ::= '''access''' [<span id="I2050"></span>general_access_modifier] <span id="I2051"></span>subtype_indication <p><span></span></p> general_access_modifier<span id="I2052"></span> ::= '''all''' | '''constant''' <p><span></span></p> access_to_subprogram_definition<span id="I2053"></span> ::= '''access''' ['''protected'''] '''procedure''' <span id="I2054"></span>parameter_profile | '''access''' ['''protected'''] '''function'''  <span id="I2055"></span>parameter_and_result_profile <p><span></span></p> access_definition<span id="I2056"></span> ::= '''access''' <span id="I2057"></span>subtype_mark == Static Semantics == <span id="I2058"></span><span id="I2059"></span><span id="I2060"></span><span id="I2061"></span>There are two kinds of access types, ''access-to-object'' types, whose values designate objects, and ''access-to-subprogram'' types, whose values designate subprograms. <span id="I2062"></span>Associated with an access-to-object type is a ''storage pool''; several access types may share the same storage pool. All descendants of an access type share the same storage pool. <span id="I2063"></span>A storage pool is an area of storage used to hold dynamically allocated objects (called ''pool elements'') created by allocators; storage pools are described further in [[Guide:95lrm/RM-13-11|13.11]], ''[[Guide:95lrm/RM-13-11|Storage Management]]''. <span id="I2064"></span><span id="I2065"></span>Access-to-object types are further subdivided into ''pool-specific'' access types, whose values can designate only the elements of their associated storage pool, and ''general'' access types, whose values can designate the elements of any storage pool, as well as aliased objects created by declarations rather than allocators, and aliased subcomponents of other objects. <span id="I2066"></span>A view of an object is defined to be ''aliased'' if it is defined by an object_declaration or component_definition with the reserved word '''aliased''', or by a renaming of an aliased view. In addition, the dereference of an access-to-object value denotes an aliased view, as does a view conversion (see [[Guide:95lrm/RM-4-6|4.6]]) of an aliased view. Finally, the current instance of a limited type, and a formal parameter or generic formal object of a tagged type are defined to be aliased. Aliased views are the ones that can be designated by an access value. <span id="I2067"></span><span id="I2068"></span><span id="I2069"></span>If the view defined by an object_declaration is aliased, and the type of the object has discriminants, then the object is constrained; if its nominal subtype is unconstrained, then the object is constrained by its initial value. Similarly, if the object created by an allocator has discriminants, the object is constrained, either by the designated subtype, or by its initial value. An access_to_object_definition defines an access-to-object type and its first subtype; <span id="I2070"></span><span id="I2071"></span>the subtype_indication defines the ''designated subtype'' of the access type. If a general_access_modifier appears, then the access type is a general access type. <span id="I2072"></span>If the modifier is the reserved word '''constant''', then the type is an ''access-to-constant type''; a designated object cannot be updated through a value of such a type. <span id="I2073"></span>If the modifier is the reserved word '''all''', then the type is an ''access-to-variable type''; a designated object can be both read and updated through a value of such a type. If no general_access_modifier appears in the access_to_object_definition, the access type is a pool-specific access-to-variable type. <span id="I2074"></span>An access_to_subprogram_definition defines an access-to-subprogram type and its first subtype; <span id="I2075"></span>the parameter_profile or parameter_and_result_profile defines the ''designated profile'' of the access type. <span id="I2076"></span>There is a ''calling convention'' associated with the designated profile; only subprograms with this calling convention can be designated by values of the access type. By default, the calling convention is ''''protected'''' if the reserved word '''protected''' appears, and ''Ada'' otherwise. See [[Guide:95lrm/RM-B|Annex B]] for how to override this default. <span id="I2077"></span><span id="I2078"></span><span id="I2079"></span>An access_definition defines an anonymous general access-to-variable type; the subtype_mark denotes its ''designated subtype''. An access_definition is used in the specification of an access discriminant (see [[Guide:95lrm/RM-3-7|3.7]]) or an access parameter (see [[Guide:95lrm/RM-6-1|6.1]]). <span id="I2080"></span>For each (named) access type, there is a literal '''null''' which has a null access value designating no entity at all. The null value of a named access type is the default initial value of the type. Other values of an access type are obtained by evaluating an attribute_reference for the Access or Unchecked_Access attribute of an aliased view of an object or non-intrinsic subprogram, or, in the case of a named access-to-object type, an allocator, which returns an access value designating a newly created object (see [[Guide:95lrm/RM-3-10-2|3.10.2]]). <span id="I2081"></span><span id="I2082"></span>All subtypes of an access-to-subprogram type are constrained. The first subtype of a type defined by an access_definition or an access_to_object_definition is unconstrained if the designated subtype is an unconstrained array or discriminated subtype; otherwise it is constrained. == Dynamic Semantics == <span id="I2083"></span>A composite_constraint is ''compatible'' with an unconstrained access subtype if it is compatible with the designated subtype. <span id="I2084"></span>An access value ''satisfies'' a composite_constraint of an access subtype if it equals the null value of its type or if it designates an object whose value satisfies the constraint. <span id="I2085"></span>The elaboration of an access_type_definition creates the access type and its first subtype. For an access-to-object type, this elaboration includes the elaboration of the subtype_indication, which creates the designated subtype. <span id="I2086"></span>The elaboration of an access_definition creates an anonymous general access-to-variable type (this happens as part of the initialization of an access parameter or access discriminant). == Notes == 77  Access values are called ''pointers'' or ''references'' in some other languages. 78  Each access-to-object type has an associated storage pool; several access types can share the same pool. An object can be created in the storage pool of an access type by an allocator (see [[Guide:95lrm/RM-4-8|4.8]]) for the access type. A storage pool (roughly) corresponds to what some other languages call a ''heap.'' See [[Guide:95lrm/RM-13-11|13.11]] for a discussion of pools. 79  Only index_constraints and discriminant_constraints can be applied to access types (see [[Guide:95lrm/RM-3-6-1|3.6.1]] and [[Guide:95lrm/RM-3-7-1|3.7.1]]). == Examples == ''Examples of access-to-object types:'' <p><syntaxhighlight lang="Ada"> type Peripheral_Ref is access Peripheral;  --  see 3.8.1 type Binop_Ptr is access all Binary_Operation'Class;                            -- general access-to-class-wide, see 3.9.1</syntaxhighlight></p> ''Example of an access subtype:'' <p><syntaxhighlight lang="Ada"> subtype Drum_Ref is Peripheral_Ref(Drum);  --  see 3.8.1</syntaxhighlight></p> ''Example of an access-to-subprogram type:'' <p><syntaxhighlight lang="Ada"> type Message_Procedure is access procedure (M : in String := "Error!"); procedure Default_Message_Procedure(M : in String); Give_Message : Message_Procedure := Default_Message_Procedure'Access; ... procedure Other_Procedure(M : in String); ... Give_Message := Other_Procedure'Access; ... Give_Message("File not found.");  -- call with parameter (.all is optional) Give_Message.all;                 -- call with no parameters</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-9-3|Previous]] | [[Guide:95lrm/RM-3-10-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} pk6h6psilmgy1832eb7x0zy9n3vwxl3 Guide:95lrm/RM-3-10-1 4200 944 3756 3755 2019-05-04T23:36:31Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-10|Previous]] | [[Guide:95lrm/RM-3-10-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.10.1 Incomplete Type Declarations}} There are no particular limitations on the designated type of an access type. In particular, the type of a component of the designated type can be another access type, or even the same access type. This permits mutually dependent and recursive access types. An incomplete_type_declaration can be used to introduce a type to be used as a designated type, while deferring its full definition to a subsequent full_type_declaration. == Syntax == <p><span></span></p> incomplete_type_declaration<span id="I2087"></span> ::= '''type''' <span id="I2088"></span>defining_identifier [<span id="I2089"></span>discriminant_part]; == Legality Rules == <span id="I2090"></span>An incomplete_type_declaration requires a completion, which shall be a full_type_declaration. If the incomplete_type_declaration occurs immediately within either the visible part of a package_specification or a declarative_part, then the full_type_declaration shall occur later and immediately within this visible part or declarative_part. If the incomplete_type_declaration occurs immediately within the private part of a given package_specification, then the full_type_declaration shall occur later and immediately within either the private part itself, or the declarative_part of the corresponding package_body. If an incomplete_type_declaration has a known_discriminant_part, then a full_type_declaration that completes it shall have a fully conforming (explicit) known_discriminant_part (see [[Guide:95lrm/RM-6-3-1|6.3.1]]). <span id="I2091"></span>If an incomplete_type_declaration has no discriminant_part (or an unknown_discriminant_part), then a corresponding full_type_declaration is nevertheless allowed to have discriminants, either explicitly, or inherited via derivation. The only allowed uses of a name that denotes an incomplete_type_declaration are as follows: * as the subtype_mark in the subtype_indication of an access_to_object_definition; the only form of constraint allowed in this subtype_indication is a discriminant_constraint; * as the subtype_mark defining the subtype of a parameter or result of an access_to_subprogram_definition; * as the subtype_mark in an access_definition; * as the prefix of an attribute_reference whose attribute_designator is Class; such an attribute_reference is similarly restricted to the uses allowed here; when used in this way, the corresponding full_type_declaration shall declare a tagged type, and the attribute_reference shall occur in the same library unit as the incomplete_type_declaration. A dereference (whether implicit or explicit -- see [[Guide:95lrm/RM-4-1|4.1]]) shall not be of an incomplete type. == Static Semantics == <span id="I2092"></span>An incomplete_type_declaration declares an incomplete type and its first subtype; the first subtype is unconstrained if a known_discriminant_part appears. == Dynamic Semantics == <span id="I2093"></span>The elaboration of an incomplete_type_declaration has no effect. == Notes == 80  <span id="I2094"></span>Within a declarative_part, an incomplete_type_declaration and a corresponding full_type_declaration cannot be separated by an intervening body. This is because a type has to be completely defined before it is frozen, and a body freezes all types declared prior to it in the same declarative_part (see [[Guide:95lrm/RM-13-14|13.14]]). == Examples == ''Example of a recursive type:'' <p><syntaxhighlight lang="Ada"> type Cell;  --  incomplete type declaration type Link is access Cell;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Cell is record    Value  : Integer;    Succ   : Link;    Pred   : Link; end record;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Head   : Link  := new Cell'(0, null, null); Next   : Link  := Head.Succ;</syntaxhighlight></p> ''Examples of mutually dependent access types:'' <p><syntaxhighlight lang="Ada"> type Person(<>);    -- incomplete type declaration type Car;           -- incomplete type declaration</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Person_Name is access Person; type Car_Name    is access all Car;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Car is record    Number  : Integer;    Owner   : Person_Name; end record;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Person(Sex : Gender) is record    Name     : String(1 .. 20);    Birth    : Date;    Age      : Integer range 0 .. 130;    Vehicle  : Car_Name;    case Sex is       when M => Wife           : Person_Name(Sex => F);       when F => Husband        : Person_Name(Sex => M);    end case; end record;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> My_Car, Your_Car, Next_Car : Car_Name := new Car;  -- see 4.8 George : Person_Name := new Person(M); ... George.Vehicle := Your_Car;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-10|Previous]] | [[Guide:95lrm/RM-3-10-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} sfpm0raho1lx67pugli2i8maf8890xx Guide:95lrm/RM-3-10-2 4200 945 3758 3757 2019-05-04T23:36:32Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-10-1|Previous]] | [[Guide:95lrm/RM-3-11|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.10.2 Operations of Access Types}} The attribute Access is used to create access values designating aliased objects and non-intrinsic subprograms. The ''accessibility'' rules prevent dangling references (in the absence of uses of certain unchecked features -- see Section 13). == Name Resolution Rules == <span id="I2095"></span>For an attribute_reference with attribute_designator Access (or Unchecked_Access -- see [[Guide:95lrm/RM-13-10|13.10]]), the expected type shall be a single access type; the prefix of such an attribute_reference is never interpreted as an implicit_dereference. <span id="I2096"></span>If the expected type is an access-to-subprogram type, then the expected profile of the prefix is the designated profile of the access type. == Static Semantics == <span id="I2097"></span><span id="I2098"></span><span id="I2099"></span><span id="I2100"></span><span id="I2101"></span><span id="I2102"></span>The accessibility rules, which prevent dangling references, are written in terms of ''accessibility levels'', which reflect the run-time nesting of ''masters''. As explained in [[Guide:95lrm/RM-7-6-1|7.6.1]], a master is the execution of a task_body, a block_statement, a subprogram_body, an entry_body, or an accept_statement. An accessibility level is ''deeper than'' another if it is more deeply nested at run time. For example, an object declared local to a called subprogram has a deeper accessibility level than an object declared local to the calling subprogram. The accessibility rules for access types require that the accessibility level of an object designated by an access value be no deeper than that of the access type. This ensures that the object will live at least as long as the access type, which in turn ensures that the access value cannot later designate an object that no longer exists. The Unchecked_Access attribute may be used to circumvent the accessibility rules. <span id="I2103"></span><span id="I2104"></span>A given accessibility level is said to be ''statically deeper'' than another if the given level is known at compile time (as defined below) to be deeper than the other for all possible executions. In most cases, accessibility is enforced at compile time by Legality Rules. Run-time accessibility checks are also used, since the Legality Rules do not cover certain cases involving access parameters and generic packages. Each master, and each entity and view created by it, has an accessibility level: * The accessibility level of a given master is deeper than that of each dynamically enclosing master, and deeper than that of each master upon which the task executing the given master directly depends (see [[Guide:95lrm/RM-9-3|9.3]]). * An entity or view created by a declaration has the same accessibility level as the innermost enclosing master, except in the cases of renaming and derived access types described below. A parameter of a master has the same accessibility level as the master. * The accessibility level of a view of an object or subprogram defined by a renaming_declaration is the same as that of the renamed view. * The accessibility level of a view conversion is the same as that of the operand. * For a function whose result type is a return-by-reference type, the accessibility level of the result object is the same as that of the master that elaborated the function body. For any other function, the accessibility level of the result object is that of the execution of the called function. * The accessibility level of a derived access type is the same as that of its ultimate ancestor. * The accessibility level of the anonymous access type of an access discriminant is the same as that of the containing object or associated constrained subtype. * The accessibility level of the anonymous access type of an access parameter is the same as that of the view designated by the actual. If the actual is an allocator, this is the accessibility level of the execution of the called subprogram. * The accessibility level of an object created by an allocator is the same as that of the access type. * The accessibility level of a view of an object or subprogram denoted by a dereference of an access value is the same as that of the access type. * The accessibility level of a component, protected subprogram, or entry of (a view of) a composite object is the same as that of (the view of) the composite object. <span id="I2105"></span><span id="I2106"></span>One accessibility level is defined to be ''statically deeper'' than another in the following cases: * For a master that is statically nested within another master, the accessibility level of the inner master is statically deeper than that of the outer master. * The statically deeper relationship does not apply to the accessibility level of the anonymous type of an access parameter; that is, such an accessibility level is not considered to be statically deeper, nor statically shallower, than any other. * For determining whether one level is statically deeper than another when within a generic package body, the generic package is presumed to be instantiated at the same level as where it was declared; run-time checks are needed in the case of more deeply nested instantiations. * For determining whether one level is statically deeper than another when within the declarative region of a type_declaration, the current instance of the type is presumed to be an object created at a deeper level than that of the type. <span id="I2107"></span><span id="I2108"></span>The accessibility level of all library units is called the ''library level''; a library-level declaration or entity is one whose accessibility level is the library level. The following attribute is defined for a prefix X that denotes an aliased view of an object: ;    X'Access : <span id="I2109"></span><span id="I2110"></span>X'Access yields an access value that designates the object denoted by X. The type of X'Access is an access-to-object type, as determined by the expected type. The expected type shall be a general access type. <span id="I2111"></span>X shall denote an aliased view of an object, including possibly the current instance (see [[Guide:95lrm/RM-8-6|8.6]]) of a limited type within its definition, or a formal parameter or generic formal object of a tagged type. The view denoted by the prefix X shall satisfy the following additional requirements, presuming the expected type for X'Access is the general access type ''A'' with designated type ''D'': <p><span></span></p> :* If ''A'' is an access-to-variable type, then the view shall be a variable; on the other hand, if ''A'' is an access-to-constant type, the view may be either a constant or a variable. <p><span></span></p> :* The view shall not be a subcomponent that depends on discriminants of a variable whose nominal subtype is unconstrained, unless this subtype is indefinite, or the variable is aliased. <p><span></span></p> :* If ''A'' is a named access type and ''D'' is a tagged type, then the type of the view shall be covered by ''D''; if ''A'' is anonymous and ''D'' is tagged, then the type of the view shall be either ''D'''Class or a type covered by D; if ''D'' is untagged, then the type of the view shall be ''D'', and ''A'''s designated subtype shall either statically match the nominal subtype of the view or be discriminated and unconstrained; <span id="I2112"></span> <p><span></span></p> :* The accessibility level of the view shall not be statically deeper than that of the access type ''A''. In addition to the places where Legality Rules normally apply (see [[Guide:95lrm/RM-12-3|12.3]]), this rule applies also in the private part of an instance of a generic unit. <span id="I2113"></span><span id="I2114"></span> <span id="I2115"></span><span id="I2116"></span><span id="I2117"></span>A check is made that the accessibility level of X is not deeper than that of the access type ''A''. If this check fails, Program_Error is raised. <span id="I2118"></span>If the nominal subtype of X does not statically match the designated subtype of ''A'', a view conversion of X to the designated subtype is evaluated (which might raise Constraint_Error -- see [[Guide:95lrm/RM-4-6|4.6]]) and the value of X'Access designates that view. The following attribute is defined for a prefix P that denotes a subprogram: ;  P'Access : <span id="I2119"></span><span id="I2120"></span>P'Access yields an access value that designates the subprogram denoted by P. The type of P'Access is an access-to-subprogram type (''S''), as determined by the expected type. <span id="I2121"></span>The accessibility level of P shall not be statically deeper than that of ''S''. <span id="I2122"></span>In addition to the places where Legality Rules normally apply (see [[Guide:95lrm/RM-12-3|12.3]]), this rule applies also in the private part of an instance of a generic unit. The profile of P shall be subtype-conformant with the designated profile of ''S'', and shall not be Intrinsic. <span id="I2123"></span>If the subprogram denoted by P is declared within a generic body, ''S'' shall be declared within the generic body. == Notes == 81  The Unchecked_Access attribute yields the same result as the Access attribute for objects, but has fewer restrictions (see [[Guide:95lrm/RM-13-10|13.10]]). There are other predefined operations that yield access values: an allocator can be used to create an object, and return an access value that designates it (see [[Guide:95lrm/RM-4-8|4.8]]); evaluating the literal '''null''' yields a null access value that designates no entity at all (see [[Guide:95lrm/RM-4-2|4.2]]). 82  <span id="I2124"></span>The predefined operations of an access type also include the assignment operation, qualification, and membership tests. Explicit conversion is allowed between general access types with matching designated subtypes; explicit conversion is allowed between access-to-subprogram types with subtype conformant profiles (see [[Guide:95lrm/RM-4-6|4.6]]). <span id="I2125"></span>Named access types have predefined equality operators; anonymous access types do not (see [[Guide:95lrm/RM-4-5-2|4.5.2]]). 83  The object or subprogram designated by an access value can be named with a dereference, either an explicit_dereference or an implicit_dereference. See [[Guide:95lrm/RM-4-1|4.1]]. 84  A call through the dereference of an access-to-subprogram value is never a dispatching call. 85  <span id="I2126"></span><span id="I2127"></span>The accessibility rules imply that it is not possible to use the Access attribute to implement ''downward closures'' -- that is, to pass a more-nested subprogram as a parameter to a less-nested subprogram, as might be desired for example for an iterator abstraction. Instead, downward closures can be implemented using generic formal subprograms (see [[Guide:95lrm/RM-12-6|12.6]]). Note that Unchecked_Access is not allowed for subprograms. 86  Note that using an access-to-class-wide tagged type with a dispatching operation is a potentially more structured alternative to using an access-to-subprogram type. 87  An implementation may consider two access-to-subprogram values to be unequal, even though they designate the same subprogram. This might be because one points directly to the subprogram, while the other points to a special prologue that performs an Elaboration_Check and then jumps to the subprogram. See [[Guide:95lrm/RM-4-5-2|4.5.2]]. == Examples == ''Example of use of the Access attribute:'' <p><syntaxhighlight lang="Ada"> Martha : Person_Name := new Person(F);       -- see 3.10.1 Cars   : array (1..2) of aliased Car; ... Martha.Vehicle := Cars(1)'Access; George.Vehicle := Cars(2)'Access;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-10-1|Previous]] | [[Guide:95lrm/RM-3-11|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 45zwhvfxl14iecnnrkeamaw6juq7ekl Guide:95lrm/RM-3-11 4200 946 3760 3759 2019-05-04T23:36:33Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-10-2|Previous]] | [[Guide:95lrm/RM-3-11-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.11 Declarative Parts}} A declarative_part contains declarative_items (possibly none). == Syntax == <p><span></span></p> declarative_part<span id="I2128"></span> ::= {<span id="I2129"></span>declarative_item} <p><span></span></p> declarative_item<span id="I2130"></span> ::= <span id="I2131"></span>basic_declarative_item | <span id="I2132"></span>body <p><span></span></p> basic_declarative_item<span id="I2133"></span> ::= <span id="I2134"></span>basic_declaration | <span id="I2135"></span>aspect_clause | <span id="I2136"></span>use_clause <p><span></span></p> body<span id="I2137"></span> ::= <span id="I2138"></span>proper_body | <span id="I2139"></span>body_stub <p><span></span></p> proper_body<span id="I2140"></span> ::= <span id="I2141"></span>subprogram_body | <span id="I2142"></span>package_body | <span id="I2143"></span>task_body | <span id="I2144"></span>protected_body == Dynamic Semantics == <span id="I2145"></span>The elaboration of a declarative_part consists of the elaboration of the declarative_items, if any, in the order in which they are given in the declarative_part. <span id="I2146"></span>An elaborable construct is in the ''elaborated'' state after the normal completion of its elaboration. Prior to that, it is ''not yet elaborated''. <span id="I2147"></span><span id="I2148"></span>For a construct that attempts to use a body, a check (Elaboration_Check) is performed, as follows: * For a call to a (non-protected) subprogram that has an explicit body, a check is made that the body is already elaborated. This check and the evaluations of any actual parameters of the call are done in an arbitrary order. * For a call to a protected operation of a protected type (that has a body -- no check is performed if a pragma Import applies to the protected type), a check is made that the protected_body is already elaborated. This check and the evaluations of any actual parameters of the call are done in an arbitrary order. * For the activation of a task, a check is made by the activator that the task_body is already elaborated. If two or more tasks are being activated together (see [[Guide:95lrm/RM-9-2|9.2]]), as the result of the elaboration of a declarative_part or the initialization for the object created by an allocator, this check is done for all of them before activating any of them. * For the instantiation of a generic unit that has a body, a check is made that this body is already elaborated. This check and the evaluation of any explicit_generic_actual_parameters of the instantiation are done in an arbitrary order. <span id="I2149"></span>The exception Program_Error is raised if any of these checks fails. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-10-2|Previous]] | [[Guide:95lrm/RM-3-11-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 6841vvom37or8ljaby1qrmf15qe09s3 Guide:95lrm/RM-3-11-1 4200 947 3762 3761 2019-05-04T23:36:33Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-11|Previous]] | [[Guide:95lrm/RM-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.11.1 Completions of Declarations}} Declarations sometimes come in two parts. <span id="I2150"></span>A declaration that requires a second part is said to ''require completion''. <span id="I2151"></span>The second part is called the ''completion'' of the declaration (and of the entity declared), and is either another declaration, a body, or a pragma. A <span id="I2152"></span>''body'' is a body, an entry_body, or a renaming-as-body (see [[Guide:95lrm/RM-8-5-4|8.5.4]]). == Name Resolution Rules == A construct that can be a completion is interpreted as the completion of a prior declaration only if: * The declaration and the completion occur immediately within the same declarative region; * The defining name or defining_program_unit_name in the completion is the same as in the declaration, or in the case of a pragma, the pragma applies to the declaration; * If the declaration is overloadable, then the completion either has a type-conformant profile, or is a pragma. <span id="I2153"></span> == Legality Rules == An implicit declaration shall not have a completion. <span id="I2154"></span>For any explicit declaration that is specified to ''require completion'', there shall be a corresponding explicit completion. At most one completion is allowed for a given declaration. Additional requirements on completions appear where each kind of completion is defined. <span id="I2155"></span>A type is ''completely defined'' at a place that is after its full type definition (if it has one) and after all of its subcomponent types are completely defined. A type shall be completely defined before it is frozen (see [[Guide:95lrm/RM-13-14|13.14]] and [[Guide:95lrm/RM-7-3|7.3]]). == Notes == 88  Completions are in principle allowed for any kind of explicit declaration. However, for some kinds of declaration, the only allowed completion is a pragma Import, and implementations are not required to support pragma Import for every kind of entity. 89  There are rules that prevent premature uses of declarations that have a corresponding completion. The Elaboration_Checks of [[Guide:95lrm/RM-3-11|3.11]] prevent such uses at run time for subprograms, protected operations, tasks, and generic units. The rules of [[Guide:95lrm/RM-13-14|13.14]], ''[[Guide:95lrm/RM-13-14|Freezing Rules]]'' prevent, at compile time, premature uses of other entities such as private types and deferred constants. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-11|Previous]] | [[Guide:95lrm/RM-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 9pjup4u8tdfcvk394igra0999l6jt7c Guide:95lrm/RM-3-2 4200 948 3764 3763 2019-05-04T23:36:33Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-1|Previous]] | [[Guide:95lrm/RM-3-2-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.2 Types and Subtypes}} == Static Semantics == <span id="I1296"></span><span id="I1297"></span>A ''type'' is characterized by a set of values, and a set of ''primitive operations'' which implement the fundamental aspects of its semantics. <span id="I1298"></span>An ''object'' of a given type is a run-time entity that contains (has) a value of the type. <span id="I1299"></span>Types are grouped into ''classes'' of types, reflecting the similarity of their values and primitive operations. <span id="I1300"></span>There exist several ''language-defined classes'' of types (see NOTES below). <span id="I1301"></span>''Elementary'' types are those whose values are logically indivisible; <span id="I1302"></span><span id="I1303"></span>''composite'' types are those whose values are composed of ''component'' values. <span id="I1304"></span> <span id="I1305"></span>The elementary types are the ''scalar'' types (''discrete'' and ''real'') and the ''access'' types (whose values provide access to objects or subprograms). <span id="I1306"></span><span id="I1307"></span>Discrete types are either ''integer'' types or are defined by enumeration of their values (''enumeration'' types). <span id="I1308"></span>Real types are either ''floating point'' types or ''fixed point'' types. The composite types are the ''record'' types, ''record extensions'', ''array'' types, ''task'' types, and ''protected'' types. <span id="I1309"></span><span id="I1310"></span>A ''private'' type or ''private extension'' represents a partial view (see [[Guide:95lrm/RM-7-3|7.3]]) of a type, providing support for data abstraction. A partial view is a composite type. <span id="I1311"></span>Certain composite types (and partial views thereof) have special components called ''discriminants'' whose values affect the presence, constraints, or initialization of other components. Discriminants can be thought of as parameters of the type. <span id="I1312"></span>The term ''subcomponent'' is used in this International Standard in place of the term component to indicate either a component, or a component of another subcomponent. Where other subcomponents are excluded, the term component is used instead. <span id="I1313"></span>Similarly, a ''part'' of an object or value is used to mean the whole object or value, or any set of its subcomponents. <span id="I1314"></span>The set of possible values for an object of a given type can be subjected to a condition that is called a ''constraint'' <span id="I1315"></span>(the case of a ''null constraint'' that specifies no restriction is also included); the rules for which values satisfy a given kind of constraint are given in [[Guide:95lrm/RM-3-5|3.5]] for range_constraints, [[Guide:95lrm/RM-3-6-1|3.6.1]] for index_constraints, and [[Guide:95lrm/RM-3-7-1|3.7.1]] for discriminant_constraints. <span id="I1316"></span>A ''subtype'' of a given type is a combination of the type, a constraint on values of the type, and certain attributes specific to the subtype. The given type is called the type ''of'' the subtype. Similarly, the associated constraint is called the constraint ''of'' the subtype. The set of values of a subtype consists of the values of its type that satisfy its constraint. <span id="I1317"></span>Such values ''belong'' to the subtype. <span id="I1318"></span><span id="I1319"></span><span id="I1320"></span><span id="I1321"></span>A subtype is called an ''unconstrained'' subtype if its type has unknown discriminants, or if its type allows range, index, or discriminant constraints, but the subtype does not impose such a constraint; otherwise, the subtype is called a ''constrained'' subtype (since it has no unconstrained characteristics). == Notes == 2  Any set of types that is closed under derivation (see [[Guide:95lrm/RM-3-4|3.4]]) can be called a ''class'' of types. However, only certain classes are used in the description of the rules of the language -- generally those that have their own particular set of primitive operations (see [[Guide:95lrm/RM-3-2-3|3.2.3]]), or that correspond to a set of types that are matched by a given kind of generic formal type (see [[Guide:95lrm/RM-12-5|12.5]]). <span id="I1322"></span>The following are examples of ''interesting'' ''language-defined classes'': elementary, scalar, discrete, enumeration, character, boolean, integer, signed integer, modular, real, floating point, fixed point, ordinary fixed point, decimal fixed point, numeric, access, access-to-object, access-to-subprogram, composite, array, string, (untagged) record, tagged, task, protected, nonlimited. Special syntax is provided to define types in each of these classes. These language-defined classes are organized like this: <p><span></span></p> all types elementary scalar discrete     enumeration        character     boolean        other enumeration    integer       signed integer        modular integer real floating point     fixed point        ordinary fixed point        decimal fixed point access access-to-object  access-to-subprogram composite array string other array untagged record tagged task protected The classes ''numeric'' and ''nonlimited'' represent other classification dimensions and do not fit into the above strictly hierarchical picture. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-1|Previous]] | [[Guide:95lrm/RM-3-2-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} cicjsswmz46xnr5wbzxadwd5wgfkysz Guide:95lrm/RM-3-2-1 4200 949 3766 3765 2019-05-04T23:36:33Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-2|Previous]] | [[Guide:95lrm/RM-3-2-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.2.1 Type Declarations}} A type_declaration declares a type and its first subtype. == Syntax == <p><span></span></p> type_declaration<span id="I1323"></span> ::=  <span id="I1324"></span>full_type_declaration | <span id="I1325"></span>incomplete_type_declaration | <span id="I1326"></span>private_type_declaration | <span id="I1327"></span>private_extension_declaration <p><span></span></p> full_type_declaration<span id="I1328"></span> ::= '''type''' <span id="I1329"></span>defining_identifier [<span id="I1330"></span>known_discriminant_part] '''is''' <span id="I1331"></span>type_definition; | <span id="I1332"></span>task_type_declaration | <span id="I1333"></span>protected_type_declaration <p><span></span></p> type_definition<span id="I1334"></span> ::= <span id="I1335"></span>enumeration_type_definition | <span id="I1336"></span>integer_type_definition | <span id="I1337"></span>real_type_definition | <span id="I1338"></span>array_type_definition | <span id="I1339"></span>record_type_definition | <span id="I1340"></span>access_type_definition | <span id="I1341"></span>derived_type_definition == Legality Rules == A given type shall not have a subcomponent whose type is the given type itself. == Static Semantics == <span id="I1342"></span>The defining_identifier of a type_declaration denotes the ''first subtype'' of the type. The known_discriminant_part, if any, defines the discriminants of the type (see [[Guide:95lrm/RM-3-7|3.7]], ''[[Guide:95lrm/RM-3-7|Discriminants]]''). The remainder of the type_declaration defines the remaining characteristics of (the view of) the type. <span id="I1343"></span>A type defined by a type_declaration is a ''named'' type; such a type has one or more nameable subtypes. <span id="I1344"></span>Certain other forms of declaration also include type definitions as part of the declaration for an object (including a parameter or a discriminant). The type defined by such a declaration is ''anonymous'' -- it has no nameable subtypes. <span id="I1345"></span>For explanatory purposes, this International Standard sometimes refers to an anonymous type by a pseudo-name, written in italics, and uses such pseudo-names at places where the syntax normally requires an identifier. For a named type whose first subtype is T, this International Standard sometimes refers to the type of T as simply ''the type T.'' <span id="I1346"></span>A named type that is declared by a full_type_declaration, or an anonymous type that is defined as part of declaring an object of the type, is called a ''full type''. <span id="I1347"></span>The type_definition, task_definition, protected_definition, or access_definition that defines a full type is called a ''full type definition''. Types declared by other forms of type_declaration are not separate types; they are partial or incomplete views of some full type. <span id="I1348"></span>The definition of a type implicitly declares certain ''predefined operators'' that operate on the type, according to what classes the type belongs, as specified in [[Guide:95lrm/RM-4-5|4.5]], ''[[Guide:95lrm/RM-4-5|Operators and Expression Evaluation]]''. <span id="I1349"></span>The ''predefined types'' (for example the types Boolean, Wide_Character, Integer, ''root_integer'', and ''universal_integer'') are the types that are defined in a predefined library package called Standard; this package also includes the (implicit) declarations of their predefined operators. The package Standard is described in [[Guide:95lrm/RM-A-1|A.1]]. == Dynamic Semantics == <span id="I1350"></span>The elaboration of a full_type_declaration consists of the elaboration of the full type definition. <span id="I1351"></span>Each elaboration of a full type definition creates a distinct type and its first subtype. == Examples == ''Examples of type definitions:'' <p><syntaxhighlight lang="Ada"> (White, Red, Yellow, Green, Blue, Brown, Black) range 1 .. 72 array(1 .. 10) of Integer</syntaxhighlight></p> ''Examples of type declarations:'' <p><syntaxhighlight lang="Ada"> type Color  is (White, Red, Yellow, Green, Blue, Brown, Black); type Column is range 1 .. 72; type Table  is array(1 .. 10) of Integer;</syntaxhighlight></p> == Notes == 3  Each of the above examples declares a named type. The identifier given denotes the first subtype of the type. Other named subtypes of the type can be declared with subtype_declarations (see [[Guide:95lrm/RM-3-2-2|3.2.2]]). Although names do not directly denote types, a phrase like ''the type Column'' is sometimes used in this International Standard to refer to the type of Column, where Column denotes the first subtype of the type. For an example of the definition of an anonymous type, see the declaration of the array Color_Table in [[Guide:95lrm/RM-3-3-1|3.3.1]]; its type is anonymous -- it has no nameable subtypes. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-2|Previous]] | [[Guide:95lrm/RM-3-2-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} gtk9bxch5x4m55t83w05938f6p0vlep Guide:95lrm/RM-3-2-2 4200 950 3768 3767 2019-05-04T23:36:34Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-2-1|Previous]] | [[Guide:95lrm/RM-3-2-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.2.2 Subtype Declarations}} A subtype_declaration declares a subtype of some previously declared type, as defined by a subtype_indication. == Syntax == <p><span></span></p> subtype_declaration<span id="I1352"></span> ::= '''subtype''' <span id="I1353"></span>defining_identifier '''is''' <span id="I1354"></span>subtype_indication; <p><span></span></p> subtype_indication<span id="I1355"></span> ::=  <span id="I1356"></span>subtype_mark [<span id="I1357"></span>constraint] <p><span></span></p> subtype_mark<span id="I1358"></span> ::= ''subtype_''<span id="I1359"></span>name <p><span></span></p> constraint<span id="I1360"></span> ::= <span id="I1361"></span>scalar_constraint | <span id="I1362"></span>composite_constraint <p><span></span></p> scalar_constraint<span id="I1363"></span> ::= <span id="I1364"></span>range_constraint | <span id="I1365"></span>digits_constraint | <span id="I1366"></span>delta_constraint <p><span></span></p> composite_constraint<span id="I1367"></span> ::= <span id="I1368"></span>index_constraint | <span id="I1369"></span>discriminant_constraint == Name Resolution Rules == A subtype_mark shall resolve to denote a subtype. <span id="I1370"></span>The type ''determined by'' a subtype_mark is the type of the subtype denoted by the subtype_mark. == Dynamic Semantics == <span id="I1371"></span>The elaboration of a subtype_declaration consists of the elaboration of the subtype_indication. <span id="I1372"></span>The elaboration of a subtype_indication creates a new subtype. If the subtype_indication does not include a constraint, the new subtype has the same (possibly null) constraint as that denoted by the subtype_mark. The elaboration of a subtype_indication that includes a constraint proceeds as follows: * The constraint is first elaborated. * <span id="I1373"></span><span id="I1374"></span>A check is then made that the constraint is ''compatible'' with the subtype denoted by the subtype_mark. The condition imposed by a constraint is the condition obtained after elaboration of the constraint. <span id="I1375"></span>The rules defining compatibility are given for each form of constraint in the appropriate subclause. These rules are such that if a constraint is ''compatible'' with a subtype, then the condition imposed by the constraint cannot contradict any condition already imposed by the subtype on its values. <span id="I1376"></span>The exception Constraint_Error is raised if any check of compatibility fails. == Notes == 4  A scalar_constraint may be applied to a subtype of an appropriate scalar type (see [[Guide:95lrm/RM-3-5|3.5]], [[Guide:95lrm/RM-3-5-9|3.5.9]], and [[Guide:95lrm/RM-J-3|J.3]]), even if the subtype is already constrained. On the other hand, a composite_constraint may be applied to a composite subtype (or an access-to-composite subtype) only if the composite subtype is unconstrained (see [[Guide:95lrm/RM-3-6-1|3.6.1]] and [[Guide:95lrm/RM-3-7-1|3.7.1]]). == Examples == ''Examples of subtype declarations:'' <p><syntaxhighlight lang="Ada"> subtype Rainbow   is Color range Red .. Blue;        --  see 3.2.1 subtype Red_Blue  is Rainbow; subtype Int       is Integer; subtype Small_Int is Integer range -10 .. 10; subtype Up_To_K   is Column range 1 .. K;            --  see 3.2.1 subtype Square    is Matrix(1 .. 10, 1 .. 10);       --  see 3.6 subtype Male      is Person(Sex => M);               --  see 3.10.1</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-2-1|Previous]] | [[Guide:95lrm/RM-3-2-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} ityu523gtx1eqs3n1ish9z446dxekq6 Guide:95lrm/RM-3-2-3 4200 951 3770 3769 2019-05-04T23:36:34Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-2-2|Previous]] | [[Guide:95lrm/RM-3-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.2.3 Classification of Operations}} == Static Semantics == <span id="I1377"></span>An operation ''operates on a type'' ''T'' if it yields a value of type ''T'', if it has an operand whose expected type (see [[Guide:95lrm/RM-8-6|8.6]]) is ''T'', or if it has an access parameter (see [[Guide:95lrm/RM-6-1|6.1]]) designating ''T''. <span id="I1378"></span>A predefined operator, or other language-defined operation such as assignment or a membership test, that operates on a type, is called a ''predefined operation'' of the type. <span id="I1379"></span>The ''primitive operations'' of a type are the predefined operations of the type, plus any user-defined primitive subprograms. <span id="I1380"></span>The ''primitive subprograms'' of a specific type are defined as follows: * The predefined operators of the type (see [[Guide:95lrm/RM-4-5|4.5]]); * For a derived type, the inherited (see [[Guide:95lrm/RM-3-4|3.4]]) user-defined subprograms; * For an enumeration type, the enumeration literals (which are considered parameterless functions -- see [[Guide:95lrm/RM-3-5-1|3.5.1]]); * For a specific type declared immediately within a package_specification, any subprograms (in addition to the enumeration literals) that are explicitly declared immediately within the same package_specification and that operate on the type; * <span id="I1381"></span>Any subprograms not covered above that are explicitly declared immediately within the same declarative region as the type and that override (see [[Guide:95lrm/RM-8-3|8.3]]) other implicitly declared primitive subprograms of the type. <span id="I1382"></span>A primitive subprogram whose designator is an operator_symbol is called a ''primitive operator''. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-2-2|Previous]] | [[Guide:95lrm/RM-3-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 2dicge5imcweidb8s7nypq8hec2dvp5 Guide:95lrm/RM-3-3 4200 952 3772 3771 2019-05-04T23:36:34Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-2-3|Previous]] | [[Guide:95lrm/RM-3-3-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.3 Objects and Named Numbers}} Objects are created at run time and contain a value of a given type. <span id="I1383"></span>An object can be created and initialized as part of elaborating a declaration, evaluating an allocator, aggregate, or function_call, or passing a parameter by copy. Prior to reclaiming the storage for an object, it is finalized if necessary (see [[Guide:95lrm/RM-7-6-1|7.6.1]]). == Static Semantics == <span id="I1384"></span>All of the following are objects: * the entity declared by an object_declaration; * a formal parameter of a subprogram, entry, or generic subprogram; * a generic formal object; * a loop parameter; * a choice parameter of an exception_handler; * an entry index of an entry_body; * the result of dereferencing an access-to-object value (see [[Guide:95lrm/RM-4-1|4.1]]); * the result of evaluating a function_call (or the equivalent operator invocation -- see [[Guide:95lrm/RM-6-6|6.6]]); * the result of evaluating an aggregate; * a component, slice, or view conversion of another object. <span id="I1385"></span><span id="I1386"></span><span id="I1387"></span><span id="I1388"></span><span id="I1389"></span><span id="I1390"></span>An object is either a ''constant'' object or a ''variable'' object. The value of a constant object cannot be changed between its initialization and its finalization, whereas the value of a variable object can be changed. Similarly, a view of an object is either a ''constant'' or a ''variable''. All views of a constant object are constant. A constant view of a variable object cannot be used to modify the value of the variable. The terms constant and variable by themselves refer to constant and variable views of objects. <span id="I1391"></span>The value of an object is ''read'' when the value of any part of the object is evaluated, or when the value of an enclosing object is evaluated. <span id="I1392"></span>The value of a variable is ''updated'' when an assignment is performed to any part of the variable, or when an assignment is performed to an enclosing object. Whether a view of an object is constant or variable is determined by the definition of the view. The following (and no others) represent constants: * an object declared by an object_declaration with the reserved word '''constant'''; * a formal parameter or generic formal object of mode '''in'''; * a discriminant; * a loop parameter, choice parameter, or entry index; * the dereference of an access-to-constant value; * the result of evaluating a function_call or an aggregate; * a selected_component, indexed_component, slice, or view conversion of a constant. <span id="I1393"></span>At the place where a view of an object is defined, a ''nominal subtype'' is associated with the view. <span id="I1394"></span><span id="I1395"></span>The object's ''actual subtype'' (that is, its subtype) can be more restrictive than the nominal subtype of the view; it always is if the nominal subtype is an ''indefinite subtype''. <span id="I1396"></span><span id="I1397"></span>A subtype is an indefinite subtype if it is an unconstrained array subtype, or if it has unknown discriminants or unconstrained discriminants without defaults (see [[Guide:95lrm/RM-3-7|3.7]]); otherwise the subtype is a ''definite'' subtype (all elementary subtypes are definite subtypes). A class-wide subtype is defined to have unknown discriminants, and is therefore an indefinite subtype. An indefinite subtype does not by itself provide enough information to create an object; an additional constraint or explicit initialization expression is necessary (see [[Guide:95lrm/RM-3-3-1|3.3.1]]). A component cannot have an indefinite nominal subtype. <span id="I1398"></span>A ''named number'' provides a name for a numeric value known at compile time. It is declared by a number_declaration. == Notes == 5  A constant cannot be the target of an assignment operation, nor be passed as an '''in''' '''out''' or '''out''' parameter, between its initialization and finalization, if any. 6  The nominal and actual subtypes of an elementary object are always the same. For a discriminated or array object, if the nominal subtype is constrained then so is the actual subtype. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-2-3|Previous]] | [[Guide:95lrm/RM-3-3-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} qrtqggdt2d9y8qeg180kglz5vvwa3px Guide:95lrm/RM-3-3-1 4200 953 3774 3773 2019-05-04T23:36:36Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-3|Previous]] | [[Guide:95lrm/RM-3-3-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.3.1 Object Declarations}} <span id="I1399"></span><span id="I1400"></span><span id="I1401"></span>An object_declaration declares a ''stand-alone'' object with a given nominal subtype and, optionally, an explicit initial value given by an initialization expression. <span id="I1402"></span><span id="I1403"></span><span id="I1404"></span>For an array, task, or protected object, the object_declaration may include the definition of the (anonymous) type of the object. == Syntax == <p><span></span></p> object_declaration<span id="I1405"></span> ::= <span id="I1406"></span>defining_identifier_list : ['''aliased'''] ['''constant'''] <span id="I1407"></span>subtype_indication [:= <span id="I1408"></span>expression]; | <span id="I1409"></span>defining_identifier_list : ['''aliased'''] ['''constant'''] <span id="I1410"></span>array_type_definition [:= <span id="I1411"></span>expression]; | <span id="I1412"></span>single_task_declaration | <span id="I1413"></span>single_protected_declaration <p><span></span></p> defining_identifier_list<span id="I1414"></span> ::= <span id="I1415"></span>defining_identifier {, <span id="I1416"></span>defining_identifier} == Name Resolution Rules == <span id="I1417"></span>For an object_declaration with an expression following the compound delimiter :=, the type expected for the expression is that of the object. <span id="I1418"></span>This expression is called the ''initialization expression''. <span id="I1419"></span> == Legality Rules == An object_declaration without the reserved word '''constant''' declares a variable object. If it has a subtype_indication or an array_type_definition that defines an indefinite subtype, then there shall be an initialization expression. An initialization expression shall not be given if the object is of a limited type. == Static Semantics == An object_declaration with the reserved word '''constant''' declares a constant object. <span id="I1420"></span>If it has an initialization expression, then it is called a ''full constant declaration''. <span id="I1421"></span>Otherwise it is called a ''deferred constant declaration''. The rules for deferred constant declarations are given in clause [[Guide:95lrm/RM-7-4|7.4]]. The rules for full constant declarations are given in this subclause. Any declaration that includes a defining_identifier_list with more than one defining_identifier is equivalent to a series of declarations each containing one defining_identifier from the list, with the rest of the text of the declaration copied for each declaration in the series, in the same order as the list. The remainder of this International Standard relies on this equivalence; explanations are given for declarations with a single defining_identifier. <span id="I1422"></span>The subtype_indication or full type definition of an object_declaration defines the nominal subtype of the object. The object_declaration declares an object of the type of the nominal subtype. == Dynamic Semantics == <span id="I1423"></span>If a composite object declared by an object_declaration has an unconstrained nominal subtype, then if this subtype is indefinite or the object is constant or aliased (see [[Guide:95lrm/RM-3-10|3.10]]) the actual subtype of this object is constrained. The constraint is determined by the bounds or discriminants (if any) of its initial value; <span id="I1424"></span>the object is said to be ''constrained by its initial value''. <span id="I1425"></span><span id="I1426"></span>In the case of an aliased object, this initial value may be either explicit or implicit; in the other cases, an explicit initial value is required. When not constrained by its initial value, the actual and nominal subtypes of the object are the same. <span id="I1427"></span><span id="I1428"></span>If its actual subtype is constrained, the object is called a ''constrained object''. <span id="I1429"></span>For an object_declaration without an initialization expression, any initial values for the object or its subcomponents are determined by the ''implicit initial values'' defined for its nominal subtype, as follows: * The implicit initial value for an access subtype is the null value of the access type. * The implicit initial (and only) value for each discriminant of a constrained discriminated subtype is defined by the subtype. * For a (definite) composite subtype, the implicit initial value of each component with a default_expression is obtained by evaluation of this expression and conversion to the component's nominal subtype (which might raise Constraint_Error -- see [[Guide:95lrm/RM-4-6|4.6]], ''[[Guide:95lrm/RM-4-6|Type Conversions]]''), unless the component is a discriminant of a constrained subtype (the previous case), or is in an excluded variant (see [[Guide:95lrm/RM-3-8-1|3.8.1]]). <span id="I1430"></span>For each component that does not have a default_expression, any implicit initial values are those determined by the component's nominal subtype. * For a protected or task subtype, there is an implicit component (an entry queue) corresponding to each entry, with its implicit initial value being an empty queue. <span id="I1431"></span>The elaboration of an object_declaration proceeds in the following sequence of steps: 1. The subtype_indication, array_type_definition, single_task_declaration, or single_protected_declaration is first elaborated. This creates the nominal subtype (and the anonymous type in the latter three cases). 2. If the object_declaration includes an initialization expression, the (explicit) initial value is obtained by evaluating the expression and converting it to the nominal subtype (which might raise Constraint_Error -- see [[Guide:95lrm/RM-4-6|4.6]]). <span id="I1432"></span> 3. The object is created, and, if there is not an initialization expression, any per-object expressions (see [[Guide:95lrm/RM-3-8|3.8]]) are elaborated and any implicit initial values for the object or for its subcomponents are obtained as determined by the nominal subtype. 4. <span id="I1433"></span><span id="I1434"></span>Any initial values (whether explicit or implicit) are assigned to the object or to the corresponding subcomponents. As described in [[Guide:95lrm/RM-5-2|5.2]] and [[Guide:95lrm/RM-7-6|7.6]], Initialize and Adjust procedures can be called. <span id="I1435"></span> For the third step above, the object creation and any elaborations and evaluations are performed in an arbitrary order, except that if the default_expression for a discriminant is evaluated to obtain its initial value, then this evaluation is performed before that of the default_expression for any component that depends on the discriminant, and also before that of any default_expression that includes the name of the discriminant. The evaluations of the third step and the assignments of the fourth step are performed in an arbitrary order, except that each evaluation is performed before the resulting value is assigned. There is no implicit initial value defined for a scalar subtype. <span id="I1436"></span>In the absence of an explicit initialization, a newly created scalar object might have a value that does not belong to its subtype (see [[Guide:95lrm/RM-13-9-1|13.9.1]] and [[Guide:95lrm/RM-H-1|H.1]]). == Notes == 7  Implicit initial values are not defined for an indefinite subtype, because if an object's nominal subtype is indefinite, an explicit initial value is required. 8  <span id="I1437"></span><span id="I1438"></span>As indicated above, a stand-alone object is an object declared by an object_declaration. Similar definitions apply to ''stand-alone constant'' and ''stand-alone variable.'' A subcomponent of an object is not a stand-alone object, nor is an object that is created by an allocator. An object declared by a loop_parameter_specification, parameter_specification, entry_index_specification, choice_parameter_specification, or a formal_object_declaration is not called a stand-alone object. 9  The type of a stand-alone object cannot be abstract (see [[Guide:95lrm/RM-3-9-3|3.9.3]]). == Examples == ''Example of a multiple object declaration:'' <p><syntaxhighlight lang="Ada"> --  the multiple object declaration </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> John, Paul : Person_Name := new Person(Sex => M);  --  see 3.10.1</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> --  is equivalent to the two single object declarations in the order given</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> John : Person_Name := new Person(Sex => M); Paul : Person_Name := new Person(Sex => M);</syntaxhighlight></p> ''Examples of variable declarations:'' <p><syntaxhighlight lang="Ada"> Count, Sum  : Integer; Size        : Integer range 0 .. 10_000 := 0; Sorted      : Boolean := False; Color_Table : array(1 .. Max) of Color; Option      : Bit_Vector(1 .. 10) := (others => True); Hello       : constant String := "Hi, world.";</syntaxhighlight></p> ''Examples of constant declarations:'' <p><syntaxhighlight lang="Ada"> Limit     : constant Integer := 10_000; Low_Limit : constant Integer := Limit/10; Tolerance : constant Real := Dispersion(1.15);</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-3|Previous]] | [[Guide:95lrm/RM-3-3-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 725tqil5kr2eb18pftwptdm17ryyrjy Guide:95lrm/RM-3-3-2 4200 954 3776 3775 2019-05-04T23:36:38Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-3-1|Previous]] | [[Guide:95lrm/RM-3-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.3.2 Number Declarations}} A number_declaration declares a named number. == Syntax == <p><span></span></p> number_declaration<span id="I1439"></span> ::= <span id="I1440"></span>defining_identifier_list : '''constant''' := ''static_''<span id="I1441"></span>expression; == Name Resolution Rules == <span id="I1442"></span>The ''static_''expression given for a number_declaration is expected to be of any numeric type. == Legality Rules == The ''static_''expression given for a number declaration shall be a static expression, as defined by clause [[Guide:95lrm/RM-4-9|4.9]]. == Static Semantics == The named number denotes a value of type ''universal_integer'' if the type of the ''static_''expression is an integer type. The named number denotes a value of type ''universal_real'' if the type of the ''static_''expression is a real type. The value denoted by the named number is the value of the ''static_''expression, converted to the corresponding universal type. <span id="I1443"></span> == Dynamic Semantics == <span id="I1444"></span>The elaboration of a number_declaration has no effect. == Examples == ''Examples of number declarations:'' <p><syntaxhighlight lang="Ada"> Two_Pi        : constant := 2.0*Ada.Numerics.Pi;   -- a real number (see A.5)</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Max           : constant := 500;                   -- an integer number Max_Line_Size : constant := Max/6                  -- the integer 83 Power_16      : constant := 2**16;                 -- the integer 65_536 One, Un, Eins : constant := 1;                     -- three different names for 1</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-3-1|Previous]] | [[Guide:95lrm/RM-3-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} r7o4fqnkpg4j5kukdw9zvwzjqzg42kn Guide:95lrm/RM-3-4 4200 955 3778 3777 2019-05-04T23:36:39Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-3-2|Previous]] | [[Guide:95lrm/RM-3-4-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.4 Derived Types and Classes}} <span id="I1445"></span>A derived_type_definition defines a new type (and its first subtype) whose characteristics are ''derived'' from those of a ''parent type''. <span id="I1446"></span> == Syntax == <p><span></span></p> derived_type_definition<span id="I1447"></span> ::= ['''abstract'''] '''new''' ''parent_''<span id="I1448"></span>subtype_indication [<span id="I1449"></span>record_extension_part] == Legality Rules == <span id="I1450"></span><span id="I1451"></span>The ''parent_''subtype_indication defines the ''parent subtype''; its type is the parent type. A type shall be completely defined (see [[Guide:95lrm/RM-3-11-1|3.11.1]]) prior to being specified as the parent type in a derived_type_definition -- the full_type_declarations for the parent type and any of its subcomponents have to precede the derived_type_definition. <span id="I1452"></span>If there is a record_extension_part, the derived type is called a ''record extension'' of the parent type. A record_extension_part shall be provided if and only if the parent type is a tagged type. == Static Semantics == <span id="I1453"></span><span id="I1454"></span>The first subtype of the derived type is unconstrained if a known_discriminant_part is provided in the declaration of the derived type, or if the parent subtype is unconstrained. <span id="I1455"></span>Otherwise, the constraint of the first subtype ''corresponds'' to that of the parent subtype in the following sense: it is the same as that of the parent subtype except that for a range constraint (implicit or explicit), the value of each bound of its range is replaced by the corresponding value of the derived type. The characteristics of the derived type are defined as follows: <p><span></span></p> :* Each class of types that includes the parent type also includes the derived type. <p><span></span></p> :* If the parent type is an elementary type or an array type, then the set of possible values of the derived type is a copy of the set of possible values of the parent type. For a scalar type, the base range of the derived type is the same as that of the parent type. <p><span></span></p> :* If the parent type is a composite type other than an array type, then the components, protected subprograms, and entries that are declared for the derived type are as follows: <p><span></span></p> ::* The discriminants specified by a new known_discriminant_part, if there is one; otherwise, each discriminant of the parent type (implicitly declared in the same order with the same specifications) -- <span id="I1456"></span><span id="I1457"></span>in the latter case, the discriminants are said to be ''inherited'', or if unknown in the parent, are also unknown in the derived type; <p><span></span></p> ::* Each nondiscriminant component, entry, and protected subprogram of the parent type, implicitly declared in the same order with the same declarations; <span id="I1458"></span><span id="I1459"></span><span id="I1460"></span>these components, entries, and protected subprograms are said to be ''inherited''; <p><span></span></p> ::* Each component declared in a record_extension_part, if any. <p><span></span></p> ::Declarations of components, protected subprograms, and entries, whether implicit or explicit, occur immediately within the declarative region of the type, in the order indicated above, following the parent subtype_indication. <p><span></span></p> :* The derived type is limited if and only if the parent type is limited. <p><span></span></p> :* For each predefined operator of the parent type, there is a corresponding predefined operator of the derived type. <p><span></span></p> :* <span id="I1461"></span>For each user-defined primitive subprogram (other than a user-defined equality operator -- see below) of the parent type that already exists at the place of the derived_type_definition, there exists a corresponding ''inherited'' primitive subprogram of the derived type with the same defining name. <span id="I1462"></span>Primitive user-defined equality operators of the parent type are also inherited by the derived type, except when the derived type is a nonlimited record extension, and the inherited operator would have a profile that is type conformant with the profile of the corresponding predefined equality operator; in this case, the user-defined equality operator is not inherited, but is rather incorporated into the implementation of the predefined equality operator of the record extension (see [[Guide:95lrm/RM-4-5-2|4.5.2]]). <span id="I1463"></span> <p><span></span></p> ::The profile of an inherited subprogram (including an inherited enumeration literal) is obtained from the profile of the corresponding (user-defined) primitive subprogram of the parent type, after systematic replacement of each subtype of its profile (see [[Guide:95lrm/RM-6-1|6.1]]) that is of the parent type with a ''corresponding subtype'' of the derived type. <span id="I1464"></span>For a given subtype of the parent type, the corresponding subtype of the derived type is defined as follows: <p><span></span></p> ::* If the declaration of the derived type has neither a known_discriminant_part nor a record_extension_part, then the corresponding subtype has a constraint that corresponds (as defined above for the first subtype of the derived type) to that of the given subtype. <p><span></span></p> ::* If the derived type is a record extension, then the corresponding subtype is the first subtype of the derived type. <p><span></span></p> ::* If the derived type has a new known_discriminant_part but is not a record extension, then the corresponding subtype is constrained to those values that when converted to the parent type belong to the given subtype (see [[Guide:95lrm/RM-4-6|4.6]]). <span id="I1465"></span> <p><span></span></p> ::The same formal parameters have default_expressions in the profile of the inherited subprogram. Any type mismatch due to the systematic replacement of the parent type by the derived type is handled as part of the normal type conversion associated with parameter passing -- see [[Guide:95lrm/RM-6-4-1|6.4.1]]. If a primitive subprogram of the parent type is visible at the place of the derived_type_definition, then the corresponding inherited subprogram is implicitly declared immediately after the derived_type_definition. Otherwise, the inherited subprogram is implicitly declared later or not at all, as explained in [[Guide:95lrm/RM-7-3-1|7.3.1]]. <span id="I1466"></span>A derived type can also be defined by a private_extension_declaration (see [[Guide:95lrm/RM-7-3|7.3]]) or a formal_derived_type_definition (see [[Guide:95lrm/RM-12-5-1|12.5.1]]). Such a derived type is a partial view of the corresponding full or actual type. All numeric types are derived types, in that they are implicitly derived from a corresponding root numeric type (see [[Guide:95lrm/RM-3-5-4|3.5.4]] and [[Guide:95lrm/RM-3-5-6|3.5.6]]). == Dynamic Semantics == <span id="I1467"></span>The elaboration of a derived_type_definition creates the derived type and its first subtype, and consists of the elaboration of the subtype_indication and the record_extension_part, if any. If the subtype_indication depends on a discriminant, then only those expressions that do not depend on a discriminant are evaluated. <span id="I1468"></span>For the execution of a call on an inherited subprogram, a call on the corresponding primitive subprogram of the parent type is performed; the normal conversion of each actual parameter to the subtype of the corresponding formal parameter (see [[Guide:95lrm/RM-6-4-1|6.4.1]]) performs any necessary type conversion as well. If the result type of the inherited subprogram is the derived type, the result of calling the parent's subprogram is converted to the derived type. <span id="I1469"></span> == Notes == 10  <span id="I1470"></span>Classes are closed under derivation -- any class that contains a type also contains its derivatives. Operations available for a given class of types are available for the derived types in that class. 11  Evaluating an inherited enumeration literal is equivalent to evaluating the corresponding enumeration literal of the parent type, and then converting the result to the derived type. This follows from their equivalence to parameterless functions. <span id="I1471"></span> 12  A generic subprogram is not a subprogram, and hence cannot be a primitive subprogram and cannot be inherited by a derived type. On the other hand, an instance of a generic subprogram can be a primitive subprogram, and hence can be inherited. 13  If the parent type is an access type, then the parent and the derived type share the same storage pool; there is a '''null''' access value for the derived type and it is the implicit initial value for the type. See [[Guide:95lrm/RM-3-10|3.10]]. 14  If the parent type is a boolean type, the predefined relational operators of the derived type deliver a result of the predefined type Boolean (see [[Guide:95lrm/RM-4-5-2|4.5.2]]). If the parent type is an integer type, the right operand of the predefined exponentiation operator is of the predefined type Integer (see [[Guide:95lrm/RM-4-5-6|4.5.6]]). 15  Any discriminants of the parent type are either all inherited, or completely replaced with a new set of discriminants. 16  For an inherited subprogram, the subtype of a formal parameter of the derived type need not have any value in common with the first subtype of the derived type. 17  If the reserved word '''abstract''' is given in the declaration of a type, the type is abstract (see [[Guide:95lrm/RM-3-9-3|3.9.3]]). == Examples == ''Examples of derived type declarations:'' <p><syntaxhighlight lang="Ada"> type Local_Coordinate is new Coordinate;   --  two different types type Midweek is new Day range Tue .. Thu;  --  see 3.5.1 type Counter is new Positive;              --  same range as Positive</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Special_Key is new Key_Manager.Key;   --  see 7.3.1   -- the inherited subprograms have the following specifications:  --         procedure Get_Key(K : out Special_Key); --         function "<"(X,Y : Special_Key) return Boolean;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-3-2|Previous]] | [[Guide:95lrm/RM-3-4-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 4kxjwb55hnwzxjbamw3nrw56phgoiq2 Guide:95lrm/RM-3-4-1 4200 956 3780 3779 2019-05-04T23:36:39Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-4|Previous]] | [[Guide:95lrm/RM-3-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.4.1 Derivation Classes}} In addition to the various language-defined classes of types, types can be grouped into ''derivation classes''. == Static Semantics == <span id="I1472"></span>A derived type is ''derived from'' its parent type ''directly''; it is derived ''indirectly'' from any type from which its parent type is derived. <span id="I1473"></span><span id="I1474"></span><span id="I1475"></span>The derivation class of types for a type ''T'' (also called the class ''rooted'' at ''T'') is the set consisting of ''T'' (the ''root type'' of the class) and all types derived from ''T'' (directly or indirectly) plus any associated universal or class-wide types (defined below). Every type is either a ''specific'' type, a ''class-wide'' type, or a ''universal'' type. <span id="I1476"></span>A specific type is one defined by a type_declaration, a formal_type_declaration, or a full type definition embedded in a declaration for an object. Class-wide and universal types are implicitly defined, to act as representatives for an entire class of types, as follows: ; <span id="I1477"></span>Class-wide types : Class-wide types are defined for (and belong to) each derivation class rooted at a tagged type (see [[Guide:95lrm/RM-3-9|3.9]]). Given a subtype S of a tagged type ''T'', S'Class is the subtype_mark for a corresponding subtype of the tagged class-wide type ''T'''Class. Such types are called ''class-wide'' because when a formal parameter is defined to be of a class-wide type ''T'''Class, an actual parameter of any type in the derivation class rooted at ''T'' is acceptable (see [[Guide:95lrm/RM-8-6|8.6]]). <p><span></span></p> :<span id="I1478"></span>The set of values for a class-wide type ''T'''Class is the discriminated union of the set of values of each specific type in the derivation class rooted at ''T'' (the tag acts as the implicit discriminant -- see [[Guide:95lrm/RM-3-9|3.9]]). Class-wide types have no primitive subprograms of their own. However, as explained in [[Guide:95lrm/RM-3-9-2|3.9.2]], operands of a class-wide type ''T'''Class can be used as part of a dispatching call on a primitive subprogram of the type ''T''. The only components (including discriminants) of ''T'''Class that are visible are those of ''T''. If S is a first subtype, then S'Class is a first subtype. ; <span id="I1479"></span>Universal types : Universal types are defined for (and belong to) the integer, real, and fixed point classes, and are referred to in this standard as respectively, ''universal_integer'', ''universal_real'', and ''universal_fixed''. These are analogous to class-wide types for these language-defined numeric classes. As with class-wide types, if a formal parameter is of a universal type, then an actual parameter of any type in the corresponding class is acceptable. In addition, a value of a universal type (including an integer or real numeric_literal) is ''universal'' in that it is acceptable where some particular type in the class is expected (see [[Guide:95lrm/RM-8-6|8.6]]). <p><span></span></p> :The set of values of a universal type is the undiscriminated union of the set of values possible for any definable type in the associated class. Like class-wide types, universal types have no primitive subprograms of their own. However, their ''universality'' allows them to be used as operands with the primitive subprograms of any type in the corresponding class. <span id="I1480"></span><span id="I1481"></span>The integer and real numeric classes each have a specific root type in addition to their universal type, named respectively ''root_integer'' and ''root_real''. <span id="I1482"></span>A class-wide or universal type is said to ''cover'' all of the types in its class. A specific type covers only itself. <span id="I1483"></span>A specific type ''T2'' is defined to be a ''descendant'' of a type ''T1'' if ''T2'' is the same as ''T1'', or if ''T2'' is derived (directly or indirectly) from ''T1''. A class-wide type ''T2'''Class is defined to be a descendant of type ''T1'' if ''T2'' is a descendant of ''T1''. Similarly, the universal types are defined to be descendants of the root types of their classes. <span id="I1484"></span>If a type ''T2'' is a descendant of a type ''T1'', then ''T1'' is called an ''ancestor'' of ''T2''. <span id="I1485"></span><span id="I1486"></span>The ''ultimate ancestor'' of a type is the ancestor of the type that is not a descendant of any other type. <span id="I1487"></span>An inherited component (including an inherited discriminant) of a derived type is inherited ''from'' a given ancestor of the type if the corresponding component was inherited by each derived type in the chain of derivations going back to the given ancestor. == Notes == 18  Because operands of a universal type are acceptable to the predefined operators of any type in their class, ambiguity can result. For ''universal_integer'' and ''universal_real'', this potential ambiguity is resolved by giving a preference (see [[Guide:95lrm/RM-8-6|8.6]]) to the predefined operators of the corresponding root types (''root_integer'' and ''root_real'', respectively). Hence, in an apparently ambiguous expression like <p><span></span></p> 1 + 4 < 7 where each of the literals is of type ''universal_integer'', the predefined operators of ''root_integer'' will be preferred over those of other specific integer types, thereby resolving the ambiguity. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-4|Previous]] | [[Guide:95lrm/RM-3-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} g495jl2kbmtw6dj8t6tlqjvfuev9jhq Guide:95lrm/RM-3-5 4200 957 3782 3781 2019-05-04T23:36:42Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-4-1|Previous]] | [[Guide:95lrm/RM-3-5-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.5 Scalar Types}} <span id="I1488"></span>''Scalar'' types comprise enumeration types, integer types, and real types. <span id="I1489"></span>Enumeration types and integer types are called ''discrete'' types; <span id="I1490"></span>each value of a discrete type has a ''position number'' which is an integer value. <span id="I1491"></span>Integer types and real types are called ''numeric'' types. All scalar types are ordered, that is, all relational operators are predefined for their values. == Syntax == <p><span></span></p> range_constraint<span id="I1492"></span> ::=  '''range''' <span id="I1493"></span>range <p><span></span></p> range<span id="I1494"></span> ::=  <span id="I1495"></span>range_attribute_reference | <span id="I1496"></span>simple_expression .. <span id="I1497"></span>simple_expression <span id="I1498"></span><span id="I1499"></span><span id="I1500"></span><span id="I1501"></span>A ''range'' has a ''lower bound'' and an ''upper bound'' and specifies a subset of the values of some scalar type (the ''type of the range''). A range with lower bound L and upper bound R is described by ''L .. R''. <span id="I1502"></span>If R is less than L, then the range is a ''null range'', and specifies an empty set of values. Otherwise, the range specifies the values of the type from the lower bound to the upper bound, inclusive. <span id="I1503"></span>A value ''belongs'' to a range if it is of the type of the range, and is in the subset of values specified by the range. <span id="I1504"></span>A value ''satisfies'' a range constraint if it belongs to the associated range. <span id="I1505"></span>One range is ''included'' in another if all values that belong to the first range also belong to the second. == Name Resolution Rules == <span id="I1506"></span>For a subtype_indication containing a range_constraint, either directly or as part of some other scalar_constraint, the type of the range shall resolve to that of the type determined by the subtype_mark of the subtype_indication. <span id="I1507"></span>For a range of a given type, the simple_expressions of the range (likewise, the simple_expressions of the equivalent range for a range_attribute_reference) are expected to be of the type of the range. == Static Semantics == <span id="I1508"></span>The ''base range'' of a scalar type is the range of finite values of the type that can be represented in every unconstrained object of the type; it is also the range supported at a minimum for intermediate values during the evaluation of expressions involving predefined operators of the type. <span id="I1509"></span><span id="I1510"></span>A constrained scalar subtype is one to which a range constraint applies. <span id="I1511"></span>The ''range'' of a constrained scalar subtype is the range associated with the range constraint of the subtype. The ''range'' of an unconstrained scalar subtype is the base range of its type. == Dynamic Semantics == <span id="I1512"></span>A range is ''compatible'' with a scalar subtype if and only if it is either a null range or each bound of the range belongs to the range of the subtype. <span id="I1513"></span>A range_constraint is ''compatible'' with a scalar subtype if and only if its range is compatible with the subtype. <span id="I1514"></span>The elaboration of a range_constraint consists of the evaluation of the range. <span id="I1515"></span>The evaluation of a range determines a lower bound and an upper bound. If simple_expressions are given to specify bounds, the evaluation of the range evaluates these simple_expressions in an arbitrary order, and converts them to the type of the range. <span id="I1516"></span>If a range_attribute_reference is given, the evaluation of the range consists of the evaluation of the range_attribute_reference. ''Attributes'' For every scalar subtype S, the following attributes are defined: ;  S'First : <span id="I1517"></span><span id="I1518"></span>S'First denotes the lower bound of the range of S. The value of this attribute is of the type of S. ;  S'Last : <span id="I1519"></span><span id="I1520"></span>S'Last denotes the upper bound of the range of S. The value of this attribute is of the type of S. ;  S'Range : <span id="I1521"></span><span id="I1522"></span>S'Range is equivalent to the range S'First .. S'Last. ;  S'Base : <span id="I1523"></span><span id="I1524"></span>S'Base denotes an unconstrained subtype of the type of S. This unconstrained subtype is called the ''base subtype'' of the type. <span id="I1525"></span> ;  S'Min : <span id="I1526"></span><span id="I1527"></span>S'Min denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Min(Left, Right : S'Base)   return S'Base</syntaxhighlight></p> The function returns the lesser of the values of the two parameters. ;  S'Max : <span id="I1528"></span><span id="I1529"></span>S'Max denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Max(Left, Right : S'Base) return S'Base</syntaxhighlight></p> The function returns the greater of the values of the two parameters. ;  S'Succ : <span id="I1530"></span><span id="I1531"></span>S'Succ denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Succ(Arg : S'Base)   return S'Base</syntaxhighlight></p> <span id="I1532"></span>For an enumeration type, the function returns the value whose position number is one more than that of the value of ''Arg''; <span id="I1533"></span><span id="I1534"></span>Constraint_Error is raised if there is no such value of the type. For an integer type, the function returns the result of adding one to the value of ''Arg''. For a fixed point type, the function returns the result of adding ''small'' to the value of ''Arg''. For a floating point type, the function returns the machine number (as defined in [[Guide:95lrm/RM-3-5-7|3.5.7]]) immediately above the value of ''Arg''; <span id="I1535"></span><span id="I1536"></span>Constraint_Error is raised if there is no such machine number. ;  S'Pred : <span id="I1537"></span><span id="I1538"></span>S'Pred denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Pred(Arg : S'Base)   return S'Base</syntaxhighlight></p> <span id="I1539"></span>For an enumeration type, the function returns the value whose position number is one less than that of the value of ''Arg''; <span id="I1540"></span><span id="I1541"></span>Constraint_Error is raised if there is no such value of the type. For an integer type, the function returns the result of subtracting one from the value of ''Arg''. For a fixed point type, the function returns the result of subtracting ''small'' from the value of ''Arg''. For a floating point type, the function returns the machine number (as defined in [[Guide:95lrm/RM-3-5-7|3.5.7]]) immediately below the value of ''Arg''; <span id="I1542"></span><span id="I1543"></span>Constraint_Error is raised if there is no such machine number. ;  S'Wide_Image : <span id="I1544"></span><span id="I1545"></span>S'Wide_Image denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Wide_Image(Arg : S'Base)   return Wide_String</syntaxhighlight></p> <span id="I1546"></span>The function returns an ''image'' of the value of ''Arg'', that is, a sequence of characters representing the value in display form. The lower bound of the result is one. The image of an integer value is the corresponding decimal literal, without underlines, leading zeros, exponent, or trailing spaces, but with a single leading character that is either a minus sign or a space. <span id="I1547"></span>The image of an enumeration value is either the corresponding identifier in upper case or the corresponding character literal (including the two apostrophes); neither leading nor trailing spaces are included. For a ''nongraphic character'' (a value of a character type that has no enumeration literal associated with it), the result is a corresponding language-defined or implementation-defined name in upper case (for example, the image of the nongraphic character identified as ''nul'' is ''NUL'' -- the quotes are not part of the image). The image of a floating point value is a decimal real literal best approximating the value (rounded away from zero if halfway between) with a single leading character that is either a minus sign or a space, a single digit (that is nonzero unless the value is zero), a decimal point, S'Digits-1 (see [[Guide:95lrm/RM-3-5-8|3.5.8]]) digits after the decimal point (but one if S'Digits is one), an upper case E, the sign of the exponent (either + or -), and two or more digits (with leading zeros if necessary) representing the exponent. If S'Signed_Zeros is True, then the leading character is a minus sign for a negatively signed zero. The image of a fixed point value is a decimal real literal best approximating the value (rounded away from zero if halfway between) with a single leading character that is either a minus sign or a space, one or more digits before the decimal point (with no redundant leading zeros), a decimal point, and S'Aft (see [[Guide:95lrm/RM-3-5-10|3.5.10]]) digits after the decimal point. ;  S'Image : <span id="I1548"></span><span id="I1549"></span>S'Image denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Image(Arg : S'Base)   return String</syntaxhighlight></p> The function returns an image of the value of ''Arg'' as a String. The lower bound of the result is one. The image has the same sequence of graphic characters as that defined for S'Wide_Image if all the graphic characters are defined in Character; otherwise the sequence of characters is implementation defined (but no shorter than that of S'Wide_Image for the same value of ''Arg''). ;  S'Wide_Width : <span id="I1550"></span><span id="I1551"></span>S'Wide_Width denotes the maximum length of a Wide_String returned by S'Wide_Image over all values of the subtype S. It denotes zero for a subtype that has a null range. Its type is ''universal_integer''. ;  S'Width : <span id="I1552"></span><span id="I1553"></span>S'Width denotes the maximum length of a String returned by S'Image over all values of the subtype S. It denotes zero for a subtype that has a null range. Its type is ''universal_integer''. ;  S'Wide_Value : <span id="I1554"></span><span id="I1555"></span>S'Wide_Value denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Wide_Value(Arg : Wide_String)   return S'Base</syntaxhighlight></p> This function returns a value given an image of the value as a Wide_String, ignoring any leading or trailing spaces. <span id="I1556"></span><span id="I1557"></span>For the evaluation of a call on S'Wide_Value for an enumeration subtype S, if the sequence of characters of the parameter (ignoring leading and trailing spaces) has the syntax of an enumeration literal and if it corresponds to a literal of the type of S (or corresponds to the result of S'Wide_Image for a nongraphic character of the type), the result is the corresponding enumeration value; <span id="I1558"></span><span id="I1559"></span>otherwise Constraint_Error is raised. <span id="I1560"></span>For the evaluation of a call on S'Wide_Value (or S'Value) for an integer subtype S, if the sequence of characters of the parameter (ignoring leading and trailing spaces) has the syntax of an integer literal, with an optional leading sign character (plus or minus for a signed type; only plus for a modular type), and the corresponding numeric value belongs to the base range of the type of S, then that value is the result; <span id="I1561"></span><span id="I1562"></span>otherwise Constraint_Error is raised. For the evaluation of a call on S'Wide_Value (or S'Value) for a real subtype S, if the sequence of characters of the parameter (ignoring leading and trailing spaces) has the syntax of one of the following: * numeric_literal * numeral.[exponent] * .numeral[exponent] * base#based_numeral.#[exponent] * base#.based_numeral#[exponent] <span id="I1563"></span>with an optional leading sign character (plus or minus), and if the corresponding numeric value belongs to the base range of the type of S, then that value is the result; <span id="I1564"></span><span id="I1565"></span>otherwise Constraint_Error is raised. The sign of a zero value is preserved (positive if none has been specified) if S'Signed_Zeros is True. ;  S'Value : <span id="I1566"></span><span id="I1567"></span>S'Value denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Value(Arg : String)   return S'Base</syntaxhighlight></p> This function returns a value given an image of the value as a String, ignoring any leading or trailing spaces. <span id="I1568"></span><span id="I1569"></span>For the evaluation of a call on S'Value for an enumeration subtype S, if the sequence of characters of the parameter (ignoring leading and trailing spaces) has the syntax of an enumeration literal and if it corresponds to a literal of the type of S (or corresponds to the result of S'Image for a value of the type), the result is the corresponding enumeration value; <span id="I1570"></span><span id="I1571"></span>otherwise Constraint_Error is raised. For a numeric subtype S, the evaluation of a call on S'Value with ''Arg'' of type String is equivalent to a call on S'Wide_Value for a corresponding ''Arg'' of type Wide_String. == Implementation Permissions == An implementation may extend the Wide_Value, Value, Wide_Image, and Image attributes of a floating point type to support special values such as infinities and NaNs. == Notes == 19  The evaluation of S'First or S'Last never raises an exception. If a scalar subtype S has a nonnull range, S'First and S'Last belong to this range. These values can, for example, always be assigned to a variable of subtype S. 20  For a subtype of a scalar type, the result delivered by the attributes Succ, Pred, and Value might not belong to the subtype; similarly, the actual parameters of the attributes Succ, Pred, and Image need not belong to the subtype. 21  For any value V (including any nongraphic character) of an enumeration subtype S, S'Value(S'Image(V)) equals V, as does S'Wide_Value(S'Wide_Image(V)). Neither expression ever raises Constraint_Error. == Examples == ''Examples of ranges:'' <p><syntaxhighlight lang="Ada"> -10 .. 10 X .. X + 1 0.0 .. 2.0*Pi Red .. Green     -- see 3.5.1 1 .. 0           -- a null range Table'Range      -- a range attribute reference (see 3.6)</syntaxhighlight></p> ''Examples of range constraints:'' <p><syntaxhighlight lang="Ada"> range -999.0 .. +999.0 range S'First+1 .. S'Last-1</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-4-1|Previous]] | [[Guide:95lrm/RM-3-5-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} bwbv4ksx236i8ia4pvx0t9udy1y6o5x Guide:95lrm/RM-3-5-1 4200 958 3784 3783 2019-05-04T23:36:44Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-5|Previous]] | [[Guide:95lrm/RM-3-5-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.5.1 Enumeration Types}} <span id="I1572"></span>An enumeration_type_definition defines an enumeration type. == Syntax == <p><span></span></p> enumeration_type_definition<span id="I1573"></span> ::= (<span id="I1574"></span>enumeration_literal_specification {, <span id="I1575"></span>enumeration_literal_specification}) <p><span></span></p> enumeration_literal_specification<span id="I1576"></span> ::=  <span id="I1577"></span>defining_identifier | <span id="I1578"></span>defining_character_literal <p><span></span></p> defining_character_literal<span id="I1579"></span> ::= <span id="I1580"></span>character_literal == Legality Rules == The defining_identifiers and defining_character_literals listed in an enumeration_type_definition shall be distinct. == Static Semantics == <span id="I1581"></span>Each enumeration_literal_specification is the explicit declaration of the corresponding ''enumeration literal'': it declares a parameterless function, whose defining name is the defining_identifier or defining_character_literal, and whose result type is the enumeration type. Each enumeration literal corresponds to a distinct value of the enumeration type, and to a distinct position number. <span id="I1582"></span>The position number of the value of the first listed enumeration literal is zero; the position number of the value of each subsequent enumeration literal is one more than that of its predecessor in the list. The predefined order relations between values of the enumeration type follow the order of corresponding position numbers. <span id="I1583"></span>If the same defining_identifier or defining_character_literal is specified in more than one enumeration_type_definition, the corresponding enumeration literals are said to be ''overloaded''. At any place where an overloaded enumeration literal occurs in the text of a program, the type of the enumeration literal has to be determinable from the context (see [[Guide:95lrm/RM-8-6|8.6]]). == Dynamic Semantics == <span id="I1584"></span><span id="I1585"></span><span id="I1586"></span>The elaboration of an enumeration_type_definition creates the enumeration type and its first subtype, which is constrained to the base range of the type. When called, the parameterless function associated with an enumeration literal returns the corresponding value of the enumeration type. == Notes == 22  If an enumeration literal occurs in a context that does not otherwise suffice to determine the type of the literal, then qualification by the name of the enumeration type is one way to resolve the ambiguity (see [[Guide:95lrm/RM-4-7|4.7]]). == Examples == ''Examples of enumeration types and subtypes:'' <p><syntaxhighlight lang="Ada"> type Day    is (Mon, Tue, Wed, Thu, Fri, Sat, Sun); type Suit   is (Clubs, Diamonds, Hearts, Spades); type Gender is (M, F); type Level  is (Low, Medium, Urgent); type Color  is (White, Red, Yellow, Green, Blue, Brown, Black); type Light  is (Red, Amber, Green); -- Red and Green are overloaded</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Hexa   is ('A', 'B', 'C', 'D', 'E', 'F'); type Mixed  is ('A', 'B', '*', B, None, '?', '%');</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> subtype Weekday is Day   range Mon .. Fri; subtype Major   is Suit  range Hearts .. Spades; subtype Rainbow is Color range Red .. Blue;  --  the Color Red, not the Light </syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-5|Previous]] | [[Guide:95lrm/RM-3-5-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} etrcd2styq2egshyerbn1jinphebxz0 Guide:95lrm/RM-3-5-10 4200 959 3786 3785 2019-05-04T23:36:45Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-5-9|Previous]] | [[Guide:95lrm/RM-3-6|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.5.10 Operations of Fixed Point Types}} == Static Semantics == The following attributes are defined for every fixed point subtype S: ;   S'Small : <span id="I1742"></span><span id="I1743"></span>S'Small denotes the ''small'' of the type of S. The value of this attribute is of the type ''universal_real''. <span id="I1744"></span><span id="I1745"></span>Small may be specified for nonderived ordinary fixed point types via an attribute_definition_clause (see [[Guide:95lrm/RM-13-3|13.3]]); the expression of such a clause shall be static. ; S'Delta : <span id="I1746"></span><span id="I1747"></span>S'Delta denotes the ''delta'' of the fixed point subtype S. The value of this attribute is of the type ''universal_real''. ; S'Fore : <span id="I1748"></span><span id="I1749"></span>S'Fore yields the minimum number of characters needed before the decimal point for the decimal representation of any value of the subtype S, assuming that the representation does not include an exponent, but includes a one-character prefix that is either a minus sign or a space. (This minimum number does not include superfluous zeros or underlines, and is at least 2.) The value of this attribute is of the type ''universal_integer''. ; S'Aft : <span id="I1750"></span><span id="I1751"></span>S'Aft yields the number of decimal digits needed after the decimal point to accommodate the ''delta'' of the subtype S, unless the ''delta'' of the subtype S is greater than 0.1, in which case the attribute yields the value one. (S'Aft is the smallest positive integer N for which (10**N)*S'Delta is greater than or equal to one.) The value of this attribute is of the type ''universal_integer''. The following additional attributes are defined for every decimal fixed point subtype S: ; S'Digits : <span id="I1752"></span><span id="I1753"></span>S'Digits denotes the ''digits'' of the decimal fixed point subtype S, which corresponds to the number of decimal digits that are representable in objects of the subtype. The value of this attribute is of the type ''universal_integer''. Its value is determined as follows: <span id="I1754"></span> <p><span></span></p> :* For a first subtype or a subtype defined by a subtype_indication with a digits_constraint, the digits is the value of the expression given after the reserved word '''digits'''; <p><span></span></p> :* For a subtype defined by a subtype_indication without a digits_constraint, the digits of the subtype is the same as that of the subtype denoted by the subtype_mark in the subtype_indication. <p><span></span></p> :* The digits of a base subtype is the largest integer ''D'' such that the range -(10**''D''-1)*''delta'' .. +(10**''D''-1)*''delta'' is included in the base range of the type. ;  S'Scale : <span id="I1755"></span><span id="I1756"></span>S'Scale denotes the ''scale'' of the subtype S, defined as the value N such that S'Delta = 10.0**(-N). <span id="I1757"></span>The scale indicates the position of the point relative to the rightmost significant digits of values of subtype S. The value of this attribute is of the type ''universal_integer''. ;  S'Round : <span id="I1758"></span><span id="I1759"></span>S'Round denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Round(X : universal_real)   return S'Base</syntaxhighlight></p> The function returns the value obtained by rounding X (away from 0, if X is midway between two values of the type of S). == Notes == 37  All subtypes of a fixed point type will have the same value for the Delta attribute, in the absence of delta_constraints (see [[Guide:95lrm/RM-J-3|J.3]]). 38  S'Scale is not always the same as S'Aft for a decimal subtype; for example, if S'Delta = 1.0 then S'Aft is 1 while S'Scale is 0. 39  <span id="I1760"></span>The predefined operations of a fixed point type include the assignment operation, qualification, the membership tests, and explicit conversion to and from other numeric types. They also include the relational operators and the following predefined arithmetic operators: the binary and unary adding operators - and +, multiplying operators, and the unary operator '''abs'''. 40  As for all types, objects of a fixed point type have Size and Address attributes (see [[Guide:95lrm/RM-13-3|13.3]]). Other attributes of fixed point types are defined in [[Guide:95lrm/RM-A-5-4|A.5.4]]. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-5-9|Previous]] | [[Guide:95lrm/RM-3-6|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} c80ciyqzwcby5ycyh5sp015d22slzl1 Guide:95lrm/RM-3-5-2 4200 960 3788 3787 2019-05-04T23:36:46Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-5-1|Previous]] | [[Guide:95lrm/RM-3-5-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.5.2 Character Types}} == Static Semantics == <span id="I1587"></span>An enumeration type is said to be a ''character type'' if at least one of its enumeration literals is a character_literal. <span id="I1588"></span><span id="I1589"></span><span id="I1590"></span><span id="I1591"></span>The predefined type Character is a character type whose values correspond to the 256 code positions of Row 00 (also known as Latin-1) of the ISO 10646 Basic Multilingual Plane (BMP). Each of the graphic characters of Row 00 of the BMP has a corresponding character_literal in Character. Each of the nongraphic positions of Row 00 (0000-001F and 007F-009F) has a corresponding language-defined name, which is not usable as an enumeration literal, but which is usable with the attributes (Wide_)Image and (Wide_)Value; these names are given in the definition of type Character in [[Guide:95lrm/RM-A-1|A.1]], ''[[Guide:95lrm/RM-A-1|The Package Standard]]'', but are set in ''italics''. <span id="I1592"></span> <span id="I1593"></span><span id="I1594"></span><span id="I1595"></span>The predefined type Wide_Character is a character type whose values correspond to the 65536 code positions of the ISO 10646 Basic Multilingual Plane (BMP). Each of the graphic characters of the BMP has a corresponding character_literal in Wide_Character. The first 256 values of Wide_Character have the same character_literal or language-defined name as defined for Character. The last 2 values of Wide_Character correspond to the nongraphic positions FFFE and FFFF of the BMP, and are assigned the language-defined names ''FFFE'' and ''FFFF''. As with the other language-defined names for nongraphic characters, the names ''FFFE'' and ''FFFF'' are usable only with the attributes (Wide_)Image and (Wide_)Value; they are not usable as enumeration literals. All other values of Wide_Character are considered graphic characters, and have a corresponding character_literal. == Implementation Permissions == <span id="I1596"></span>In a nonstandard mode, an implementation may provide other interpretations for the predefined types Character and Wide_Character, to conform to local conventions. == Implementation Advice == <span id="I1597"></span>If an implementation supports a mode with alternative interpretations for Character and Wide_Character, the set of graphic characters of Character should nevertheless remain a proper subset of the set of graphic characters of Wide_Character. Any character set ''localizations'' should be reflected in the results of the subprograms defined in the language-defined package Characters.Handling (see [[Guide:95lrm/RM-A-3|A.3]]) available in such a mode. In a mode with an alternative interpretation of Character, the implementation should also support a corresponding change in what is a legal identifier_letter. == Notes == 23  The language-defined library package Characters.Latin_1 (see [[Guide:95lrm/RM-A-3-3|A.3.3]]) includes the declaration of constants denoting control characters, lower case characters, and special characters of the predefined type Character. 24  A conventional character set such as ''EBCDIC'' can be declared as a character type; the internal codes of the characters can be specified by an enumeration_representation_clause as explained in clause [[Guide:95lrm/RM-13-4|13.4]]. == Examples == ''Example of a character type:'' <p><syntaxhighlight lang="Ada">type Roman_Digit is ('I', 'V', 'X', 'L', 'C', 'D', 'M');</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-5-1|Previous]] | [[Guide:95lrm/RM-3-5-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 0rfvkkme4f8hoamwc4s6cddeh6xpjc7 Guide:95lrm/RM-3-5-3 4200 961 3790 3789 2019-05-04T23:36:46Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-5-2|Previous]] | [[Guide:95lrm/RM-3-5-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.5.3 Boolean Types}} == Static Semantics == <span id="I1598"></span>There is a predefined enumeration type named Boolean, declared in the visible part of package Standard. <span id="I1599"></span><span id="I1600"></span>It has the two enumeration literals False and True ordered with the relation False < True. <span id="I1601"></span>Any descendant of the predefined type Boolean is called a ''boolean'' type. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-5-2|Previous]] | [[Guide:95lrm/RM-3-5-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} rapnpm6wusdnhjpjumqcutnlwvau077 Guide:95lrm/RM-3-5-4 4200 962 3792 3791 2019-05-04T23:36:47Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-5-3|Previous]] | [[Guide:95lrm/RM-3-5-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.5.4 Integer Types}} <span id="I1602"></span><span id="I1603"></span><span id="I1604"></span>An integer_type_definition defines an integer type; it defines either a ''signed'' integer type, or a ''modular'' integer type. The base range of a signed integer type includes at least the values of the specified range. A modular type is an integer type with all arithmetic modulo a specified positive ''modulus''; such a type corresponds to an unsigned type with wrap-around semantics. <span id="I1605"></span> == Syntax == <p><span></span></p> integer_type_definition<span id="I1606"></span> ::= <span id="I1607"></span>signed_integer_type_definition | <span id="I1608"></span>modular_type_definition <p><span></span></p> signed_integer_type_definition<span id="I1609"></span> ::= '''range''' ''static_''<span id="I1610"></span>simple_expression .. ''static_''<span id="I1611"></span>simple_expression <p><span></span></p> modular_type_definition<span id="I1612"></span> ::= '''mod''' ''static_''<span id="I1613"></span>expression == Name Resolution Rules == <span id="I1614"></span>Each simple_expression in a signed_integer_type_definition is expected to be of any integer type; they need not be of the same type. <span id="I1615"></span>The expression in a modular_type_definition is likewise expected to be of any integer type. == Legality Rules == The simple_expressions of a signed_integer_type_definition shall be static, and their values shall be in the range System.Min_Int .. System.Max_Int. <span id="I1616"></span><span id="I1617"></span><span id="I1618"></span>The expression of a modular_type_definition shall be static, and its value (the ''modulus'') shall be positive, and shall be no greater than System.Max_Binary_Modulus if a power of 2, or no greater than System.Max_Nonbinary_Modulus if not. == Static Semantics == The set of values for a signed integer type is the (infinite) set of mathematical integers, though only values of the base range of the type are fully supported for run-time operations. The set of values for a modular integer type are the values from 0 to one less than the modulus, inclusive. <span id="I1619"></span>A signed_integer_type_definition defines an integer type whose base range includes at least the values of the simple_expressions and is symmetric about zero, excepting possibly an extra negative value. <span id="I1620"></span><span id="I1621"></span>A signed_integer_type_definition also defines a constrained first subtype of the type, with a range whose bounds are given by the values of the simple_expressions, converted to the type being defined. <span id="I1622"></span>A modular_type_definition defines a modular type whose base range is from zero to one less than the given modulus. <span id="I1623"></span><span id="I1624"></span>A modular_type_definition also defines a constrained first subtype of the type with a range that is the same as the base range of the type. <span id="I1625"></span>There is a predefined signed integer subtype named Integer, declared in the visible part of package Standard. It is constrained to the base range of its type. <span id="I1626"></span><span id="I1627"></span>Integer has two predefined subtypes, declared in the visible part of package Standard: <p><syntaxhighlight lang="Ada"> subtype Natural  is Integer range 0 .. Integer'Last; subtype Positive is Integer range 1 .. Integer'Last;</syntaxhighlight></p> <span id="I1628"></span><span id="I1629"></span><span id="I1630"></span>A type defined by an integer_type_definition is implicitly derived from ''root_integer'', an anonymous predefined (specific) integer type, whose base range is System.Min_Int .. System.Max_Int. However, the base range of the new type is not inherited from ''root_integer'', but is instead determined by the range or modulus specified by the integer_type_definition. <span id="I1631"></span><span id="I1632"></span>Integer literals are all of the type ''universal_integer'', the universal type (see [[Guide:95lrm/RM-3-4-1|3.4.1]]) for the class rooted at ''root_integer'', allowing their use with the operations of any integer type. <span id="I1633"></span>The ''position number'' of an integer value is equal to the value. For every modular subtype S, the following attribute is defined: ;  S'Modulus : <span id="I1634"></span><span id="I1635"></span>S'Modulus yields the modulus of the type of S, as a value of the type ''universal_integer''. == Dynamic Semantics == <span id="I1636"></span>The elaboration of an integer_type_definition creates the integer type and its first subtype. For a modular type, if the result of the execution of a predefined operator (see [[Guide:95lrm/RM-4-5|4.5]]) is outside the base range of the type, the result is reduced modulo the modulus of the type to a value that is within the base range of the type. <span id="I1637"></span><span id="I1638"></span><span id="I1639"></span>For a signed integer type, the exception Constraint_Error is raised by the execution of an operation that cannot deliver the correct result because it is outside the base range of the type. <span id="I1640"></span><span id="I1641"></span><span id="I1642"></span>For any integer type, Constraint_Error is raised by the operators "/", "'''rem'''", and "'''mod'''" if the right operand is zero. == Implementation Requirements == <span id="I1643"></span>In an implementation, the range of Integer shall include the range -2**15+1 .. +2**15-1. <span id="I1644"></span>If Long_Integer is predefined for an implementation, then its range shall include the range -2**31+1 .. +2**31-1. System.Max_Binary_Modulus shall be at least 2**16. == Implementation Permissions == For the execution of a predefined operation of a signed integer type, the implementation need not raise Constraint_Error if the result is outside the base range of the type, so long as the correct result is produced. <span id="I1645"></span><span id="I1646"></span>An implementation may provide additional predefined signed integer types, declared in the visible part of Standard, whose first subtypes have names of the form Short_Integer, Long_Integer, Short_Short_Integer, Long_Long_Integer, etc. Different predefined integer types are allowed to have the same base range. However, the range of Integer should be no wider than that of Long_Integer. Similarly, the range of Short_Integer (if provided) should be no wider than Integer. Corresponding recommendations apply to any other predefined integer types. There need not be a named integer type corresponding to each distinct base range supported by an implementation. The range of each first subtype should be the base range of its type. <span id="I1647"></span>An implementation may provide ''nonstandard integer types'', descendants of ''root_integer'' that are declared outside of the specification of package Standard, which need not have all the standard characteristics of a type defined by an integer_type_definition. For example, a nonstandard integer type might have an asymmetric base range or it might not be allowed as an array or loop index (a very long integer). Any type descended from a nonstandard integer type is also nonstandard. An implementation may place arbitrary restrictions on the use of such types; it is implementation defined whether operators that are predefined for ''any integer type'' are defined for a particular nonstandard integer type. In any case, such types are not permitted as explicit_generic_actual_parameters for formal scalar types -- see [[Guide:95lrm/RM-12-5-2|12.5.2]]. <span id="I1648"></span>For a one's complement machine, the high bound of the base range of a modular type whose modulus is one less than a power of 2 may be equal to the modulus, rather than one less than the modulus. It is implementation defined for which powers of 2, if any, this permission is exercised. <div>For a one's complement machine, implementations may support non-binary modulus values greater than System.Max_Nonbinary_Modulus. It is implementation defined which specific values greater than System.Max_Nonbinary_Modulus, if any, are supported.</div> == Implementation Advice == <span id="I1649"></span>An implementation should support Long_Integer in addition to Integer if the target machine supports 32-bit (or longer) arithmetic. No other named integer subtypes are recommended for package Standard. Instead, appropriate named integer subtypes should be provided in the library package Interfaces (see [[Guide:95lrm/RM-B-2|B.2]]). <span id="I1650"></span>An implementation for a two's complement machine should support modular types with a binary modulus up to System.Max_Int*2+2. An implementation should support a nonbinary modulus up to Integer'Last. == Notes == 25  <span id="I1651"></span><span id="I1652"></span>Integer literals are of the anonymous predefined integer type ''universal_integer''. Other integer types have no literals. However, the overload resolution rules (see [[Guide:95lrm/RM-8-6|8.6]], ''[[Guide:95lrm/RM-8-6|The Context of Overload Resolution]]'') allow expressions of the type ''universal_integer'' whenever an integer type is expected. 26  The same arithmetic operators are predefined for all signed integer types defined by a signed_integer_type_definition (see [[Guide:95lrm/RM-4-5|4.5]], ''[[Guide:95lrm/RM-4-5|Operators and Expression Evaluation]]''). For modular types, these same operators are predefined, plus bit-wise logical operators ('''and''', '''or''', '''xor''', and '''not'''). In addition, for the unsigned types declared in the language-defined package Interfaces (see [[Guide:95lrm/RM-B-2|B.2]]), functions are defined that provide bit-wise shifting and rotating. 27  Modular types match a generic_formal_parameter_declaration of the form "'''type''' T '''is mod''' <>;"; signed integer types match "'''type''' T '''is range''' <>;" (see [[Guide:95lrm/RM-12-5-2|12.5.2]]). == Examples == ''Examples of integer types and subtypes:'' <p><syntaxhighlight lang="Ada"> type Page_Num  is range 1 .. 2_000; type Line_Size is range 1 .. Max_Line_Size;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> subtype Small_Int   is Integer   range -10 .. 10; subtype Column_Ptr  is Line_Size range 1 .. 10; subtype Buffer_Size is Integer   range 0 .. Max;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Byte        is mod 256; -- an unsigned byte type Hash_Index  is mod 97;  -- modulus is prime</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-5-3|Previous]] | [[Guide:95lrm/RM-3-5-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} r00kvoaz82z3bmgme2lp9q8oo8ujhev Guide:95lrm/RM-3-5-5 4200 963 3794 3793 2019-05-04T23:36:49Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-5-4|Previous]] | [[Guide:95lrm/RM-3-5-6|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.5.5 Operations of Discrete Types}} == Static Semantics == For every discrete subtype S, the following attributes are defined: ; S'Pos : <span id="I1653"></span><span id="I1654"></span>S'Pos denotes a function with the following specification: <p><syntaxhighlight lang="Ada">function S'Pos(Arg : S'Base)   return universal_integer</syntaxhighlight></p> This function returns the position number of the value of ''Arg'', as a value of type ''universal_integer''. ; S'Val : <span id="I1655"></span><span id="I1656"></span>S'Val denotes a function with the following specification: <p><syntaxhighlight lang="Ada">function S'Val(Arg : universal_integer)   return S'Base</syntaxhighlight></p> <span id="I1657"></span><span id="I1658"></span>This function returns a value of the type of S whose position number equals the value of ''Arg''. <span id="I1659"></span><span id="I1660"></span>For the evaluation of a call on S'Val, if there is no value in the base range of its type with the given position number, Constraint_Error is raised. == Implementation Advice == For the evaluation of a call on S'Pos for an enumeration subtype, if the value of the operand does not correspond to the internal code for any enumeration literal of its type (perhaps due to an uninitialized variable), then the implementation should raise Program_Error. <span id="I1661"></span>This is particularly important for enumeration types with noncontiguous internal codes specified by an enumeration_representation_clause. == Notes == 28  Indexing and loop iteration use values of discrete types. 29  <span id="I1662"></span>The predefined operations of a discrete type include the assignment operation, qualification, the membership tests, and the relational operators; for a boolean type they include the short-circuit control forms and the logical operators; for an integer type they include type conversion to and from other numeric types, as well as the binary and unary adding operators - and +, the multiplying operators, the unary operator '''abs''', and the exponentiation operator. The assignment operation is described in [[Guide:95lrm/RM-5-2|5.2]]. The other predefined operations are described in Section 4. 30  As for all types, objects of a discrete type have Size and Address attributes (see [[Guide:95lrm/RM-13-3|13.3]]). 31  For a subtype of a discrete type, the result delivered by the attribute Val might not belong to the subtype; similarly, the actual parameter of the attribute Pos need not belong to the subtype. The following relations are satisfied (in the absence of an exception) by these attributes: <p><syntaxhighlight lang="Ada">   S'Val(S'Pos(X)) = X S'Pos(S'Val(N)) = N</syntaxhighlight></p> == Examples == ''Examples of attributes of discrete subtypes:'' <p><syntaxhighlight lang="Ada"> --  For the types and subtypes declared in subclause 3.5.1 the following hold: </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> --  Color'First   = White,   Color'Last   = Black --  Rainbow'First = Red,     Rainbow'Last = Blue</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> --  Color'Succ(Blue) = Rainbow'Succ(Blue) = Brown --  Color'Pos(Blue)  = Rainbow'Pos(Blue)  = 4 --  Color'Val(0)     = Rainbow'Val(0)     = White</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-5-4|Previous]] | [[Guide:95lrm/RM-3-5-6|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} e5di84ysr6g6wt57r9zt35jg3lssfve Guide:95lrm/RM-3-5-6 4200 964 3796 3795 2019-05-04T23:36:50Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-5-5|Previous]] | [[Guide:95lrm/RM-3-5-7|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.5.6 Real Types}} <span id="I1663"></span>Real types provide approximations to the real numbers, with relative bounds on errors for floating point types, and with absolute bounds for fixed point types. == Syntax == <p><span></span></p> real_type_definition<span id="I1664"></span> ::= <span id="I1665"></span>floating_point_definition | <span id="I1666"></span>fixed_point_definition == Static Semantics == <span id="I1667"></span>A type defined by a real_type_definition is implicitly derived from ''root_real'', an anonymous predefined (specific) real type. Hence, all real types, whether floating point or fixed point, are in the derivation class rooted at ''root_real''. <span id="I1668"></span><span id="I1669"></span>Real literals are all of the type ''universal_real'', the universal type (see [[Guide:95lrm/RM-3-4-1|3.4.1]]) for the class rooted at ''root_real'', allowing their use with the operations of any real type. <span id="I1670"></span>Certain multiplying operators have a result type of ''universal_fixed'' (see [[Guide:95lrm/RM-4-5-5|4.5.5]]), the universal type for the class of fixed point types, allowing the result of the multiplication or division to be used where any specific fixed point type is expected. == Dynamic Semantics == <span id="I1671"></span>The elaboration of a real_type_definition consists of the elaboration of the floating_point_definition or the fixed_point_definition. == Implementation Requirements == An implementation shall perform the run-time evaluation of a use of a predefined operator of ''root_real'' with an accuracy at least as great as that of any floating point type definable by a floating_point_definition. == Implementation Permissions == For the execution of a predefined operation of a real type, the implementation need not raise Constraint_Error if the result is outside the base range of the type, so long as the correct result is produced, or the Machine_Overflows attribute of the type is false (see [[Guide:95lrm/RM-G-2|G.2]]). <span id="I1672"></span>An implementation may provide ''nonstandard real types'', descendants of ''root_real'' that are declared outside of the specification of package Standard, which need not have all the standard characteristics of a type defined by a real_type_definition. For example, a nonstandard real type might have an asymmetric or unsigned base range, or its predefined operations might wrap around or ''saturate'' rather than overflow (modular or saturating arithmetic), or it might not conform to the accuracy model (see [[Guide:95lrm/RM-G-2|G.2]]). Any type descended from a nonstandard real type is also nonstandard. An implementation may place arbitrary restrictions on the use of such types; it is implementation defined whether operators that are predefined for ''any real type'' are defined for a particular nonstandard real type. In any case, such types are not permitted as explicit_generic_actual_parameters for formal scalar types -- see [[Guide:95lrm/RM-12-5-2|12.5.2]]. == Notes == 32  As stated, real literals are of the anonymous predefined real type ''universal_real''. Other real types have no literals. However, the overload resolution rules (see [[Guide:95lrm/RM-8-6|8.6]]) allow expressions of the type ''universal_real'' whenever a real type is expected. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-5-5|Previous]] | [[Guide:95lrm/RM-3-5-7|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 48wgftf19oxzymk8coc24qomt2wwh3r Guide:95lrm/RM-3-5-7 4200 965 3798 3797 2019-05-04T23:36:51Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-5-6|Previous]] | [[Guide:95lrm/RM-3-5-8|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.5.7 Floating Point Types}} <span id="I1673"></span>For floating point types, the error bound is specified as a relative precision by giving the required minimum number of significant decimal digits. == Syntax == <p><span></span></p> floating_point_definition<span id="I1674"></span> ::= '''digits''' ''static_''<span id="I1675"></span>expression [<span id="I1676"></span>real_range_specification] <p><span></span></p> real_range_specification<span id="I1677"></span> ::= '''range''' ''static_''<span id="I1678"></span>simple_expression .. ''static_''<span id="I1679"></span>simple_expression == Name Resolution Rules == <span id="I1680"></span>The ''requested decimal precision'', which is the minimum number of significant decimal digits required for the floating point type, is specified by the value of the expression given after the reserved word '''digits'''. <span id="I1681"></span>This expression is expected to be of any integer type. <span id="I1682"></span>Each simple_expression of a real_range_specification is expected to be of any real type; the types need not be the same. == Legality Rules == <span id="I1683"></span>The requested decimal precision shall be specified by a static expression whose value is positive and no greater than System.Max_Base_Digits. Each simple_expression of a real_range_specification shall also be static. <span id="I1684"></span>If the real_range_specification is omitted, the requested decimal precision shall be no greater than System.Max_Digits. A floating_point_definition is illegal if the implementation does not support a floating point type that satisfies the requested decimal precision and range. == Static Semantics == The set of values for a floating point type is the (infinite) set of rational numbers. <span id="I1685"></span>The ''machine numbers'' of a floating point type are the values of the type that can be represented exactly in every unconstrained variable of the type. <span id="I1686"></span>The base range (see [[Guide:95lrm/RM-3-5|3.5]]) of a floating point type is symmetric around zero, except that it can include some extra negative values in some implementations. <span id="I1687"></span>The ''base decimal precision'' of a floating point type is the number of decimal digits of precision representable in objects of the type. <span id="I1688"></span>The ''safe range'' of a floating point type is that part of its base range for which the accuracy corresponding to the base decimal precision is preserved by all predefined operations. <span id="I1689"></span>A floating_point_definition defines a floating point type whose base decimal precision is no less than the requested decimal precision. <span id="I1690"></span><span id="I1691"></span>If a real_range_specification is given, the safe range of the floating point type (and hence, also its base range) includes at least the values of the simple expressions given in the real_range_specification. If a real_range_specification is not given, the safe (and base) range of the type includes at least the values of the range -10.0**(4*D) .. +10.0**(4*D) where D is the requested decimal precision. The safe range might include other values as well. The attributes Safe_First and Safe_Last give the actual bounds of the safe range. A floating_point_definition also defines a first subtype of the type. <span id="I1692"></span><span id="I1693"></span>If a real_range_specification is given, then the subtype is constrained to a range whose bounds are given by a conversion of the values of the simple_expressions of the real_range_specification to the type being defined. Otherwise, the subtype is unconstrained. <span id="I1694"></span>There is a predefined, unconstrained, floating point subtype named Float, declared in the visible part of package Standard. == Dynamic Semantics == <span id="I1695"></span>The elaboration of a floating_point_definition creates the floating point type and its first subtype. == Implementation Requirements == <span id="I1696"></span>In an implementation that supports floating point types with 6 or more digits of precision, the requested decimal precision for Float shall be at least 6. <span id="I1697"></span>If Long_Float is predefined for an implementation, then its requested decimal precision shall be at least 11. == Implementation Permissions == <span id="I1698"></span><span id="I1699"></span>An implementation is allowed to provide additional predefined floating point types, declared in the visible part of Standard, whose (unconstrained) first subtypes have names of the form Short_Float, Long_Float, Short_Short_Float, Long_Long_Float, etc. Different predefined floating point types are allowed to have the same base decimal precision. However, the precision of Float should be no greater than that of Long_Float. Similarly, the precision of Short_Float (if provided) should be no greater than Float. Corresponding recommendations apply to any other predefined floating point types. There need not be a named floating point type corresponding to each distinct base decimal precision supported by an implementation. == Implementation Advice == <span id="I1700"></span>An implementation should support Long_Float in addition to Float if the target machine supports 11 or more digits of precision. No other named floating point subtypes are recommended for package Standard. Instead, appropriate named floating point subtypes should be provided in the library package Interfaces (see [[Guide:95lrm/RM-B-2|B.2]]). == Notes == 33  If a floating point subtype is unconstrained, then assignments to variables of the subtype involve only Overflow_Checks, never Range_Checks. == Examples == ''Examples of floating point types and subtypes:'' <p><syntaxhighlight lang="Ada"> type Coefficient is digits 10 range -1.0 .. 1.0;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Real is digits 8; type Mass is digits 7 range 0.0 .. 1.0E35;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> subtype Probability is Real range 0.0 .. 1.0;   --   a subtype with a smaller range</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-5-6|Previous]] | [[Guide:95lrm/RM-3-5-8|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} f83ij8j5xhrkzjpv0qhw6lxlpdpa7gj Guide:95lrm/RM-3-5-8 4200 966 3800 3799 2019-05-04T23:36:52Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-5-7|Previous]] | [[Guide:95lrm/RM-3-5-9|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.5.8 Operations of Floating Point Types}} == Static Semantics == The following attribute is defined for every floating point subtype S: ;   S'Digits : <span id="I1701"></span><span id="I1702"></span>S'Digits denotes the requested decimal precision for the subtype S. The value of this attribute is of the type ''universal_integer''. The requested decimal precision of the base subtype of a floating point type ''T'' is defined to be the largest value of ''d'' for which <code>ceiling(''d'' * log(10) / log(T'Machine_Radix)) + ''g'' <= T'Model_Mantissa</code> where g is 0 if Machine_Radix is a positive power of 10 and 1 otherwise. == Notes == 34  <span id="I1703"></span>The predefined operations of a floating point type include the assignment operation, qualification, the membership tests, and explicit conversion to and from other numeric types. They also include the relational operators and the following predefined arithmetic operators: the binary and unary adding operators - and +, certain multiplying operators, the unary operator '''abs''', and the exponentiation operator. 35  As for all types, objects of a floating point type have Size and Address attributes (see [[Guide:95lrm/RM-13-3|13.3]]). Other attributes of floating point types are defined in [[Guide:95lrm/RM-A-5-3|A.5.3]]. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-5-7|Previous]] | [[Guide:95lrm/RM-3-5-9|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} sam8s1x14gd6z8wsi48o2oboyea25m5 Guide:95lrm/RM-3-5-9 4200 967 3802 3801 2019-05-04T23:36:53Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-5-8|Previous]] | [[Guide:95lrm/RM-3-5-10|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.5.9 Fixed Point Types}} <span id="I1704"></span><span id="I1705"></span><span id="I1706"></span>A fixed point type is either an ordinary fixed point type, or a decimal fixed point type. <span id="I1707"></span>The error bound of a fixed point type is specified as an absolute value, called the ''delta'' of the fixed point type. == Syntax == <p><span></span></p> fixed_point_definition<span id="I1708"></span> ::= <span id="I1709"></span>ordinary_fixed_point_definition | <span id="I1710"></span>decimal_fixed_point_definition <p><span></span></p> ordinary_fixed_point_definition<span id="I1711"></span> ::= '''delta''' ''static_''<span id="I1712"></span>expression  <span id="I1713"></span>real_range_specification <p><span></span></p> decimal_fixed_point_definition<span id="I1714"></span> ::= '''delta''' ''static_''<span id="I1715"></span>expression '''digits''' ''static_''<span id="I1716"></span>expression [<span id="I1717"></span>real_range_specification] <p><span></span></p> digits_constraint<span id="I1718"></span> ::= '''digits''' ''static_''<span id="I1719"></span>expression [<span id="I1720"></span>range_constraint] == Name Resolution Rules == <span id="I1721"></span>For a type defined by a fixed_point_definition, the ''delta'' of the type is specified by the value of the expression given after the reserved word '''delta'''; this expression is expected to be of any real type. <span id="I1722"></span><span id="I1723"></span><span id="I1724"></span>For a type defined by a decimal_fixed_point_definition (a ''decimal'' fixed point type), the number of significant decimal digits for its first subtype (the ''digits'' of the first subtype) is specified by the expression given after the reserved word '''digits'''; this expression is expected to be of any integer type. == Legality Rules == In a fixed_point_definition or digits_constraint, the expressions given after the reserved words '''delta''' and '''digits''' shall be static; their values shall be positive. <span id="I1725"></span>The set of values of a fixed point type comprise the integral multiples of a number called the ''small'' of the type. <span id="I1726"></span>For a type defined by an ordinary_fixed_point_definition (an ''ordinary'' fixed point type), the ''small'' may be specified by an attribute_definition_clause (see [[Guide:95lrm/RM-13-3|13.3]]); if so specified, it shall be no greater than the ''delta'' of the type. If not specified, the ''small'' of an ordinary fixed point type is an implementation-defined power of two less than or equal to the ''delta''. For a decimal fixed point type, the ''small'' equals the ''delta''; the ''delta'' shall be a power of 10. If a real_range_specification is given, both bounds of the range shall be in the range -(10**''digits''-1)*''delta'' .. +(10**''digits''-1)*''delta''. A fixed_point_definition is illegal if the implementation does not support a fixed point type with the given ''small'' and specified range or ''digits''. For a subtype_indication with a digits_constraint, the subtype_mark shall denote a decimal fixed point subtype. == Static Semantics == <span id="I1727"></span>The base range (see [[Guide:95lrm/RM-3-5|3.5]]) of a fixed point type is symmetric around zero, except possibly for an extra negative value in some implementations. <span id="I1728"></span>An ordinary_fixed_point_definition defines an ordinary fixed point type whose base range includes at least all multiples of ''small'' that are between the bounds specified in the real_range_specification. The base range of the type does not necessarily include the specified bounds themselves. <span id="I1729"></span><span id="I1730"></span>An ordinary_fixed_point_definition also defines a constrained first subtype of the type, with each bound of its range given by the closer to zero of: * the value of the conversion to the fixed point type of the corresponding expression of the real_range_specification; <span id="I1731"></span> * the corresponding bound of the base range. <span id="I1732"></span>A decimal_fixed_point_definition defines a decimal fixed point type whose base range includes at least the range -(10**''digits''-1)*''delta'' .. +(10**''digits''-1)*''delta''. <span id="I1733"></span><span id="I1734"></span>A decimal_fixed_point_definition also defines a constrained first subtype of the type. If a real_range_specification is given, the bounds of the first subtype are given by a conversion of the values of the expressions of the real_range_specification. <span id="I1735"></span>Otherwise, the range of the first subtype is -(10**''digits''-1)*''delta'' .. +(10**''digits''-1)*''delta''. == Dynamic Semantics == <span id="I1736"></span>The elaboration of a fixed_point_definition creates the fixed point type and its first subtype. For a digits_constraint on a decimal fixed point subtype with a given ''delta'', if it does not have a range_constraint, then it specifies an implicit range -(10**''D''-1)*''delta'' .. +(10**''D''-1)*''delta'', where ''D'' is the value of the expression. <span id="I1737"></span>A digits_constraint is ''compatible'' with a decimal fixed point subtype if the value of the expression is no greater than the ''digits'' of the subtype, and if it specifies (explicitly or implicitly) a range that is compatible with the subtype. <span id="I1738"></span>The elaboration of a digits_constraint consists of the elaboration of the range_constraint, if any. <span id="I1739"></span><span id="I1740"></span>If a range_constraint is given, a check is made that the bounds of the range are both in the range -(10**''D''-1)*''delta'' .. +(10**''D''-1)*''delta'', where ''D'' is the value of the (static) expression given after the reserved word '''digits'''. <span id="I1741"></span>If this check fails, Constraint_Error is raised. == Implementation Requirements == The implementation shall support at least 24 bits of precision (including the sign bit) for fixed point types. == Implementation Permissions == Implementations are permitted to support only ''small''s that are a power of two. In particular, all decimal fixed point type declarations can be disallowed. Note however that conformance with the Information Systems Annex requires support for decimal ''small''s, and decimal fixed point type declarations with ''digits'' up to at least 18. == Notes == 36  The base range of an ordinary fixed point type need not include the specified bounds themselves so that the range specification can be given in a natural way, such as: <p><syntaxhighlight lang="Ada"> type Fraction is delta 2.0**(-15) range -1.0 .. 1.0;   </syntaxhighlight></p> With 2's complement hardware, such a type could have a signed 16-bit representation, using 1 bit for the sign and 15 bits for fraction, resulting in a base range of -1.0 .. 1.0-2.0**(-15). == Examples == ''Examples of fixed point types and subtypes:'' <p><syntaxhighlight lang="Ada"> type Volt is delta 0.125 range 0.0 .. 255.0;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   --  A pure fraction which requires all the available   --  space in a word can be declared as the type Fraction: type Fraction is delta System.Fine_Delta range -1.0 .. 1.0;   --  Fraction'Last = 1.0 - System.Fine_Delta</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Money is delta 0.01 digits 15;  -- decimal fixed point subtype Salary is Money digits 10;   -- Money'Last = 10.0**13 - 0.01, Salary'Last = 10.0**8 - 0.01</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-5-8|Previous]] | [[Guide:95lrm/RM-3-5-10|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 8w49plezj7h93h0aywpbg296blxohzf Guide:95lrm/RM-3-6 4200 968 3804 3803 2019-05-04T23:36:55Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-5-10|Previous]] | [[Guide:95lrm/RM-3-6-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.6 Array Types}} <span id="I1761"></span><span id="I1762"></span>An ''array'' object is a composite object consisting of components which all have the same subtype. The name for a component of an array uses one or more index values belonging to specified discrete types. The value of an array object is a composite value consisting of the values of the components. == Syntax == <p><span></span></p> array_type_definition<span id="I1763"></span> ::= <span id="I1764"></span>unconstrained_array_definition | <span id="I1765"></span>constrained_array_definition <p><span></span></p> unconstrained_array_definition<span id="I1766"></span> ::= '''array'''(<span id="I1767"></span>index_subtype_definition {, <span id="I1768"></span>index_subtype_definition}) '''of''' <span id="I1769"></span>component_definition <p><span></span></p> index_subtype_definition<span id="I1770"></span> ::= <span id="I1771"></span>subtype_mark '''range''' <> <p><span></span></p> constrained_array_definition<span id="I1772"></span> ::= '''array''' (<span id="I1773"></span>discrete_subtype_definition {, <span id="I1774"></span>discrete_subtype_definition}) '''of''' <span id="I1775"></span>component_definition <p><span></span></p> discrete_subtype_definition<span id="I1776"></span> ::= ''discrete_''<span id="I1777"></span>subtype_indication | <span id="I1778"></span>range <p><span></span></p> component_definition<span id="I1779"></span> ::= ['''aliased'''] <span id="I1780"></span>subtype_indication == Name Resolution Rules == <span id="I1781"></span>For a discrete_subtype_definition that is a range, the range shall resolve to be of some specific discrete type; which discrete type shall be determined without using any context other than the bounds of the range itself (plus the preference for ''root_integer'' -- see [[Guide:95lrm/RM-8-6|8.6]]). == Legality Rules == <span id="I1782"></span>Each index_subtype_definition or discrete_subtype_definition in an array_type_definition defines an ''index subtype''; <span id="I1783"></span>its type (the ''index type'') shall be discrete. <span id="I1784"></span>The subtype defined by the subtype_indication of a component_definition (the ''component subtype'') shall be a definite subtype. Within the definition of a nonlimited composite type (or a limited composite type that later in its immediate scope becomes nonlimited -- see [[Guide:95lrm/RM-7-3-1|7.3.1]] and [[Guide:95lrm/RM-7-5|7.5]]), if a component_definition contains the reserved word '''aliased''' and the type of the component is discriminated, then the nominal subtype of the component shall be constrained. == Static Semantics == <span id="I1785"></span><span id="I1786"></span><span id="I1787"></span>An array is characterized by the number of indices (the ''dimensionality'' of the array), the type and position of each index, the lower and upper bounds for each index, and the subtype of the components. The order of the indices is significant. A one-dimensional array has a distinct component for each possible index value. A multidimensional array has a distinct component for each possible sequence of index values that can be formed by selecting one value for each index position (in the given order). The possible values for a given index are all the values between the lower and upper bounds, inclusive; <span id="I1788"></span>this range of values is called the ''index range''. <span id="I1789"></span>The ''bounds'' of an array are the bounds of its index ranges. <span id="I1790"></span>The ''length'' of a dimension of an array is the number of values of the index range of the dimension (zero for a null range). <span id="I1791"></span>The ''length'' of a one-dimensional array is the length of its only dimension. An array_type_definition defines an array type and its first subtype. For each object of this array type, the number of indices, the type and position of each index, and the subtype of the components are as in the type definition; the values of the lower and upper bounds for each index belong to the corresponding index subtype of its type, except for null arrays (see [[Guide:95lrm/RM-3-6-1|3.6.1]]). <span id="I1792"></span><span id="I1793"></span>An unconstrained_array_definition defines an array type with an unconstrained first subtype. Each index_subtype_definition defines the corresponding index subtype to be the subtype denoted by the subtype_mark. <span id="I1794"></span>The compound delimiter <> (called a ''box'') of an index_subtype_definition stands for an undefined range (different objects of the type need not have the same bounds). <span id="I1795"></span><span id="I1796"></span>A constrained_array_definition defines an array type with a constrained first subtype. Each discrete_subtype_definition defines the corresponding index subtype, as well as the corresponding index range for the constrained first subtype. <span id="I1797"></span>The ''constraint'' of the first subtype consists of the bounds of the index ranges. The discrete subtype defined by a discrete_subtype_definition is either that defined by the subtype_indication, or a subtype determined by the range as follows: * If the type of the range resolves to ''root_integer'', then the discrete_subtype_definition defines a subtype of the predefined type Integer with bounds given by a conversion to Integer of the bounds of the range; <span id="I1798"></span> * Otherwise, the discrete_subtype_definition defines a subtype of the type of the range, with the bounds given by the range. <span id="I1799"></span>The component_definition of an array_type_definition defines the nominal subtype of the components. If the reserved word '''aliased''' appears in the component_definition, then each component of the array is aliased (see [[Guide:95lrm/RM-3-10|3.10]]). == Dynamic Semantics == <span id="I1800"></span>The elaboration of an array_type_definition creates the array type and its first subtype, and consists of the elaboration of any discrete_subtype_definitions and the component_definition. <span id="I1801"></span>The elaboration of a discrete_subtype_definition that does not contain any per-object expressions creates the discrete subtype, and consists of the elaboration of the subtype_indication or the evaluation of the range. The elaboration of a discrete_subtype_definition that contains one or more per-object expressions is defined in [[Guide:95lrm/RM-3-8|3.8]]. <span id="I1802"></span>The elaboration of a component_definition in an array_type_definition consists of the elaboration of the subtype_indication. The elaboration of any discrete_subtype_definitions and the elaboration of the component_definition are performed in an arbitrary order. == Notes == 41  All components of an array have the same subtype. In particular, for an array of components that are one-dimensional arrays, this means that all components have the same bounds and hence the same length. 42  Each elaboration of an array_type_definition creates a distinct array type. A consequence of this is that each object whose object_declaration contains an array_type_definition is of its own unique type. == Examples == ''Examples of type declarations with unconstrained array definitions:'' <p><syntaxhighlight lang="Ada"> type Vector     is array(Integer  range <>) of Real; type Matrix     is array(Integer  range <>, Integer range <>) of Real; type Bit_Vector is array(Integer  range <>) of Boolean; type Roman      is array(Positive range <>) of Roman_Digit; -- see 3.5.2</syntaxhighlight></p> ''Examples of type declarations with constrained array definitions:'' <p><syntaxhighlight lang="Ada"> type Table    is array(1 .. 10) of Integer; type Schedule is array(Day) of Boolean; type Line     is array(1 .. Max_Line_Size) of Character;</syntaxhighlight></p> ''Examples of object declarations with array type definitions:'' <p><syntaxhighlight lang="Ada"> Grid : array(1 .. 80, 1 .. 100) of Boolean; Mix  : array(Color range Red .. Green) of Boolean; Page : array(Positive range <>) of Line :=  --  an array of arrays   (1 | 50  => Line'(1 | Line'Last => '+', others => '-'),  -- see 4.3.3 2 .. 49 => Line'(1 | Line'Last => '|', others => ' '));  -- Page is constrained by its initial value to (1..50)</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-5-10|Previous]] | [[Guide:95lrm/RM-3-6-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} bsn4br3qes459wyijwnn3recnzayiim Guide:95lrm/RM-3-6-1 4200 969 3806 3805 2019-05-04T23:36:57Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-6|Previous]] | [[Guide:95lrm/RM-3-6-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.6.1 Index Constraints and Discrete Ranges}} An index_constraint determines the range of possible values for every index of an array subtype, and thereby the corresponding array bounds. == Syntax == <p><span></span></p> index_constraint<span id="I1803"></span> ::=  (<span id="I1804"></span>discrete_range {, <span id="I1805"></span>discrete_range}) <p><span></span></p> discrete_range<span id="I1806"></span> ::= ''discrete_''<span id="I1807"></span>subtype_indication | <span id="I1808"></span>range == Name Resolution Rules == <span id="I1809"></span>The type of a discrete_range is the type of the subtype defined by the subtype_indication, or the type of the range. <span id="I1810"></span>For an index_constraint, each discrete_range shall resolve to be of the type of the corresponding index. == Legality Rules == An index_constraint shall appear only in a subtype_indication whose subtype_mark denotes either an unconstrained array subtype, or an unconstrained access subtype whose designated subtype is an unconstrained array subtype; in either case, the index_constraint shall provide a discrete_range for each index of the array type. == Static Semantics == <span id="I1811"></span>A discrete_range defines a range whose bounds are given by the range, or by the range of the subtype defined by the subtype_indication. == Dynamic Semantics == <span id="I1812"></span>An index_constraint is ''compatible'' with an unconstrained array subtype if and only if the index range defined by each discrete_range is compatible (see [[Guide:95lrm/RM-3-5|3.5]]) with the corresponding index subtype. <span id="I1813"></span>If any of the discrete_ranges defines a null range, any array thus constrained is a ''null array'', having no components. <span id="I1814"></span>An array value ''satisfies'' an index_constraint if at each index position the array value and the index_constraint have the same index bounds. <span id="I1815"></span>The elaboration of an index_constraint consists of the evaluation of the discrete_range(s), in an arbitrary order. <span id="I1816"></span>The evaluation of a discrete_range consists of the elaboration of the subtype_indication or the evaluation of the range. == Notes == 43  The elaboration of a subtype_indication consisting of a subtype_mark followed by an index_constraint checks the compatibility of the index_constraint with the subtype_mark (see [[Guide:95lrm/RM-3-2-2|3.2.2]]). 44  Even if an array value does not satisfy the index constraint of an array subtype, Constraint_Error is not raised on conversion to the array subtype, so long as the length of each dimension of the array value and the array subtype match. See [[Guide:95lrm/RM-4-6|4.6]]. == Examples == ''Examples of array declarations including an index constraint:'' <p><syntaxhighlight lang="Ada"> Board     : Matrix(1 .. 8,  1 .. 8);  --  see 3.6 Rectangle : Matrix(1 .. 20, 1 .. 30); Inverse   : Matrix(1 .. N,  1 .. N);  --  N need not be static </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Filter    : Bit_Vector(0 .. 31);</syntaxhighlight></p> ''Example of array declaration with a constrained array subtype:'' <p><syntaxhighlight lang="Ada"> My_Schedule : Schedule;  --  all arrays of type Schedule have the same bounds</syntaxhighlight></p> ''Example of record type with a component that is an array:'' <p><syntaxhighlight lang="Ada"> type Var_Line(Length : Natural) is record     Image : String(1 .. Length); end record;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Null_Line : Var_Line(0);  --  Null_Line.Image is a null array</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-6|Previous]] | [[Guide:95lrm/RM-3-6-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 7j1bc7sej3b8bhsi6en1c1fwab74qxs Guide:95lrm/RM-3-6-2 4200 970 3808 3807 2019-05-04T23:36:58Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-6-1|Previous]] | [[Guide:95lrm/RM-3-6-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.6.2 Operations of Array Types}} == Legality Rules == The argument N used in the attribute_designators for the N-th dimension of an array shall be a static expression of some integer type. The value of N shall be positive (nonzero) and no greater than the dimensionality of the array. == Static Semantics == The following attributes are defined for a prefix A that is of an array type (after any implicit dereference), or denotes a constrained array subtype: ; A'First : <span id="I1817"></span><span id="I1818"></span>A'First denotes the lower bound of the first index range; its type is the corresponding index type. ; A'First(N) : <span id="I1819"></span><span id="I1820"></span>A'First(N) denotes the lower bound of the N-th index range; its type is the corresponding index type. ; A'Last : <span id="I1821"></span><span id="I1822"></span>A'Last denotes the upper bound of the first index range; its type is the corresponding index type. ; A'Last(N) : <span id="I1823"></span><span id="I1824"></span>A'Last(N) denotes the upper bound of the N-th index range; its type is the corresponding index type. ; A'Range : <span id="I1825"></span><span id="I1826"></span>A'Range is equivalent to the range A'First .. A'Last, except that the prefix A is only evaluated once. ; A'Range(N) : <span id="I1827"></span><span id="I1828"></span>A'Range(N) is equivalent to the range A'First(N) .. A'Last(N), except that the prefix A is only evaluated once. ; A'Length : <span id="I1829"></span><span id="I1830"></span>A'Length denotes the number of values of the first index range (zero for a null range); its type is ''universal_integer''. ;  A'Length(N) : <span id="I1831"></span><span id="I1832"></span>A'Length(N) denotes the number of values of the N-th index range (zero for a null range); its type is ''universal_integer''. == Implementation Advice == An implementation should normally represent multidimensional arrays in row-major order, consistent with the notation used for multidimensional array aggregates (see [[Guide:95lrm/RM-4-3-3|4.3.3]]). However, if a '''pragma''' Convention(Fortran, ...) applies to a multidimensional array type, then column-major order should be used instead (see [[Guide:95lrm/RM-B-5|B.5]], ''[[Guide:95lrm/RM-B-5|Interfacing with Fortran]]''). == Notes == 45  The attribute_references A'First and A'First(1) denote the same value. A similar relation exists for the attribute_references A'Last, A'Range, and A'Length. The following relation is satisfied (except for a null array) by the above attributes if the index type is an integer type: <p><syntaxhighlight lang="Ada">   A'Length(N) = A'Last(N) - A'First(N) + 1</syntaxhighlight></p> 46  An array type is limited if its component type is limited (see [[Guide:95lrm/RM-7-5|7.5]]). 47  <span id="I1833"></span>The predefined operations of an array type include the membership tests, qualification, and explicit conversion. If the array type is not limited, they also include assignment and the predefined equality operators. For a one-dimensional array type, they include the predefined concatenation operators (if nonlimited) and, if the component type is discrete, the predefined relational operators; if the component type is boolean, the predefined logical operators are also included. 48  A component of an array can be named with an indexed_component. A value of an array type can be specified with an array_aggregate, unless the array type is limited. For a one-dimensional array type, a slice of the array can be named; also, string literals are defined if the component type is a character type. == Examples == ''Examples (using arrays declared in the examples of subclause [[Guide:95lrm/RM-3-6-1|3.6.1]]):'' <p><syntaxhighlight lang="Ada"> --  Filter'First      =   0   Filter'Last       =  31   Filter'Length =  32 --  Rectangle'Last(1) =  20   Rectangle'Last(2) =  30</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-6-1|Previous]] | [[Guide:95lrm/RM-3-6-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 6spto1ofprqf56fsi2ganas2ux6spxh Guide:95lrm/RM-3-6-3 4200 971 3810 3809 2019-05-04T23:36:59Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-6-2|Previous]] | [[Guide:95lrm/RM-3-7|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.6.3 String Types}} == Static Semantics == <span id="I1834"></span>A one-dimensional array type whose component type is a character type is called a ''string'' type. There are two predefined string types, String and Wide_String, each indexed by values of the predefined subtype Positive; these are declared in the visible part of package Standard: <p><syntaxhighlight lang="Ada"> subtype Positive is Integer range 1 .. Integer'Last;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type String is array(Positive range <>) of Character; type Wide_String is array(Positive range <>) of Wide_Character;</syntaxhighlight></p> == Notes == 49  String literals (see [[Guide:95lrm/RM-2-6|2.6]] and [[Guide:95lrm/RM-4-2|4.2]]) are defined for all string types. The concatenation operator & is predefined for string types, as for all nonlimited one-dimensional array types. The ordering operators <, <=, >, and >= are predefined for string types, as for all one-dimensional discrete array types; these ordering operators correspond to lexicographic order (see [[Guide:95lrm/RM-4-5-2|4.5.2]]). == Examples == ''Examples of string objects:'' <p><syntaxhighlight lang="Ada"> Stars      : String(1 .. 120) := (1 .. 120 => '*' ); Question   : constant String  := "How many characters?"; -- Question'First = 1, Question'Last = 20    -- Question'Length = 20 (the number of characters)</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Ask_Twice  : String  := Question & Question;       -- constrained to (1..40) Ninety_Six : constant Roman   := "XCVI";  -- see 3.5.2 and 3.6</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-6-2|Previous]] | [[Guide:95lrm/RM-3-7|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} gn8kz6sek4husuv9oscp88xyke6cpsi Guide:95lrm/RM-3-7 4200 972 3812 3811 2019-05-04T23:37:02Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-6-3|Previous]] | [[Guide:95lrm/RM-3-7-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.7 Discriminants}} <span id="I1835"></span><span id="I1836"></span><span id="I1837"></span>A composite type (other than an array type) can have discriminants, which parameterize the type. A known_discriminant_part specifies the discriminants of a composite type. A discriminant of an object is a component of the object, and is either of a discrete type or an access type. An unknown_discriminant_part in the declaration of a partial view of a type specifies that the discriminants of the type are unknown for the given view; all subtypes of such a partial view are indefinite subtypes. == Syntax == <p><span></span></p> discriminant_part<span id="I1838"></span> ::= <span id="I1839"></span>unknown_discriminant_part | <span id="I1840"></span>known_discriminant_part <p><span></span></p> unknown_discriminant_part<span id="I1841"></span> ::= (<>) <p><span></span></p> known_discriminant_part<span id="I1842"></span> ::= (<span id="I1843"></span>discriminant_specification {; <span id="I1844"></span>discriminant_specification}) <p><span></span></p> discriminant_specification<span id="I1845"></span> ::= <span id="I1846"></span>defining_identifier_list : <span id="I1847"></span>subtype_mark [:= <span id="I1848"></span>default_expression] | <span id="I1849"></span>defining_identifier_list : <span id="I1850"></span>access_definition [:= <span id="I1851"></span>default_expression] <p><span></span></p> default_expression<span id="I1852"></span> ::= <span id="I1853"></span>expression == Name Resolution Rules == <span id="I1854"></span>The expected type for the default_expression of a discriminant_specification is that of the corresponding discriminant. == Legality Rules == A discriminant_part is only permitted in a declaration for a composite type that is not an array type (this includes generic formal types). A type declared with a known_discriminant_part is called a ''discriminated'' type,<span id="I1855"></span> as is a type that inherits (known) discriminants. The subtype of a discriminant may be defined by a subtype_mark, in which case the subtype_mark shall denote a discrete or access subtype, or it may be defined by an access_definition (in which case the subtype_mark of the access_definition may denote any kind of subtype). <span id="I1856"></span>A discriminant that is defined by an access_definition is called an ''access discriminant'' and is of an anonymous general access-to-variable type whose designated subtype is denoted by the subtype_mark of the access_definition. A discriminant_specification for an access discriminant shall appear only in the declaration for a task or protected type, or for a type with the reserved word '''limited''' in its (full) definition or in that of one of its ancestors. In addition to the places where Legality Rules normally apply (see [[Guide:95lrm/RM-12-3|12.3]]), this rule applies also in the private part of an instance of a generic unit. Default_expressions shall be provided either for all or for none of the discriminants of a known_discriminant_part. No default_expressions are permitted in a known_discriminant_part in a declaration of a tagged type or a generic formal type. For a type defined by a derived_type_definition, if a known_discriminant_part is provided in its declaration, then: * The parent subtype shall be constrained; * If the parent type is not a tagged type, then each discriminant of the derived type shall be used in the constraint defining the parent subtype; * If a discriminant is used in the constraint defining the parent subtype, the subtype of the discriminant shall be statically compatible (see [[Guide:95lrm/RM-4-9-1|4.9.1]]) with the subtype of the corresponding parent discriminant. The type of the default_expression, if any, for an access discriminant shall be convertible to the anonymous access type of the discriminant (see [[Guide:95lrm/RM-4-6|4.6]]). <span id="I1857"></span> == Static Semantics == A discriminant_specification declares a discriminant; the subtype_mark denotes its subtype unless it is an access discriminant, in which case the discriminant's subtype is the anonymous access-to-variable subtype defined by the access_definition. For a type defined by a derived_type_definition, each discriminant of the parent type is either inherited, constrained to equal some new discriminant of the derived type, or constrained to the value of an expression. <span id="I1858"></span>When inherited or constrained to equal some new discriminant, the parent discriminant and the discriminant of the derived type are said to ''correspond''. Two discriminants also correspond if there is some common discriminant to which they both correspond. A discriminant corresponds to itself as well. <span id="I1859"></span>If a discriminant of a parent type is constrained to a specific value by a derived_type_definition, then that discriminant is said to be ''specified'' by that derived_type_definition. <span id="I1860"></span>A constraint that appears within the definition of a discriminated type ''depends on a discriminant'' of the type if it names the discriminant as a bound or discriminant value. A component_definition depends on a discriminant if its constraint depends on the discriminant, or on a discriminant that corresponds to it. <span id="I1861"></span>A component ''depends on a discriminant'' if: * Its component_definition depends on the discriminant; or * It is declared in a variant_part that is governed by the discriminant; or * It is a component inherited as part of a derived_type_definition, and the constraint of the ''parent_''subtype_indication depends on the discriminant; or * It is a subcomponent of a component that depends on the discriminant. Each value of a discriminated type includes a value for each component of the type that does not depend on a discriminant; this includes the discriminants themselves. The values of discriminants determine which other component values are present in the value of the discriminated type. <span id="I1862"></span><span id="I1863"></span><span id="I1864"></span><span id="I1865"></span>A type declared with a known_discriminant_part is said to have ''known discriminants''; its first subtype is unconstrained. <span id="I1866"></span><span id="I1867"></span>A type declared with an unknown_discriminant_part is said to have ''unknown discriminants''. A type declared without a discriminant_part has no discriminants, unless it is a derived type; if derived, such a type has the same sort of discriminants (known, unknown, or none) as its parent (or ancestor) type. A tagged class-wide type also has unknown discriminants. <span id="I1868"></span><span id="I1869"></span>Any subtype of a type with unknown discriminants is an unconstrained and indefinite subtype (see [[Guide:95lrm/RM-3-2|3.2]] and [[Guide:95lrm/RM-3-3|3.3]]). == Dynamic Semantics == An access_definition is elaborated when the value of a corresponding access discriminant is defined, either by evaluation of its default_expression or by elaboration of a discriminant_constraint. The elaboration of an access_definition creates the anonymous access type. When the expression defining the access discriminant is evaluated, it is converted to this anonymous access type (see [[Guide:95lrm/RM-4-6|4.6]]). <span id="I1870"></span> == Notes == 50  If a discriminated type has default_expressions for its discriminants, then unconstrained variables of the type are permitted, and the values of the discriminants can be changed by an assignment to such a variable. If defaults are not provided for the discriminants, then all variables of the type are constrained, either by explicit constraint or by their initial value; the values of the discriminants of such a variable cannot be changed after initialization. 51  The default_expression for a discriminant of a type is evaluated when an object of an unconstrained subtype of the type is created. 52  Assignment to a discriminant of an object (after its initialization) is not allowed, since the name of a discriminant is a constant; neither assignment_statements nor assignments inherent in passing as an '''in out''' or '''out''' parameter are allowed. Note however that the value of a discriminant can be changed by assigning to the enclosing object, presuming it is an unconstrained variable. 53  A discriminant that is of a named access type is not called an access discriminant; that term is used only for discriminants defined by an access_definition. == Examples == ''Examples of discriminated types:'' <p><syntaxhighlight lang="Ada"> type Buffer(Size : Buffer_Size := 100)  is        -- see 3.5.4 record     Pos   : Buffer_Size := 0;    Value : String(1 .. Size); end record;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Matrix_Rec(Rows, Columns : Integer) is record     Mat : Matrix(1 .. Rows, 1 .. Columns);       -- see 3.6 end record;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Square(Side : Integer) is new Matrix_Rec(Rows => Side, Columns => Side);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Double_Square(Number : Integer) is record    Left  : Square(Number);    Right : Square(Number); end record;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Item(Number : Positive) is record    Content : Integer;    --  no component depends on the discriminant end record;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-6-3|Previous]] | [[Guide:95lrm/RM-3-7-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 4ws0j2mkhjaddptyida8rc1t0uvt6wu Guide:95lrm/RM-3-7-1 4200 973 3814 3813 2019-05-04T23:37:03Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-7|Previous]] | [[Guide:95lrm/RM-3-7-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.7.1 Discriminant Constraints}} A discriminant_constraint specifies the values of the discriminants for a given discriminated type. == Syntax == <p><span></span></p> discriminant_constraint<span id="I1871"></span> ::= (<span id="I1872"></span>discriminant_association {, <span id="I1873"></span>discriminant_association}) <p><span></span></p> discriminant_association<span id="I1874"></span> ::= [''discriminant_''<span id="I1875"></span>selector_name {| ''discriminant_''<span id="I1876"></span>selector_name} =>] <span id="I1877"></span>expression <span id="I1878"></span>A discriminant_association is said to be ''named'' if it has one or more ''discriminant_''selector_names; <span id="I1879"></span>it is otherwise said to be ''positional''. In a discriminant_constraint, any positional associations shall precede any named associations. == Name Resolution Rules == Each selector_name of a named discriminant_association shall resolve to denote a discriminant of the subtype being constrained; <span id="I1880"></span>the discriminants so named are the ''associated discriminants'' of the named association. <span id="I1881"></span>For a positional association, the ''associated discriminant'' is the one whose discriminant_specification occurred in the corresponding position in the known_discriminant_part that defined the discriminants of the subtype being constrained. <span id="I1882"></span>The expected type for the expression in a discriminant_association is that of the associated discriminant(s). == Legality Rules == A discriminant_constraint is only allowed in a subtype_indication whose subtype_mark denotes either an unconstrained discriminated subtype, or an unconstrained access subtype whose designated subtype is an unconstrained discriminated subtype. However, in the case of a general access subtype, a discriminant_constraint is illegal if there is a place within the immediate scope of the designated subtype where the designated subtype's view is constrained. A named discriminant_association with more than one selector_name is allowed only if the named discriminants are all of the same type. A discriminant_constraint shall provide exactly one value for each discriminant of the subtype being constrained. The expression associated with an access discriminant shall be of a type convertible to the anonymous access type. <span id="I1883"></span> == Dynamic Semantics == <span id="I1884"></span>A discriminant_constraint is ''compatible'' with an unconstrained discriminated subtype if each discriminant value belongs to the subtype of the corresponding discriminant. <span id="I1885"></span>A composite value ''satisfies'' a discriminant constraint if and only if each discriminant of the composite value has the value imposed by the discriminant constraint. <span id="I1886"></span>For the elaboration of a discriminant_constraint, the expressions in the discriminant_associations are evaluated in an arbitrary order and converted to the type of the associated discriminant (which might raise Constraint_Error -- see [[Guide:95lrm/RM-4-6|4.6]]); the expression of a named association is evaluated (and converted) once for each associated discriminant. <span id="I1887"></span>The result of each evaluation and conversion is the value imposed by the constraint for the associated discriminant. == Notes == 54  The rules of the language ensure that a discriminant of an object always has a value, either from explicit or implicit initialization. == Examples == ''Examples (using types declared above in clause [[Guide:95lrm/RM-3-7|3.7]]):'' <p><syntaxhighlight lang="Ada"> Large   : Buffer(200);  --  constrained, always 200 characters          --   (explicit discriminant value) Message : Buffer;       --  unconstrained, initially 100 characters                      --   (default discriminant value) Basis   : Square(5);    --  constrained, always 5 by 5 Illegal : Square;       --  illegal, a Square has to be constrained</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-7|Previous]] | [[Guide:95lrm/RM-3-7-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} nfxqwn46lqgbfzadlenweeii4igjv5h Guide:95lrm/RM-3-7-2 4200 974 3816 3815 2019-05-04T23:37:03Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-7-1|Previous]] | [[Guide:95lrm/RM-3-8|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.7.2 Operations of Discriminated Types}} If a discriminated type has default_expressions for its discriminants, then unconstrained variables of the type are permitted, and the discriminants of such a variable can be changed by assignment to the variable. For a formal parameter of such a type, an attribute is provided to determine whether the corresponding actual parameter is constrained or unconstrained. == Static Semantics == For a prefix A that is of a discriminated type (after any implicit dereference), the following attribute is defined: ; A'Constrained : <span id="I1888"></span><span id="I1889"></span>Yields the value True if A denotes a constant, a value, or a constrained variable, and False otherwise. == Erroneous Execution == <span id="I1890"></span>The execution of a construct is erroneous if the construct has a constituent that is a name denoting a subcomponent that depends on discriminants, and the value of any of these discriminants is changed by this execution between evaluating the name and the last use (within this execution) of the subcomponent denoted by the name. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-7-1|Previous]] | [[Guide:95lrm/RM-3-8|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} dadyrfhsgk2r1hpyzght0tqyz4y3d6a Guide:95lrm/RM-3-8 4200 975 3818 3817 2019-05-04T23:37:04Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-7-2|Previous]] | [[Guide:95lrm/RM-3-8-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.8 Record Types}} <span id="I1891"></span><span id="I1892"></span>A record object is a composite object consisting of named components. The value of a record object is a composite value consisting of the values of the components. <span id="I1893"></span> == Syntax == <p><span></span></p> record_type_definition<span id="I1894"></span> ::= [['''abstract'''] '''tagged'''] ['''limited'''] <span id="I1895"></span>record_definition <p><span></span></p> record_definition<span id="I1896"></span> ::= '''record''' <span id="I1897"></span>component_list '''end''' '''record''' | '''null record''' <p><span></span></p> component_list<span id="I1898"></span> ::= <span id="I1899"></span>component_item {<span id="I1900"></span>component_item} | {<span id="I1901"></span>component_item} <span id="I1902"></span>variant_part |  '''null'''; <p><span></span></p> component_item<span id="I1903"></span> ::= <span id="I1904"></span>component_declaration | <span id="I1905"></span>aspect_clause <p><span></span></p> component_declaration<span id="I1906"></span> ::= <span id="I1907"></span>defining_identifier_list : <span id="I1908"></span>component_definition [:= <span id="I1909"></span>default_expression]; == Name Resolution Rules == <span id="I1910"></span>The expected type for the default_expression, if any, in a component_declaration is the type of the component. == Legality Rules == A default_expression is not permitted if the component is of a limited type. <span id="I1911"></span>Each component_declaration declares a ''component'' of the record type. Besides components declared by component_declarations, the components of a record type include any components declared by discriminant_specifications of the record type declaration. The identifiers of all components of a record type shall be distinct. Within a type_declaration, a name that denotes a component, protected subprogram, or entry of the type is allowed only in the following cases: * A name that denotes any component, protected subprogram, or entry is allowed within a representation item that occurs within the declaration of the composite type. * A name that denotes a noninherited discriminant is allowed within the declaration of the type, but not within the discriminant_part. If the discriminant is used to define the constraint of a component, the bounds of an entry family, or the constraint of the parent subtype in a derived_type_definition then its name shall appear alone as a direct_name (not as part of a larger expression or expanded name). A discriminant shall not be used to define the constraint of a scalar component. If the name of the current instance of a type (see [[Guide:95lrm/RM-8-6|8.6]]) is used to define the constraint of a component, then it shall appear as a direct_name that is the prefix of an attribute_reference whose result is of an access type, and the attribute_reference shall appear alone. == Static Semantics == <span id="I1912"></span>The component_definition of a component_declaration defines the (nominal) subtype of the component. If the reserved word '''aliased''' appears in the component_definition, then the component is aliased (see [[Guide:95lrm/RM-3-10|3.10]]). <span id="I1913"></span>If the component_list of a record type is defined by the reserved word '''null''' and there are no discriminants, then the record type has no components and all records of the type are ''null records''. A record_definition of '''null record''' is equivalent to '''record null; end record'''. == Dynamic Semantics == <span id="I1914"></span>The elaboration of a record_type_definition creates the record type and its first subtype, and consists of the elaboration of the record_definition. <span id="I1915"></span>The elaboration of a record_definition consists of the elaboration of its component_list, if any. <span id="I1916"></span>The elaboration of a component_list consists of the elaboration of the component_items and variant_part, if any, in the order in which they appear. <span id="I1917"></span>The elaboration of a component_declaration consists of the elaboration of the component_definition. <span id="I1918"></span><span id="I1919"></span><span id="I1920"></span>Within the definition of a composite type, if a component_definition or discrete_subtype_definition (see [[Guide:95lrm/RM-9-5-2|9.5.2]]) includes a name that denotes a discriminant of the type, or that is an attribute_reference whose prefix denotes the current instance of the type, the expression containing the name is called a ''per-object expression'', and the constraint or range being defined is called a ''per-object constraint''. <span id="I1921"></span>For the elaboration of a component_definition of a component_declaration or the discrete_subtype_definition of an entry_declaration for an entry family (see [[Guide:95lrm/RM-9-5-2|9.5.2]]), if the constraint or range of the subtype_indication or discrete_subtype_definition is not a per-object constraint, then the subtype_indication or discrete_subtype_definition is elaborated. On the other hand, if the constraint or range is a per-object constraint, then the elaboration consists of the evaluation of any included expression that is not part of a per-object expression. Each such expression is evaluated once unless it is part of a named association in a discriminant constraint, in which case it is evaluated once for each associated discriminant. <div><span id="I1922"></span>When a per-object constraint is elaborated (as part of creating an object), each per-object expression of the constraint is evaluated. For other expressions, the values determined during the elaboration of the component_definition or entry_declaration are used. Any checks associated with the enclosing subtype_indication or discrete_subtype_definition are performed, including the subtype compatibility check (see [[Guide:95lrm/RM-3-2-2|3.2.2]]), and the associated subtype is created.</div> == Notes == 55  A component_declaration with several identifiers is equivalent to a sequence of single component_declarations, as explained in [[Guide:95lrm/RM-3-3-1|3.3.1]]. 56  The default_expression of a record component is only evaluated upon the creation of a default-initialized object of the record type (presuming the object has the component, if it is in a variant_part -- see [[Guide:95lrm/RM-3-3-1|3.3.1]]). 57  The subtype defined by a component_definition (see [[Guide:95lrm/RM-3-6|3.6]]) has to be a definite subtype. 58  If a record type does not have a variant_part, then the same components are present in all values of the type. 59  A record type is limited if it has the reserved word '''limited''' in its definition, or if any of its components are limited (see [[Guide:95lrm/RM-7-5|7.5]]). 60  <span id="I1923"></span>The predefined operations of a record type include membership tests, qualification, and explicit conversion. If the record type is nonlimited, they also include assignment and the predefined equality operators. 61  A component of a record can be named with a selected_component. A value of a record can be specified with a record_aggregate, unless the record type is limited. == Examples == ''Examples of record type declarations:'' <p><syntaxhighlight lang="Ada"> type Date is record    Day   : Integer range 1 .. 31;    Month : Month_Name;    Year  : Integer range 0 .. 4000; end record;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Complex is record    Re : Real := 0.0;    Im : Real := 0.0; end record;</syntaxhighlight></p> ''Examples of record variables:'' <p><syntaxhighlight lang="Ada"> Tomorrow, Yesterday : Date; A, B, C : Complex;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- both components of A, B, and C are implicitly initialized to zero </syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-7-2|Previous]] | [[Guide:95lrm/RM-3-8-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} j2wsutgkoiaheichnw4fc7j3g2n9vse Guide:95lrm/RM-3-8-1 4200 976 3820 3819 2019-05-04T23:37:06Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-8|Previous]] | [[Guide:95lrm/RM-3-9|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.8.1 Variant Parts and Discrete Choices}} A record type with a variant_part specifies alternative lists of components. Each variant defines the components for the value or values of the discriminant covered by its discrete_choice_list. == Syntax == <p><span></span></p> variant_part<span id="I1924"></span> ::= '''case''' ''discriminant_''<span id="I1925"></span>direct_name '''is''' <span id="I1926"></span>variant {<span id="I1927"></span>variant} '''end''' '''case'''; <p><span></span></p> variant<span id="I1928"></span> ::= '''when''' <span id="I1929"></span>discrete_choice_list => <span id="I1930"></span>component_list <p><span></span></p> discrete_choice_list<span id="I1931"></span> ::= <span id="I1932"></span>discrete_choice {| <span id="I1933"></span>discrete_choice} <p><span></span></p> discrete_choice<span id="I1934"></span> ::= <span id="I1935"></span>expression | <span id="I1936"></span>discrete_range | '''others''' == Name Resolution Rules == <span id="I1937"></span>The ''discriminant_''direct_name shall resolve to denote a discriminant (called the ''discriminant of the variant_part'') specified in the known_discriminant_part of the full_type_declaration that contains the variant_part. <span id="I1938"></span>The expected type for each discrete_choice in a variant is the type of the discriminant of the variant_part. == Legality Rules == The discriminant of the variant_part shall be of a discrete type. The expressions and discrete_ranges given as discrete_choices in a variant_part shall be static. The discrete_choice '''others''' shall appear alone in a discrete_choice_list, and such a discrete_choice_list, if it appears, shall be the last one in the enclosing construct. <span id="I1939"></span>A discrete_choice is defined to ''cover a value'' in the following cases: * A discrete_choice that is an expression covers a value if the value equals the value of the expression converted to the expected type. * A discrete_choice that is a discrete_range covers all values (possibly none) that belong to the range. * The discrete_choice '''others''' covers all values of its expected type that are not covered by previous discrete_choice_lists of the same construct. <span id="I1940"></span>A discrete_choice_list covers a value if one of its discrete_choices covers the value. The possible values of the discriminant of a variant_part shall be covered as follows: * If the discriminant is of a static constrained scalar subtype, then each non-'''others''' discrete_choice shall cover only values in that subtype, and each value of that subtype shall be covered by some discrete_choice (either explicitly or by '''others'''); * If the type of the discriminant is a descendant of a generic formal scalar type then the variant_part shall have an '''others''' discrete_choice; * Otherwise, each value of the base range of the type of the discriminant shall be covered (either explicitly or by '''others'''). Two distinct discrete_choices of a variant_part shall not cover the same value. == Static Semantics == If the component_list of a variant is specified by '''null''', the variant has no components. <span id="I1941"></span><span id="I1942"></span>The discriminant of a variant_part is said to ''govern'' the variant_part and its variants. In addition, the discriminant of a derived type governs a variant_part and its variants if it corresponds (see [[Guide:95lrm/RM-3-7|3.7]]) to the discriminant of the variant_part. == Dynamic Semantics == A record value contains the values of the components of a particular variant only if the value of the discriminant governing the variant is covered by the discrete_choice_list of the variant. This rule applies in turn to any further variant that is, itself, included in the component_list of the given variant. <span id="I1943"></span>The elaboration of a variant_part consists of the elaboration of the component_list of each variant in the order in which they appear. == Examples == ''Example of record type with a variant part:'' <p><syntaxhighlight lang="Ada"> type Device is (Printer, Disk, Drum); type State  is (Open, Closed);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Peripheral(Unit : Device := Disk) is record    Status : State;    case Unit is       when Printer =>          Line_Count : Integer range 1 .. Page_Size;       when others =>          Cylinder   : Cylinder_Index;          Track      : Track_Number;      end case;    end record;</syntaxhighlight></p> ''Examples of record subtypes:'' <p><syntaxhighlight lang="Ada"> subtype Drum_Unit is Peripheral(Drum); subtype Disk_Unit is Peripheral(Disk);</syntaxhighlight></p> ''Examples of constrained record variables:'' <p><syntaxhighlight lang="Ada"> Writer   : Peripheral(Unit  => Printer); Archive  : Disk_Unit;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-8|Previous]] | [[Guide:95lrm/RM-3-9|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 4x6e90p8pmk7vcvkde77xhhhjo3l705 Guide:95lrm/RM-3-9 4200 977 3822 3821 2019-05-04T23:37:08Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-8-1|Previous]] | [[Guide:95lrm/RM-3-9-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.9 Tagged Types and Type Extensions}} <span id="I1944"></span><span id="I1945"></span><span id="I1946"></span><span id="I1947"></span><span id="I1948"></span>Tagged types and type extensions support object-oriented programming, based on inheritance with extension and run-time polymorphism via ''dispatching operations''. <span id="I1949"></span><span id="I1950"></span><span id="I1951"></span> == Static Semantics == <span id="I1952"></span>A record type or private type that has the reserved word '''tagged''' in its declaration is called a ''tagged'' type. When deriving from a tagged type, additional components may be defined. As for any derived type, additional primitive subprograms may be defined, and inherited primitive subprograms may be overridden. <span id="I1953"></span><span id="I1954"></span>The derived type is called an ''extension'' of the ancestor type, or simply a ''type extension''. <span id="I1955"></span><span id="I1956"></span><span id="I1957"></span>Every type extension is also a tagged type, and is either a ''record extension'' or a ''private extension'' of some other tagged type. A record extension is defined by a derived_type_definition with a record_extension_part. A private extension, which is a partial view of a record extension, can be declared in the visible part of a package (see [[Guide:95lrm/RM-7-3|7.3]]) or in a generic formal part (see [[Guide:95lrm/RM-12-5-1|12.5.1]]). <span id="I1958"></span>An object of a tagged type has an associated (run-time) ''tag'' that identifies the specific tagged type used to create the object originally. The tag of an operand of a class-wide tagged type ''T'''Class controls which subprogram body is to be executed when a primitive subprogram of type ''T'' is applied to the operand (see [[Guide:95lrm/RM-3-9-2|3.9.2]]); <span id="I1959"></span>using a tag to control which body to execute is called ''dispatching''. <span id="I1960"></span><span id="I1961"></span><span id="I1962"></span><span id="I1963"></span> The tag of a specific tagged type identifies the full_type_declaration of the type. If a declaration for a tagged type occurs within a generic_package_declaration, then the corresponding type declarations in distinct instances of the generic package are associated with distinct tags. For a tagged type that is local to a generic package body, the language does not specify whether repeated instantiations of the generic body result in distinct tags. The following language-defined library package exists: <p><syntaxhighlight lang="Ada"> package Ada.Tags is   type Tag is private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     function Expanded_Name(T : Tag) return String;  function External_Tag(T : Tag) return String;  function Internal_Tag(External : String) return Tag;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     Tag_Error : exception;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> private ... -- not specified by the language end Ada.Tags;</syntaxhighlight></p> The function Expanded_Name returns the full expanded name of the first subtype of the specific type identified by the tag, in upper case, starting with a root library unit. The result is implementation defined if the type is declared within an unnamed block_statement. The function External_Tag returns a string to be used in an external representation for the given tag. The call External_Tag(S'Tag) is equivalent to the attribute_reference S'External_Tag (see [[Guide:95lrm/RM-13-3|13.3]]). The function Internal_Tag returns the tag that corresponds to the given external tag, or raises Tag_Error if the given string is not the external tag for any specific type of the partition. For every subtype S of a tagged type ''T'' (specific or class-wide), the following attributes are defined: ;  S'Class : <span id="I1976"></span><span id="I1977"></span>S'Class denotes a subtype of the class-wide type (called ''T'''Class in this International Standard) for the class rooted at ''T'' (or if S already denotes a class-wide subtype, then S'Class is the same as S). <p><span></span></p> :<span id="I1978"></span><span id="I1979"></span>S'Class is unconstrained. However, if S is constrained, then the values of S'Class are only those that when converted to the type ''T'' belong to S. ;  S'Tag : <span id="I1980"></span><span id="I1981"></span>S'Tag denotes the tag of the type ''T'' (or if ''T'' is class-wide, the tag of the root type of the corresponding class). The value of this attribute is of type Tag. Given a prefix X that is of a class-wide tagged type (after any implicit dereference), the following attribute is defined: ;  X'Tag : <span id="I1982"></span><span id="I1983"></span>X'Tag denotes the tag of X. The value of this attribute is of type Tag. == Dynamic Semantics == The tag associated with an object of a tagged type is determined as follows: * <span id="I1984"></span>The tag of a stand-alone object, a component, or an aggregate of a specific tagged type ''T'' identifies ''T''. * <span id="I1985"></span>The tag of an object created by an allocator for an access type with a specific designated tagged type ''T'', identifies ''T''. * <span id="I1986"></span>The tag of an object of a class-wide tagged type is that of its initialization expression. * <span id="I1987"></span>The tag of the result returned by a function whose result type is a specific tagged type ''T'' identifies ''T''. * <span id="I1988"></span>The tag of the result returned by a function with a class-wide result type is that of the return expression. <span id="I1989"></span>The tag is preserved by type conversion and by parameter passing. The tag of a value is the tag of the associated object (see [[Guide:95lrm/RM-6-2|6.2]]). == Implementation Permissions == The implementation of the functions in Ada.Tags may raise Tag_Error if no specific type corresponding to the tag passed as a parameter exists in the partition at the time the function is called. == Notes == 62  A type declared with the reserved word '''tagged''' should normally be declared in a package_specification, so that new primitive subprograms can be declared for it. 63  Once an object has been created, its tag never changes. 64  Class-wide types are defined to have unknown discriminants (see [[Guide:95lrm/RM-3-7|3.7]]). This means that objects of a class-wide type have to be explicitly initialized (whether created by an object_declaration or an allocator), and that aggregates have to be explicitly qualified with a specific type when their expected type is class-wide. 65  If S denotes an untagged private type whose full type is tagged, then S'Class is also allowed before the full type definition, but only in the private part of the package in which the type is declared (see [[Guide:95lrm/RM-7-3-1|7.3.1]]). Similarly, the Class attribute is defined for incomplete types whose full type is tagged, but only within the library unit in which the incomplete type is declared (see [[Guide:95lrm/RM-3-10-1|3.10.1]]). == Examples == ''Examples of tagged record types:'' <p><syntaxhighlight lang="Ada"> type Point is tagged  record   X, Y : Real := 0.0;   end record;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Expression is tagged null record;   -- Components will be added by each extension</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-8-1|Previous]] | [[Guide:95lrm/RM-3-9-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 1v97tfaia1vivic33soucpyk3ls6669 Guide:95lrm/RM-3-9-1 4200 979 3824 3823 2019-05-04T23:37:11Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-9|Previous]] | [[Guide:95lrm/RM-3-9-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.9.1 Type Extensions}} <span id="I1990"></span><span id="I1991"></span><span id="I1992"></span><span id="I1993"></span><span id="I1994"></span><span id="I1995"></span>Every type extension is a tagged type, and is either a ''record extension'' or a ''private extension'' of some other tagged type. == Syntax == <p><span></span></p> record_extension_part<span id="I1996"></span> ::= '''with''' <span id="I1997"></span>record_definition == Legality Rules == The parent type of a record extension shall not be a class-wide type. If the parent type is nonlimited, then each of the components of the record_extension_part shall be nonlimited. <span id="I1998"></span>The accessibility level (see [[Guide:95lrm/RM-3-10-2|3.10.2]]) of a record extension shall not be statically deeper than that of its parent type. <span id="I1999"></span>In addition to the places where Legality Rules normally apply (see [[Guide:95lrm/RM-12-3|12.3]]), these rules apply also in the private part of an instance of a generic unit. A type extension shall not be declared in a generic body if the parent type is declared outside that body. == Dynamic Semantics == <span id="I2000"></span>The elaboration of a record_extension_part consists of the elaboration of the record_definition. == Notes == 66  The term ''type extension'' refers to a type as a whole. The term ''extension part'' refers to the piece of text that defines the additional components (if any) the type extension has relative to its specified ancestor type. 67  The accessibility rules imply that a tagged type declared in a library package_specification can be extended only at library level or as a generic formal. When the extension is declared immediately within a package_body, primitive subprograms are inherited and are overridable, but new primitive subprograms cannot be added. 68  A name that denotes a component (including a discriminant) of the parent type is not allowed within the record_extension_part. Similarly, a name that denotes a component defined within the record_extension_part is not allowed within the record_extension_part. It is permissible to use a name that denotes a discriminant of the record extension, providing there is a new known_discriminant_part in the enclosing type declaration. (The full rule is given in [[Guide:95lrm/RM-3-8|3.8]].) 69  Each visible component of a record extension has to have a unique name, whether the component is (visibly) inherited from the parent type or declared in the record_extension_part (see [[Guide:95lrm/RM-8-3|8.3]]). == Examples == ''Examples of record extensions (of types defined above in [[Guide:95lrm/RM-3-9|3.9]]):'' <p><syntaxhighlight lang="Ada"> type Painted_Point is new Point with   record  Paint : Color := White;   end record;  -- Components X and Y are inherited</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Origin : constant Painted_Point := (X | Y => 0.0, Paint => Black);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Literal is new Expression with   record                 -- a leaf in an Expression tree  Value : Real;   end record;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Expr_Ptr is access all Expression'Class;                             -- see 3.10</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Binary_Operation is new Expression with   record                 -- an internal node in an Expression tree Left, Right : Expr_Ptr;   end record;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> type Addition is new Binary_Operation with null record; type Subtraction is new Binary_Operation with null record;   -- No additional components needed for these extensions</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Tree : Expr_Ptr :=         -- A tree representation of ''5.0 + (13.0-7.0)'' new Addition'(    Left  => new Literal'(Value => 5.0),    Right => new Subtraction'(       Left  => new Literal'(Value => 13.0),       Right => new Literal'(Value => 7.0)));</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-9|Previous]] | [[Guide:95lrm/RM-3-9-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 5tsdn8f0hejia9e8ijryt3ui7xar62n Guide:95lrm/RM-3-9-2 4200 980 3826 3825 2019-05-04T23:37:12Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-9-1|Previous]] | [[Guide:95lrm/RM-3-9-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.9.2 Dispatching Operations of Tagged Types}} <span id="I2001"></span><span id="I2002"></span><span id="I2003"></span><span id="I2004"></span><span id="I2005"></span><span id="I2006"></span><span id="I2007"></span><span id="I2008"></span>The primitive subprograms of a tagged type are called ''dispatching operations''. A dispatching operation can be called using a statically determined ''controlling'' tag, in which case the body to be executed is determined at compile time. Alternatively, the controlling tag can be dynamically determined, in which case the call ''dispatches'' to a body that is determined at run time; such a call is termed a ''dispatching call''. As explained below, the properties of the operands and the context of a particular call on a dispatching operation determine how the controlling tag is determined, and hence whether or not the call is a dispatching call. Run-time polymorphism is achieved when a dispatching operation is called by a dispatching call. <span id="I2009"></span><span id="I2010"></span><span id="I2011"></span><span id="I2012"></span><span id="I2013"></span> == Static Semantics == <span id="I2014"></span><span id="I2015"></span>A ''call on a dispatching operation'' is a call whose name or prefix denotes the declaration of a primitive subprogram of a tagged type, that is, a dispatching operation. <span id="I2016"></span>A ''controlling operand'' in a call on a dispatching operation of a tagged type ''T'' is one whose corresponding formal parameter is of type ''T'' or is of an anonymous access type with designated type ''T''; <span id="I2017"></span>the corresponding formal parameter is called a ''controlling formal parameter''. If the controlling formal parameter is an access parameter, the controlling operand is the object designated by the actual parameter, rather than the actual parameter itself. <span id="I2018"></span>If the call is to a (primitive) function with result type ''T'', then the call has a ''controlling result'' -- the context of the call can control the dispatching. A name or expression of a tagged type is either ''statically'' tagged, ''dynamically'' tagged, or ''tag indeterminate'', according to whether, when used as a controlling operand, the tag that controls dispatching is determined statically by the operand's (specific) type, dynamically by its tag at run time, or from context. A qualified_expression or parenthesized expression is statically, dynamically, or indeterminately tagged according to its operand. For other kinds of names and expressions, this is determined as follows: * <span id="I2019"></span>The name or expression is ''statically tagged'' if it is of a specific tagged type and, if it is a call with a controlling result, it has at least one statically tagged controlling operand; * <span id="I2020"></span>The name or expression is ''dynamically tagged'' if it is of a class-wide type, or it is a call with a controlling result and at least one dynamically tagged controlling operand; * <span id="I2021"></span>The name or expression is ''tag indeterminate'' if it is a call with a controlling result, all of whose controlling operands (if any) are tag indeterminate. A type_conversion is statically or dynamically tagged according to whether the type determined by the subtype_mark is specific or class-wide, respectively. For an object that is designated by an expression whose expected type is an anonymous access-to-specific tagged type, the object is dynamically tagged if the expression, ignoring enclosing parentheses, is of the form X'Access, where X is of a class-wide type, or is of the form '''new''' T'(...), where T denotes a class-wide subtype. Otherwise, the object is statically or dynamically tagged according to whether the designated type of the type of the expression is specific or class-wide, respectively. == Legality Rules == A call on a dispatching operation shall not have both dynamically tagged and statically tagged controlling operands. If the expected type for an expression or name is some specific tagged type, then the expression or name shall not be dynamically tagged unless it is a controlling operand in a call on a dispatching operation. Similarly, if the expected type for an expression is an anonymous access-to-specific tagged type, then the object designated by the expression shall not be dynamically tagged unless it is a controlling operand in a call on a dispatching operation. In the declaration of a dispatching operation of a tagged type, everywhere a subtype of the tagged type appears as a subtype of the profile (see [[Guide:95lrm/RM-6-1|6.1]]), it shall statically match the first subtype of the tagged type. <span id="I2022"></span>If the dispatching operation overrides an inherited subprogram, it shall be subtype conformant with the inherited subprogram. <span id="I2023"></span>The convention of an inherited or overriding dispatching operation is the convention of the corresponding primitive operation of the parent type. An explicitly declared dispatching operation shall not be of convention Intrinsic. The default_expression for a controlling formal parameter of a dispatching operation shall be tag indeterminate. A controlling formal parameter that is an access parameter shall not have a default_expression. A given subprogram shall not be a dispatching operation of two or more distinct tagged types. The explicit declaration of a primitive subprogram of a tagged type shall occur before the type is frozen (see [[Guide:95lrm/RM-13-14|13.14]]). For example, new dispatching operations cannot be added after objects or values of the type exist, nor after deriving a record extension from it, nor after a body. == Dynamic Semantics == <span id="I2024"></span><span id="I2025"></span>For the execution of a call on a dispatching operation of a type ''T'', the ''controlling tag value'' determines which subprogram body is executed. The controlling tag value is defined as follows: * <span id="I2026"></span>If one or more controlling operands are statically tagged, then the controlling tag value is ''statically determined'' to be the tag of ''T''. * If one or more controlling operands are dynamically tagged, then the controlling tag value is not statically determined, but is rather determined by the tags of the controlling operands. <span id="I2027"></span><span id="I2028"></span>If there is more than one dynamically tagged controlling operand, a check is made that they all have the same tag. <span id="I2029"></span>If this check fails, Constraint_Error is raised unless the call is a function_call whose name denotes the declaration of an equality operator (predefined or user defined) that returns Boolean, in which case the result of the call is defined to indicate inequality, and no subprogram_body is executed. This check is performed prior to evaluating any tag-indeterminate controlling operands. * If all of the controlling operands are tag-indeterminate, then: <p><span></span></p> :* If the call has a controlling result and is itself a (possibly parenthesized or qualified) controlling operand of an enclosing call on a dispatching operation of type ''T'', then its controlling tag value is determined by the controlling tag value of this enclosing call; <p><span></span></p> :* <span id="I2030"></span>Otherwise, the controlling tag value is statically determined to be the tag of type ''T''. For the execution of a call on a dispatching operation, the body executed is the one for the corresponding primitive subprogram of the specific type identified by the controlling tag value. The body for an explicitly declared dispatching operation is the corresponding explicit body for the subprogram. The body for an implicitly declared dispatching operation that is overridden is the body for the overriding subprogram, even if the overriding occurs in a private part. The body for an inherited dispatching operation that is not overridden is the body of the corresponding subprogram of the parent or ancestor type. == Notes == 70  The body to be executed for a call on a dispatching operation is determined by the tag; it does not matter whether that tag is determined statically or dynamically, and it does not matter whether the subprogram's declaration is visible at the place of the call. 71  This subclause covers calls on primitive subprograms of a tagged type. Rules for tagged type membership tests are described in [[Guide:95lrm/RM-4-5-2|4.5.2]]. Controlling tag determination for an assignment_statement is described in [[Guide:95lrm/RM-5-2|5.2]]. 72  A dispatching call can dispatch to a body whose declaration is not visible at the place of the call. 73  A call through an access-to-subprogram value is never a dispatching call, even if the access value designates a dispatching operation. Similarly a call whose prefix denotes a subprogram_renaming_declaration cannot be a dispatching call unless the renaming itself is the declaration of a primitive subprogram. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-9-1|Previous]] | [[Guide:95lrm/RM-3-9-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 7wcqqba2qgvuh8c3q998grwf1j6sg54 Guide:95lrm/RM-3-9-3 4200 981 3828 3827 2019-05-04T23:37:13Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-9-2|Previous]] | [[Guide:95lrm/RM-3-10|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 3.9.3 Abstract Types and Subprograms}} <span id="I2031"></span><span id="I2032"></span><span id="I2033"></span><span id="I2034"></span>An ''abstract type'' is a tagged type intended for use as a parent type for type extensions, but which is not allowed to have objects of its own. <span id="I2035"></span><span id="I2036"></span>An ''abstract subprogram'' is a subprogram that has no body, but is intended to be overridden at some point when inherited. Because objects of an abstract type cannot be created, a dispatching call to an abstract subprogram always dispatches to some overriding body. == Legality Rules == <span id="I2037"></span><span id="I2038"></span>An ''abstract type'' is a specific type that has the reserved word '''abstract''' in its declaration. Only a tagged type is allowed to be declared abstract. <span id="I2039"></span><span id="I2040"></span>A subprogram declared by an abstract_subprogram_declaration (see [[Guide:95lrm/RM-6-1|6.1]]) is an ''abstract subprogram''. If it is a primitive subprogram of a tagged type, then the tagged type shall be abstract. For a derived type, if the parent or ancestor type has an abstract primitive subprogram, or a primitive function with a controlling result, then: * If the derived type is abstract or untagged, the inherited subprogram is ''abstract''. * Otherwise, the subprogram shall be overridden with a nonabstract subprogram; for a type declared in the visible part of a package, the overriding may be either in the visible or the private part. However, if the type is a generic formal type, the subprogram need not be overridden for the formal type itself; a nonabstract version will necessarily be provided by the actual type. A call on an abstract subprogram shall be a dispatching call; nondispatching calls to an abstract subprogram are not allowed. The type of an aggregate, or of an object created by an object_declaration or an allocator, or a generic formal object of mode '''in''', shall not be abstract. The type of the target of an assignment operation (see [[Guide:95lrm/RM-5-2|5.2]]) shall not be abstract. The type of a component shall not be abstract. If the result type of a function is abstract, then the function shall be abstract. If a partial view is not abstract, the corresponding full view shall not be abstract. If a generic formal type is abstract, then for each primitive subprogram of the formal that is not abstract, the corresponding primitive subprogram of the actual shall not be abstract. For an abstract type declared in a visible part, an abstract primitive subprogram shall not be declared in the private part, unless it is overriding an abstract subprogram implicitly declared in the visible part. For a tagged type declared in a visible part, a primitive function with a controlling result shall not be declared in the private part, unless it is overriding a function implicitly declared in the visible part. A generic actual subprogram shall not be an abstract subprogram. The prefix of an attribute_reference for the Access, Unchecked_Access, or Address attributes shall not denote an abstract subprogram. == Notes == 74  Abstractness is not inherited; to declare an abstract type, the reserved word '''abstract''' has to be used in the declaration of the type extension. 75  A class-wide type is never abstract. Even if a class is rooted at an abstract type, the class-wide type for the class is not abstract, and an object of the class-wide type can be created; the tag of such an object will identify some nonabstract type in the class. == Examples == ''Example of an abstract type representing a set of natural numbers:'' <p><syntaxhighlight lang="Ada"> package Sets is   subtype Element_Type is Natural;   type Set is abstract tagged null record; function Empty return Set is abstract;  function Union(Left, Right : Set) return Set is abstract;  function Intersection(Left, Right : Set) return Set is abstract;  function Unit_Set(Element : Element_Type) return Set is abstract;  procedure Take(Element : out Element_Type;                 From : in out Set) is abstract; end Sets;</syntaxhighlight></p> == Notes == 76  ''Notes on the example:'' Given the above abstract type, one could then derive various (nonabstract) extensions of the type, representing alternative implementations of a set. One might use a bit vector, but impose an upper bound on the largest element representable, while another might use a hash table, trading off space for flexibility. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-9-2|Previous]] | [[Guide:95lrm/RM-3-10|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 20zyg411qo58lqdlnwgc5s32dwoqo84 Guide:95lrm/RM-4 4200 982 3830 3829 2019-05-04T23:37:13Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-11-1|Previous]] | [[Guide:95lrm/RM-4-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Section 4: Names and Expressions}} The rules applicable to the different forms of name and expression, and to their evaluation, are given in this section. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-3-11-1|Previous]] | [[Guide:95lrm/RM-4-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} j08xj8nbeglnnzp97f7ue3mecbs8obz Guide:95lrm/RM-4-1 4200 983 3832 3831 2019-05-04T23:37:14Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4|Previous]] | [[Guide:95lrm/RM-4-1-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 4.1 Names}} Names can denote declared entities, whether declared explicitly or implicitly (see [[Guide:95lrm/RM-3-1|3.1]]). Names can also denote objects or subprograms designated by access values; the results of type_conversions or function_calls; subcomponents and slices of objects and values; protected subprograms, single entries, entry families, and entries in families of entries. Finally, names can denote attributes of any of the foregoing. == Syntax == <p><span></span></p> name<span id="I2156"></span> ::= <span id="I2157"></span>direct_name | <span id="I2158"></span>explicit_dereference | <span id="I2159"></span>indexed_component | <span id="I2160"></span>slice | <span id="I2161"></span>selected_component | <span id="I2162"></span>attribute_reference | <span id="I2163"></span>type_conversion | <span id="I2164"></span>function_call | <span id="I2165"></span>character_literal <p><span></span></p> direct_name<span id="I2166"></span> ::= <span id="I2167"></span>identifier | <span id="I2168"></span>operator_symbol <p><span></span></p> prefix<span id="I2169"></span> ::= <span id="I2170"></span>name | <span id="I2171"></span>implicit_dereference <p><span></span></p> explicit_dereference<span id="I2172"></span> ::= <span id="I2173"></span>name.'''all''' <p><span></span></p> implicit_dereference<span id="I2174"></span> ::= <span id="I2175"></span>name Certain forms of name (indexed_components, selected_components, slices, and attributes) include a prefix that is either itself a name that denotes some related entity, or an implicit_dereference of an access value that designates some related entity. == Name Resolution Rules == <span id="I2176"></span><span id="I2177"></span>The name in a ''dereference'' (either an implicit_dereference or an explicit_dereference) is expected to be of any access type. == Static Semantics == <span id="I2178"></span>If the type of the name in a dereference is some access-to-object type ''T'', then the dereference denotes a view of an object, the ''nominal subtype'' of the view being the designated subtype of ''T''. <span id="I2179"></span>If the type of the name in a dereference is some access-to-subprogram type ''S'', then the dereference denotes a view of a subprogram, the ''profile'' of the view being the designated profile of ''S''. == Dynamic Semantics == <span id="I2180"></span>The evaluation of a name determines the entity denoted by the name. This evaluation has no other effect for a name that is a direct_name or a character_literal. <span id="I2181"></span>The evaluation of a name that has a prefix includes the evaluation of the prefix. <span id="I2182"></span>The evaluation of a prefix consists of the evaluation of the name or the implicit_dereference. The prefix denotes the entity denoted by the name or the implicit_dereference. <span id="I2183"></span>The evaluation of a dereference consists of the evaluation of the name and the determination of the object or subprogram that is designated by the value of the name. <span id="I2184"></span><span id="I2185"></span>A check is made that the value of the name is not the null access value. <span id="I2186"></span>Constraint_Error is raised if this check fails. The dereference denotes the object or subprogram designated by the value of the name. == Examples == ''Examples of direct names:'' <p><syntaxhighlight lang="Ada"> Pi       -- the direct name of a number           (see 3.3.2) Limit    -- the direct name of a constant         (see 3.3.1) Count    -- the direct name of a scalar variable  (see 3.3.1) Board    -- the direct name of an array variable  (see 3.6.1) Matrix   -- the direct name of a type             (see 3.6) Random   -- the direct name of a function         (see 6.1) Error    -- the direct name of an exception       (see 11.1)</syntaxhighlight></p> ''Examples of dereferences:'' <p><syntaxhighlight lang="Ada"> Next_Car.all        --  explicit dereference denoting the object designated by                  --  the access variable Next_Car (see 3.10.1) Next_Car.Owner      --  selected component with implicit dereference;                  --  same as Next_Car.all.Owner</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4|Previous]] | [[Guide:95lrm/RM-4-1-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 1aaibffshf4ggsd2aixjo3gemhd0cax Guide:95lrm/RM-4-1-1 4200 984 3834 3833 2019-05-04T23:37:14Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-1|Previous]] | [[Guide:95lrm/RM-4-1-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 4.1.1 Indexed Components}} An indexed_component denotes either a component of an array or an entry in a family of entries. <span id="I2187"></span> == Syntax == <p><span></span></p> indexed_component<span id="I2188"></span> ::= <span id="I2189"></span>prefix(<span id="I2190"></span>expression {, <span id="I2191"></span>expression}) == Name Resolution Rules == The prefix of an indexed_component with a given number of expressions shall resolve to denote an array (after any implicit dereference) with the corresponding number of index positions, or shall resolve to denote an entry family of a task or protected object (in which case there shall be only one expression). <span id="I2192"></span>The expected type for each expression is the corresponding index type. == Static Semantics == When the prefix denotes an array, the indexed_component denotes the component of the array with the specified index value(s). <span id="I2193"></span>The nominal subtype of the indexed_component is the component subtype of the array type. When the prefix denotes an entry family, the indexed_component denotes the individual entry of the entry family with the specified index value. == Dynamic Semantics == <span id="I2194"></span>For the evaluation of an indexed_component, the prefix and the expressions are evaluated in an arbitrary order. The value of each expression is converted to the corresponding index type. <span id="I2195"></span><span id="I2196"></span><span id="I2197"></span>A check is made that each index value belongs to the corresponding index range of the array or entry family denoted by the prefix. <span id="I2198"></span>Constraint_Error is raised if this check fails. == Examples == ''Examples of indexed components:'' <p><syntaxhighlight lang="Ada"> My_Schedule(Sat)     --  a component of a one-dimensional array     (see 3.6.1) Page(10)             --  a component of a one-dimensional array     (see 3.6) Board(M, J + 1)      --  a component of a two-dimensional array     (see 3.6.1) Page(10)(20)         --  a component of a component                 (see 3.6) Request(Medium)      --  an entry in a family of entries            (see 9.1) Next_Frame(L)(M, N)  --  a component of a function call             (see 6.1)</syntaxhighlight></p> == Notes == 1  ''Notes on the examples:'' Distinct notations are used for components of multidimensional arrays (such as Board) and arrays of arrays (such as Page). The components of an array of arrays are arrays and can therefore be indexed. Thus Page(10)(20) denotes the 20th component of Page(10). In the last example Next_Frame(L) is a function call returning an access value that designates a two-dimensional array. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-1|Previous]] | [[Guide:95lrm/RM-4-1-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 63gy5w5nsc9y7q76yp3d4h7e1rwoird Guide:95lrm/RM-4-1-2 4200 985 3836 3835 2019-05-04T23:37:15Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-1-1|Previous]] | [[Guide:95lrm/RM-4-1-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 4.1.2 Slices}} <span id="I2199"></span>A slice denotes a one-dimensional array formed by a sequence of consecutive components of a one-dimensional array. A slice of a variable is a variable; a slice of a constant is a constant; a slice of a value is a value. == Syntax == <p><span></span></p> slice<span id="I2200"></span> ::= <span id="I2201"></span>prefix(<span id="I2202"></span>discrete_range) == Name Resolution Rules == The prefix of a slice shall resolve to denote a one-dimensional array (after any implicit dereference). <span id="I2203"></span>The expected type for the discrete_range of a slice is the index type of the array type. == Static Semantics == A slice denotes a one-dimensional array formed by the sequence of consecutive components of the array denoted by the prefix, corresponding to the range of values of the index given by the discrete_range. The type of the slice is that of the prefix. Its bounds are those defined by the discrete_range. == Dynamic Semantics == <span id="I2204"></span>For the evaluation of a slice, the prefix and the discrete_range are evaluated in an arbitrary order. <span id="I2205"></span><span id="I2206"></span><span id="I2207"></span>If the slice is not a ''null slice'' (a slice where the discrete_range is a null range), then a check is made that the bounds of the discrete_range belong to the index range of the array denoted by the prefix. <span id="I2208"></span>Constraint_Error is raised if this check fails. == Notes == 2  A slice is not permitted as the prefix of an Access attribute_reference, even if the components or the array as a whole are aliased. See [[Guide:95lrm/RM-3-10-2|3.10.2]]. 3  For a one-dimensional array A, the slice A(N .. N) denotes an array that has only one component; its type is the type of A. On the other hand, A(N) denotes a component of the array A and has the corresponding component type. == Examples == ''Examples of slices:'' <p><syntaxhighlight lang="Ada">   Stars(1 .. 15)        --  a slice of 15 characters          (see 3.6.3)   Page(10 .. 10 + Size) --  a slice of 1 + Size components    (see 3.6)   Page(L)(A .. B)       --  a slice of the array Page(L)      (see 3.6)   Stars(1 .. 0)         --  a null slice                      (see 3.6.3)   My_Schedule(Weekday)  --  bounds given by subtype           (see 3.6.1 and 3.5.1)   Stars(5 .. 15)(K)     --  same as Stars(K)                  (see 3.6.3)                      --  provided that K is in 5 .. 15</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-1-1|Previous]] | [[Guide:95lrm/RM-4-1-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 2w5opi61ngi7q8fuzytiqyx1y8rqu2y Guide:95lrm/RM-4-1-3 4200 986 3838 3837 2019-05-04T23:37:16Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-1-2|Previous]] | [[Guide:95lrm/RM-4-1-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 4.1.3 Selected Components}} Selected_components are used to denote components (including discriminants), entries, entry families, and protected subprograms; they are also used as expanded names as described below. <span id="I2209"></span> == Syntax == <p><span></span></p> selected_component<span id="I2210"></span> ::= <span id="I2211"></span>prefix . <span id="I2212"></span>selector_name <p><span></span></p> selector_name<span id="I2213"></span> ::= <span id="I2214"></span>identifier | <span id="I2215"></span>character_literal | <span id="I2216"></span>operator_symbol == Name Resolution Rules == <span id="I2217"></span>A selected_component is called an ''expanded name'' if, according to the visibility rules, at least one possible interpretation of its prefix denotes a package or an enclosing named construct (directly, not through a subprogram_renaming_declaration or generic_renaming_declaration). A selected_component that is not an expanded name shall resolve to denote one of the following: * A component (including a discriminant): <p><span></span></p> :The prefix shall resolve to denote an object or value of some non-array composite type (after any implicit dereference). The selector_name shall resolve to denote a discriminant_specification of the type, or, unless the type is a protected type, a component_declaration of the type. The selected_component denotes the corresponding component of the object or value. * A single entry, an entry family, or a protected subprogram: <p><span></span></p> :The prefix shall resolve to denote an object or value of some task or protected type (after any implicit dereference). The selector_name shall resolve to denote an entry_declaration or subprogram_declaration occurring (implicitly or explicitly) within the visible part of that type. The selected_component denotes the corresponding entry, entry family, or protected subprogram. An expanded name shall resolve to denote a declaration that occurs immediately within a named declarative region, as follows: * The prefix shall resolve to denote either a package (including the current instance of a generic package, or a rename of a package), or an enclosing named construct. * The selector_name shall resolve to denote a declaration that occurs immediately within the declarative region of the package or enclosing construct (the declaration shall be visible at the place of the expanded name -- see [[Guide:95lrm/RM-8-3|8.3]]). The expanded name denotes that declaration. * If the prefix does not denote a package, then it shall be a direct_name or an expanded name, and it shall resolve to denote a program unit (other than a package), the current instance of a type, a block_statement, a loop_statement, or an accept_statement (in the case of an accept_statement or entry_body, no family index is allowed); the expanded name shall occur within the declarative region of this construct. Further, if this construct is a callable construct and the prefix denotes more than one such enclosing callable construct, then the expanded name is ambiguous, independently of the selector_name. == Dynamic Semantics == <span id="I2218"></span>The evaluation of a selected_component includes the evaluation of the prefix. <span id="I2219"></span><span id="I2220"></span>For a selected_component that denotes a component of a variant, a check is made that the values of the discriminants are such that the value or object denoted by the prefix has this component. <span id="I2221"></span><span id="I2222"></span>The exception Constraint_Error is raised if this check fails. == Examples == ''Examples of selected components:'' <p><syntaxhighlight lang="Ada">   Tomorrow.Month     --  a record component                      (see 3.8)   Next_Car.Owner     --  a record component                      (see 3.10.1)   Next_Car.Owner.Age --  a record component                      (see 3.10.1)                   --  the previous two lines involve implicit dereferences   Writer.Unit        --  a record component (a discriminant)     (see 3.8.1)   Min_Cell(H).Value  --  a record component of the result        (see 6.1)                   --  of the function call Min_Cell(H)   Control.Seize      --  an entry of a protected object          (see 9.4)   Pool(K).Write      --  an entry of the task Pool(K)            (see 9.4)</syntaxhighlight></p> ''Examples of expanded names:'' <p><syntaxhighlight lang="Ada"> Key_Manager."<"  --  an operator of the visible part of a package  (see 7.3.1) Dot_Product.Sum      --  a variable declared in a function body      (see 6.1) Buffer.Pool          --  a variable declared in a protected unit     (see 9.11) Buffer.Read          --  an entry of a protected unit                (see 9.11) Swap.Temp            --  a variable declared in a block statement    (see 5.6) Standard.Boolean     --  the name of a predefined type               (see A.1)</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-1-2|Previous]] | [[Guide:95lrm/RM-4-1-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 0kzkmyphhfc940nzoy8c5ipkjxsrdgw Guide:95lrm/RM-4-1-4 4200 987 3840 3839 2019-05-04T23:37:16Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-1-3|Previous]] | [[Guide:95lrm/RM-4-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 4.1.4 Attributes}} <span id="I2223"></span>An ''attribute'' is a characteristic of an entity that can be queried via an attribute_reference or a range_attribute_reference. == Syntax == <p><span></span></p> attribute_reference<span id="I2224"></span> ::= <span id="I2225"></span>prefix'<span id="I2226"></span>attribute_designator <p><span></span></p> attribute_designator<span id="I2227"></span> ::= <span id="I2228"></span>identifier[(''static_''<span id="I2229"></span>expression)] | Access | Delta | Digits <p><span></span></p> range_attribute_reference<span id="I2230"></span> ::= <span id="I2231"></span>prefix'<span id="I2232"></span>range_attribute_designator <p><span></span></p> range_attribute_designator<span id="I2233"></span> ::= Range[(''static_''<span id="I2234"></span>expression)] == Name Resolution Rules == In an attribute_reference, if the attribute_designator is for an attribute defined for (at least some) objects of an access type, then the prefix is never interpreted as an implicit_dereference; otherwise (and for all range_attribute_references), if the type of the name within the prefix is of an access type, the prefix is interpreted as an implicit_dereference. Similarly, if the attribute_designator is for an attribute defined for (at least some) functions, then the prefix is never interpreted as a parameterless function_call; otherwise (and for all range_attribute_references), if the prefix consists of a name that denotes a function, it is interpreted as a parameterless function_call. <span id="I2235"></span><span id="I2236"></span>The expression, if any, in an attribute_designator or range_attribute_designator is expected to be of any integer type. == Legality Rules == The expression, if any, in an attribute_designator or range_attribute_designator shall be static. == Static Semantics == An attribute_reference denotes a value, an object, a subprogram, or some other kind of program entity. A range_attribute_reference X'Range(N) is equivalent to the range X'First(N) .. X'Last(N), except that the prefix is only evaluated once. Similarly, X'Range is equivalent to X'First .. X'Last, except that the prefix is only evaluated once. == Dynamic Semantics == <span id="I2237"></span><span id="I2238"></span>The evaluation of an attribute_reference (or range_attribute_reference) consists of the evaluation of the prefix. == Implementation Permissions == An implementation may provide implementation-defined attributes; the identifier for an implementation-defined attribute shall differ from those of the language-defined attributes unless supplied for compatibility with a previous edition of this International Standard. == Notes == 4  Attributes are defined throughout this International Standard, and are summarized in [[Guide:95lrm/RM-K|Annex K]]. 5  In general, the name in a prefix of an attribute_reference (or a range_attribute_reference) has to be resolved without using any context. However, in the case of the Access attribute, the expected type for the prefix has to be a single access type, and if it is an access-to-subprogram type (see [[Guide:95lrm/RM-3-10-2|3.10.2]]) then the resolution of the name can use the fact that the profile of the callable entity denoted by the prefix has to be type conformant with the designated profile of the access type. <span id="I2239"></span> == Examples == ''Examples of attributes:'' <p><syntaxhighlight lang="Ada"> Color'First        -- minimum value of the enumeration type Color    (see 3.5.1) Rainbow'Base'First -- same as Color'First                            (see 3.5.1) Real'Digits        -- precision of the type Real                     (see 3.5.7) Board'Last(2)      -- upper bound of the second dimension of Board   (see 3.6.1) Board'Range(1)     -- index range of the first dimension of Board    (see 3.6.1) Pool(K)'Terminated -- True if task Pool(K) is terminated             (see 9.1) Date'Size          -- number of bits for records of type Date        (see 3.8) Message'Address    -- address of the record variable Message         (see 3.7.1) </syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-1-3|Previous]] | [[Guide:95lrm/RM-4-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 7y22a7wqoukcxflb1rc13leyqouhlen Guide:95lrm/RM-4-2 4200 988 3842 3841 2019-05-04T23:37:17Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-1-4|Previous]] | [[Guide:95lrm/RM-4-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 4.2 Literals}} <span id="I2240"></span>A ''literal'' represents a value literally, that is, by means of notation suited to its kind. A literal is either a numeric_literal, a character_literal, the literal '''null''', or a string_literal. <span id="I2241"></span> == Name Resolution Rules == <span id="I2242"></span>The expected type for a literal '''null''' shall be a single access type. <span id="I2243"></span><span id="I2244"></span>For a name that consists of a character_literal, either its expected type shall be a single character type, in which case it is interpreted as a parameterless function_call that yields the corresponding value of the character type, or its expected profile shall correspond to a parameterless function with a character result type, in which case it is interpreted as the name of the corresponding parameterless function declared as part of the character type's definition (see [[Guide:95lrm/RM-3-5-1|3.5.1]]). In either case, the character_literal denotes the enumeration_literal_specification. <span id="I2245"></span>The expected type for a primary that is a string_literal shall be a single string type. == Legality Rules == A character_literal that is a name shall correspond to a defining_character_literal of the expected type, or of the result type of the expected profile. For each character of a string_literal with a given expected string type, there shall be a corresponding defining_character_literal of the component type of the expected string type. A literal null shall not be of an anonymous access type, since such types do not have a null value (see [[Guide:95lrm/RM-3-10|3.10]]). == Static Semantics == An integer literal is of type ''universal_integer''. A real literal is of type ''universal_real''. == Dynamic Semantics == <span id="I2246"></span><span id="I2247"></span><span id="I2248"></span><span id="I2249"></span>The evaluation of a numeric literal, or the literal '''null''', yields the represented value. <span id="I2250"></span>The evaluation of a string_literal that is a primary yields an array value containing the value of each character of the sequence of characters of the string_literal, as defined in [[Guide:95lrm/RM-2-6|2.6]]. The bounds of this array value are determined according to the rules for positional_array_aggregates (see [[Guide:95lrm/RM-4-3-3|4.3.3]]), except that for a null string literal, the upper bound is the predecessor of the lower bound. <span id="I2251"></span><span id="I2252"></span>For the evaluation of a string_literal of type ''T'', a check is made that the value of each character of the string_literal belongs to the component subtype of ''T''. For the evaluation of a null string literal, a check is made that its lower bound is greater than the lower bound of the base range of the index type. <span id="I2253"></span>The exception Constraint_Error is raised if either of these checks fails. == Notes == 6  Enumeration literals that are identifiers rather than character_literals follow the normal rules for identifiers when used in a name (see [[Guide:95lrm/RM-4-1|4.1]] and [[Guide:95lrm/RM-4-1-3|4.1.3]]). Character_literals used as selector_names follow the normal rules for expanded names (see [[Guide:95lrm/RM-4-1-3|4.1.3]]). == Examples == ''Examples of literals:'' <p><syntaxhighlight lang="Ada"> 3.14159_26536    --  a real literal 1_345            --  an integer literal 'A'              --  a character literal "Some Text"      --  a string literal </syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-1-4|Previous]] | [[Guide:95lrm/RM-4-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 8lqnlwz0gk37llbs6ppi1a6zfiw0gv2 Guide:95lrm/RM-4-3 4200 989 3844 3843 2019-05-04T23:37:17Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-2|Previous]] | [[Guide:95lrm/RM-4-3-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 4.3 Aggregates}} <span id="I2254"></span>An ''aggregate'' combines component values into a composite value of an array type, record type, or record extension. <span id="I2255"></span> == Syntax == <p><span></span></p> aggregate<span id="I2256"></span> ::= <span id="I2257"></span>record_aggregate | <span id="I2258"></span>extension_aggregate | <span id="I2259"></span>array_aggregate == Name Resolution Rules == <span id="I2260"></span>The expected type for an aggregate shall be a single nonlimited array type, record type, or record extension. == Legality Rules == An aggregate shall not be of a class-wide type. == Dynamic Semantics == <span id="I2261"></span>For the evaluation of an aggregate, an anonymous object is created and values for the components or ancestor part are obtained (as described in the subsequent subclause for each kind of the aggregate) and assigned into the corresponding components or ancestor part of the anonymous object. <span id="I2262"></span>Obtaining the values and the assignments occur in an arbitrary order. The value of the aggregate is the value of this object. <span id="I2263"></span><span id="I2264"></span>If an aggregate is of a tagged type, a check is made that its value belongs to the first subtype of the type. <span id="I2265"></span>Constraint_Error is raised if this check fails. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-2|Previous]] | [[Guide:95lrm/RM-4-3-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 5e4iamdcsb114h08r0cxsy8vod11cxk Guide:95lrm/RM-4-3-1 4200 990 3846 3845 2019-05-04T23:37:19Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-3|Previous]] | [[Guide:95lrm/RM-4-3-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 4.3.1 Record Aggregates}} In a record_aggregate, a value is specified for each component of the record or record extension value, using either a named or a positional association. == Syntax == <p><span></span></p> record_aggregate<span id="I2266"></span> ::= (<span id="I2267"></span>record_component_association_list) <p><span></span></p> record_component_association_list<span id="I2268"></span> ::= <span id="I2269"></span>record_component_association {, <span id="I2270"></span>record_component_association} | '''null record''' <p><span></span></p> record_component_association<span id="I2271"></span> ::= [ <span id="I2272"></span>component_choice_list => ] <span id="I2273"></span>expression <p><span></span></p> component_choice_list<span id="I2274"></span> ::= ''component_''<span id="I2275"></span>selector_name {| ''component_''<span id="I2276"></span>selector_name} | '''others''' <span id="I2277"></span>A record_component_association is a ''named component association'' if it has a component_choice_list; <span id="I2278"></span>otherwise, it is a ''positional component association''. Any positional component associations shall precede any named component associations. If there is a named association with a component_choice_list of '''others''', it shall come last. In the record_component_association_list for a record_aggregate, if there is only one association, it shall be a named association. == Name Resolution Rules == <span id="I2279"></span>The expected type for a record_aggregate shall be a single nonlimited record type or record extension. <span id="I2280"></span>For the record_component_association_list of a record_aggregate, all components of the composite value defined by the aggregate are ''needed''; for the association list of an extension_aggregate, only those components not determined by the ancestor expression or subtype are needed (see [[Guide:95lrm/RM-4-3-2|4.3.2]]). Each selector_name in a record_component_association shall denote a needed component (including possibly a discriminant). <span id="I2281"></span>The expected type for the expression of a record_component_association is the type of the ''associated'' component(s); <span id="I2282"></span>the associated component(s) are as follows: * For a positional association, the component (including possibly a discriminant) in the corresponding relative position (in the declarative region of the type), counting only the needed components; * For a named association with one or more ''component_''selector_names, the named component(s); * For a named association with the reserved word '''others''', all needed components that are not associated with some previous association. == Legality Rules == If the type of a record_aggregate is a record extension, then it shall be a descendant of a record type, through one or more record extensions (and no private extensions). If there are no components needed in a given record_component_association_list, then the reserved words '''null record''' shall appear rather than a list of record_component_associations. Each record_component_association shall have at least one associated component, and each needed component shall be associated with exactly one record_component_association. If a record_component_association has two or more associated components, all of them shall be of the same type. If the components of a variant_part are needed, then the value of a discriminant that governs the variant_part shall be given by a static expression. == Dynamic Semantics == <span id="I2283"></span>The evaluation of a record_aggregate consists of the evaluation of the record_component_association_list. <span id="I2284"></span>For the evaluation of a record_component_association_list, any per-object constraints (see [[Guide:95lrm/RM-3-8|3.8]]) for components specified in the association list are elaborated and any expressions are evaluated and converted to the subtype of the associated component. <span id="I2285"></span>Any constraint elaborations and expression evaluations (and conversions) occur in an arbitrary order, except that the expression for a discriminant is evaluated (and converted) prior to the elaboration of any per-object constraint that depends on it, which in turn occurs prior to the evaluation and conversion of the expression for the component with the per-object constraint. The expression of a record_component_association is evaluated (and converted) once for each associated component. == Notes == 7  For a record_aggregate with positional associations, expressions specifying discriminant values appear first since the known_discriminant_part is given first in the declaration of the type; they have to be in the same order as in the known_discriminant_part. == Examples == ''Example of a record aggregate with positional associations:'' <p><syntaxhighlight lang="Ada"> (4, July, 1776)                                       --  see 3.8 </syntaxhighlight></p> ''Examples of record aggregates with named associations:'' <p><syntaxhighlight lang="Ada"> (Day => 4, Month => July, Year => 1776) (Month => July, Day => 4, Year => 1776)</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> (Disk, Closed, Track => 5, Cylinder => 12)            --  see 3.8.1 (Unit => Disk, Status => Closed, Cylinder => 9, Track => 1)</syntaxhighlight></p> ''Example of component association with several choices:'' <p><syntaxhighlight lang="Ada"> (Value => 0, Succ|Pred => new Cell'(0, null, null))   --  see 3.10.1</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> --  The allocator is evaluated twice: Succ and Pred designate different cells</syntaxhighlight></p> ''Examples of record aggregates for tagged types (see [[Guide:95lrm/RM-3-9|3.9]] and [[Guide:95lrm/RM-3-9-1|3.9.1]]):'' <p><syntaxhighlight lang="Ada"> Expression'(null record) Literal'(Value => 0.0) Painted_Point'(0.0, Pi/2.0, Paint => Red)</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-3|Previous]] | [[Guide:95lrm/RM-4-3-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 7tyrz81zovt6puev9jhbsyny57ok3yi Guide:95lrm/RM-4-3-2 4200 991 3848 3847 2019-05-04T23:37:20Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-3-1|Previous]] | [[Guide:95lrm/RM-4-3-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 4.3.2 Extension Aggregates}} An extension_aggregate specifies a value for a type that is a record extension by specifying a value or subtype for an ancestor of the type, followed by associations for any components not determined by the ancestor_part. == Syntax == <p><span></span></p> extension_aggregate<span id="I2286"></span> ::= (<span id="I2287"></span>ancestor_part '''with''' <span id="I2288"></span>record_component_association_list) <p><span></span></p> ancestor_part<span id="I2289"></span> ::= <span id="I2290"></span>expression | <span id="I2291"></span>subtype_mark == Name Resolution Rules == <span id="I2292"></span>The expected type for an extension_aggregate shall be a single nonlimited type that is a record extension. <span id="I2293"></span>If the ancestor_part is an expression, it is expected to be of any nonlimited tagged type. == Legality Rules == If the ancestor_part is a subtype_mark, it shall denote a specific tagged subtype. The type of the extension_aggregate shall be derived from the type of the ancestor_part, through one or more record extensions (and no private extensions). == Static Semantics == <span id="I2294"></span>For the record_component_association_list of an extension_aggregate, the only components ''needed'' are those of the composite value defined by the aggregate that are not inherited from the type of the ancestor_part, plus any inherited discriminants if the ancestor_part is a subtype_mark that denotes an unconstrained subtype. == Dynamic Semantics == <span id="I2295"></span>For the evaluation of an extension_aggregate, the record_component_association_list is evaluated. If the ancestor_part is an expression, it is also evaluated; if the ancestor_part is a subtype_mark, the components of the value of the aggregate not given by the record_component_association_list are initialized by default as for an object of the ancestor type. Any implicit initializations or evaluations are performed in an arbitrary order, except that the expression for a discriminant is evaluated prior to any other evaluation or initialization that depends on it. <span id="I2296"></span><span id="I2297"></span>If the type of the ancestor_part has discriminants that are not inherited by the type of the extension_aggregate, then, unless the ancestor_part is a subtype_mark that denotes an unconstrained subtype, a check is made that each discriminant of the ancestor has the value specified for a corresponding discriminant, either in the record_component_association_list, or in the derived_type_definition for some ancestor of the type of the extension_aggregate. <span id="I2298"></span>Constraint_Error is raised if this check fails. == Notes == 8  If all components of the value of the extension_aggregate are determined by the ancestor_part, then the record_component_association_list is required to be simply '''null record'''. 9  If the ancestor_part is a subtype_mark, then its type can be abstract. If its type is controlled, then as the last step of evaluating the aggregate, the Initialize procedure of the ancestor type is called, unless the Initialize procedure is abstract (see [[Guide:95lrm/RM-7-6|7.6]]). == Examples == ''Examples of extension aggregates (for types defined in [[Guide:95lrm/RM-3-9-1|3.9.1]]):'' <p><syntaxhighlight lang="Ada"> Painted_Point'(Point with Red) (Point'(P) with Paint => Black)</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> (Expression with Left => 1.2, Right => 3.4) Addition'(Binop with null record)           -- presuming Binop is of type Binary_Operation</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-3-1|Previous]] | [[Guide:95lrm/RM-4-3-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} osc175cl9wsdtquevxgzvj2qxpaiijn Guide:95lrm/RM-4-3-3 4200 992 3850 3849 2019-05-04T23:37:23Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-3-2|Previous]] | [[Guide:95lrm/RM-4-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 4.3.3 Array Aggregates}} In an array_aggregate, a value is specified for each component of an array, either positionally or by its index. For a positional_array_aggregate, the components are given in increasing-index order, with a final '''others''', if any, representing any remaining components. For a named_array_aggregate, the components are identified by the values covered by the discrete_choices. == Syntax == <p><span></span></p> array_aggregate<span id="I2299"></span> ::= <span id="I2300"></span>positional_array_aggregate | <span id="I2301"></span>named_array_aggregate <p><span></span></p> positional_array_aggregate<span id="I2302"></span> ::= (<span id="I2303"></span>expression, <span id="I2304"></span>expression {, <span id="I2305"></span>expression}) | (<span id="I2306"></span>expression {, <span id="I2307"></span>expression}, '''others''' => <span id="I2308"></span>expression) <p><span></span></p> named_array_aggregate<span id="I2309"></span> ::= (<span id="I2310"></span>array_component_association {, <span id="I2311"></span>array_component_association}) <p><span></span></p> array_component_association<span id="I2312"></span> ::= <span id="I2313"></span>discrete_choice_list => <span id="I2314"></span>expression <span id="I2315"></span>An ''n-dimensional'' array_aggregate is one that is written as n levels of nested array_aggregates (or at the bottom level, equivalent string_literals). <span id="I2316"></span>For the multidimensional case (n >= 2) the array_aggregates (or equivalent string_literals) at the n-1 lower levels are called ''subaggregate''s of the enclosing n-dimensional array_aggregate. <span id="I2317"></span>The expressions of the bottom level subaggregates (or of the array_aggregate itself if one-dimensional) are called the ''array component expressions'' of the enclosing n-dimensional array_aggregate. == Name Resolution Rules == <span id="I2318"></span>The expected type for an array_aggregate (that is not a subaggregate) shall be a single nonlimited array type. <span id="I2319"></span>The component type of this array type is the expected type for each array component expression of the array_aggregate. <span id="I2320"></span>The expected type for each discrete_choice in any discrete_choice_list of a named_array_aggregate is the type of the ''corresponding index''; <span id="I2321"></span>the corresponding index for an array_aggregate that is not a subaggregate is the first index of its type; for an (n-m)-dimensional subaggregate within an array_aggregate of an n-dimensional type, the corresponding index is the index in position m+1. == Legality Rules == An array_aggregate of an n-dimensional array type shall be written as an n-dimensional array_aggregate. An '''others''' choice is allowed for an array_aggregate only if an ''applicable index constraint'' applies to the array_aggregate. <span id="I2322"></span>An applicable index constraint is a constraint provided by certain contexts where an array_aggregate is permitted that can be used to determine the bounds of the array value specified by the aggregate. Each of the following contexts (and none other) defines an applicable index constraint: * For an explicit_actual_parameter, an explicit_generic_actual_parameter, the expression of a return_statement, the initialization expression in an object_declaration, or a default_expression (for a parameter or a component), when the nominal subtype of the corresponding formal parameter, generic formal parameter, function result, object, or component is a constrained array subtype, the applicable index constraint is the constraint of the subtype; * For the expression of an assignment_statement where the name denotes an array variable, the applicable index constraint is the constraint of the array variable; * For the operand of a qualified_expression whose subtype_mark denotes a constrained array subtype, the applicable index constraint is the constraint of the subtype; * For a component expression in an aggregate, if the component's nominal subtype is a constrained array subtype, the applicable index constraint is the constraint of the subtype; * For a parenthesized expression, the applicable index constraint is that, if any, defined for the expression. The applicable index constraint ''applies'' to an array_aggregate that appears in such a context, as well as to any subaggregates thereof. In the case of an explicit_actual_parameter (or default_expression) for a call on a generic formal subprogram, no applicable index constraint is defined. The discrete_choice_list of an array_component_association is allowed to have a discrete_choice that is a nonstatic expression or that is a discrete_range that defines a nonstatic or null range, only if it is the single discrete_choice of its discrete_choice_list, and there is only one array_component_association in the array_aggregate. In a named_array_aggregate with more than one discrete_choice, no two discrete_choices are allowed to cover the same value (see [[Guide:95lrm/RM-3-8-1|3.8.1]]); if there is no '''others''' choice, the discrete_choices taken together shall exactly cover a contiguous sequence of values of the corresponding index type. A bottom level subaggregate of a multidimensional array_aggregate of a given array type is allowed to be a string_literal only if the component type of the array type is a character type; each character of such a string_literal shall correspond to a defining_character_literal of the component type. == Static Semantics == A subaggregate that is a string_literal is equivalent to one that is a positional_array_aggregate of the same length, with each expression being the character_literal for the corresponding character of the string_literal. == Dynamic Semantics == <span id="I2323"></span>The evaluation of an array_aggregate of a given array type proceeds in two steps: <p><span></span></p> :1. Any discrete_choices of this aggregate and of its subaggregates are evaluated in an arbitrary order, and converted to the corresponding index type; <span id="I2324"></span> <p><span></span></p> :2. The array component expressions of the aggregate are evaluated in an arbitrary order and their values are converted to the component subtype of the array type; an array component expression is evaluated once for each associated component. <span id="I2325"></span> <span id="I2326"></span>The bounds of the index range of an array_aggregate (including a subaggregate) are determined as follows: * For an array_aggregate with an '''others''' choice, the bounds are those of the corresponding index range from the applicable index constraint; * For a positional_array_aggregate (or equivalent string_literal) without an '''others''' choice, the lower bound is that of the corresponding index range in the applicable index constraint, if defined, or that of the corresponding index subtype, if not; in either case, the upper bound is determined from the lower bound and the number of expressions (or the length of the string_literal); * For a named_array_aggregate without an '''others''' choice, the bounds are determined by the smallest and largest index values covered by any discrete_choice_list. <span id="I2327"></span><span id="I2328"></span>For an array_aggregate, a check is made that the index range defined by its bounds is compatible with the corresponding index subtype. <span id="I2329"></span><span id="I2330"></span>For an array_aggregate with an '''others''' choice, a check is made that no expression is specified for an index value outside the bounds determined by the applicable index constraint. <span id="I2331"></span><span id="I2332"></span>For a multidimensional array_aggregate, a check is made that all subaggregates that correspond to the same index have the same bounds. <span id="I2333"></span>The exception Constraint_Error is raised if any of the above checks fail. == Notes == 10  In an array_aggregate, positional notation may only be used with two or more expressions; a single expression in parentheses is interpreted as a parenthesized_expression. A named_array_aggregate, such as (1 => X), may be used to specify an array with a single component. == Examples == ''Examples of array aggregates with positional associations:'' <p><syntaxhighlight lang="Ada"> (7, 9, 5, 1, 3, 2, 4, 8, 6, 0) Table'(5, 8, 4, 1, others => 0)  --  see 3.6 </syntaxhighlight></p> ''Examples of array aggregates with named associations:'' <p><syntaxhighlight lang="Ada"> (1 .. 5 => (1 .. 8 => 0.0))      --  two-dimensional (1 .. N => new Cell)             --  N new cells, in particular for N = 0</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Table'(2 | 4 | 10 => 1, others => 0) Schedule'(Mon .. Fri => True,  others => False)  --  see 3.6 Schedule'(Wed | Sun  => False, others => True) Vector'(1 => 2.5)                                --  single-component vector</syntaxhighlight></p> ''Examples of two-dimensional array aggregates:'' <p><syntaxhighlight lang="Ada"> -- Three aggregates for the same value of subtype Matrix(1..2,1..3) (see 3.6):</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> ((1.1, 1.2, 1.3), (2.1, 2.2, 2.3)) (1 => (1.1, 1.2, 1.3), 2 => (2.1, 2.2, 2.3)) (1 => (1 => 1.1, 2 => 1.2, 3 => 1.3), 2 => (1 => 2.1, 2 => 2.2, 3 => 2.3))</syntaxhighlight></p> ''Examples of aggregates as initial values:'' <p><syntaxhighlight lang="Ada"> A : Table := (7, 9, 5, 1, 3, 2, 4, 8, 6, 0);        -- A(1)=7, A(10)=0 B : Table := (2 | 4 | 10 => 1, others => 0);        -- B(1)=0, B(10)=1 C : constant Matrix := (1 .. 5 => (1 .. 8 => 0.0)); -- C'Last(1)=5, C'Last(2)=8</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> D : Bit_Vector(M .. N) := (M .. N => True);         -- see 3.6 E : Bit_Vector(M .. N) := (others => True); F : String(1 .. 1) := (1 => 'F');  -- a one component aggregate: same as "F";</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-3-2|Previous]] | [[Guide:95lrm/RM-4-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} kuksmtisq4k62yaqqptngeemuyguex5 Guide:95lrm/RM-4-4 4200 993 3852 3851 2019-05-04T23:37:24Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-3-3|Previous]] | [[Guide:95lrm/RM-4-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 4.4 Expressions}} <span id="I2334"></span>An ''expression'' is a formula that defines the computation or retrieval of a value. In this International Standard, the term ''expression'' refers to a construct of the syntactic category expression or of any of the other five syntactic categories defined below. <span id="I2335"></span><span id="I2336"></span><span id="I2337"></span><span id="I2338"></span><span id="I2339"></span><span id="I2340"></span><span id="I2341"></span><span id="I2342"></span><span id="I2343"></span><span id="I2344"></span><span id="I2345"></span><span id="I2346"></span><span id="I2347"></span><span id="I2348"></span><span id="I2349"></span><span id="I2350"></span><span id="I2351"></span><span id="I2352"></span><span id="I2353"></span><span id="I2354"></span><span id="I2355"></span><span id="I2356"></span><span id="I2357"></span><span id="I2358"></span><span id="I2359"></span><span id="I2360"></span><span id="I2361"></span><span id="I2362"></span><span id="I2363"></span><span id="I2364"></span><span id="I2365"></span><span id="I2366"></span><span id="I2367"></span><span id="I2368"></span><span id="I2369"></span><span id="I2370"></span><span id="I2371"></span><span id="I2372"></span><span id="I2373"></span><span id="I2374"></span><span id="I2375"></span><span id="I2376"></span><span id="I2377"></span><span id="I2378"></span><span id="I2379"></span><span id="I2380"></span><span id="I2381"></span><span id="I2382"></span><span id="I2383"></span><span id="I2384"></span><span id="I2385"></span><span id="I2386"></span><span id="I2387"></span><span id="I2388"></span><span id="I2389"></span><span id="I2390"></span><span id="I2391"></span><span id="I2392"></span><span id="I2393"></span><span id="I2394"></span><span id="I2395"></span><span id="I2396"></span><span id="I2397"></span><span id="I2398"></span><span id="I2399"></span><span id="I2400"></span><span id="I2401"></span><span id="I2402"></span><span id="I2403"></span><span id="I2404"></span><span id="I2405"></span><span id="I2406"></span> == Syntax == <p><span></span></p> expression<span id="I2407"></span> ::= <span id="I2408"></span>relation {'''and''' <span id="I2409"></span>relation}  | <span id="I2410"></span>relation {'''and''' '''then''' <span id="I2411"></span>relation} | <span id="I2412"></span>relation {'''or''' <span id="I2413"></span>relation}  | <span id="I2414"></span>relation {'''or''' '''else''' <span id="I2415"></span>relation} | <span id="I2416"></span>relation {'''xor''' <span id="I2417"></span>relation} <p><span></span></p> relation<span id="I2418"></span> ::= <span id="I2419"></span>simple_expression [<span id="I2420"></span>relational_operator <span id="I2421"></span>simple_expression] | <span id="I2422"></span>simple_expression ['''not'''] '''in''' <span id="I2423"></span>range | <span id="I2424"></span>simple_expression ['''not'''] '''in''' <span id="I2425"></span>subtype_mark <p><span></span></p> simple_expression<span id="I2426"></span> ::= [<span id="I2427"></span>unary_adding_operator] <span id="I2428"></span>term {<span id="I2429"></span>binary_adding_operator <span id="I2430"></span>term} <p><span></span></p> term<span id="I2431"></span> ::= <span id="I2432"></span>factor {<span id="I2433"></span>multiplying_operator <span id="I2434"></span>factor} <p><span></span></p> factor<span id="I2435"></span> ::= <span id="I2436"></span>primary [** <span id="I2437"></span>primary] | '''abs''' <span id="I2438"></span>primary | '''not''' <span id="I2439"></span>primary <p><span></span></p> primary<span id="I2440"></span> ::= <span id="I2441"></span>numeric_literal | '''null''' | <span id="I2442"></span>string_literal | <span id="I2443"></span>aggregate | <span id="I2444"></span>name | <span id="I2445"></span>qualified_expression | <span id="I2446"></span>allocator | (<span id="I2447"></span>expression) == Name Resolution Rules == A name used as a primary shall resolve to denote an object or a value. == Static Semantics == Each expression has a type; it specifies the computation or retrieval of a value of that type. == Dynamic Semantics == <span id="I2448"></span>The value of a primary that is a name denoting an object is the value of the object. == Implementation Permissions == <span id="I2449"></span><span id="I2450"></span><span id="I2451"></span>For the evaluation of a primary that is a name denoting an object of an unconstrained numeric subtype, if the value of the object is outside the base range of its type, the implementation may either raise Constraint_Error or return the value of the object. == Examples == ''Examples of primaries:'' <p><syntaxhighlight lang="Ada"> 4.0                --  real literal Pi                 --  named number (1 .. 10 => 0)     --  array aggregate Sum                --  variable Integer'Last       --  attribute Sine(X)            --  function call Color'(Blue)       --  qualified expression Real(M*N)          --  conversion (Line_Count + 10)  --  parenthesized expression </syntaxhighlight></p> ''Examples of expressions:'' <p><syntaxhighlight lang="Ada"> Volume                      -- primary not Destroyed               -- factor 2*Line_Count                -- term   -4.0                        -- simple expression -4.0 + A                    -- simple expression B**2 - 4.0*A*C              -- simple expression Password(1 .. 3) = "Bwv"    -- relation Count in Small_Int          -- relation Count not in Small_Int      -- relation Index = 0 or Item_Hit       -- expression (Cold and Sunny) or Warm    -- expression (parentheses are required) A**(B**C)                   -- expression (parentheses are required)</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-3-3|Previous]] | [[Guide:95lrm/RM-4-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} czwbc4og934e9a7uk3pnc1777ufzxzb Guide:95lrm/RM-4-5 4200 994 3854 3853 2019-05-04T23:37:25Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-4|Previous]] | [[Guide:95lrm/RM-4-5-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 4.5 Operators and Expression Evaluation}} <span id="I2452"></span><span id="I2453"></span>The language defines the following six categories of operators (given in order of increasing precedence). The corresponding operator_symbols, and only those, can be used as designators in declarations of functions for user-defined operators. See [[Guide:95lrm/RM-6-6|6.6]], ''[[Guide:95lrm/RM-6-6|Overloading of Operators]]''. == Syntax == <p><span></span></p> logical_operator<span id="I2454"></span> ::=   '''and''' | '''or'''  | '''xor''' <p><span></span></p> relational_operator<span id="I2455"></span> ::=   =   | /=  | <   | <= | > | >= <p><span></span></p> binary_adding_operator<span id="I2456"></span> ::=   +   | -   | & <p><span></span></p> unary_adding_operator<span id="I2457"></span> ::=   +   | - <p><span></span></p> multiplying_operator<span id="I2458"></span> ::=   *   | /   | '''mod''' | '''rem''' <p><span></span></p> highest_precedence_operator<span id="I2459"></span> ::=   **  | '''abs''' | '''not''' == Static Semantics == For a sequence of operators of the same precedence level, the operators are associated with their operands in textual order from left to right. Parentheses can be used to impose specific associations. <span id="I2460"></span><span id="I2461"></span>For each form of type definition, certain of the above operators are ''predefined''; that is, they are implicitly declared immediately after the type definition. <span id="I2462"></span><span id="I2463"></span><span id="I2464"></span><span id="I2465"></span>For each such implicit operator declaration, the parameters are called Left and Right for ''binary'' operators; the single parameter is called Right for ''unary'' operators. An expression of the form X op Y, where op is a binary operator, is equivalent to a function_call of the form "op"(X, Y). An expression of the form op Y, where op is a unary operator, is equivalent to a function_call of the form "op"(Y). The predefined operators and their effects are described in subclauses [[Guide:95lrm/RM-4-5-1|4.5.1]] through [[Guide:95lrm/RM-4-5-6|4.5.6]]. == Dynamic Semantics == <span id="I2466"></span>The predefined operations on integer types either yield the mathematically correct result or raise the exception Constraint_Error. For implementations that support the Numerics Annex, the predefined operations on real types yield results whose accuracy is defined in [[Guide:95lrm/RM-G|Annex G]], or raise the exception Constraint_Error. == Implementation Requirements == <span id="I2467"></span>The implementation of a predefined operator that delivers a result of an integer or fixed point type may raise Constraint_Error only if the result is outside the base range of the result type. <span id="I2468"></span>The implementation of a predefined operator that delivers a result of a floating point type may raise Constraint_Error only if the result is outside the safe range of the result type. == Implementation Permissions == For a sequence of predefined operators of the same precedence level (and in the absence of parentheses imposing a specific association), an implementation may impose any association of the operators with operands so long as the result produced is an allowed result for the left-to-right association, but ignoring the potential for failure of language-defined checks in either the left-to-right or chosen order of association. == Notes == 11  The two operands of an expression of the form X op Y, where op is a binary operator, are evaluated in an arbitrary order, as for any function_call (see [[Guide:95lrm/RM-6-4|6.4]]). == Examples == ''Examples of precedence:'' <p><syntaxhighlight lang="Ada"> not Sunny or Warm    --  same as (not Sunny) or Warm X > 4.0 and Y > 0.0  --  same as (X > 4.0) and (Y > 0.0)</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -4.0*A**2            --  same as -(4.0 * (A**2)) abs(1 + A) + B       --  same as (abs (1 + A)) + B Y**(-3)              --  parentheses are necessary A / B * C            --  same as (A/B)*C A + (B + C)          --  evaluate B + C before adding it to A </syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-4|Previous]] | [[Guide:95lrm/RM-4-5-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 45n88dq1rsa4sg1c7dj4rwb726hzrds Guide:95lrm/RM-4-5-1 4200 995 3856 3855 2019-05-04T23:37:26Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-5|Previous]] | [[Guide:95lrm/RM-4-5-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 4.5.1 Logical Operators and Short-circuit Control Forms}} == Name Resolution Rules == <span id="I2469"></span><span id="I2470"></span><span id="I2471"></span>An expression consisting of two relations connected by '''and then''' or '''or else''' (a ''short-circuit control form'') shall resolve to be of some boolean type; <span id="I2472"></span>the expected type for both relations is that same boolean type. == Static Semantics == <span id="I2473"></span><span id="I2474"></span><span id="I2475"></span><span id="I2476"></span><span id="I2477"></span><span id="I2478"></span><span id="I2479"></span><span id="I2480"></span>The following logical operators are predefined for every boolean type ''T'', for every modular type ''T'', and for every one-dimensional array type ''T'' whose component type is a boolean type: <span id="I2481"></span> <p><syntaxhighlight lang="Ada"> function "and" (Left, Right : T) return T function "or" (Left, Right : T) return T function "xor" (Left, Right : T) return T</syntaxhighlight></p> For boolean types, the predefined logical operators '''and''', '''or''', and '''xor''' perform the conventional operations of conjunction, inclusive disjunction, and exclusive disjunction, respectively. For modular types, the predefined logical operators are defined on a bit-by-bit basis, using the binary representation of the value of the operands to yield a binary representation for the result, where zero represents False and one represents True. If this result is outside the base range of the type, a final subtraction by the modulus is performed to bring the result into the base range of the type. The logical operators on arrays are performed on a component-by-component basis on matching components (as for equality -- see [[Guide:95lrm/RM-4-5-2|4.5.2]]), using the predefined logical operator for the component type. The bounds of the resulting array are those of the left operand. == Dynamic Semantics == <span id="I2482"></span>The short-circuit control forms '''and then''' and '''or else''' deliver the same result as the corresponding predefined '''and''' and '''or''' operators for boolean types, except that the left operand is always evaluated first, and the right operand is not evaluated if the value of the left operand determines the result. <span id="I2483"></span><span id="I2484"></span>For the logical operators on arrays, a check is made that for each component of the left operand there is a matching component of the right operand, and vice versa. <span id="I2485"></span><span id="I2486"></span>Also, a check is made that each component of the result belongs to the component subtype. <span id="I2487"></span>The exception Constraint_Error is raised if either of the above checks fails. == Notes == 12  The conventional meaning of the logical operators is given by the following truth table: <p><span></span></p> A   B (A '''and''' B) (A '''or''' B) (A '''xor''' B) True   True   True   True   False True   False  False  True   True False  True   False  True   True False  False  False  False  False == Examples == ''Examples of logical operators:'' <p><syntaxhighlight lang="Ada"> Sunny or Warm Filter(1 .. 10) and Filter(15 .. 24)   --   see 3.6.1 </syntaxhighlight></p> ''Examples of short-circuit control forms:'' <p><syntaxhighlight lang="Ada"> Next_Car.Owner /= null and then Next_Car.Owner.Age > 25   --   see 3.10.1 N = 0 or else A(N) = Hit_Value</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-5|Previous]] | [[Guide:95lrm/RM-4-5-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 0x2r8wosyn2r2szw8cot8gq6dz61wdo Guide:95lrm/RM-4-5-2 4200 996 3858 3857 2019-05-04T23:37:29Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-5-1|Previous]] | [[Guide:95lrm/RM-4-5-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 4.5.2 Relational Operators and Membership Tests}} <span id="I2488"></span><span id="I2489"></span><span id="I2490"></span><span id="I2491"></span><span id="I2492"></span>The ''equality operators'' = (equals) and /= (not equals) are predefined for nonlimited types. <span id="I2493"></span><span id="I2494"></span>The other relational_operators are the ''ordering operators'' < (less than), <= (less than or equal), > (greater than), and >= (greater than or equal). <span id="I2495"></span><span id="I2496"></span><span id="I2497"></span><span id="I2498"></span><span id="I2499"></span><span id="I2500"></span><span id="I2501"></span><span id="I2502"></span><span id="I2503"></span><span id="I2504"></span><span id="I2505"></span><span id="I2506"></span><span id="I2507"></span><span id="I2508"></span><span id="I2509"></span><span id="I2510"></span><span id="I2511"></span><span id="I2512"></span><span id="I2513"></span><span id="I2514"></span><span id="I2515"></span><span id="I2516"></span><span id="I2517"></span><span id="I2518"></span><span id="I2519"></span>The ordering operators are predefined for scalar types, and for ''discrete array types'', that is, one-dimensional array types whose components are of a discrete type. <span id="I2520"></span><span id="I2521"></span><span id="I2522"></span>A ''membership test'', using '''in''' or '''not in''', determines whether or not a value belongs to a given subtype or range, or has a tag that identifies a type that is covered by a given type. Membership tests are allowed for all types. == Name Resolution Rules == <span id="I2523"></span><span id="I2524"></span>The ''tested type'' of a membership test is the type of the range or the type determined by the subtype_mark. If the tested type is tagged, then the simple_expression shall resolve to be of a type that covers or is covered by the tested type; if untagged, the expected type for the simple_expression is the tested type. == Legality Rules == For a membership test, if the simple_expression is of a tagged class-wide type, then the tested type shall be (visibly) tagged. == Static Semantics == The result type of a membership test is the predefined type Boolean. The equality operators are predefined for every specific type ''T'' that is not limited, and not an anonymous access type, with the following specifications: <p><syntaxhighlight lang="Ada"> function "=" (Left, Right : T) return Boolean function "/=" (Left, Right : T) return Boolean</syntaxhighlight></p> The ordering operators are predefined for every specific scalar type ''T'', and for every discrete array type ''T'', with the following specifications: <p><syntaxhighlight lang="Ada"> function "<" (Left, Right : T) return Boolean function "<=" (Left, Right : T) return Boolean function ">" (Left, Right : T) return Boolean function ">=" (Left, Right : T) return Boolean</syntaxhighlight></p> == Dynamic Semantics == For discrete types, the predefined relational operators are defined in terms of corresponding mathematical operations on the position numbers of the values of the operands. For real types, the predefined relational operators are defined in terms of the corresponding mathematical operations on the values of the operands, subject to the accuracy of the type. Two access-to-object values are equal if they designate the same object, or if both are equal to the null value of the access type. Two access-to-subprogram values are equal if they are the result of the same evaluation of an Access attribute_reference, or if both are equal to the null value of the access type. Two access-to-subprogram values are unequal if they designate different subprograms. <span id="I2525"></span>It is unspecified whether two access values that designate the same subprogram but are the result of distinct evaluations of Access attribute_references are equal or unequal. <span id="I2526"></span>For a type extension, predefined equality is defined in terms of the primitive (possibly user-defined) equals operator of the parent type and of any tagged components of the extension part, and predefined equality for any other components not inherited from the parent type. For a private type, if its full type is tagged, predefined equality is defined in terms of the primitive equals operator of the full type; if the full type is untagged, predefined equality for the private type is that of its full type. <span id="I2527"></span>For other composite types, the predefined equality operators (and certain other predefined operations on composite types -- see [[Guide:95lrm/RM-4-5-1|4.5.1]] and [[Guide:95lrm/RM-4-6|4.6]]) are defined in terms of the corresponding operation on ''matching components'', defined as follows: * For two composite objects or values of the same non-array type, matching components are those that correspond to the same component_declaration or discriminant_specification; * For two one-dimensional arrays of the same type, matching components are those (if any) whose index values match in the following sense: the lower bounds of the index ranges are defined to match, and the successors of matching indices are defined to match; * For two multidimensional arrays of the same type, matching components are those whose index values match in successive index positions. The analogous definitions apply if the types of the two objects or values are convertible, rather than being the same. Given the above definition of matching components, the result of the predefined equals operator for composite types (other than for those composite types covered earlier) is defined as follows: * If there are no components, the result is defined to be True; * If there are unmatched components, the result is defined to be False; * Otherwise, the result is defined in terms of the primitive equals operator for any matching tagged components, and the predefined equals for any matching untagged components. <div>For any composite type, the order in which "=" is called for components is unspecified. Furthermore, if the result can be determined before calling "=" on some components, it is unspecified whether "=" is called on those components.<span id="I2528"></span></div> The predefined "/=" operator gives the complementary result to the predefined "=" operator. <span id="I2529"></span>For a discrete array type, the predefined ordering operators correspond to ''lexicographic order'' using the predefined order relation of the component type: A null array is lexicographically less than any array having at least one component. In the case of nonnull arrays, the left operand is lexicographically less than the right operand if the first component of the left operand is less than that of the right; otherwise the left operand is lexicographically less than the right operand only if their first components are equal and the tail of the left operand is lexicographically less than that of the right (the ''tail'' consists of the remaining components beyond the first and can be null). <span id="I2530"></span>For the evaluation of a membership test, the simple_expression and the range (if any) are evaluated in an arbitrary order. A membership test using '''in''' yields the result True if: * The tested type is scalar, and the value of the simple_expression belongs to the given range, or the range of the named subtype; or * The tested type is not scalar, and the value of the simple_expression satisfies any constraints of the named subtype, and, if the type of the simple_expression is class-wide, the value has a tag that identifies a type covered by the tested type. Otherwise the test yields the result False. A membership test using '''not in''' gives the complementary result to the corresponding membership test using '''in'''. == Implementation Requirements == <div>For all nonlimited types declared in language-defined packages, the "=" and "/=" operators of the type shall behave as if they were the predefined equality operators for the purposes of the equality of composite types and generic formal types.</div> == Notes == 13  No exception is ever raised by a membership test, by a predefined ordering operator, or by a predefined equality operator for an elementary type, but an exception can be raised by the evaluation of the operands. A predefined equality operator for a composite type can only raise an exception if the type has a tagged part whose primitive equals operator propagates an exception. 14  If a composite type has components that depend on discriminants, two values of this type have matching components if and only if their discriminants are equal. Two nonnull arrays have matching components if and only if the length of each dimension is the same for both. == Examples == ''Examples of expressions involving relational operators and membership tests:'' <p><syntaxhighlight lang="Ada"> X /= Y</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> "" < "A" and "A" < "Aa"     --  True "Aa" < "B" and "A" < "A  "  --  True</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> My_Car = null               -- true if My_Car has been set to null (see 3.10.1) My_Car = Your_Car           -- true if we both share the same car My_Car.all = Your_Car.all   -- true if the two cars are identical</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> N not in 1 .. 10            -- range membership test Today in Mon .. Fri         -- range membership test Today in Weekday            -- subtype membership test (see 3.5.1) Archive in Disk_Unit        -- subtype membership test (see 3.8.1) Tree.all in Addition'Class  -- class membership test (see 3.9.1)</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-5-1|Previous]] | [[Guide:95lrm/RM-4-5-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} hsdvzpi7roo376m0ufwja1v9kwo35hm Guide:95lrm/RM-4-5-3 4200 997 3860 3859 2019-05-04T23:37:31Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-5-2|Previous]] | [[Guide:95lrm/RM-4-5-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 4.5.3 Binary Adding Operators}} == Static Semantics == <span id="I2531"></span><span id="I2532"></span><span id="I2533"></span><span id="I2534"></span><span id="I2535"></span><span id="I2536"></span><span id="I2537"></span><span id="I2538"></span><span id="I2539"></span><span id="I2540"></span>The binary adding operators + (addition) and - (subtraction) are predefined for every specific numeric type ''T'' with their conventional meaning. They have the following specifications: <p><syntaxhighlight lang="Ada"> function "+"(Left, Right : T) return T function "-"(Left, Right : T) return T</syntaxhighlight></p> <span id="I2541"></span><span id="I2542"></span><span id="I2543"></span><span id="I2544"></span><span id="I2545"></span><span id="I2546"></span><span id="I2547"></span>The concatenation operators & are predefined for every nonlimited, one-dimensional array type ''T'' with component type ''C''. They have the following specifications: <p><syntaxhighlight lang="Ada"> function "&"(Left : T; Right : T) return T function "&"(Left : T; Right : C) return T function "&"(Left : C; Right : T) return T function "&"(Left : C; Right : C) return T</syntaxhighlight></p> == Dynamic Semantics == <span id="I2548"></span>For the evaluation of a concatenation with result type ''T'', if both operands are of type ''T'', the result of the concatenation is a one-dimensional array whose length is the sum of the lengths of its operands, and whose components comprise the components of the left operand followed by the components of the right operand. If the left operand is a null array, the result of the concatenation is the right operand. Otherwise, the lower bound of the result is determined as follows: * If the ultimate ancestor of the array type was defined by a constrained_array_definition, then the lower bound of the result is that of the index subtype; * If the ultimate ancestor of the array type was defined by an unconstrained_array_definition, then the lower bound of the result is that of the left operand. The upper bound is determined by the lower bound and the length. <span id="I2549"></span><span id="I2550"></span>A check is made that the upper bound of the result of the concatenation belongs to the range of the index subtype, unless the result is a null array. <span id="I2551"></span>Constraint_Error is raised if this check fails. If either operand is of the component type ''C'', the result of the concatenation is given by the above rules, using in place of such an operand an array having this operand as its only component (converted to the component subtype) and having the lower bound of the index subtype of the array type as its lower bound. <span id="I2552"></span> <span id="I2553"></span>The result of a concatenation is defined in terms of an assignment to an anonymous object, as for any function call (see [[Guide:95lrm/RM-6-5|6.5]]). == Notes == 15  As for all predefined operators on modular types, the binary adding operators + and - on modular types include a final reduction modulo the modulus if the result is outside the base range of the type. == Examples == ''Examples of expressions involving binary adding operators:'' <p><syntaxhighlight lang="Ada"> Z + 0.1      --  Z has to be of a real type </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> "A" & "BCD"  --  concatenation of two string literals 'A' & "BCD"  --  concatenation of a character literal and a string literal 'A' & 'A'    --  concatenation of two character literals </syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-5-2|Previous]] | [[Guide:95lrm/RM-4-5-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} lo4wa60dvbmoy6wx600upu5e7kwozsk Guide:95lrm/RM-4-5-4 4200 998 3862 3861 2019-05-04T23:37:32Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-5-3|Previous]] | [[Guide:95lrm/RM-4-5-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 4.5.4 Unary Adding Operators}} == Static Semantics == <span id="I2554"></span><span id="I2555"></span><span id="I2556"></span><span id="I2557"></span><span id="I2558"></span><span id="I2559"></span><span id="I2560"></span><span id="I2561"></span><span id="I2562"></span><span id="I2563"></span>The unary adding operators + (identity) and - (negation) are predefined for every specific numeric type ''T'' with their conventional meaning. They have the following specifications: <p><syntaxhighlight lang="Ada"> function "+"(Right : T) return T function "-"(Right : T) return T</syntaxhighlight></p> == Notes == 16  For modular integer types, the unary adding operator -, when given a nonzero operand, returns the result of subtracting the value of the operand from the modulus; for a zero operand, the result is zero. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-5-3|Previous]] | [[Guide:95lrm/RM-4-5-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} pyz2kalm14hq34qv11tjtxqdpx0lb36 Guide:95lrm/RM-4-5-5 4200 999 3864 3863 2019-05-04T23:37:37Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-5-4|Previous]] | [[Guide:95lrm/RM-4-5-6|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 4.5.5 Multiplying Operators}} == Static Semantics == <span id="I2564"></span><span id="I2565"></span><span id="I2566"></span><span id="I2567"></span><span id="I2568"></span><span id="I2569"></span><span id="I2570"></span><span id="I2571"></span><span id="I2572"></span><span id="I2573"></span><span id="I2574"></span><span id="I2575"></span><span id="I2576"></span><span id="I2577"></span><span id="I2578"></span><span id="I2579"></span>The multiplying operators * (multiplication), / (division), '''mod''' (modulus), and '''rem''' (remainder) are predefined for every specific integer type ''T'': <p><syntaxhighlight lang="Ada"> function "*"  (Left, Right : T) return T function "/"  (Left, Right : T) return T function "mod"(Left, Right : T) return T function "rem"(Left, Right : T) return T</syntaxhighlight></p> Signed integer multiplication has its conventional meaning. Signed integer division and remainder are defined by the relation: <p><syntaxhighlight lang="Ada"> A = (A/B)*B + (A rem B)</syntaxhighlight></p> where (A '''rem''' B) has the sign of A and an absolute value less than the absolute value of B. Signed integer division satisfies the identity: <p><syntaxhighlight lang="Ada"> (-A)/B = -(A/B) = A/(-B)</syntaxhighlight></p> The signed integer modulus operator is defined such that the result of A '''mod''' B has the sign of B and an absolute value less than the absolute value of B; in addition, for some signed integer value N, this result satisfies the relation: <p><syntaxhighlight lang="Ada"> A = B*N + (A mod B)</syntaxhighlight></p> The multiplying operators on modular types are defined in terms of the corresponding signed integer operators, followed by a reduction modulo the modulus if the result is outside the base range of the type (which is only possible for the "*" operator). Multiplication and division operators are predefined for every specific floating point type ''T'': <p><syntaxhighlight lang="Ada"> function "*"(Left, Right : T) return T function "/"(Left, Right : T) return T</syntaxhighlight></p> The following multiplication and division operators, with an operand of the predefined type Integer, are predefined for every specific fixed point type ''T'': <p><syntaxhighlight lang="Ada"> function "*"(Left : T; Right : Integer) return T function "*"(Left : Integer; Right : T) return T function "/"(Left : T; Right : Integer) return T</syntaxhighlight></p> All of the above multiplying operators are usable with an operand of an appropriate universal numeric type. The following additional multiplying operators for ''root_real'' are predefined, and are usable when both operands are of an appropriate universal or root numeric type, and the result is allowed to be of type ''root_real'', as in a number_declaration: <p><syntaxhighlight lang="Ada"> function "*"(Left, Right : root_real) return root_real function "/"(Left, Right : root_real) return root_real</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> function "*"(Left : root_real; Right : root_integer) return root_real function "*"(Left : root_integer; Right : root_real) return root_real function "/"(Left : root_real; Right : root_integer) return root_real</syntaxhighlight></p> Multiplication and division between any two fixed point types are provided by the following two predefined operators: <p><syntaxhighlight lang="Ada"> function "*"(Left, Right : universal_fixed) return universal_fixed function "/"(Left, Right : universal_fixed) return universal_fixed</syntaxhighlight></p> == Legality Rules == The above two fixed-fixed multiplying operators shall not be used in a context where the expected type for the result is itself ''universal_fixed'' -- the context has to identify some other numeric type to which the result is to be converted, either explicitly or implicitly. == Dynamic Semantics == The multiplication and division operators for real types have their conventional meaning. For floating point types, the accuracy of the result is determined by the precision of the result type. For decimal fixed point types, the result is truncated toward zero if the mathematical result is between two multiples of the ''small'' of the specific result type (possibly determined by context); for ordinary fixed point types, if the mathematical result is between two multiples of the ''small'', it is unspecified which of the two is the result. <span id="I2580"></span> <span id="I2581"></span><span id="I2582"></span><span id="I2583"></span>The exception Constraint_Error is raised by integer division, '''rem''', and '''mod''' if the right operand is zero. Similarly, for a real type ''T'' with ''T'''Machine_Overflows True, division by zero raises Constraint_Error. == Notes == 17  For positive A and B, A/B is the quotient and A '''rem''' B is the remainder when A is divided by B. The following relations are satisfied by the rem operator: <p><syntaxhighlight lang="Ada"> A  rem (-B) =   A rem B (-A) rem   B  = -(A rem B)</syntaxhighlight></p> 18  For any signed integer K, the following identity holds: <p><syntaxhighlight lang="Ada"> A mod B   =   (A + K*B) mod B</syntaxhighlight></p> The relations between signed integer division, remainder, and modulus are illustrated by the following table: <p><syntaxhighlight lang="Ada"> A      B   A/B   A rem B  A mod B     A     B    A/B   A rem B   A mod B</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> 10     5    2       0        0       -10    5    -2       0         0 11     5    2       1        1       -11    5    -2      -1         4 12     5    2       2        2       -12    5    -2      -2         3 13     5    2       3        3       -13    5    -2      -3         2 14     5    2       4        4       -14    5    -2      -4         1</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> A      B   A/B   A rem B  A mod B     A     B    A/B   A rem B   A mod B 10    -5   -2       0        0       -10   -5     2       0         0 11    -5   -2       1       -4       -11   -5     2      -1        -1 12    -5   -2       2       -3       -12   -5     2      -2        -2 13    -5   -2       3       -2       -13   -5     2      -3        -3 14    -5   -2       4       -1       -14   -5     2      -4        -4</syntaxhighlight></p> == Examples == ''Examples of expressions involving multiplying operators:'' <p><syntaxhighlight lang="Ada"> I : Integer := 1; J : Integer := 2; K : Integer := 3;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> X : Real := 1.0;                      --     see 3.5.7 Y : Real := 2.0;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> F : Fraction := 0.25;                 --     see 3.5.9 G : Fraction := 0.5;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Expression          Value        Result Type I*J                 2            same as I and J, that is, Integer K/J                 1            same as K and J, that is, Integer K mod J             1            same as K and J, that is, Integer X/Y                 0.5          same as X and Y, that is, Real F/2                 0.125        same as F, that is, Fraction 3*F                 0.75         same as F, that is, Fraction 0.75*G              0.375        universal_fixed, implicitly convertible                               to any fixed point type Fraction(F*G)       0.125        Fraction, as stated by the conversion Real(J)*Y           4.0          Real, the type of both operands after                               conversion of J</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-5-4|Previous]] | [[Guide:95lrm/RM-4-5-6|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 48aifxjfaijfwwc3vo965yrdcsyrkxs Guide:95lrm/RM-4-5-6 4200 1000 3866 3865 2019-05-04T23:37:41Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-5-5|Previous]] | [[Guide:95lrm/RM-4-6|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 4.5.6 Highest Precedence Operators}} == Static Semantics == <span id="I2584"></span><span id="I2585"></span><span id="I2586"></span><span id="I2587"></span><span id="I2588"></span>The highest precedence unary operator '''abs''' (absolute value) is predefined for every specific numeric type ''T'', with the following specification: <p><syntaxhighlight lang="Ada">function "abs"(Right : T) return T</syntaxhighlight></p> <span id="I2589"></span><span id="I2590"></span><span id="I2591"></span>The highest precedence unary operator '''not''' (logical negation) is predefined for every boolean type ''T'', every modular type ''T'', and for every one-dimensional array type ''T'' whose components are of a boolean type, with the following specification: <p><syntaxhighlight lang="Ada">function "not"(Right : T) return T</syntaxhighlight></p> The result of the operator '''not''' for a modular type is defined as the difference between the high bound of the base range of the type and the value of the operand. For a binary modulus, this corresponds to a bit-wise complement of the binary representation of the value of the operand. The operator '''not''' that applies to a one-dimensional array of boolean components yields a one-dimensional boolean array with the same bounds; each component of the result is obtained by logical negation of the corresponding component of the operand (that is, the component that has the same index value). <span id="I2592"></span><span id="I2593"></span><span id="I2594"></span>A check is made that each component of the result belongs to the component subtype; the exception Constraint_Error is raised if this check fails. <span id="I2595"></span><span id="I2596"></span><span id="I2597"></span><span id="I2598"></span>The highest precedence ''exponentiation'' operator ** is predefined for every specific integer type ''T'' with the following specification: <p><syntaxhighlight lang="Ada">function "**"(Left : T; Right : Natural) return T</syntaxhighlight></p> Exponentiation is also predefined for every specific floating point type as well as ''root_real'', with the following specification (where ''T'' is ''root_real'' or the floating point type): <p><syntaxhighlight lang="Ada">function "**"(Left : T; Right : Integer'Base) return T</syntaxhighlight></p> <span id="I2599"></span>The right operand of an exponentiation is the ''exponent''. The expression X**N with the value of the exponent N positive is equivalent to the expression X*X*...X (with N-1 multiplications) except that the multiplications are associated in an arbitrary order. With N equal to zero, the result is one. With the value of N negative (only defined for a floating point operand), the result is the reciprocal of the result using the absolute value of N as the exponent. == Implementation Permissions == <span id="I2600"></span>The implementation of exponentiation for the case of a negative exponent is allowed to raise Constraint_Error if the intermediate result of the repeated multiplications is outside the safe range of the type, even though the final result (after taking the reciprocal) would not be. (The best machine approximation to the final result in this case would generally be 0.0.) == Notes == 19  <span id="I2601"></span><span id="I2602"></span>As implied by the specification given above for exponentiation of an integer type, a check is made that the exponent is not negative. <span id="I2603"></span>Constraint_Error is raised if this check fails. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-5-5|Previous]] | [[Guide:95lrm/RM-4-6|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} klkg410lkgq7lq5wg1sxjn9it1iirfo Guide:95lrm/RM-4-6 4200 1001 3868 3867 2019-05-04T23:37:43Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-5-6|Previous]] | [[Guide:95lrm/RM-4-7|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 4.6 Type Conversions}} Explicit type conversions, both value conversions and view conversions, are allowed between closely related types as defined below. This clause also defines rules for value and view conversions to a particular subtype of a type, both explicit ones and those implicit in other constructs. <span id="I2604"></span><span id="I2605"></span><span id="I2606"></span><span id="I2607"></span><span id="I2608"></span><span id="I2609"></span> == Syntax == <p><span></span></p> type_conversion<span id="I2610"></span> ::= <span id="I2611"></span>subtype_mark(<span id="I2612"></span>expression)<br />| <span id="I2613"></span>subtype_mark(<span id="I2614"></span>name) <span id="I2615"></span>The ''target subtype'' of a type_conversion is the subtype denoted by the subtype_mark. <span id="I2616"></span>The ''operand'' of a type_conversion is the expression or name within the parentheses; <span id="I2617"></span>its type is the ''operand type''. <span id="I2618"></span>One type is ''convertible'' to a second type if a type_conversion with the first type as operand type and the second type as target type is legal according to the rules of this clause. Two types are convertible if each is convertible to the other. <span id="I2619"></span><span id="I2620"></span>A type_conversion whose operand is the name of an object is called a ''view conversion'' if both its target type and operand type are tagged, or if it appears as an actual parameter of mode '''out''' or '''in out'''; <span id="I2621"></span><span id="I2622"></span>other type_conversions are called ''value conversions''. <span id="I2623"></span> == Name Resolution Rules == <span id="I2624"></span>The operand of a type_conversion is expected to be of any type. The operand of a view conversion is interpreted only as a name; the operand of a value conversion is interpreted as an expression. == Legality Rules == <span id="I2625"></span><span id="I2626"></span>If the target type is a numeric type, then the operand type shall be a numeric type. <span id="I2627"></span><span id="I2628"></span>If the target type is an array type, then the operand type shall be an array type. Further: * The types shall have the same dimensionality; * Corresponding index types shall be convertible; <span id="I2629"></span> * The component subtypes shall statically match; and <span id="I2630"></span> <div> * In a view conversion, the target type and the operand type shall both or neither have aliased components.</div> <span id="I2631"></span><span id="I2632"></span>If the target type is a general access type, then the operand type shall be an access-to-object type. Further: * If the target type is an access-to-variable type, then the operand type shall be an access-to-variable type; * If the target designated type is tagged, then the operand designated type shall be convertible to the target designated type; <span id="I2633"></span> * If the target designated type is not tagged, then the designated types shall be the same, and either the designated subtypes shall statically match or the target designated subtype shall be discriminated and unconstrained; and <span id="I2634"></span> * <span id="I2635"></span>The accessibility level of the operand type shall not be statically deeper than that of the target type. <span id="I2636"></span>In addition to the places where Legality Rules normally apply (see [[Guide:95lrm/RM-12-3|12.3]]), this rule applies also in the private part of an instance of a generic unit. <span id="I2637"></span><span id="I2638"></span>If the target type is an access-to-subprogram type, then the operand type shall be an access-to-subprogram type. Further: * The designated profiles shall be subtype-conformant. <span id="I2639"></span> * <span id="I2640"></span>The accessibility level of the operand type shall not be statically deeper than that of the target type. <span id="I2641"></span>In addition to the places where Legality Rules normally apply (see [[Guide:95lrm/RM-12-3|12.3]]), this rule applies also in the private part of an instance of a generic unit. If the operand type is declared within a generic body, the target type shall be declared within the generic body. <span id="I2642"></span><span id="I2643"></span><span id="I2644"></span><span id="I2645"></span>If the target type is not included in any of the above four cases, there shall be a type that is an ancestor of both the target type and the operand type. Further, if the target type is tagged, then either: * The operand type shall be covered by or descended from the target type; or * The operand type shall be a class-wide type that covers the target type. In a view conversion for an untagged type, the target type shall be convertible (back) to the operand type. == Static Semantics == A type_conversion that is a value conversion denotes the value that is the result of converting the value of the operand to the target subtype. A type_conversion that is a view conversion denotes a view of the object denoted by the operand. This view is a variable of the target type if the operand denotes a variable; otherwise it is a constant of the target type. <span id="I2646"></span>The nominal subtype of a type_conversion is its target subtype. == Dynamic Semantics == <span id="I2647"></span><span id="I2648"></span><span id="I2649"></span>For the evaluation of a type_conversion that is a value conversion, the operand is evaluated, and then the value of the operand is ''converted'' to a ''corresponding'' value of the target type, if any. <span id="I2650"></span><span id="I2651"></span><span id="I2652"></span>If there is no value of the target type that corresponds to the operand value, Constraint_Error is raised; this can only happen on conversion to a modular type, and only when the operand value is outside the base range of the modular type. Additional rules follow: * <span id="I2653"></span><span id="I2654"></span>Numeric Type Conversion <p><span></span></p> :* If the target and the operand types are both integer types, then the result is the value of the target type that corresponds to the same mathematical integer as the operand. <p><span></span></p> :* If the target type is a decimal fixed point type, then the result is truncated (toward 0) if the value of the operand is not a multiple of the ''small'' of the target type. <p><span></span></p> :* <span id="I2655"></span>If the target type is some other real type, then the result is within the accuracy of the target type (see [[Guide:95lrm/RM-G-2|G.2]], ''[[Guide:95lrm/RM-G-2|Numeric Performance Requirements]]'', for implementations that support the Numerics Annex). <p><span></span></p> :* If the target type is an integer type and the operand type is real, the result is rounded to the nearest integer (away from zero if exactly halfway between two integers). * <span id="I2656"></span><span id="I2657"></span>Enumeration Type Conversion <p><span></span></p> :* The result is the value of the target type with the same position number as that of the operand value. * <span id="I2658"></span><span id="I2659"></span>Array Type Conversion <p><span></span></p> :* <span id="I2660"></span><span id="I2661"></span>If the target subtype is a constrained array subtype, then a check is made that the length of each dimension of the value of the operand equals the length of the corresponding dimension of the target subtype. The bounds of the result are those of the target subtype. <p><span></span></p> :* <span id="I2662"></span><span id="I2663"></span>If the target subtype is an unconstrained array subtype, then the bounds of the result are obtained by converting each bound of the value of the operand to the corresponding index type of the target type. <span id="I2664"></span>For each nonnull index range, a check is made that the bounds of the range belong to the corresponding index subtype. <p><span></span></p> :* In either array case, the value of each component of the result is that of the matching component of the operand value (see [[Guide:95lrm/RM-4-5-2|4.5.2]]). * <span id="I2665"></span><span id="I2666"></span>Composite (Non-Array) Type Conversion <p><span></span></p> :* The value of each nondiscriminant component of the result is that of the matching component of the operand value. <p><span></span></p> :* The tag of the result is that of the operand. <span id="I2667"></span><span id="I2668"></span>If the operand type is class-wide, a check is made that the tag of the operand identifies a (specific) type that is covered by or descended from the target type. <p><span></span></p> :* For each discriminant of the target type that corresponds to a discriminant of the operand type, its value is that of the corresponding discriminant of the operand value; <span id="I2669"></span><span id="I2670"></span>if it corresponds to more than one discriminant of the operand type, a check is made that all these discriminants are equal in the operand value. <p><span></span></p> :* For each discriminant of the target type that corresponds to a discriminant that is specified by the derived_type_definition for some ancestor of the operand type (or if class-wide, some ancestor of the specific type identified by the tag of the operand), its value in the result is that specified by the derived_type_definition. <p><span></span></p> :* <span id="I2671"></span><span id="I2672"></span>For each discriminant of the operand type that corresponds to a discriminant that is specified by the derived_type_definition for some ancestor of the target type, a check is made that in the operand value it equals the value specified for it. <p><span></span></p> :* <span id="I2673"></span><span id="I2674"></span>For each discriminant of the result, a check is made that its value belongs to its subtype. * <span id="I2675"></span><span id="I2676"></span>Access Type Conversion <p><span></span></p> :* For an access-to-object type, a check is made that the accessibility level of the operand type is not deeper than that of the target type. <span id="I2677"></span><span id="I2678"></span> <p><span></span></p> :* If the target type is an anonymous access type, a check is made that the value of the operand is not null; if the target is not an anonymous access type, then the result is null if the operand value is null. <span id="I2679"></span><span id="I2680"></span> <p><span></span></p> :* If the operand value is not null, then the result designates the same object (or subprogram) as is designated by the operand value, but viewed as being of the target designated subtype (or profile); any checks associated with evaluating a conversion to the target designated subtype are performed. <span id="I2681"></span><span id="I2682"></span><span id="I2683"></span><span id="I2684"></span><span id="I2685"></span><span id="I2686"></span>After conversion of the value to the target type, if the target subtype is constrained, a check is performed that the value satisfies this constraint. <span id="I2687"></span>For the evaluation of a view conversion, the operand name is evaluated, and a new view of the object denoted by the operand is created, whose type is the target type; <span id="I2688"></span><span id="I2689"></span><span id="I2690"></span><span id="I2691"></span><span id="I2692"></span><span id="I2693"></span>if the target type is composite, checks are performed as above for a value conversion. The properties of this new view are as follows: * If the target type is composite, the bounds or discriminants (if any) of the view are as defined above for a value conversion; each nondiscriminant component of the view denotes the matching component of the operand object; the subtype of the view is constrained if either the target subtype or the operand object is constrained, or if the target subtype is indefinite, or if the operand type is a descendant of the target type, and has discriminants that were not inherited from the target type; * If the target type is tagged, then an assignment to the view assigns to the corresponding part of the object denoted by the operand; otherwise, an assignment to the view assigns to the object, after converting the assigned value to the subtype of the object (which might raise Constraint_Error); <span id="I2694"></span> * Reading the value of the view yields the result of converting the value of the operand object to the target subtype (which might raise Constraint_Error), except if the object is of an access type and the view conversion is passed as an '''out''' parameter; in this latter case, the value of the operand object is used to initialize the formal parameter without checking against any constraint of the target subtype (see [[Guide:95lrm/RM-6-4-1|6.4.1]]). <span id="I2695"></span> <span id="I2696"></span><span id="I2697"></span>If an Accessibility_Check fails, Program_Error is raised. Any other check associated with a conversion raises Constraint_Error if it fails. Conversion to a type is the same as conversion to an unconstrained subtype of the type. == Notes == 20  <span id="I2698"></span>In addition to explicit type_conversions, type conversions are performed implicitly in situations where the expected type and the actual type of a construct differ, as is permitted by the type resolution rules (see [[Guide:95lrm/RM-8-6|8.6]]). For example, an integer literal is of the type ''universal_integer'', and is implicitly converted when assigned to a target of some specific integer type. Similarly, an actual parameter of a specific tagged type is implicitly converted when the corresponding formal parameter is of a class-wide type. 21  <span id="I2699"></span><span id="I2700"></span>Even when the expected and actual types are the same, implicit subtype conversions are performed to adjust the array bounds (if any) of an operand to match the desired target subtype, or to raise Constraint_Error if the (possibly adjusted) value does not satisfy the constraints of the target subtype. A ramification of the overload resolution rules is that the operand of an (explicit) type_conversion cannot be the literal '''null''', an allocator, an aggregate, a string_literal, a character_literal, or an attribute_reference for an Access or Unchecked_Access attribute. Similarly, such an expression enclosed by parentheses is not allowed. A qualified_expression (see [[Guide:95lrm/RM-4-7|4.7]]) can be used instead of such a type_conversion. 22  The constraint of the target subtype has no effect for a type_conversion of an elementary type passed as an '''out''' parameter. Hence, it is recommended that the first subtype be specified as the target to minimize confusion (a similar recommendation applies to renaming and generic formal '''in out''' objects). == Examples == ''Examples of numeric type conversion:'' <p><syntaxhighlight lang="Ada"> Real(2*J)      --  value is converted to floating point Integer(1.6)   --  value is 2 Integer(-0.4)  --  value is 0</syntaxhighlight></p> ''Example of conversion between derived types:'' <p><syntaxhighlight lang="Ada"> type A_Form is new B_Form;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> X : A_Form; Y : B_Form;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> X := A_Form(Y); Y := B_Form(X);  --  the reverse conversion </syntaxhighlight></p> ''Examples of conversions between array types:'' <p><syntaxhighlight lang="Ada"> type Sequence is array (Integer range <>) of Integer; subtype Dozen is Sequence(1 .. 12); Ledger : array(1 .. 100) of Integer;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Sequence(Ledger)            --  bounds are those of Ledger Sequence(Ledger(31 .. 42))  --  bounds are 31 and 42 Dozen(Ledger(31 .. 42))     --  bounds are those of Dozen </syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-5-6|Previous]] | [[Guide:95lrm/RM-4-7|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} pg60hx222p7i26hd7j36afnp40d3yfe Guide:95lrm/RM-4-7 4200 1002 3870 3869 2019-05-04T23:37:45Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-6|Previous]] | [[Guide:95lrm/RM-4-8|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 4.7 Qualified Expressions}} A qualified_expression is used to state explicitly the type, and to verify the subtype, of an operand that is either an expression or an aggregate. <span id="I2701"></span> == Syntax == <p><span></span></p> qualified_expression<span id="I2702"></span> ::= <span id="I2703"></span>subtype_mark'(<span id="I2704"></span>expression) | <span id="I2705"></span>subtype_mark'<span id="I2706"></span>aggregate == Name Resolution Rules == <span id="I2707"></span>The ''operand'' (the expression or aggregate) shall resolve to be of the type determined by the subtype_mark, or a universal type that covers it. == Dynamic Semantics == <span id="I2708"></span><span id="I2709"></span><span id="I2710"></span><span id="I2711"></span><span id="I2712"></span><span id="I2713"></span><span id="I2714"></span>The evaluation of a qualified_expression evaluates the operand (and if of a universal type, converts it to the type determined by the subtype_mark) and checks that its value belongs to the subtype denoted by the subtype_mark. <span id="I2715"></span><span id="I2716"></span>The exception Constraint_Error is raised if this check fails. == Notes == 23  When a given context does not uniquely identify an expected type, a qualified_expression can be used to do so. In particular, if an overloaded name or aggregate is passed to an overloaded subprogram, it might be necessary to qualify the operand to resolve its type. == Examples == ''Examples of disambiguating expressions using qualification:'' <p><syntaxhighlight lang="Ada"> type Mask is (Fix, Dec, Exp, Signif); type Code is (Fix, Cla, Dec, Tnz, Sub);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Print (Mask'(Dec));  --  Dec is of type Mask Print (Code'(Dec));  --  Dec is of type Code </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> for J in Code'(Fix) .. Code'(Dec) loop ... -- qualification needed for either Fix or Dec for J in Code range Fix .. Dec loop ...    -- qualification unnecessary for J in Code'(Fix) .. Dec loop ...        -- qualification unnecessary for Dec</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Dozen'(1 | 3 | 5 | 7 => 2, others => 0) -- see 4.6 </syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-6|Previous]] | [[Guide:95lrm/RM-4-8|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} b43z0v0nfce2y3wrv03t9yii58cxowr Guide:95lrm/RM-4-8 4200 1003 3872 3871 2019-05-04T23:37:47Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-7|Previous]] | [[Guide:95lrm/RM-4-9|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 4.8 Allocators}} The evaluation of an allocator creates an object and yields an access value that designates the object. <span id="I2717"></span><span id="I2718"></span><span id="I2719"></span> == Syntax == <p><span></span></p> allocator<span id="I2720"></span> ::= '''new''' <span id="I2721"></span>subtype_indication | '''new''' <span id="I2722"></span>qualified_expression == Name Resolution Rules == <span id="I2723"></span>The expected type for an allocator shall be a single access-to-object type with designated type ''D'' such that either ''D'' covers the type determined by the subtype_mark of the subtype_indication or qualified_expression, or the expected type is anonymous and the determined type is ''D'''Class. == Legality Rules == <span id="I2724"></span>An ''initialized'' allocator is an allocator with a qualified_expression. <span id="I2725"></span>An ''uninitialized'' allocator is one with a subtype_indication. In the subtype_indication of an uninitialized allocator, a constraint is permitted only if the subtype_mark denotes an unconstrained composite subtype; if there is no constraint, then the subtype_mark shall denote a definite subtype. <span id="I2726"></span> If the type of the allocator is an access-to-constant type, the allocator shall be an initialized allocator. If the designated type is limited, the allocator shall be an uninitialized allocator. == Static Semantics == If the designated type of the type of the allocator is elementary, then the subtype of the created object is the designated subtype. If the designated type is composite, then the created object is always constrained; if the designated subtype is constrained, then it provides the constraint of the created object; otherwise, the object is constrained by its initial value (even if the designated subtype is unconstrained with defaults). <span id="I2727"></span> == Dynamic Semantics == <span id="I2728"></span>For the evaluation of an allocator, the elaboration of the subtype_indication or the evaluation of the qualified_expression is performed first. <span id="I2729"></span><span id="I2730"></span>For the evaluation of an initialized allocator, an object of the designated type is created and the value of the qualified_expression is converted to the designated subtype and assigned to the object. <span id="I2731"></span> <span id="I2732"></span>For the evaluation of an uninitialized allocator: * <span id="I2733"></span>If the designated type is elementary, an object of the designated subtype is created and any implicit initial value is assigned; * <span id="I2734"></span>If the designated type is composite, an object of the designated type is created with tag, if any, determined by the subtype_mark of the subtype_indication; any per-object constraints on subcomponents are elaborated (see [[Guide:95lrm/RM-3-8|3.8]]) and any implicit initial values for the subcomponents of the object are obtained as determined by the subtype_indication and assigned to the corresponding subcomponents. <span id="I2735"></span><span id="I2736"></span><span id="I2737"></span><span id="I2738"></span>A check is made that the value of the object belongs to the designated subtype. <span id="I2739"></span>Constraint_Error is raised if this check fails. This check and the initialization of the object are performed in an arbitrary order. If the created object contains any tasks, they are activated (see [[Guide:95lrm/RM-9-2|9.2]]). Finally, an access value that designates the created object is returned. == Notes == 24  Allocators cannot create objects of an abstract type. See [[Guide:95lrm/RM-3-9-3|3.9.3]]. 25  If any part of the created object is controlled, the initialization includes calls on corresponding Initialize or Adjust procedures. See [[Guide:95lrm/RM-7-6|7.6]]. 26  As explained in [[Guide:95lrm/RM-13-11|13.11]], ''[[Guide:95lrm/RM-13-11|Storage Management]]'', the storage for an object allocated by an allocator comes from a storage pool (possibly user defined). <span id="I2740"></span>The exception Storage_Error is raised by an allocator if there is not enough storage. Instances of Unchecked_Deallocation may be used to explicitly reclaim storage. 27  Implementations are permitted, but not required, to provide garbage collection (see [[Guide:95lrm/RM-13-11-3|13.11.3]]). == Examples == ''Examples of allocators:'' <p><syntaxhighlight lang="Ada"> new Cell'(0, null, null)                          -- initialized explicitly, see 3.10.1 new Cell'(Value => 0, Succ => null, Pred => null) -- initialized explicitly new Cell                                          -- not initialized</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> new Matrix(1 .. 10, 1 .. 20)                      -- the bounds only are given new Matrix'(1 .. 10 => (1 .. 20 => 0.0))          -- initialized explicitly</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> new Buffer(100)                                   -- the discriminant only is given new Buffer'(Size => 80, Pos => 0, Value => (1 .. 80 => 'A')) -- initialized explicitly</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Expr_Ptr'(new Literal)                  -- allocator for access-to-class-wide type, see 3.9.1 Expr_Ptr'(new Literal'(Expression with 3.5))      -- initialized explicitly</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-7|Previous]] | [[Guide:95lrm/RM-4-9|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} oxbfzbnz172xoppn3lkh8c4rmrm7haf Guide:95lrm/RM-4-9 4200 1004 3874 3873 2019-05-04T23:37:49Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-8|Previous]] | [[Guide:95lrm/RM-4-9-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 4.9 Static Expressions and Static Subtypes}} Certain expressions of a scalar or string type are defined to be static. Similarly, certain discrete ranges are defined to be static, and certain scalar and string subtypes are defined to be static subtypes. <span id="I2741"></span>''Static'' means determinable at compile time, using the declared properties or values of the program entities. <span id="I2742"></span> <span id="I2743"></span>A static expression is a scalar or string expression that is one of the following: * a numeric_literal; * a string_literal of a static string subtype; * a name that denotes the declaration of a named number or a static constant; * a function_call whose ''function_''name or ''function_''prefix statically denotes a static function, and whose actual parameters, if any (whether given explicitly or by default), are all static expressions; * an attribute_reference that denotes a scalar value, and whose prefix denotes a static scalar subtype; * an attribute_reference whose prefix statically denotes a statically constrained array object or array subtype, and whose attribute_designator is First, Last, or Length, with an optional dimension; * a type_conversion whose subtype_mark denotes a static scalar subtype, and whose operand is a static expression; * a qualified_expression whose subtype_mark denotes a static (scalar or string) subtype, and whose operand is a static expression; * a membership test whose simple_expression is a static expression, and whose range is a static range or whose subtype_mark denotes a static (scalar or string) subtype; * a short-circuit control form both of whose relations are static expressions; * a static expression enclosed in parentheses. <span id="I2744"></span>A name ''statically denotes'' an entity if it denotes the entity and: * It is a direct_name, expanded name, or character_literal, and it denotes a declaration other than a renaming_declaration; or * It is an attribute_reference whose prefix statically denotes some entity; or * It denotes a renaming_declaration with a name that statically denotes the renamed entity. <span id="I2745"></span>A ''static function'' is one of the following: * a predefined operator whose parameter and result types are all scalar types none of which are descendants of formal scalar types; * a predefined concatenation operator whose result type is a string type; * an enumeration literal; * a language-defined attribute that is a function, if the prefix denotes a static scalar subtype, and if the parameter and result types are scalar. In any case, a generic formal subprogram is not a static function. <span id="I2746"></span>A ''static constant'' is a constant view declared by a full constant declaration or an object_renaming_declaration with a static nominal subtype, having a value defined by a static scalar expression or by a static string expression whose value has a length not exceeding the maximum length of a string_literal in the implementation. <span id="I2747"></span>A ''static range'' is a range whose bounds are static expressions, or a range_attribute_reference that is equivalent to such a range. <span id="I2748"></span>A ''static discrete_range'' is one that is a static range or is a subtype_indication that defines a static scalar subtype. The base range of a scalar type is a static range, unless the type is a descendant of a formal scalar type. <span id="I2749"></span>A ''static subtype'' is either a ''static scalar subtype'' or a ''static string subtype''. <span id="I2750"></span>A static scalar subtype is an unconstrained scalar subtype whose type is not a descendant of a formal scalar type, or a constrained scalar subtype formed by imposing a compatible static constraint on a static scalar subtype. <span id="I2751"></span>A static string subtype is an unconstrained string subtype whose index subtype and component subtype are static (and whose type is not a descendant of a formal array type), or a constrained string subtype formed by imposing a compatible static constraint on a static string subtype. In any case, the subtype of a generic formal object of mode '''in out''', and the result subtype of a generic formal function, are not static. <span id="I2752"></span>The different kinds of ''static constraint'' are defined as follows: * A null constraint is always static; * <span id="I2753"></span><span id="I2754"></span><span id="I2755"></span>A scalar constraint is static if it has no range_constraint, or one with a static range; * <span id="I2756"></span>An index constraint is static if each discrete_range is static, and each index subtype of the corresponding array type is static; * <span id="I2757"></span>A discriminant constraint is static if each expression of the constraint is static, and the subtype of each discriminant is static. <span id="I2758"></span>A subtype is ''statically constrained'' if it is constrained, and its constraint is static. An object is ''statically constrained'' if its nominal subtype is statically constrained, or if it is a static string constant. == Legality Rules == A static expression is evaluated at compile time except when it is part of the right operand of a static short-circuit control form whose value is determined by its left operand. This evaluation is performed exactly, without performing Overflow_Checks. For a static expression that is evaluated: * The expression is illegal if its evaluation fails a language-defined check other than Overflow_Check. * If the expression is not part of a larger static expression, then its value shall be within the base range of its expected type. Otherwise, the value may be arbitrarily large or small. * If the expression is of type ''universal_real'' and its expected type is a decimal fixed point type, then its value shall be a multiple of the ''small'' of the decimal type. The last two restrictions above do not apply if the expected type is a descendant of a formal scalar type (or a corresponding actual type in an instance). == Implementation Requirements == For a real static expression that is not part of a larger static expression, and whose expected type is not a descendant of a formal scalar type, the implementation shall round or truncate the value (according to the Machine_Rounds attribute of the expected type) to the nearest machine number of the expected type; if the value is exactly half-way between two machine numbers, any rounding shall be performed away from zero. If the expected type is a descendant of a formal scalar type, no special rounding or truncating is required -- normal accuracy rules apply (see [[Guide:95lrm/RM-G|Annex G]]). == Notes == 28  An expression can be static even if it occurs in a context where staticness is not required. 29  A static (or run-time) type_conversion from a real type to an integer type performs rounding. If the operand value is exactly half-way between two integers, the rounding is performed away from zero. == Examples == ''Examples of static expressions:'' <p><syntaxhighlight lang="Ada"> 1 + 1       -- 2 abs(-10)*3  -- 30</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Kilo : constant := 1000; Mega : constant := Kilo*Kilo;   -- 1_000_000 Long : constant := Float'Digits*2;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Half_Pi    : constant := Pi/2;           -- see 3.3.2 Deg_To_Rad : constant := Half_Pi/90; Rad_To_Deg : constant := 1.0/Deg_To_Rad; -- equivalent to 1.0/((3.14159_26536/2)/90)</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-8|Previous]] | [[Guide:95lrm/RM-4-9-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} f0r1pka9rw5t162o3enznu20ys3bul5 Guide:95lrm/RM-4-9-1 4200 1005 3876 3875 2019-05-04T23:37:49Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-9|Previous]] | [[Guide:95lrm/RM-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 4.9.1 Statically Matching Constraints and Subtypes}} == Static Semantics == <span id="I2759"></span>A constraint ''statically matches'' another constraint if both are null constraints, both are static and have equal corresponding bounds or discriminant values, or both are nonstatic and result from the same elaboration of a constraint of a subtype_indication or the same evaluation of a range of a discrete_subtype_definition. <span id="I2760"></span>A subtype ''statically matches'' another subtype of the same type if they have statically matching constraints. Two anonymous access subtypes statically match if their designated subtypes statically match. <span id="I2761"></span>Two ranges of the same type ''statically match'' if both result from the same evaluation of a range, or if both are static and have equal corresponding bounds. <span id="I2762"></span>A constraint is ''statically compatible'' with a scalar subtype if it statically matches the constraint of the subtype, or if both are static and the constraint is compatible with the subtype. <span id="I2763"></span>A constraint is ''statically compatible'' with an access or composite subtype if it statically matches the constraint of the subtype, or if the subtype is unconstrained. <span id="I2764"></span>One subtype is ''statically compatible'' with a second subtype if the constraint of the first is statically compatible with the second subtype. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-9|Previous]] | [[Guide:95lrm/RM-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} fd20mw0szc94y6gftzpu2arlfrh9ebt Guide:95lrm/RM-5 4200 1006 3878 3877 2019-05-04T23:37:49Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-9-1|Previous]] | [[Guide:95lrm/RM-5-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Section 5: Statements}} A statement defines an action to be performed upon its execution. This section describes the general rules applicable to all statements. Some statements are discussed in later sections: Procedure_call_statements and return_statements are described in [[Guide:95lrm/RM-6|6]], ''[[Guide:95lrm/RM-6|Subprograms]]''. Entry_call_statements, requeue_statements, delay_statements, accept_statements, select_statements, and abort_statements are described in [[Guide:95lrm/RM-9|9]], ''[[Guide:95lrm/RM-9|Tasks and Synchronization]]''. Raise_statements are described in [[Guide:95lrm/RM-11|11]], ''[[Guide:95lrm/RM-11|Exceptions]]'', and code_statements in [[Guide:95lrm/RM-13|13]]. The remaining forms of statements are presented in this section. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-4-9-1|Previous]] | [[Guide:95lrm/RM-5-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} o3v9oxuov2qeclf0eiwdkt570m7u3wg Guide:95lrm/RM-5-1 4200 1007 3880 3879 2019-05-04T23:37:50Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-5|Previous]] | [[Guide:95lrm/RM-5-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 5.1 Simple and Compound Statements - Sequences of Statements}} A statement is either simple or compound. A simple_statement encloses no other statement. A compound_statement can enclose simple_statements and other compound_statements. == Syntax == <p><span></span></p> sequence_of_statements<span id="I2765"></span> ::= <span id="I2766"></span>statement {<span id="I2767"></span>statement} <p><span></span></p> statement<span id="I2768"></span> ::= {<span id="I2769"></span>label} <span id="I2770"></span>simple_statement | {<span id="I2771"></span>label} <span id="I2772"></span>compound_statement <p><span></span></p> simple_statement<span id="I2773"></span> ::= <span id="I2774"></span>null_statement | <span id="I2775"></span>assignment_statement | <span id="I2776"></span>exit_statement | <span id="I2777"></span>goto_statement | <span id="I2778"></span>procedure_call_statement | <span id="I2779"></span>return_statement | <span id="I2780"></span>entry_call_statement | <span id="I2781"></span>requeue_statement | <span id="I2782"></span>delay_statement | <span id="I2783"></span>abort_statement | <span id="I2784"></span>raise_statement | <span id="I2785"></span>code_statement <p><span></span></p> compound_statement<span id="I2786"></span> ::= <span id="I2787"></span>if_statement | <span id="I2788"></span>case_statement | <span id="I2789"></span>loop_statement | <span id="I2790"></span>block_statement | <span id="I2791"></span>accept_statement | <span id="I2792"></span>select_statement <p><span></span></p> null_statement<span id="I2793"></span> ::= '''null'''; <p><span></span></p> label<span id="I2794"></span> ::= <<''label_''<span id="I2795"></span>statement_identifier>> <p><span></span></p> statement_identifier<span id="I2796"></span> ::= <span id="I2797"></span>direct_name The direct_name of a statement_identifier shall be an identifier (not an operator_symbol). == Name Resolution Rules == The direct_name of a statement_identifier shall resolve to denote its corresponding implicit declaration (see below). == Legality Rules == Distinct identifiers shall be used for all statement_identifiers that appear in the same body, including inner block_statements but excluding inner program units. == Static Semantics == For each statement_identifier, there is an implicit declaration (with the specified identifier) at the end of the declarative_part of the innermost block_statement or body that encloses the statement_identifier. The implicit declarations occur in the same order as the statement_identifiers occur in the source text. If a usage name denotes such an implicit declaration, the entity it denotes is the label, loop_statement, or block_statement with the given statement_identifier. == Dynamic Semantics == <span id="I2798"></span>The execution of a null_statement has no effect. <span id="I2799"></span>A ''transfer of control'' is the run-time action of an exit_statement, return_statement, goto_statement, or requeue_statement, selection of a terminate_alternative, raising of an exception, or an abort, which causes the next action performed to be one other than what would normally be expected from the other rules of the language. As explained in [[Guide:95lrm/RM-7-6-1|7.6.1]], a transfer of control can cause the execution of constructs to be completed and then left, which may trigger finalization. <span id="I2800"></span>The execution of a sequence_of_statements consists of the execution of the individual statements in succession until the sequence_ is completed. == Notes == 1  A statement_identifier that appears immediately within the declarative region of a named loop_statement or an accept_statement is nevertheless implicitly declared immediately within the declarative region of the innermost enclosing body or block_statement; in other words, the expanded name for a named statement is not affected by whether the statement occurs inside or outside a named loop or an accept_statement -- only nesting within block_statements is relevant to the form of its expanded name. == Examples == ''Examples of labeled statements:'' <p><syntaxhighlight lang="Ada"><<Here>> <<Ici>> <<Aqui>> <<Hier>> null;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> <<After>> X := 1;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-5|Previous]] | [[Guide:95lrm/RM-5-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 81jjc37dnue5r317u8bk2fsffxwm359 Guide:95lrm/RM-5-2 4200 1008 3882 3881 2019-05-04T23:37:53Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-5-1|Previous]] | [[Guide:95lrm/RM-5-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 5.2 Assignment Statements}} An assignment_statement replaces the current value of a variable with the result of evaluating an expression. == Syntax == <p><span></span></p> assignment_statement<span id="I2801"></span> ::= ''variable_''<span id="I2802"></span>name := <span id="I2803"></span>expression; The execution of an assignment_statement includes the evaluation of the expression and the ''assignment'' of the value of the expression into the ''target''. <span id="I2804"></span><span id="I2805"></span>An assignment operation (as opposed to an assignment_statement) is performed in other contexts as well, including object initialization and by-copy parameter passing. <span id="I2806"></span><span id="I2807"></span>The ''target'' of an assignment operation is the view of the object to which a value is being assigned; the target of an assignment_statement is the variable denoted by the ''variable_''name. == Name Resolution Rules == <span id="I2808"></span>The ''variable_''name of an assignment_statement is expected to be of any nonlimited type. <span id="I2809"></span>The expected type for the expression is the type of the target. == Legality Rules == The target denoted by the ''variable_''name shall be a variable. If the target is of a tagged class-wide type ''T'''Class, then the expression shall either be dynamically tagged, or of type ''T'' and tag-indeterminate (see [[Guide:95lrm/RM-3-9-2|3.9.2]]). == Dynamic Semantics == <span id="I2810"></span>For the execution of an assignment_statement, the ''variable_''name and the expression are first evaluated in an arbitrary order. When the type of the target is class-wide: * <span id="I2811"></span>If the expression is tag-indeterminate (see [[Guide:95lrm/RM-3-9-2|3.9.2]]), then the controlling tag value for the expression is the tag of the target; * <span id="I2812"></span><span id="I2813"></span><span id="I2814"></span>Otherwise (the expression is dynamically tagged), a check is made that the tag of the value of the expression is the same as that of the target; if this check fails, Constraint_Error is raised. The value of the expression is converted to the subtype of the target. The conversion might raise an exception (see [[Guide:95lrm/RM-4-6|4.6]]). <span id="I2815"></span> In cases involving controlled types, the target is finalized, and an anonymous object might be used as an intermediate in the assignment, as described in [[Guide:95lrm/RM-7-6-1|7.6.1]], ''[[Guide:95lrm/RM-7-6-1|Completion and Finalization]]''. <span id="I2816"></span><span id="I2817"></span>In any case, the converted value of the expression is then ''assigned'' to the target, which consists of the following two steps: * The value of the target becomes the converted value. * If any part of the target is controlled, its value is adjusted as explained in clause [[Guide:95lrm/RM-7-6|7.6]]. <span id="I2818"></span> == Notes == 2  The tag of an object never changes; in particular, an assignment_statement does not change the tag of the target. 3  The values of the discriminants of an object designated by an access value cannot be changed (not even by assigning a complete value to the object itself) since such objects are always constrained; however, subcomponents of such objects may be unconstrained. == Examples == ''Examples of assignment statements:'' <p><syntaxhighlight lang="Ada"> Value := Max_Value - 1; Shade := Blue;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Next_Frame(F)(M, N) := 2.5;        --  see 4.1.1 U := Dot_Product(V, W);            --  see 6.3</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Writer := (Status => Open, Unit => Printer, Line_Count => 60);  -- see 3.8.1 Next_Car.all := (72074, null);    --  see 3.10.1</syntaxhighlight></p> ''Examples involving scalar subtype conversions:'' <p><syntaxhighlight lang="Ada"> I, J : Integer range 1 .. 10 := 5; K    : Integer range 1 .. 20 := 15;   ...</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> I := J;  --  identical ranges K := J;  --  compatible ranges J := K;  --  will raise Constraint_Error if K > 10</syntaxhighlight></p> ''Examples involving array subtype conversions:'' <p><syntaxhighlight lang="Ada"> A : String(1 .. 31); B : String(3 .. 33);   ...</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> A := B;  --  same number of components</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> A(1 .. 9)  := "tar sauce"; A(4 .. 12) := A(1 .. 9);  --  A(1 .. 12) = "tartar sauce"</syntaxhighlight></p> == Notes == 4  ''Notes on the examples:'' Assignment_statements are allowed even in the case of overlapping slices of the same array, because the ''variable_''name and expression are both evaluated before copying the value into the variable. In the above example, an implementation yielding A(1 .. 12) = "tartartartar" would be incorrect. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-5-1|Previous]] | [[Guide:95lrm/RM-5-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} stbhypvhxvj81xm87pv6ea66eulu9ey Guide:95lrm/RM-5-3 4200 1009 3884 3883 2019-05-04T23:37:55Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-5-2|Previous]] | [[Guide:95lrm/RM-5-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 5.3 If Statements}} An if_statement selects for execution at most one of the enclosed sequences_of_statements, depending on the (truth) value of one or more corresponding conditions. == Syntax == <p><span></span></p> if_statement<span id="I2819"></span> ::= '''if''' <span id="I2820"></span>condition '''then''' <span id="I2821"></span>sequence_of_statements {'''elsif''' <span id="I2822"></span>condition '''then''' <span id="I2823"></span>sequence_of_statements} ['''else''' <span id="I2824"></span>sequence_of_statements] '''end''' '''if'''; <p><span></span></p> condition<span id="I2825"></span> ::= ''boolean_''<span id="I2826"></span>expression == Name Resolution Rules == <span id="I2827"></span>A condition is expected to be of any boolean type. == Dynamic Semantics == <span id="I2828"></span>For the execution of an if_statement, the condition specified after '''if''', and any conditions specified after '''elsif''', are evaluated in succession (treating a final '''else''' as '''elsif''' True '''then'''), until one evaluates to True or all conditions are evaluated and yield False. If a condition evaluates to True, then the corresponding sequence_of_statements is executed; otherwise none of them is executed. == Examples == ''Examples of if statements:'' <p><syntaxhighlight lang="Ada"> if Month = December and Day = 31 then Month := January; Day   := 1; Year  := Year + 1; end if;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> if Line_Too_Short then raise Layout_Error; elsif Line_Full then New_Line; Put(Item); else Put(Item); end if;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> if My_Car.Owner.Vehicle /= My_Car then            --  see 3.10.1 Report ("Incorrect data"); end if;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-5-2|Previous]] | [[Guide:95lrm/RM-5-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 5g12xl78a7c9krwel3au5yiem631red Guide:95lrm/RM-5-4 4200 1010 3886 3885 2019-05-04T23:37:56Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-5-3|Previous]] | [[Guide:95lrm/RM-5-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 5.4 Case Statements}} A case_statement selects for execution one of a number of alternative sequences_of_statements; the chosen alternative is defined by the value of an expression. == Syntax == <p><span></span></p> case_statement<span id="I2829"></span> ::= '''case''' <span id="I2830"></span>expression '''is''' <span id="I2831"></span>case_statement_alternative {<span id="I2832"></span>case_statement_alternative} '''end''' '''case'''; <p><span></span></p> case_statement_alternative<span id="I2833"></span> ::= '''when''' <span id="I2834"></span>discrete_choice_list => <span id="I2835"></span>sequence_of_statements == Name Resolution Rules == <span id="I2836"></span>The expression is expected to be of any discrete type. <span id="I2837"></span>The expected type for each discrete_choice is the type of the expression. == Legality Rules == The expressions and discrete_ranges given as discrete_choices of a case_statement shall be static. A discrete_choice '''others''', if present, shall appear alone and in the last discrete_choice_list. The possible values of the expression shall be covered as follows: * If the expression is a name (including a type_conversion or a function_call) having a static and constrained nominal subtype, or is a qualified_expression whose subtype_mark denotes a static and constrained scalar subtype, then each non-'''others''' discrete_choice shall cover only values in that subtype, and each value of that subtype shall be covered by some discrete_choice (either explicitly or by '''others'''). * If the type of the expression is ''root_integer'', ''universal_integer'', or a descendant of a formal scalar type, then the case_statement shall have an '''others''' discrete_choice. * Otherwise, each value of the base range of the type of the expression shall be covered (either explicitly or by '''others'''). Two distinct discrete_choices of a case_statement shall not cover the same value. == Dynamic Semantics == <span id="I2838"></span>For the execution of a case_statement the expression is first evaluated. If the value of the expression is covered by the discrete_choice_list of some case_statement_alternative, then the sequence_of_statements of the _alternative is executed. <span id="I2839"></span><span id="I2840"></span><span id="I2841"></span>Otherwise (the value is not covered by any discrete_choice_list, perhaps due to being outside the base range), Constraint_Error is raised. == Notes == 5  The execution of a case_statement chooses one and only one alternative. Qualification of the expression of a case_statement by a static subtype can often be used to limit the number of choices that need be given explicitly. == Examples == ''Examples of case statements:'' <p><syntaxhighlight lang="Ada"> case Sensor is when Elevation      => Record_Elevation(Sensor_Value); when Azimuth        => Record_Azimuth  (Sensor_Value); when Distance       => Record_Distance (Sensor_Value); when others         => null; end case;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> case Today is when Mon            => Compute_Initial_Balance; when Fri            => Compute_Closing_Balance; when Tue .. Thu     => Generate_Report(Today); when Sat .. Sun     => null; end case;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> case Bin_Number(Count) is when 1        => Update_Bin(1); when 2        => Update_Bin(2); when 3 | 4    =>     Empty_Bin(1);     Empty_Bin(2); when others   => raise Error; end case;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-5-3|Previous]] | [[Guide:95lrm/RM-5-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} qhkf3pia3z71bc57w53nsdb0ljnlte4 Guide:95lrm/RM-5-5 4200 1011 3888 3887 2019-05-04T23:37:58Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-5-4|Previous]] | [[Guide:95lrm/RM-5-6|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 5.5 Loop Statements}} A loop_statement includes a sequence_of_statements that is to be executed repeatedly, zero or more times. == Syntax == <p><span></span></p> loop_statement<span id="I2842"></span> ::= [''loop_''<span id="I2843"></span>statement_identifier:] [<span id="I2844"></span>iteration_scheme] '''loop''' <span id="I2845"></span>sequence_of_statements '''end''' '''loop''' [''loop_''<span id="I2846"></span>identifier]; <p><span></span></p> iteration_scheme<span id="I2847"></span> ::= '''while''' <span id="I2848"></span>condition | '''for''' <span id="I2849"></span>loop_parameter_specification <p><span></span></p> loop_parameter_specification<span id="I2850"></span> ::= <span id="I2851"></span>defining_identifier '''in''' ['''reverse'''] <span id="I2852"></span>discrete_subtype_definition If a loop_statement has a ''loop_''statement_identifier, then the identifier shall be repeated after the '''end loop'''; otherwise, there shall not be an identifier after the '''end loop'''. == Static Semantics == <span id="I2853"></span>A loop_parameter_specification declares a ''loop parameter'', which is an object whose subtype is that defined by the discrete_subtype_definition. <span id="I2854"></span> == Dynamic Semantics == <span id="I2855"></span>For the execution of a loop_statement, the sequence_of_statements is executed repeatedly, zero or more times, until the loop_statement is complete. The loop_statement is complete when a transfer of control occurs that transfers control out of the loop, or, in the case of an iteration_scheme, as specified below. <span id="I2856"></span>For the execution of a loop_statement with a '''while''' iteration_scheme, the condition is evaluated before each execution of the sequence_of_statements; if the value of the condition is True, the sequence_of_statements is executed; if False, the execution of the loop_statement is complete. <span id="I2857"></span><span id="I2858"></span>For the execution of a loop_statement with a '''for''' iteration_scheme, the loop_parameter_specification is first elaborated. This elaboration creates the loop parameter and elaborates the discrete_subtype_definition. If the discrete_subtype_definition defines a subtype with a null range, the execution of the loop_statement is complete. Otherwise, the sequence_of_statements is executed once for each value of the discrete subtype defined by the discrete_subtype_definition (or until the loop is left as a consequence of a transfer of control). <span id="I2859"></span>Prior to each such iteration, the corresponding value of the discrete subtype is assigned to the loop parameter. These values are assigned in increasing order unless the reserved word '''reverse''' is present, in which case the values are assigned in decreasing order. == Notes == 6  A loop parameter is a constant; it cannot be updated within the sequence_of_statements of the loop (see [[Guide:95lrm/RM-3-3|3.3]]). 7  An object_declaration should not be given for a loop parameter, since the loop parameter is automatically declared by the loop_parameter_specification. The scope of a loop parameter extends from the loop_parameter_specification to the end of the loop_statement, and the visibility rules are such that a loop parameter is only visible within the sequence_of_statements of the loop. 8  The discrete_subtype_definition of a for loop is elaborated just once. Use of the reserved word '''reverse''' does not alter the discrete subtype defined, so that the following iteration_schemes are not equivalent; the first has a null range. <p><syntaxhighlight lang="Ada"> for J in reverse 1 .. 0 for J in 0 .. 1</syntaxhighlight></p> == Examples == ''Example of a loop statement without an iteration scheme:'' <p><syntaxhighlight lang="Ada"> loop Get(Current_Character); exit when Current_Character = '*'; end loop;</syntaxhighlight></p> ''Example of a loop statement with a '''while''' iteration scheme:'' <p><syntaxhighlight lang="Ada"> while Bid(N).Price < Cut_Off.Price loop Record_Bid(Bid(N).Price); N := N + 1; end loop;</syntaxhighlight></p> ''Example of a loop statement with a '''for''' iteration scheme:'' <p><syntaxhighlight lang="Ada"> for J in Buffer'Range loop     --  works even with a null range if Buffer(J) /= Space then    Put(Buffer(J)); end if; end loop;</syntaxhighlight></p> ''Example of a loop statement with a name:'' <p><syntaxhighlight lang="Ada"> Summation: while Next /= Head loop       -- see 3.10.1     Sum  := Sum + Next.Value;     Next := Next.Succ; end loop Summation;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-5-4|Previous]] | [[Guide:95lrm/RM-5-6|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 4ahse3f8e2sbj8qzoael8pt33k0fasc Guide:95lrm/RM-5-6 4200 1012 3890 3889 2019-05-04T23:37:59Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-5-5|Previous]] | [[Guide:95lrm/RM-5-7|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 5.6 Block Statements}} A block_statement encloses a handled_sequence_of_statements optionally preceded by a declarative_part. == Syntax == <p><span></span></p> block_statement<span id="I2860"></span> ::= [''block_''<span id="I2861"></span>statement_identifier:] ['''declare'''     <span id="I2862"></span>declarative_part] '''begin''' <span id="I2863"></span>handled_sequence_of_statements '''end''' [''block_''<span id="I2864"></span>identifier]; If a block_statement has a ''block_''statement_identifier, then the identifier shall be repeated after the '''end'''; otherwise, there shall not be an identifier after the '''end'''. == Static Semantics == A block_statement that has no explicit declarative_part has an implicit empty declarative_part. == Dynamic Semantics == <span id="I2865"></span>The execution of a block_statement consists of the elaboration of its declarative_part followed by the execution of its handled_sequence_of_statements. == Examples == ''Example of a block statement with a local variable:'' <p><syntaxhighlight lang="Ada"> Swap: declare    Temp : Integer; begin    Temp := V; V := U; U := Temp; end Swap;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-5-5|Previous]] | [[Guide:95lrm/RM-5-7|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} l9sclrd2dw88jbgzfbbsftj44hrzb2v Guide:95lrm/RM-5-7 4200 1013 3892 3891 2019-05-04T23:38:00Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-5-6|Previous]] | [[Guide:95lrm/RM-5-8|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 5.7 Exit Statements}} An exit_statement is used to complete the execution of an enclosing loop_statement; the completion is conditional if the exit_statement includes a condition. == Syntax == <p><span></span></p> exit_statement<span id="I2866"></span> ::= '''exit''' [''loop_''<span id="I2867"></span>name] ['''when''' <span id="I2868"></span>condition]; == Name Resolution Rules == The ''loop_''name, if any, in an exit_statement shall resolve to denote a loop_statement. == Legality Rules == <span id="I2869"></span>Each exit_statement ''applies to'' a loop_statement; this is the loop_statement being exited. An exit_statement with a name is only allowed within the loop_statement denoted by the name, and applies to that loop_statement. An exit_statement without a name is only allowed within a loop_statement, and applies to the innermost enclosing one. An exit_statement that applies to a given loop_statement shall not appear within a body or accept_statement, if this construct is itself enclosed by the given loop_statement. == Dynamic Semantics == <span id="I2870"></span>For the execution of an exit_statement, the condition, if present, is first evaluated. If the value of the condition is True, or if there is no condition, a transfer of control is done to complete the loop_statement. If the value of the condition is False, no transfer of control takes place. == Notes == 9  Several nested loops can be exited by an exit_statement that names the outer loop. == Examples == ''Examples of loops with exit statements:'' <p><syntaxhighlight lang="Ada"> for N in 1 .. Max_Num_Items loop Get_New_Item(New_Item); Merge_Item(New_Item, Storage_File); exit when New_Item = Terminal_Item; end loop;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Main_Cycle: loop    --  initial statements    exit Main_Cycle when Found;    --  final statements end loop Main_Cycle;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-5-6|Previous]] | [[Guide:95lrm/RM-5-8|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} d5stwiki0adezmpmpttj89o77wcslyz Guide:95lrm/RM-5-8 4200 1014 3894 3893 2019-05-04T23:38:00Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-5-7|Previous]] | [[Guide:95lrm/RM-6|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 5.8 Goto Statements}} A goto_statement specifies an explicit transfer of control from this statement to a target statement with a given label. == Syntax == <p><span></span></p> goto_statement<span id="I2871"></span> ::= '''goto''' ''label_''<span id="I2872"></span>name; == Name Resolution Rules == <span id="I2873"></span>The ''label_''name shall resolve to denote a label; the statement with that label is the ''target statement''. == Legality Rules == The innermost sequence_of_statements that encloses the target statement shall also enclose the goto_statement. Furthermore, if a goto_statement is enclosed by an accept_statement or a body, then the target statement shall not be outside this enclosing construct. == Dynamic Semantics == <span id="I2874"></span>The execution of a goto_statement transfers control to the target statement, completing the execution of any compound_statement that encloses the goto_statement but does not enclose the target. == Notes == 10  The above rules allow transfer of control to a statement of an enclosing sequence_of_statements but not the reverse. Similarly, they prohibit transfers of control such as between alternatives of a case_statement, if_statement, or select_statement; between exception_handlers; or from an exception_handler of a handled_sequence_of_statements back to its sequence_of_statements. == Examples == ''Example of a loop containing a goto statement:'' <p><syntaxhighlight lang="Ada"> <<Sort>> for I in 1 .. N-1 loop if A(I) > A(I+1) then    Exchange(A(I), A(I+1));    goto Sort; end if; end loop;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-5-7|Previous]] | [[Guide:95lrm/RM-6|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} sfwkc3s7tof32l25x66jhgwh5qgm83z Guide:95lrm/RM-6 4200 1015 3896 3895 2019-05-04T23:38:01Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-5-8|Previous]] | [[Guide:95lrm/RM-6-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Section 6: Subprograms}} <span id="I2875"></span><span id="I2876"></span><span id="I2877"></span>A subprogram is a program unit or intrinsic operation whose execution is invoked by a subprogram call. There are two forms of subprogram: procedures and functions. A procedure call is a statement; a function call is an expression and returns a value. The definition of a subprogram can be given in two parts: a subprogram declaration defining its interface, and a subprogram_body defining its execution. Operators and enumeration literals are functions. <span id="I2878"></span>A ''callable entity'' is a subprogram or entry (see Section 9). <span id="I2879"></span>A callable entity is invoked by a ''call''; that is, a subprogram call or entry call. <span id="I2880"></span>A ''callable construct'' is a construct that defines the action of a call upon a callable entity: a subprogram_body, entry_body, or accept_statement. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-5-8|Previous]] | [[Guide:95lrm/RM-6-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} bynnnscn662ey5o6lsejiwueffr72iu Guide:95lrm/RM-6-1 4200 1016 3898 3897 2019-05-04T23:38:02Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-6|Previous]] | [[Guide:95lrm/RM-6-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 6.1 Subprogram Declarations}} A subprogram_declaration declares a procedure or function. == Syntax == <p><span></span></p> subprogram_declaration<span id="I2881"></span> ::= <span id="I2882"></span>subprogram_specification; <p><span></span></p> abstract_subprogram_declaration<span id="I2883"></span> ::= <span id="I2884"></span>subprogram_specification '''is''' '''abstract'''; <p><span></span></p> subprogram_specification<span id="I2885"></span> ::= '''procedure''' <span id="I2886"></span>defining_program_unit_name  <span id="I2887"></span>parameter_profile | '''function''' <span id="I2888"></span>defining_designator  <span id="I2889"></span>parameter_and_result_profile <p><span></span></p> designator<span id="I2890"></span> ::= [<span id="I2891"></span>parent_unit_name . ]<span id="I2892"></span>identifier | <span id="I2893"></span>operator_symbol <p><span></span></p> defining_designator<span id="I2894"></span> ::= <span id="I2895"></span>defining_program_unit_name | <span id="I2896"></span>defining_operator_symbol <p><span></span></p> defining_program_unit_name<span id="I2897"></span> ::= [<span id="I2898"></span>parent_unit_name . ]<span id="I2899"></span>defining_identifier The optional parent_unit_name is only allowed for library units (see [[Guide:95lrm/RM-10-1-1|10.1.1]]). <p><span></span></p> operator_symbol<span id="I2900"></span> ::= <span id="I2901"></span>string_literal The sequence of characters in an operator_symbol shall correspond to an operator belonging to one of the six classes of operators defined in clause [[Guide:95lrm/RM-4-5|4.5]] (spaces are not allowed and the case of letters is not significant). <p><span></span></p> defining_operator_symbol<span id="I2902"></span> ::= <span id="I2903"></span>operator_symbol <p><span></span></p> parameter_profile<span id="I2904"></span> ::= [<span id="I2905"></span>formal_part] <p><span></span></p> parameter_and_result_profile<span id="I2906"></span> ::= [<span id="I2907"></span>formal_part] '''return''' <span id="I2908"></span>subtype_mark <p><span></span></p> formal_part<span id="I2909"></span> ::= (<span id="I2910"></span>parameter_specification {; <span id="I2911"></span>parameter_specification}) <p><span></span></p> parameter_specification<span id="I2912"></span> ::= <span id="I2913"></span>defining_identifier_list : <span id="I2914"></span>mode  <span id="I2915"></span>subtype_mark [:= <span id="I2916"></span>default_expression] | <span id="I2917"></span>defining_identifier_list : <span id="I2918"></span>access_definition [:= <span id="I2919"></span>default_expression] <p><span></span></p> mode<span id="I2920"></span> ::= ['''in'''] | '''in''' '''out''' | '''out''' == Name Resolution Rules == <span id="I2921"></span>A ''formal parameter'' is an object directly visible within a subprogram_body that represents the actual parameter passed to the subprogram in a call; it is declared by a parameter_specification. <span id="I2922"></span>For a formal parameter, the expected type for its default_expression, if any, is that of the formal parameter. <span id="I2923"></span> == Legality Rules == <span id="I2924"></span>The ''parameter mode'' of a formal parameter conveys the direction of information transfer with the actual parameter: '''in''', '''in out''', or '''out'''. Mode '''in''' is the default, and is the mode of a parameter defined by an access_definition. The formal parameters of a function, if any, shall have the mode '''in'''. A default_expression is only allowed in a parameter_specification for a formal parameter of mode '''in'''. <span id="I2925"></span><span id="I2926"></span>A subprogram_declaration or a generic_subprogram_declaration requires a completion: a body, a renaming_declaration (see [[Guide:95lrm/RM-8-5|8.5]]), or a '''pragma''' Import (see [[Guide:95lrm/RM-B-1|B.1]]). A completion is not allowed for an abstract_subprogram_declaration. A name that denotes a formal parameter is not allowed within the formal_part in which it is declared, nor within the formal_part of a corresponding body or accept_statement. == Static Semantics == <span id="I2927"></span>The ''profile'' of (a view of) a callable entity is either a parameter_profile or parameter_and_result_profile; it embodies information about the interface to that entity -- for example, the profile includes information about parameters passed to the callable entity. All callable entities have a profile -- enumeration literals, other subprograms, and entries. An access-to-subprogram type has a designated profile. Associated with a profile is a calling convention. A subprogram_declaration declares a procedure or a function, as indicated by the initial reserved word, with name and profile as given by its specification. <span id="I2928"></span>The nominal subtype of a formal parameter is the subtype denoted by the subtype_mark, or defined by the access_definition, in the parameter_specification. <span id="I2929"></span>An ''access parameter'' is a formal '''in''' parameter specified by an access_definition. An access parameter is of an anonymous general access-to-variable type (see [[Guide:95lrm/RM-3-10|3.10]]). Access parameters allow dispatching calls to be controlled by access values. <span id="I2930"></span>The ''subtypes of a profile'' are: * For any non-access parameters, the nominal subtype of the parameter. * For any access parameters, the designated subtype of the parameter type. * For any result, the result subtype. <span id="I2931"></span>The ''types of a profile'' are the types of those subtypes. A subprogram declared by an abstract_subprogram_declaration is abstract; a subprogram declared by a subprogram_declaration is not. See [[Guide:95lrm/RM-3-9-3|3.9.3]], ''[[Guide:95lrm/RM-3-9-3|Abstract Types and Subprograms]]''. == Dynamic Semantics == <span id="I2932"></span><span id="I2933"></span>The elaboration of a subprogram_declaration or an abstract_subprogram_declaration has no effect. == Notes == 1  A parameter_specification with several identifiers is equivalent to a sequence of single parameter_specifications, as explained in [[Guide:95lrm/RM-3-3|3.3]]. 2  Abstract subprograms do not have bodies, and cannot be used in a nondispatching call (see [[Guide:95lrm/RM-3-9-3|3.9.3]], ''[[Guide:95lrm/RM-3-9-3|Abstract Types and Subprograms]]''). 3  The evaluation of default_expressions is caused by certain calls, as described in [[Guide:95lrm/RM-6-4-1|6.4.1]]. They are not evaluated during the elaboration of the subprogram declaration. 4  Subprograms can be called recursively and can be called concurrently from multiple tasks. == Examples == ''Examples of subprogram declarations:'' <p><syntaxhighlight lang="Ada"> procedure Traverse_Tree; procedure Increment(X : in out Integer); procedure Right_Indent(Margin : out Line_Size);          --  see 3.5.4 procedure Switch(From, To : in out Link);                --  see 3.10.1</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> function Random return Probability;                      --  see 3.5.7</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> function Min_Cell(X : Link) return Cell;                 --  see 3.10.1 function Next_Frame(K : Positive) return Frame;          --  see 3.10 function Dot_Product(Left, Right : Vector) return Real;  --  see 3.6</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> function "*"(Left, Right : Matrix) return Matrix;        --  see 3.6</syntaxhighlight></p> ''Examples of '''in''' parameters with default expressions:'' <p><syntaxhighlight lang="Ada"> procedure Print_Header(Pages  : in Natural;      Header : in Line    :=  (1 .. Line'Last => ' ');  --  see 3.6      Center : in Boolean := True);</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-6|Previous]] | [[Guide:95lrm/RM-6-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} szzswdqbjz3grtms1v9ewv0xmp4ky87 Guide:95lrm/RM-6-2 4200 1017 3900 3899 2019-05-04T23:38:03Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-6-1|Previous]] | [[Guide:95lrm/RM-6-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 6.2 Formal Parameter Modes}} A parameter_specification declares a formal parameter of mode '''in''', '''in out''', or '''out'''. == Static Semantics == <span id="I2934"></span><span id="I2935"></span><span id="I2936"></span><span id="I2937"></span><span id="I2938"></span><span id="I2939"></span>A parameter is passed either ''by copy'' or ''by reference''. When a parameter is passed by copy, the formal parameter denotes a separate object from the actual parameter, and any information transfer between the two occurs only before and after executing the subprogram. When a parameter is passed by reference, the formal parameter denotes (a view of) the object denoted by the actual parameter; reads and updates of the formal parameter directly reference the actual parameter object. <span id="I2940"></span>A type is a ''by-copy type'' if it is an elementary type, or if it is a descendant of a private type whose full type is a by-copy type. A parameter of a by-copy type is passed by copy. <span id="I2941"></span>A type is a ''by-reference type'' if it is a descendant of one of the following: * a tagged type; * a task or protected type; * a nonprivate type with the reserved word '''limited''' in its declaration; * a composite type with a subcomponent of a by-reference type; * a private type whose full type is a by-reference type. A parameter of a by-reference type is passed by reference. <span id="I2942"></span>Each value of a by-reference type has an associated object. For a parenthesized expression, qualified_expression, or type_conversion, this object is the one associated with the operand. <span id="I2943"></span>For parameters of other types, it is unspecified whether the parameter is passed by copy or by reference. == Bounded (Run-Time) Errors == <span id="I2944"></span><span id="I2945"></span><span id="I2946"></span><span id="I2947"></span>If one name denotes a part of a formal parameter, and a second name denotes a part of a distinct formal parameter or an object that is not part of a formal parameter, then the two names are considered ''distinct access paths''. If an object is of a type for which the parameter passing mechanism is not specified, then it is a bounded error to assign to the object via one access path, and then read the value of the object via a distinct access path, unless the first access path denotes a part of a formal parameter that no longer exists at the point of the second access (due to leaving the corresponding callable construct). <span id="I2948"></span>The possible consequences are that Program_Error is raised, or the newly assigned value is read, or some old value of the object is read. == Notes == 5  A formal parameter of mode '''in''' is a constant view (see [[Guide:95lrm/RM-3-3|3.3]]); it cannot be updated within the subprogram_body. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-6-1|Previous]] | [[Guide:95lrm/RM-6-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} oddhht6mim98pkq7ogilui7i9rzugcs Guide:95lrm/RM-6-3 4200 1018 3902 3901 2019-05-04T23:38:04Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-6-2|Previous]] | [[Guide:95lrm/RM-6-3-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 6.3 Subprogram Bodies}} A subprogram_body specifies the execution of a subprogram. == Syntax == <p><span></span></p> subprogram_body<span id="I2949"></span> ::= <span id="I2950"></span>subprogram_specification '''is''' <span id="I2951"></span>declarative_part '''begin''' <span id="I2952"></span>handled_sequence_of_statements '''end''' [<span id="I2953"></span>designator]; If a designator appears at the end of a subprogram_body, it shall repeat the defining_designator of the subprogram_specification. == Legality Rules == In contrast to other bodies, a subprogram_body need not be the completion of a previous declaration, in which case the body declares the subprogram. If the body is a completion, it shall be the completion of a subprogram_declaration or generic_subprogram_declaration. The profile of a subprogram_body that completes a declaration shall conform fully to that of the declaration. <span id="I2954"></span> == Static Semantics == A subprogram_body is considered a declaration. It can either complete a previous declaration, or itself be the initial declaration of the subprogram. == Dynamic Semantics == <span id="I2955"></span>The elaboration of a non-generic subprogram_body has no other effect than to establish that the subprogram can from then on be called without failing the Elaboration_Check. <span id="I2956"></span>The execution of a subprogram_body is invoked by a subprogram call. For this execution the declarative_part is elaborated, and the handled_sequence_of_statements is then executed. == Examples == ''Example of procedure body:'' <p><syntaxhighlight lang="Ada"> procedure Push(E : in Element_Type; S : in out Stack) is begin if S.Index = S.Size then    raise Stack_Overflow; else    S.Index := S.Index + 1;    S.Space(S.Index) := E; end if; end Push;</syntaxhighlight></p> ''Example of a function body:'' <p><syntaxhighlight lang="Ada"> function Dot_Product(Left, Right : Vector) return Real is Sum : Real := 0.0; begin Check(Left'First = Right'First and Left'Last = Right'Last); for J in Left'Range loop    Sum := Sum + Left(J)*Right(J); end loop; return Sum; end Dot_Product;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-6-2|Previous]] | [[Guide:95lrm/RM-6-3-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} kman1wglpxqsin8qrap4psi4ow7xvuu Guide:95lrm/RM-6-3-1 4200 1019 3904 3903 2019-05-04T23:38:04Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-6-3|Previous]] | [[Guide:95lrm/RM-6-3-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 6.3.1 Conformance Rules}} <span id="I2957"></span><span id="I2958"></span><span id="I2959"></span><span id="I2960"></span><span id="I2961"></span>When subprogram profiles are given in more than one place, they are required to conform in one of four ways: type conformance, mode conformance, subtype conformance, or full conformance. == Static Semantics == <span id="I2962"></span><span id="I2963"></span>As explained in [[Guide:95lrm/RM-B-1|B.1]], ''[[Guide:95lrm/RM-B-1|Interfacing Pragmas]]'', a ''convention'' can be specified for an entity. Unless this International Standard states otherwise, the default convention of an entity is Ada. For a callable entity or access-to-subprogram type, the convention is called the ''calling convention''. The following conventions are defined by the language: * <span id="I2964"></span><span id="I2965"></span>The default calling convention for any subprogram not listed below is ''Ada''. A pragma Convention, Import, or Export may be used to override the default calling convention (see [[Guide:95lrm/RM-B-1|B.1]]). * <span id="I2966"></span><span id="I2967"></span>The ''Intrinsic'' calling convention represents subprograms that are ''built in'' to the compiler. The default calling convention is Intrinsic for the following: <p><span></span></p> :* an enumeration literal; <p><span></span></p> :* a "/=" operator declared implicitly due to the declaration of "=" (see [[Guide:95lrm/RM-6-6|6.6]]); <p><span></span></p> :* any other implicitly declared subprogram unless it is a dispatching operation of a tagged type; <p><span></span></p> :* an inherited subprogram of a generic formal tagged type with unknown discriminants; <p><span></span></p> :* an attribute that is a subprogram; <p><span></span></p> :* a subprogram declared immediately within a protected_body. <p><span></span></p> ::The Access attribute is not allowed for Intrinsic subprograms. * <span id="I2968"></span><span id="I2969"></span>The default calling convention is ''protected'' for a protected subprogram, and for an access-to-subprogram type with the reserved word '''protected''' in its definition. * <span id="I2970"></span><span id="I2971"></span>The default calling convention is ''entry'' for an entry. <div> * If not specified above as Intrinsic, the calling convention for any inherited or overriding dispatching operation of a tagged type is that of the corresponding subprogram of the parent type. The default calling convention for a new dispatching operation of a tagged type is the convention of the type.</div> Of these four conventions, only Ada and Intrinsic are allowed as a ''convention_''identifier in a pragma Convention, Import, or Export. <span id="I2972"></span><span id="I2973"></span>Two profiles are ''type conformant'' if they have the same number of parameters, and both have a result if either does, and corresponding parameter and result types are the same, or, for access parameters, corresponding designated types are the same. <span id="I2974"></span> <span id="I2975"></span><span id="I2976"></span>Two profiles are ''mode conformant'' if they are type-conformant, and corresponding parameters have identical modes, and, for access parameters, the designated subtypes statically match. <span id="I2977"></span> <span id="I2978"></span><span id="I2979"></span>Two profiles are ''subtype conformant'' if they are mode-conformant, corresponding subtypes of the profile statically match, and the associated calling conventions are the same. The profile of a generic formal subprogram is not subtype-conformant with any other profile. <span id="I2980"></span> <span id="I2981"></span><span id="I2982"></span>Two profiles are ''fully conformant'' if they are subtype-conformant, and corresponding parameters have the same names and have default_expressions that are fully conformant with one another. <span id="I2983"></span>Two expressions are ''fully conformant'' if, after replacing each use of an operator with the equivalent function_call: * each constituent construct of one corresponds to an instance of the same syntactic category in the other, except that an expanded name may correspond to a direct_name (or character_literal) or to a different expanded name in the other; and * each direct_name, character_literal, and selector_name that is not part of the prefix of an expanded name in one denotes the same declaration as the corresponding direct_name, character_literal, or selector_name in the other; and <div> * each attribute_designator in one must be the same as the corresponding attribute_designator in the other; and </div> * each primary that is a literal in one has the same value as the corresponding literal in the other. <span id="I2984"></span>Two known_discriminant_parts are ''fully conformant'' if they have the same number of discriminants, and discriminants in the same positions have the same names, statically matching subtypes, and default_expressions that are fully conformant with one another. <span id="I2985"></span> <span id="I2986"></span>Two discrete_subtype_definitions are ''fully conformant'' if they are both subtype_indications or are both ranges, the subtype_marks (if any) denote the same subtype, and the corresponding simple_expressions of the ranges (if any) fully conform. == Implementation Permissions == An implementation may declare an operator declared in a language-defined library unit to be intrinsic. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-6-3|Previous]] | [[Guide:95lrm/RM-6-3-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 8h0m2ola4gszguhce86w92txzs6tg4p Guide:95lrm/RM-6-3-2 4200 1020 3906 3905 2019-05-04T23:38:04Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-6-3-1|Previous]] | [[Guide:95lrm/RM-6-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 6.3.2 Inline Expansion of Subprograms}} Subprograms may be expanded in line at the call site. == Syntax == <span id="I2987"></span><span id="I2988"></span>The form of a pragma Inline, which is a program unit pragma (see [[Guide:95lrm/RM-10-1-5|10.1.5]]), is as follows: <p><span></span></p> '''pragma''' <span id="I2989"></span><span id="I2990"></span>Inline(<span id="I2991"></span>name {, <span id="I2992"></span>name}); == Legality Rules == The pragma shall apply to one or more callable entities or generic subprograms. == Static Semantics == If a pragma Inline applies to a callable entity, this indicates that inline expansion is desired for all calls to that entity. If a pragma Inline applies to a generic subprogram, this indicates that inline expansion is desired for all calls to all instances of that generic subprogram. == Implementation Permissions == For each call, an implementation is free to follow or to ignore the recommendation expressed by the pragma. == Notes == 6  The name in a pragma Inline can denote more than one entity in the case of overloading. Such a pragma applies to all of the denoted entities. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-6-3-1|Previous]] | [[Guide:95lrm/RM-6-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} ewopikh5mme227isgj5tomnfegk4czs Guide:95lrm/RM-6-4 4200 1021 3908 3907 2019-05-04T23:38:08Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-6-3-2|Previous]] | [[Guide:95lrm/RM-6-4-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 6.4 Subprogram Calls}} <span id="I2993"></span>A ''subprogram call'' is either a procedure_call_statement or a function_call; it invokes the execution of the subprogram_body. The call specifies the association of the actual parameters, if any, with formal parameters of the subprogram. == Syntax == <p><span></span></p> procedure_call_statement<span id="I2994"></span> ::= ''procedure_''<span id="I2995"></span>name; | ''procedure_''<span id="I2996"></span>prefix <span id="I2997"></span>actual_parameter_part; <p><span></span></p> function_call<span id="I2998"></span> ::= ''function_''<span id="I2999"></span>name | ''function_''<span id="I3000"></span>prefix <span id="I3001"></span>actual_parameter_part <p><span></span></p> actual_parameter_part<span id="I3002"></span> ::= (<span id="I3003"></span>parameter_association {, <span id="I3004"></span>parameter_association}) <p><span></span></p> parameter_association<span id="I3005"></span> ::= [''formal_parameter_''<span id="I3006"></span>selector_name =>] <span id="I3007"></span>explicit_actual_parameter <p><span></span></p> explicit_actual_parameter<span id="I3008"></span> ::= <span id="I3009"></span>expression | ''variable_''<span id="I3010"></span>name <span id="I3011"></span><span id="I3012"></span>A parameter_association is ''named'' or ''positional'' according to whether or not the ''formal_parameter_''selector_name is specified. Any positional associations shall precede any named associations. Named associations are not allowed if the prefix in a subprogram call is an attribute_reference. == Name Resolution Rules == The name or prefix given in a procedure_call_statement shall resolve to denote a callable entity that is a procedure, or an entry renamed as (viewed as) a procedure. The name or prefix given in a function_call shall resolve to denote a callable entity that is a function. When there is an actual_parameter_part, the prefix can be an implicit_dereference of an access-to-subprogram value. A subprogram call shall contain at most one association for each formal parameter. Each formal parameter without an association shall have a default_expression (in the profile of the view denoted by the name or prefix). This rule is an overloading rule (see [[Guide:95lrm/RM-8-6|8.6]]). == Dynamic Semantics == <span id="I3013"></span>For the execution of a subprogram call, the name or prefix of the call is evaluated, and each parameter_association is evaluated (see [[Guide:95lrm/RM-6-4-1|6.4.1]]). If a default_expression is used, an implicit parameter_association is assumed for this rule. These evaluations are done in an arbitrary order. The subprogram_body is then executed. Finally, if the subprogram completes normally, then after it is left, any necessary assigning back of formal to actual parameters occurs (see [[Guide:95lrm/RM-6-4-1|6.4.1]]). <span id="I3014"></span>The exception Program_Error is raised at the point of a function_call if the function completes normally without executing a return_statement. A function_call denotes a constant, as defined in [[Guide:95lrm/RM-6-5|6.5]]; the nominal subtype of the constant is given by the result subtype of the function. <span id="I3015"></span><span id="I3016"></span> == Examples == ''Examples of procedure calls:'' <p><syntaxhighlight lang="Ada"> Traverse_Tree;                                               --  see 6.1 Print_Header(128, Title, True);                              --  see 6.1</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Switch(From => X, To => Next);                               --  see 6.1 Print_Header(128, Header => Title, Center => True);          --  see 6.1 Print_Header(Header => Title, Center => True, Pages => 128); --  see 6.1</syntaxhighlight></p> ''Examples of function calls:'' <p><syntaxhighlight lang="Ada"> Dot_Product(U, V)   --  see 6.1 and 6.3 Clock               --  see 9.6 F.all               --  presuming F is of an access-to-subprogram type -- see 3.10</syntaxhighlight></p> ''Examples of procedures with default expressions:'' <p><syntaxhighlight lang="Ada"> procedure Activate(Process : in Process_Name;                 After   : in Process_Name := No_Process;                 Wait    : in Duration := 0.0;                 Prior   : in Boolean := False);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> procedure Pair(Left, Right : in Person_Name := new Person);   --  see 3.10.1</syntaxhighlight></p> ''Examples of their calls:'' <p><syntaxhighlight lang="Ada"> Activate(X); Activate(X, After => Y); Activate(X, Wait => 60.0, Prior => True); Activate(X, Y, 10.0, False);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Pair; Pair(Left => new Person, Right => new Person);</syntaxhighlight></p> == Notes == 7  If a default_expression is used for two or more parameters in a multiple parameter_specification, the default_expression is evaluated once for each omitted parameter. Hence in the above examples, the two calls of Pair are equivalent. == Examples == ''Examples of overloaded subprograms:'' <p><syntaxhighlight lang="Ada"> procedure Put(X : in Integer); procedure Put(X : in String);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> procedure Set(Tint   : in Color); procedure Set(Signal : in Light);</syntaxhighlight></p> ''Examples of their calls:'' <p><syntaxhighlight lang="Ada"> Put(28); Put("no possible ambiguity here");</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Set(Tint   => Red); Set(Signal => Red); Set(Color'(Red));</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> --  Set(Red) would be ambiguous since Red may --  denote a value either of type Color or of type Light</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-6-3-2|Previous]] | [[Guide:95lrm/RM-6-4-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} s8butcsxis3uim6j3mzzsc6fulo3pdm Guide:95lrm/RM-6-4-1 4200 1022 3910 3909 2019-05-04T23:38:09Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-6-4|Previous]] | [[Guide:95lrm/RM-6-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 6.4.1 Parameter Associations}} <span id="I3017"></span>A parameter association defines the association between an actual parameter and a formal parameter. == Name Resolution Rules == The ''formal_parameter_''selector_name of a parameter_association shall resolve to denote a parameter_specification of the view being called. <span id="I3018"></span>The ''actual parameter'' is either the explicit_actual_parameter given in a parameter_association for a given formal parameter, or the corresponding default_expression if no parameter_association is given for the formal parameter. <span id="I3019"></span>The expected type for an actual parameter is the type of the corresponding formal parameter. If the mode is '''in''', the actual is interpreted as an expression; otherwise, the actual is interpreted only as a name, if possible. == Legality Rules == If the mode is '''in out''' or '''out''', the actual shall be a name that denotes a variable. The type of the actual parameter associated with an access parameter shall be convertible (see [[Guide:95lrm/RM-4-6|4.6]]) to its anonymous access type. <span id="I3020"></span> == Dynamic Semantics == <span id="I3021"></span>For the evaluation of a parameter_association: * The actual parameter is first evaluated. * For an access parameter, the access_definition is elaborated, which creates the anonymous access type. * For a parameter (of any mode) that is passed by reference (see [[Guide:95lrm/RM-6-2|6.2]]), a view conversion of the actual parameter to the nominal subtype of the formal parameter is evaluated, and the formal parameter denotes that conversion. <span id="I3022"></span> * <span id="I3023"></span>For an '''in''' or '''in out''' parameter that is passed by copy (see [[Guide:95lrm/RM-6-2|6.2]]), the formal parameter object is created, and the value of the actual parameter is converted to the nominal subtype of the formal parameter and assigned to the formal. <span id="I3024"></span> * For an '''out''' parameter that is passed by copy, the formal parameter object is created, and: <p><span></span></p> :* For an access type, the formal parameter is initialized from the value of the actual, without a constraint check; <p><span></span></p> :* For a composite type with discriminants or that has implicit initial values for any subcomponents (see [[Guide:95lrm/RM-3-3-1|3.3.1]]), the behavior is as for an '''in out''' parameter passed by copy. <p><span></span></p> :* For any other type, the formal parameter is uninitialized. If composite, a view conversion of the actual parameter to the nominal subtype of the formal is evaluated (which might raise Constraint_Error), and the actual subtype of the formal is that of the view conversion. If elementary, the actual subtype of the formal is given by its nominal subtype. <span id="I3025"></span><span id="I3026"></span>A formal parameter of mode '''in out''' or '''out''' with discriminants is constrained if either its nominal subtype or the actual parameter is constrained. <span id="I3027"></span><span id="I3028"></span><span id="I3029"></span><span id="I3030"></span><span id="I3031"></span>After normal completion and leaving of a subprogram, for each '''in out''' or '''out''' parameter that is passed by copy, the value of the formal parameter is converted to the subtype of the variable given as the actual parameter and assigned to it. <span id="I3032"></span>These conversions and assignments occur in an arbitrary order. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-6-4|Previous]] | [[Guide:95lrm/RM-6-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} gzgjige9n8hibwdja53qsuy8j2ewm3n Guide:95lrm/RM-6-5 4200 1023 3912 3911 2019-05-04T23:38:10Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-6-4-1|Previous]] | [[Guide:95lrm/RM-6-6|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 6.5 Return Statements}} A return_statement is used to complete the execution of the innermost enclosing subprogram_body, entry_body, or accept_statement. == Syntax == <p><span></span></p> return_statement<span id="I3033"></span> ::= '''return''' [<span id="I3034"></span>expression]; == Name Resolution Rules == <span id="I3035"></span>The expression, if any, of a return_statement is called the ''return expression''. <span id="I3036"></span>The ''result subtype'' of a function is the subtype denoted by the subtype_mark after the reserved word '''return''' in the profile of the function. <span id="I3037"></span>The expected type for a return expression is the result type of the corresponding function. == Legality Rules == <span id="I3038"></span>A return_statement shall be within a callable construct, and it ''applies to'' the innermost one. A return_statement shall not be within a body that is within the construct to which the return_statement applies. A function body shall contain at least one return_statement that applies to the function body, unless the function contains code_statements. A return_statement shall include a return expression if and only if it applies to a function body. == Dynamic Semantics == <span id="I3039"></span>For the execution of a return_statement, the expression (if any) is first evaluated and converted to the result subtype. <span id="I3040"></span> If the result type is class-wide, then the tag of the result is the tag of the value of the expression. If the result type is a specific tagged type: * <span id="I3041"></span><span id="I3042"></span>If it is limited, then a check is made that the tag of the value of the return expression identifies the result type. <span id="I3043"></span>Constraint_Error is raised if this check fails. * If it is nonlimited, then the tag of the result is that of the result type. <span id="I3044"></span>A type is a ''return-by-reference'' type if it is a descendant of one of the following: * a tagged limited type; * a task or protected type; * a nonprivate type with the reserved word '''limited''' in its declaration; * a composite type with a subcomponent of a return-by-reference type; * a private type whose full type is a return-by-reference type. <span id="I3045"></span><span id="I3046"></span>If the result type is a return-by-reference type, then a check is made that the return expression is one of the following: * a name that denotes an object view whose accessibility level is not deeper than that of the master that elaborated the function body; or * a parenthesized expression or qualified_expression whose operand is one of these kinds of expressions. <span id="I3047"></span>The exception Program_Error is raised if this check fails. For a function with a return-by-reference result type the result is returned by reference; that is, the function call denotes a constant view of the object associated with the value of the return expression. <span id="I3048"></span>For any other function, the result is returned by copy; that is, the converted value is assigned into an anonymous constant created at the point of the return_statement, and the function call denotes that object. Finally, a transfer of control is performed which completes the execution of the callable construct to which the return_statement applies, and returns to the caller. == Examples == ''Examples of return statements:'' <p><syntaxhighlight lang="Ada"> return;                         -- in a procedure body, entry_body, or accept_statement return Key_Value(Last_Index);   -- in a function body</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-6-4-1|Previous]] | [[Guide:95lrm/RM-6-6|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 89s14ek0kaiydfs0knz4xn6gjqspw7g Guide:95lrm/RM-6-6 4200 1024 3914 3913 2019-05-04T23:38:10Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-6-5|Previous]] | [[Guide:95lrm/RM-7|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 6.6 Overloading of Operators}} <span id="I3049"></span><span id="I3050"></span><span id="I3051"></span>An ''operator'' is a function whose designator is an operator_symbol. Operators, like other functions, may be overloaded. == Name Resolution Rules == Each use of a unary or binary operator is equivalent to a function_call with ''function_''prefix being the corresponding operator_symbol, and with (respectively) one or two positional actual parameters being the operand(s) of the operator (in order). == Legality Rules == The subprogram_specification of a unary or binary operator shall have one or two parameters, respectively. A generic function instantiation whose designator is an operator_symbol is only allowed if the specification of the generic function has the corresponding number of parameters. Default_expressions are not allowed for the parameters of an operator (whether the operator is declared with an explicit subprogram_specification or by a generic_instantiation). An explicit declaration of "/=" shall not have a result type of the predefined type Boolean. == Static Semantics == A declaration of "=" whose result type is Boolean implicitly declares a declaration of "/=" that gives the complementary result. == Notes == 8  The operators "+" and "-" are both unary and binary operators, and hence may be overloaded with both one- and two-parameter functions. == Examples == ''Examples of user-defined operators:'' <p><syntaxhighlight lang="Ada"> function "+" (Left, Right : Matrix) return Matrix; function "+" (Left, Right : Vector) return Vector; --  assuming that A, B, and C are of the type Vector --  the following two statements are equivalent: A := B + C; A := "+"(B, C);</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-6-5|Previous]] | [[Guide:95lrm/RM-7|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} k3r3qhujln18krxdjqvwwpwjq7fpjnr Guide:95lrm/RM-7 4200 1025 3916 3915 2019-05-04T23:38:10Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-6-6|Previous]] | [[Guide:95lrm/RM-7-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Section 7: Packages}} <span id="I3052"></span>Packages are program units that allow the specification of groups of logically related entities. Typically, a package contains the declaration of a type (often a private type or private extension) along with the declarations of primitive subprograms of the type, which can be called from outside the package, while their inner workings remain hidden from outside users. <span id="I3053"></span><span id="I3054"></span><span id="I3055"></span><span id="I3056"></span> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-6-6|Previous]] | [[Guide:95lrm/RM-7-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} f5m9nf8pe33xadv77ydfat2iyf9r6or Guide:95lrm/RM-7-1 4200 1026 3918 3917 2019-05-04T23:38:12Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-7|Previous]] | [[Guide:95lrm/RM-7-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 7.1 Package Specifications and Declarations}} A package is generally provided in two parts: a package_specification and a package_body. Every package has a package_specification, but not all packages have a package_body. == Syntax == <p><span></span></p> package_declaration<span id="I3057"></span> ::= <span id="I3058"></span>package_specification; <p><span></span></p> package_specification<span id="I3059"></span> ::= '''package''' <span id="I3060"></span>defining_program_unit_name '''is''' {<span id="I3061"></span>basic_declarative_item} ['''private''' {<span id="I3062"></span>basic_declarative_item}] '''end''' [[<span id="I3063"></span>parent_unit_name.]<span id="I3064"></span>identifier] If an identifier or parent_unit_name.identifier appears at the end of a package_specification, then this sequence of lexical elements shall repeat the defining_program_unit_name. == Legality Rules == <span id="I3065"></span><span id="I3066"></span>A package_declaration or generic_package_declaration requires a completion (a body) if it contains any declarative_item that requires a completion, but whose completion is not in its package_specification. == Static Semantics == <span id="I3067"></span>The first list of declarative_items of a package_specification of a package other than a generic formal package is called the ''visible part'' of the package. <span id="I3068"></span>The optional list of declarative_items after the reserved word '''private''' (of any package_specification) is called the ''private part'' of the package. If the reserved word '''private''' does not appear, the package has an implicit empty private part. An entity declared in the private part of a package is visible only within the declarative region of the package itself (including any child units -- see [[Guide:95lrm/RM-10-1-1|10.1.1]]). In contrast, expanded names denoting entities declared in the visible part can be used even outside the package; furthermore, direct visibility of such entities can be achieved by means of use_clauses (see [[Guide:95lrm/RM-4-1-3|4.1.3]] and [[Guide:95lrm/RM-8-4|8.4]]). == Dynamic Semantics == <span id="I3069"></span>The elaboration of a package_declaration consists of the elaboration of its basic_declarative_items in the given order. == Notes == 1  The visible part of a package contains all the information that another program unit is able to know about the package. 2  If a declaration occurs immediately within the specification of a package, and the declaration has a corresponding completion that is a body, then that body has to occur immediately within the body of the package. == Examples == ''Example of a package declaration:'' <p><syntaxhighlight lang="Ada"> package Rational_Numbers is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     type Rational is    record       Numerator   : Integer;       Denominator : Positive;     end record;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     function "="(X,Y : Rational) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     function "/"  (X,Y : Integer)  return Rational;   --  to construct a rational number</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     function "+"  (X,Y : Rational) return Rational; function "-"  (X,Y : Rational) return Rational; function "*"  (X,Y : Rational) return Rational; function "/"  (X,Y : Rational) return Rational; end Rational_Numbers;</syntaxhighlight></p> There are also many examples of package declarations in the predefined language environment (see [[Guide:95lrm/RM-A|Annex A]]). </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-7|Previous]] | [[Guide:95lrm/RM-7-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} bsbxw35igk8x344fhcwuetfhtnq6q2z Guide:95lrm/RM-7-2 4200 1027 3920 3919 2019-05-04T23:38:14Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-7-1|Previous]] | [[Guide:95lrm/RM-7-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 7.2 Package Bodies}} In contrast to the entities declared in the visible part of a package, the entities declared in the package_body are visible only within the package_body itself. As a consequence, a package with a package_body can be used for the construction of a group of related subprograms in which the logical operations available to clients are clearly isolated from the internal entities. == Syntax == <p><span></span></p> package_body<span id="I3070"></span> ::= '''package''' '''body''' <span id="I3071"></span>defining_program_unit_name '''is''' <span id="I3072"></span>declarative_part ['''begin''' <span id="I3073"></span>handled_sequence_of_statements] '''end''' [[<span id="I3074"></span>parent_unit_name.]<span id="I3075"></span>identifier]; If an identifier or parent_unit_name.identifier appears at the end of a package_body, then this sequence of lexical elements shall repeat the defining_program_unit_name. == Legality Rules == A package_body shall be the completion of a previous package_declaration or generic_package_declaration. A library package_declaration or library generic_package_declaration shall not have a body unless it requires a body; '''pragma''' Elaborate_Body can be used to require a library_unit_declaration to have a body (see [[Guide:95lrm/RM-10-2-1|10.2.1]]) if it would not otherwise require one. == Static Semantics == In any package_body without statements there is an implicit null_statement. For any package_declaration without an explicit completion, there is an implicit package_body containing a single null_statement. For a noninstance, nonlibrary package, this body occurs at the end of the declarative_part of the innermost enclosing program unit or block_statement; if there are several such packages, the order of the implicit package_bodies is unspecified. <span id="I3076"></span>(For an instance, the implicit package_body occurs at the place of the instantiation (see [[Guide:95lrm/RM-12-3|12.3]]). For a library package, the place is partially determined by the elaboration dependences (see Section 10).) == Dynamic Semantics == <span id="I3077"></span>For the elaboration of a nongeneric package_body, its declarative_part is first elaborated, and its handled_sequence_of_statements is then executed. == Notes == 3  A variable declared in the body of a package is only visible within this body and, consequently, its value can only be changed within the package_body. In the absence of local tasks, the value of such a variable remains unchanged between calls issued from outside the package to subprograms declared in the visible part. The properties of such a variable are similar to those of a ''static'' variable of C. 4  The elaboration of the body of a subprogram explicitly declared in the visible part of a package is caused by the elaboration of the body of the package. Hence a call of such a subprogram by an outside program unit raises the exception Program_Error if the call takes place before the elaboration of the package_body (see [[Guide:95lrm/RM-3-11|3.11]]). == Examples == ''Example of a package body (see [[Guide:95lrm/RM-7-1|7.1]]):'' <p><syntaxhighlight lang="Ada"> package body Rational_Numbers is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Same_Denominator (X,Y : in out Rational) is begin    --  reduces X and Y to the same denominator:    ... end Same_Denominator;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "="(X,Y : Rational) return Boolean is    U : Rational := X;    V : Rational := Y; begin    Same_Denominator (U,V);    return U.Numerator = V.Numerator; end "=";</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "/" (X,Y : Integer) return Rational is begin    if Y > 0 then       return (Numerator => X,  Denominator => Y);    else       return (Numerator => -X, Denominator => -Y); end if; end "/";</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "+" (X,Y : Rational) return Rational is ... end "+"; function "-" (X,Y : Rational) return Rational is ... end "-"; function "*" (X,Y : Rational) return Rational is ... end "*"; function "/" (X,Y : Rational) return Rational is ... end "/";</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> end Rational_Numbers;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-7-1|Previous]] | [[Guide:95lrm/RM-7-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 5q95skhv1kjia41fm885g3x08iegwg0 Guide:95lrm/RM-7-3 4200 1028 3922 3921 2019-05-04T23:38:16Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-7-2|Previous]] | [[Guide:95lrm/RM-7-3-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 7.3 Private Types and Private Extensions}} The declaration (in the visible part of a package) of a type as a private type or private extension serves to separate the characteristics that can be used directly by outside program units (that is, the logical properties) from other characteristics whose direct use is confined to the package (the details of the definition of the type itself). See [[Guide:95lrm/RM-3-9-1|3.9.1]] for an overview of type extensions. <span id="I3078"></span><span id="I3079"></span><span id="I3080"></span><span id="I3081"></span><span id="I3082"></span> == Syntax == <p><span></span></p> private_type_declaration<span id="I3083"></span> ::= '''type''' <span id="I3084"></span>defining_identifier [<span id="I3085"></span>discriminant_part] '''is''' [['''abstract'''] '''tagged'''] ['''limited'''] '''private'''; <p><span></span></p> private_extension_declaration<span id="I3086"></span> ::= '''type''' <span id="I3087"></span>defining_identifier [<span id="I3088"></span>discriminant_part] '''is''' ['''abstract'''] '''new''' ''ancestor_''<span id="I3089"></span>subtype_indication '''with private'''; == Legality Rules == <span id="I3090"></span><span id="I3091"></span>A private_type_declaration or private_extension_declaration declares a ''partial view'' of the type; such a declaration is allowed only as a declarative_item of the visible part of a package, and it requires a completion, which shall be a full_type_declaration that occurs as a declarative_item of the private part of the package. <span id="I3092"></span>The view of the type declared by the full_type_declaration is called the ''full view''. A generic formal private type or a generic formal private extension is also a partial view. A type shall be completely defined before it is frozen (see [[Guide:95lrm/RM-3-11-1|3.11.1]] and [[Guide:95lrm/RM-13-14|13.14]]). Thus, neither the declaration of a variable of a partial view of a type, nor the creation by an allocator of an object of the partial view are allowed before the full declaration of the type. Similarly, before the full declaration, the name of the partial view cannot be used in a generic_instantiation or in a representation item. A private type is limited if its declaration includes the reserved word '''limited'''; a private extension is limited if its ancestor type is limited. If the partial view is nonlimited, then the full view shall be nonlimited. If a tagged partial view is limited, then the full view shall be limited. On the other hand, if an untagged partial view is limited, the full view may be limited or nonlimited. If the partial view is tagged, then the full view shall be tagged. On the other hand, if the partial view is untagged, then the full view may be tagged or untagged. In the case where the partial view is untagged and the full view is tagged, no derivatives of the partial view are allowed within the immediate scope of the partial view; derivatives of the full view are allowed. <span id="I3093"></span>The ''ancestor subtype'' of a private_extension_declaration is the subtype defined by the ''ancestor_''subtype_indication; the ancestor type shall be a specific tagged type. The full view of a private extension shall be derived (directly or indirectly) from the ancestor type. In addition to the places where Legality Rules normally apply (see [[Guide:95lrm/RM-12-3|12.3]]), the requirement that the ancestor be specific applies also in the private part of an instance of a generic unit. If the declaration of a partial view includes a known_discriminant_part, then the full_type_declaration shall have a fully conforming (explicit) known_discriminant_part (see [[Guide:95lrm/RM-6-3-1|6.3.1]], ''[[Guide:95lrm/RM-6-3-1|Conformance Rules]]''). <span id="I3094"></span>The ancestor subtype may be unconstrained; the parent subtype of the full view is required to be constrained (see [[Guide:95lrm/RM-3-7|3.7]]). If a private extension inherits known discriminants from the ancestor subtype, then the full view shall also inherit its discriminants from the ancestor subtype, and the parent subtype of the full view shall be constrained if and only if the ancestor subtype is constrained. If a partial view has unknown discriminants, then the full_type_declaration may define a definite or an indefinite subtype, with or without discriminants. If a partial view has neither known nor unknown discriminants, then the full_type_declaration shall define a definite subtype. If the ancestor subtype of a private extension has constrained discriminants, then the parent subtype of the full view shall impose a statically matching constraint on those discriminants. <span id="I3095"></span> == Static Semantics == <span id="I3096"></span>A private_type_declaration declares a private type and its first subtype. <span id="I3097"></span>Similarly, a private_extension_declaration declares a private extension and its first subtype. A declaration of a partial view and the corresponding full_type_declaration define two views of a single type. The declaration of a partial view together with the visible part define the operations that are available to outside program units; the declaration of the full view together with the private part define other operations whose direct use is possible only within the declarative region of the package itself. <span id="I3098"></span>Moreover, within the scope of the declaration of the full view, the ''characteristics'' of the type are determined by the full view; in particular, within its scope, the full view determines the classes that include the type, which components, entries, and protected subprograms are visible, what attributes and other predefined operations are allowed, and whether the first subtype is static. See [[Guide:95lrm/RM-7-3-1|7.3.1]]. A private extension inherits components (including discriminants unless there is a new discriminant_part specified) and user-defined primitive subprograms from its ancestor type, in the same way that a record extension inherits components and user-defined primitive subprograms from its parent type (see [[Guide:95lrm/RM-3-4|3.4]]). == Dynamic Semantics == <span id="I3099"></span>The elaboration of a private_type_declaration creates a partial view of a type. <span id="I3100"></span>The elaboration of a private_extension_declaration elaborates the ''ancestor_''subtype_indication, and creates a partial view of a type. == Notes == 5  The partial view of a type as declared by a private_type_declaration is defined to be a composite view (in [[Guide:95lrm/RM-3-2|3.2]]). The full view of the type might or might not be composite. A private extension is also composite, as is its full view. 6  Declaring a private type with an unknown_discriminant_part is a way of preventing clients from creating uninitialized objects of the type; they are then forced to initialize each object by calling some operation declared in the visible part of the package. If such a type is also limited, then no objects of the type can be declared outside the scope of the full_type_declaration, restricting all object creation to the package defining the type. This allows complete control over all storage allocation for the type. Objects of such a type can still be passed as parameters, however. 7  The ancestor type specified in a private_extension_declaration and the parent type specified in the corresponding declaration of a record extension given in the private part need not be the same -- the parent type of the full view can be any descendant of the ancestor type. In this case, for a primitive subprogram that is inherited from the ancestor type and not overridden, the formal parameter names and default expressions (if any) come from the corresponding primitive subprogram of the specified ancestor type, while the body comes from the corresponding primitive subprogram of the parent type of the full view. See [[Guide:95lrm/RM-3-9-2|3.9.2]]. == Examples == ''Examples of private type declarations:'' <p><syntaxhighlight lang="Ada"> type Key is private; type File_Name is limited private;</syntaxhighlight></p> ''Example of a private extension declaration:'' <p><syntaxhighlight lang="Ada"> type List is new Ada.Finalization.Controlled with private;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-7-2|Previous]] | [[Guide:95lrm/RM-7-3-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 93rp57mhft8e2kt8vqwhg48u5biro9z Guide:95lrm/RM-7-3-1 4200 1029 3924 3923 2019-05-04T23:38:17Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-7-3|Previous]] | [[Guide:95lrm/RM-7-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 7.3.1 Private Operations}} For a type declared in the visible part of a package or generic package, certain operations on the type do not become visible until later in the package -- either in the private part or the body. <span id="I3101"></span>Such ''private operations'' are available only inside the declarative region of the package or generic package. == Static Semantics == The predefined operators that exist for a given type are determined by the classes to which the type belongs. For example, an integer type has a predefined "+" operator. In most cases, the predefined operators of a type are declared immediately after the definition of the type; the exceptions are explained below. Inherited subprograms are also implicitly declared immediately after the definition of the type, except as stated below. For a composite type, the characteristics (see [[Guide:95lrm/RM-7-3|7.3]]) of the type are determined in part by the characteristics of its component types. At the place where the composite type is declared, the only characteristics of component types used are those characteristics visible at that place. If later immediately within the declarative region in which the composite type is declared additional characteristics become visible for a component type, then any corresponding characteristics become visible for the composite type. Any additional predefined operators are implicitly declared at that place. The corresponding rule applies to a type defined by a derived_type_definition, if there is a place immediately within the declarative region in which the type is declared where additional characteristics of its parent type become visible. <span id="I3102"></span><span id="I3103"></span><span id="I3104"></span>For example, an array type whose component type is limited private becomes nonlimited if the full view of the component type is nonlimited and visible at some later place immediately within the declarative region in which the array type is declared. In such a case, the predefined "=" operator is implicitly declared at that place, and assignment is allowed after that place. Inherited primitive subprograms follow a different rule. For a derived_type_definition, each inherited primitive subprogram is implicitly declared at the earliest place, if any, immediately within the declarative region in which the type_declaration occurs, but after the type_declaration, where the corresponding declaration from the parent is visible. If there is no such place, then the inherited subprogram is not declared at all. An inherited subprogram that is not declared at all cannot be named in a call and cannot be overridden, but for a tagged type, it is possible to dispatch to it. For a private_extension_declaration, each inherited subprogram is declared immediately after the private_extension_declaration if the corresponding declaration from the ancestor is visible at that place. Otherwise, the inherited subprogram is not declared for the private extension, though it might be for the full type. The Class attribute is defined for tagged subtypes in [[Guide:95lrm/RM-3-9|3.9]]. In addition, for every subtype S of an untagged private type whose full view is tagged, the following attribute is defined: ; S'Class : <span id="I3105"></span><span id="I3106"></span>Denotes the class-wide subtype corresponding to the full view of S. This attribute is allowed only from the beginning of the private part in which the full view is declared, until the declaration of the full view. After the full view, the Class attribute of the full view can be used. == Notes == 8  Because a partial view and a full view are two different views of one and the same type, outside of the defining package the characteristics of the type are those defined by the visible part. Within these outside program units the type is just a private type or private extension, and any language rule that applies only to another class of types does not apply. The fact that the full declaration might implement a private type with a type of a particular class (for example, as an array type) is relevant only within the declarative region of the package itself including any child units. The consequences of this actual implementation are, however, valid everywhere. For example: any default initialization of components takes place; the attribute Size provides the size of the full view; finalization is still done for controlled components of the full view; task dependence rules still apply to components that are task objects. 9  Partial views provide assignment (unless the view is limited), membership tests, selected components for the selection of discriminants and inherited components, qualification, and explicit conversion. 10  For a subtype S of a partial view, S'Size is defined (see [[Guide:95lrm/RM-13-3|13.3]]). For an object A of a partial view, the attributes A'Size and A'Address are defined (see [[Guide:95lrm/RM-13-3|13.3]]). The Position, First_Bit, and Last_Bit attributes are also defined for discriminants and inherited components. == Examples == ''Example of a type with private operations:'' <p><syntaxhighlight lang="Ada"> package Key_Manager is type Key is private; Null_Key : constant Key; -- a deferred constant declaration (see 7.4) procedure Get_Key(K : out Key); function "<" (X, Y : Key) return Boolean; private type Key is new Natural; Null_Key : constant Key := Key'First; end Key_Manager;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> package body Key_Manager is Last_Key : Key := Null_Key; procedure Get_Key(K : out Key) is begin    Last_Key := Last_Key + 1;    K := Last_Key; end Get_Key;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function "<" (X, Y : Key) return Boolean is begin    return Natural(X) < Natural(Y); end "<"; end Key_Manager;</syntaxhighlight></p> == Notes == 11  ''Notes on the example:'' Outside of the package Key_Manager, the operations available for objects of type Key include assignment, the comparison for equality or inequality, the procedure Get_Key and the operator "<"; they do not include other relational operators such as ">=", or arithmetic operators. The explicitly declared operator "<" hides the predefined operator "<" implicitly declared by the full_type_declaration. Within the body of the function, an explicit conversion of X and Y to the subtype Natural is necessary to invoke the "<" operator of the parent type. Alternatively, the result of the function could be written as not (X >= Y), since the operator ">=" is not redefined. The value of the variable Last_Key, declared in the package body, remains unchanged between calls of the procedure Get_Key. (See also the NOTES of [[Guide:95lrm/RM-7-2|7.2]].) </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-7-3|Previous]] | [[Guide:95lrm/RM-7-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 79mqdqbypa7yg4dwi3fg6rjabsdlvl9 Guide:95lrm/RM-7-4 4200 1030 3926 3925 2019-05-04T23:38:18Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-7-3-1|Previous]] | [[Guide:95lrm/RM-7-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 7.4 Deferred Constants}} Deferred constant declarations may be used to declare constants in the visible part of a package, but with the value of the constant given in the private part. They may also be used to declare constants imported from other languages (see [[Guide:95lrm/RM-B|Annex B]]). == Legality Rules == <span id="I3107"></span>A ''deferred constant declaration'' is an object_declaration with the reserved word '''constant''' but no initialization expression. <span id="I3108"></span>The constant declared by a deferred constant declaration is called a ''deferred constant''. <span id="I3109"></span>A deferred constant declaration requires a completion, which shall be a full constant declaration (called the ''full declaration'' of the deferred constant), or a pragma Import (see [[Guide:95lrm/RM-B|Annex B]]). <span id="I3110"></span> A deferred constant declaration that is completed by a full constant declaration shall occur immediately within the visible part of a package_specification. For this case, the following additional rules apply to the corresponding full declaration: * The full declaration shall occur immediately within the private part of the same package; * The deferred and full constants shall have the same type; * If the subtype defined by the subtype_indication in the deferred declaration is constrained, then the subtype defined by the subtype_indication in the full declaration shall match it statically. On the other hand, if the subtype of the deferred constant is unconstrained, then the full declaration is still allowed to impose a constraint. The constant itself will be constrained, like all constants; * If the deferred constant declaration includes the reserved word '''aliased''', then the full declaration shall also. A deferred constant declaration that is completed by a pragma Import need not appear in the visible part of a package_specification, and has no full constant declaration. The completion of a deferred constant declaration shall occur before the constant is frozen (see [[Guide:95lrm/RM-7-4|7.4]]). == Dynamic Semantics == <span id="I3111"></span>The elaboration of a deferred constant declaration elaborates the subtype_indication or (only allowed in the case of an imported constant) the array_type_definition. == Notes == 12  The full constant declaration for a deferred constant that is of a given private type or private extension is not allowed before the corresponding full_type_declaration. This is a consequence of the freezing rules for types (see [[Guide:95lrm/RM-13-14|13.14]]). == Examples == ''Examples of deferred constant declarations:'' <p><syntaxhighlight lang="Ada"> Null_Key : constant Key;      -- see 7.3.1</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> CPU_Identifier : constant String(1..8); pragma Import(Assembler, CPU_Identifier, Link_Name => "CPU_ID");                          -- see B.1</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-7-3-1|Previous]] | [[Guide:95lrm/RM-7-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 02qgmrbqar82npntftzw7u8ffzkcr5e Guide:95lrm/RM-7-5 4200 1031 3928 3927 2019-05-04T23:38:19Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-7-4|Previous]] | [[Guide:95lrm/RM-7-6|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 7.5 Limited Types}} <span id="I3112"></span>A limited type is (a view of) a type for which the assignment operation is not allowed. A nonlimited type is a (view of a) type for which the assignment operation is allowed. == Legality Rules == If a tagged record type has any limited components, then the reserved word '''limited''' shall appear in its record_type_definition. == Static Semantics == <span id="I3113"></span>A type is ''limited'' if it is a descendant of one of the following: * a type with the reserved word '''limited''' in its definition; * a task or protected type; * a composite type with a limited component. <span id="I3114"></span>Otherwise, the type is nonlimited. There are no predefined equality operators for a limited type. == Notes == 13  The following are consequences of the rules for limited types: * An initialization expression is not allowed in an object_declaration if the type of the object is limited. * A default expression is not allowed in a component_declaration if the type of the record component is limited. * An initialized allocator is not allowed if the designated type is limited. * A generic formal parameter of mode '''in''' must not be of a limited type. 14  Aggregates are not available for a limited composite type. Concatenation is not available for a limited array type. 15  The rules do not exclude a default_expression for a formal parameter of a limited type; they do not exclude a deferred constant of a limited type if the full declaration of the constant is of a nonlimited type. 16  <span id="I3115"></span><span id="I3116"></span><span id="I3117"></span>As illustrated in [[Guide:95lrm/RM-7-3-1|7.3.1]], an untagged limited type can become nonlimited under certain circumstances. == Examples == ''Example of a package with a limited type:'' <p><syntaxhighlight lang="Ada"> package IO_Package is type File_Name is limited private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Open (F : in out File_Name); procedure Close(F : in out File_Name); procedure Read (F : in File_Name; Item : out Integer); procedure Write(F : in File_Name; Item : in  Integer); private type File_Name is    limited record       Internal_Name : Integer := 0;     end record; end IO_Package;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> package body IO_Package is Limit : constant := 200; type File_Descriptor is record  ...  end record; Directory : array (1 .. Limit) of File_Descriptor; ... procedure Open (F : in out File_Name) is  ...  end; procedure Close(F : in out File_Name) is  ...  end; procedure Read (F : in File_Name; Item : out Integer) is ... end; procedure Write(F : in File_Name; Item : in  Integer) is ... end; begin ... end IO_Package;</syntaxhighlight></p> == Notes == 17  ''Notes on the example:'' In the example above, an outside subprogram making use of IO_Package may obtain a file name by calling Open and later use it in calls to Read and Write. Thus, outside the package, a file name obtained from Open acts as a kind of password; its internal properties (such as containing a numeric value) are not known and no other operations (such as addition or comparison of internal names) can be performed on a file name. Most importantly, clients of the package cannot make copies of objects of type File_Name. This example is characteristic of any case where complete control over the operations of a type is desired. Such packages serve a dual purpose. They prevent a user from making use of the internal structure of the type. They also implement the notion of an encapsulated data type where the only operations on the type are those given in the package specification. The fact that the full view of File_Name is explicitly declared '''limited''' means that parameter passing and function return will always be by reference (see [[Guide:95lrm/RM-6-2|6.2]] and [[Guide:95lrm/RM-6-5|6.5]]). </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-7-4|Previous]] | [[Guide:95lrm/RM-7-6|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} r4w75rdt0j2pz59qf3cc4uwny3q2sky Guide:95lrm/RM-7-6 4200 1032 3930 3929 2019-05-04T23:38:21Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-7-5|Previous]] | [[Guide:95lrm/RM-7-6-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 7.6 User-Defined Assignment and Finalization}} <span id="I3118"></span><span id="I3119"></span>Three kinds of actions are fundamental to the manipulation of objects: initialization, finalization, and assignment. Every object is initialized, either explicitly or by default, after being created (for example, by an object_declaration or allocator). Every object is finalized before being destroyed (for example, by leaving a subprogram_body containing an object_declaration, or by a call to an instance of Unchecked_Deallocation). An assignment operation is used as part of assignment_statements, explicit initialization, parameter passing, and other operations. <span id="I3120"></span><span id="I3121"></span><span id="I3122"></span> Default definitions for these three fundamental operations are provided by the language, but <span id="I3123"></span>a ''controlled'' type gives the user additional control over parts of these operations. <span id="I3124"></span><span id="I3125"></span><span id="I3126"></span>In particular, the user can define, for a controlled type, an Initialize procedure which is invoked immediately after the normal default initialization of a controlled object, a Finalize procedure which is invoked immediately before finalization of any of the components of a controlled object, and an Adjust procedure which is invoked as the last step of an assignment to a (nonlimited) controlled object. == Static Semantics == The following language-defined library package exists: <p><syntaxhighlight lang="Ada"> package Ada.Finalization is  pragma Preelaborate(Finalization);  pragma Remote_Types(Finalization);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     type Controlled is abstract tagged private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     procedure Initialize (Object : in out Controlled);  procedure Adjust   (Object : in out Controlled);  procedure Finalize (Object : in out Controlled);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     type Limited_Controlled is abstract tagged limited private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     procedure Initialize (Object : in out Limited_Controlled);  procedure Finalize (Object : in out Limited_Controlled); private  ... -- not specified by the language end Ada.Finalization;</syntaxhighlight></p> <span id="I3144"></span>A controlled type is a descendant of Controlled or Limited_Controlled. The (default) implementations of Initialize, Adjust, and Finalize have no effect. The predefined "=" operator of type Controlled always returns True, since this operator is incorporated into the implementation of the predefined equality operator of types derived from Controlled, as explained in [[Guide:95lrm/RM-4-5-2|4.5.2]]. The type Limited_Controlled is like Controlled, except that it is limited and it lacks the primitive subprogram Adjust. == Dynamic Semantics == <span id="I3145"></span>During the elaboration of an object_declaration, for every controlled subcomponent of the object that is not assigned an initial value (as defined in [[Guide:95lrm/RM-3-3-1|3.3.1]]), Initialize is called on that subcomponent. Similarly, if the object as a whole is controlled and is not assigned an initial value, Initialize is called on the object. The same applies to the evaluation of an allocator, as explained in [[Guide:95lrm/RM-4-8|4.8]]. For an extension_aggregate whose ancestor_part is a subtype_mark, for each controlled subcomponent of the ancestor part, either Initialize is called, or its initial value is assigned, as appropriate; if the type of the ancestor part is itself controlled, the Initialize procedure of the ancestor type is called, unless that Initialize procedure is abstract. Initialize and other initialization operations are done in an arbitrary order, except as follows. Initialize is applied to an object after initialization of its subcomponents, if any (including both implicit initialization and Initialize calls). If an object has a component with an access discriminant constrained by a per-object expression, Initialize is applied to this component after any components that do not have such discriminants. For an object with several components with such a discriminant, Initialize is applied to them in order of their component_declarations. For an allocator, any task activations follow all calls on Initialize. <span id="I3146"></span>When a target object with any controlled parts is assigned a value, either when created or in a subsequent assignment_statement, the ''assignment operation'' proceeds as follows: * The value of the target becomes the assigned value. * <span id="I3147"></span><span id="I3148"></span>The value of the target is ''adjusted.'' <span id="I3149"></span><span id="I3150"></span>To adjust the value of a (nonlimited) composite object, the values of the components of the object are first adjusted in an arbitrary order, and then, if the object is controlled, Adjust is called. Adjusting the value of an elementary object has no effect, nor does adjusting the value of a composite object with no controlled parts. <span id="I3151"></span>For an assignment_statement, after the name and expression have been evaluated, and any conversion (including constraint checking) has been done, an anonymous object is created, and the value is assigned into it; that is, the assignment operation is applied. (Assignment includes value adjustment.) The target of the assignment_statement is then finalized. The value of the anonymous object is then assigned into the target of the assignment_statement. Finally, the anonymous object is finalized. As explained below, the implementation may eliminate the intermediate anonymous object, so this description subsumes the one given in [[Guide:95lrm/RM-5-2|5.2]], ''[[Guide:95lrm/RM-5-2|Assignment Statements]]''. == Implementation Requirements == <div> For an aggregate of a controlled type whose value is assigned, other than by an assignment_statement or a return_statement, the implementation shall not create a separate anonymous object for the aggregate. The aggregate value shall be constructed directly in the target of the assignment operation and Adjust is not called on the target object.</div> == Implementation Permissions == An implementation is allowed to relax the above rules (for nonlimited controlled types) in the following ways: * For an assignment_statement that assigns to an object the value of that same object, the implementation need not do anything. * For an assignment_statement for a noncontrolled type, the implementation may finalize and assign each component of the variable separately (rather than finalizing the entire variable and assigning the entire new value) unless a discriminant of the variable is changed by the assignment. * For an aggregate or function call whose value is assigned into a target object, the implementation need not create a separate anonymous object if it can safely create the value of the aggregate or function call directly in the target object. Similarly, for an assignment_statement, the implementation need not create an anonymous object if the value being assigned is the result of evaluating a name denoting an object (the source object) whose storage cannot overlap with the target. If the source object might overlap with the target object, then the implementation can avoid the need for an intermediary anonymous object by exercising one of the above permissions and perform the assignment one component at a time (for an overlapping array assignment), or not at all (for an assignment where the target and the source of the assignment are the same object). Even if an anonymous object is created, the implementation may move its value to the target object as part of the assignment without re-adjusting so long as the anonymous object has no aliased subcomponents. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-7-5|Previous]] | [[Guide:95lrm/RM-7-6-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} imbnwzipanv4fn48rn8oidqup2sv1wg Guide:95lrm/RM-7-6-1 4200 1033 3932 3931 2019-05-04T23:38:22Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-7-6|Previous]] | [[Guide:95lrm/RM-8|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 7.6.1 Completion and Finalization}} This subclause defines ''completion'' and ''leaving'' of the execution of constructs and entities. A ''master'' is the execution of a construct that includes finalization of local objects after it is complete (and after waiting for any local tasks -- see [[Guide:95lrm/RM-9-3|9.3]]), but before leaving. Other constructs and entities are left immediately upon completion. <span id="I3152"></span><span id="I3153"></span> == Dynamic Semantics == <span id="I3154"></span><span id="I3155"></span>The execution of a construct or entity is ''complete'' when the end of that execution has been reached, or when a transfer of control (see [[Guide:95lrm/RM-5-1|5.1]]) causes it to be abandoned. <span id="I3156"></span><span id="I3157"></span><span id="I3158"></span><span id="I3159"></span>Completion due to reaching the end of execution, or due to the transfer of control of an exit_, return_, goto_, or requeue_statement or of the selection of a terminate_alternative is ''normal completion''. Completion is ''abnormal'' otherwise -- when control is transferred out of a construct due to abort or the raising of an exception. <span id="I3160"></span><span id="I3161"></span>After execution of a construct or entity is complete, it is ''left'', meaning that execution continues with the next action, as defined for the execution that is taking place. <span id="I3162"></span>Leaving an execution happens immediately after its completion, except in the case of a ''master'': the execution of a task_body, a block_statement, a subprogram_body, an entry_body, or an accept_statement. A master is finalized after it is complete, and before it is left. <span id="I3163"></span>For the ''finalization'' of a master, dependent tasks are first awaited, as explained in [[Guide:95lrm/RM-9-3|9.3]]. Then each object whose accessibility level is the same as that of the master is finalized if the object was successfully initialized and still exists. These actions are performed whether the master is left by reaching the last statement or via a transfer of control. When a transfer of control causes completion of an execution, each included master is finalized in order, from innermost outward. <span id="I3164"></span>For the ''finalization'' of an object: * If the object is of an elementary type, finalization has no effect; * If the object is of a controlled type, the Finalize procedure is called; * If the object is of a protected type, the actions defined in [[Guide:95lrm/RM-9-4|9.4]] are performed; * If the object is of a composite type, then after performing the above actions, if any, every component of the object is finalized in an arbitrary order, except as follows: if the object has a component with an access discriminant constrained by a per-object expression, this component is finalized before any components that do not have such discriminants; for an object with several components with such a discriminant, they are finalized in the reverse of the order of their component_declarations. <span id="I3165"></span>Immediately before an instance of Unchecked_Deallocation reclaims the storage of an object, the object is finalized. If an instance of Unchecked_Deallocation is never applied to an object created by an allocator, the object will still exist when the corresponding master completes, and it will be finalized then. The order in which the finalization of a master performs finalization of objects is as follows: Objects created by declarations in the master are finalized in the reverse order of their creation. For objects that were created by allocators for an access type whose ultimate ancestor is declared in the master, this rule is applied as though each such object that still exists had been created in an arbitrary order at the first freezing point (see [[Guide:95lrm/RM-13-14|13.14]]) of the ultimate ancestor type. <span id="I3166"></span>The target of an assignment statement is finalized before copying in the new value, as explained in [[Guide:95lrm/RM-7-6|7.6]]. If the object_name in an object_renaming_declaration, or the actual parameter for a generic formal '''in out''' parameter in a generic_instantiation, denotes any part of an anonymous object created by a function call, the anonymous object is not finalized until after it is no longer accessible via any name. Otherwise, an anonymous object created by a function call or by an aggregate is finalized no later than the end of the innermost enclosing declarative_item or statement; if that is a compound_statement, the object is finalized before starting the execution of any statement within the compound_statement. <div> If a transfer of control or raising of an exception occurs prior to performing a finalization of an anonymous object, the anonymous object is finalized as part of the finalizations due to be performed for the object's innermost enclosing master.</div> == Bounded (Run-Time) Errors == <span id="I3167"></span>It is a bounded error for a call on Finalize or Adjust that occurs as part of object finalization or assignment to propagate an exception. The possible consequences depend on what action invoked the Finalize or Adjust operation: * <span id="I3168"></span>For a Finalize invoked as part of an assignment_statement, Program_Error is raised at that point. * For an Adjust invoked as part of the initialization of a controlled object, other adjustments due to be performed might or might not be performed, and then Program_Error is raised. During its propagation, finalization might or might not be applied to objects whose Adjust failed. <span id="I3169"></span>For an Adjust invoked as part of an assignment statement, any other adjustments due to be performed are performed, and then Program_Error is raised. * <span id="I3170"></span>For a Finalize invoked as part of a call on an instance of Unchecked_Deallocation, any other finalizations due to be performed are performed, and then Program_Error is raised. <div> * <span id="I3171"></span>For a Finalize invoked as part of the finalization of the anonymous object created by a function call or aggregate, any other finalizations due to be performed are performed, and then Program_Error is raised. * <span id="I3172"></span>For a Finalize invoked due to reaching the end of the execution of a master, any other finalizations associated with the master are performed, and Program_Error is raised immediately after leaving the master. </div> * <span id="I3173"></span>For a Finalize invoked by the transfer of control of an exit_, return_, goto_, or requeue_statement, Program_Error is raised no earlier than after the finalization of the master being finalized when the exception occurred, and no later than the point where normal execution would have continued. Any other finalizations due to be performed up to that point are performed before raising Program_Error. * For a Finalize invoked by a transfer of control that is due to raising an exception, any other finalizations due to be performed for the same master are performed; Program_Error is raised immediately after leaving the master. * For a Finalize invoked by a transfer of control due to an abort or selection of a terminate alternative, the exception is ignored; any other finalizations due to be performed are performed. == Notes == 18  The rules of Section 10 imply that immediately prior to partition termination, Finalize operations are applied to library-level controlled objects (including those created by allocators of library-level access types, except those already finalized). This occurs after waiting for library-level tasks to terminate. 19  A constant is only constant between its initialization and finalization. Both initialization and finalization are allowed to change the value of a constant. 20  Abort is deferred during certain operations related to controlled types, as explained in [[Guide:95lrm/RM-9-8|9.8]]. Those rules prevent an abort from causing a controlled object to be left in an ill-defined state. 21  The Finalize procedure is called upon finalization of a controlled object, even if Finalize was called earlier, either explicitly or as part of an assignment; hence, if a controlled type is visibly controlled (implying that its Finalize primitive is directly callable), or is nonlimited (implying that assignment is allowed), its Finalize procedure should be designed to have no ill effect if it is applied a second time to the same object. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-7-6|Previous]] | [[Guide:95lrm/RM-8|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} c7mq7fs0i1i7k8049yix8se0m92le3g Guide:95lrm/RM-8 4200 1034 3934 3933 2019-05-04T23:38:22Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-7-6-1|Previous]] | [[Guide:95lrm/RM-8-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Section 8: Visibility Rules}} The rules defining the scope of declarations and the rules defining which identifiers, character_literals, and operator_symbols are visible at (or from) various places in the text of the program are described in this section. The formulation of these rules uses the notion of a declarative region. As explained in Section 3, a declaration declares a view of an entity and associates a defining name with that view. The view comprises an identification of the viewed entity, and possibly additional properties. A usage name denotes a declaration. It also denotes the view declared by that declaration, and denotes the entity of that view. Thus, two different usage names might denote two different views of the same entity; in this case they denote the same entity. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-7-6-1|Previous]] | [[Guide:95lrm/RM-8-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 5owxwwoiew1iycacoel10wuve4qctpq Guide:95lrm/RM-8-1 4200 1035 3936 3935 2019-05-04T23:38:22Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-8|Previous]] | [[Guide:95lrm/RM-8-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 8.1 Declarative Region}} == Static Semantics == <span id="I3174"></span>For each of the following constructs, there is a portion of the program text called its ''declarative region'', within which nested declarations can occur: * any declaration, other than that of an enumeration type, that is not a completion of a previous declaration; * a block_statement; * a loop_statement; * an accept_statement; * an exception_handler. The declarative region includes the text of the construct together with additional text determined (recursively), as follows: * If a declaration is included, so is its completion, if any. * If the declaration of a library unit (including Standard -- see [[Guide:95lrm/RM-10-1-1|10.1.1]]) is included, so are the declarations of any child units (and their completions, by the previous rule). The child declarations occur after the declaration. * If a body_stub is included, so is the corresponding subunit. * If a type_declaration is included, then so is a corresponding record_representation_clause, if any. The declarative region of a declaration is also called the ''declarative region'' of any view or entity declared by the declaration. <span id="I3175"></span><span id="I3176"></span><span id="I3177"></span><span id="I3178"></span><span id="I3179"></span>A declaration occurs ''immediately within'' a declarative region if this region is the innermost declarative region that encloses the declaration (the ''immediately enclosing'' declarative region), not counting the declarative region (if any) associated with the declaration itself. <span id="I3180"></span>A declaration is ''local'' to a declarative region if the declaration occurs immediately within the declarative region. An entity is ''local'' to a declarative region if the entity is declared by a declaration that is local to the declarative region. <span id="I3181"></span>A declaration is ''global'' to a declarative region if the declaration occurs immediately within another declarative region that encloses the declarative region. An entity is ''global'' to a declarative region if the entity is declared by a declaration that is global to the declarative region. == Notes == 1  The children of a parent library unit are inside the parent's declarative region, even though they do not occur inside the parent's declaration or body. This implies that one can use (for example) "P.Q" to refer to a child of P whose defining name is Q, and that after "'''use''' P;" Q can refer (directly) to that child. 2  As explained above and in [[Guide:95lrm/RM-10-1-1|10.1.1]], ''[[Guide:95lrm/RM-10-1-1|Compilation Units - Library Units]]'', all library units are descendants of Standard, and so are contained in the declarative region of Standard. They are ''not'' inside the declaration or body of Standard, but they ''are'' inside its declarative region. 3  For a declarative region that comes in multiple parts, the text of the declarative region does not contain any text that might appear between the parts. Thus, when a portion of a declarative region is said to extend from one place to another in the declarative region, the portion does not contain any text that might appear between the parts of the declarative region. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-8|Previous]] | [[Guide:95lrm/RM-8-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} agcf3q2ir96j6c39n1abwbzdworsj5y Guide:95lrm/RM-8-2 4200 1036 3938 3937 2019-05-04T23:38:22Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-8-1|Previous]] | [[Guide:95lrm/RM-8-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 8.2 Scope of Declarations}} For each declaration, the language rules define a certain portion of the program text called the ''scope'' of the declaration. The scope of a declaration is also called the scope of any view or entity declared by the declaration. Within the scope of an entity, and only there, there are places where it is legal to refer to the declared entity. These places are defined by the rules of visibility and overloading. == Static Semantics == <span id="I3182"></span>The ''immediate scope'' of a declaration is a portion of the declarative region immediately enclosing the declaration. The immediate scope starts at the beginning of the declaration, except in the case of an overloadable declaration, in which case the immediate scope starts just after the place where the profile of the callable entity is determined (which is at the end of the _specification for the callable entity, or at the end of the generic_instantiation if an instance). The immediate scope extends to the end of the declarative region, with the following exceptions: * The immediate scope of a library_item includes only its semantic dependents. * The immediate scope of a declaration in the private part of a library unit does not include the visible part of any public descendant of that library unit. <span id="I3183"></span> <span id="I3184"></span>The ''visible part'' of (a view of) an entity is a portion of the text of its declaration containing declarations that are visible from outside. <span id="I3185"></span>The ''private part'' of (a view of) an entity that has a visible part contains all declarations within the declaration of (the view of) the entity, except those in the visible part; these are not visible from outside. Visible and private parts are defined only for these kinds of entities: callable entities, other program units, and composite types. * <span id="I3186"></span>The visible part of a view of a callable entity is its profile. * <span id="I3187"></span>The visible part of a composite type other than a task or protected type consists of the declarations of all components declared (explicitly or implicitly) within the type_declaration. * <span id="I3188"></span>The visible part of a generic unit includes the generic_formal_part. For a generic package, it also includes the first list of basic_declarative_items of the package_specification. For a generic subprogram, it also includes the profile. * The visible part of a package, task unit, or protected unit consists of declarations in the program unit's declaration other than those following the reserved word '''private''', if any; see [[Guide:95lrm/RM-7-1|7.1]] and [[Guide:95lrm/RM-12-7|12.7]] for packages, [[Guide:95lrm/RM-9-1|9.1]] for task units, and [[Guide:95lrm/RM-9-4|9.4]] for protected units. <span id="I3189"></span>The scope of a declaration always contains the immediate scope of the declaration. In addition, for a given declaration that occurs immediately within the visible part of an outer declaration, or is a public child of an outer declaration, the scope of the given declaration extends to the end of the scope of the outer declaration, except that the scope of a library_item includes only its semantic dependents. <span id="I3190"></span>The immediate scope of a declaration is also the immediate scope of the entity or view declared by the declaration. <span id="I3191"></span>Similarly, the scope of a declaration is also the scope of the entity or view declared by the declaration. == Notes == 4  There are notations for denoting visible declarations that are not directly visible. For example, parameter_specifications are in the visible part of a subprogram_declaration so that they can be used in named-notation calls appearing outside the called subprogram. For another example, declarations of the visible part of a package can be denoted by expanded names appearing outside the package, and can be made directly visible by a use_clause. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-8-1|Previous]] | [[Guide:95lrm/RM-8-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} e8pprk7ze2zz4uce6lb8j3oudfo4fwq Guide:95lrm/RM-8-3 4200 1037 3940 3939 2019-05-04T23:38:22Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-8-2|Previous]] | [[Guide:95lrm/RM-8-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 8.3 Visibility}} <span id="I3192"></span>The ''visibility rules'', given below, determine which declarations are visible and directly visible at each place within a program. The visibility rules apply to both explicit and implicit declarations. == Static Semantics == <span id="I3193"></span><span id="I3194"></span><span id="I3195"></span>A declaration is defined to be ''directly visible'' at places where a name consisting of only an identifier or operator_symbol is sufficient to denote the declaration; that is, no selected_component notation or special context (such as preceding => in a named association) is necessary to denote the declaration. <span id="I3196"></span>A declaration is defined to be ''visible'' wherever it is directly visible, as well as at other places where some name (such as a selected_component) can denote the declaration. The syntactic category direct_name is used to indicate contexts where direct visibility is required. The syntactic category selector_name is used to indicate contexts where visibility, but not direct visibility, is required. <span id="I3197"></span><span id="I3198"></span>There are two kinds of direct visibility: ''immediate visibility'' and ''use-visibility''. <span id="I3199"></span>A declaration is immediately visible at a place if it is directly visible because the place is within its immediate scope. <span id="I3200"></span>A declaration is use-visible if it is directly visible because of a use_clause (see [[Guide:95lrm/RM-8-4|8.4]]). Both conditions can apply. <span id="I3201"></span>A declaration can be ''hidden'', either from direct visibility, or from all visibility, within certain parts of its scope. <span id="I3202"></span>Where ''hidden from all visibility'', it is not visible at all (neither using a direct_name nor a selector_name). <span id="I3203"></span>Where ''hidden from direct visibility'', only direct visibility is lost; visibility using a selector_name is still possible. <span id="I3204"></span>Two or more declarations are ''overloaded'' if they all have the same defining name and there is a place where they are all directly visible. <span id="I3205"></span>The declarations of callable entities (including enumeration literals) are ''overloadable'', meaning that overloading is allowed for them. <span id="I3206"></span>Two declarations are ''homographs'' if they have the same defining name, and, if both are overloadable, their profiles are type conformant. <span id="I3207"></span>An inner declaration hides any outer homograph from direct visibility. Two homographs are not generally allowed immediately within the same declarative region unless one ''overrides'' the other (see Legality Rules below). <span id="I3208"></span>The only declarations that are <span id="I3209"></span>''overridable'' are the implicit declarations for predefined operators and inherited primitive subprograms. A declaration overrides another homograph that occurs immediately within the same declarative region in the following cases: * A declaration that is not overridable overrides one that is overridable, regardless of which declaration occurs first; * The implicit declaration of an inherited operator overrides that of a predefined operator; * An implicit declaration of an inherited subprogram overrides a previous implicit declaration of an inherited subprogram. * For an implicit declaration of a primitive subprogram in a generic unit, there is a copy of this declaration in an instance. However, a whole new set of primitive subprograms is implicitly declared for each type declared within the visible part of the instance. These new declarations occur immediately after the type declaration, and override the copied ones. The copied ones can be called only from within the instance; the new ones can be called only from outside the instance, although for tagged types, the body of a new one can be executed by a call to an old one. <span id="I3210"></span><span id="I3211"></span>A declaration is visible within its scope, except where hidden from all visibility, as follows: * <span id="I3212"></span>An overridden declaration is hidden from all visibility within the scope of the overriding declaration. * <span id="I3213"></span>A declaration is hidden from all visibility until the end of the declaration, except: * For a record type or record extension, the declaration is hidden from all visibility only until the reserved word '''record'''; * For a package_declaration, task declaration, protected declaration, generic_package_declaration, or subprogram_body, the declaration is hidden from all visibility only until the reserved word '''is''' of the declaration. * <span id="I3214"></span>If the completion of a declaration is a declaration, then within the scope of the completion, the first declaration is hidden from all visibility. Similarly, a discriminant_specification or parameter_specification is hidden within the scope of a corresponding discriminant_specification or parameter_specification of a corresponding completion, or of a corresponding accept_statement. * <span id="I3215"></span>The declaration of a library unit (including a library_unit_renaming_declaration) is hidden from all visibility except at places that are within its declarative region or within the scope of a with_clause that mentions it. For each declaration or renaming of a generic unit as a child of some parent generic package, there is a corresponding declaration nested immediately within each instance of the parent. Such a nested declaration is hidden from all visibility except at places that are within the scope of a with_clause that mentions the child. <span id="I3216"></span><span id="I3217"></span><span id="I3218"></span><span id="I3219"></span>A declaration with a defining_identifier or defining_operator_symbol is immediately visible (and hence directly visible) within its immediate scope <span id="I3220"></span> except where hidden from direct visibility, as follows: * <span id="I3221"></span>A declaration is hidden from direct visibility within the immediate scope of a homograph of the declaration, if the homograph occurs within an inner declarative region; * <span id="I3222"></span>A declaration is also hidden from direct visibility where hidden from all visibility. == Name Resolution Rules == <span id="I3223"></span>A direct_name shall resolve to denote a directly visible declaration whose defining name is the same as the direct_name. <span id="I3224"></span>A selector_name shall resolve to denote a visible declaration whose defining name is the same as the selector_name. These rules on visibility and direct visibility do not apply in a context_clause, a parent_unit_name, or a pragma that appears at the place of a compilation_unit. For those contexts, see the rules in [[Guide:95lrm/RM-10-1-6|10.1.6]], ''[[Guide:95lrm/RM-10-1-6|Environment-Level Visibility Rules]]''. == Legality Rules == A non-overridable declaration is illegal if there is a homograph occurring immediately within the same declarative region that is visible at the place of the declaration, and is not hidden from all visibility by the non-overridable declaration. In addition, a type extension is illegal if somewhere within its immediate scope it has two visible components with the same name. Similarly, the context_clause for a subunit is illegal if it mentions (in a with_clause) some library unit, and there is a homograph of the library unit that is visible at the place of the corresponding stub, and the homograph and the mentioned library unit are both declared immediately within the same declarative region. <span id="I3225"></span>These rules also apply to dispatching operations declared in the visible part of an instance of a generic unit. However, they do not apply to other overloadable declarations in an instance; such declarations may have type conformant profiles in the instance, so long as the corresponding declarations in the generic were not type conformant. <span id="I3226"></span> == Notes == 5  Visibility for compilation units follows from the definition of the environment in [[Guide:95lrm/RM-10-1-4|10.1.4]], except that it is necessary to apply a with_clause to obtain visibility to a library_unit_declaration or library_unit_renaming_declaration. 6  In addition to the visibility rules given above, the meaning of the occurrence of a direct_name or selector_name at a given place in the text can depend on the overloading rules (see [[Guide:95lrm/RM-8-6|8.6]]). 7  Not all contexts where an identifier, character_literal, or operator_symbol are allowed require visibility of a corresponding declaration. Contexts where visibility is not required are identified by using one of these three syntactic categories directly in a syntax rule, rather than using direct_name or selector_name. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-8-2|Previous]] | [[Guide:95lrm/RM-8-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 6zt0ffcyy6vd6j782t5av5ey70id70q Guide:95lrm/RM-8-4 4200 1038 3942 3941 2019-05-04T23:38:23Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-8-3|Previous]] | [[Guide:95lrm/RM-8-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 8.4 Use Clauses}} A use_package_clause achieves direct visibility of declarations that appear in the visible part of a package; a use_type_clause achieves direct visibility of the primitive operators of a type. == Syntax == <p><span></span></p> use_clause<span id="I3227"></span> ::= <span id="I3228"></span>use_package_clause | <span id="I3229"></span>use_type_clause <p><span></span></p> use_package_clause<span id="I3230"></span> ::= '''use''' ''package_''<span id="I3231"></span>name {, ''package_''<span id="I3232"></span>name}; <p><span></span></p> use_type_clause<span id="I3233"></span> ::= '''use type''' <span id="I3234"></span>subtype_mark {, <span id="I3235"></span>subtype_mark}; == Legality Rules == A ''package_''name of a use_package_clause shall denote a package. == Static Semantics == <span id="I3236"></span>For each use_clause, there is a certain region of text called the ''scope'' of the use_clause. For a use_clause within a context_clause of a library_unit_declaration or library_unit_renaming_declaration, the scope is the entire declarative region of the declaration. For a use_clause within a context_clause of a body, the scope is the entire body and any subunits (including multiply nested subunits). The scope does not include context_clauses themselves. For a use_clause immediately within a declarative region, the scope is the portion of the declarative region starting just after the use_clause and extending to the end of the declarative region. However, the scope of a use_clause in the private part of a library unit does not include the visible part of any public descendant of that library unit. <span id="I3237"></span>For each package denoted by a ''package_''name of a use_package_clause whose scope encloses a place, each declaration that occurs immediately within the declarative region of the package is ''potentially'' ''use-visible'' at this place if the declaration is visible at this place. For each type ''T'' or ''T'''Class determined by a subtype_mark of a use_type_clause whose scope encloses a place, the declaration of each primitive operator of type ''T'' is potentially use-visible at this place if its declaration is visible at this place. <span id="I3238"></span><span id="I3239"></span>A declaration is ''use-visible'' if it is potentially use-visible, except in these naming-conflict cases: * A potentially use-visible declaration is not use-visible if the place considered is within the immediate scope of a homograph of the declaration. * Potentially use-visible declarations that have the same identifier are not use-visible unless each of them is an overloadable declaration. == Dynamic Semantics == <span id="I3240"></span>The elaboration of a use_clause has no effect. == Examples == ''Example of a use clause in a context clause:'' <p><syntaxhighlight lang="Ada"> with Ada.Calendar; use Ada;</syntaxhighlight></p> ''Example of a use type clause:'' <p><syntaxhighlight lang="Ada"> use type Rational_Numbers.Rational; -- see 7.1 Two_Thirds: Rational_Numbers.Rational := 2/3;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-8-3|Previous]] | [[Guide:95lrm/RM-8-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} tiuc09k3iqgai4v41vf97343j6nxd84 Guide:95lrm/RM-8-5 4200 1039 3944 3943 2019-05-04T23:38:24Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-8-4|Previous]] | [[Guide:95lrm/RM-8-5-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 8.5 Renaming Declarations}} A renaming_declaration declares another name for an entity, such as an object, exception, package, subprogram, entry, or generic unit. Alternatively, a subprogram_renaming_declaration can be the completion of a previous subprogram_declaration. == Syntax == <p><span></span></p> renaming_declaration<span id="I3241"></span> ::= <span id="I3242"></span>object_renaming_declaration | <span id="I3243"></span>exception_renaming_declaration | <span id="I3244"></span>package_renaming_declaration | <span id="I3245"></span>subprogram_renaming_declaration | <span id="I3246"></span>generic_renaming_declaration == Dynamic Semantics == <span id="I3247"></span>The elaboration of a renaming_declaration evaluates the name that follows the reserved word '''renames''' and thereby determines the view and entity denoted by this name <span id="I3248"></span><span id="I3249"></span>(the ''renamed view'' and ''renamed entity''). A name that denotes the renaming_declaration denotes (a new view of) the renamed entity. == Notes == 8  Renaming may be used to resolve name conflicts and to act as a shorthand. Renaming with a different identifier or operator_symbol does not hide the old name; the new name and the old name need not be visible at the same places. 9  A task or protected object that is declared by an explicit object_declaration can be renamed as an object. However, a single task or protected object cannot be renamed since the corresponding type is anonymous (meaning it has no nameable subtypes). For similar reasons, an object of an anonymous array or access type cannot be renamed. 10  A subtype defined without any additional constraint can be used to achieve the effect of renaming another subtype (including a task or protected subtype) as in <p><syntaxhighlight lang="Ada"> subtype Mode is Ada.Text_IO.File_Mode;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-8-4|Previous]] | [[Guide:95lrm/RM-8-5-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 13typ61qgy8xs037pnp5rubpr4ceudu Guide:95lrm/RM-8-5-1 4200 1040 3946 3945 2019-05-04T23:38:24Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-8-5|Previous]] | [[Guide:95lrm/RM-8-5-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 8.5.1 Object Renaming Declarations}} An object_renaming_declaration is used to rename an object. == Syntax == <p><span></span></p> object_renaming_declaration<span id="I3250"></span> ::= <span id="I3251"></span>defining_identifier : <span id="I3252"></span>subtype_mark '''renames''' ''object_''<span id="I3253"></span>name; == Name Resolution Rules == The type of the ''object_''name shall resolve to the type determined by the subtype_mark. == Legality Rules == The renamed entity shall be an object. The renamed entity shall not be a subcomponent that depends on discriminants of a variable whose nominal subtype is unconstrained, unless this subtype is indefinite, or the variable is aliased. A slice of an array shall not be renamed if this restriction disallows renaming of the array. In addition to the places where Legality Rules normally apply, these rules apply also in the private part of an instance of a generic unit. These rules also apply for a renaming that appears in the body of a generic unit, with the additional requirement that even if the nominal subtype of the variable is indefinite, its type shall not be a descendant of an untagged generic formal derived type. == Static Semantics == An object_renaming_declaration declares a new view of the renamed object whose properties are identical to those of the renamed view. Thus, the properties of the renamed object are not affected by the renaming_declaration. In particular, its value and whether or not it is a constant are unaffected; similarly, the constraints that apply to an object are not affected by renaming (any constraint implied by the subtype_mark of the object_renaming_declaration is ignored). == Examples == ''Example of renaming an object:'' <p><syntaxhighlight lang="Ada"> declare L : Person renames Leftmost_Person; -- see 3.10.1 begin L.Age := L.Age + 1; end;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-8-5|Previous]] | [[Guide:95lrm/RM-8-5-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} lfvgu89hhztkbgd3puown07ar1xngkz Guide:95lrm/RM-8-5-2 4200 1041 3948 3947 2019-05-04T23:38:25Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-8-5-1|Previous]] | [[Guide:95lrm/RM-8-5-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 8.5.2 Exception Renaming Declarations}} An exception_renaming_declaration is used to rename an exception. == Syntax == <p><span></span></p> exception_renaming_declaration<span id="I3254"></span> ::= <span id="I3255"></span>defining_identifier : '''exception''' '''renames''' ''exception_''<span id="I3256"></span>name; == Legality Rules == The renamed entity shall be an exception. == Static Semantics == An exception_renaming_declaration declares a new view of the renamed exception. == Examples == ''Example of renaming an exception:'' <p><syntaxhighlight lang="Ada"> EOF : exception renames Ada.IO_Exceptions.End_Error; -- see A.13</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-8-5-1|Previous]] | [[Guide:95lrm/RM-8-5-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} p8ww8i8i4ty0m2w68d3tny36epy0387 Guide:95lrm/RM-8-5-3 4200 1042 3950 3949 2019-05-04T23:38:25Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-8-5-2|Previous]] | [[Guide:95lrm/RM-8-5-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 8.5.3 Package Renaming Declarations}} A package_renaming_declaration is used to rename a package. == Syntax == <p><span></span></p> package_renaming_declaration<span id="I3257"></span> ::= '''package''' <span id="I3258"></span>defining_program_unit_name '''renames''' ''package_''<span id="I3259"></span>name; == Legality Rules == The renamed entity shall be a package. == Static Semantics == A package_renaming_declaration declares a new view of the renamed package. == Examples == ''Example of renaming a package:'' <p><syntaxhighlight lang="Ada"> package TM renames Table_Manager;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-8-5-2|Previous]] | [[Guide:95lrm/RM-8-5-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 5i7n8n3viu5pm0pmvqkxlhnoi0kcuo7 Guide:95lrm/RM-8-5-4 4200 1043 3952 3951 2019-05-04T23:38:27Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-8-5-3|Previous]] | [[Guide:95lrm/RM-8-5-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 8.5.4 Subprogram Renaming Declarations}} A subprogram_renaming_declaration can serve as the completion of a subprogram_declaration; <span id="I3260"></span>such a renaming_declaration is called a ''renaming-as-body''. <span id="I3261"></span>A subprogram_renaming_declaration that is not a completion is called a ''renaming-as-declaration'', and is used to rename a subprogram (possibly an enumeration literal) or an entry. == Syntax == <p><span></span></p> subprogram_renaming_declaration<span id="I3262"></span> ::= <span id="I3263"></span>subprogram_specification '''renames''' ''callable_entity_''<span id="I3264"></span>name; == Name Resolution Rules == <span id="I3265"></span>The expected profile for the ''callable_entity_''name is the profile given in the subprogram_specification. == Legality Rules == The profile of a renaming-as-declaration shall be mode-conformant with that of the renamed callable entity. <span id="I3266"></span> The profile of a renaming-as-body shall conform fully to that of the declaration it completes. <span id="I3267"></span>If the renaming-as-body completes that declaration before the subprogram it declares is frozen, the profile shall be mode-conformant <span id="I3268"></span>with that of the renamed callable entity and the subprogram it declares takes its convention from the renamed subprogram; otherwise, the profile shall be subtype-conformant with that of the renamed callable entity and the convention of the renamed subprogram shall not be Intrinsic. <span id="I3269"></span>A renaming-as-body is illegal if the declaration occurs before the subprogram whose declaration it completes is frozen, and the renaming renames the subprogram itself, through one or more subprogram renaming declarations, none of whose subprograms has been frozen. A name that denotes a formal parameter of the subprogram_specification is not allowed within the ''callable_entity_''name. == Static Semantics == A renaming-as-declaration declares a new view of the renamed entity. The profile of this new view takes its subtypes, parameter modes, and calling convention from the original profile of the callable entity, while taking the formal parameter names and default_expressions from the profile given in the subprogram_renaming_declaration. The new view is a function or procedure, never an entry. == Dynamic Semantics == <div> For a call to a subprogram whose body is given as a renaming-as-body, the execution of the renaming-as-body is equivalent to the execution of a subprogram_body that simply calls the renamed subprogram with its formal parameters as the actual parameters and, if it is a function, returns the value of the call. </div> For a call on a renaming of a dispatching subprogram that is overridden, if the overriding occurred before the renaming, then the body executed is that of the overriding declaration, even if the overriding declaration is not visible at the place of the renaming; otherwise, the inherited or predefined subprogram is called. == Bounded (Run-Time) Errors == <div> <span id="I3270"></span><span id="I3271"></span>If a subprogram directly or indirectly renames itself, then it is a bounded error to call that subprogram. Possible consequences are that Program_Error or Storage_Error is raised, or that the call results in infinite recursion. </div> == Notes == 11  A procedure can only be renamed as a procedure. A function whose defining_designator is either an identifier or an operator_symbol can be renamed with either an identifier or an operator_symbol; for renaming as an operator, the subprogram specification given in the renaming_declaration is subject to the rules given in [[Guide:95lrm/RM-6-6|6.6]] for operator declarations. Enumeration literals can be renamed as functions; similarly, attribute_references that denote functions (such as references to Succ and Pred) can be renamed as functions. An entry can only be renamed as a procedure; the new name is only allowed to appear in contexts that allow a procedure name. An entry of a family can be renamed, but an entry family cannot be renamed as a whole. 12  The operators of the root numeric types cannot be renamed because the types in the profile are anonymous, so the corresponding specifications cannot be written; the same holds for certain attributes, such as Pos. 13  Calls with the new name of a renamed entry are procedure_call_statements and are not allowed at places where the syntax requires an entry_call_statement in conditional_ and timed_entry_calls, nor in an asynchronous_select; similarly, the Count attribute is not available for the new name. 14  The primitiveness of a renaming-as-declaration is determined by its profile, and by where it occurs, as for any declaration of (a view of) a subprogram; primitiveness is not determined by the renamed view. In order to perform a dispatching call, the subprogram name has to denote a primitive subprogram, not a non-primitive renaming of a primitive subprogram. == Examples == ''Examples of subprogram renaming declarations:'' <p><syntaxhighlight lang="Ada"> procedure My_Write(C : in Character) renames Pool(K).Write; --  see 4.1.3</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> function Real_Plus(Left, Right : Real   ) return Real    renames "+"; function Int_Plus (Left, Right : Integer) return Integer renames "+";</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> function Rouge return Color renames Red;  --  see 3.5.1 function Rot   return Color renames Red; function Rosso return Color renames Rouge;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> function Next(X : Color) return Color renames Color'Succ; -- see 3.5.1</syntaxhighlight></p> ''Example of a subprogram renaming declaration with new parameter names:'' <p><syntaxhighlight lang="Ada">function "*" (X,Y : Vector) return Real renames Dot_Product; -- see 6.1</syntaxhighlight></p> ''Example of a subprogram renaming declaration with a new default expression:'' <p><syntaxhighlight lang="Ada"> function Minimum(L : Link := Head) return Cell renames Min_Cell; -- see 6.1</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-8-5-3|Previous]] | [[Guide:95lrm/RM-8-5-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} dnd12burgcm0x5ehr1lccoa7vlzioat Guide:95lrm/RM-8-5-5 4200 1044 3954 3953 2019-05-04T23:38:28Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-8-5-4|Previous]] | [[Guide:95lrm/RM-8-6|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 8.5.5 Generic Renaming Declarations}} A generic_renaming_declaration is used to rename a generic unit. == Syntax == <p><span></span></p> generic_renaming_declaration<span id="I3272"></span> ::= '''generic package''' <span id="I3273"></span>defining_program_unit_name '''renames''' ''generic_package_''<span id="I3274"></span>name; | '''generic procedure''' <span id="I3275"></span>defining_program_unit_name '''renames''' ''generic_procedure_''<span id="I3276"></span>name; | '''generic function''' <span id="I3277"></span>defining_program_unit_name '''renames''' ''generic_function_''<span id="I3278"></span>name; == Legality Rules == The renamed entity shall be a generic unit of the corresponding kind. == Static Semantics == A generic_renaming_declaration declares a new view of the renamed generic unit. == Notes == 15  Although the properties of the new view are the same as those of the renamed view, the place where the generic_renaming_declaration occurs may affect the legality of subsequent renamings and instantiations that denote the generic_renaming_declaration, in particular if the renamed generic unit is a library unit (see [[Guide:95lrm/RM-10-1-1|10.1.1]]). == Examples == ''Example of renaming a generic unit:'' <p><syntaxhighlight lang="Ada"> generic package Enum_IO renames Ada.Text_IO.Enumeration_IO;  -- see A.10.10</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-8-5-4|Previous]] | [[Guide:95lrm/RM-8-6|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} ez9jalhfjwjsyssxz7jjocd8iggrp4e Guide:95lrm/RM-8-6 4200 1045 3956 3955 2019-05-04T23:38:29Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-8-5-5|Previous]] | [[Guide:95lrm/RM-9|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 8.6 The Context of Overload Resolution}} <span id="I3279"></span>Because declarations can be overloaded, it is possible for an occurrence of a usage name to have more than one possible interpretation; in most cases, ambiguity is disallowed. This clause describes how the possible interpretations resolve to the actual interpretation. <span id="I3280"></span>Certain rules of the language (the Name Resolution Rules) are considered ''overloading rules''. If a possible interpretation violates an overloading rule, it is assumed not to be the intended interpretation; some other possible interpretation is assumed to be the actual interpretation. On the other hand, violations of non-overloading rules do not affect which interpretation is chosen; instead, they cause the construct to be illegal. To be legal, there usually has to be exactly one acceptable interpretation of a construct that is a ''complete context'', not counting any nested complete contexts. <span id="I3281"></span>The syntax rules of the language and the visibility rules given in [[Guide:95lrm/RM-8-3|8.3]] determine the possible interpretations. Most type checking rules (rules that require a particular type, or a particular class of types, for example) are overloading rules. Various rules for the matching of formal and actual parameters are overloading rules. == Name Resolution Rules == <span id="I3282"></span>Overload resolution is applied separately to each ''complete context'', not counting inner complete contexts. Each of the following constructs is a ''complete context'': * A context_item. * A declarative_item or declaration. * A statement. * A pragma_argument_association. * The expression of a case_statement. <span id="I3283"></span><span id="I3284"></span>An (overall) ''interpretation'' of a complete context embodies its meaning, and includes the following information about the constituents of the complete context, not including constituents of inner complete contexts: * for each constituent of the complete context, to which syntactic categories it belongs, and by which syntax rules; and * for each usage name, which declaration it denotes (and, therefore, which view and which entity it denotes); and * for a complete context that is a declarative_item, whether or not it is a completion of a declaration, and (if so) which declaration it completes. <span id="I3285"></span>A ''possible interpretation'' is one that obeys the syntax rules and the visibility rules. <span id="I3286"></span><span id="I3287"></span><span id="I3288"></span>An ''acceptable interpretation'' is a possible interpretation that obeys the ''overloading rules'', that is, those rules that specify an expected type or expected profile, or specify how a construct shall ''resolve'' or be ''interpreted''. <span id="I3289"></span>The ''interpretation'' of a constituent of a complete context is determined from the overall interpretation of the complete context as a whole. Thus, for example, ''interpreted as a function_call,'' means that the construct's interpretation says that it belongs to the syntactic category function_call. <span id="I3290"></span>Each occurrence of a usage name ''denotes'' the declaration determined by its interpretation. It also denotes the view declared by its denoted declaration, except in the following cases: * <span id="I3291"></span>If a usage name appears within the declarative region of a type_declaration and denotes that same type_declaration, then it denotes the ''current instance'' of the type (rather than the type itself). The current instance of a type is the object or value of the type that is associated with the execution that evaluates the usage name. * <span id="I3292"></span>If a usage name appears within the declarative region of a generic_declaration (but not within its generic_formal_part) and it denotes that same generic_declaration, then it denotes the ''current instance'' of the generic unit (rather than the generic unit itself). See also [[Guide:95lrm/RM-12-3|12.3]]. A usage name that denotes a view also denotes the entity of that view. <span id="I3293"></span>The ''expected type'' for a given expression, name, or other construct determines, according to the ''type resolution rules'' given below, the types considered for the construct during overload resolution. <span id="I3294"></span>The type resolution rules provide support for class-wide programming, universal numeric literals, dispatching operations, and anonymous access types: * <span id="I3295"></span><span id="I3296"></span>If a construct is expected to be of any type in a class of types, or of the universal or class-wide type for a class, then the type of the construct shall resolve to a type in that class or to a universal type that covers the class. * <span id="I3297"></span>If the expected type for a construct is a specific type ''T'', then the type of the construct shall resolve either to ''T'', or: <p><span></span></p> :* to ''T'''Class; or <p><span></span></p> :* to a universal type that covers ''T''; or <p><span></span></p> :* when ''T'' is an anonymous access type (see [[Guide:95lrm/RM-3-10|3.10]]) with designated type ''D'', to an access-to-variable type whose designated type is ''D'''Class or is covered by ''D''. <span id="I3298"></span>In certain contexts, such as in a subprogram_renaming_declaration, the Name Resolution Rules define an ''expected profile'' for a given name; <span id="I3299"></span>in such cases, the name shall resolve to the name of a callable entity whose profile is type conformant with the expected profile. <span id="I3300"></span> == Legality Rules == <span id="I3301"></span>When the expected type for a construct is required to be a ''single'' type in a given class, the type expected for the construct shall be determinable solely from the context in which the construct appears, excluding the construct itself, but using the requirement that it be in the given class; the type of the construct is then this single expected type. Furthermore, the context shall not be one that expects any type in some class that contains types of the given class; in particular, the construct shall not be the operand of a type_conversion. A complete context shall have at least one acceptable interpretation; if there is exactly one, then that one is chosen. <span id="I3302"></span>There is a ''preference'' for the primitive operators (and ranges) of the root numeric types ''root_integer'' and ''root_real''. In particular, if two acceptable interpretations of a constituent of a complete context differ only in that one is for a primitive operator (or range) of the type ''root_integer'' or ''root_real'', and the other is not, the interpretation using the primitive operator (or range) of the root numeric type is ''preferred''. For a complete context, if there is exactly one overall acceptable interpretation where each constituent's interpretation is the same as or preferred (in the above sense) over those in all other overall acceptable interpretations, then that one overall acceptable interpretation is chosen. <span id="I3303"></span>Otherwise, the complete context is ''ambiguous''. A complete context other than a pragma_argument_association shall not be ambiguous. A complete context that is a pragma_argument_association is allowed to be ambiguous (unless otherwise specified for the particular pragma), but only if every acceptable interpretation of the pragma argument is as a name that statically denotes a callable entity. <span id="I3304"></span>Such a name denotes all of the declarations determined by its interpretations, and all of the views declared by these declarations. == Notes == 16  If a usage name has only one acceptable interpretation, then it denotes the corresponding entity. However, this does not mean that the usage name is necessarily legal since other requirements exist which are not considered for overload resolution; for example, the fact that an expression is static, whether an object is constant, mode and subtype conformance rules, freezing rules, order of elaboration, and so on. Similarly, subtypes are not considered for overload resolution (the violation of a constraint does not make a program illegal but raises an exception during program execution). </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-8-5-5|Previous]] | [[Guide:95lrm/RM-9|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} pugp8z36vmtqjf12q4iccb3njjo8msr Guide:95lrm/RM-9 4200 1046 3958 3957 2019-05-04T23:38:29Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-8-6|Previous]] | [[Guide:95lrm/RM-9-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Section 9: Tasks and Synchronization}} <span id="I3305"></span>The execution of an Ada program consists of the execution of one or more ''tasks''. <span id="I3306"></span><span id="I3307"></span>Each task represents a separate thread of control that proceeds independently and concurrently between the points where it ''interacts'' with other tasks. The various forms of task interaction are described in this section, and include: <span id="I3308"></span><span id="I3309"></span><span id="I3310"></span><span id="I3311"></span> * the activation and termination of a task; * <span id="I3312"></span>a call on a protected subprogram of a ''protected object'', providing exclusive read-write access, or concurrent read-only access to shared data; * a call on an entry, either of another task, allowing for synchronous communication with that task, or of a protected object, allowing for asynchronous communication with one or more other tasks using that same protected object; * a timed operation, including a simple delay statement, a timed entry call or accept, or a timed asynchronous select statement (see next item); * an asynchronous transfer of control as part of an asynchronous select statement, where a task stops what it is doing and begins execution at a different point in response to the completion of an entry call or the expiration of a delay; * an abort statement, allowing one task to cause the termination of another task. In addition, tasks can communicate indirectly by reading and updating (unprotected) shared variables, presuming the access is properly synchronized through some other kind of task interaction. == Static Semantics == <span id="I3313"></span>The properties of a task are defined by a corresponding task declaration and task_body, which together define a program unit called a ''task unit''. == Dynamic Semantics == Over time, tasks proceed through various ''states''. <span id="I3314"></span><span id="I3315"></span><span id="I3316"></span><span id="I3317"></span><span id="I3318"></span><span id="I3319"></span><span id="I3320"></span><span id="I3321"></span>A task is initially ''inactive''; upon activation, and prior to its ''termination'' it is either ''blocked'' (as part of some task interaction) or ''ready'' to run. <span id="I3322"></span>While ready, a task competes for the available ''execution resources'' that it requires to run. == Notes == 1  Concurrent task execution may be implemented on multicomputers, multiprocessors, or with interleaved execution on a single physical processor. On the other hand, whenever an implementation can determine that the required semantic effects can be achieved when parts of the execution of a given task are performed by different physical processors acting in parallel, it may choose to perform them in this way. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-8-6|Previous]] | [[Guide:95lrm/RM-9-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} oz0q9zz2gq25aeagr8sngpaxqfqy1ln Guide:95lrm/RM-9-1 4200 1047 3960 3959 2019-05-04T23:38:31Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9|Previous]] | [[Guide:95lrm/RM-9-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 9.1 Task Units and Task Objects}} <span id="I3323"></span>A task unit is declared by a ''task declaration'', which has a corresponding task_body. A task declaration may be a task_type_declaration, in which case it declares a named task type; alternatively, it may be a single_task_declaration, in which case it defines an anonymous task type, as well as declaring a named task object of that type. == Syntax == <p><span></span></p> task_type_declaration<span id="I3324"></span> ::= '''task''' '''type''' <span id="I3325"></span>defining_identifier [<span id="I3326"></span>known_discriminant_part] ['''is''' <span id="I3327"></span>task_definition]; <p><span></span></p> single_task_declaration<span id="I3328"></span> ::= '''task''' <span id="I3329"></span>defining_identifier ['''is''' <span id="I3330"></span>task_definition]; <p><span></span></p> task_definition<span id="I3331"></span> ::= {<span id="I3332"></span>task_item} [ '''private''' {<span id="I3333"></span>task_item}] '''end''' [''task_''<span id="I3334"></span>identifier] <p><span></span></p> task_item<span id="I3335"></span> ::= <span id="I3336"></span>entry_declaration | <span id="I3337"></span>aspect_clause <p><span></span></p> task_body<span id="I3338"></span> ::= '''task''' '''body''' <span id="I3339"></span>defining_identifier '''is''' <span id="I3340"></span>declarative_part '''begin''' <span id="I3341"></span>handled_sequence_of_statements '''end''' [''task_''<span id="I3342"></span>identifier]; If a ''task_''identifier appears at the end of a task_definition or task_body, it shall repeat the defining_identifier. == Legality Rules == <span id="I3343"></span>A task declaration requires a completion, which shall be a task_body, and every task_body shall be the completion of some task declaration. == Static Semantics == A task_definition defines a task type and its first subtype. <span id="I3344"></span>The first list of task_items of a task_definition, together with the known_discriminant_part, if any, is called the visible part of the task unit. <span id="I3345"></span>The optional list of task_items after the reserved word '''private''' is called the private part of the task unit. <div> For a task declaration without a task_definition, a task_definition without task_items is assumed. </div> == Dynamic Semantics == <span id="I3346"></span>The elaboration of a task declaration elaborates the task_definition. <span id="I3347"></span>The elaboration of a single_task_declaration also creates an object of an (anonymous) task type. <span id="I3348"></span>The elaboration of a task_definition creates the task type and its first subtype; it also includes the elaboration of the entry_declarations in the given order. <span id="I3349"></span>As part of the initialization of a task object, any aspect_clauses and any per-object constraints associated with entry_declarations of the corresponding task_definition are elaborated in the given order. <span id="I3350"></span>The elaboration of a task_body has no effect other than to establish that tasks of the type can from then on be activated without failing the Elaboration_Check. The execution of a task_body is invoked by the activation of a task of the corresponding type (see [[Guide:95lrm/RM-9-2|9.2]]). The content of a task object of a given task type includes: * The values of the discriminants of the task object, if any; * An entry queue for each entry of the task object; * A representation of the state of the associated task. == Notes == 2  Within the declaration or body of a task unit, the name of the task unit denotes the current instance of the unit (see [[Guide:95lrm/RM-8-6|8.6]]), rather than the first subtype of the corresponding task type (and thus the name cannot be used as a subtype_mark). 3  The notation of a selected_component can be used to denote a discriminant of a task (see [[Guide:95lrm/RM-4-1-3|4.1.3]]). Within a task unit, the name of a discriminant of the task type denotes the corresponding discriminant of the current instance of the unit. 4  A task type is a limited type (see [[Guide:95lrm/RM-7-5|7.5]]), and hence has neither an assignment operation nor predefined equality operators. If an application needs to store and exchange task identities, it can do so by defining an access type designating the corresponding task objects and by using access values for identification purposes. Assignment is available for such an access type as for any access type. Alternatively, if the implementation supports the Systems Programming Annex, the Identity attribute can be used for task identification (see [[Guide:95lrm/RM-C-7|C.7]]). == Examples == ''Examples of declarations of task types:'' <p><syntaxhighlight lang="Ada"> task type Server is entry Next_Work_Item(WI : in Work_Item); entry Shut_Down; end Server;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> task type Keyboard_Driver(ID : Keyboard_ID := New_ID) is entry Read (C : out Character); entry Write(C : in  Character); end Keyboard_Driver;</syntaxhighlight></p> ''Examples of declarations of single tasks:'' <p><syntaxhighlight lang="Ada"> task Controller is entry Request(Level)(D : Item);  --  a family of entries end Controller;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> task Parser is entry Next_Lexeme(L : in  Lexical_Element); entry Next_Action(A : out Parser_Action); end;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> task User;  --  has no entries</syntaxhighlight></p> ''Examples of task objects:'' <p><syntaxhighlight lang="Ada"> Agent    : Server; Teletype : Keyboard_Driver(TTY_ID); Pool     : array(1 .. 10) of Keyboard_Driver;</syntaxhighlight></p> ''Example of access type designating task objects:'' <p><syntaxhighlight lang="Ada"> type Keyboard is access Keyboard_Driver; Terminal : Keyboard := new Keyboard_Driver(Term_ID);</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9|Previous]] | [[Guide:95lrm/RM-9-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 3odf3tzxdonu7iv4qsh5131rcun3tcz Guide:95lrm/RM-9-10 4200 1048 3962 3961 2019-05-04T23:38:32Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-9|Previous]] | [[Guide:95lrm/RM-9-11|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 9.10 Shared Variables}} == Static Semantics == <span id="I3661"></span><span id="I3662"></span>If two different objects, including nonoverlapping parts of the same object, are ''independently addressable'', they can be manipulated concurrently by two different tasks without synchronization. Normally, any two nonoverlapping objects are independently addressable. However, if packing, record layout, or Component_Size is specified for a given composite object, then it is implementation defined whether or not two nonoverlapping parts of that composite object are independently addressable. == Dynamic Semantics == Separate tasks normally proceed independently and concurrently with one another. However, task interactions can be used to synchronize the actions of two or more tasks to allow, for example, meaningful communication by the direct updating and reading of variables shared between the tasks. The actions of two different tasks are synchronized in this sense when an action of one task ''signals'' an action of the other task; <span id="I3663"></span>an action A1 is defined to signal an action A2 under the following circumstances: * If A1 and A2 are part of the execution of the same task, and the language rules require A1 to be performed before A2; * If A1 is the action of an activator that initiates the activation of a task, and A2 is part of the execution of the task that is activated; * If A1 is part of the activation of a task, and A2 is the action of waiting for completion of the activation; * If A1 is part of the execution of a task, and A2 is the action of waiting for the termination of the task; <div> * If A1 is the termination of a task T, and A2 is either the evaluation of the expression T'Terminated or a call to Ada.Task_Identification.Is_Terminated with an actual parameter that identifies T (see [[Guide:95lrm/RM-C-7-1|C.7.1]]); </div> * If A1 is the action of issuing an entry call, and A2 is part of the corresponding execution of the appropriate entry_body or accept_statement. * If A1 is part of the execution of an accept_statement or entry_body, and A2 is the action of returning from the corresponding entry call; * If A1 is part of the execution of a protected procedure body or entry_body for a given protected object, and A2 is part of a later execution of an entry_body for the same protected object; * If A1 signals some action that in turn signals A2. == Erroneous Execution == <span id="I3664"></span>Given an action of assigning to an object, and an action of reading or updating a part of the same object (or of a neighboring object if the two are not independently addressable), then the execution of the actions is erroneous unless the actions are ''sequential''. <span id="I3665"></span>Two actions are sequential if one of the following is true: * One action signals the other; * Both actions occur as part of the execution of the same task; * Both actions occur as part of protected actions on the same protected object, and at most one of the actions is part of a call on a protected function of the protected object. A pragma Atomic or Atomic_Components may also be used to ensure that certain reads and updates are sequential -- see [[Guide:95lrm/RM-C-6|C.6]]. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-9|Previous]] | [[Guide:95lrm/RM-9-11|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} r7hnvwdywgaxjgxhrkayp5t0l44dw86 Guide:95lrm/RM-9-11 4200 1049 3964 3963 2019-05-04T23:38:34Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-10|Previous]] | [[Guide:95lrm/RM-10|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 9.11 Example of Tasking and Synchronization}} == Examples == The following example defines a buffer protected object to smooth variations between the speed of output of a producing task and the speed of input of some consuming task. For instance, the producing task might have the following structure: <p><syntaxhighlight lang="Ada"> task Producer;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> task body Producer is Char : Character; begin loop    ... --  produce the next character Char    Buffer.Write(Char);    exit when Char = ASCII.EOT; end loop; end Producer;</syntaxhighlight></p> and the consuming task might have the following structure: <p><syntaxhighlight lang="Ada"> task Consumer;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> task body Consumer is Char : Character; begin loop    Buffer.Read(Char);    exit when Char = ASCII.EOT;     ... --  consume the character Char end loop; end Consumer;</syntaxhighlight></p> The buffer object contains an internal pool of characters managed in a round-robin fashion. The pool has two indices, an In_Index denoting the space for the next input character and an Out_Index denoting the space for the next output character. <p><syntaxhighlight lang="Ada"> protected Buffer is entry Read (C : out Character); entry Write(C : in  Character); private Pool      : String(1 .. 100); Count     : Natural := 0; In_Index, Out_Index : Positive := 1; end Buffer;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> protected body Buffer is entry Write(C : in Character)    when Count < Pool'Length is begin    Pool(In_Index) := C;    In_Index := (In_Index mod Pool'Length) + 1;    Count    := Count + 1; end Write;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    entry Read(C : out Character)    when Count > 0 is begin    C := Pool(Out_Index);    Out_Index := (Out_Index mod Pool'Length) + 1;    Count     := Count - 1; end Read; end Buffer;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-10|Previous]] | [[Guide:95lrm/RM-10|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} bx3wiepnhxnhzyrga844p2tg895tlwz Guide:95lrm/RM-9-2 4200 1050 3966 3965 2019-05-04T23:38:35Z WikiVisor 11 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-1|Previous]] | [[Guide:95lrm/RM-9-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 9.2 Task Execution - Task Activation}} == Dynamic Semantics == <span id="I3351"></span>The execution of a task of a given task type consists of the execution of the corresponding task_body. <span id="I3352"></span><span id="I3353"></span><span id="I3354"></span><span id="I3355"></span>The initial part of this execution is called the ''activation'' of the task; it consists of the elaboration of the declarative_part of the task_body. <span id="I3356"></span>Should an exception be propagated by the elaboration of its declarative_part, the activation of the task is defined to have ''failed'', and it becomes a completed task. A task object (which represents one task) can be created either as part of the elaboration of an object_declaration occurring immediately within some declarative region, or as part of the evaluation of an allocator. All tasks created by the elaboration of object_declarations of a single declarative region (including subcomponents of the declared objects) are activated together. Similarly, all tasks created by the evaluation of a single allocator are activated together. The activation of a task is associated with the innermost allocator or object_declaration that is responsible for its creation. For tasks created by the elaboration of object_declarations of a given declarative region, the activations are initiated within the context of the handled_sequence_of_statements (and its associated exception_handlers if any -- see [[Guide:95lrm/RM-11-2|11.2]]), just prior to executing the statements of the _sequence. For a package without an explicit body or an explicit handled_sequence_of_statements, an implicit body or an implicit null_statement is assumed, as defined in [[Guide:95lrm/RM-7-2|7.2]]. For tasks created by the evaluation of an allocator, the activations are initiated as the last step of evaluating the allocator, after completing any initialization for the object created by the allocator, and prior to returning the new access value. <span id="I3357"></span><span id="I3358"></span>The task that created the new tasks and initiated their activations (the ''activator'') is blocked until all of these activations complete (successfully or not). <span id="I3359"></span>Once all of these activations are complete, if the activation of any of the tasks has failed (due to the propagation of an exception), Tasking_Error is raised in the activator, at the place at which it initiated the activations. Otherwise, the activator proceeds with its execution normally. Any tasks that are aborted prior to completing their activation are ignored when determining whether to raise Tasking_Error. Should the task that created the new tasks never reach the point where it would initiate the activations (due to an abort or the raising of an exception), the newly created tasks become terminated and are never activated. == Notes == 5  An entry of a task can be called before the task has been activated. 6  If several tasks are activated together, the execution of any of these tasks need not await the end of the activation of the other tasks. 7  A task can become completed during its activation either because of an exception or because it is aborted (see [[Guide:95lrm/RM-9-8|9.8]]). == Examples == ''Example of task activation:'' <p><syntaxhighlight lang="Ada"> procedure P is A, B : Server;    --  elaborate the task objects A, B C    : Server;    --  elaborate the task object C begin --  the tasks A, B, C are activated together before the first statement ... end;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-1|Previous]] | [[Guide:95lrm/RM-9-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} r61esmpuq966o3gsdorr6klt36kpzt2 Guide:95lrm/RM-9-3 4200 1051 4323 2019-04-30T10:27:24Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-2|Previous]] | [[Guide:95lrm/RM-9-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 9.3 Task Dependence - Termination of Tasks}} == Dynamic Semantics == <span id="I3360"></span><span id="I3361"></span><span id="I3362"></span><span id="I3363"></span>Each task (other than an environment task -- see [[Guide:95lrm/RM-10-2|10.2]]) ''depends'' on one or more masters (see [[Guide:95lrm/RM-7-6-1|7.6.1]]), as follows: * If the task is created by the evaluation of an allocator for a given access type, it depends on each master that includes the elaboration of the declaration of the ultimate ancestor of the given access type. * If the task is created by the elaboration of an object_declaration, it depends on each master that includes this elaboration. <span id="I3364"></span>Furthermore, if a task depends on a given master, it is defined to depend on the task that executes the master, and (recursively) on any master of that task. A task is said to be ''completed'' when the execution of its corresponding task_body is completed. A task is said to be ''terminated'' when any finalization of the task_body has been performed (see [[Guide:95lrm/RM-7-6-1|7.6.1]]). The first step of finalizing a master (including a task_body) is to wait for the termination of any tasks dependent on the master. <span id="I3365"></span>The task executing the master is blocked until all the dependents have terminated. Any remaining finalization is then performed and the master is left. Completion of a task (and the corresponding task_body) can occur when the task is blocked at a select_statement with an open terminate_alternative (see [[Guide:95lrm/RM-9-7-1|9.7.1]]); the open terminate_alternative is selected if and only if the following conditions are satisfied: * The task depends on some completed master; * Each task that depends on the master considered is either already terminated or similarly blocked at a select_statement with an open terminate_alternative. When both conditions are satisfied, the task considered becomes completed, together with all tasks that depend on the master considered that are not yet completed. == Notes == 8  The full view of a limited private type can be a task type, or can have subcomponents of a task type. Creation of an object of such a type creates dependences according to the full type. 9  An object_renaming_declaration defines a new view of an existing entity and hence creates no further dependence. 10  The rules given for the collective completion of a group of tasks all blocked on select_statements with open terminate_alternatives ensure that the collective completion can occur only when there are no remaining active tasks that could call one of the tasks being collectively completed. 11  If two or more tasks are blocked on select_statements with open terminate_alternatives, and become completed collectively, their finalization actions proceed concurrently. 12  The completion of a task can occur due to any of the following: * the raising of an exception during the elaboration of the declarative_part of the corresponding task_body; * the completion of the handled_sequence_of_statements of the corresponding task_body; * the selection of an open terminate_alternative of a select_statement in the corresponding task_body; * the abort of the task. == Examples == ''Example of task dependence:'' <p><syntaxhighlight lang="Ada"> declare type Global is access Server;        --  see 9.1 A, B : Server; G    : Global; begin --  activation of A and B declare    type Local is access Server;    X : Global := new Server;  --  activation of X.all     L : Local  := new Server;  --  activation of L.all     C : Server; begin    --  activation of C    G := X;  --  both G and X designate the same task object    ... end;  --  await termination of C and L.all (but not X.all) ... end;  --  await termination of A, B, and G.all</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-2|Previous]] | [[Guide:95lrm/RM-9-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} etje9ntntoa54nklcmuygmsgfa09tok Guide:95lrm/RM-9-4 4200 1052 4324 2019-04-30T10:38:21Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-3|Previous]] | [[Guide:95lrm/RM-9-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 9.4 Protected Units and Protected Objects}} <span id="I3366"></span><span id="I3367"></span><span id="I3368"></span><span id="I3369"></span>A ''protected object'' provides coordinated access to shared data, through calls on its visible ''protected operations'', which can be ''protected subprograms'' or ''protected entries''. <span id="I3370"></span><span id="I3371"></span><span id="I3372"></span>A ''protected unit'' is declared by a ''protected declaration'', which has a corresponding protected_body. A protected declaration may be a protected_type_declaration, in which case it declares a named protected type; alternatively, it may be a single_protected_declaration, in which case it defines an anonymous protected type, as well as declaring a named protected object of that type. <span id="I3373"></span> == Syntax == <p><span></span></p> protected_type_declaration<span id="I3374"></span> ::= '''protected''' '''type''' <span id="I3375"></span>defining_identifier [<span id="I3376"></span>known_discriminant_part] '''is''' <span id="I3377"></span>protected_definition; <p><span></span></p> single_protected_declaration<span id="I3378"></span> ::= '''protected''' <span id="I3379"></span>defining_identifier '''is''' <span id="I3380"></span>protected_definition; <p><span></span></p> protected_definition<span id="I3381"></span> ::= { <span id="I3382"></span>protected_operation_declaration } [ '''private''' { <span id="I3383"></span>protected_element_declaration } ] '''end''' [''protected_''<span id="I3384"></span>identifier] <p><span></span></p> protected_operation_declaration<span id="I3385"></span> ::= <span id="I3386"></span>subprogram_declaration | <span id="I3387"></span>entry_declaration | <span id="I3388"></span>aspect_clause <p><span></span></p> protected_element_declaration<span id="I3389"></span> ::= <span id="I3390"></span>protected_operation_declaration | <span id="I3391"></span>component_declaration <p><span></span></p> protected_body<span id="I3392"></span> ::= '''protected''' '''body''' <span id="I3393"></span>defining_identifier '''is''' { <span id="I3394"></span>protected_operation_item } '''end''' [''protected_''<span id="I3395"></span>identifier]; <p><span></span></p> protected_operation_item<span id="I3396"></span> ::= <span id="I3397"></span>subprogram_declaration | <span id="I3398"></span>subprogram_body | <span id="I3399"></span>entry_body | <span id="I3400"></span>aspect_clause If a ''protected_''identifier appears at the end of a protected_definition or protected_body, it shall repeat the defining_identifier. == Legality Rules == <span id="I3401"></span>A protected declaration requires a completion, which shall be a protected_body, and every protected_body shall be the completion of some protected declaration. == Static Semantics == A protected_definition defines a protected type and its first subtype. <span id="I3402"></span>The list of protected_operation_declarations of a protected_definition, together with the known_discriminant_part, if any, is called the visible part of the protected unit. <span id="I3403"></span>The optional list of protected_element_declarations after the reserved word '''private''' is called the private part of the protected unit. == Dynamic Semantics == <span id="I3404"></span>The elaboration of a protected declaration elaborates the protected_definition. <span id="I3405"></span>The elaboration of a single_protected_declaration also creates an object of an (anonymous) protected type. <span id="I3406"></span>The elaboration of a protected_definition creates the protected type and its first subtype; it also includes the elaboration of the component_declarations and protected_operation_declarations in the given order. <span id="I3407"></span>As part of the initialization of a protected object, any per-object constraints (see [[Guide:95lrm/RM-3-8|3.8]]) are elaborated. <span id="I3408"></span>The elaboration of a protected_body has no other effect than to establish that protected operations of the type can from then on be called without failing the Elaboration_Check. The content of an object of a given protected type includes: * The values of the components of the protected object, including (implicitly) an entry queue for each entry declared for the protected object; * <span id="I3409"></span>A representation of the state of the execution resource ''associated'' with the protected object (one such resource is associated with each protected object). The execution resource associated with a protected object has to be acquired to read or update any components of the protected object; it can be acquired (as part of a protected action -- see [[Guide:95lrm/RM-9-5-1|9.5.1]]) either for concurrent read-only access, or for exclusive read-write access. <span id="I3410"></span><span id="I3411"></span>As the first step of the ''finalization'' of a protected object, each call remaining on any entry queue of the object is removed from its queue and Program_Error is raised at the place of the corresponding entry_call_statement. == Notes == 13  Within the declaration or body of a protected unit, the name of the protected unit denotes the current instance of the unit (see [[Guide:95lrm/RM-8-6|8.6]]), rather than the first subtype of the corresponding protected type (and thus the name cannot be used as a subtype_mark). 14  A selected_component can be used to denote a discriminant of a protected object (see [[Guide:95lrm/RM-4-1-3|4.1.3]]). Within a protected unit, the name of a discriminant of the protected type denotes the corresponding discriminant of the current instance of the unit. 15  A protected type is a limited type (see [[Guide:95lrm/RM-7-5|7.5]]), and hence has neither an assignment operation nor predefined equality operators. 16  The bodies of the protected operations given in the protected_body define the actions that take place upon calls to the protected operations. 17  The declarations in the private part are only visible within the private part and the body of the protected unit. == Examples == ''Example of declaration of protected type and corresponding body:'' <p><syntaxhighlight lang="Ada"> protected type Resource is entry Seize; procedure Release; private Busy : Boolean := False; end Resource;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> protected body Resource is entry Seize when not Busy is begin    Busy := True; end Seize;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Release is begin    Busy := False; end Release; end Resource;</syntaxhighlight></p> ''Example of a single protected declaration and corresponding body:'' <p><syntaxhighlight lang="Ada"> protected Shared_Array is --  Index, Item, and Item_Array are global types function  Component    (N : in Index) return Item; procedure Set_Component(N : in Index; E : in  Item); private Table : Item_Array(Index) := (others => Null_Item); end Shared_Array;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> protected body Shared_Array is function Component(N : in Index) return Item is begin    return Table(N); end Component;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Set_Component(N : in Index; E : in Item) is begin    Table(N) := E; end Set_Component; end Shared_Array;</syntaxhighlight></p> ''Examples of protected objects:'' <p><syntaxhighlight lang="Ada"> Control  : Resource; Flags    : array(1 .. 100) of Resource;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-3|Previous]] | [[Guide:95lrm/RM-9-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 4j7x69ii4xbhzcgf4v2v6zt7a9jjklq Guide:95lrm/RM-9-5 4200 1053 4325 2019-04-29T15:48:18Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-4|Previous]] | [[Guide:95lrm/RM-9-5-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 9.5 Intertask Communication}} <span id="I3412"></span><span id="I3413"></span>The primary means for intertask communication is provided by calls on entries and protected subprograms. Calls on protected subprograms allow coordinated access to shared data objects. Entry calls allow for blocking the caller until a given condition is satisfied (namely, that the corresponding entry is open -- see [[Guide:95lrm/RM-9-5-3|9.5.3]]), and then communicating data or control information directly with another task or indirectly via a shared protected object. == Static Semantics == <span id="I3414"></span>Any call on an entry or on a protected subprogram identifies a ''target object'' for the operation, which is either a task (for an entry call) or a protected object (for an entry call or a protected subprogram call). The target object is considered an implicit parameter to the operation, and is determined by the operation name (or prefix) used in the call on the operation, as follows: * If it is a direct_name or expanded name that denotes the declaration (or body) of the operation, then the target object is implicitly specified to be the current instance of the task or protected unit immediately enclosing the operation; <span id="I3415"></span>such a call is defined to be an ''internal call''; * If it is a selected_component that is not an expanded name, then the target object is explicitly specified to be the task or protected object denoted by the prefix of the name; <span id="I3416"></span>such a call is defined to be an ''external call''; * If the name or prefix is a dereference (implicit or explicit) of an access-to-protected-subprogram value, then the target object is determined by the prefix of the Access attribute_reference that produced the access value originally, and the call is defined to be an ''external call''; * If the name or prefix denotes a subprogram_renaming_declaration, then the target object is as determined by the name of the renamed entity. <span id="I3417"></span><span id="I3418"></span><span id="I3419"></span>A corresponding definition of target object applies to a requeue_statement (see [[Guide:95lrm/RM-9-5-4|9.5.4]]), with a corresponding distinction between an ''internal requeue'' and an ''external requeue''. == Dynamic Semantics == Within the body of a protected operation, the current instance (see [[Guide:95lrm/RM-8-6|8.6]]) of the immediately enclosing protected unit is determined by the target object specified (implicitly or explicitly) in the call (or requeue) on the protected operation. Any call on a protected procedure or entry of a target protected object is defined to be an update to the object, as is a requeue on such an entry. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-4|Previous]] | [[Guide:95lrm/RM-9-5-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} igrr6lu1z7qev3jocbihdg3oe2v4y9n Guide:95lrm/RM-9-5-1 4200 1054 4326 2019-04-30T10:39:06Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-5|Previous]] | [[Guide:95lrm/RM-9-5-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 9.5.1 Protected Subprograms and Protected Actions}} <span id="I3420"></span><span id="I3421"></span><span id="I3422"></span>A ''protected subprogram'' is a subprogram declared immediately within a protected_definition. Protected procedures provide exclusive read-write access to the data of a protected object; protected functions provide concurrent read-only access to the data. == Static Semantics == Within the body of a protected function (or a function declared immediately within a protected_body), the current instance of the enclosing protected unit is defined to be a constant (that is, its subcomponents may be read but not updated). Within the body of a protected procedure (or a procedure declared immediately within a protected_body), and within an entry_body, the current instance is defined to be a variable (updating is permitted). == Dynamic Semantics == <span id="I3423"></span>For the execution of a call on a protected subprogram, the evaluation of the name or prefix and of the parameter associations, and any assigning back of '''in out''' or '''out''' parameters, proceeds as for a normal subprogram call (see [[Guide:95lrm/RM-6-4|6.4]]). If the call is an internal call (see [[Guide:95lrm/RM-9-5|9.5]]), the body of the subprogram is executed as for a normal subprogram call. If the call is an external call, then the body of the subprogram is executed as part of a new ''protected action'' on the target protected object; the protected action completes after the body of the subprogram is executed. A protected action can also be started by an entry call (see [[Guide:95lrm/RM-9-5-3|9.5.3]]). <span id="I3424"></span>A new protected action is not started on a protected object while another protected action on the same protected object is underway, unless both actions are the result of a call on a protected function. This rule is expressible in terms of the execution resource associated with the protected object: * <span id="I3425"></span><span id="I3426"></span>''Starting'' a protected action on a protected object corresponds to ''acquiring'' the execution resource associated with the protected object, either for concurrent read-only access if the protected action is for a call on a protected function, or for exclusive read-write access otherwise; * <span id="I3427"></span><span id="I3428"></span>''Completing'' the protected action corresponds to ''releasing'' the associated execution resource. After performing an operation on a protected object other than a call on a protected function, but prior to completing the associated protected action, the entry queues (if any) of the protected object are serviced (see [[Guide:95lrm/RM-9-5-3|9.5.3]]). == Bounded (Run-Time) Errors == <span id="I3429"></span>During a protected action, it is a bounded error to invoke an operation that is ''potentially blocking''. <span id="I3430"></span><span id="I3431"></span>The following are defined to be potentially blocking operations: * a select_statement; * an accept_statement; * an entry_call_statement; * a delay_statement; * an abort_statement; * task creation or activation; * an external call on a protected subprogram (or an external requeue) with the same target object as that of the protected action; * a call on a subprogram whose body contains a potentially blocking operation. <span id="I3432"></span>If the bounded error is detected, Program_Error is raised. If not detected, the bounded error might result in deadlock or a (nested) protected action on the same target object. Certain language-defined subprograms are potentially blocking. In particular, the subprograms of the language-defined input-output packages that manipulate files (implicitly or explicitly) are potentially blocking. Other potentially blocking subprograms are identified where they are defined. When not specified as potentially blocking, a language-defined subprogram is nonblocking. == Notes == 18  If two tasks both try to start a protected action on a protected object, and at most one is calling a protected function, then only one of the tasks can proceed. Although the other task cannot proceed, it is not considered blocked, and it might be consuming processing resources while it awaits its turn. There is no language-defined ordering or queuing presumed for tasks competing to start a protected action -- on a multiprocessor such tasks might use busy-waiting; for monoprocessor considerations, see [[Guide:95lrm/RM-D-3|D.3]], ''[[Guide:95lrm/RM-D-3|Priority Ceiling Locking]]''. 19  The body of a protected unit may contain declarations and bodies for local subprograms. These are not visible outside the protected unit. 20  The body of a protected function can contain internal calls on other protected functions, but not protected procedures, because the current instance is a constant. On the other hand, the body of a protected procedure can contain internal calls on both protected functions and procedures. 21  From within a protected action, an internal call on a protected subprogram, or an external call on a protected subprogram with a different target object is not considered a potentially blocking operation. == Examples == ''Examples of protected subprogram calls (see [[Guide:95lrm/RM-9-4|9.4]]):'' <p><syntaxhighlight lang="Ada"> Shared_Array.Set_Component(N, E); E := Shared_Array.Component(M); Control.Release;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-5|Previous]] | [[Guide:95lrm/RM-9-5-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 6vclx1flc0o52u6m4ztdnefulmynr2b Guide:95lrm/RM-9-5-2 4200 1055 4327 2019-04-30T10:43:06Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-5-1|Previous]] | [[Guide:95lrm/RM-9-5-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 9.5.2 Entries and Accept Statements}} Entry_declarations, with the corresponding entry_bodies or accept_statements, are used to define potentially queued operations on tasks and protected objects. == Syntax == <p><span></span></p> entry_declaration<span id="I3433"></span> ::= '''entry''' <span id="I3434"></span>defining_identifier [(<span id="I3435"></span>discrete_subtype_definition)] <span id="I3436"></span>parameter_profile; <p><span></span></p> accept_statement<span id="I3437"></span> ::= '''accept''' ''entry_''<span id="I3438"></span>direct_name [(<span id="I3439"></span>entry_index)] <span id="I3440"></span>parameter_profile ['''do''' <span id="I3441"></span>handled_sequence_of_statements '''end''' [''entry_''<span id="I3442"></span>identifier]]; <p><span></span></p> entry_index<span id="I3443"></span> ::= <span id="I3444"></span>expression <p><span></span></p> entry_body<span id="I3445"></span> ::= '''entry''' <span id="I3446"></span>defining_identifier  <span id="I3447"></span>entry_body_formal_part  <span id="I3448"></span>entry_barrier '''is''' <span id="I3449"></span>declarative_part '''begin''' <span id="I3450"></span>handled_sequence_of_statements '''end''' [''entry_''<span id="I3451"></span>identifier]; <p><span></span></p> entry_body_formal_part<span id="I3452"></span> ::= [(<span id="I3453"></span>entry_index_specification)] <span id="I3454"></span>parameter_profile <p><span></span></p> entry_barrier<span id="I3455"></span> ::= '''when''' <span id="I3456"></span>condition <p><span></span></p> entry_index_specification<span id="I3457"></span> ::= '''for''' <span id="I3458"></span>defining_identifier '''in''' <span id="I3459"></span>discrete_subtype_definition If an ''entry_''identifier appears at the end of an accept_statement, it shall repeat the ''entry_''direct_name. If an ''entry_''identifier appears at the end of an entry_body, it shall repeat the defining_identifier. An entry_declaration is allowed only in a protected or task declaration. == Name Resolution Rules == <span id="I3460"></span>In an accept_statement, the expected profile for the ''entry_''direct_name is that of the entry_declaration; <span id="I3461"></span>the expected type for an entry_index is that of the subtype defined by the discrete_subtype_definition of the corresponding entry_declaration. Within the handled_sequence_of_statements of an accept_statement, if a selected_component has a prefix that denotes the corresponding entry_declaration, then the entity denoted by the prefix is the accept_statement, and the selected_component is interpreted as an expanded name (see [[Guide:95lrm/RM-4-1-3|4.1.3]]); the selector_name of the selected_component has to be the identifier for some formal parameter of the accept_statement. == Legality Rules == An entry_declaration in a task declaration shall not contain a specification for an access parameter (see [[Guide:95lrm/RM-3-10|3.10]]). For an accept_statement, the innermost enclosing body shall be a task_body, and the ''entry_''direct_name shall denote an entry_declaration in the corresponding task declaration; the profile of the accept_statement shall conform fully to that of the corresponding entry_declaration. <span id="I3462"></span>An accept_statement shall have a parenthesized entry_index if and only if the corresponding entry_declaration has a discrete_subtype_definition. An accept_statement shall not be within another accept_statement that corresponds to the same entry_declaration, nor within an asynchronous_select inner to the enclosing task_body. <span id="I3463"></span>An entry_declaration of a protected unit requires a completion, which shall be an entry_body, <span id="I3464"></span>and every entry_body shall be the completion of an entry_declaration of a protected unit. <span id="I3465"></span>The profile of the entry_body shall conform fully to that of the corresponding declaration. <span id="I3466"></span> An entry_body_formal_part shall have an entry_index_specification if and only if the corresponding entry_declaration has a discrete_subtype_definition. In this case, the discrete_subtype_definitions of the entry_declaration and the entry_index_specification shall fully conform to one another (see [[Guide:95lrm/RM-6-3-1|6.3.1]]). <span id="I3467"></span> A name that denotes a formal parameter of an entry_body is not allowed within the entry_barrier of the entry_body. == Static Semantics == The parameter modes defined for parameters in the parameter_profile of an entry_declaration are the same as for a subprogram_declaration and have the same meaning (see [[Guide:95lrm/RM-6-2|6.2]]). <span id="I3468"></span><span id="I3469"></span><span id="I3470"></span>An entry_declaration with a discrete_subtype_definition (see [[Guide:95lrm/RM-3-6|3.6]]) declares a ''family'' of distinct entries having the same profile, with one such entry for each value of the ''entry index subtype'' defined by the discrete_subtype_definition. A name for an entry of a family takes the form of an indexed_component, where the prefix denotes the entry_declaration for the family, and the index value identifies the entry within the family. <span id="I3471"></span><span id="I3472"></span>The term ''single entry'' is used to refer to any entry other than an entry of an entry family. In the entry_body for an entry family, the entry_index_specification declares a named constant whose subtype is the entry index subtype defined by the corresponding entry_declaration; <span id="I3473"></span>the value of the ''named entry index'' identifies which entry of the family was called. == Dynamic Semantics == <span id="I3474"></span>The elaboration of an entry_declaration for an entry family consists of the elaboration of the discrete_subtype_definition, as described in [[Guide:95lrm/RM-3-8|3.8]]. The elaboration of an entry_declaration for a single entry has no effect. The actions to be performed when an entry is called are specified by the corresponding accept_statements (if any) for an entry of a task unit, and by the corresponding entry_body for an entry of a protected unit. <span id="I3475"></span>For the execution of an accept_statement, the entry_index, if any, is first evaluated and converted to the entry index subtype; this index value identifies which entry of the family is to be accepted. <span id="I3476"></span><span id="I3477"></span><span id="I3478"></span>Further execution of the accept_statement is then blocked until a caller of the corresponding entry is selected (see [[Guide:95lrm/RM-9-5-3|9.5.3]]), whereupon the handled_sequence_of_statements, if any, of the accept_statement is executed, with the formal parameters associated with the corresponding actual parameters of the selected entry call. Upon completion of the handled_sequence_of_statements, the accept_statement completes and is left. When an exception is propagated from the handled_sequence_of_statements of an accept_statement, the same exception is also raised by the execution of the corresponding entry_call_statement. <span id="I3479"></span>The above interaction between a calling task and an accepting task is called a ''rendezvous''. After a rendezvous, the two tasks continue their execution independently. An entry_body is executed when the condition of the entry_barrier evaluates to True and a caller of the corresponding single entry, or entry of the corresponding entry family, has been selected (see [[Guide:95lrm/RM-9-5-3|9.5.3]]). <span id="I3480"></span>For the execution of the entry_body, the declarative_part of the entry_body is elaborated, and the handled_sequence_of_statements of the body is executed, as for the execution of a subprogram_body. The value of the named entry index, if any, is determined by the value of the entry index specified in the ''entry_''name of the selected entry call (or intermediate requeue_statement -- see [[Guide:95lrm/RM-9-5-4|9.5.4]]). == Notes == 22  A task entry has corresponding accept_statements (zero or more), whereas a protected entry has a corresponding entry_body (exactly one). 23  A consequence of the rule regarding the allowed placements of accept_statements is that a task can execute accept_statements only for its own entries. 24  A return_statement (see [[Guide:95lrm/RM-6-5|6.5]]) or a requeue_statement (see [[Guide:95lrm/RM-9-5-4|9.5.4]]) may be used to complete the execution of an accept_statement or an entry_body. 25  The condition in the entry_barrier may reference anything visible except the formal parameters of the entry. This includes the entry index (if any), the components (including discriminants) of the protected object, the Count attribute of an entry of that protected object, and data global to the protected unit. The restriction against referencing the formal parameters within an entry_barrier ensures that all calls of the same entry see the same barrier value. If it is necessary to look at the parameters of an entry call before deciding whether to handle it, the entry_barrier can be '''''when''' True'' and the caller can be requeued (on some private entry) when its parameters indicate that it cannot be handled immediately. == Examples == ''Examples of entry declarations:'' <p><syntaxhighlight lang="Ada"> entry Read(V : out Item); entry Seize; entry Request(Level)(D : Item);  --  a family of entries</syntaxhighlight></p> ''Examples of accept statements:'' <p><syntaxhighlight lang="Ada"> accept Shut_Down;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> accept Read(V : out Item) do V := Local_Item; end Read;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> accept Request(Low)(D : Item) do ... end Request;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-5-1|Previous]] | [[Guide:95lrm/RM-9-5-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 8sejzvcuacsk6qm8k1u4py0x282ryi9 Guide:95lrm/RM-9-5-3 4200 1056 4328 2019-05-04T12:59:03Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-5-2|Previous]] | [[Guide:95lrm/RM-9-5-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 9.5.3 Entry Calls}} <span id="I3481"></span>An entry_call_statement (an ''entry call'') can appear in various contexts. <span id="I3482"></span><span id="I3483"></span>A ''simple'' entry call is a stand-alone statement that represents an unconditional call on an entry of a target task or a protected object. Entry calls can also appear as part of select_statements (see [[Guide:95lrm/RM-9-7|9.7]]). == Syntax == <p><span></span></p> entry_call_statement<span id="I3484"></span> ::= ''entry_''<span id="I3485"></span>name [<span id="I3486"></span>actual_parameter_part]; == Name Resolution Rules == The ''entry_''name given in an entry_call_statement shall resolve to denote an entry. The rules for parameter associations are the same as for subprogram calls (see [[Guide:95lrm/RM-6-4|6.4]] and [[Guide:95lrm/RM-6-4-1|6.4.1]]). == Static Semantics == The ''entry_''name of an entry_call_statement specifies (explicitly or implicitly) the target object of the call, the entry or entry family, and the entry index, if any (see [[Guide:95lrm/RM-9-5|9.5]]). == Dynamic Semantics == <span id="I3487"></span><span id="I3488"></span><span id="I3489"></span><span id="I3490"></span>Under certain circumstances (detailed below), an entry of a task or protected object is checked to see whether it is ''open'' or ''closed'': * <span id="I3491"></span><span id="I3492"></span>An entry of a task is open if the task is blocked on an accept_statement that corresponds to the entry (see [[Guide:95lrm/RM-9-5-2|9.5.2]]), or on a selective_accept (see [[Guide:95lrm/RM-9-7-1|9.7.1]]) with an open accept_alternative that corresponds to the entry; otherwise it is closed. * <span id="I3493"></span><span id="I3494"></span>An entry of a protected object is open if the condition of the entry_barrier of the corresponding entry_body evaluates to True; otherwise it is closed. <span id="I3495"></span>If the evaluation of the condition propagates an exception, the exception Program_Error is propagated to all current callers of all entries of the protected object. <span id="I3496"></span>For the execution of an entry_call_statement, evaluation of the name and of the parameter associations is as for a subprogram call (see [[Guide:95lrm/RM-6-4|6.4]]). <span id="I3497"></span>The entry call is then ''issued'': For a call on an entry of a protected object, a new protected action is started on the object (see [[Guide:95lrm/RM-9-5-1|9.5.1]]). The named entry is checked to see if it is open; <span id="I3498"></span>if open, the entry call is said to be ''selected immediately'', and the execution of the call proceeds as follows: * For a call on an open entry of a task, the accepting task becomes ready and continues the execution of the corresponding accept_statement (see [[Guide:95lrm/RM-9-5-2|9.5.2]]). * For a call on an open entry of a protected object, the corresponding entry_body is executed (see [[Guide:95lrm/RM-9-5-2|9.5.2]]) as part of the protected action. If the accept_statement or entry_body completes other than by a requeue (see [[Guide:95lrm/RM-9-5-4|9.5.4]]), return is made to the caller (after servicing the entry queues -- see below); any necessary assigning back of formal to actual parameters occurs, as for a subprogram call (see [[Guide:95lrm/RM-6-4-1|6.4.1]]); such assignments take place outside of any protected action. If the named entry is closed, the entry call is added to an ''entry queue'' (as part of the protected action, for a call on a protected entry), and the call remains queued until it is selected or cancelled; <span id="I3499"></span>there is a separate (logical) entry queue for each entry of a given task or protected object (including each entry of an entry family). <span id="I3500"></span><span id="I3501"></span>When a queued call is ''selected'', it is removed from its entry queue. Selecting a queued call from a particular entry queue is called ''servicing'' the entry queue. An entry with queued calls can be serviced under the following circumstances: * When the associated task reaches a corresponding accept_statement, or a selective_accept with a corresponding open accept_alternative; * If after performing, as part of a protected action on the associated protected object, an operation on the object other than a call on a protected function, the entry is checked and found to be open. <span id="I3502"></span>If there is at least one call on a queue corresponding to an open entry, then one such call is selected according to the ''entry queuing policy'' in effect (see below), and the corresponding accept_statement or entry_body is executed as above for an entry call that is selected immediately. <span id="I3503"></span>The entry queuing policy controls selection among queued calls both for task and protected entry queues. <span id="I3504"></span><span id="I3505"></span>The default entry queuing policy is to select calls on a given entry queue in order of arrival. If calls from two or more queues are simultaneously eligible for selection, the default entry queuing policy does not specify which queue is serviced first. Other entry queuing policies can be specified by pragmas (see [[Guide:95lrm/RM-D-4|D.4]]). For a protected object, the above servicing of entry queues continues until there are no open entries with queued calls, at which point the protected action completes. <span id="I3506"></span>For an entry call that is added to a queue, and that is not the triggering_statement of an asynchronous_select (see [[Guide:95lrm/RM-9-7-4|9.7.4]]), the calling task is blocked until the call is cancelled, or the call is selected and a corresponding accept_statement or entry_body completes without requeuing. In addition, the calling task is blocked during a rendezvous. <span id="I3507"></span>An attempt can be made to cancel an entry call upon an abort (see [[Guide:95lrm/RM-9-8|9.8]]) and as part of certain forms of select_statement (see [[Guide:95lrm/RM-9-7-2|9.7.2]], [[Guide:95lrm/RM-9-7-3|9.7.3]], and [[Guide:95lrm/RM-9-7-4|9.7.4]]). The cancellation does not take place until a point (if any) when the call is on some entry queue, and not protected from cancellation as part of a requeue (see [[Guide:95lrm/RM-9-5-4|9.5.4]]); at such a point, the call is removed from the entry queue and the call completes due to the cancellation. The cancellation of a call on an entry of a protected object is a protected action, and as such cannot take place while any other protected action is occurring on the protected object. Like any protected action, it includes servicing of the entry queues (in case some entry barrier depends on a Count attribute). <span id="I3508"></span>A call on an entry of a task that has already completed its execution raises the exception Tasking_Error at the point of the call; similarly, this exception is raised at the point of the call if the called task completes its execution or becomes abnormal before accepting the call or completing the rendezvous (see [[Guide:95lrm/RM-9-8|9.8]]). This applies equally to a simple entry call and to an entry call as part of a select_statement. == Implementation Permissions == An implementation may perform the sequence of steps of a protected action using any thread of control; it need not be that of the task that started the protected action. If an entry_body completes without requeuing, then the corresponding calling task may be made ready without waiting for the entire protected action to complete. When the entry of a protected object is checked to see whether it is open, the implementation need not reevaluate the condition of the corresponding entry_barrier if no variable or attribute referenced by the condition (directly or indirectly) has been altered by the execution (or cancellation) of a protected procedure or entry call on the object since the condition was last evaluated. An implementation may evaluate the conditions of all entry_barriers of a given protected object any time any entry of the object is checked to see if it is open. When an attempt is made to cancel an entry call, the implementation need not make the attempt using the thread of control of the task (or interrupt) that initiated the cancellation; in particular, it may use the thread of control of the caller itself to attempt the cancellation, even if this might allow the entry call to be selected in the interim. == Notes == 26  If an exception is raised during the execution of an entry_body, it is propagated to the corresponding caller (see [[Guide:95lrm/RM-11-4|11.4]]). 27  For a call on a protected entry, the entry is checked to see if it is open prior to queuing the call, and again thereafter if its Count attribute (see [[Guide:95lrm/RM-9-9|9.9]]) is referenced in some entry barrier. 28  In addition to simple entry calls, the language permits timed, conditional, and asynchronous entry calls (see [[Guide:95lrm/RM-9-7-2|9.7.2]], [[Guide:95lrm/RM-9-7-3|9.7.3]], and see [[Guide:95lrm/RM-9-7-4|9.7.4]]). 29  The condition of an entry_barrier is allowed to be evaluated by an implementation more often than strictly necessary, even if the evaluation might have side effects. On the other hand, an implementation need not reevaluate the condition if nothing it references was updated by an intervening protected action on the protected object, even if the condition references some global variable that might have been updated by an action performed from outside of a protected action. == Examples == ''Examples of entry calls:'' <p><syntaxhighlight lang="Ada"> Agent.Shut_Down;                      --  see 9.1 Parser.Next_Lexeme(E);                --  see 9.1 Pool(5).Read(Next_Char);              --  see 9.1 Controller.Request(Low)(Some_Item);   --  see 9.1 Flags(3).Seize;                       --  see 9.4</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-5-2|Previous]] | [[Guide:95lrm/RM-9-5-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} rsqixhzy6k2e9uv1mmqvfg1lotm1gns Guide:95lrm/RM-9-5-4 4200 1057 4329 2019-04-30T10:44:44Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-5-3|Previous]] | [[Guide:95lrm/RM-9-6|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 9.5.4 Requeue Statements}} A requeue_statement can be used to complete an accept_statement or entry_body, while redirecting the corresponding entry call to a new (or the same) entry queue. <span id="I3509"></span>Such a ''requeue'' can be performed with or without allowing an intermediate cancellation of the call, due to an abort or the expiration of a delay. <span id="I3510"></span><span id="I3511"></span> == Syntax == <p><span></span></p> requeue_statement<span id="I3512"></span> ::= '''requeue''' ''entry_''<span id="I3513"></span>name ['''with''' '''abort''']; == Name Resolution Rules == <span id="I3514"></span>The ''entry_''name of a requeue_statement shall resolve to denote an entry (the ''target entry'') that either has no parameters, or that has a profile that is type conformant (see [[Guide:95lrm/RM-6-3-1|6.3.1]]) with the profile of the innermost enclosing entry_body or accept_statement. <span id="I3515"></span> == Legality Rules == A requeue_statement shall be within a callable construct that is either an entry_body or an accept_statement, and this construct shall be the innermost enclosing body or callable construct. If the target entry has parameters, then its profile shall be subtype conformant with the profile of the innermost enclosing callable construct. <span id="I3516"></span> <span id="I3517"></span>In a requeue_statement of an accept_statement of some task unit, either the target object shall be a part of a formal parameter of the accept_statement, or the accessibility level of the target object shall not be equal to or statically deeper than any enclosing accept_statement of the task unit. In a requeue_statement of an entry_body of some protected unit, either the target object shall be a part of a formal parameter of the entry_body, or the accessibility level of the target object shall not be statically deeper than that of the entry_declaration. == Dynamic Semantics == <span id="I3518"></span>The execution of a requeue_statement proceeds by first evaluating the ''entry_''name, including the prefix identifying the target task or protected object and the expression identifying the entry within an entry family, if any. The entry_body or accept_statement enclosing the requeue_statement is then completed, finalized, and left (see [[Guide:95lrm/RM-7-6-1|7.6.1]]). <span id="I3519"></span>For the execution of a requeue on an entry of a target task, after leaving the enclosing callable construct, the named entry is checked to see if it is open and the requeued call is either selected immediately or queued, as for a normal entry call (see [[Guide:95lrm/RM-9-5-3|9.5.3]]). <span id="I3520"></span>For the execution of a requeue on an entry of a target protected object, after leaving the enclosing callable construct: * if the requeue is an internal requeue (that is, the requeue is back on an entry of the same protected object -- see [[Guide:95lrm/RM-9-5|9.5]]), the call is added to the queue of the named entry and the ongoing protected action continues (see [[Guide:95lrm/RM-9-5-1|9.5.1]]); * if the requeue is an external requeue (that is, the target protected object is not implicitly the same as the current object -- see [[Guide:95lrm/RM-9-5|9.5]]), a protected action is started on the target object and proceeds as for a normal entry call (see [[Guide:95lrm/RM-9-5-3|9.5.3]]). If the new entry named in the requeue_statement has formal parameters, then during the execution of the accept_statement or entry_body corresponding to the new entry, the formal parameters denote the same objects as did the corresponding formal parameters of the callable construct completed by the requeue. In any case, no parameters are specified in a requeue_statement; any parameter passing is implicit. <span id="I3521"></span>If the requeue_statement includes the reserved words '''with abort''' (it is a ''requeue-with-abort''), then: * if the original entry call has been aborted (see [[Guide:95lrm/RM-9-8|9.8]]), then the requeue acts as an abort completion point for the call, and the call is cancelled and no requeue is performed; * if the original entry call was timed (or conditional), then the original expiration time is the expiration time for the requeued call. If the reserved words '''with abort''' do not appear, then the call remains protected against cancellation while queued as the result of the requeue_statement. == Notes == 30  A requeue is permitted from a single entry to an entry of an entry family, or vice-versa. The entry index, if any, plays no part in the subtype conformance check between the profiles of the two entries; an entry index is part of the ''entry_''name for an entry of a family. <span id="I3522"></span> == Examples == ''Examples of requeue statements:'' <p><syntaxhighlight lang="Ada"> requeue Request(Medium) with abort;                  -- requeue on a member of an entry family of the current task, see 9.1</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> requeue Flags(I).Seize;                  -- requeue on an entry of an array component, see 9.4</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-5-3|Previous]] | [[Guide:95lrm/RM-9-6|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 2fh7fz95z0mshljazs94u19pilh37hi Guide:95lrm/RM-9-6 4200 1058 4330 2019-04-30T10:50:11Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-5-4|Previous]] | [[Guide:95lrm/RM-9-7|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 9.6 Delay Statements, Duration, and Time}} <span id="I3523"></span>A delay_statement is used to block further execution until a specified ''expiration time'' is reached. The expiration time can be specified either as a particular point in time (in a delay_until_statement), or in seconds from the current time (in a delay_relative_statement). The language-defined package Calendar provides definitions for a type Time and associated operations, including a function Clock that returns the current time. <span id="I3524"></span> == Syntax == <p><span></span></p> delay_statement<span id="I3525"></span> ::= <span id="I3526"></span>delay_until_statement | <span id="I3527"></span>delay_relative_statement <p><span></span></p> delay_until_statement<span id="I3528"></span> ::= '''delay until''' ''delay_''<span id="I3529"></span>expression; <p><span></span></p> delay_relative_statement<span id="I3530"></span> ::= '''delay''' ''delay_''<span id="I3531"></span>expression; == Name Resolution Rules == <span id="I3532"></span>The expected type for the ''delay_''expression in a delay_relative_statement is the predefined type Duration. <span id="I3533"></span>The ''delay_''expression in a delay_until_statement is expected to be of any nonlimited type. == Legality Rules == <span id="I3534"></span><span id="I3535"></span><span id="I3536"></span>There can be multiple time bases, each with a corresponding clock, and a corresponding ''time type''. The type of the ''delay_''expression in a delay_until_statement shall be a time type -- either the type Time defined in the language-defined package Calendar (see below), or some other implementation-defined time type (see [[Guide:95lrm/RM-D-8|D.8]]). == Static Semantics == There is a predefined fixed point type named Duration, declared in the visible part of package Standard; a value of type Duration is used to represent the length of an interval of time, expressed in seconds. The type Duration is not specific to a particular time base, but can be used with any time base. A value of the type Time in package Calendar, or of some other implementation-defined time type, represents a time as reported by a corresponding clock. The following language-defined library package exists: <p><syntaxhighlight lang="Ada"> package Ada.Calendar is   type Time is private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   subtype Year_Number  is Integer range 1901 .. 2099;   subtype Month_Number is Integer range 1 .. 12;   subtype Day_Number   is Integer range 1 .. 31;   subtype Day_Duration is Duration range 0.0 .. 86_400.0;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function Clock return Time;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function Year   (Date : Time) return Year_Number;   function Month  (Date : Time) return Month_Number;   function Day    (Date : Time) return Day_Number;   function Seconds(Date : Time) return Day_Duration;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   procedure Split (Date  : in Time;                 Year    : out Year_Number;                 Month   : out Month_Number;                 Day     : out Day_Number;                 Seconds : out Day_Duration);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function Time_Of(Year  : Year_Number;                 Month   : Month_Number;                 Day     : Day_Number;                 Seconds : Day_Duration := 0.0) return Time;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function "+" (Left : Time;   Right : Duration) return Time;   function "+" (Left : Duration; Right : Time) return Time;   function "-" (Left : Time;   Right : Duration) return Time;   function "-" (Left : Time;   Right : Time) return Duration;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function "<" (Left, Right : Time) return Boolean;   function "<="(Left, Right : Time) return Boolean;   function ">" (Left, Right : Time) return Boolean;   function ">="(Left, Right : Time) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   Time_Error : exception;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> private ... -- not specified by the language end Ada.Calendar;</syntaxhighlight></p> == Dynamic Semantics == <span id="I3561"></span>For the execution of a delay_statement, the ''delay_''expression is first evaluated. <span id="I3562"></span>For a delay_until_statement, the expiration time for the delay is the value of the ''delay_''expression, in the time base associated with the type of the expression. <span id="I3563"></span>For a delay_relative_statement, the expiration time is defined as the current time, in the time base associated with relative delays, plus the value of the ''delay_''expression converted to the type Duration, and then rounded up to the next clock tick. <span id="I3564"></span>The time base associated with relative delays is as defined in [[Guide:95lrm/RM-D-9|D.9]], ''[[Guide:95lrm/RM-D-9|Delay Accuracy]]'' or is implementation defined. <span id="I3565"></span>The task executing a delay_statement is blocked until the expiration time is reached, at which point it becomes ready again. If the expiration time has already passed, the task is not blocked. <span id="I3566"></span>If an attempt is made to ''cancel'' the delay_statement (as part of an asynchronous_select or abort -- see [[Guide:95lrm/RM-9-7-4|9.7.4]] and [[Guide:95lrm/RM-9-8|9.8]]), the _statement is cancelled if the expiration time has not yet passed, thereby completing the delay_statement. The time base associated with the type Time of package Calendar is implementation defined. The function Clock of package Calendar returns a value representing the current time for this time base. The implementation-defined value of the named number System.Tick (see [[Guide:95lrm/RM-13-7|13.7]]) is an approximation of the length of the real-time interval during which the value of Calendar.Clock remains constant. The functions Year, Month, Day, and Seconds return the corresponding values for a given value of the type Time, as appropriate to an implementation-defined timezone; the procedure Split returns all four corresponding values. Conversely, the function Time_Of combines a year number, a month number, a day number, and a duration, into a value of type Time. The operators "+" and "-" for addition and subtraction of times and durations, and the relational operators for times, have the conventional meaning. If Time_Of is called with a seconds value of 86_400.0, the value returned is equal to the value of Time_Of for the next day with a seconds value of 0.0. The value returned by the function Seconds or through the Seconds parameter of the procedure Split is always less than 86_400.0. The exception Time_Error is raised by the function Time_Of if the actual parameters do not form a proper date. This exception is also raised by the operators "+" and "-" if the result is not representable in the type Time or Duration, as appropriate. This exception is also raised by the functions Year, Month, Day, and Seconds and the procedure Split if the year number of the given date is outside of the range of the subtype Year_Number. == Implementation Requirements == The implementation of the type Duration shall allow representation of time intervals (both positive and negative) up to at least 86400 seconds (one day); Duration'Small shall not be greater than twenty milliseconds. The implementation of the type Time shall allow representation of all dates with year numbers in the range of Year_Number; it may allow representation of other dates as well (both earlier and later). == Implementation Permissions == An implementation may define additional time types (see [[Guide:95lrm/RM-D-8|D.8]]). An implementation may raise Time_Error if the value of a ''delay_''expression in a delay_until_statement of a select_statement represents a time more than 90 days past the current time. The actual limit, if any, is implementation-defined. == Implementation Advice == Whenever possible in an implementation, the value of Duration'Small should be no greater than 100 microseconds. The time base for delay_relative_statements should be monotonic; it need not be the same time base as used for Calendar.Clock. == Notes == 31  A delay_relative_statement with a negative value of the ''delay_''expression is equivalent to one with a zero value. 32  A delay_statement may be executed by the environment task; consequently delay_statements may be executed as part of the elaboration of a library_item or the execution of the main subprogram. Such statements delay the environment task (see [[Guide:95lrm/RM-10-2|10.2]]). 33  <span id="I3567"></span><span id="I3568"></span>A delay_statement is an abort completion point and a potentially blocking operation, even if the task is not actually blocked. 34  There is no necessary relationship between System.Tick (the resolution of the clock of package Calendar) and Duration'Small (the ''small'' of type Duration). 35  Additional requirements associated with delay_statements are given in [[Guide:95lrm/RM-D-9|D.9]], ''[[Guide:95lrm/RM-D-9|Delay Accuracy]]''. == Examples == ''Example of a relative delay statement:'' <p><syntaxhighlight lang="Ada"> delay 3.0;  -- delay 3.0 seconds</syntaxhighlight></p> <span id="I3569"></span><span id="I3570"></span>''Example of a periodic task:'' <p><syntaxhighlight lang="Ada"> declare use Ada.Calendar; Next_Time : Time := Clock + Period;                    -- Period is a global constant of type Duration begin loop               -- repeated every Period seconds    delay until Next_Time;     ... -- perform some actions    Next_Time := Next_Time + Period; end loop; end;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-5-4|Previous]] | [[Guide:95lrm/RM-9-7|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 2gw0p172qrdzpla3vgn89dom4kvpnwt Guide:95lrm/RM-9-7 4200 1059 4331 2019-04-30T10:51:26Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-6|Previous]] | [[Guide:95lrm/RM-9-7-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 9.7 Select Statements}} There are four forms of the select_statement. One form provides a selective wait for one or more select_alternatives. Two provide timed and conditional entry calls. The fourth provides asynchronous transfer of control. == Syntax == <p><span></span></p> select_statement<span id="I3571"></span> ::= <span id="I3572"></span>selective_accept | <span id="I3573"></span>timed_entry_call | <span id="I3574"></span>conditional_entry_call | <span id="I3575"></span>asynchronous_select == Examples == ''Example of a select statement:'' <p><syntaxhighlight lang="Ada"> select accept Driver_Awake_Signal; or delay 30.0*Seconds; Stop_The_Train; end select;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-6|Previous]] | [[Guide:95lrm/RM-9-7-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 6t0tdokhmzg9wsl9wlsiqdq5jk87qof Guide:95lrm/RM-9-7-1 4200 1060 4332 2019-04-30T10:57:17Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-7|Previous]] | [[Guide:95lrm/RM-9-7-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 9.7.1 Selective Accept}} This form of the select_statement allows a combination of waiting for, and selecting from, one or more alternatives. The selection may depend on conditions associated with each alternative of the selective_accept. <span id="I3576"></span> == Syntax == <p><span></span></p> selective_accept<span id="I3577"></span> ::= '''select''' [<span id="I3578"></span>guard] <span id="I3579"></span>select_alternative { '''or''' [<span id="I3580"></span>guard] <span id="I3581"></span>select_alternative } [ '''else''' <span id="I3582"></span>sequence_of_statements ] '''end select'''; <p><span></span></p> guard<span id="I3583"></span> ::= '''when''' <span id="I3584"></span>condition => <p><span></span></p> select_alternative<span id="I3585"></span> ::= <span id="I3586"></span>accept_alternative | <span id="I3587"></span>delay_alternative | <span id="I3588"></span>terminate_alternative <p><span></span></p> accept_alternative<span id="I3589"></span> ::= <span id="I3590"></span>accept_statement [<span id="I3591"></span>sequence_of_statements] <p><span></span></p> delay_alternative<span id="I3592"></span> ::= <span id="I3593"></span>delay_statement [<span id="I3594"></span>sequence_of_statements] <p><span></span></p> terminate_alternative<span id="I3595"></span> ::= '''terminate'''; A selective_accept shall contain at least one accept_alternative. In addition, it can contain: * a terminate_alternative (only one); or * one or more delay_alternatives; or * <span id="I3596"></span>an ''else part'' (the reserved word '''else''' followed by a sequence_of_statements). These three possibilities are mutually exclusive. == Legality Rules == If a selective_accept contains more than one delay_alternative, then all shall be delay_relative_statements, or all shall be delay_until_statements for the same time type. == Dynamic Semantics == <span id="I3597"></span>A select_alternative is said to be ''open'' if it is not immediately preceded by a guard, or if the condition of its guard evaluates to True. It is said to be ''closed'' otherwise. <span id="I3598"></span>For the execution of a selective_accept, any guard conditions are evaluated; open alternatives are thus determined. For an open delay_alternative, the ''delay_''expression is also evaluated. Similarly, for an open accept_alternative for an entry of a family, the entry_index is also evaluated. These evaluations are performed in an arbitrary order, except that a ''delay_''expression or entry_index is not evaluated until after evaluating the corresponding condition, if any. Selection and execution of one open alternative, or of the else part, then completes the execution of the selective_accept; the rules for this selection are described below. Open accept_alternatives are first considered. Selection of one such alternative takes place immediately if the corresponding entry already has queued calls. If several alternatives can thus be selected, one of them is selected according to the entry queuing policy in effect (see [[Guide:95lrm/RM-9-5-3|9.5.3]] and [[Guide:95lrm/RM-D-4|D.4]]). When such an alternative is selected, the selected call is removed from its entry queue and the handled_sequence_of_statements (if any) of the corresponding accept_statement is executed; after the rendezvous completes any subsequent sequence_of_statements of the alternative is executed. <span id="I3599"></span>If no selection is immediately possible (in the above sense) and there is no else part, the task blocks until an open alternative can be selected. Selection of the other forms of alternative or of an else part is performed as follows: * An open delay_alternative is selected when its expiration time is reached if no accept_alternative or other delay_alternative can be selected prior to the expiration time. If several delay_alternatives have this same expiration time, one of them is selected according to the queuing policy in effect (see [[Guide:95lrm/RM-D-4|D.4]]); the default queuing policy chooses arbitrarily among the delay_alternatives whose expiration time has passed. * The else part is selected and its sequence_of_statements is executed if no accept_alternative can immediately be selected; in particular, if all alternatives are closed. * An open terminate_alternative is selected if the conditions stated at the end of clause [[Guide:95lrm/RM-9-3|9.3]] are satisfied. <span id="I3600"></span>The exception Program_Error is raised if all alternatives are closed and there is no else part. == Notes == 36  A selective_accept is allowed to have several open delay_alternatives. A selective_accept is allowed to have several open accept_alternatives for the same entry. == Examples == ''Example of a task body with a selective accept:'' <p><syntaxhighlight lang="Ada"> task body Server is Current_Work_Item : Work_Item; begin loop    select       accept Next_Work_Item(WI : in Work_Item) do          Current_Work_Item := WI;         end;        Process_Work_Item(Current_Work_Item);    or       accept Shut_Down;       exit;       -- Premature shut down requested     or       terminate;  -- Normal shutdown at end of scope    end select; end loop; end Server;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-7|Previous]] | [[Guide:95lrm/RM-9-7-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} rd0vgagaxv3vg5fzyl32ci56rkhnoal Guide:95lrm/RM-9-7-2 4200 1061 4333 2019-04-30T10:59:02Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-7-1|Previous]] | [[Guide:95lrm/RM-9-7-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 9.7.2 Timed Entry Calls}} A timed_entry_call issues an entry call that is cancelled if the call (or a requeue-with-abort of the call) is not selected before the expiration time is reached. <span id="I3601"></span> == Syntax == <p><span></span></p> timed_entry_call<span id="I3602"></span> ::= '''select''' <span id="I3603"></span>entry_call_alternative '''or''' <span id="I3604"></span>delay_alternative '''end select'''; <p><span></span></p> entry_call_alternative<span id="I3605"></span> ::= <span id="I3606"></span>entry_call_statement [<span id="I3607"></span>sequence_of_statements] == Dynamic Semantics == <span id="I3608"></span>For the execution of a timed_entry_call, the ''entry_''name and the actual parameters are evaluated, as for a simple entry call (see [[Guide:95lrm/RM-9-5-3|9.5.3]]). The expiration time (see [[Guide:95lrm/RM-9-6|9.6]]) for the call is determined by evaluating the ''delay_''expression of the delay_alternative; the entry call is then issued. If the call is queued (including due to a requeue-with-abort), and not selected before the expiration time is reached, an attempt to cancel the call is made. If the call completes due to the cancellation, the optional sequence_of_statements of the delay_alternative is executed; if the entry call completes normally, the optional sequence_of_statements of the entry_call_alternative is executed. == Examples == ''Example of a timed entry call:'' <p><syntaxhighlight lang="Ada"> select Controller.Request(Medium)(Some_Item); or delay 45.0; --  controller too busy, try something else end select;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-7-1|Previous]] | [[Guide:95lrm/RM-9-7-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} fv0gz01nii60wowxzkbn8qwq2frkddm Guide:95lrm/RM-9-7-3 4200 1062 4334 2019-04-30T11:00:57Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-7-2|Previous]] | [[Guide:95lrm/RM-9-7-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 9.7.3 Conditional Entry Calls}} A conditional_entry_call issues an entry call that is then cancelled if it is not selected immediately (or if a requeue-with-abort of the call is not selected immediately). == Syntax == <p><span></span></p> conditional_entry_call<span id="I3609"></span> ::= '''select''' <span id="I3610"></span>entry_call_alternative '''else''' <span id="I3611"></span>sequence_of_statements '''end select'''; == Dynamic Semantics == <span id="I3612"></span>The execution of a conditional_entry_call is defined to be equivalent to the execution of a timed_entry_call with a delay_alternative specifying an immediate expiration time and the same sequence_of_statements as given after the reserved word '''else'''. == Notes == 37  A conditional_entry_call may briefly increase the Count attribute of the entry, even if the conditional call is not selected. == Examples == ''Example of a conditional entry call:'' <p><syntaxhighlight lang="Ada"> procedure Spin(R : in Resource) is begin loop    select       R.Seize;       return;    else       null;  --  busy waiting     end select; end loop; end;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-7-2|Previous]] | [[Guide:95lrm/RM-9-7-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} e73t91jnccrpoiqsdex0cjkqr2g8chu Guide:95lrm/RM-9-7-4 4200 1063 4335 2019-04-30T11:05:15Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-7-3|Previous]] | [[Guide:95lrm/RM-9-8|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 9.7.4 Asynchronous Transfer of Control}} An asynchronous select_statement provides asynchronous transfer of control upon completion of an entry call or the expiration of a delay. == Syntax == <p><span></span></p> asynchronous_select<span id="I3613"></span> ::= '''select''' <span id="I3614"></span>triggering_alternative '''then abort''' <span id="I3615"></span>abortable_part '''end select'''; <p><span></span></p> triggering_alternative<span id="I3616"></span> ::= <span id="I3617"></span>triggering_statement [<span id="I3618"></span>sequence_of_statements] <p><span></span></p> triggering_statement<span id="I3619"></span> ::= <span id="I3620"></span>entry_call_statement | <span id="I3621"></span>delay_statement <p><span></span></p> abortable_part<span id="I3622"></span> ::= <span id="I3623"></span>sequence_of_statements == Dynamic Semantics == <span id="I3624"></span>For the execution of an asynchronous_select whose triggering_statement is an entry_call_statement, the ''entry_''name and actual parameters are evaluated as for a simple entry call (see [[Guide:95lrm/RM-9-5-3|9.5.3]]), and the entry call is issued. If the entry call is queued (or requeued-with-abort), then the abortable_part is executed. If the entry call is selected immediately, and never requeued-with-abort, then the abortable_part is never started. <span id="I3625"></span>For the execution of an asynchronous_select whose triggering_statement is a delay_statement, the ''delay_''expression is evaluated and the expiration time is determined, as for a normal delay_statement. If the expiration time has not already passed, the abortable_part is executed. If the abortable_part completes and is left prior to completion of the triggering_statement, an attempt to cancel the triggering_statement is made. If the attempt to cancel succeeds (see [[Guide:95lrm/RM-9-5-3|9.5.3]] and [[Guide:95lrm/RM-9-6|9.6]]), the asynchronous_select is complete. If the triggering_statement completes other than due to cancellation, the abortable_part is aborted (if started but not yet completed -- see [[Guide:95lrm/RM-9-8|9.8]]). If the triggering_statement completes normally, the optional sequence_of_statements of the triggering_alternative is executed after the abortable_part is left. == Examples == <span id="I3626"></span><span id="I3627"></span><span id="I3628"></span>''Example of a main command loop for a command interpreter:'' <p><syntaxhighlight lang="Ada"> loop  select      Terminal.Wait_For_Interrupt;      Put_Line("Interrupted");  then abort      -- This will be abandoned upon terminal interrupt      Put_Line("-> ");      Get_Line(Command, Last);      Process_Command(Command(1..Last)); end select; end loop;</syntaxhighlight></p> ''Example of a time-limited calculation:'' <span id="I3629"></span><span id="I3630"></span><span id="I3631"></span><span id="I3632"></span><span id="I3633"></span> <p><syntaxhighlight lang="Ada"> select delay 5.0; Put_Line("Calculation does not converge"); then abort -- This calculation should finish in 5.0 seconds; --  if not, it is assumed to diverge. Horribly_Complicated_Recursive_Function(X, Y); end select;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-7-3|Previous]] | [[Guide:95lrm/RM-9-8|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} t2otgumrffqvzq1v9vopiv0lgwyotnw Guide:95lrm/RM-9-8 4200 1064 4336 2019-04-30T11:05:49Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-7-4|Previous]] | [[Guide:95lrm/RM-9-9|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 9.8 Abort of a Task - Abort of a Sequence of Statements}} An abort_statement causes one or more tasks to become abnormal, thus preventing any further interaction with such tasks. The completion of the triggering_statement of an asynchronous_select causes a sequence_of_statements to be aborted. == Syntax == <p><span></span></p> abort_statement<span id="I3634"></span> ::= '''abort''' ''task_''<span id="I3635"></span>name {, ''task_''<span id="I3636"></span>name}; == Name Resolution Rules == <span id="I3637"></span>Each ''task_''name is expected to be of any task type; they need not all be of the same task type. == Dynamic Semantics == <span id="I3638"></span>For the execution of an abort_statement, the given ''task_''names are evaluated in an arbitrary order. <span id="I3639"></span><span id="I3640"></span><span id="I3641"></span>Each named task is then ''aborted'', which consists of making the task ''abnormal'' and aborting the execution of the corresponding task_body, unless it is already completed. <span id="I3642"></span><span id="I3643"></span>When the execution of a construct is ''aborted'' (including that of a task_body or of a sequence_of_statements), the execution of every construct included within the aborted execution is also aborted, except for executions included within the execution of an ''abort-deferred'' operation; the execution of an abort-deferred operation continues to completion without being affected by the abort; <span id="I3644"></span>the following are the abort-deferred operations: * a protected action; * waiting for an entry call to complete (after having initiated the attempt to cancel it -- see below); * waiting for the termination of dependent tasks; * the execution of an Initialize procedure as the last step of the default initialization of a controlled object; * the execution of a Finalize procedure as part of the finalization of a controlled object; * an assignment operation to an object with a controlled part. The last three of these are discussed further in [[Guide:95lrm/RM-7-6|7.6]]. When a master is aborted, all tasks that depend on that master are aborted. <span id="I3645"></span>The order in which tasks become abnormal as the result of an abort_statement or the abort of a sequence_of_statements is not specified by the language. If the execution of an entry call is aborted, an immediate attempt is made to cancel the entry call (see [[Guide:95lrm/RM-9-5-3|9.5.3]]). If the execution of a construct is aborted at a time when the execution is blocked, other than for an entry call, at a point that is outside the execution of an abort-deferred operation, then the execution of the construct completes immediately. For an abort due to an abort_statement, these immediate effects occur before the execution of the abort_statement completes. Other than for these immediate cases, the execution of a construct that is aborted does not necessarily complete before the abort_statement completes. However, the execution of the aborted construct completes no later than its next ''abort completion point'' (if any) that occurs outside of an abort-deferred operation; <span id="I3646"></span>the following are abort completion points for an execution: * the point where the execution initiates the activation of another task; * the end of the activation of a task; * the start or end of the execution of an entry call, accept_statement, delay_statement, or abort_statement; * the start of the execution of a select_statement, or of the sequence_of_statements of an exception_handler. == Bounded (Run-Time) Errors == <span id="I3647"></span>An attempt to execute an asynchronous_select as part of the execution of an abort-deferred operation is a bounded error. Similarly, an attempt to create a task that depends on a master that is included entirely within the execution of an abort-deferred operation is a bounded error. <span id="I3648"></span>In both cases, Program_Error is raised if the error is detected by the implementation; otherwise the operations proceed as they would outside an abort-deferred operation, except that an abort of the abortable_part or the created task might or might not have an effect. == Erroneous Execution == <span id="I3649"></span><span id="I3650"></span><span id="I3651"></span><span id="I3652"></span>If an assignment operation completes prematurely due to an abort, the assignment is said to be ''disrupted''; the target of the assignment or its parts can become abnormal, and certain subsequent uses of the object can be erroneous, as explained in [[Guide:95lrm/RM-13-9-1|13.9.1]]. == Notes == 38  An abort_statement should be used only in situations requiring unconditional termination. 39  A task is allowed to abort any task it can name, including itself. 40  Additional requirements associated with abort are given in [[Guide:95lrm/RM-D-6|D.6]], ''[[Guide:95lrm/RM-D-6|Preemptive Abort]]''. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-7-4|Previous]] | [[Guide:95lrm/RM-9-9|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 8hkktfg6cff757fdxs24naqjbgzafu9 Guide:95lrm/RM-9-9 4200 1065 4337 2019-04-29T15:48:18Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-8|Previous]] | [[Guide:95lrm/RM-9-10|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: 9.9 Task and Entry Attributes}} == Dynamic Semantics == For a prefix T that is of a task type (after any implicit dereference), the following attributes are defined: ; T'Callable : <span id="I3653"></span><span id="I3654"></span>Yields the value True when the task denoted by T is ''callable'', and False otherwise; <span id="I3655"></span><span id="I3656"></span>a task is callable unless it is completed or abnormal. The value of this attribute is of the predefined type Boolean. ; T'Terminated : <span id="I3657"></span><span id="I3658"></span>Yields the value True if the task denoted by T is terminated, and False otherwise. The value of this attribute is of the predefined type Boolean. For a prefix E that denotes an entry of a task or protected unit, the following attribute is defined. This attribute is only allowed within the body of the task or protected unit, but excluding, in the case of an entry of a task unit, within any program unit that is, itself, inner to the body of the task unit. ; E'Count : <span id="I3659"></span><span id="I3660"></span>Yields the number of calls presently queued on the entry E of the current instance of the unit. The value of this attribute is of the type ''universal_integer''. == Notes == 41  For the Count attribute, the entry can be either a single entry or an entry of a family. The name of the entry or entry family can be either a direct_name or an expanded name. 42  Within task units, algorithms interrogating the attribute E'Count should take precautions to allow for the increase of the value of this attribute for incoming entry calls, and its decrease, for example with timed_entry_calls. Also, a conditional_entry_call may briefly increase this value, even if the conditional call is not accepted. 43  Within protected units, algorithms interrogating the attribute E'Count in the entry_barrier for the entry E should take precautions to allow for the evaluation of the condition of the barrier both before and after queuing a given caller. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-9-8|Previous]] | [[Guide:95lrm/RM-9-10|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} fje33fuf0vcakt296qgshvymbgr44ki Guide:95lrm/RM-A 4200 1066 4338 2019-05-01T12:28:43Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-0-28|Previous]] | [[Guide:95lrm/RM-A-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Annex A. Predefined Language Environment}} ''(normative)'' <span id="I4543"></span><span id="I4544"></span>This Annex contains the specifications of library units that shall be provided by every implementation. There are three root library units: Ada, Interfaces, and System; other library units are children of these: <p><span></span></p> <div> Standard -- [[Guide:95lrm/RM-A-1|A.1]] ::Ada -- [[Guide:95lrm/RM-A-2|A.2]] ::::Asynchronous_Task_Control -- [[Guide:95lrm/RM-D-11|D.11]] ::::Calendar -- [[Guide:95lrm/RM-9-6|9.6]] ::::Characters -- [[Guide:95lrm/RM-A-3-1|A.3.1]] ::::::Handling -- [[Guide:95lrm/RM-A-3-2|A.3.2]] ::::::Latin_1 -- [[Guide:95lrm/RM-A-3-3|A.3.3]] ::::Command_Line -- [[Guide:95lrm/RM-A-15|A.15]] ::::Decimal -- [[Guide:95lrm/RM-F-2|F.2]] ::::Direct_IO -- [[Guide:95lrm/RM-A-8-4|A.8.4]] ::::Dynamic_Priorities -- [[Guide:95lrm/RM-D-5|D.5]] ::::Exceptions -- [[Guide:95lrm/RM-11-4-1|11.4.1]] ::::Finalization -- [[Guide:95lrm/RM-7-6|7.6]] ::::Float_Text_IO -- [[Guide:95lrm/RM-A-10-9|A.10.9]] ::::Float_Wide_Text_IO -- [[Guide:95lrm/RM-A-11|A.11]] ::::Integer_Text_IO -- [[Guide:95lrm/RM-A-10-8|A.10.8]] ::::Integer_Wide_Text_IO -- [[Guide:95lrm/RM-A-11|A.11]] ::::Interrupts -- [[Guide:95lrm/RM-C-3-2|C.3.2]] ::::::Names -- [[Guide:95lrm/RM-C-3-2|C.3.2]] ::::IO_Exceptions -- [[Guide:95lrm/RM-A-13|A.13]] ::::Numerics -- [[Guide:95lrm/RM-A-5|A.5]] ::::::Complex_Elementary_Functions -- [[Guide:95lrm/RM-G-1-2|G.1.2]] ::::::Complex_Types -- [[Guide:95lrm/RM-G-1-1|G.1.1]] ::::::Discrete_Random -- [[Guide:95lrm/RM-A-5-2|A.5.2]] ::::::Elementary_Functions -- [[Guide:95lrm/RM-A-5-1|A.5.1]] ::::::Float_Random -- [[Guide:95lrm/RM-A-5-2|A.5.2]] ::::::Generic_Complex_Elementary_Functions -- [[Guide:95lrm/RM-G-1-2|G.1.2]] ::::::Generic_Complex_Types -- [[Guide:95lrm/RM-G-1-1|G.1.1]] ::::::Generic_Elementary_Functions -- [[Guide:95lrm/RM-A-5-1|A.5.1]] ::::Real_Time -- [[Guide:95lrm/RM-D-8|D.8]] ::::Sequential_IO -- [[Guide:95lrm/RM-A-8-1|A.8.1]] ::::Storage_IO -- [[Guide:95lrm/RM-A-9|A.9]] ::::Streams -- [[Guide:95lrm/RM-13-13-1|13.13.1]] ::::::Stream_IO -- [[Guide:95lrm/RM-A-12-1|A.12.1]] ::::Strings -- [[Guide:95lrm/RM-A-4-1|A.4.1]] ::::::Bounded -- [[Guide:95lrm/RM-A-4-4|A.4.4]] ::::::Fixed -- [[Guide:95lrm/RM-A-4-3|A.4.3]] ::::::Maps -- [[Guide:95lrm/RM-A-4-2|A.4.2]] ::::::::Constants -- [[Guide:95lrm/RM-A-4-6|A.4.6]] ::::::Unbounded -- [[Guide:95lrm/RM-A-4-5|A.4.5]] ::::::Wide_Bounded -- [[Guide:95lrm/RM-A-4-7|A.4.7]] ::::::Wide_Fixed -- [[Guide:95lrm/RM-A-4-7|A.4.7]] ::::::Wide_Maps -- [[Guide:95lrm/RM-A-4-7|A.4.7]] ::::::::Wide_Constants -- [[Guide:95lrm/RM-A-4-7|A.4.7]] ::::::Wide_Unbounded -- [[Guide:95lrm/RM-A-4-7|A.4.7]] ::::Synchronous_Task_Control -- [[Guide:95lrm/RM-D-10|D.10]] ::::Tags -- [[Guide:95lrm/RM-3-9|3.9]] ::::Task_Attributes -- [[Guide:95lrm/RM-C-7-2|C.7.2]] ::::Task_Identification -- [[Guide:95lrm/RM-C-7-1|C.7.1]] ::::Text_IO -- [[Guide:95lrm/RM-A-10-1|A.10.1]] ::::::Complex_IO -- [[Guide:95lrm/RM-G-1-3|G.1.3]] ::::::Editing -- [[Guide:95lrm/RM-F-3-3|F.3.3]] ::::::Text_Streams -- [[Guide:95lrm/RM-A-12-2|A.12.2]] ::::Unchecked_Conversion -- [[Guide:95lrm/RM-13-9|13.9]] ::::Unchecked_Deallocation -- [[Guide:95lrm/RM-13-11-2|13.11.2]] ::::Wide_Text_IO -- [[Guide:95lrm/RM-A-11|A.11]] ::::::Complex_IO -- [[Guide:95lrm/RM-G-1-3|G.1.3]] ::::::Editing -- [[Guide:95lrm/RM-F-3-4|F.3.4]] ::::::Text_Streams -- [[Guide:95lrm/RM-A-12-3|A.12.3]] ::Interfaces -- [[Guide:95lrm/RM-B-2|B.2]] ::::C -- [[Guide:95lrm/RM-B-3|B.3]] ::::::Pointers -- [[Guide:95lrm/RM-B-3-2|B.3.2]] ::::::Strings -- [[Guide:95lrm/RM-B-3-1|B.3.1]] ::::COBOL -- [[Guide:95lrm/RM-B-4|B.4]] ::::Fortran -- [[Guide:95lrm/RM-B-5|B.5]] ::System -- [[Guide:95lrm/RM-13-7|13.7]] ::::Address_To_Access_Conversions -- [[Guide:95lrm/RM-13-7-2|13.7.2]] ::::Machine_Code -- [[Guide:95lrm/RM-13-8|13.8]] ::::RPC -- [[Guide:95lrm/RM-E-5|E.5]] ::::Storage_Elements -- [[Guide:95lrm/RM-13-7-1|13.7.1]] ::::Storage_Pools -- [[Guide:95lrm/RM-13-11|13.11]] </div> == Implementation Requirements == The implementation shall ensure that each language defined subprogram is reentrant in the sense that concurrent calls on the same subprogram perform as specified, so long as all parameters that could be passed by reference denote nonoverlapping objects. == Implementation Permissions == The implementation may restrict the replacement of language-defined compilation units. The implementation may restrict children of language-defined library units (other than Standard). </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-0-28|Previous]] | [[Guide:95lrm/RM-A-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} f7wfdtxo67n13vlwryjajljgmmucez6 Guide:95lrm/RM-A-1 4200 1067 4339 2019-05-01T12:40:18Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A|Previous]] | [[Guide:95lrm/RM-A-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.1 The Package Standard}} This clause outlines the specification of the package Standard containing all predefined identifiers in the language. <span id="I4545"></span>The corresponding package body is not specified by the language. The operators that are predefined for the types declared in the package Standard are given in comments since they are implicitly declared. <span id="I4546"></span>Italics are used for pseudo-names of anonymous types (such as ''root_real'') and for undefined information (such as ''implementation-defined''). == Static Semantics == The library package Standard has the following declaration: <p><syntaxhighlight lang="Ada"> package Standard is pragma Pure(Standard);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Boolean is (False, True);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- The predefined relational operators for this type are as follows:</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- function "="   (Left, Right : Boolean'Base) return Boolean; -- function "/="  (Left, Right : Boolean'Base) return Boolean; -- function "<"   (Left, Right : Boolean'Base) return Boolean; -- function "<="  (Left, Right : Boolean'Base) return Boolean; -- function ">"   (Left, Right : Boolean'Base) return Boolean; -- function ">="  (Left, Right : Boolean'Base) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- The predefined logical operators and the predefined logical -- negation operator are as follows:</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- function "and" (Left, Right : Boolean'Base) return Boolean; -- function "or"  (Left, Right : Boolean'Base) return Boolean; -- function "xor" (Left, Right : Boolean'Base) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   -- function "not" (Right : Boolean'Base) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- The integer type root_integer is predefined. -- The corresponding universal type is universal_integer.</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   type Integer is range implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    subtype Natural  is Integer range 0 .. Integer'Last; subtype Positive is Integer range 1 .. Integer'Last;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- The predefined operators for type Integer are as follows:</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- function "="  (Left, Right : Integer'Base) return Boolean; -- function "/=" (Left, Right : Integer'Base) return Boolean; -- function "<"  (Left, Right : Integer'Base) return Boolean; -- function "<=" (Left, Right : Integer'Base) return Boolean; -- function ">"  (Left, Right : Integer'Base) return Boolean; -- function ">=" (Left, Right : Integer'Base) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- function "+"   (Right : Integer'Base) return Integer'Base; -- function "-"   (Right : Integer'Base) return Integer'Base; -- function "abs" (Right : Integer'Base) return Integer'Base;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- function "+"   (Left, Right : Integer'Base) return Integer'Base; -- function "-"   (Left, Right : Integer'Base) return Integer'Base; -- function "*"   (Left, Right : Integer'Base) return Integer'Base; -- function "/"   (Left, Right : Integer'Base) return Integer'Base; -- function "rem" (Left, Right : Integer'Base) return Integer'Base; -- function "mod" (Left, Right : Integer'Base) return Integer'Base;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   -- function "**"  (Left : Integer'Base; Right : Natural) --                  return Integer'Base;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- The specification of each operator for the type -- root_integer, or for any additional predefined integer -- type, is obtained by replacing Integer by the name of the type -- in the specification of the corresponding operator of the type -- Integer. The right operand of the exponentiation operator -- remains as subtype Natural.</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- The floating point type root_real is predefined. -- The corresponding universal type is universal_real.</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Float is digits implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- The predefined operators for this type are as follows:</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- function "="   (Left, Right : Float) return Boolean; -- function "/="  (Left, Right : Float) return Boolean; -- function "<"   (Left, Right : Float) return Boolean; -- function "<="  (Left, Right : Float) return Boolean; -- function ">"   (Left, Right : Float) return Boolean; -- function ">="  (Left, Right : Float) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- function "+"   (Right : Float) return Float; -- function "-"   (Right : Float) return Float; -- function "abs" (Right : Float) return Float;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- function "+"   (Left, Right : Float) return Float; -- function "-"   (Left, Right : Float) return Float; -- function "*"   (Left, Right : Float) return Float; -- function "/"   (Left, Right : Float) return Float;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- function "**"  (Left : Float; Right : Integer'Base) return Float;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- The specification of each operator for the type root_real, or for -- any additional predefined floating point type, is obtained by -- replacing Float by the name of the type in the specification of the -- corresponding operator of the type Float.</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- In addition, the following operators are predefined for the root -- numeric types:</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "*" (Left : root_integer; Right : root_real)   return root_real;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "*" (Left : root_real;    Right : root_integer)   return root_real;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "/" (Left : root_real;    Right : root_integer)   return root_real;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- The type universal_fixed is predefined. -- The only multiplying operators defined between -- fixed point types are</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "*" (Left : universal_fixed; Right : universal_fixed)   return universal_fixed;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "/" (Left : universal_fixed; Right : universal_fixed)   return universal_fixed;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       -- The declaration of type Character is based on the standard ISO 8859-1 character set.    -- There are no character literals corresponding to the positions for control characters.    -- They are indicated in italics in this definition. See 3.5.2. type Character is   (nul,     soh,   stx,    etx,      eot,   enq,    ack,   bel,   --0 (16#00#) .. 7 (16#07#)    bs,      ht,    lf,     vt,       ff,    cr,     so,    si,    --8 (16#08#) .. 15 (16#0F#)    dle,     dc1,   dc2,    dc3,      dc4,   nak,    syn,   etb,   --16 (16#10#) .. 23 (16#17#)    can,     em,    sub,    esc,      fs,    gs,     rs,    us,    --24 (16#18#) .. 31 (16#1F#)    ' ',     '!',   '"',    '#',      '$',   '%',    '&',   ''',   --32 (16#20#) .. 39 (16#27#)    '(',     ')',   '*',    '+',      ',',   '-',    '.',   '/',   --40 (16#28#) .. 47 (16#2F#)    '0',     '1',   '2',    '3',      '4',   '5',    '6',   '7',   --48 (16#30#) .. 55 (16#37#)    '8',     '9',   ':',    ';',      '<',   '=',    '>',   '?',   --56 (16#38#) .. 63 (16#3F#)    '@',     'A',   'B',    'C',      'D',   'E',    'F',   'G',   --64 (16#40#) .. 71 (16#47#)    'H',     'I',   'J',    'K',      'L',   'M',    'N',   'O',   --72 (16#48#) .. 79 (16#4F#)    'P',     'Q',   'R',    'S',      'T',   'U',    'V',   'W',   --80 (16#50#) .. 87 (16#57#)    'X',     'Y',   'Z',    '[',      '\',   ']',    '^',   '_',   --88 (16#58#) .. 95 (16#5F#)    '`',     'a',   'b',    'c',      'd',   'e',    'f',   'g',   --96 (16#60#) .. 103 (16#67#)    'h',     'i',   'j',    'k',      'l',   'm',    'n',   'o',   --104 (16#68#) .. 111 (16#6F#)    'p',     'q',   'r',    's',      't',   'u',    'v',   'w',   --112 (16#70#) .. 119 (16#77#)    'x',     'y',   'z',    '{',      '|',   '}',    '~',   del,   --120 (16#78#) .. 127 (16#7F#)    reserved_128,   reserved_129,     bph,   nbh,                  --128 (16#80#) .. 131 (16#83#)    reserved_132,   nel,    ssa,      esa,                         --132 (16#84#) .. 135 (16#87#)    hts,     htj,   vts,    pld,      plu,   ri,     ss2,   ss3,   --136 (16#88#) .. 143 (16#8F#)    dcs,     pu1,   pu2,    sts,      cch,   mw,     spa,   epa,   --144 (16#90#) .. 151 (16#97#)    sos,     reserved_153,  sci,      csi,                         --152 (16#98#) .. 155 (16#9B#)    st,      osc,   pm,     apc,                                   --156 (16#9C#) .. 159 (16#9F#)    ' ',     '¡',   '¢',    '£',      '¤',   '¥',    '¦',   '§',   --160 (16#A0#) .. 167 (16#A7#)    '¨',     '©',   'ª',    '«',      '¬',   '­',    '®',   '¯',   --168 (16#A8#) .. 175 (16#AF#)    '°',     '±',   '²',    '³',      '´',   'µ',    '¶',   '·',   --176 (16#B0#) .. 183 (16#B7#)    '¸',     '¹',   'º',    '»',      '¼',   '½',    '¾',   '¿',   --184 (16#B8#) .. 191 (16#BF#)    'À',     'Á',   'Â',    'Ã',      'Ä',   'Å',    'Æ',   'Ç',   --192 (16#C0#) .. 199 (16#C7#)    'È',     'É',   'Ê',    'Ë',      'Ì',   'Í',    'Î',   'Ï',   --200 (16#C8#) .. 207 (16#CF#)    'Ð',     'Ñ',   'Ò',    'Ó',      'Ô',   'Õ',    'Ö',   '×',   --208 (16#D0#) .. 215 (16#D7#)    'Ø',     'Ù',   'Ú',    'Û',      'Ü',   'Ý',    'Þ',   'ß',   --216 (16#D8#) .. 223 (16#DF#)    'à',     'á',   'â',    'ã',      'ä',   'å',    'æ',   'ç',   --224 (16#E0#) .. 231 (16#E7#)    'è',     'é',   'ê',    'ë',      'ì',   'í',    'î',   'ï',   --232 (16#E8#) .. 239 (16#EF#)    'ð',     'ñ',   'ò',    'ó',      'ô',   'õ',    'ö',   '÷',   --240 (16#F0#) .. 247 (16#F7#)    'ø',     'ù',   'ú',    'û',      'ü',   'ý',    'þ',   'ÿ',   --248 (16#F8#) .. 255 (16#FF#)</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- The predefined operators for the type Character are the same as for -- any enumeration type. -- The declaration of type Wide_Character is based on the standard ISO 10646 BMP character set. -- The first 256 positions have the same contents as type Character. See 3.5.2. type Wide_Character is (nul, soh ... FFFE, FFFF); package ASCII is ... end ASCII;  --Obsolescent; see J.5</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Predefined string types: type String is array(Positive range <>) of Character; pragma Pack(String);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     -- The predefined operators for this type are as follows:</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    --     function "="  (Left, Right: String) return Boolean; --     function "/=" (Left, Right: String) return Boolean; --     function "<"  (Left, Right: String) return Boolean; --     function "<=" (Left, Right: String) return Boolean; --     function ">"  (Left, Right: String) return Boolean; --     function ">=" (Left, Right: String) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    --     function "&" (Left: String;    Right: String)    return String; --     function "&" (Left: Character; Right: String)    return String; --     function "&" (Left: String;    Right: Character) return String; --     function "&" (Left: Character; Right: Character) return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Wide_String is array(Positive range <>) of Wide_Character; pragma Pack(Wide_String);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- The predefined operators for this type correspond to those for String</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Duration is delta implementation-defined range implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       -- The predefined operators for the type Duration are the same as for    -- any fixed point type.</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- The predefined exceptions:</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Constraint_Error: exception; Program_Error   : exception; Storage_Error   : exception; Tasking_Error   : exception;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> end Standard;</syntaxhighlight></p> Standard has no private part. In each of the types Character and Wide_Character, the character literals for the space character (position 32) and the non-breaking space character (position 160) correspond to different values. Unless indicated otherwise, each occurrence of the character literal ' ' in this International Standard refers to the space character. Similarly, the character literals for hyphen (position 45) and soft hyphen (position 173) correspond to different values. Unless indicated otherwise, each occurrence of the character literal '-' in this International Standard refers to the hyphen character. == Dynamic Semantics == <span id="I4572"></span>Elaboration of the body of Standard has no effect. == Implementation Permissions == An implementation may provide additional predefined integer types and additional predefined floating point types. Not all of these types need have names. == Implementation Advice == If an implementation provides additional named predefined integer types, then the names should end with ''Integer'' as in ''Long_Integer''. If an implementation provides additional named predefined floating point types, then the names should end with ''Float'' as in ''Long_Float''. == Notes == 1  Certain aspects of the predefined entities cannot be completely described in the language itself. For example, although the enumeration type Boolean can be written showing the two enumeration literals False and True, the short-circuit control forms cannot be expressed in the language. 2  As explained in [[Guide:95lrm/RM-8-1|8.1]], ''[[Guide:95lrm/RM-8-1|Declarative Region]]'' and [[Guide:95lrm/RM-10-1-4|10.1.4]], ''[[Guide:95lrm/RM-10-1-4|The Compilation Process]]'', the declarative region of the package Standard encloses every library unit and consequently the main subprogram; the declaration of every library unit is assumed to occur within this declarative region. Library_items are assumed to be ordered in such a way that there are no forward semantic dependences. However, as explained in [[Guide:95lrm/RM-8-3|8.3]], ''[[Guide:95lrm/RM-8-3|Visibility]]'', the only library units that are visible within a given compilation unit are the library units named by all with_clauses that apply to the given unit, and moreover, within the declarative region of a given library unit, that library unit itself. 3  If all block_statements of a program are named, then the name of each program unit can always be written as an expanded name starting with Standard (unless Standard is itself hidden). The name of a library unit cannot be a homograph of a name (such as Integer) that is already declared in Standard. 4  The exception Standard.Numeric_Error is defined in [[Guide:95lrm/RM-J-6|J.6]]. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A|Previous]] | [[Guide:95lrm/RM-A-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} sgctn1if9qwiaemz71llz2hyyk8kac5 Guide:95lrm/RM-A-10 4200 1068 4340 2019-05-01T16:49:05Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-9|Previous]] | [[Guide:95lrm/RM-A-10-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.10 Text Input-Output}} == Static Semantics == This clause describes the package Text_IO, which provides facilities for input and output in human-readable form. Each file is read or written sequentially, as a sequence of characters grouped into lines, and as a sequence of lines grouped into pages. The specification of the package is given below in subclause [[Guide:95lrm/RM-A-10-1|A.10.1]]. The facilities for file management given above, in subclauses [[Guide:95lrm/RM-A-8-2|A.8.2]] and [[Guide:95lrm/RM-A-8-3|A.8.3]], are available for text input-output. In place of Read and Write, however, there are procedures Get and Put that input values of suitable types from text files, and output values to them. These values are provided to the Put procedures, and returned by the Get procedures, in a parameter Item. Several overloaded procedures of these names exist, for different types of Item. These Get procedures analyze the input sequences of characters based on lexical elements (see Section 2) and return the corresponding values; the Put procedures output the given values as appropriate lexical elements. Procedures Get and Put are also available that input and output individual characters treated as character values rather than as lexical elements. Related to character input are procedures to look ahead at the next character without reading it, and to read a character ''immediately'' without waiting for an end-of-line to signal availability. In addition to the procedures Get and Put for numeric and enumeration types of Item that operate on text files, analogous procedures are provided that read from and write to a parameter of type String. These procedures perform the same analysis and composition of character sequences as their counterparts which have a file parameter. For all Get and Put procedures that operate on text files, and for many other subprograms, there are forms with and without a file parameter. Each such Get procedure operates on an input file, and each such Put procedure operates on an output file. If no file is specified, a default input file or a default output file is used. <span id="I5606"></span><span id="I5607"></span>At the beginning of program execution the default input and output files are the so-called standard input file and standard output file. These files are open, have respectively the current modes In_File and Out_File, and are associated with two implementation-defined external files. Procedures are provided to change the current default input file and the current default output file. <span id="I5608"></span>At the beginning of program execution a default file for program-dependent error-related text output is the so-called standard error file. This file is open, has the current mode Out_File, and is associated with an implementation-defined external file. A procedure is provided to change the current default error file. <span id="I5609"></span><span id="I5610"></span><span id="I5611"></span>From a logical point of view, a text file is a sequence of pages, a page is a sequence of lines, and a line is a sequence of characters; the end of a line is marked by a ''line terminator''; the end of a page is marked by the combination of a line terminator immediately followed by a ''page terminator''; and the end of a file is marked by the combination of a line terminator immediately followed by a page terminator and then a ''file terminator''. Terminators are generated during output; either by calls of procedures provided expressly for that purpose; or implicitly as part of other operations, for example, when a bounded line length, a bounded page length, or both, have been specified for a file. The actual nature of terminators is not defined by the language and hence depends on the implementation. Although terminators are recognized or generated by certain of the procedures that follow, they are not necessarily implemented as characters or as sequences of characters. Whether they are characters (and if so which ones) in any particular implementation need not concern a user who neither explicitly outputs nor explicitly inputs control characters. The effect of input (Get) or output (Put) of control characters (other than horizontal tabulation) is not specified by the language. <span id="I5612"></span> <span id="I5613"></span><span id="I5614"></span><span id="I5615"></span><span id="I5616"></span>The characters of a line are numbered, starting from one; the number of a character is called its ''column number''. For a line terminator, a column number is also defined: it is one more than the number of characters in the line. The lines of a page, and the pages of a file, are similarly numbered. The current column number is the column number of the next character or line terminator to be transferred. The current line number is the number of the current line. The current page number is the number of the current page. These numbers are values of the subtype Positive_Count of the type Count (by convention, the value zero of the type Count is used to indicate special conditions). <p><syntaxhighlight lang="Ada"> type Count is range 0 .. implementation-defined; subtype Positive_Count is Count range 1 .. Count'Last;</syntaxhighlight></p> <span id="I5617"></span><span id="I5618"></span>For an output file or an append file, a ''maximum line length'' can be specified and a ''maximum page length'' can be specified. If a value to be output cannot fit on the current line, for a specified maximum line length, then a new line is automatically started before the value is output; if, further, this new line cannot fit on the current page, for a specified maximum page length, then a new page is automatically started before the value is output. Functions are provided to determine the maximum line length and the maximum page length. When a file is opened with mode Out_File or Append_File, both values are zero: by convention, this means that the line lengths and page lengths are unbounded. (Consequently, output consists of a single line if the subprograms for explicit control of line and page structure are not used.) The constant Unbounded is provided for this purpose. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-9|Previous]] | [[Guide:95lrm/RM-A-10-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 1tx0ed82mmqqd47wnrefeji5e3iic8w Guide:95lrm/RM-A-10-1 4200 1069 4341 2019-05-01T17:09:47Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-10|Previous]] | [[Guide:95lrm/RM-A-10-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.10.1 The Package Text_IO}} == Static Semantics == The library package Text_IO has the following declaration: <p><syntaxhighlight lang="Ada"> with Ada.IO_Exceptions; package Ada.Text_IO is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type File_Type is limited private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type File_Mode is (In_File, Out_File, Append_File);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Count is range 0 .. implementation-defined; subtype Positive_Count is Count range 1 .. Count'Last; Unbounded : constant Count := 0; -- line and page length</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    subtype Field       is Integer range 0 .. implementation-defined; subtype Number_Base is Integer range 2 .. 16;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Type_Set is (Lower_Case, Upper_Case);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- File Management</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Create (File : in out File_Type;                   Mode : in File_Mode := Out_File;                   Name : in String    := "";                   Form : in String    := "");</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Open   (File : in out File_Type;                   Mode : in File_Mode;                   Name : in String;                   Form : in String := "");</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Close  (File : in out File_Type); procedure Delete (File : in out File_Type); procedure Reset  (File : in out File_Type; Mode : in File_Mode); procedure Reset  (File : in out File_Type);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function  Mode   (File : in File_Type) return File_Mode; function  Name   (File : in File_Type) return String; function  Form   (File : in File_Type) return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function  Is_Open(File : in File_Type) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Control of default input and output files</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Set_Input (File : in File_Type); procedure Set_Output(File : in File_Type); procedure Set_Error (File : in File_Type);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Standard_Input  return File_Type; function Standard_Output return File_Type; function Standard_Error  return File_Type;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Current_Input   return File_Type; function Current_Output  return File_Type; function Current_Error   return File_Type;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type File_Access is access constant File_Type;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Standard_Input  return File_Access; function Standard_Output return File_Access; function Standard_Error  return File_Access;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Current_Input   return File_Access; function Current_Output  return File_Access; function Current_Error   return File_Access;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> --Buffer control procedure Flush (File : in File_Type); procedure Flush;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Specification of line and page lengths</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Set_Line_Length(File : in File_Type; To : in Count); procedure Set_Line_Length(To   : in Count);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Set_Page_Length(File : in File_Type; To : in Count); procedure Set_Page_Length(To   : in Count);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function  Line_Length(File : in File_Type) return Count; function  Line_Length return Count;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function  Page_Length(File : in File_Type) return Count; function  Page_Length return Count;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Column, Line, and Page Control</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure New_Line   (File    : in File_Type;                       Spacing : in Positive_Count := 1); procedure New_Line   (Spacing : in Positive_Count := 1);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Skip_Line  (File    : in File_Type;                       Spacing : in Positive_Count := 1); procedure Skip_Line  (Spacing : in Positive_Count := 1);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function  End_Of_Line(File : in File_Type) return Boolean; function  End_Of_Line return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure New_Page   (File : in File_Type); procedure New_Page;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Skip_Page  (File : in File_Type); procedure Skip_Page;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function  End_Of_Page(File : in File_Type) return Boolean; function  End_Of_Page return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function  End_Of_File(File : in File_Type) return Boolean; function  End_Of_File return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Set_Col (File : in File_Type; To : in Positive_Count); procedure Set_Col (To   : in Positive_Count);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Set_Line(File : in File_Type; To : in Positive_Count); procedure Set_Line(To   : in Positive_Count);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Col (File : in File_Type) return Positive_Count; function Col  return Positive_Count;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function Line(File : in File_Type) return Positive_Count; function Line return Positive_Count;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Page(File : in File_Type) return Positive_Count; function Page return Positive_Count;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Character Input-Output</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Get(File : in  File_Type; Item : out Character); procedure Get(Item : out Character);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Put(File : in  File_Type; Item : in Character); procedure Put(Item : in  Character);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Look_Ahead (File        : in  File_Type;                       Item        : out Character;                       End_Of_Line : out Boolean); procedure Look_Ahead (Item        : out Character;                       End_Of_Line : out Boolean);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Get_Immediate(File      : in  File_Type;                         Item      : out Character); procedure Get_Immediate(Item      : out Character);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Get_Immediate(File      : in  File_Type;                         Item      : out Character;                         Available : out Boolean); procedure Get_Immediate(Item      : out Character;                         Available : out Boolean);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- String Input-Output</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Get(File : in  File_Type; Item : out String); procedure Get(Item : out String);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Put(File : in  File_Type; Item : in String); procedure Put(Item : in  String);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Get_Line(File : in  File_Type;                    Item : out String;                    Last : out Natural); procedure Get_Line(Item : out String; Last : out Natural);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Put_Line(File : in  File_Type; Item : in String); procedure Put_Line(Item : in  String);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- Generic packages for Input-Output of Integer Types</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    generic    type Num is range <>; package Integer_IO is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       Default_Width : Field := Num'Width;    Default_Base  : Number_Base := 10;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Get(File  : in  File_Type;                  Item  : out Num;                  Width : in Field := 0);    procedure Get(Item  : out Num;                  Width : in  Field := 0);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Put(File  : in File_Type;                  Item  : in Num;                  Width : in Field := Default_Width;                  Base  : in Number_Base := Default_Base);    procedure Put(Item  : in Num;                  Width : in Field := Default_Width;                  Base  : in Number_Base := Default_Base);    procedure Get(From  : in  String;                  Item  : out Num;                 Last  : out Positive);    procedure Put(To    : out String;                  Item  : in Num;                 Base  : in Number_Base := Default_Base);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    end Integer_IO;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    generic    type Num is mod <>; package Modular_IO is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       Default_Width : Field := Num'Width;    Default_Base  : Number_Base := 10;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Get(File  : in  File_Type;                  Item  : out Num;                  Width : in Field := 0);    procedure Get(Item  : out Num;                  Width : in  Field := 0);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Put(File  : in File_Type;                  Item  : in Num;                  Width : in Field := Default_Width;                  Base  : in Number_Base := Default_Base);    procedure Put(Item  : in Num;                  Width : in Field := Default_Width;                  Base  : in Number_Base := Default_Base);    procedure Get(From : in  String;                  Item : out Num;                  Last : out Positive);    procedure Put(To   : out String;                  Item : in Num;                  Base : in Number_Base := Default_Base);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    end Modular_IO;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Generic packages for Input-Output of Real Types</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    generic    type Num is digits <>; package Float_IO is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       Default_Fore : Field := 2;    Default_Aft  : Field := Num'Digits-1;    Default_Exp  : Field := 3;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Get(File  : in  File_Type;                  Item  : out Num;                  Width : in  Field := 0);    procedure Get(Item  : out Num;                  Width : in  Field := 0);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Put(File : in File_Type;                  Item : in Num;                  Fore : in Field := Default_Fore;                  Aft  : in Field := Default_Aft;                  Exp  : in Field := Default_Exp);    procedure Put(Item : in Num;                  Fore : in Field := Default_Fore;                  Aft  : in Field := Default_Aft;                  Exp  : in Field := Default_Exp);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">      procedure Get(From : in String;                  Item : out Num;                  Last : out Positive);    procedure Put(To   : out String;                  Item : in Num;                  Aft  : in Field := Default_Aft;                  Exp  : in Field := Default_Exp); end Float_IO;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    generic    type Num is delta <>; package Fixed_IO is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       Default_Fore : Field := Num'Fore;    Default_Aft  : Field := Num'Aft;    Default_Exp  : Field := 0;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Get(File  : in  File_Type;                  Item  : out Num;                  Width : in  Field := 0);    procedure Get(Item  : out Num;                  Width : in  Field := 0);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Put(File : in File_Type;                  Item : in Num;                  Fore : in Field := Default_Fore;                  Aft  : in Field := Default_Aft;                  Exp  : in Field := Default_Exp);    procedure Put(Item : in Num;                  Fore : in Field := Default_Fore;                  Aft  : in Field := Default_Aft;                  Exp  : in Field := Default_Exp);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Get(From : in  String;                  Item : out Num;                  Last : out Positive);    procedure Put(To   : out String;                  Item : in Num;                  Aft  : in Field := Default_Aft;                  Exp  : in Field := Default_Exp); end Fixed_IO;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    generic    type Num is delta <> digits <>; package Decimal_IO is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       Default_Fore : Field := Num'Fore;    Default_Aft  : Field := Num'Aft;    Default_Exp  : Field := 0;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Get(File  : in  File_Type;                  Item  : out Num;                  Width : in  Field := 0);    procedure Get(Item  : out Num;                  Width : in  Field := 0);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Put(File : in File_Type;                  Item : in Num;                  Fore : in Field := Default_Fore;                  Aft  : in Field := Default_Aft;                  Exp  : in Field := Default_Exp);    procedure Put(Item : in Num;                  Fore : in Field := Default_Fore;                  Aft  : in Field := Default_Aft;                 Exp  : in Field := Default_Exp);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Get(From : in  String;                  Item : out Num;                  Last : out Positive);    procedure Put(To   : out String;                  Item : in Num;                  Aft  : in Field := Default_Aft;                  Exp  : in Field := Default_Exp); end Decimal_IO;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Generic package for Input-Output of Enumeration Types</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    generic    type Enum is (<>); package Enumeration_IO is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       Default_Width   : Field := 0;    Default_Setting : Type_Set := Upper_Case;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Get(File : in  File_Type;                  Item : out Enum);    procedure Get(Item : out Enum);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Put(File  : in File_Type;                  Item  : in Enum;                  Width : in Field    := Default_Width;                  Set   : in Type_Set := Default_Setting);    procedure Put(Item  : in Enum;                  Width : in Field    := Default_Width;                  Set   : in Type_Set := Default_Setting);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Get(From : in  String;                  Item : out Enum;                  Last : out Positive);    procedure Put(To   : out String;                  Item : in  Enum;                  Set  : in  Type_Set := Default_Setting); end Enumeration_IO;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- Exceptions</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Status_Error : exception renames IO_Exceptions.Status_Error; Mode_Error   : exception renames IO_Exceptions.Mode_Error; Name_Error   : exception renames IO_Exceptions.Name_Error; Use_Error    : exception renames IO_Exceptions.Use_Error; Device_Error : exception renames IO_Exceptions.Device_Error; End_Error    : exception renames IO_Exceptions.End_Error; Data_Error   : exception renames IO_Exceptions.Data_Error; Layout_Error : exception renames IO_Exceptions.Layout_Error; private ... -- not specified by the language end Ada.Text_IO;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-10|Previous]] | [[Guide:95lrm/RM-A-10-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} rkgo1u5dirubbu7mwvpa6eguosm4xpd Guide:95lrm/RM-A-10-10 4200 1070 4342 2019-05-01T17:41:56Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-10-9|Previous]] | [[Guide:95lrm/RM-A-11|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.10.10 Input-Output for Enumeration Types}} == Static Semantics == The following procedures are defined in the generic package Enumeration_IO, which has to be instantiated for the appropriate enumeration type (indicated by Enum in the specification). Values are output using either upper or lower case letters for identifiers. This is specified by the parameter Set, which is of the enumeration type Type_Set. <p><syntaxhighlight lang="Ada"> type Type_Set is (Lower_Case, Upper_Case);</syntaxhighlight></p> The format (which includes any trailing spaces) can be specified by an optional field width parameter. The default field width and letter case are defined by the following variables that are declared in the generic package Enumeration_IO: <p><syntaxhighlight lang="Ada"> Default_Width   : Field := 0; Default_Setting : Type_Set := Upper_Case;</syntaxhighlight></p> The following procedures are provided: <p><syntaxhighlight lang="Ada"> procedure Get(File : in File_Type; Item : out Enum); procedure Get(Item : out Enum);</syntaxhighlight></p> <p><span></span></p> :After skipping any leading blanks, line terminators, or page terminators, reads an identifier according to the syntax of this lexical element (lower and upper case being considered equivalent), or a character literal according to the syntax of this lexical element (including the apostrophes). Returns, in the parameter Item, the value of type Enum that corresponds to the sequence input. <p><span></span></p> :The exception Data_Error is propagated if the sequence input does not have the required syntax, or if the identifier or character literal does not correspond to a value of the subtype Enum. <p><syntaxhighlight lang="Ada"> procedure Put(File  : in File_Type;            Item  : in Enum;            Width : in Field := Default_Width;            Set   : in Type_Set := Default_Setting); procedure Put(Item  : in Enum;            Width : in Field := Default_Width;            Set   : in Type_Set := Default_Setting);</syntaxhighlight></p> <p><span></span></p> :Outputs the value of the parameter Item as an enumeration literal (either an identifier or a character literal). The optional parameter Set indicates whether lower case or upper case is used for identifiers; it has no effect for character literals. If the sequence of characters produced has fewer than Width characters, then trailing spaces are finally output to make up the difference. If Enum is a character type, the sequence of characters produced is as for Enum'Image(Item), as modified by the Width and Set parameters. <p><syntaxhighlight lang="Ada"> procedure Get(From : in String; Item : out Enum; Last : out Positive);</syntaxhighlight></p> <p><span></span></p> :Reads an enumeration value from the beginning of the given string, following the same rule as the Get procedure that reads an enumeration value from a file, but treating the end of the string as a file terminator. Returns, in the parameter Item, the value of type Enum that corresponds to the sequence input. Returns in Last the index value such that From(Last) is the last character read. <p><span></span></p> :The exception Data_Error is propagated if the sequence input does not have the required syntax, or if the identifier or character literal does not correspond to a value of the subtype Enum. <p><syntaxhighlight lang="Ada"> procedure Put(To   : out String;            Item : in Enum;            Set  : in Type_Set := Default_Setting);</syntaxhighlight></p> <p><span></span></p> :Outputs the value of the parameter Item to the given string, following the same rule as for output to a file, using the length of the given string as the value for Width. Although the specification of the generic package Enumeration_IO would allow instantiation for an integer type, this is not the intended purpose of this generic package, and the effect of such instantiations is not defined by the language. == Notes == 32  There is a difference between Put defined for characters, and for enumeration values. Thus <p><syntaxhighlight lang="Ada">    Ada.Text_IO.Put('A');  --  outputs the character A</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    package Char_IO is new Ada.Text_IO.Enumeration_IO(Character); Char_IO.Put('A');  --  outputs the character 'A', between apostrophes</syntaxhighlight></p> 33  The type Boolean is an enumeration type, hence Enumeration_IO can be instantiated for this type. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-10-9|Previous]] | [[Guide:95lrm/RM-A-11|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} g03xh0vls4w5xgjpr53wnyzexjgo6ho Guide:95lrm/RM-A-10-2 4200 1071 4343 2019-04-29T15:48:19Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-10-1|Previous]] | [[Guide:95lrm/RM-A-10-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.10.2 Text File Management}} == Static Semantics == The only allowed file modes for text files are the modes In_File, Out_File, and Append_File. The subprograms given in subclause [[Guide:95lrm/RM-A-8-2|A.8.2]] for the control of external files, and the function End_Of_File given in subclause [[Guide:95lrm/RM-A-8-3|A.8.3]] for sequential input-output, are also available for text files. There is also a version of End_Of_File that refers to the current default input file. For text files, the procedures have the following additional effects: * For the procedures Create and Open: After a file with mode Out_File or Append_File is opened, the page length and line length are unbounded (both have the conventional value zero). After a file (of any mode) is opened, the current column, current line, and current page numbers are set to one. If the mode is Append_File, it is implementation defined whether a page terminator will separate preexisting text in the file from the new text to be written. * For the procedure Close: If the file has the current mode Out_File or Append_File, has the effect of calling New_Page, unless the current page is already terminated; then outputs a file terminator. * For the procedure Reset: If the file has the current mode Out_File or Append_File, has the effect of calling New_Page, unless the current page is already terminated; then outputs a file terminator. The current column, line, and page numbers are set to one, and the line and page lengths to Unbounded. If the new mode is Append_File, it is implementation defined whether a page terminator will separate preexisting text in the file from the new text to be written. The exception Mode_Error is propagated by the procedure Reset upon an attempt to change the mode of a file that is the current default input file, the current default output file, or the current default error file. == Notes == 22  An implementation can define the Form parameter of Create and Open to control effects including the following: * the interpretation of line and column numbers for an interactive file, and * the interpretation of text formats in a file created by a foreign program. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-10-1|Previous]] | [[Guide:95lrm/RM-A-10-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} l1uwwo7cy0kkpc37r2ujiliipa0eunw Guide:95lrm/RM-A-10-3 4200 1072 4344 2019-05-01T17:13:13Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-10-2|Previous]] | [[Guide:95lrm/RM-A-10-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.10.3 Default Input, Output, and Error Files}} == Static Semantics == The following subprograms provide for the control of the particular default files that are used when a file parameter is omitted from a Get, Put, or other operation of text input-output described below, or when application-dependent error-related text is to be output. <p><syntaxhighlight lang="Ada"> procedure Set_Input(File : in File_Type);</syntaxhighlight></p> <p><span></span></p> :Operates on a file of mode In_File. Sets the current default input file to File. <p><span></span></p> :The exception Status_Error is propagated if the given file is not open. The exception Mode_Error is propagated if the mode of the given file is not In_File. <p><syntaxhighlight lang="Ada"> procedure Set_Output(File : in File_Type); procedure Set_Error (File : in File_Type);</syntaxhighlight></p> <p><span></span></p> :Each operates on a file of mode Out_File or Append_File. Set_Output sets the current default output file to File. Set_Error sets the current default error file to File. The exception Status_Error is propagated if the given file is not open. The exception Mode_Error is propagated if the mode of the given file is not Out_File or Append_File. <p><syntaxhighlight lang="Ada"> function Standard_Input return File_Type; function Standard_Input return File_Access;</syntaxhighlight></p> <p><span></span></p> :Returns the standard input file (see [[Guide:95lrm/RM-A-10|A.10]]), or an access value designating the standard input file, respectively. <p><syntaxhighlight lang="Ada"> function Standard_Output return File_Type; function Standard_Output return File_Access;</syntaxhighlight></p> <p><span></span></p> :Returns the standard output file (see [[Guide:95lrm/RM-A-10|A.10]]) or an access value designating the standard output file, respectively. <p><syntaxhighlight lang="Ada"> function Standard_Error return File_Type; function Standard_Error return File_Access;</syntaxhighlight></p> <p><span></span></p> :Returns the standard error file (see [[Guide:95lrm/RM-A-10|A.10]]), or an access value designating the standard error file, respectively. The Form strings implicitly associated with the opening of Standard_Input, Standard_Output, and Standard_Error at the start of program execution are implementation defined. <p><syntaxhighlight lang="Ada"> function Current_Input return File_Type; function Current_Input return File_Access;</syntaxhighlight></p> <p><span></span></p> :Returns the current default input file, or an access value designating the current default input file, respectively. <p><syntaxhighlight lang="Ada"> function Current_Output return File_Type; function Current_Output return File_Access;</syntaxhighlight></p> <p><span></span></p> :Returns the current default output file, or an access value designating the current default output file, respectively. <p><syntaxhighlight lang="Ada"> function Current_Error return File_Type; function Current_Error return File_Access;</syntaxhighlight></p> <p><span></span></p> :Returns the current default error file, or an access value designating the current default error file, respectively. <p><syntaxhighlight lang="Ada"> procedure Flush (File : in File_Type); procedure Flush;</syntaxhighlight></p> <p><span></span></p> :The effect of Flush is the same as the corresponding subprogram in Streams.Stream_IO (see [[Guide:95lrm/RM-A-12-1|A.12.1]]). If File is not explicitly specified, Current_Output is used. == Erroneous Execution == <span id="I5891"></span>The execution of a program is erroneous if it invokes an operation on a current default input, default output, or default error file, and if the corresponding file object is closed or no longer exists. ''This paragraph was deleted.'' == Notes == 23  The standard input, standard output, and standard error files cannot be opened, closed, reset, or deleted, because the parameter File of the corresponding procedures has the mode '''in''' '''out'''. 24  The standard input, standard output, and standard error files are different file objects, but not necessarily different external files. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-10-2|Previous]] | [[Guide:95lrm/RM-A-10-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} ovn0vt59t0ut7ofz476vdaooxi47mew Guide:95lrm/RM-A-10-4 4200 1073 4345 2019-05-01T17:14:24Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-10-3|Previous]] | [[Guide:95lrm/RM-A-10-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.10.4 Specification of Line and Page Lengths}} == Static Semantics == The subprograms described in this subclause are concerned with the line and page structure of a file of mode Out_File or Append_File. They operate either on the file given as the first parameter, or, in the absence of such a file parameter, on the current default output file. They provide for output of text with a specified maximum line length or page length. In these cases, line and page terminators are output implicitly and automatically when needed. When line and page lengths are unbounded (that is, when they have the conventional value zero), as in the case of a newly opened file, new lines and new pages are only started when explicitly called for. In all cases, the exception Status_Error is propagated if the file to be used is not open; the exception Mode_Error is propagated if the mode of the file is not Out_File or Append_File. <p><syntaxhighlight lang="Ada"> procedure Set_Line_Length(File : in File_Type; To : in Count); procedure Set_Line_Length(To   : in Count);</syntaxhighlight></p> <p><span></span></p> :Sets the maximum line length of the specified output or append file to the number of characters specified by To. The value zero for To specifies an unbounded line length. <p><span></span></p> :The exception Use_Error is propagated if the specified line length is inappropriate for the associated external file. <p><syntaxhighlight lang="Ada"> procedure Set_Page_Length(File : in File_Type; To : in Count); procedure Set_Page_Length(To   : in Count);</syntaxhighlight></p> <p><span></span></p> :Sets the maximum page length of the specified output or append file to the number of lines specified by To. The value zero for To specifies an unbounded page length. <p><span></span></p> :The exception Use_Error is propagated if the specified page length is inappropriate for the associated external file. <p><syntaxhighlight lang="Ada"> function Line_Length(File : in File_Type) return Count; function Line_Length return Count;</syntaxhighlight></p> <p><span></span></p> :Returns the maximum line length currently set for the specified output or append file, or zero if the line length is unbounded. <p><syntaxhighlight lang="Ada"> function Page_Length(File : in File_Type) return Count; function Page_Length return Count;</syntaxhighlight></p> <p><span></span></p> :Returns the maximum page length currently set for the specified output or append file, or zero if the page length is unbounded. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-10-3|Previous]] | [[Guide:95lrm/RM-A-10-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} jm0tdftf8w3cwphp6h6sc305iskq3d1 Guide:95lrm/RM-A-10-5 4200 1074 4346 2019-05-01T17:19:23Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-10-4|Previous]] | [[Guide:95lrm/RM-A-10-6|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.10.5 Operations on Columns, Lines, and Pages}} == Static Semantics == The subprograms described in this subclause provide for explicit control of line and page structure; they operate either on the file given as the first parameter, or, in the absence of such a file parameter, on the appropriate (input or output) current default file. The exception Status_Error is propagated by any of these subprograms if the file to be used is not open. <p><syntaxhighlight lang="Ada"> procedure New_Line(File : in File_Type; Spacing : in Positive_Count := 1); procedure New_Line(Spacing : in Positive_Count := 1);</syntaxhighlight></p> <p><span></span></p> :Operates on a file of mode Out_File or Append_File. <p><span></span></p> :For a Spacing of one: Outputs a line terminator and sets the current column number to one. Then increments the current line number by one, except in the case that the current line number is already greater than or equal to the maximum page length, for a bounded page length; in that case a page terminator is output, the current page number is incremented by one, and the current line number is set to one. <p><span></span></p> :For a Spacing greater than one, the above actions are performed Spacing times. <p><span></span></p> :The exception Mode_Error is propagated if the mode is not Out_File or Append_File. <p><syntaxhighlight lang="Ada"> procedure Skip_Line(File  : in File_Type; Spacing : in Positive_Count := 1); procedure Skip_Line(Spacing : in Positive_Count := 1);</syntaxhighlight></p> <p><span></span></p> :Operates on a file of mode In_File. <p><span></span></p> :For a Spacing of one: Reads and discards all characters until a line terminator has been read, and then sets the current column number to one. If the line terminator is not immediately followed by a page terminator, the current line number is incremented by one. Otherwise, if the line terminator is immediately followed by a page terminator, then the page terminator is skipped, the current page number is incremented by one, and the current line number is set to one. <p><span></span></p> :For a Spacing greater than one, the above actions are performed Spacing times. <p><span></span></p> :The exception Mode_Error is propagated if the mode is not In_File. The exception End_Error is propagated if an attempt is made to read a file terminator. <p><syntaxhighlight lang="Ada"> function End_Of_Line(File : in File_Type) return Boolean; function End_Of_Line return Boolean;</syntaxhighlight></p> <p><span></span></p> :Operates on a file of mode In_File. Returns True if a line terminator or a file terminator is next; otherwise returns False. <p><span></span></p> :The exception Mode_Error is propagated if the mode is not In_File. <p><syntaxhighlight lang="Ada"> procedure New_Page(File : in File_Type); procedure New_Page;</syntaxhighlight></p> <p><span></span></p> :Operates on a file of mode Out_File or Append_File. Outputs a line terminator if the current line is not terminated, or if the current page is empty (that is, if the current column and line numbers are both equal to one). Then outputs a page terminator, which terminates the current page. Adds one to the current page number and sets the current column and line numbers to one. <p><span></span></p> :The exception Mode_Error is propagated if the mode is not Out_File or Append_File. <p><syntaxhighlight lang="Ada"> procedure Skip_Page(File : in File_Type); procedure Skip_Page;</syntaxhighlight></p> <p><span></span></p> :Operates on a file of mode In_File. Reads and discards all characters and line terminators until a page terminator has been read. Then adds one to the current page number, and sets the current column and line numbers to one. <p><span></span></p> :The exception Mode_Error is propagated if the mode is not In_File. The exception End_Error is propagated if an attempt is made to read a file terminator. <p><syntaxhighlight lang="Ada"> function End_Of_Page(File : in File_Type) return Boolean; function End_Of_Page return Boolean;</syntaxhighlight></p> <p><span></span></p> :Operates on a file of mode In_File. Returns True if the combination of a line terminator and a page terminator is next, or if a file terminator is next; otherwise returns False. <p><span></span></p> :The exception Mode_Error is propagated if the mode is not In_File. <p><syntaxhighlight lang="Ada"> function End_Of_File(File : in File_Type) return Boolean; function End_Of_File return Boolean;</syntaxhighlight></p> <p><span></span></p> :Operates on a file of mode In_File. Returns True if a file terminator is next, or if the combination of a line, a page, and a file terminator is next; otherwise returns False. <p><span></span></p> :The exception Mode_Error is propagated if the mode is not In_File. The following subprograms provide for the control of the current position of reading or writing in a file. In all cases, the default file is the current output file. <p><syntaxhighlight lang="Ada"> procedure Set_Col(File : in File_Type; To : in Positive_Count); procedure Set_Col(To   : in Positive_Count);</syntaxhighlight></p> <p><span></span></p> :If the file mode is Out_File or Append_File: <p><span></span></p> :* If the value specified by To is greater than the current column number, outputs spaces, adding one to the current column number after each space, until the current column number equals the specified value. If the value specified by To is equal to the current column number, there is no effect. If the value specified by To is less than the current column number, has the effect of calling New_Line (with a spacing of one), then outputs (To - 1) spaces, and sets the current column number to the specified value. <p><span></span></p> :* The exception Layout_Error is propagated if the value specified by To exceeds Line_Length when the line length is bounded (that is, when it does not have the conventional value zero). <p><span></span></p> :If the file mode is In_File: <p><span></span></p> :* Reads (and discards) individual characters, line terminators, and page terminators, until the next character to be read has a column number that equals the value specified by To; there is no effect if the current column number already equals this value. Each transfer of a character or terminator maintains the current column, line, and page numbers in the same way as a Get procedure (see [[Guide:95lrm/RM-A-10-6|A.10.6]]). (Short lines will be skipped until a line is reached that has a character at the specified column position.) <p><span></span></p> :* The exception End_Error is propagated if an attempt is made to read a file terminator. <p><syntaxhighlight lang="Ada"> procedure Set_Line(File : in File_Type; To : in Positive_Count); procedure Set_Line(To   : in Positive_Count);</syntaxhighlight></p> <p><span></span></p> :If the file mode is Out_File or Append_File: <p><span></span></p> :* If the value specified by To is greater than the current line number, has the effect of repeatedly calling New_Line (with a spacing of one), until the current line number equals the specified value. If the value specified by To is equal to the current line number, there is no effect. If the value specified by To is less than the current line number, has the effect of calling New_Page followed by a call of New_Line with a spacing equal to (To - 1). <p><span></span></p> :* The exception Layout_Error is propagated if the value specified by To exceeds Page_Length when the page length is bounded (that is, when it does not have the conventional value zero). <p><span></span></p> :If the mode is In_File: <p><span></span></p> :* Has the effect of repeatedly calling Skip_Line (with a spacing of one), until the current line number equals the value specified by To; there is no effect if the current line number already equals this value. (Short pages will be skipped until a page is reached that has a line at the specified line position.) <p><span></span></p> :* The exception End_Error is propagated if an attempt is made to read a file terminator. <p><syntaxhighlight lang="Ada"> function Col(File : in File_Type) return Positive_Count; function Col return Positive_Count;</syntaxhighlight></p> <p><span></span></p> :Returns the current column number. <p><span></span></p> :The exception Layout_Error is propagated if this number exceeds Count'Last. <p><syntaxhighlight lang="Ada"> function Line(File : in File_Type) return Positive_Count; function Line return Positive_Count;</syntaxhighlight></p> <p><span></span></p> :Returns the current line number. <p><span></span></p> :The exception Layout_Error is propagated if this number exceeds Count'Last. <p><syntaxhighlight lang="Ada"> function Page(File : in File_Type) return Positive_Count; function Page return Positive_Count;</syntaxhighlight></p> <p><span></span></p> :Returns the current page number. <p><span></span></p> :The exception Layout_Error is propagated if this number exceeds Count'Last. The column number, line number, or page number are allowed to exceed Count'Last (as a consequence of the input or output of sufficiently many characters, lines, or pages). These events do not cause any exception to be propagated. However, a call of Col, Line, or Page propagates the exception Layout_Error if the corresponding number exceeds Count'Last. == Notes == 25  A page terminator is always skipped whenever the preceding line terminator is skipped. An implementation may represent the combination of these terminators by a single character, provided that it is properly recognized on input. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-10-4|Previous]] | [[Guide:95lrm/RM-A-10-6|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} e4elst9l6oldvg6tii6fd85aqzz5zzo Guide:95lrm/RM-A-10-6 4200 1075 4347 2019-05-01T17:20:30Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-10-5|Previous]] | [[Guide:95lrm/RM-A-10-7|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.10.6 Get and Put Procedures}} == Static Semantics == The procedures Get and Put for items of the type Character, String, numeric types, and enumeration types are described in subsequent subclauses. Features of these procedures that are common to most of these types are described in this subclause. The Get and Put procedures for items of type Character and String deal with individual character values; the Get and Put procedures for numeric and enumeration types treat the items as lexical elements. All procedures Get and Put have forms with a file parameter, written first. Where this parameter is omitted, the appropriate (input or output) current default file is understood to be specified. Each procedure Get operates on a file of mode In_File. Each procedure Put operates on a file of mode Out_File or Append_File. All procedures Get and Put maintain the current column, line, and page numbers of the specified file: the effect of each of these procedures upon these numbers is the result of the effects of individual transfers of characters and of individual output or skipping of terminators. Each transfer of a character adds one to the current column number. Each output of a line terminator sets the current column number to one and adds one to the current line number. Each output of a page terminator sets the current column and line numbers to one and adds one to the current page number. For input, each skipping of a line terminator sets the current column number to one and adds one to the current line number; each skipping of a page terminator sets the current column and line numbers to one and adds one to the current page number. Similar considerations apply to the procedures Get_Line, Put_Line, and Set_Col. Several Get and Put procedures, for numeric and enumeration types, have ''format'' parameters which specify field lengths; these parameters are of the nonnegative subtype Field of the type Integer. <span id="I5892"></span>Input-output of enumeration values uses the syntax of the corresponding lexical elements. Any Get procedure for an enumeration type begins by skipping any leading blanks, or line or page terminators. Get procedures for numeric or enumeration types start by skipping leading blanks, where a ''blank'' is defined as a space or a horizontal tabulation character. Next, characters are input only so long as the sequence input is an initial sequence of an identifier or of a character literal (in particular, input ceases when a line terminator is encountered). The character or line terminator that causes input to cease remains available for subsequent input. For a numeric type, the Get procedures have a format parameter called Width. If the value given for this parameter is zero, the Get procedure proceeds in the same manner as for enumeration types, but using the syntax of numeric literals instead of that of enumeration literals. If a nonzero value is given, then exactly Width characters are input, or the characters up to a line terminator, whichever comes first; any skipped leading blanks are included in the count. The syntax used for numeric literals is an extended syntax that allows a leading sign (but no intervening blanks, or line or page terminators) and that also allows (for real types) an integer literal as well as forms that have digits only before the point or only after the point. Any Put procedure, for an item of a numeric or an enumeration type, outputs the value of the item as a numeric literal, identifier, or character literal, as appropriate. This is preceded by leading spaces if required by the format parameters Width or Fore (as described in later subclauses), and then a minus sign for a negative value; for an enumeration type, the spaces follow instead of leading. The format given for a Put procedure is overridden if it is insufficiently wide, by using the minimum needed width. Two further cases arise for Put procedures for numeric and enumeration types, if the line length of the specified output file is bounded (that is, if it does not have the conventional value zero). If the number of characters to be output does not exceed the maximum line length, but is such that they cannot fit on the current line, starting from the current column, then (in effect) New_Line is called (with a spacing of one) before output of the item. Otherwise, if the number of characters exceeds the maximum line length, then the exception Layout_Error is propagated and nothing is output. The exception Status_Error is propagated by any of the procedures Get, Get_Line, Put, and Put_Line if the file to be used is not open. The exception Mode_Error is propagated by the procedures Get and Get_Line if the mode of the file to be used is not In_File; and by the procedures Put and Put_Line, if the mode is not Out_File or Append_File. The exception End_Error is propagated by a Get procedure if an attempt is made to skip a file terminator. The exception Data_Error is propagated by a Get procedure if the sequence finally input is not a lexical element corresponding to the type, in particular if no characters were input; for this test, leading blanks are ignored; for an item of a numeric type, when a sign is input, this rule applies to the succeeding numeric literal. The exception Layout_Error is propagated by a Put procedure that outputs to a parameter of type String, if the length of the actual string is insufficient for the output of the item. == Examples == In the examples, here and in subclauses [[Guide:95lrm/RM-A-10-8|A.10.8]] and [[Guide:95lrm/RM-A-10-9|A.10.9]], the string quotes and the lower case letter b are not transferred: they are shown only to reveal the layout and spaces. <p><syntaxhighlight lang="Ada"> N : Integer; ... Get(N);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> --                     Characters at input  Sequence input  Value of N --                     bb-12535b         -12535  -12535 --                     bb12_535e1b       12_535e1  125350 --                     bb12_535e;        12_535e  (none) Data_Error raised</syntaxhighlight></p> Example of overridden width parameter: <p><syntaxhighlight lang="Ada"> Put(Item => -23, Width => 2);  --  "-23"</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-10-5|Previous]] | [[Guide:95lrm/RM-A-10-7|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} lclcrl7l34ep5q4wx4pg7liy5vdn6cf Guide:95lrm/RM-A-10-7 4200 1076 4348 2019-05-01T17:24:14Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-10-6|Previous]] | [[Guide:95lrm/RM-A-10-8|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.10.7 Input-Output of Characters and Strings}} == Static Semantics == For an item of type Character the following procedures are provided: <p><syntaxhighlight lang="Ada"> procedure Get(File : in File_Type; Item : out Character); procedure Get(Item : out Character);</syntaxhighlight></p> <p><span></span></p> :After skipping any line terminators and any page terminators, reads the next character from the specified input file and returns the value of this character in the out parameter Item. <p><span></span></p> :The exception End_Error is propagated if an attempt is made to skip a file terminator. <p><syntaxhighlight lang="Ada"> procedure Put(File : in File_Type; Item : in Character); procedure Put(Item : in Character);</syntaxhighlight></p> <p><span></span></p> :If the line length of the specified output file is bounded (that is, does not have the conventional value zero), and the current column number exceeds it, has the effect of calling New_Line with a spacing of one. Then, or otherwise, outputs the given character to the file. <p><syntaxhighlight lang="Ada"> procedure Look_Ahead (File        : in  File_Type;                    Item        : out Character;                    End_Of_Line : out Boolean); procedure Look_Ahead (Item        : out Character;                    End_Of_Line : out Boolean);</syntaxhighlight></p> <p><span></span></p> :Mode_Error is propagated if the mode of the file is not In_File. Sets End_Of_Line to True if at end of line, including if at end of page or at end of file; in each of these cases the value of Item is not specified. <span id="I5893"></span>Otherwise End_Of_Line is set to False and Item is set to the next character (without consuming it) from the file. <p><syntaxhighlight lang="Ada"> procedure Get_Immediate(File : in  File_Type;                      Item : out Character); procedure Get_Immediate(Item : out Character);</syntaxhighlight></p> <p><span></span></p> :Reads the next character, either control or graphic, from the specified File or the default input file. Mode_Error is propagated if the mode of the file is not In_File. End_Error is propagated if at the end of the file. The current column, line and page numbers for the file are not affected. <p><syntaxhighlight lang="Ada"> procedure Get_Immediate(File      : in  File_Type;                      Item      : out Character;                     Available : out Boolean); procedure Get_Immediate(Item      : out Character;                      Available : out Boolean);</syntaxhighlight></p> <p><span></span></p> :If a character, either control or graphic, is available from the specified File or the default input file, then the character is read; Available is True and Item contains the value of this character. If a character is not available, then Available is False and the value of Item is not specified. <span id="I5894"></span>Mode_Error is propagated if the mode of the file is not In_File. End_Error is propagated if at the end of the file. The current column, line and page numbers for the file are not affected. For an item of type String the following procedures are provided: <p><syntaxhighlight lang="Ada"> procedure Get(File : in File_Type; Item : out String); procedure Get(Item : out String);</syntaxhighlight></p> <p><span></span></p> :Determines the length of the given string and attempts that number of Get operations for successive characters of the string (in particular, no operation is performed if the string is null). <p><syntaxhighlight lang="Ada"> procedure Put(File : in File_Type; Item : in String); procedure Put(Item : in String);</syntaxhighlight></p> <p><span></span></p> :Determines the length of the given string and attempts that number of Put operations for successive characters of the string (in particular, no operation is performed if the string is null). <p><syntaxhighlight lang="Ada"> procedure Get_Line(File : in File_Type;                    Item : out String;                    Last : out Natural); procedure Get_Line(Item : out String;   Last : out Natural);</syntaxhighlight></p> <p><span></span></p> :Reads successive characters from the specified input file and assigns them to successive characters of the specified string. Reading stops if the end of the string is met. Reading also stops if the end of the line is met before meeting the end of the string; in this case Skip_Line is (in effect) called with a spacing of 1. <span id="I5895"></span>The values of characters not assigned are not specified. <p><span></span></p> :If characters are read, returns in Last the index value such that Item(Last) is the last character assigned (the index of the first character assigned is Item'First). If no characters are read, returns in Last an index value that is one less than Item'First. The exception End_Error is propagated if an attempt is made to skip a file terminator. <p><syntaxhighlight lang="Ada"> procedure Put_Line(File : in File_Type; Item : in String); procedure Put_Line(Item : in String);</syntaxhighlight></p> <p><span></span></p> :Calls the procedure Put for the given string, and then the procedure New_Line with a spacing of one. == Implementation Advice == The Get_Immediate procedures should be implemented with unbuffered input. For a device such as a keyboard, input should be ''available'' if a key has already been typed, whereas for a disk file, input should always be available except at end of file. For a file associated with a keyboard-like device, any line-editing features of the underlying operating system should be disabled during the execution of Get_Immediate. == Notes == 26  Get_Immediate can be used to read a single key from the keyboard ''immediately''; that is, without waiting for an end of line. In a call of Get_Immediate without the parameter Available, the caller will wait until a character is available. 27  In a literal string parameter of Put, the enclosing string bracket characters are not output. Each doubled string bracket character in the enclosed string is output as a single string bracket character, as a consequence of the rule for string literals (see [[Guide:95lrm/RM-2-6|2.6]]). 28  A string read by Get or written by Put can extend over several lines. An implementation is allowed to assume that certain external files do not contain page terminators, in which case Get_Line and Skip_Line can return as soon as a line terminator is read. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-10-6|Previous]] | [[Guide:95lrm/RM-A-10-8|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 3tpsnxmeu1w2latdllsw27ztsq4klf8 Guide:95lrm/RM-A-10-8 4200 1077 4349 2019-05-01T17:27:30Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-10-7|Previous]] | [[Guide:95lrm/RM-A-10-9|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.10.8 Input-Output for Integer Types}} == Static Semantics == The following procedures are defined in the generic packages Integer_IO and Modular_IO, which have to be instantiated for the appropriate signed integer or modular type respectively (indicated by Num in the specifications). Values are output as decimal or based literals, without low line characters or exponent, and, for Integer_IO, preceded by a minus sign if negative. The format (which includes any leading spaces and minus sign) can be specified by an optional field width parameter. Values of widths of fields in output formats are of the nonnegative integer subtype Field. Values of bases are of the integer subtype Number_Base. <p><syntaxhighlight lang="Ada"> subtype Number_Base is Integer range 2 .. 16;</syntaxhighlight></p> The default field width and base to be used by output procedures are defined by the following variables that are declared in the generic packages Integer_IO and Modular_IO: <p><syntaxhighlight lang="Ada"> Default_Width : Field := Num'Width; Default_Base  : Number_Base := 10;</syntaxhighlight></p> The following procedures are provided: <p><syntaxhighlight lang="Ada"> procedure Get(File : in File_Type; Item : out Num; Width : in Field := 0); procedure Get(Item : out Num; Width : in Field := 0);</syntaxhighlight></p> <p><span></span></p> :If the value of the parameter Width is zero, skips any leading blanks, line terminators, or page terminators, then reads a plus sign if present or (for a signed type only) a minus sign if present, then reads the longest possible sequence of characters matching the syntax of a numeric literal without a point. If a nonzero value of Width is supplied, then exactly Width characters are input, or the characters (possibly none) up to a line terminator, whichever comes first; any skipped leading blanks are included in the count. <p><span></span></p> :Returns, in the parameter Item, the value of type Num that corresponds to the sequence input. <p><span></span></p> :The exception Data_Error is propagated if the sequence of characters read does not form a legal integer literal or if the value obtained is not of the subtype Num (for Integer_IO) or is not in the base range of Num (for Modular_IO). <p><syntaxhighlight lang="Ada"> procedure Put(File  : in File_Type;            Item  : in Num;            Width : in Field := Default_Width;            Base  : in Number_Base := Default_Base); procedure Put(Item  : in Num;            Width : in Field := Default_Width;            Base  : in Number_Base := Default_Base);</syntaxhighlight></p> <p><span></span></p> :Outputs the value of the parameter Item as an integer literal, with no low lines, no exponent, and no leading zeros (but a single zero for the value zero), and a preceding minus sign for a negative value. <p><span></span></p> :If the resulting sequence of characters to be output has fewer than Width characters, then leading spaces are first output to make up the difference. <p><span></span></p> :Uses the syntax for decimal literal if the parameter Base has the value ten (either explicitly or through Default_Base); otherwise, uses the syntax for based literal, with any letters in upper case. <p><syntaxhighlight lang="Ada"> procedure Get(From : in String; Item : out Num; Last : out Positive);</syntaxhighlight></p> <p><span></span></p> :Reads an integer value from the beginning of the given string, following the same rules as the Get procedure that reads an integer value from a file, but treating the end of the string as a file terminator. Returns, in the parameter Item, the value of type Num that corresponds to the sequence input. Returns in Last the index value such that From(Last) is the last character read. <p><span></span></p> :The exception Data_Error is propagated if the sequence input does not have the required syntax or if the value obtained is not of the subtype Num. <p><syntaxhighlight lang="Ada"> procedure Put(To   : out String;            Item : in Num;            Base : in Number_Base := Default_Base);</syntaxhighlight></p> <p><span></span></p> :Outputs the value of the parameter Item to the given string, following the same rule as for output to a file, using the length of the given string as the value for Width. Integer_Text_IO is a library package that is a nongeneric equivalent to Text_IO.Integer_IO for the predefined type Integer: <p><syntaxhighlight lang="Ada"> with Ada.Text_IO; package Ada.Integer_Text_IO is new Ada.Text_IO.Integer_IO(Integer);</syntaxhighlight></p> For each predefined signed integer type, a nongeneric equivalent to Text_IO.Integer_IO is provided, with names such as Ada.Long_Integer_Text_IO. == Implementation Permissions == The nongeneric equivalent packages may, but need not, be actual instantiations of the generic package for the appropriate predefined type. == Notes == 29  For Modular_IO, execution of Get propagates Data_Error if the sequence of characters read forms an integer literal outside the range 0..Num'Last. == Examples == ''This paragraph was deleted.'' <p><syntaxhighlight lang="Ada"> package Int_IO is new Integer_IO(Small_Int); use Int_IO; -- default format used at instantiation, -- Default_Width = 4, Default_Base = 10</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Put(126);                            -- "b126" Put(-126, 7);                        -- "bbb-126" Put(126, Width => 13, Base => 2);    -- "bbb2#1111110#"</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-10-7|Previous]] | [[Guide:95lrm/RM-A-10-9|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 4w5gaf7wapnnat3lyak3tmom9wbj43e Guide:95lrm/RM-A-10-9 4200 1078 4350 2019-05-01T17:37:40Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-10-8|Previous]] | [[Guide:95lrm/RM-A-10-10|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.10.9 Input-Output for Real Types}} == Static Semantics == The following procedures are defined in the generic packages Float_IO, Fixed_IO, and Decimal_IO, which have to be instantiated for the appropriate floating point, ordinary fixed point, or decimal fixed point type respectively (indicated by Num in the specifications). Values are output as decimal literals without low line characters. The format of each value output consists of a Fore field, a decimal point, an Aft field, and (if a nonzero Exp parameter is supplied) the letter E and an Exp field. The two possible formats thus correspond to: <p><syntaxhighlight lang="Ada"> Fore  .  Aft</syntaxhighlight></p> and to: <p><syntaxhighlight lang="Ada"> Fore  .  Aft  E  Exp</syntaxhighlight></p> without any spaces between these fields. The Fore field may include leading spaces, and a minus sign for negative values. The Aft field includes only decimal digits (possibly with trailing zeros). The Exp field includes the sign (plus or minus) and the exponent (possibly with leading zeros). For floating point types, the default lengths of these fields are defined by the following variables that are declared in the generic package Float_IO: <p><syntaxhighlight lang="Ada"> Default_Fore : Field := 2; Default_Aft  : Field := Num'Digits-1; Default_Exp  : Field := 3;</syntaxhighlight></p> For ordinary or decimal fixed point types, the default lengths of these fields are defined by the following variables that are declared in the generic packages Fixed_IO and Decimal_IO, respectively: <p><syntaxhighlight lang="Ada"> Default_Fore : Field := Num'Fore; Default_Aft  : Field := Num'Aft; Default_Exp  : Field := 0;</syntaxhighlight></p> The following procedures are provided: <p><syntaxhighlight lang="Ada"> procedure Get(File : in File_Type; Item : out Num; Width : in Field := 0); procedure Get(Item : out Num; Width : in Field := 0);</syntaxhighlight></p> <p><span></span></p> :If the value of the parameter Width is zero, skips any leading blanks, line terminators, or page terminators, then reads the longest possible sequence of characters matching the syntax of any of the following (see [[Guide:95lrm/RM-2-4|2.4]]): <p><span></span></p> :* [+|-]numeric_literal <p><span></span></p> :* [+|-]numeral.[exponent] <p><span></span></p> :* [+|-].numeral[exponent] <p><span></span></p> :* [+|-]base#based_numeral.#[exponent] <p><span></span></p> :* [+|-]base#.based_numeral#[exponent] <p><span></span></p> :If a nonzero value of Width is supplied, then exactly Width characters are input, or the characters (possibly none) up to a line terminator, whichever comes first; any skipped leading blanks are included in the count. <p><span></span></p> :Returns in the parameter Item the value of type Num that corresponds to the sequence input, preserving the sign (positive if none has been specified) of a zero value if Num is a floating point type and Num'Signed_Zeros is True. <p><span></span></p> :The exception Data_Error is propagated if the sequence input does not have the required syntax or if the value obtained is not of the subtype Num. <p><syntaxhighlight lang="Ada"> procedure Put(File : in File_Type;            Item : in Num;            Fore : in Field := Default_Fore;            Aft  : in Field := Default_Aft;            Exp  : in Field := Default_Exp); procedure Put(Item : in Num;            Fore : in Field := Default_Fore;            Aft  : in Field := Default_Aft;            Exp  : in Field := Default_Exp);</syntaxhighlight></p> <p><span></span></p> :Outputs the value of the parameter Item as a decimal literal with the format defined by Fore, Aft and Exp. If the value is negative, or if Num is a floating point type where Num'Signed_Zeros is True and the value is a negatively signed zero, then a minus sign is included in the integer part. If Exp has the value zero, then the integer part to be output has as many digits as are needed to represent the integer part of the value of Item, overriding Fore if necessary, or consists of the digit zero if the value of Item has no integer part. <p><span></span></p> :If Exp has a value greater than zero, then the integer part to be output has a single digit, which is nonzero except for the value 0.0 of Item. <p><span></span></p> :In both cases, however, if the integer part to be output has fewer than Fore characters, including any minus sign, then leading spaces are first output to make up the difference. The number of digits of the fractional part is given by Aft, or is one if Aft equals zero. The value is rounded; a value of exactly one half in the last place is rounded away from zero. <p><span></span></p> :If Exp has the value zero, there is no exponent part. If Exp has a value greater than zero, then the exponent part to be output has as many digits as are needed to represent the exponent part of the value of Item (for which a single digit integer part is used), and includes an initial sign (plus or minus). If the exponent part to be output has fewer than Exp characters, including the sign, then leading zeros precede the digits, to make up the difference. For the value 0.0 of Item, the exponent has the value zero. <p><syntaxhighlight lang="Ada"> procedure Get(From : in String; Item : out Num; Last : out Positive);</syntaxhighlight></p> <p><span></span></p> :Reads a real value from the beginning of the given string, following the same rule as the Get procedure that reads a real value from a file, but treating the end of the string as a file terminator. Returns, in the parameter Item, the value of type Num that corresponds to the sequence input. Returns in Last the index value such that From(Last) is the last character read. <p><span></span></p> :The exception Data_Error is propagated if the sequence input does not have the required syntax, or if the value obtained is not of the subtype Num. <p><syntaxhighlight lang="Ada"> procedure Put(To   : out String;            Item : in Num;            Aft  : in Field := Default_Aft;            Exp  : in Field := Default_Exp);</syntaxhighlight></p> <p><span></span></p> :Outputs the value of the parameter Item to the given string, following the same rule as for output to a file, using a value for Fore such that the sequence of characters output exactly fills the string, including any leading spaces. Float_Text_IO is a library package that is a nongeneric equivalent to Text_IO.Float_IO for the predefined type Float: <p><syntaxhighlight lang="Ada"> with Ada.Text_IO; package Ada.Float_Text_IO is new Ada.Text_IO.Float_IO(Float);</syntaxhighlight></p> For each predefined floating point type, a nongeneric equivalent to Text_IO.Float_IO is provided, with names such as Ada.Long_Float_Text_IO. == Implementation Permissions == An implementation may extend Get and Put for floating point types to support special values such as infinities and NaNs. The implementation of Put need not produce an output value with greater accuracy than is supported for the base subtype. The additional accuracy, if any, of the value produced by Put when the number of requested digits in the integer and fractional parts exceeds the required accuracy is implementation defined. The nongeneric equivalent packages may, but need not, be actual instantiations of the generic package for the appropriate predefined type. == Notes == 30  For an item with a positive value, if output to a string exactly fills the string without leading spaces, then output of the corresponding negative value will propagate Layout_Error. 31  The rules for the Value attribute (see [[Guide:95lrm/RM-3-5|3.5]]) and the rules for Get are based on the same set of formats. == Examples == ''This paragraph was deleted.'' <p><syntaxhighlight lang="Ada"> package Real_IO is new Float_IO(Real); use Real_IO; -- default format used at instantiation, Default_Exp = 3</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> X : Real := -123.4567;  --  digits 8      (see 3.5.7)</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Put(X);  -- default format                            "-1.2345670E+02" Put(X, Fore => 5, Aft => 3, Exp => 2);                -- "bbb-1.235E+2" Put(X, 5, 3, 0);                                      -- "b-123.457"</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-10-8|Previous]] | [[Guide:95lrm/RM-A-10-10|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} fmzwrcm3kh2kddnubvg6qiai1llqeu5 Guide:95lrm/RM-A-11 4200 1079 4351 2019-04-29T15:48:20Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-10-10|Previous]] | [[Guide:95lrm/RM-A-12|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.11 Wide Text Input-Output}} The package Wide_Text_IO provides facilities for input and output in human-readable form. Each file is read or written sequentially, as a sequence of wide characters grouped into lines, and as a sequence of lines grouped into pages. == Static Semantics == <span id="I5902"></span><span id="I5903"></span><span id="I5904"></span>The specification of package Wide_Text_IO is the same as that for Text_IO, except that in each Get, Look_Ahead, Get_Immediate, Get_Line, Put, and Put_Line procedure, any occurrence of Character is replaced by Wide_Character, and any occurrence of String is replaced by Wide_String. <span id="I5905"></span><span id="I5906"></span><span id="I5907"></span><span id="I5908"></span><span id="I5909"></span><span id="I5910"></span>Nongeneric equivalents of Wide_Text_IO.Integer_IO and Wide_Text_IO.Float_IO are provided (as for Text_IO) for each predefined numeric type, with names such as Ada.Integer_Wide_Text_IO, Ada.Long_Integer_Wide_Text_IO, Ada.Float_Wide_Text_IO, Ada.Long_Float_Wide_Text_IO. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-10-10|Previous]] | [[Guide:95lrm/RM-A-12|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 7oln5zapqkh7sj6cg3zw3pon5v2751g Guide:95lrm/RM-A-12 4200 1080 4352 2019-04-29T15:48:20Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-11|Previous]] | [[Guide:95lrm/RM-A-12-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.12 Stream Input-Output}} The packages Streams.Stream_IO, Text_IO.Text_Streams, and Wide_Text_IO.Text_Streams provide stream-oriented operations on files. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-11|Previous]] | [[Guide:95lrm/RM-A-12-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} jiq7iwhjv4jqhh5kfn16npf6fu6c6n4 Guide:95lrm/RM-A-12-1 4200 1081 4353 2019-05-01T17:51:06Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-12|Previous]] | [[Guide:95lrm/RM-A-12-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.12.1 The Package Streams.Stream_IO}} <span id="I5911"></span>The subprograms in the child package Streams.Stream_IO provide control over stream files. Access to a stream file is either sequential, via a call on Read or Write to transfer an array of stream elements, or positional (if supported by the implementation for the given file), by specifying a relative index for an element. Since a stream file can be converted to a Stream_Access value, calling stream-oriented attribute subprograms of different element types with the same Stream_Access value provides heterogeneous input-output. See [[Guide:95lrm/RM-13-13|13.13]] for a general discussion of streams. == Static Semantics == <div> The elements of a stream file are stream elements. If positioning is supported for the specified external file, a current index and current size are maintained for the file as described in [[Guide:95lrm/RM-A-8|A.8]]. If positioning is not supported, a current index is not maintained, and the current size is implementation defined.<span id="I5912"></span><span id="I5913"></span> </div> The library package Streams.Stream_IO has the following declaration: <p><syntaxhighlight lang="Ada"> with Ada.IO_Exceptions; package Ada.Streams.Stream_IO is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     type Stream_Access is access all Root_Stream_Type'Class;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     type File_Type is limited private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     type File_Mode is (In_File, Out_File, Append_File);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     type    Count          is range 0 .. implementation-defined;  subtype Positive_Count is Count range 1 .. Count'Last;    -- Index into file, in stream elements.</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     procedure Create (File : in out File_Type;                    Mode : in File_Mode := Out_File;                    Name : in String    := "";                    Form : in String    := "");</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     procedure Open (File : in out File_Type;                  Mode : in File_Mode;                  Name : in String;                  Form : in String := "");</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     procedure Close  (File : in out File_Type);  procedure Delete (File : in out File_Type);  procedure Reset  (File : in out File_Type; Mode : in File_Mode);  procedure Reset  (File : in out File_Type);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     function Mode (File : in File_Type) return File_Mode;  function Name (File : in File_Type) return String;  function Form (File : in File_Type) return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     function Is_Open     (File : in File_Type) return Boolean;  function End_Of_File (File : in File_Type) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     function Stream (File : in File_Type) return Stream_Access;      -- Return stream access for use with T'Input and T'Output</syntaxhighlight></p> ''This paragraph was deleted.'' <p><syntaxhighlight lang="Ada">     -- Read array of stream elements from file  procedure Read (File : in  File_Type;                  Item : out Stream_Element_Array;                 Last : out Stream_Element_Offset;                  From : in  Positive_Count);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     procedure Read (File : in  File_Type;                  Item : out Stream_Element_Array;                  Last : out Stream_Element_Offset);</syntaxhighlight></p> ''This paragraph was deleted.'' <p><syntaxhighlight lang="Ada">     -- Write array of stream elements into file  procedure Write (File : in File_Type;                   Item : in Stream_Element_Array;                  To   : in Positive_Count);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     procedure Write (File : in File_Type;                      Item : in Stream_Element_Array);</syntaxhighlight></p> ''This paragraph was deleted.'' <p><syntaxhighlight lang="Ada">     -- Operations on position within file</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     procedure Set_Index(File : in File_Type; To : in Positive_Count);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     function Index(File : in File_Type) return Positive_Count;  function Size (File : in File_Type) return Count;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     procedure Set_Mode(File : in out File_Type; Mode : in File_Mode);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     procedure Flush(File : in File_Type);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     -- exceptions  Status_Error : exception renames IO_Exceptions.Status_Error;  Mode_Error   : exception renames IO_Exceptions.Mode_Error;  Name_Error   : exception renames IO_Exceptions.Name_Error;  Use_Error    : exception renames IO_Exceptions.Use_Error;  Device_Error : exception renames IO_Exceptions.Device_Error;  End_Error    : exception renames IO_Exceptions.End_Error;  Data_Error   : exception renames IO_Exceptions.Data_Error;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> private ... -- not specified by the language end Ada.Streams.Stream_IO;</syntaxhighlight></p> The subprograms Create, Open, Close, Delete, Reset, Mode, Name, Form, Is_Open, and End_of_File have the same effect as the corresponding subprograms in Sequential_IO (see [[Guide:95lrm/RM-A-8-2|A.8.2]]). <div> The Set_Mode procedure changes the mode of the file. If the new mode is Append_File, the file is positioned to its end; otherwise, the position in the file is unchanged. The Flush procedure synchronizes the external file with the internal file (by flushing any internal buffers) without closing the file or changing the position. Mode_Error is propagated if the mode of the file is In_File. </div> The Stream function returns a Stream_Access result from a File_Type object, thus allowing the stream-oriented attributes Read, Write, Input, and Output to be used on the same file for multiple types. Stream propagates Status_Error if File is not open. The procedures Read and Write are equivalent to the corresponding operations in the package Streams. Read propagates Mode_Error if the mode of File is not In_File. Write propagates Mode_Error if the mode of File is not Out_File or Append_File. The Read procedure with a Positive_Count parameter starts reading at the specified index. The Write procedure with a Positive_Count parameter starts writing at the specified index. <div> The Size function returns the current size of the file. </div> The Index function returns the current index. The Set_Index procedure sets the current index to the specified value. :If positioning is supported for the external file, the current index is maintained as follows: ::* For Open and Create, if the Mode parameter is Append_File, the current index is set to the current size of the file plus one; otherwise, the current index is set to one. ::* For Reset, if the Mode parameter is Append_File, or no Mode parameter is given and the current mode is Append_File, the current index is set to the current size of the file plus one; otherwise, the current index is set to one. ::* For Set_Mode, if the new mode is Append_File, the current index is set to current size plus one; otherwise, the current index is unchanged. ::* For Read and Write without a Positive_Count parameter, the current index is incremented by the number of stream elements read or written. ::* For Read and Write with a Positive_Count parameter, the value of the current index is set to the value of the Positive_Count parameter plus the number of stream elements read or written. If positioning is not supported for the given file, then a call of Index or Set_Index propagates Use_Error. Similarly, a call of Read or Write with a Positive_Count parameter propagates Use_Error. ''This paragraph was deleted.'' ''This paragraph was deleted.'' ''This paragraph was deleted.'' == Erroneous Execution == <div> <span id="I5975"></span>If the File_Type object passed to the Stream function is later closed or finalized, and the stream-oriented attributes are subsequently called (explicitly or implicitly) on the Stream_Access value returned by Stream, execution is erroneous. This rule applies even if the File_Type object was opened again after it had been closed. </div> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-12|Previous]] | [[Guide:95lrm/RM-A-12-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} fkc6mp2c3jobuh2s88yig7igjclodbf Guide:95lrm/RM-A-12-2 4200 1082 4354 2019-05-01T17:52:07Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-12-1|Previous]] | [[Guide:95lrm/RM-A-12-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.12.2 The Package Text_IO.Text_Streams}} The package Text_IO.Text_Streams provides a function for treating a text file as a stream. == Static Semantics == The library package Text_IO.Text_Streams has the following declaration: <p><syntaxhighlight lang="Ada"> with Ada.Streams; package Ada.Text_IO.Text_Streams is type Stream_Access is access all Streams.Root_Stream_Type'Class;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Stream (File : in File_Type) return Stream_Access; end Ada.Text_IO.Text_Streams;</syntaxhighlight></p> The Stream function has the same effect as the corresponding function in Streams.Stream_IO. == Notes == 34  The ability to obtain a stream for a text file allows Current_Input, Current_Output, and Current_Error to be processed with the functionality of streams, including the mixing of text and binary input-output, and the mixing of binary input-output for different types. 35  Performing operations on the stream associated with a text file does not affect the column, line, or page counts. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-12-1|Previous]] | [[Guide:95lrm/RM-A-12-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 6usbcs3i3gku7r23v72ozewtvskd7r3 Guide:95lrm/RM-A-12-3 4200 1083 4355 2019-05-01T17:52:46Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-12-2|Previous]] | [[Guide:95lrm/RM-A-13|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.12.3 The Package Wide_Text_IO.Text_Streams}} The package Wide_Text_IO.Text_Streams provides a function for treating a wide text file as a stream. == Static Semantics == The library package Wide_Text_IO.Text_Streams has the following declaration: <p><syntaxhighlight lang="Ada"> with Ada.Streams; package Ada.Wide_Text_IO.Text_Streams is type Stream_Access is access all Streams.Root_Stream_Type'Class;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Stream (File : in File_Type) return Stream_Access; end Ada.Wide_Text_IO.Text_Streams;</syntaxhighlight></p> The Stream function has the same effect as the corresponding function in Streams.Stream_IO. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-12-2|Previous]] | [[Guide:95lrm/RM-A-13|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} kjduqot9h40e594dntzozt8o0eqgzi0 Guide:95lrm/RM-A-13 4200 1084 4356 2019-05-01T17:53:48Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-12-3|Previous]] | [[Guide:95lrm/RM-A-14|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.13 Exceptions in Input-Output}} The package IO_Exceptions defines the exceptions needed by the predefined input-output packages. == Static Semantics == The library package IO_Exceptions has the following declaration: <p><syntaxhighlight lang="Ada"> package Ada.IO_Exceptions is pragma Pure(IO_Exceptions);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Status_Error : exception; Mode_Error   : exception; Name_Error   : exception; Use_Error    : exception; Device_Error : exception; End_Error    : exception; Data_Error   : exception; Layout_Error : exception;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> end Ada.IO_Exceptions;</syntaxhighlight></p> If more than one error condition exists, the corresponding exception that appears earliest in the following list is the one that is propagated. The exception Status_Error is propagated by an attempt to operate upon a file that is not open, and by an attempt to open a file that is already open. The exception Mode_Error is propagated by an attempt to read from, or test for the end of, a file whose current mode is Out_File or Append_File, and also by an attempt to write to a file whose current mode is In_File. In the case of Text_IO, the exception Mode_Error is also propagated by specifying a file whose current mode is Out_File or Append_File in a call of Set_Input, Skip_Line, End_Of_Line, Skip_Page, or End_Of_Page; and by specifying a file whose current mode is In_File in a call of Set_Output, Set_Line_Length, Set_Page_Length, Line_Length, Page_Length, New_Line, or New_Page. The exception Name_Error is propagated by a call of Create or Open if the string given for the parameter Name does not allow the identification of an external file. For example, this exception is propagated if the string is improper, or, alternatively, if either none or more than one external file corresponds to the string. The exception Use_Error is propagated if an operation is attempted that is not possible for reasons that depend on characteristics of the external file. For example, this exception is propagated by the procedure Create, among other circumstances, if the given mode is Out_File but the form specifies an input only device, if the parameter Form specifies invalid access rights, or if an external file with the given name already exists and overwriting is not allowed. The exception Device_Error is propagated if an input-output operation cannot be completed because of a malfunction of the underlying system. The exception End_Error is propagated by an attempt to skip (read past) the end of a file. The exception Data_Error can be propagated by the procedure Read (or by the Read attribute) if the element read cannot be interpreted as a value of the required subtype. This exception is also propagated by a procedure Get (defined in the package Text_IO) if the input character sequence fails to satisfy the required syntax, or if the value input does not belong to the range of the required subtype. The exception Layout_Error is propagated (in text input-output) by Col, Line, or Page if the value returned exceeds Count'Last. The exception Layout_Error is also propagated on output by an attempt to set column or line numbers in excess of specified maximum line or page lengths, respectively (excluding the unbounded cases). It is also propagated by an attempt to Put too many characters to a string. == Documentation Requirements == The implementation shall document the conditions under which Name_Error, Use_Error and Device_Error are propagated. == Implementation Permissions == If the associated check is too complex, an implementation need not propagate Data_Error as part of a procedure Read (or the Read attribute) if the value read cannot be interpreted as a value of the required subtype. == Erroneous Execution == <span id="I6001"></span>If the element read by the procedure Read (or by the Read attribute) cannot be interpreted as a value of the required subtype, but this is not detected and Data_Error is not propagated, then the resulting value can be abnormal, and subsequent references to the value can lead to erroneous execution, as explained in [[Guide:95lrm/RM-13-9-1|13.9.1]]. <span id="I6002"></span><span id="I6003"></span> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-12-3|Previous]] | [[Guide:95lrm/RM-A-14|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 7jo64r5eglj5r2graz2jev6wdj2c87s Guide:95lrm/RM-A-14 4200 1085 4357 2019-04-29T15:48:20Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-13|Previous]] | [[Guide:95lrm/RM-A-15|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.14 File Sharing}} == Dynamic Semantics == <span id="I6004"></span>It is not specified by the language whether the same external file can be associated with more than one file object. If such sharing is supported by the implementation, the following effects are defined: * Operations on one text file object do not affect the column, line, and page numbers of any other file object. * ''This paragraph was deleted.'' * For direct and stream files, the current index is a property of each file object; an operation on one file object does not affect the current index of any other file object. * For direct and stream files, the current size of the file is a property of the external file. All other effects are identical. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-13|Previous]] | [[Guide:95lrm/RM-A-15|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} nxwcgipj5cfe4mg0wl27w9zym4eiayf Guide:95lrm/RM-A-15 4200 1086 4358 2019-05-01T17:58:27Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-14|Previous]] | [[Guide:95lrm/RM-B|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.15 The Package Command_Line}} The package Command_Line allows a program to obtain the values of its arguments and to set the exit status code to be returned on normal termination. == Static Semantics == The library package Ada.Command_Line has the following declaration: <p><syntaxhighlight lang="Ada"> package Ada.Command_Line is   pragma Preelaborate(Command_Line);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function Argument_Count return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function Argument (Number : in Positive) return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function Command_Name return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   type Exit_Status is implementation-defined integer type;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   Success : constant Exit_Status;   Failure : constant Exit_Status;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   procedure Set_Exit_Status (Code : in Exit_Status);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> private   ... -- not specified by the language end Ada.Command_Line;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> function Argument_Count return Natural;</syntaxhighlight></p> <p><span></span></p> :If the external execution environment supports passing arguments to a program, then Argument_Count returns the number of arguments passed to the program invoking the function. Otherwise it returns 0. The meaning of ''number of arguments'' is implementation defined. <p><syntaxhighlight lang="Ada"> function Argument (Number : in Positive) return String;</syntaxhighlight></p> <p><span></span></p> :If the external execution environment supports passing arguments to a program, then Argument returns an implementation-defined value corresponding to the argument at relative position Number. <span id="I6020"></span>If Number is outside the range 1..Argument_Count, then Constraint_Error is propagated. <p><syntaxhighlight lang="Ada"> function Command_Name return String;</syntaxhighlight></p> <p><span></span></p> :If the external execution environment supports passing arguments to a program, then Command_Name returns an implementation-defined value corresponding to the name of the command invoking the program; otherwise Command_Name returns the null string. <div> <p><syntaxhighlight lang="Ada"> type Exit_Status is implementation-defined integer type;</syntaxhighlight></p> </div> <p><span></span></p> :The type Exit_Status represents the range of exit status values supported by the external execution environment. The constants Success and Failure correspond to success and failure, respectively. <p><syntaxhighlight lang="Ada"> procedure Set_Exit_Status (Code : in Exit_Status);</syntaxhighlight></p> <p><span></span></p> :If the external execution environment supports returning an exit status from a program, then Set_Exit_Status sets Code as the status. Normal termination of a program returns as the exit status the value most recently set by Set_Exit_Status, or, if no such value has been set, then the value Success. If a program terminates abnormally, the status set by Set_Exit_Status is ignored, and an implementation-defined exit status value is set. <p><span></span></p> :If the external execution environment does not support returning an exit value from a program, then Set_Exit_Status does nothing. == Implementation Permissions == An alternative declaration is allowed for package Command_Line if different functionality is appropriate for the external execution environment. == Notes == 36  Argument_Count, Argument, and Command_Name correspond to the C language's argc, argv[n] (for n>0) and argv[0], respectively. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-14|Previous]] | [[Guide:95lrm/RM-B|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} a8lv46kbasbmxrqo29d7m5e2wddhiyz Guide:95lrm/RM-A-2 4200 1087 4359 2019-05-01T12:40:47Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-1|Previous]] | [[Guide:95lrm/RM-A-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.2 The Package Ada}} == Static Semantics == The following language-defined library package exists: <p><syntaxhighlight lang="Ada"> package Ada is  pragma Pure(Ada); end Ada;</syntaxhighlight></p> Ada serves as the parent of most of the other language-defined library units; its declaration is empty (except for the pragma Pure). == Legality Rules == In the standard mode, it is illegal to compile a child of package Ada. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-1|Previous]] | [[Guide:95lrm/RM-A-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 12tfctl9rm6j0ffbfd9e6io7r0ifvam Guide:95lrm/RM-A-3 4200 1088 4360 2019-04-29T15:48:20Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-2|Previous]] | [[Guide:95lrm/RM-A-3-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.3 Character Handling}} This clause presents the packages related to character processing: an empty pure package Characters and child packages Characters.Handling and Characters.Latin_1. The package Characters.Handling provides classification and conversion functions for Character data, and some simple functions for dealing with Wide_Character data. The child package Characters.Latin_1 declares a set of constants initialized to values of type Character. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-2|Previous]] | [[Guide:95lrm/RM-A-3-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} dguf1tk7ut8q71b5zryh26vgsrr7v7d Guide:95lrm/RM-A-3-1 4200 1089 4361 2019-05-01T12:41:20Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-3|Previous]] | [[Guide:95lrm/RM-A-3-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.3.1 The Package Characters}} == Static Semantics == The library package Characters has the following declaration: <p><syntaxhighlight lang="Ada"> package Ada.Characters is   pragma Pure(Characters); end Ada.Characters;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-3|Previous]] | [[Guide:95lrm/RM-A-3-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} az4c2ttk51b8jg78g4bbn9whwkhbrry Guide:95lrm/RM-A-3-2 4200 1090 4362 2019-05-01T12:48:27Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-3-1|Previous]] | [[Guide:95lrm/RM-A-3-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.3.2 The Package Characters.Handling}} == Static Semantics == The library package Characters.Handling has the following declaration: <p><syntaxhighlight lang="Ada"> package Ada.Characters.Handling is   pragma Preelaborate(Handling);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> --Character classification functions</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function Is_Control           (Item : in Character) return Boolean;   function Is_Graphic           (Item : in Character) return Boolean;   function Is_Letter            (Item : in Character) return Boolean;   function Is_Lower             (Item : in Character) return Boolean;   function Is_Upper             (Item : in Character) return Boolean;   function Is_Basic             (Item : in Character) return Boolean;   function Is_Digit             (Item : in Character) return Boolean;   function Is_Decimal_Digit     (Item : in Character) return Boolean                   renames Is_Digit;   function Is_Hexadecimal_Digit (Item : in Character) return Boolean;   function Is_Alphanumeric      (Item : in Character) return Boolean;   function Is_Special           (Item : in Character) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> --Conversion functions for Character and String</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function To_Lower (Item : in Character) return Character;   function To_Upper (Item : in Character) return Character;   function To_Basic (Item : in Character) return Character;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function To_Lower (Item : in String) return String;   function To_Upper (Item : in String) return String;   function To_Basic (Item : in String) return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> --Classifications of and conversions between Character and ISO 646</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   subtype ISO_646 is  Character range Character'Val(0) .. Character'Val(127);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function Is_ISO_646 (Item : in Character) return Boolean;   function Is_ISO_646 (Item : in String)    return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function To_ISO_646 (Item       : in Character;                     Substitute : in ISO_646 := ' ')  return ISO_646;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function To_ISO_646 (Item       : in String;                     Substitute : in ISO_646 := ' ')  return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> --Classifications of and conversions between Wide_Character and Character.</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function Is_Character (Item : in Wide_Character) return Boolean;   function Is_String    (Item : in Wide_String)    return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function To_Character (Item       : in Wide_Character;                       Substitute : in Character := ' ')   return Character;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">  function To_String    (Item       : in Wide_String;                       Substitute : in Character := ' ')  return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function To_Wide_Character (Item : in Character) return Wide_Character;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function To_Wide_String    (Item : in String)    return Wide_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> end Ada.Characters.Handling;</syntaxhighlight></p> In the description below for each function that returns a Boolean result, the effect is described in terms of the conditions under which the value True is returned. If these conditions are not met, then the function returns False. Each of the following classification functions has a formal Character parameter, Item, and returns a Boolean result. ;  <span id="I4636"></span>Is_Control : True if Item is a control character. A ''control character'' is a character whose position is in one of the ranges 0..31 or 127..159. ;  <span id="I4637"></span>Is_Graphic : True if Item is a graphic character. A ''graphic character'' is a character whose position is in one of the ranges 32..126 or 160..255. ;  <span id="I4638"></span>Is_Letter : True if Item is a letter. A ''letter'' is a character that is in one of the ranges 'A'..'Z' or 'a'..'z', or whose position is in one of the ranges 192..214, 216..246, or 248..255. ;  <span id="I4639"></span>Is_Lower : True if Item is a lower-case letter. A ''lower-case letter'' is a character that is in the range 'a'..'z', or whose position is in one of the ranges 223..246 or 248..255. ;  <span id="I4640"></span>Is_Upper : True if Item is an upper-case letter. An ''upper-case letter'' is a character that is in the range 'A'..'Z' or whose position is in one of the ranges 192..214 or 216.. 222. ;  <span id="I4641"></span>Is_Basic : True if Item is a basic letter. A ''basic letter'' is a character that is in one of the ranges 'A'..'Z' and 'a'..'z', or that is one of the following: 'Æ', 'æ', 'Ð', 'ð', 'Þ', 'þ', or 'ß'. ;  <span id="I4642"></span>Is_Digit : True if Item is a decimal digit. A ''decimal digit'' is a character in the range '0'..'9'. ;  Is_Decimal_Digit : A renaming of Is_Digit. ;  <span id="I4643"></span>Is_Hexadecimal_Digit : True if Item is a hexadecimal digit. A ''hexadecimal digit'' is a character that is either a decimal digit or that is in one of the ranges 'A' .. 'F' or 'a' .. 'f'. ;  <span id="I4644"></span>Is_Alphanumeric : True if Item is an alphanumeric character. An ''alphanumeric character'' is a character that is either a letter or a decimal digit. ;  <span id="I4645"></span>Is_Special : True if Item is a special graphic character. A ''special graphic character'' is a graphic character that is not alphanumeric. Each of the names To_Lower, To_Upper, and To_Basic refers to two functions: one that converts from Character to Character, and the other that converts from String to String. The result of each Character-to-Character function is described below, in terms of the conversion applied to Item, its formal Character parameter. The result of each String-to-String conversion is obtained by applying to each element of the function's String parameter the corresponding Character-to-Character conversion; the result is the null String if the value of the formal parameter is the null String. The lower bound of the result String is 1. ;  To_Lower : Returns the corresponding lower-case value for Item if Is_Upper(Item), and returns Item otherwise. ;  To_Upper : Returns the corresponding upper-case value for Item if Is_Lower(Item) and Item has an upper-case form, and returns Item otherwise. The lower case letters 'ß' and 'ÿ' do not have upper case forms. ;  To_Basic : Returns the letter corresponding to Item but with no diacritical mark, if Item is a letter but not a basic letter; returns Item otherwise. The following set of functions test for membership in the ISO 646 character range, or convert between ISO 646 and Character. ;  Is_ISO_646 : The function whose formal parameter, Item, is of type Character returns True if Item is in the subtype ISO_646. ;  Is_ISO_646 : The function whose formal parameter, Item, is of type String returns True if Is_ISO_646(Item(I)) is True for each I in Item'Range. ;  To_ISO_646 : The function whose first formal parameter, Item, is of type Character returns Item if Is_ISO_646(Item), and returns the Substitute ISO_646 character otherwise. ;  To_ISO_646 : The function whose first formal parameter, Item, is of type String returns the String whose Range is 1..Item'Length and each of whose elements is given by To_ISO_646 of the corresponding element in Item. The following set of functions test Wide_Character values for membership in Character, or convert between corresponding characters of Wide_Character and Character. ;  Is_Character : Returns True if Wide_Character'Pos(Item) <= Character'Pos(Character'Last). ;  Is_String : Returns True if Is_Character(Item(I)) is True for each I in Item'Range. ;  To_Character : Returns the Character corresponding to Item if Is_Character(Item), and returns the Substitute Character otherwise. ;  To_String : Returns the String whose range is 1..Item'Length and each of whose elements is given by To_Character of the corresponding element in Item. ;  To_Wide_Character : Returns the Wide_Character X such that Character'Pos(Item) = Wide_Character'Pos(X). ;  To_Wide_String : Returns the Wide_String whose range is 1..Item'Length and each of whose elements is given by To_Wide_Character of the corresponding element in Item. == Implementation Advice == If an implementation provides a localized definition of Character or Wide_Character, then the effects of the subprograms in Characters.Handling should reflect the localizations. See also [[Guide:95lrm/RM-3-5-2|3.5.2]]. == Notes == 5  A basic letter is a letter without a diacritical mark. 6  Except for the hexadecimal digits, basic letters, and ISO_646 characters, the categories identified in the classification functions form a strict hierarchy: <p><span></span></p> ::-- Control characters <p><span></span></p> ::-- Graphic characters <p><span></span></p> :::-- Alphanumeric characters <p><span></span></p> ::::-- Letters <p><span></span></p> :::::-- Upper-case letters <p><span></span></p> :::::-- Lower-case letters <p><span></span></p> ::::-- Decimal digits <p><span></span></p> :::-- Special graphic characters </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-3-1|Previous]] | [[Guide:95lrm/RM-A-3-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 7mukb1lc1gokwi5rnrwcuhga3dy8n0o Guide:95lrm/RM-A-3-3 4200 1091 4363 2019-05-01T12:55:39Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-3-2|Previous]] | [[Guide:95lrm/RM-A-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.3.3 The Package Characters.Latin_1}} The package Characters.Latin_1 declares constants for characters in ISO 8859-1. == Static Semantics == The library package Characters.Latin_1 has the following declaration: <p><syntaxhighlight lang="Ada"> package Ada.Characters.Latin_1 is  pragma Pure(Latin_1);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- Control characters:</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">  NUL                  : constant Character := Character'Val(0);  SOH                  : constant Character := Character'Val(1);  STX                  : constant Character := Character'Val(2);  ETX                  : constant Character := Character'Val(3);  EOT                  : constant Character := Character'Val(4);  ENQ                  : constant Character := Character'Val(5);  ACK                  : constant Character := Character'Val(6);  BEL                  : constant Character := Character'Val(7);  BS                   : constant Character := Character'Val(8);  HT                   : constant Character := Character'Val(9);  LF                   : constant Character := Character'Val(10);  VT                   : constant Character := Character'Val(11);  FF                   : constant Character := Character'Val(12);  CR                   : constant Character := Character'Val(13);  SO                   : constant Character := Character'Val(14);  SI                   : constant Character := Character'Val(15);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">  DLE                  : constant Character := Character'Val(16);  DC1                  : constant Character := Character'Val(17);  DC2                  : constant Character := Character'Val(18);  DC3                  : constant Character := Character'Val(19);  DC4                  : constant Character := Character'Val(20);  NAK                  : constant Character := Character'Val(21);  SYN                  : constant Character := Character'Val(22);  ETB                  : constant Character := Character'Val(23);  CAN                  : constant Character := Character'Val(24);  EM                   : constant Character := Character'Val(25);  SUB                  : constant Character := Character'Val(26);  ESC                  : constant Character := Character'Val(27);  FS                   : constant Character := Character'Val(28);  GS                   : constant Character := Character'Val(29);  RS                   : constant Character := Character'Val(30);  US                   : constant Character := Character'Val(31);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- ISO 646 graphic characters:</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">  Space                : constant Character := ' ';  -- Character'Val(32)  Exclamation          : constant Character := '!';  -- Character'Val(33)  Quotation            : constant Character := '"';  -- Character'Val(34)  Number_Sign          : constant Character := '#';  -- Character'Val(35)  Dollar_Sign          : constant Character := '$';  -- Character'Val(36)  Percent_Sign         : constant Character := '%';  -- Character'Val(37)  Ampersand            : constant Character := '&';  -- Character'Val(38)  Apostrophe           : constant Character := ''';  -- Character'Val(39)  Left_Parenthesis     : constant Character := '(';  -- Character'Val(40)  Right_Parenthesis    : constant Character := ')';  -- Character'Val(41)  Asterisk             : constant Character := '*';  -- Character'Val(42)  Plus_Sign            : constant Character := '+';  -- Character'Val(43)  Comma                : constant Character := ',';  -- Character'Val(44)  Hyphen               : constant Character := '-';  -- Character'Val(45)  Minus_Sign           : Character renames Hyphen;  Full_Stop            : constant Character := '.';  -- Character'Val(46)  Solidus              : constant Character := '/';  -- Character'Val(47) </syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     -- Decimal digits '0' though '9' are at positions 48 through 57</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">  Colon                : constant Character := ':';  -- Character'Val(58)  Semicolon            : constant Character := ';';  -- Character'Val(59)  Less_Than_Sign       : constant Character := '<';  -- Character'Val(60)  Equals_Sign          : constant Character := '=';  -- Character'Val(61)  Greater_Than_Sign    : constant Character := '>';  -- Character'Val(62)  Question             : constant Character := '?';  -- Character'Val(63)  Commercial_At        : constant Character := '@';  -- Character'Val(64) </syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     -- Letters 'A' through 'Z' are at positions 65 through 90</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   Left_Square_Bracket  : constant Character := '[';  -- Character'Val(91)  Reverse_Solidus      : constant Character := '\';  -- Character'Val(92)  Right_Square_Bracket : constant Character := ']';  -- Character'Val(93)  Circumflex           : constant Character := '^';  -- Character'Val(94)  Low_Line             : constant Character := '_';  -- Character'Val(95) </syntaxhighlight></p> <p><syntaxhighlight lang="Ada">  Grave                : constant Character := '`';  -- Character'Val(96)  LC_A                 : constant Character := 'a';  -- Character'Val(97)  LC_B                 : constant Character := 'b';  -- Character'Val(98)  LC_C                 : constant Character := 'c';  -- Character'Val(99)  LC_D                 : constant Character := 'd';  -- Character'Val(100)  LC_E                 : constant Character := 'e';  -- Character'Val(101)  LC_F                 : constant Character := 'f';  -- Character'Val(102)  LC_G                 : constant Character := 'g';  -- Character'Val(103)  LC_H                 : constant Character := 'h';  -- Character'Val(104)  LC_I                 : constant Character := 'i';  -- Character'Val(105)  LC_J                 : constant Character := 'j';  -- Character'Val(106)  LC_K                 : constant Character := 'k';  -- Character'Val(107)  LC_L                 : constant Character := 'l';  -- Character'Val(108)  LC_M                 : constant Character := 'm';  -- Character'Val(109)  LC_N                 : constant Character := 'n';  -- Character'Val(110)  LC_O                 : constant Character := 'o';  -- Character'Val(111) </syntaxhighlight></p> <p><syntaxhighlight lang="Ada">  LC_P                 : constant Character := 'p';  -- Character'Val(112)  LC_Q                 : constant Character := 'q';  -- Character'Val(113)  LC_R                 : constant Character := 'r';  -- Character'Val(114)  LC_S                 : constant Character := 's';  -- Character'Val(115)  LC_T                 : constant Character := 't';  -- Character'Val(116)  LC_U                 : constant Character := 'u';  -- Character'Val(117)  LC_V                 : constant Character := 'v';  -- Character'Val(118)  LC_W                 : constant Character := 'w';  -- Character'Val(119)  LC_X                 : constant Character := 'x';  -- Character'Val(120)  LC_Y                 : constant Character := 'y';  -- Character'Val(121)  LC_Z                 : constant Character := 'z';  -- Character'Val(122)  Left_Curly_Bracket   : constant Character := '{';  -- Character'Val(123)  Vertical_Line        : constant Character := '|';  -- Character'Val(124)  Right_Curly_Bracket  : constant Character := '}';  -- Character'Val(125)  Tilde                : constant Character := '~';  -- Character'Val(126)  DEL                  : constant Character := Character'Val(127);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- ISO 6429 control characters:</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   IS4                  : Character renames FS;  IS3                  : Character renames GS;  IS2                  : Character renames RS;  IS1                  : Character renames US;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">  Reserved_128         : constant Character := Character'Val(128);  Reserved_129         : constant Character := Character'Val(129);  BPH                  : constant Character := Character'Val(130);  NBH                  : constant Character := Character'Val(131);  Reserved_132         : constant Character := Character'Val(132);  NEL                  : constant Character := Character'Val(133);  SSA                  : constant Character := Character'Val(134);  ESA                  : constant Character := Character'Val(135);  HTS                  : constant Character := Character'Val(136);  HTJ                  : constant Character := Character'Val(137);  VTS                  : constant Character := Character'Val(138);  PLD                  : constant Character := Character'Val(139);  PLU                  : constant Character := Character'Val(140);  RI                   : constant Character := Character'Val(141);  SS2                  : constant Character := Character'Val(142);  SS3                  : constant Character := Character'Val(143);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">  DCS                  : constant Character := Character'Val(144);  PU1                  : constant Character := Character'Val(145);  PU2                  : constant Character := Character'Val(146);  STS                  : constant Character := Character'Val(147);  CCH                  : constant Character := Character'Val(148);  MW                   : constant Character := Character'Val(149);  SPA                  : constant Character := Character'Val(150);  EPA                  : constant Character := Character'Val(151);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">  SOS                  : constant Character := Character'Val(152);  Reserved_153         : constant Character := Character'Val(153);  SCI                  : constant Character := Character'Val(154);  CSI                  : constant Character := Character'Val(155);  ST                   : constant Character := Character'Val(156);  OSC                  : constant Character := Character'Val(157);  PM                   : constant Character := Character'Val(158);  APC                  : constant Character := Character'Val(159);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- Other graphic characters:</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- Character positions 160 (16#A0#) .. 175 (16#AF#):  No_Break_Space              : constant Character := ' ';  --Character'Val(160)  NBSP                        : Character renames No_Break_Space;  Inverted_Exclamation        : constant Character := '¡';  --Character'Val(161)  Cent_Sign                   : constant Character := '¢';  --Character'Val(162)  Pound_Sign                  : constant Character := '£';  --Character'Val(163)  Currency_Sign               : constant Character := '¤';  --Character'Val(164)  Yen_Sign                    : constant Character := '¥';  --Character'Val(165)  Broken_Bar                  : constant Character := '¦';  --Character'Val(166)  Section_Sign                : constant Character := '§';  --Character'Val(167)  Diaeresis                   : constant Character := '¨';  --Character'Val(168)  Copyright_Sign              : constant Character := '©';  --Character'Val(169)  Feminine_Ordinal_Indicator  : constant Character := 'ª';  --Character'Val(170)  Left_Angle_Quotation        : constant Character := '«';  --Character'Val(171)  Not_Sign                    : constant Character := '¬';  --Character'Val(172)  Soft_Hyphen                 : constant Character := '­';  --Character'Val(173)  Registered_Trade_Mark_Sign  : constant Character := '®';  --Character'Val(174)  Macron                      : constant Character := '¯';  --Character'Val(175) </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- Character positions 176 (16#B0#) .. 191 (16#BF#):  Degree_Sign                 : constant Character := '°';  --Character'Val(176)  Ring_Above                  : Character renames Degree_Sign;  Plus_Minus_Sign             : constant Character := '±';  --Character'Val(177)  Superscript_Two             : constant Character := '²';  --Character'Val(178)  Superscript_Three           : constant Character := '³';  --Character'Val(179)  Acute                       : constant Character := '´';  --Character'Val(180)  Micro_Sign                  : constant Character := 'µ';  --Character'Val(181)  Pilcrow_Sign                : constant Character := '¶';  --Character'Val(182)  Paragraph_Sign              : Character renames Pilcrow_Sign;  Middle_Dot                  : constant Character := '·';  --Character'Val(183)  Cedilla                     : constant Character := '¸';  --Character'Val(184)  Superscript_One             : constant Character := '¹';  --Character'Val(185)  Masculine_Ordinal_Indicator : constant Character := 'º';  --Character'Val(186)  Right_Angle_Quotation       : constant Character := '»';  --Character'Val(187)  Fraction_One_Quarter        : constant Character := '¼';  --Character'Val(188)  Fraction_One_Half           : constant Character := '½';  --Character'Val(189)  Fraction_Three_Quarters     : constant Character := '¾';  --Character'Val(190)  Inverted_Question           : constant Character := '¿';  --Character'Val(191) </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- Character positions 192 (16#C0#) .. 207 (16#CF#):  UC_A_Grave                  : constant Character := 'À';  --Character'Val(192)  UC_A_Acute                  : constant Character := 'Á';  --Character'Val(193)  UC_A_Circumflex             : constant Character := 'Â';  --Character'Val(194)  UC_A_Tilde                  : constant Character := 'Ã';  --Character'Val(195)  UC_A_Diaeresis              : constant Character := 'Ä';  --Character'Val(196)  UC_A_Ring                   : constant Character := 'Å';  --Character'Val(197)  UC_AE_Diphthong             : constant Character := 'Æ';  --Character'Val(198)  UC_C_Cedilla                : constant Character := 'Ç';  --Character'Val(199)  UC_E_Grave                  : constant Character := 'È';  --Character'Val(200)  UC_E_Acute                  : constant Character := 'É';  --Character'Val(201)  UC_E_Circumflex             : constant Character := 'Ê';  --Character'Val(202)  UC_E_Diaeresis              : constant Character := 'Ë';  --Character'Val(203)  UC_I_Grave                  : constant Character := 'Ì';  --Character'Val(204)  UC_I_Acute                  : constant Character := 'Í';  --Character'Val(205)  UC_I_Circumflex             : constant Character := 'Î';  --Character'Val(206)  UC_I_Diaeresis              : constant Character := 'Ï';  --Character'Val(207) </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- Character positions 208 (16#D0#) .. 223 (16#DF#):  UC_Icelandic_Eth            : constant Character := 'Ð';  --Character'Val(208)  UC_N_Tilde                  : constant Character := 'Ñ';  --Character'Val(209)  UC_O_Grave                  : constant Character := 'Ò';  --Character'Val(210)  UC_O_Acute                  : constant Character := 'Ó';  --Character'Val(211)  UC_O_Circumflex             : constant Character := 'Ô';  --Character'Val(212)  UC_O_Tilde                  : constant Character := 'Õ';  --Character'Val(213)  UC_O_Diaeresis              : constant Character := 'Ö';  --Character'Val(214)  Multiplication_Sign         : constant Character := '×';  --Character'Val(215)  UC_O_Oblique_Stroke         : constant Character := 'Ø';  --Character'Val(216)  UC_U_Grave                  : constant Character := 'Ù';  --Character'Val(217)  UC_U_Acute                  : constant Character := 'Ú';  --Character'Val(218)  UC_U_Circumflex             : constant Character := 'Û';  --Character'Val(219)  UC_U_Diaeresis              : constant Character := 'Ü';  --Character'Val(220)  UC_Y_Acute                  : constant Character := 'Ý';  --Character'Val(221)  UC_Icelandic_Thorn          : constant Character := 'Þ';  --Character'Val(222)  LC_German_Sharp_S           : constant Character := 'ß';  --Character'Val(223) </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- Character positions 224 (16#E0#) .. 239 (16#EF#):  LC_A_Grave                  : constant Character := 'à';  --Character'Val(224)  LC_A_Acute                  : constant Character := 'á';  --Character'Val(225)  LC_A_Circumflex             : constant Character := 'â';  --Character'Val(226)  LC_A_Tilde                  : constant Character := 'ã';  --Character'Val(227)  LC_A_Diaeresis              : constant Character := 'ä';  --Character'Val(228)  LC_A_Ring                   : constant Character := 'å';  --Character'Val(229)  LC_AE_Diphthong             : constant Character := 'æ';  --Character'Val(230)  LC_C_Cedilla                : constant Character := 'ç';  --Character'Val(231)  LC_E_Grave                  : constant Character := 'è';  --Character'Val(232)  LC_E_Acute                  : constant Character := 'é';  --Character'Val(233)  LC_E_Circumflex             : constant Character := 'ê';  --Character'Val(234)  LC_E_Diaeresis              : constant Character := 'ë';  --Character'Val(235)  LC_I_Grave                  : constant Character := 'ì';  --Character'Val(236)  LC_I_Acute                  : constant Character := 'í';  --Character'Val(237)  LC_I_Circumflex             : constant Character := 'î';  --Character'Val(238)  LC_I_Diaeresis              : constant Character := 'ï';  --Character'Val(239) </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- Character positions 240 (16#F0#) .. 255 (16#FF#):  LC_Icelandic_Eth            : constant Character := 'ð';  --Character'Val(240)  LC_N_Tilde                  : constant Character := 'ñ';  --Character'Val(241)  LC_O_Grave                  : constant Character := 'ò';  --Character'Val(242)  LC_O_Acute                  : constant Character := 'ó';  --Character'Val(243)  LC_O_Circumflex             : constant Character := 'ô';  --Character'Val(244)  LC_O_Tilde                  : constant Character := 'õ';  --Character'Val(245)  LC_O_Diaeresis              : constant Character := 'ö';  --Character'Val(246)  Division_Sign               : constant Character := '÷';  --Character'Val(247)  LC_O_Oblique_Stroke         : constant Character := 'ø';  --Character'Val(248)  LC_U_Grave                  : constant Character := 'ù';  --Character'Val(249)  LC_U_Acute                  : constant Character := 'ú';  --Character'Val(250)  LC_U_Circumflex             : constant Character := 'û';  --Character'Val(251)  LC_U_Diaeresis              : constant Character := 'ü';  --Character'Val(252)  LC_Y_Acute                  : constant Character := 'ý';  --Character'Val(253)  LC_Icelandic_Thorn          : constant Character := 'þ';  --Character'Val(254)  LC_Y_Diaeresis              : constant Character := 'ÿ';  --Character'Val(255)end Ada.Chara cters.Latin_1;</syntaxhighlight></p> == Implementation Permissions == An implementation may provide additional packages as children of Ada.Characters, to declare names for the symbols of the local character set or other character sets. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-3-2|Previous]] | [[Guide:95lrm/RM-A-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 2zuflbx54n57qpau52azp5ieeruwrwf Guide:95lrm/RM-A-4 4200 1092 4364 2019-04-29T15:48:20Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-3-3|Previous]] | [[Guide:95lrm/RM-A-4-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.4 String Handling}} This clause presents the specifications of the package Strings and several child packages, which provide facilities for dealing with string data. Fixed-length, bounded-length, and unbounded-length strings are supported, for both String and Wide_String. The string-handling subprograms include searches for pattern strings and for characters in program-specified sets, translation (via a character-to-character mapping), and transformation (replacing, inserting, overwriting, and deleting of substrings). </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-3-3|Previous]] | [[Guide:95lrm/RM-A-4-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 39z8jec6tqu5ymn2mzjhelc4dngsyr5 Guide:95lrm/RM-A-4-1 4200 1093 4365 2019-05-01T12:57:14Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-4|Previous]] | [[Guide:95lrm/RM-A-4-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.4.1 The Package Strings}} The package Strings provides declarations common to the string handling packages. == Static Semantics == The library package Strings has the following declaration: <p><syntaxhighlight lang="Ada"> package Ada.Strings is pragma Pure(Strings);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Space      : constant Character      := ' '; Wide_Space : constant Wide_Character := ' ';</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Length_Error, Pattern_Error, Index_Error, Translation_Error : exception;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Alignment  is (Left, Right, Center); type Truncation is (Left, Right, Error); type Membership is (Inside, Outside); type Direction  is (Forward, Backward); type Trim_End   is (Left, Right, Both); end Ada.Strings;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-4|Previous]] | [[Guide:95lrm/RM-A-4-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} k9rv5pqaki5h56mosjihnm1smr9eqm0 Guide:95lrm/RM-A-4-2 4200 1094 4366 2019-05-01T14:07:17Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-4-1|Previous]] | [[Guide:95lrm/RM-A-4-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.4.2 The Package Strings.Maps}} The package Strings.Maps defines the types, operations, and other entities needed for character sets and character-to-character mappings. == Static Semantics == The library package Strings.Maps has the following declaration: <p><syntaxhighlight lang="Ada"> package Ada.Strings.Maps is pragma Preelaborate(Maps);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   -- Representation for a set of character values: type Character_Set is private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Null_Set : constant Character_Set;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Character_Range is   record      Low  : Character;      High : Character;   end record; -- Represents Character range Low..High</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Character_Ranges is array (Positive range <>) of Character_Range;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Set    (Ranges : in Character_Ranges)return Character_Set;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Set    (Span   : in Character_Range)return Character_Set;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Ranges (Set    : in Character_Set)  return Character_Ranges;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "="   (Left, Right : in Character_Set) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "not" (Right : in Character_Set)       return Character_Set; function "and" (Left, Right : in Character_Set) return Character_Set; function "or"  (Left, Right : in Character_Set) return Character_Set; function "xor" (Left, Right : in Character_Set) return Character_Set; function "-"   (Left, Right : in Character_Set) return Character_Set;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Is_In (Element : in Character;                 Set     : in Character_Set)     return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Is_Subset (Elements : in Character_Set;                     Set      : in Character_Set)     return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "<=" (Left  : in Character_Set;                Right : in Character_Set)     return Boolean renames Is_Subset;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Alternative representation for a set of character values: subtype Character_Sequence is String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Set (Sequence  : in Character_Sequence)return Character_Set;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Set (Singleton : in Character)     return Character_Set;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Sequence (Set  : in Character_Set) return Character_Sequence;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Representation for a character to character mapping: type Character_Mapping is private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Value (Map     : in Character_Mapping;                 Element : in Character)    return Character;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Identity : constant Character_Mapping;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Mapping (From, To : in Character_Sequence)    return Character_Mapping;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Domain (Map : in Character_Mapping)    return Character_Sequence; function To_Range  (Map : in Character_Mapping)    return Character_Sequence;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Character_Mapping_Function is    access function (From : in Character) return Character;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> private ... -- not specified by the language end Ada.Strings.Maps;</syntaxhighlight></p> An object of type Character_Set represents a set of characters. Null_Set represents the set containing no characters. An object Obj of type Character_Range represents the set of characters in the range Obj.Low .. Obj.High. An object Obj of type Character_Ranges represents the union of the sets corresponding to Obj(I) for I in Obj'Range. <p><syntaxhighlight lang="Ada"> function To_Set (Ranges : in Character_Ranges) return Character_Set;</syntaxhighlight></p> <p><span></span></p> :If Ranges'Length=0 then Null_Set is returned; otherwise the returned value represents the set corresponding to Ranges. <p><syntaxhighlight lang="Ada"> function To_Set (Span : in Character_Range) return Character_Set;</syntaxhighlight></p> <p><span></span></p> :The returned value represents the set containing each character in Span. <p><syntaxhighlight lang="Ada"> function To_Ranges (Set : in Character_Set) return Character_Ranges;</syntaxhighlight></p> <p><span></span></p> :If Set = Null_Set then an empty Character_Ranges array is returned; otherwise the shortest array of contiguous ranges of Character values in Set, in increasing order of Low, is returned. <p><syntaxhighlight lang="Ada"> function "=" (Left, Right : in Character_Set) return Boolean;</syntaxhighlight></p> <p><span></span></p> :The function "=" returns True if Left and Right represent identical sets, and False otherwise. Each of the logical operators "'''not'''", "'''and'''", "'''or'''", and "'''xor'''" returns a Character_Set value that represents the set obtained by applying the corresponding operation to the set(s) represented by the parameter(s) of the operator. "-"(Left, Right) is equivalent to "and"(Left, "not"(Right)). <p><syntaxhighlight lang="Ada"> function Is_In (Element : in Character;              Set     : in Character_Set); return Boolean;</syntaxhighlight></p> <p><span></span></p> :Is_In returns True if Element is in Set, and False otherwise. <p><syntaxhighlight lang="Ada"> function Is_Subset (Elements : in Character_Set;                  Set      : in Character_Set) return Boolean;</syntaxhighlight></p> <p><span></span></p> :Is_Subset returns True if Elements is a subset of Set, and False otherwise. <p><syntaxhighlight lang="Ada"> subtype Character_Sequence is String;</syntaxhighlight></p> <p><span></span></p> :The Character_Sequence subtype is used to portray a set of character values and also to identify the domain and range of a character mapping. <p><syntaxhighlight lang="Ada"> function To_Set (Sequence  : in Character_Sequence) return Character_Set;function To_Set (Singleton : in Character)          return Character_Set;</syntaxhighlight></p> <p><span></span></p> :Sequence portrays the set of character values that it explicitly contains (ignoring duplicates). Singleton portrays the set comprising a single Character. Each of the To_Set functions returns a Character_Set value that represents the set portrayed by Sequence or Singleton. <p><syntaxhighlight lang="Ada"> function To_Sequence (Set : in Character_Set) return Character_Sequence;</syntaxhighlight></p> <p><span></span></p> :The function To_Sequence returns a Character_Sequence value containing each of the characters in the set represented by Set, in ascending order with no duplicates. <p><syntaxhighlight lang="Ada"> type Character_Mapping is private;</syntaxhighlight></p> <p><span></span></p> :An object of type Character_Mapping represents a Character-to-Character mapping. <p><syntaxhighlight lang="Ada"> function Value (Map     : in Character_Mapping;              Element : in Character) return Character;</syntaxhighlight></p> <p><span></span></p> :The function Value returns the Character value to which Element maps with respect to the mapping represented by Map. <span id="I4938"></span>A character C ''matches'' a pattern character P with respect to a given Character_Mapping value Map if Value(Map, C) = P. <span id="I4939"></span>A string S ''matches'' a pattern string P with respect to a given Character_Mapping if their lengths are the same and if each character in S matches its corresponding character in the pattern string P. String handling subprograms that deal with character mappings have parameters whose type is Character_Mapping. <p><syntaxhighlight lang="Ada"> Identity : constant Character_Mapping;</syntaxhighlight></p> <p><span></span></p> :Identity maps each Character to itself. <p><syntaxhighlight lang="Ada"> function To_Mapping (From, To : in Character_Sequence)  return Character_Mapping;</syntaxhighlight></p> <p><span></span></p> :To_Mapping produces a Character_Mapping such that each element of From maps to the corresponding element of To, and each other character maps to itself. If From'Length /= To'Length, or if some character is repeated in From, then Translation_Error is propagated. <p><syntaxhighlight lang="Ada"> function To_Domain (Map : in Character_Mapping) return Character_Sequence;</syntaxhighlight></p> <p><span></span></p> :To_Domain returns the shortest Character_Sequence value D such that each character not in D maps to itself, and such that the characters in D are in ascending order. The lower bound of D is 1. <p><syntaxhighlight lang="Ada"> function To_Range  (Map : in Character_Mapping) return Character_Sequence;</syntaxhighlight></p> <p><span></span></p> :To_Range returns the Character_Sequence value R, such that if D = To_Domain(Map), then R has the same bounds as D, and D(I) maps to R(I) for each I in D'Range. An object F of type Character_Mapping_Function maps a Character value C to the Character value F.'''all'''(C), which is said to ''match'' C with respect to mapping function F. <span id="I4940"></span> == Notes == 7  Character_Mapping and Character_Mapping_Function are used both for character equivalence mappings in the search subprograms (such as for case insensitivity) and as transformational mappings in the Translate subprograms. 8  To_Domain(Identity) and To_Range(Identity) each returns the null string. == Examples == To_Mapping("ABCD", "ZZAB") returns a Character_Mapping that maps 'A' and 'B' to 'Z', 'C' to 'A', 'D' to 'B', and each other Character to itself. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-4-1|Previous]] | [[Guide:95lrm/RM-A-4-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} d2j1b9z55r0w051dxavohamtsfqkbl3 Guide:95lrm/RM-A-4-3 4200 1095 4367 2019-05-01T14:55:47Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-4-2|Previous]] | [[Guide:95lrm/RM-A-4-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.4.3 Fixed-Length String Handling}} The language-defined package Strings.Fixed provides string-handling subprograms for fixed-length strings; that is, for values of type Standard.String. Several of these subprograms are procedures that modify the contents of a String that is passed as an '''out''' or an '''in''' '''out''' parameter; each has additional parameters to control the effect when the logical length of the result differs from the parameter's length. For each function that returns a String, the lower bound of the returned value is 1. The basic model embodied in the package is that a fixed-length string comprises significant characters and possibly padding (with space characters) on either or both ends. When a shorter string is copied to a longer string, padding is inserted, and when a longer string is copied to a shorter one, padding is stripped. The Move procedure in Strings.Fixed, which takes a String as an '''out''' parameter, allows the programmer to control these effects. Similar control is provided by the string transformation procedures. == Static Semantics == The library package Strings.Fixed has the following declaration: <p><syntaxhighlight lang="Ada"> with Ada.Strings.Maps; package Ada.Strings.Fixed is pragma Preelaborate(Fixed);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- "Copy" procedure for strings of possibly different lengths</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Move (Source  : in  String;                 Target  : out String;                 Drop    : in  Truncation := Error;                 Justify : in  Alignment  := Left;                 Pad     : in  Character  := Space);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- Search subprograms</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Index (Source   : in String;                 Pattern  : in String;                 Going    : in Direction := Forward;                 Mapping  : in Maps.Character_Mapping                              := Maps.Identity)    return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Index (Source   : in String;                 Pattern  : in String;                Going    : in Direction := Forward;                 Mapping  : in Maps.Character_Mapping_Function)     return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Index (Source : in String;                 Set    : in Maps.Character_Set;                 Test   : in Membership := Inside;                 Going  : in Direction  := Forward)     return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Index_Non_Blank (Source : in String;                           Going  : in Direction := Forward) return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Count (Source   : in String;                 Pattern  : in String;                 Mapping  : in Maps.Character_Mapping                             := Maps.Identity) return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function Count (Source   : in String;                 Pattern  : in String;                 Mapping  : in Maps.Character_Mapping_Function)    return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function Count (Source   : in String;                 Set      : in Maps.Character_Set)    return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   procedure Find_Token (Source : in String;                       Set    : in Maps.Character_Set;                       Test   : in Membership;                       First  : out Positive;                       Last   : out Natural);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- String translation subprograms</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Translate (Source  : in String;                      Mapping : in Maps.Character_Mapping) return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Translate (Source  : in out String;                      Mapping : in Maps.Character_Mapping);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Translate (Source  : in String;                      Mapping : in Maps.Character_Mapping_Function)    return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Translate (Source  : in out String;                      Mapping : in Maps.Character_Mapping_Function);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- String transformation subprograms</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Replace_Slice (Source   : in String;                         Low      : in Positive;                         High     : in Natural;                         By       : in String)    return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Replace_Slice (Source   : in out String;                          Low      : in Positive;                          High     : in Natural;                          By       : in String;                          Drop     : in Truncation := Error;                          Justify  : in Alignment  := Left;                          Pad      : in Character  := Space);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Insert (Source   : in String;                  Before   : in Positive;                  New_Item : in String)    return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Insert (Source   : in out String;                   Before   : in Positive;                   New_Item : in String;                   Drop     : in Truncation := Error);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Overwrite (Source   : in String;                     Position : in Positive;                     New_Item : in String)    return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     procedure Overwrite (Source   : in out String;                      Position : in Positive;                      New_Item : in String;                      Drop     : in Truncation := Right);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     function Delete (Source  : in String;                  From    : in Positive;                  Through : in Natural)    return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     procedure Delete (Source  : in out String;                   From    : in Positive;                   Through : in Natural;                   Justify : in Alignment := Left;                   Pad     : in Character := Space);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   --String selector subprograms function Trim (Source : in String;                Side   : in Trim_End)    return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   procedure Trim (Source  : in out String;                 Side    : in Trim_End;                 Justify : in Alignment := Left;                 Pad     : in Character := Space);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function Trim (Source : in String;                Left   : in Maps.Character_Set;                Right  : in Maps.Character_Set)    return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   procedure Trim (Source  : in out String;                 Left    : in Maps.Character_Set;                 Right   : in Maps.Character_Set;                 Justify : in Alignment := Strings.Left;                 Pad     : in Character := Space);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Head (Source : in String;                Count  : in Natural;                Pad    : in Character := Space)    return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Head (Source  : in out String;                 Count   : in Natural;                 Justify : in Alignment := Left;                 Pad     : in Character := Space);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Tail (Source : in String;               Count  : in Natural;                Pad    : in Character := Space)    return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Tail (Source  : in out String;                 Count   : in Natural;                 Justify : in Alignment := Left;                 Pad     : in Character := Space);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> --String constructor functions</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "*" (Left  : in Natural;               Right : in Character)  return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "*" (Left  : in Natural;               Right : in String)  return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> end Ada.Strings.Fixed;</syntaxhighlight></p> The effects of the above subprograms are as follows. <p><syntaxhighlight lang="Ada"> procedure Move (Source  : in  String;              Target  : out String;              Drop    : in  Truncation := Error;              Justify : in  Alignment  := Left;              Pad     : in  Character  := Space);</syntaxhighlight></p> <p><span></span></p> :The Move procedure copies characters from Source to Target. If Source has the same length as Target, then the effect is to assign Source to Target. If Source is shorter than Target then: <p><span></span></p> :* If Justify=Left, then Source is copied into the first Source'Length characters of Target. <p><span></span></p> :* If Justify=Right, then Source is copied into the last Source'Length characters of Target. <p><span></span></p> :* If Justify=Center, then Source is copied into the middle Source'Length characters of Target. In this case, if the difference in length between Target and Source is odd, then the extra Pad character is on the right. <p><span></span></p> :* Pad is copied to each Target character not otherwise assigned. <p><span></span></p> :If Source is longer than Target, then the effect is based on Drop. <p><span></span></p> :* If Drop=Left, then the rightmost Target'Length characters of Source are copied into Target. <p><span></span></p> :* If Drop=Right, then the leftmost Target'Length characters of Source are copied into Target. <p><span></span></p> :* If Drop=Error, then the effect depends on the value of the Justify parameter and also on whether any characters in Source other than Pad would fail to be copied: <p><span></span></p> ::* If Justify=Left, and if each of the rightmost Source'Length-Target'Length characters in Source is Pad, then the leftmost Target'Length characters of Source are copied to Target. <p><span></span></p> ::* If Justify=Right, and if each of the leftmost Source'Length-Target'Length characters in Source is Pad, then the rightmost Target'Length characters of Source are copied to Target. <p><span></span></p> ::* Otherwise, Length_Error is propagated. <p><syntaxhighlight lang="Ada"> function Index (Source   : in String;              Pattern  : in String;              Going    : in Direction := Forward;              Mapping  : in Maps.Character_Mapping                            := Maps.Identity) return Natural; function Index (Source   : in String;              Pattern  : in String;              Going    : in Direction := Forward;              Mapping  : in Maps.Character_Mapping_Function) return Natural;</syntaxhighlight></p> <p><span></span></p> :Each Index function searches for a slice of Source, with length Pattern'Length, that matches Pattern with respect to Mapping; the parameter Going indicates the direction of the lookup. If Going = Forward, then Index returns the smallest index I such that the slice of Source starting at I matches Pattern. If Going = Backward, then Index returns the largest index I such that the slice of Source starting at I matches Pattern. If there is no such slice, then 0 is returned. If Pattern is the null string then Pattern_Error is propagated. <p><syntaxhighlight lang="Ada"> function Index (Source : in String;              Set    : in Maps.Character_Set;              Test   : in Membership := Inside;              Going  : in Direction  := Forward) return Natural;</syntaxhighlight></p> <p><span></span></p> :Index searches for the first or last occurrence of any of a set of characters (when Test=Inside), or any of the complement of a set of characters (when Test=Outside). It returns the smallest index I (if Going=Forward) or the largest index I (if Going=Backward) such that Source(I) satisfies the Test condition with respect to Set; it returns 0 if there is no such Character in Source. <p><syntaxhighlight lang="Ada"> function Index_Non_Blank (Source : in String;                        Going  : in Direction := Forward) return Natural;</syntaxhighlight></p> <p><span></span></p> :Returns Index(Source, Maps.To_Set(Space), Outside, Going) <p><syntaxhighlight lang="Ada"> function Count (Source   : in String;              Pattern  : in String;              Mapping  : in Maps.Character_Mapping                           := Maps.Identity) return Natural; function Count (Source   : in String;              Pattern  : in String;              Mapping  : in Maps.Character_Mapping_Function) return Natural;</syntaxhighlight></p> <p><span></span></p> :Returns the maximum number of nonoverlapping slices of Source that match Pattern with respect to Mapping. If Pattern is the null string then Pattern_Error is propagated. <p><syntaxhighlight lang="Ada"> function Count (Source   : in String;              Set      : in Maps.Character_Set) return Natural;</syntaxhighlight></p> <p><span></span></p> :Returns the number of occurrences in Source of characters that are in Set. <p><syntaxhighlight lang="Ada"> procedure Find_Token (Source : in String;                    Set    : in Maps.Character_Set;                    Test   : in Membership;                    First  : out Positive;                    Last   : out Natural);</syntaxhighlight></p> <p><span></span></p> :Find_Token returns in First and Last the indices of the beginning and end of the first slice of Source all of whose elements satisfy the Test condition, and such that the elements (if any) immediately before and after the slice do not satisfy the Test condition. If no such slice exists, then the value returned for Last is zero, and the value returned for First is Source'First; however, if Source'First is not in Positive then Constraint_Error <span id="I5002"></span>is raised. <p><syntaxhighlight lang="Ada"> function Translate (Source  : in String;                  Mapping : in Maps.Character_Mapping) return String; function Translate (Source  : in String;                  Mapping : in Maps.Character_Mapping_Function) return String;</syntaxhighlight></p> Returns the string S whose length is Source'Length and such that S(I) is the character to which Mapping maps the corresponding element of Source, for I in 1..Source'Length. <p><syntaxhighlight lang="Ada"> procedure Translate (Source  : in out String;                   Mapping : in Maps.Character_Mapping); procedure Translate (Source  : in out String;                   Mapping : in Maps.Character_Mapping_Function);</syntaxhighlight></p> <p><span></span></p> :Equivalent to Source := Translate(Source, Mapping). <p><syntaxhighlight lang="Ada"> function Replace_Slice (Source   : in String;                     Low      : in Positive;                      High     : in Natural;                      By       : in String) return String;</syntaxhighlight></p> <p><span></span></p> :If Low > Source'Last+1, or High < Source'First-1, then Index_Error is propagated. Otherwise: ::* If High >= Low, then the returned string comprises Source(Source'First..Low-1) & By & Source(High+1..Source'Last), but with lower bound 1. ::* If High < Low, then the returned string is Insert(Source, Before=>Low, New_Item=>By). <p><syntaxhighlight lang="Ada"> procedure Replace_Slice (Source   : in out String;                       Low      : in Positive;                       High     : in Natural;                       By       : in String;                       Drop     : in Truncation := Error;                       Justify  : in Alignment  := Left;                       Pad      : in Character  := Space);</syntaxhighlight></p> <p><span></span></p> :Equivalent to Move(Replace_Slice(Source, Low, High, By), Source, Drop, Justify, Pad). <p><syntaxhighlight lang="Ada"> function Insert (Source   : in String;               Before   : in Positive;               New_Item : in String) return String;</syntaxhighlight></p> <p><span></span></p> :Propagates Index_Error if Before is not in Source'First .. Source'Last+1; otherwise returns Source(Source'First..Before-1) & New_Item & Source(Before..Source'Last), but with lower bound 1. <p><syntaxhighlight lang="Ada"> procedure Insert (Source   : in out String;                Before   : in Positive;                New_Item : in String;                Drop     : in Truncation := Error);</syntaxhighlight></p> <p><span></span></p> :Equivalent to Move(Insert(Source, Before, New_Item), Source, Drop). <p><syntaxhighlight lang="Ada"> function Overwrite (Source   : in String;                  Position : in Positive;                  New_Item : in String) return String;</syntaxhighlight></p> <p><span></span></p> :Propagates Index_Error if Position is not in Source'First .. Source'Last+1; otherwise returns the string obtained from Source by consecutively replacing characters starting at Position with corresponding characters from New_Item. If the end of Source is reached before the characters in New_Item are exhausted, the remaining characters from New_Item are appended to the string. <p><syntaxhighlight lang="Ada"> procedure Overwrite (Source   : in out String;                   Position : in Positive;                   New_Item : in String;                   Drop     : in Truncation := Right);</syntaxhighlight></p> <p><span></span></p> :Equivalent to Move(Overwrite(Source, Position, New_Item), Source, Drop). <p><syntaxhighlight lang="Ada"> function Delete (Source  : in String;               From    : in Positive;               Through : in Natural) return String;</syntaxhighlight></p> <p><span></span></p> :If From <= Through, the returned string is Replace_Slice(Source, From, Through, ""), otherwise it is Source with lower bound 1. <p><syntaxhighlight lang="Ada"> procedure Delete (Source  : in out String;                From    : in Positive;                Through : in Natural;                Justify : in Alignment := Left;                Pad     : in Character := Space);</syntaxhighlight></p> <p><span></span></p> :Equivalent to Move(Delete(Source, From, Through), Source, Justify => Justify, Pad => Pad). <p><syntaxhighlight lang="Ada"> function Trim (Source : in String;             Side   : in Trim_End)   return String;</syntaxhighlight></p> <p><span></span></p> :Returns the string obtained by removing from Source all leading Space characters (if Side = Left), all trailing Space characters (if Side = Right), or all leading and trailing Space characters (if Side = Both). <p><syntaxhighlight lang="Ada"> procedure Trim (Source  : in out String;              Side    : in Trim_End;              Justify : in Alignment := Left;              Pad     : in Character := Space);</syntaxhighlight></p> <p><span></span></p> :Equivalent to Move(Trim(Source, Side), Source, Justify=>Justify, Pad=>Pad). <p><syntaxhighlight lang="Ada"> function Trim (Source : in String;             Left   : in Maps.Character_Set;              Right  : in Maps.Character_Set) return String;</syntaxhighlight></p> <p><span></span></p> :Returns the string obtained by removing from Source all leading characters in Left and all trailing characters in Right. <p><syntaxhighlight lang="Ada">procedure Trim (Source  : in out String;              Left    : in Maps.Character_Set;              Right   : in Maps.Character_Set;              Justify : in Alignment := Strings.Left;              Pad     : in Character := Space);</syntaxhighlight></p> <p><span></span></p> :Equivalent to Move(Trim(Source, Left, Right), Source, Justify => Justify, Pad=>Pad). <p><syntaxhighlight lang="Ada"> function Head (Source : in String;             Count  : in Natural;             Pad    : in Character := Space) return String;</syntaxhighlight></p> <p><span></span></p> :Returns a string of length Count. If Count <= Source'Length, the string comprises the first Count characters of Source. Otherwise its contents are Source concatenated with Count-Source'Length Pad characters. <p><syntaxhighlight lang="Ada"> procedure Head (Source  : in out String;              Count   : in Natural;              Justify : in Alignment := Left;              Pad     : in Character := Space);</syntaxhighlight></p> <p><span></span></p> :Equivalent to Move(Head(Source, Count, Pad), Source, Drop=>Error, Justify=>Justify, Pad=>Pad). <p><syntaxhighlight lang="Ada"> function Tail (Source : in String;             Count  : in Natural;             Pad    : in Character := Space) return String;</syntaxhighlight></p> <p><span></span></p> :Returns a string of length Count. If Count <= Source'Length, the string comprises the last Count characters of Source. Otherwise its contents are Count-Source'Length Pad characters concatenated with Source. <p><syntaxhighlight lang="Ada"> procedure Tail (Source  : in out String;             Count   : in Natural;              Justify : in Alignment := Left;              Pad     : in Character := Space);</syntaxhighlight></p> <p><span></span></p> :Equivalent to Move(Tail(Source, Count, Pad), Source, Drop=>Error, Justify=>Justify, Pad=>Pad). <p><syntaxhighlight lang="Ada"> function "*" (Left  : in Natural;        Right : in Character) return String; function "*" (Left  : in Natural;            Right : in String) return String;</syntaxhighlight></p> <p><span></span></p> :These functions replicate a character or string a specified number of times. The first function returns a string whose length is Left and each of whose elements is Right. The second function returns a string whose length is Left*Right'Length and whose value is the null string if Left = 0 and otherwise is (Left-1)*Right & Right with lower bound 1. == Notes == 9  In the Index and Count functions taking Pattern and Mapping parameters, the actual String parameter passed to Pattern should comprise characters occurring as target characters of the mapping. Otherwise the pattern will not match. 10  In the Insert subprograms, inserting at the end of a string is obtained by passing Source'Last+1 as the Before parameter. 11  <span id="I5003"></span>If a null Character_Mapping_Function is passed to any of the string handling subprograms, Constraint_Error is propagated. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-4-2|Previous]] | [[Guide:95lrm/RM-A-4-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} cmkpqvyb4slodllykvbw3ch8zc6xri5 Guide:95lrm/RM-A-4-4 4200 1096 4368 2019-05-01T15:23:22Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-4-3|Previous]] | [[Guide:95lrm/RM-A-4-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.4.4 Bounded-Length String Handling}} The language-defined package Strings.Bounded provides a generic package each of whose instances yields a private type Bounded_String and a set of operations. An object of a particular Bounded_String type represents a String whose low bound is 1 and whose length can vary conceptually between 0 and a maximum size established at the generic instantiation. The subprograms for fixed-length string handling are either overloaded directly for Bounded_String, or are modified as needed to reflect the variability in length. Additionally, since the Bounded_String type is private, appropriate constructor and selector operations are provided. == Static Semantics == The library package Strings.Bounded has the following declaration: <p><syntaxhighlight lang="Ada"> with Ada.Strings.Maps; package Ada.Strings.Bounded is pragma Preelaborate(Bounded);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    generic    Max   : Positive;    -- Maximum length of a Bounded_String package Generic_Bounded_Length is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       Max_Length : constant Positive := Max;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       type Bounded_String is private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       Null_Bounded_String : constant Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       subtype Length_Range is Natural range 0 .. Max_Length;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Length (Source : in Bounded_String) return Length_Range;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Conversion, Concatenation, and Selection functions</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function To_Bounded_String (Source : in String;                                Drop   : in Truncation := Error)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function To_String (Source : in Bounded_String) return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Append (Left, Right : in Bounded_String;                     Drop        : in Truncation  := Error)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Append (Left  : in Bounded_String;                     Right : in String;                     Drop  : in Truncation := Error)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Append (Left  : in String;                     Right : in Bounded_String;                     Drop  : in Truncation := Error)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Append (Left  : in Bounded_String;                     Right : in Character;                     Drop  : in Truncation := Error)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Append (Left  : in Character;                     Right : in Bounded_String;                     Drop  : in Truncation := Error)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Append (Source   : in out Bounded_String;                      New_Item : in Bounded_String;                      Drop     : in Truncation  := Error);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Append (Source   : in out Bounded_String;                      New_Item : in String;                      Drop     : in Truncation  := Error);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Append (Source   : in out Bounded_String;                      New_Item : in Character;                      Drop     : in Truncation  := Error);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function "&" (Left, Right : in Bounded_String)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function "&" (Left : in Bounded_String; Right : in String)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function "&" (Left : in String; Right : in Bounded_String)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function "&" (Left : in Bounded_String; Right : in Character)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function "&" (Left : in Character; Right : in Bounded_String)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Element (Source : in Bounded_String;                      Index  : in Positive)       return Character;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Replace_Element (Source : in out Bounded_String;                               Index  : in Positive;                               By     : in Character);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Slice (Source : in Bounded_String;                    Low    : in Positive;                    High   : in Natural)       return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function "="  (Left, Right : in Bounded_String) return Boolean;    function "="  (Left : in Bounded_String; Right : in String)      return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function "="  (Left : in String; Right : in Bounded_String)      return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function "<"  (Left, Right : in Bounded_String)  return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function "<"  (Left : in Bounded_String; Right : in String)      return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function "<"  (Left : in String; Right : in Bounded_String)      return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function "<=" (Left, Right : in Bounded_String)  return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function "<="  (Left : in Bounded_String; Right : in String)      return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function "<="  (Left : in String; Right : in Bounded_String)       return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function ">"  (Left, Right : in Bounded_String)  return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function ">"  (Left : in Bounded_String; Right : in String)      return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function ">"  (Left : in String; Right : in Bounded_String)      return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function ">=" (Left, Right : in Bounded_String)  return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function ">="  (Left : in Bounded_String; Right : in String)      return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function ">="  (Left : in String; Right : in Bounded_String)      return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Search functions</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Index (Source   : in Bounded_String;                    Pattern  : in String;                    Going    : in Direction := Forward;                    Mapping  : in Maps.Character_Mapping                               := Maps.Identity)       return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Index (Source   : in Bounded_String;                    Pattern  : in String;                    Going    : in Direction := Forward;                    Mapping  : in Maps.Character_Mapping_Function)       return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Index (Source : in Bounded_String;                    Set    : in Maps.Character_Set;                    Test   : in Membership := Inside;                    Going  : in Direction  := Forward)       return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Index_Non_Blank (Source : in Bounded_String;                              Going  : in Direction := Forward)       return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Count (Source   : in Bounded_String;                    Pattern  : in String;                    Mapping  : in Maps.Character_Mapping                                 := Maps.Identity) return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Count (Source   : in Bounded_String;                    Pattern  : in String;                    Mapping  : in Maps.Character_Mapping_Function)       return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Count (Source   : in Bounded_String;                    Set      : in Maps.Character_Set)       return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Find_Token (Source : in Bounded_String;                          Set    : in Maps.Character_Set;                          Test   : in Membership;                          First  : out Positive;                          Last   : out Natural);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- String translation subprograms</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Translate (Source  : in Bounded_String;                        Mapping : in Maps.Character_Mapping)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Translate (Source  : in out Bounded_String;                         Mapping : in Maps.Character_Mapping);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Translate (Source  : in Bounded_String;                        Mapping : in Maps.Character_Mapping_Function)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Translate (Source  : in out Bounded_String;                         Mapping : in Maps.Character_Mapping_Function);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- String transformation subprograms</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Replace_Slice (Source   : in Bounded_String;                            Low      : in Positive;                            High     : in Natural;                            By       : in String;                            Drop     : in Truncation := Error)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Replace_Slice (Source   : in out Bounded_String;                             Low      : in Positive;                             High     : in Natural;                             By       : in String;                             Drop     : in Truncation := Error);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Insert (Source   : in Bounded_String;                     Before   : in Positive;                     New_Item : in String;                     Drop     : in Truncation := Error)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Insert (Source   : in out Bounded_String;                      Before   : in Positive;                      New_Item : in String;                      Drop     : in Truncation := Error);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Overwrite (Source    : in Bounded_String;                        Position  : in Positive;                        New_Item  : in String;                        Drop      : in Truncation := Error)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Overwrite (Source    : in out Bounded_String;                         Position  : in Positive;                         New_Item  : in String;                         Drop      : in Truncation := Error);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Delete (Source  : in Bounded_String;                     From    : in Positive;                     Through : in Natural)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Delete (Source  : in out Bounded_String;                      From    : in Positive;                      Through : in Natural);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> --String selector subprograms</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Trim (Source : in Bounded_String;                   Side   : in Trim_End)       return Bounded_String;    procedure Trim (Source : in out Bounded_String;                    Side   : in Trim_End);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Trim (Source : in Bounded_String;                   Left   : in Maps.Character_Set;                   Right  : in Maps.Character_Set)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Trim (Source : in out Bounded_String;                    Left   : in Maps.Character_Set;                    Right  : in Maps.Character_Set);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Head (Source : in Bounded_String;                   Count  : in Natural;                   Pad    : in Character  := Space;                   Drop   : in Truncation := Error)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Head (Source : in out Bounded_String;                    Count  : in Natural;                    Pad    : in Character  := Space;                    Drop   : in Truncation := Error);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Tail (Source : in Bounded_String;                   Count  : in Natural;                   Pad    : in Character  := Space;                   Drop   : in Truncation := Error)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Tail (Source : in out Bounded_String;                    Count  : in Natural;                    Pad    : in Character  := Space;                    Drop   : in Truncation := Error);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> --String constructor subprograms</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function "*" (Left  : in Natural;                  Right : in Character)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function "*" (Left  : in Natural;                  Right : in String)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function "*" (Left  : in Natural;                  Right : in Bounded_String)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Replicate (Count : in Natural;                        Item  : in Character;                        Drop  : in Truncation := Error)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Replicate (Count : in Natural;                        Item  : in String;                        Drop  : in Truncation := Error)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">      function Replicate (Count : in Natural;                       Item  : in Bounded_String;                       Drop  : in Truncation := Error)       return Bounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    private     ... -- not specified by the language end Generic_Bounded_Length;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> end Ada.Strings.Bounded;</syntaxhighlight></p> Null_Bounded_String represents the null string. If an object of type Bounded_String is not otherwise initialized, it will be initialized to the same value as Null_Bounded_String. <p><syntaxhighlight lang="Ada"> function Length (Source : in Bounded_String) return Length_Range;</syntaxhighlight></p> <p><span></span></p> :The Length function returns the length of the string represented by Source. <p><syntaxhighlight lang="Ada"> function To_Bounded_String (Source : in String;                          Drop   : in Truncation := Error) return Bounded_String;</syntaxhighlight></p> <p><span></span></p> :If Source'Length <= Max_Length then this function returns a Bounded_String that represents Source. Otherwise the effect depends on the value of Drop: <p><span></span></p> ::* If Drop=Left, then the result is a Bounded_String that represents the string comprising the rightmost Max_Length characters of Source. <p><span></span></p> ::* If Drop=Right, then the result is a Bounded_String that represents the string comprising the leftmost Max_Length characters of Source. <p><span></span></p> ::* If Drop=Error, then Strings.Length_Error is propagated. <p><syntaxhighlight lang="Ada"> function To_String (Source : in Bounded_String) return String;</syntaxhighlight></p> <p><span></span></p> :To_String returns the String value with lower bound 1 represented by Source. If B is a Bounded_String, then B = To_Bounded_String(To_String(B)). Each of the Append functions returns a Bounded_String obtained by concatenating the string or character given or represented by one of the parameters, with the string or character given or represented by the other parameter, and applying To_Bounded_String to the concatenation result string, with Drop as provided to the Append function. Each of the procedures Append(Source, New_Item, Drop) has the same effect as the corresponding assignment Source := Append(Source, New_Item, Drop). Each of the "&" functions has the same effect as the corresponding Append function, with Error as the Drop parameter. <p><syntaxhighlight lang="Ada"> function Element (Source : in Bounded_String;                Index  : in Positive) return Character;</syntaxhighlight></p> <p><span></span></p> :Returns the character at position Index in the string represented by Source; propagates Index_Error if Index > Length(Source). <p><syntaxhighlight lang="Ada"> procedure Replace_Element (Source : in out Bounded_String;                         Index  : in Positive;                         By     : in Character);</syntaxhighlight></p> <p><span></span></p> :Updates Source such that the character at position Index in the string represented by Source is By; propagates Index_Error if Index > Length(Source). <p><syntaxhighlight lang="Ada"> function Slice (Source : in Bounded_String;              Low    : in Positive;              High   : in Natural) return String;</syntaxhighlight></p> <p><span></span></p> :Returns the slice at positions Low through High in the string represented by Source; propagates Index_Error if Low > Length(Source)+1 or High > Length(Source). Each of the functions "=", "<", ">","<=", and ">=" returns the same result as the corresponding String operation applied to the String values given or represented by the two parameters. Each of the search subprograms (Index, Index_Non_Blank, Count, Find_Token) has the same effect as the corresponding subprogram in Strings.Fixed applied to the string represented by the Bounded_String parameter. Each of the Translate subprograms, when applied to a Bounded_String, has an analogous effect to the corresponding subprogram in Strings.Fixed. For the Translate function, the translation is applied to the string represented by the Bounded_String parameter, and the result is converted (via To_Bounded_String) to a Bounded_String. For the Translate procedure, the string represented by the Bounded_String parameter after the translation is given by the Translate function for fixed-length strings applied to the string represented by the original value of the parameter. Each of the transformation subprograms (Replace_Slice, Insert, Overwrite, Delete), selector subprograms (Trim, Head, Tail), and constructor functions ("*") has an effect based on its corresponding subprogram in Strings.Fixed, and Replicate is based on Fixed."*". In the case of a function, the corresponding fixed-length string subprogram is applied to the string represented by the Bounded_String parameter. To_Bounded_String is applied the result string, with Drop (or Error in the case of Generic_Bounded_Length."*") determining the effect when the string length exceeds Max_Length. In the case of a procedure, the corresponding function in Strings.Bounded.Generic_Bounded_Length is applied, with the result assigned into the Source parameter. == Implementation Advice == Bounded string objects should not be implemented by implicit pointers and dynamic allocation. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-4-3|Previous]] | [[Guide:95lrm/RM-A-4-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 6lct8p22xbntqdau94lhmnjfkagtde6 Guide:95lrm/RM-A-4-5 4200 1097 4369 2019-05-01T15:43:11Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-4-4|Previous]] | [[Guide:95lrm/RM-A-4-6|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.4.5 Unbounded-Length String Handling}} The language-defined package Strings.Unbounded provides a private type Unbounded_String and a set of operations. An object of type Unbounded_String represents a String whose low bound is 1 and whose length can vary conceptually between 0 and Natural'Last. The subprograms for fixed-length string handling are either overloaded directly for Unbounded_String, or are modified as needed to reflect the flexibility in length. Since the Unbounded_String type is private, relevant constructor and selector operations are provided. == Static Semantics == The library package Strings.Unbounded has the following declaration: <p><syntaxhighlight lang="Ada"> with Ada.Strings.Maps; package Ada.Strings.Unbounded is pragma Preelaborate(Unbounded);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   type Unbounded_String is private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Null_Unbounded_String : constant Unbounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Length (Source : in Unbounded_String) return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type String_Access is access all String; procedure Free (X : in out String_Access);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- Conversion, Concatenation, and Selection functions</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Unbounded_String (Source : in String)    return Unbounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Unbounded_String (Length : in Natural)    return Unbounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_String (Source : in Unbounded_String) return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Append (Source   : in out Unbounded_String;                   New_Item : in Unbounded_String);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Append (Source   : in out Unbounded_String;                   New_Item : in String);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Append (Source   : in out Unbounded_String;                   New_Item : in Character);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "&" (Left, Right : in Unbounded_String)    return Unbounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "&" (Left : in Unbounded_String; Right : in String)    return Unbounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "&" (Left : in String; Right : in Unbounded_String)    return Unbounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     function "&" (Left : in Unbounded_String; Right : in Character)    return Unbounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "&" (Left : in Character; Right : in Unbounded_String)    return Unbounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Element (Source : in Unbounded_String;                   Index  : in Positive)    return Character;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Replace_Element (Source : in out Unbounded_String;                            Index  : in Positive;                            By     : in Character);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Slice (Source : in Unbounded_String;                 Low    : in Positive;                 High   : in Natural)    return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "="  (Left, Right : in Unbounded_String)  return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "="  (Left : in Unbounded_String; Right : in String)   return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     function "="  (Left : in String; Right : in Unbounded_String)   return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "<"  (Left, Right : in Unbounded_String)  return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "<"  (Left : in Unbounded_String; Right : in String)   return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     function "<"  (Left : in String; Right : in Unbounded_String)   return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "<=" (Left, Right : in Unbounded_String)  return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "<="  (Left : in Unbounded_String; Right : in String)   return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "<="  (Left : in String; Right : in Unbounded_String)    return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function ">"  (Left, Right : in Unbounded_String)  return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function ">"  (Left : in Unbounded_String; Right : in String)   return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function ">"  (Left : in String; Right : in Unbounded_String)   return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function ">=" (Left, Right : in Unbounded_String)  return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function ">="  (Left : in Unbounded_String; Right : in String)   return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function ">="  (Left : in String; Right : in Unbounded_String)   return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- Search subprograms</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Index (Source   : in Unbounded_String;                 Pattern  : in String;                 Going    : in Direction := Forward;                 Mapping  : in Maps.Character_Mapping                              := Maps.Identity) return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Index (Source   : in Unbounded_String;                 Pattern  : in String;                 Going    : in Direction := Forward;                 Mapping  : in Maps.Character_Mapping_Function)    return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Index (Source : in Unbounded_String;                 Set    : in Maps.Character_Set;                 Test   : in Membership := Inside;                 Going  : in Direction  := Forward) return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Index_Non_Blank (Source : in Unbounded_String;                           Going  : in Direction := Forward)    return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Count (Source   : in Unbounded_String;                 Pattern  : in String;                 Mapping  : in Maps.Character_Mapping                              := Maps.Identity) return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Count (Source   : in Unbounded_String;                 Pattern  : in String;                 Mapping  : in Maps.Character_Mapping_Function)    return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Count (Source   : in Unbounded_String;                 Set      : in Maps.Character_Set)    return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Find_Token (Source : in Unbounded_String;                       Set    : in Maps.Character_Set;                       Test   : in Membership;                       First  : out Positive;                       Last   : out Natural);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- String translation subprograms</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Translate (Source  : in Unbounded_String;                     Mapping : in Maps.Character_Mapping)    return Unbounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Translate (Source  : in out Unbounded_String;                      Mapping : in Maps.Character_Mapping);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Translate (Source  : in Unbounded_String;                     Mapping : in Maps.Character_Mapping_Function)    return Unbounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Translate (Source  : in out Unbounded_String;                      Mapping : in Maps.Character_Mapping_Function);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- String transformation subprograms</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Replace_Slice (Source   : in Unbounded_String;                         Low      : in Positive;                         High     : in Natural;                         By       : in String)    return Unbounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Replace_Slice (Source   : in out Unbounded_String;                          Low      : in Positive;                          High     : in Natural;                          By       : in String);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Insert (Source   : in Unbounded_String;                  Before   : in Positive;                  New_Item : in String)    return Unbounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Insert (Source   : in out Unbounded_String;                   Before   : in Positive;                   New_Item : in String);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Overwrite (Source    : in Unbounded_String;                     Position  : in Positive;                     New_Item  : in String)    return Unbounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Overwrite (Source    : in out Unbounded_String;                      Position  : in Positive;                      New_Item  : in String);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Delete (Source  : in Unbounded_String;                  From    : in Positive;                  Through : in Natural)    return Unbounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Delete (Source  : in out Unbounded_String;                   From    : in Positive;                   Through : in Natural);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Trim (Source : in Unbounded_String;                Side   : in Trim_End)    return Unbounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Trim (Source : in out Unbounded_String;                 Side   : in Trim_End);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Trim (Source : in Unbounded_String;                Left   : in Maps.Character_Set;                Right  : in Maps.Character_Set)    return Unbounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Trim (Source : in out Unbounded_String;                 Left   : in Maps.Character_Set;                 Right  : in Maps.Character_Set);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Head (Source : in Unbounded_String;                Count  : in Natural;                Pad    : in Character := Space)    return Unbounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Head (Source : in out Unbounded_String;                 Count  : in Natural;                 Pad    : in Character := Space);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Tail (Source : in Unbounded_String;                Count  : in Natural;                Pad    : in Character := Space)    return Unbounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Tail (Source : in out Unbounded_String;                 Count  : in Natural;                 Pad    : in Character := Space);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "*" (Left  : in Natural;               Right : in Character)    return Unbounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "*" (Left  : in Natural;               Right : in String)    return Unbounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "*" (Left  : in Natural;               Right : in Unbounded_String)    return Unbounded_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> private ... -- not specified by the language end Ada.Strings.Unbounded;</syntaxhighlight></p> Null_Unbounded_String represents the null String. If an object of type Unbounded_String is not otherwise initialized, it will be initialized to the same value as Null_Unbounded_String. The function Length returns the length of the String represented by Source. The type String_Access provides a (non-private) access type for explicit processing of unbounded-length strings. The procedure Free performs an unchecked deallocation of an object of type String_Access. The function To_Unbounded_String(Source : in String) returns an Unbounded_String that represents Source. The function To_Unbounded_String(Length : in Natural) returns an Unbounded_String that represents an uninitialized String whose length is Length. The function To_String returns the String with lower bound 1 represented by Source. To_String and To_Unbounded_String are related as follows: * If S is a String, then To_String(To_Unbounded_String(S)) = S. * If U is an Unbounded_String, then To_Unbounded_String(To_String(U)) = U. For each of the Append procedures, the resulting string represented by the Source parameter is given by the concatenation of the original value of Source and the value of New_Item. Each of the "&" functions returns an Unbounded_String obtained by concatenating the string or character given or represented by one of the parameters, with the string or character given or represented by the other parameter, and applying To_Unbounded_String to the concatenation result string. The Element, Replace_Element, and Slice subprograms have the same effect as the corresponding bounded-length string subprograms. Each of the functions "=", "<", ">","<=", and ">=" returns the same result as the corresponding String operation applied to the String values given or represented by Left and Right. Each of the search subprograms (Index, Index_Non_Blank, Count, Find_Token) has the same effect as the corresponding subprogram in Strings.Fixed applied to the string represented by the Unbounded_String parameter. The Translate function has an analogous effect to the corresponding subprogram in Strings.Fixed. The translation is applied to the string represented by the Unbounded_String parameter, and the result is converted (via To_Unbounded_String) to an Unbounded_String. Each of the transformation functions (Replace_Slice, Insert, Overwrite, Delete), selector functions (Trim, Head, Tail), and constructor functions ("*") is likewise analogous to its corresponding subprogram in Strings.Fixed. For each of the subprograms, the corresponding fixed-length string subprogram is applied to the string represented by the Unbounded_String parameter, and To_Unbounded_String is applied the result string. For each of the procedures Translate, Replace_Slice, Insert, Overwrite, Delete, Trim, Head, and Tail, the resulting string represented by the Source parameter is given by the corresponding function for fixed-length strings applied to the string represented by Source's original value. == Implementation Requirements == No storage associated with an Unbounded_String object shall be lost upon assignment or scope exit. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-4-4|Previous]] | [[Guide:95lrm/RM-A-4-6|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} lg5z1267mqaqdbq03j6rifspyg7v19s Guide:95lrm/RM-A-4-6 4200 1098 4370 2019-05-01T15:44:50Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-4-5|Previous]] | [[Guide:95lrm/RM-A-4-7|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.4.6 String-Handling Sets and Mappings}} The language-defined package Strings.Maps.Constants declares Character_Set and Character_Mapping constants corresponding to classification and conversion functions in package Characters.Handling. == Static Semantics == The library package Strings.Maps.Constants has the following declaration: <p><syntaxhighlight lang="Ada"> package Ada.Strings.Maps.Constants is pragma Preelaborate(Constants);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     Control_Set           : constant Character_Set; Graphic_Set           : constant Character_Set; Letter_Set            : constant Character_Set; Lower_Set             : constant Character_Set; Upper_Set             : constant Character_Set; Basic_Set             : constant Character_Set; Decimal_Digit_Set     : constant Character_Set; Hexadecimal_Digit_Set : constant Character_Set; Alphanumeric_Set      : constant Character_Set; Special_Set           : constant Character_Set; ISO_646_Set           : constant Character_Set;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Lower_Case_Map        : constant Character_Mapping;   --Maps to lower case for letters, else identity Upper_Case_Map        : constant Character_Mapping;   --Maps to upper case for letters, else identity Basic_Map             : constant Character_Mapping;   --Maps to basic letter for letters, else identity</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> private ... -- not specified by the language end Ada.Strings.Maps.Constants;</syntaxhighlight></p> Each of these constants represents a correspondingly named set of characters or character mapping in Characters.Handling (see [[Guide:95lrm/RM-A-3-2|A.3.2]]). </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-4-5|Previous]] | [[Guide:95lrm/RM-A-4-7|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} t4aya1jn9sq39bupqzofl05gg3ws22j Guide:95lrm/RM-A-4-7 4200 1099 4371 2019-05-01T15:53:19Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-4-6|Previous]] | [[Guide:95lrm/RM-A-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.4.7 Wide_String Handling}} Facilities for handling strings of Wide_Character elements are found in the packages Strings.Wide_Maps, Strings.Wide_Fixed, Strings.Wide_Bounded, Strings.Wide_Unbounded, and Strings.Wide_Maps.Wide_Constants. They provide the same string-handling operations as the corresponding packages for strings of Character elements. <span id="I5206"></span><span id="I5207"></span><span id="I5208"></span><span id="I5209"></span><span id="I5210"></span><span id="I5211"></span><span id="I5212"></span><span id="I5213"></span><span id="I5214"></span> == Static Semantics == The package Strings.Wide_Maps has the following declaration. <p><syntaxhighlight lang="Ada"> package Ada.Strings.Wide_Maps is pragma Preelaborate(Wide_Maps);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Representation for a set of Wide_Character values: type Wide_Character_Set is private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Null_Set : constant Wide_Character_Set;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Wide_Character_Range is   record       Low  : Wide_Character;       High : Wide_Character;   end record; -- Represents Wide_Character range Low..High</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Wide_Character_Ranges is array (Positive range <>)    of Wide_Character_Range;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Set    (Ranges : in Wide_Character_Ranges)    return Wide_Character_Set;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     function To_Set    (Span   : in Wide_Character_Range)    return Wide_Character_Set;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Ranges (Set    : in Wide_Character_Set)    return Wide_Character_Ranges;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "="   (Left, Right : in Wide_Character_Set) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "not" (Right : in Wide_Character_Set)    return Wide_Character_Set; function "and" (Left, Right : in Wide_Character_Set)    return Wide_Character_Set; function "or"  (Left, Right : in Wide_Character_Set)    return Wide_Character_Set; function "xor" (Left, Right : in Wide_Character_Set)    return Wide_Character_Set; function "-"   (Left, Right : in Wide_Character_Set)    return Wide_Character_Set;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Is_In (Element : in Wide_Character;                 Set     : in Wide_Character_Set)    return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Is_Subset (Elements : in Wide_Character_Set;                   Set      : in Wide_Character_Set)    return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "<=" (Left  : in Wide_Character_Set;                Right : in Wide_Character_Set)    return Boolean renames Is_Subset;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Alternative representation for a set of Wide_Character values: subtype Wide_Character_Sequence is Wide_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Set (Sequence  : in Wide_Character_Sequence)    return Wide_Character_Set;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Set (Singleton : in Wide_Character)    return Wide_Character_Set;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Sequence (Set  : in Wide_Character_Set)    return Wide_Character_Sequence;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Representation for a Wide_Character to Wide_Character mapping: type Wide_Character_Mapping is private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Value (Map     : in Wide_Character_Mapping;                 Element : in Wide_Character)    return Wide_Character;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Identity : constant Wide_Character_Mapping;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Mapping (From, To : in Wide_Character_Sequence)    return Wide_Character_Mapping;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Domain (Map : in Wide_Character_Mapping)    return Wide_Character_Sequence;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Range  (Map : in Wide_Character_Mapping)    return Wide_Character_Sequence;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Wide_Character_Mapping_Function is    access function (From : in Wide_Character) return Wide_Character;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> private ... -- not specified by the language end Ada.Strings.Wide_Maps;</syntaxhighlight></p> <span id="I5255"></span><span id="I5256"></span><span id="I5257"></span>The context clause for each of the packages Strings.Wide_Fixed, Strings.Wide_Bounded, and Strings.Wide_Unbounded identifies Strings.Wide_Maps instead of Strings.Maps. For each of the packages Strings.Fixed, Strings.Bounded, Strings.Unbounded, and Strings.Maps.Constants the corresponding wide string package has the same contents except that * Wide_Space replaces Space * Wide_Character replaces Character * Wide_String replaces String * Wide_Character_Set replaces Character_Set * Wide_Character_Mapping replaces Character_Mapping * Wide_Character_Mapping_Function replaces Character_Mapping_Function * Wide_Maps replaces Maps * Bounded_Wide_String replaces Bounded_String * Null_Bounded_Wide_String replaces Null_Bounded_String * To_Bounded_Wide_String replaces To_Bounded_String * To_Wide_String replaces To_String * Unbounded_Wide_String replaces Unbounded_String * Null_Unbounded_Wide_String replaces Null_Unbounded_String * Wide_String_Access replaces String_Access * To_Unbounded_Wide_String replaces To_Unbounded_String The following additional declaration is present in Strings.Wide_Maps.Wide_Constants: <p><syntaxhighlight lang="Ada"> Character_Set : constant Wide_Maps.Wide_Character_Set; -- Contains each Wide_Character value WC  -- such that Characters.Is_Character(WC) is True</syntaxhighlight></p> == Notes == 12  <span id="I5259"></span>If a null Wide_Character_Mapping_Function is passed to any of the Wide_String handling subprograms, Constraint_Error is propagated. 13  Each Wide_Character_Set constant in the package Strings.Wide_Maps.Wide_Constants contains no values outside the Character portion of Wide_Character. Similarly, each Wide_Character_Mapping constant in this package is the identity mapping when applied to any element outside the Character portion of Wide_Character. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-4-6|Previous]] | [[Guide:95lrm/RM-A-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} obj2e408tko6vfquqm3j5rcsz0oa5we Guide:95lrm/RM-A-5 4200 1100 4372 2019-05-01T15:54:33Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-4-7|Previous]] | [[Guide:95lrm/RM-A-5-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.5 The Numerics Packages}} The library package Numerics is the parent of several child units that provide facilities for mathematical computation. One child, the generic package Generic_Elementary_Functions, is defined in [[Guide:95lrm/RM-A-5-1|A.5.1]], together with nongeneric equivalents; two others, the package Float_Random and the generic package Discrete_Random, are defined in [[Guide:95lrm/RM-A-5-2|A.5.2]]. Additional (optional) children are defined in [[Guide:95lrm/RM-G|Annex G]], ''[[Guide:95lrm/RM-G|Numerics]]''. == Static Semantics == ''This paragraph was deleted.'' <p><syntaxhighlight lang="Ada"> package Ada.Numerics is pragma Pure(Numerics); Argument_Error : exception; Pi : constant := 3.14159_26535_89793_23846_26433_83279_50288_41971_69399_37511; e  : constant :=        2.71828_18284_59045_23536_02874_71352_66249_77572_47093_69996; end Ada.Numerics;</syntaxhighlight></p> The Argument_Error exception is raised by a subprogram in a child unit of Numerics to signal that one or more of the actual subprogram parameters are outside the domain of the corresponding mathematical function. == Implementation Permissions == The implementation may specify the values of Pi and e to a larger number of significant digits. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-4-7|Previous]] | [[Guide:95lrm/RM-A-5-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 6mb8ac7sbo6deioockbukgm4z9qzhnl Guide:95lrm/RM-A-5-1 4200 1101 4373 2019-05-01T15:58:57Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-5|Previous]] | [[Guide:95lrm/RM-A-5-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.5.1 Elementary Functions}} Implementation-defined approximations to the mathematical functions known as the ''elementary functions'' are provided by the subprograms in Numerics.Generic_Elementary_Functions. Nongeneric equivalents of this generic package for each of the predefined floating point types are also provided as children of Numerics. == Static Semantics == The generic library package Numerics.Generic_Elementary_Functions has the following declaration: <p><syntaxhighlight lang="Ada"> generic type Float_Type is digits <>; package Ada.Numerics.Generic_Elementary_Functions is pragma Pure(Generic_Elementary_Functions);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Sqrt    (X           : Float_Type'Base) return Float_Type'Base; function Log     (X           : Float_Type'Base) return Float_Type'Base; function Log     (X, Base     : Float_Type'Base) return Float_Type'Base; function Exp     (X           : Float_Type'Base) return Float_Type'Base; function "**"    (Left, Right : Float_Type'Base) return Float_Type'Base;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Sin     (X           : Float_Type'Base) return Float_Type'Base; function Sin     (X, Cycle    : Float_Type'Base) return Float_Type'Base; function Cos     (X           : Float_Type'Base) return Float_Type'Base; function Cos     (X, Cycle    : Float_Type'Base) return Float_Type'Base; function Tan     (X           : Float_Type'Base) return Float_Type'Base; function Tan     (X, Cycle    : Float_Type'Base) return Float_Type'Base; function Cot     (X           : Float_Type'Base) return Float_Type'Base; function Cot     (X, Cycle    : Float_Type'Base) return Float_Type'Base;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Arcsin  (X           : Float_Type'Base) return Float_Type'Base; function Arcsin  (X, Cycle    : Float_Type'Base) return Float_Type'Base; function Arccos  (X           : Float_Type'Base) return Float_Type'Base; function Arccos  (X, Cycle    : Float_Type'Base) return Float_Type'Base; function Arctan  (Y           : Float_Type'Base;                   X           : Float_Type'Base := 1.0)                                                  return Float_Type'Base; function Arctan  (Y           : Float_Type'Base;                   X           : Float_Type'Base := 1.0;                   Cycle       : Float_Type'Base) return Float_Type'Base; function Arccot  (X           : Float_Type'Base;                   Y           : Float_Type'Base := 1.0)                                                  return Float_Type'Base; function Arccot  (X           : Float_Type'Base;                   Y           : Float_Type'Base := 1.0;                   Cycle       : Float_Type'Base) return Float_Type'Base;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Sinh    (X           : Float_Type'Base) return Float_Type'Base; function Cosh    (X           : Float_Type'Base) return Float_Type'Base; function Tanh    (X           : Float_Type'Base) return Float_Type'Base; function Coth    (X           : Float_Type'Base) return Float_Type'Base; function Arcsinh (X           : Float_Type'Base) return Float_Type'Base; function Arccosh (X           : Float_Type'Base) return Float_Type'Base; function Arctanh (X           : Float_Type'Base) return Float_Type'Base; function Arccoth (X           : Float_Type'Base) return Float_Type'Base;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> end Ada.Numerics.Generic_Elementary_Functions;</syntaxhighlight></p> <span id="I5325"></span><span id="I5326"></span><span id="I5327"></span><span id="I5328"></span>The library package Numerics.Elementary_Functions is declared pure and defines the same subprograms as Numerics.Generic_Elementary_Functions, except that the predefined type Float is systematically substituted for Float_Type'Base throughout. Nongeneric equivalents of Numerics.Generic_Elementary_Functions for each of the other predefined floating point types are defined similarly, with the names Numerics.Short_Elementary_Functions, Numerics.Long_Elementary_Functions, etc. The functions have their usual mathematical meanings. When the Base parameter is specified, the Log function computes the logarithm to the given base; otherwise, it computes the natural logarithm. When the Cycle parameter is specified, the parameter X of the forward trigonometric functions (Sin, Cos, Tan, and Cot) and the results of the inverse trigonometric functions (Arcsin, Arccos, Arctan, and Arccot) are measured in units such that a full cycle of revolution has the given value; otherwise, they are measured in radians. The computed results of the mathematically multivalued functions are rendered single-valued by the following conventions, which are meant to imply the principal branch: * The results of the Sqrt and Arccosh functions and that of the exponentiation operator are nonnegative. * The result of the Arcsin function is in the quadrant containing the point (1.0, ''x''), where ''x'' is the value of the parameter X. This quadrant is I or IV; thus, the range of the Arcsin function is approximately -PI/2.0 to PI/2.0 (-Cycle/4.0 to Cycle/4.0, if the parameter Cycle is specified). * The result of the Arccos function is in the quadrant containing the point (''x'', 1.0), where ''x'' is the value of the parameter X. This quadrant is I or II; thus, the Arccos function ranges from 0.0 to approximately PI (Cycle/2.0, if the parameter Cycle is specified). * The results of the Arctan and Arccot functions are in the quadrant containing the point (''x'', ''y''), where ''x'' and ''y'' are the values of the parameters X and Y, respectively. This may be any quadrant (I through IV) when the parameter X (resp., Y) of Arctan (resp., Arccot) is specified, but it is restricted to quadrants I and IV (resp., I and II) when that parameter is omitted. Thus, the range when that parameter is specified is approximately -PI to PI (-Cycle/2.0 to Cycle/2.0, if the parameter Cycle is specified); when omitted, the range of Arctan (resp., Arccot) is that of Arcsin (resp., Arccos), as given above. When the point (''x'', ''y'') lies on the negative x-axis, the result approximates <p><span></span></p> :* PI (resp., -PI) when the sign of the parameter Y is positive (resp., negative), if Float_Type'Signed_Zeros is True; <p><span></span></p> :* PI, if Float_Type'Signed_Zeros is False. (In the case of the inverse trigonometric functions, in which a result lying on or near one of the axes may not be exactly representable, the approximation inherent in computing the result may place it in an adjacent quadrant, close to but on the wrong side of the axis.) == Dynamic Semantics == The exception Numerics.Argument_Error is raised, signaling a parameter value outside the domain of the corresponding mathematical function, in the following cases: * by any forward or inverse trigonometric function with specified cycle, when the value of the parameter Cycle is zero or negative; * by the Log function with specified base, when the value of the parameter Base is zero, one, or negative; * by the Sqrt and Log functions, when the value of the parameter X is negative; * by the exponentiation operator, when the value of the left operand is negative or when both operands have the value zero; * by the Arcsin, Arccos, and Arctanh functions, when the absolute value of the parameter X exceeds one; * by the Arctan and Arccot functions, when the parameters X and Y both have the value zero; * by the Arccosh function, when the value of the parameter X is less than one; and * by the Arccoth function, when the absolute value of the parameter X is less than one. <span id="I5329"></span><span id="I5330"></span><span id="I5331"></span>The exception Constraint_Error is raised, signaling a pole of the mathematical function (analogous to dividing by zero), in the following cases, provided that Float_Type'Machine_Overflows is True: * by the Log, Cot, and Coth functions, when the value of the parameter X is zero; * by the exponentiation operator, when the value of the left operand is zero and the value of the exponent is negative; * by the Tan function with specified cycle, when the value of the parameter X is an odd multiple of the quarter cycle; * by the Cot function with specified cycle, when the value of the parameter X is zero or a multiple of the half cycle; and * by the Arctanh and Arccoth functions, when the absolute value of the parameter X is one. <span id="I5332"></span>Constraint_Error can also be raised when a finite result overflows (see [[Guide:95lrm/RM-G-2-4|G.2.4]]); this may occur for parameter values sufficiently ''near'' poles, and, in the case of some of the functions, for parameter values with sufficiently large magnitudes.<span id="I5333"></span> When Float_Type'Machine_Overflows is False, the result at poles is unspecified. When one parameter of a function with multiple parameters represents a pole and another is outside the function's domain, the latter takes precedence (i.e., Numerics.Argument_Error is raised). == Implementation Requirements == In the implementation of Numerics.Generic_Elementary_Functions, the range of intermediate values allowed during the calculation of a final result shall not be affected by any range constraint of the subtype Float_Type. <span id="I5334"></span>In the following cases, evaluation of an elementary function shall yield the ''prescribed result'', provided that the preceding rules do not call for an exception to be raised: * When the parameter X has the value zero, the Sqrt, Sin, Arcsin, Tan, Sinh, Arcsinh, Tanh, and Arctanh functions yield a result of zero, and the Exp, Cos, and Cosh functions yield a result of one. * When the parameter X has the value one, the Sqrt function yields a result of one, and the Log, Arccos, and Arccosh functions yield a result of zero. * When the parameter Y has the value zero and the parameter X has a positive value, the Arctan and Arccot functions yield a result of zero. * The results of the Sin, Cos, Tan, and Cot functions with specified cycle are exact when the mathematical result is zero; those of the first two are also exact when the mathematical result is ± 1.0. * Exponentiation by a zero exponent yields the value one. Exponentiation by a unit exponent yields the value of the left operand. Exponentiation of the value one yields the value one. Exponentiation of the value zero yields the value zero. Other accuracy requirements for the elementary functions, which apply only in implementations conforming to the Numerics Annex, and then only in the ''strict'' mode defined there (see [[Guide:95lrm/RM-G-2|G.2]]), are given in [[Guide:95lrm/RM-G-2-4|G.2.4]]. When Float_Type'Signed_Zeros is True, the sign of a zero result shall be as follows: * A prescribed zero result delivered ''at the origin'' by one of the odd functions (Sin, Arcsin, Sinh, Arcsinh, Tan, Arctan or Arccot as a function of Y when X is fixed and positive, Tanh, and Arctanh) has the sign of the parameter X (Y, in the case of Arctan or Arccot). * A prescribed zero result delivered by one of the odd functions ''away from the origin'', or by some other elementary function, has an implementation-defined sign. * A zero result that is not a prescribed result (i.e., one that results from rounding or underflow) has the correct mathematical sign. == Implementation Permissions == The nongeneric equivalent packages may, but need not, be actual instantiations of the generic package for the appropriate predefined type. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-5|Previous]] | [[Guide:95lrm/RM-A-5-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} bisj0wrms0blgmb766hr2s64ifys377 Guide:95lrm/RM-A-5-2 4200 1102 4374 2019-05-01T16:14:52Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-5-1|Previous]] | [[Guide:95lrm/RM-A-5-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.5.2 Random Number Generation}} Facilities for the generation of pseudo-random floating point numbers are provided in the package Numerics.Float_Random; the generic package Numerics.Discrete_Random provides similar facilities for the generation of pseudo-random integers and pseudo-random values of enumeration types. <span id="I5335"></span>For brevity, pseudo-random values of any of these types are called ''random numbers''. Some of the facilities provided are basic to all applications of random numbers. These include a limited private type each of whose objects serves as the generator of a (possibly distinct) sequence of random numbers; a function to obtain the ''next'' random number from a given sequence of random numbers (that is, from its generator); and subprograms to initialize or reinitialize a given generator to a time-dependent state or a state denoted by a single integer. Other facilities are provided specifically for advanced applications. These include subprograms to save and restore the state of a given generator; a private type whose objects can be used to hold the saved state of a generator; and subprograms to obtain a string representation of a given generator state, or, given such a string representation, the corresponding state. == Static Semantics == The library package Numerics.Float_Random has the following declaration: <p><syntaxhighlight lang="Ada"> package Ada.Numerics.Float_Random is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Basic facilities</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Generator is limited private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    subtype Uniformly_Distributed is Float range 0.0 .. 1.0; function Random (Gen : Generator) return Uniformly_Distributed;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Reset (Gen       : in Generator;                  Initiator : in Integer); procedure Reset (Gen       : in Generator);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Advanced facilities</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type State is private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Save  (Gen        : in  Generator;                  To_State   : out State); procedure Reset (Gen        : in  Generator;                  From_State : in  State);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Max_Image_Width : constant := implementation-defined integer value;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Image (Of_State    : State)  return String; function Value (Coded_State : String) return State;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> private ... -- not specified by the language end Ada.Numerics.Float_Random;</syntaxhighlight></p> The generic library package Numerics.Discrete_Random has the following declaration: <p><syntaxhighlight lang="Ada"> generic type Result_Subtype is (<>); package Ada.Numerics.Discrete_Random is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Basic facilities</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Generator is limited private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Random (Gen : Generator) return Result_Subtype;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Reset (Gen       : in Generator;                  Initiator : in Integer); procedure Reset (Gen       : in Generator);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Advanced facilities</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type State is private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Save  (Gen        : in  Generator;                  To_State   : out State); procedure Reset (Gen        : in  Generator;                  From_State : in  State);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Max_Image_Width : constant := implementation-defined integer value;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Image (Of_State    : State)  return String; function Value (Coded_State : String) return State;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> private ... -- not specified by the language end Ada.Numerics.Discrete_Random;</syntaxhighlight></p> An object of the limited private type Generator is associated with a sequence of random numbers. Each generator has a hidden (internal) state, which the operations on generators use to determine the position in the associated sequence. <span id="I5381"></span>All generators are implicitly initialized to an unspecified state that does not vary from one program execution to another; they may also be explicitly initialized, or reinitialized, to a time-dependent state, to a previously saved state, or to a state uniquely denoted by an integer value. An object of the private type State can be used to hold the internal state of a generator. Such objects are only needed if the application is designed to save and restore generator states or to examine or manufacture them. The operations on generators affect the state and therefore the future values of the associated sequence. The semantics of the operations on generators and states are defined below. <p><syntaxhighlight lang="Ada"> function Random (Gen : Generator) return Uniformly_Distributed; function Random (Gen : Generator) return Result_Subtype;</syntaxhighlight></p> <p><span></span></p> :Obtains the ''next'' random number from the given generator, relative to its current state, according to an implementation-defined algorithm. The result of the function in Numerics.Float_Random is delivered as a value of the subtype Uniformly_Distributed, which is a subtype of the predefined type Float having a range of 0.0 .. 1.0. The result of the function in an instantiation of Numerics.Discrete_Random is delivered as a value of the generic formal subtype Result_Subtype. <p><syntaxhighlight lang="Ada"> procedure Reset (Gen       : in Generator;               Initiator : in Integer); procedure Reset (Gen       : in Generator);</syntaxhighlight></p> <p><span></span></p> :<span id="I5382"></span>Sets the state of the specified generator to one that is an unspecified function of the value of the parameter Initiator (or to a time-dependent state, if only a generator parameter is specified). <span id="I5383"></span>The latter form of the procedure is known as the ''time-dependent Reset procedure''. <p><syntaxhighlight lang="Ada"> procedure Save  (Gen        : in  Generator;               To_State   : out State); procedure Reset (Gen        : in  Generator;               From_State : in  State);</syntaxhighlight></p> <p><span></span></p> :Save obtains the current state of a generator. Reset gives a generator the specified state. A generator that is reset to a state previously obtained by invoking Save is restored to the state it had when Save was invoked. <p><syntaxhighlight lang="Ada"> function Image (Of_State    : State)  return String; function Value (Coded_State : String) return State;</syntaxhighlight></p> <p><span></span></p> :Image provides a representation of a state coded (in an implementation-defined way) as a string whose length is bounded by the value of Max_Image_Width. Value is the inverse of Image: Value(Image(S)) = S for each state S that can be obtained from a generator by invoking Save. == Dynamic Semantics == <span id="I5384"></span><span id="I5385"></span><span id="I5386"></span>Instantiation of Numerics.Discrete_Random with a subtype having a null range raises Constraint_Error. ''This paragraph was deleted.'' == Bounded (Run-Time) Errors == <div> It is a bounded error to invoke Value with a string that is not the image of any generator state. <span id="I5387"></span><span id="I5388"></span>If the error is detected, Constraint_Error or Program_Error is raised. Otherwise, a call to Reset with the resulting state will produce a generator such that calls to Random with this generator will produce a sequence of values of the appropriate subtype, but which might not be random in character. That is, the sequence of values might not fulfill the implementation requirements of this subclause. </div> == Implementation Requirements == A sufficiently long sequence of random numbers obtained by successive calls to Random is approximately uniformly distributed over the range of the result subtype. The Random function in an instantiation of Numerics.Discrete_Random is guaranteed to yield each value in its result subtype in a finite number of calls, provided that the number of such values does not exceed 2 <sup>15</sup>. Other performance requirements for the random number generator, which apply only in implementations conforming to the Numerics Annex, and then only in the ''strict'' mode defined there (see [[Guide:95lrm/RM-G-2|G.2]]), are given in [[Guide:95lrm/RM-G-2-5|G.2.5]]. == Documentation Requirements == No one algorithm for random number generation is best for all applications. To enable the user to determine the suitability of the random number generators for the intended application, the implementation shall describe the algorithm used and shall give its period, if known exactly, or a lower bound on the period, if the exact period is unknown. Periods that are so long that the periodicity is unobservable in practice can be described in such terms, without giving a numerical bound. The implementation also shall document the minimum time interval between calls to the time-dependent Reset procedure that are guaranteed to initiate different sequences, and it shall document the nature of the strings that Value will accept without raising Constraint_Error. == Implementation Advice == Any storage associated with an object of type Generator should be reclaimed on exit from the scope of the object. If the generator period is sufficiently long in relation to the number of distinct initiator values, then each possible value of Initiator passed to Reset should initiate a sequence of random numbers that does not, in a practical sense, overlap the sequence initiated by any other value. If this is not possible, then the mapping between initiator values and generator states should be a rapidly varying function of the initiator value. == Notes == 14  If two or more tasks are to share the same generator, then the tasks have to synchronize their access to the generator as for any shared variable (see [[Guide:95lrm/RM-9-10|9.10]]). 15  Within a given implementation, a repeatable random number sequence can be obtained by relying on the implicit initialization of generators or by explicitly initializing a generator with a repeatable initiator value. Different sequences of random numbers can be obtained from a given generator in different program executions by explicitly initializing the generator to a time-dependent state. 16  A given implementation of the Random function in Numerics.Float_Random may or may not be capable of delivering the values 0.0 or 1.0. Portable applications should assume that these values, or values sufficiently close to them to behave indistinguishably from them, can occur. If a sequence of random integers from some fixed range is needed, the application should use the Random function in an appropriate instantiation of Numerics.Discrete_Random, rather than transforming the result of the Random function in Numerics.Float_Random. However, some applications with unusual requirements, such as for a sequence of random integers each drawn from a different range, will find it more convenient to transform the result of the floating point Random function. For M >= 1, the expression <p><syntaxhighlight lang="Ada">    Integer(Float(M) * Random(G)) mod M</syntaxhighlight></p> transforms the result of Random(G) to an integer uniformly distributed over the range 0 .. M-1; it is valid even if Random delivers 0.0 or 1.0. Each value of the result range is possible, provided that M is not too large. Exponentially distributed (floating point) random numbers with mean and standard deviation 1.0 can be obtained by the transformation <p><syntaxhighlight lang="Ada">    -Log(Random(G) + Float'Model_Small))</syntaxhighlight></p> where Log comes from Numerics.Elementary_Functions (see [[Guide:95lrm/RM-A-5-1|A.5.1]]); in this expression, the addition of Float'Model_Small avoids the exception that would be raised were Log to be given the value zero, without affecting the result (in most implementations) when Random returns a nonzero value. == Examples == ''Example of a program that plays a simulated dice game:'' <p><syntaxhighlight lang="Ada"> with Ada.Numerics.Discrete_Random; procedure Dice_Game is subtype Die is Integer range 1 .. 6; subtype Dice is Integer range 2*Die'First .. 2*Die'Last; package Random_Die is new Ada.Numerics.Discrete_Random (Die); use Random_Die; G : Generator; D : Dice; begin Reset (G);  -- Start the generator in a unique state in each run loop    -- Roll a pair of dice; sum and process the results     D := Random(G) + Random(G);    ... end loop; end Dice_Game;</syntaxhighlight></p> ''Example of a program that simulates coin tosses:'' <p><syntaxhighlight lang="Ada"> with Ada.Numerics.Discrete_Random; procedure Flip_A_Coin is type Coin is (Heads, Tails); package Random_Coin is new Ada.Numerics.Discrete_Random (Coin); use Random_Coin; G : Generator; begin Reset (G);  -- Start the generator in a unique state in each run loop     -- Toss a coin and process the result    case Random(G) is        when Heads =>           ...        when Tails =>           ...     end case; ... end loop; end Flip_A_Coin;</syntaxhighlight></p> ''Example of a parallel simulation of a physical system, with a separate generator of event probabilities in each task:'' <p><syntaxhighlight lang="Ada"> with Ada.Numerics.Float_Random; procedure Parallel_Simulation is use Ada.Numerics.Float_Random; task type Worker is    entry Initialize_Generator (Initiator : in Integer);    ... end Worker; W : array (1 .. 10) of Worker; task body Worker is     G : Generator;     Probability_Of_Event : Uniformly_Distributed; begin     accept Initialize_Generator (Initiator : in Integer) do        Reset (G, Initiator);     end Initialize_Generator;     loop      ...   Probability_Of_Event := Random(G);         ...     end loop; end Worker; begin -- Initialize the generators in the Worker tasks to different states for I in W'Range loop    W(I).Initialize_Generator (I); end loop; ... -- Wait for the Worker tasks to terminate end Parallel_Simulation;</syntaxhighlight></p> == Notes == 17  ''Notes on the last example:'' Although each Worker task initializes its generator to a different state, those states will be the same in every execution of the program. The generator states can be initialized uniquely in each program execution by instantiating Ada.Numerics.Discrete_Random for the type Integer in the main procedure, resetting the generator obtained from that instance to a time-dependent state, and then using random integers obtained from that generator to initialize the generators in each Worker task. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-5-1|Previous]] | [[Guide:95lrm/RM-A-5-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} eadya8ftfaqmezxwfcog4rifu5lg270 Guide:95lrm/RM-A-5-3 4200 1103 4375 2019-05-01T16:32:28Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-5-2|Previous]] | [[Guide:95lrm/RM-A-5-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.5.3 Attributes of Floating Point Types}} == Static Semantics == <span id="I5389"></span>The following ''representation-oriented attributes'' are defined for every subtype S of a floating point type ''T''. ; S'Machine_Radix : <span id="I5390"></span><span id="I5391"></span>Yields the radix of the hardware representation of the type ''T''. The value of this attribute is of the type ''universal_integer''. <span id="I5392"></span>The values of other representation-oriented attributes of a floating point subtype, and of the ''primitive function'' attributes of a floating point subtype described later, are defined in terms of a particular representation of nonzero values called the ''canonical form''. The canonical form (for the type ''T'') is the form <div> ± ''mantissa'' · ''T'''Machine_Radix<sup>''exponent''</sup> where </div> * ''mantissa'' is a fraction in the number base ''T'''Machine_Radix, the first digit of which is nonzero, and * ''exponent'' is an integer. ; S'Machine_Mantissa : <span id="I5393"></span><span id="I5394"></span>Yields the largest value of ''p'' such that every value expressible in the canonical form (for the type ''T''), having a ''p''-digit ''mantissa'' and an ''exponent'' between ''T'''Machine_Emin and ''T'''Machine_Emax, is a machine number (see [[Guide:95lrm/RM-3-5-7|3.5.7]]) of the type ''T''. This attribute yields a value of the type ''universal_integer''. ; S'Machine_Emin : <span id="I5395"></span><span id="I5396"></span>Yields the smallest (most negative) value of ''exponent'' such that every value expressible in the canonical form (for the type ''T''), having a ''mantissa'' of ''T'''Machine_Mantissa digits, is a machine number (see [[Guide:95lrm/RM-3-5-7|3.5.7]]) of the type ''T''. This attribute yields a value of the type ''universal_integer''. ; S'Machine_Emax : <span id="I5397"></span><span id="I5398"></span>Yields the largest (most positive) value of ''exponent'' such that every value expressible in the canonical form (for the type ''T''), having a ''mantissa'' of ''T'''Machine_Mantissa digits, is a machine number (see [[Guide:95lrm/RM-3-5-7|3.5.7]]) of the type ''T''. This attribute yields a value of the type ''universal_integer''. ; S'Denorm : <span id="I5399"></span><span id="I5400"></span>Yields the value True if every value expressible in the form :± ''mantissa'' · ''T'''Machine_Radix<sup>''T'''Machine_Emin</sup> :where ''mantissa'' is a nonzero ''T'''Machine_Mantissa-digit fraction in the number base ''T'''Machine_Radix, the first digit of which is zero, is a machine number (see [[Guide:95lrm/RM-3-5-7|3.5.7]]) of the type ''T''; yields the value False otherwise. The value of this attribute is of the predefined type Boolean. <span id="I5401"></span>The values described by the formula in the definition of S'Denorm are called ''denormalized numbers''. <span id="I5402"></span>A nonzero machine number that is not a denormalized number is a ''normalized number''. <span id="I5403"></span><span id="I5404"></span>A normalized number ''x'' of a given type ''T'' is said to be ''represented in canonical form'' when it is expressed in the canonical form (for the type ''T'') with a ''mantissa'' having ''T'''Machine_Mantissa digits; the resulting form is the ''canonical-form representation'' of ''x''. ;  S'Machine_Rounds : <span id="I5405"></span><span id="I5406"></span>Yields the value True if rounding is performed on inexact results of every predefined operation that yields a result of the type ''T''; yields the value False otherwise. The value of this attribute is of the predefined type Boolean. ;  S'Machine_Overflows : <span id="I5407"></span><span id="I5408"></span>Yields the value True if overflow and divide-by-zero are detected and reported by raising Constraint_Error for every predefined operation that yields a result of the type ''T''; yields the value False otherwise. The value of this attribute is of the predefined type Boolean. ;  S'Signed_Zeros : <span id="I5409"></span><span id="I5410"></span>Yields the value True if the hardware representation for the type ''T'' has the capability of representing both positively and negatively signed zeros, these being generated and used by the predefined operations of the type ''T'' as specified in IEC 559:1989; yields the value False otherwise. The value of this attribute is of the predefined type Boolean. <span id="I5411"></span>For every value ''x'' of a floating point type ''T'', the ''normalized exponent'' of ''x'' is defined as follows: * the normalized exponent of zero is (by convention) zero; * for nonzero ''x'', the normalized exponent of ''x'' is the unique integer ''k'' such that ''T'''Machine_Radix<sup>''k''-1</sup> <= |''x''| < ''T'''Machine_Radix<sup>''k''</sup>. <span id="I5412"></span>The following ''primitive function attributes'' are defined for any subtype S of a floating point type ''T''. ;  S'Exponent : <span id="I5413"></span><span id="I5414"></span>S'Exponent denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Exponent (X : T)   return universal_integer</syntaxhighlight></p> <p><span></span></p> :The function yields the normalized exponent of ''X''. ;  S'Fraction : <span id="I5415"></span><span id="I5416"></span>S'Fraction denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Fraction (X : T)   return T</syntaxhighlight></p> <p><span></span></p> :The function yields the value ''X'' · ''T'''Machine_Radix<sup>-''k''</sup>, where ''k'' is the normalized exponent of ''X''. A zero result, which can only occur when ''X'' is zero, has the sign of ''X''. ;  S'Compose : <span id="I5417"></span><span id="I5418"></span>S'Compose denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Compose (Fraction : T;                  Exponent : universal_integer)   return T</syntaxhighlight></p> <p><span></span></p> :<span id="I5419"></span>Let ''v'' be the value ''Fraction'' · ''T'''Machine_Radix<sup>''Exponent''-''k''</sup>, where ''k'' is the normalized exponent of ''Fraction''. If ''v'' is a machine number of the type ''T'', or if |''v''| >= ''T'''Model_Small, the function yields ''v''; otherwise, it yields either one of the machine numbers of the type ''T'' adjacent to ''v''. <span id="I5420"></span><span id="I5421"></span>Constraint_Error is optionally raised if ''v'' is outside the base range of S. A zero result has the sign of ''Fraction'' when S'Signed_Zeros is True. ;  S'Scaling : <span id="I5422"></span><span id="I5423"></span>S'Scaling denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Scaling (X : T;                  Adjustment : universal_integer)   return T</syntaxhighlight></p> <p><span></span></p> :<span id="I5424"></span>Let ''v'' be the value ''X'' · ''T'''Machine_Radix<sup>''Adjustment''</sup>. If ''v'' is a machine number of the type ''T'', or if |''v''| >= ''T'''Model_Small, the function yields ''v''; otherwise, it yields either one of the machine numbers of the type ''T'' adjacent to ''v''. <span id="I5425"></span><span id="I5426"></span>Constraint_Error is optionally raised if ''v'' is outside the base range of S. A zero result has the sign of ''X'' when S'Signed_Zeros is True. ;  S'Floor : <span id="I5427"></span><span id="I5428"></span>S'Floor denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Floor (X : T)   return T</syntaxhighlight></p> <p><span></span></p> :The function yields the value ''Floor''(''X''), i.e., the largest (most positive) integral value less than or equal to ''X''. When ''X'' is zero, the result has the sign of ''X''; a zero result otherwise has a positive sign. ;  S'Ceiling : <span id="I5429"></span><span id="I5430"></span>S'Ceiling denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Ceiling (X : T)   return T</syntaxhighlight></p> <p><span></span></p> :The function yields the value ''Ceiling''(''X''), i.e., the smallest (most negative) integral value greater than or equal to ''X''. When ''X'' is zero, the result has the sign of ''X''; a zero result otherwise has a negative sign when S'Signed_Zeros is True. ;  S'Rounding : <span id="I5431"></span><span id="I5432"></span>S'Rounding denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Rounding (X : T)   return T</syntaxhighlight></p> <p><span></span></p> :The function yields the integral value nearest to ''X'', rounding away from zero if ''X'' lies exactly halfway between two integers. A zero result has the sign of ''X'' when S'Signed_Zeros is True. ;  S'Unbiased_Rounding : <span id="I5433"></span><span id="I5434"></span>S'Unbiased_Rounding denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Unbiased_Rounding (X : T)   return T</syntaxhighlight></p> <p><span></span></p> :The function yields the integral value nearest to ''X'', rounding toward the even integer if ''X'' lies exactly halfway between two integers. A zero result has the sign of ''X'' when S'Signed_Zeros is True. ;  S'Truncation : <span id="I5435"></span><span id="I5436"></span>S'Truncation denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Truncation (X : T)   return T</syntaxhighlight></p> <p><span></span></p> :The function yields the value ''Ceiling''(''X'') when ''X'' is negative, and ''Floor''(''X'') otherwise. A zero result has the sign of ''X'' when S'Signed_Zeros is True. ;  S'Remainder : <span id="I5437"></span><span id="I5438"></span>S'Remainder denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Remainder (X, Y : T)   return T</syntaxhighlight></p> <p><span></span></p> :<span id="I5439"></span>For nonzero ''Y'', let ''v'' be the value ''X'' - ''n'' · ''Y'', where ''n'' is the integer nearest to the exact value of ''X''/''Y''; if |''n'' - ''X''/''Y''| = 1/2, then ''n'' is chosen to be even. If ''v'' is a machine number of the type ''T'', the function yields ''v''; otherwise, it yields zero. <span id="I5440"></span><span id="I5441"></span>Constraint_Error is raised if ''Y'' is zero. A zero result has the sign of ''X'' when S'Signed_Zeros is True. ;  S'Adjacent : <span id="I5442"></span><span id="I5443"></span>S'Adjacent denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Adjacent (X, Towards : T)   return T</syntaxhighlight></p> <p><span></span></p> :<span id="I5444"></span>If ''Towards'' = ''X'', the function yields ''X''; otherwise, it yields the machine number of the type ''T'' adjacent to ''X'' in the direction of ''Towards'', if that machine number exists. <span id="I5445"></span><span id="I5446"></span>If the result would be outside the base range of S, Constraint_Error is raised. When ''T'''Signed_Zeros is True, a zero result has the sign of ''X''. When ''Towards'' is zero, its sign has no bearing on the result. ;  S'Copy_Sign : <span id="I5447"></span><span id="I5448"></span>S'Copy_Sign denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Copy_Sign (Value, Sign : T)   return T</syntaxhighlight></p> <p><span></span></p> :<span id="I5449"></span>If the value of ''Value'' is nonzero, the function yields a result whose magnitude is that of ''Value'' and whose sign is that of ''Sign''; otherwise, it yields the value zero. <span id="I5450"></span><span id="I5451"></span>Constraint_Error is optionally raised if the result is outside the base range of S. A zero result has the sign of ''Sign'' when S'Signed_Zeros is True. ;  S'Leading_Part : <span id="I5452"></span><span id="I5453"></span>S'Leading_Part denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Leading_Part (X : T;                       Radix_Digits : universal_integer)   return T</syntaxhighlight></p> <p><span></span></p> :Let ''v'' be the value ''T'''Machine_Radix<sup>''k''-''Radix_Digits''</sup>, where ''k'' is the normalized exponent of ''X''. The function yields the value <p><span></span></p> :* ''Floor''(''X''/''v'') · ''v'', when ''X'' is nonnegative and ''Radix_Digits'' is positive; <p><span></span></p> :* ''Ceiling''(''X''/''v'') · ''v'', when ''X'' is negative and ''Radix_Digits'' is positive. <p><span></span></p> :<span id="I5454"></span><span id="I5455"></span><span id="I5456"></span>Constraint_Error is raised when ''Radix_Digits'' is zero or negative. A zero result, which can only occur when ''X'' is zero, has the sign of ''X''. ;  S'Machine : <span id="I5457"></span><span id="I5458"></span>S'Machine denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Machine (X : T)   return T</syntaxhighlight></p> <p><span></span></p> :<span id="I5459"></span>If ''X'' is a machine number of the type ''T'', the function yields ''X''; otherwise, it yields the value obtained by rounding or truncating ''X'' to either one of the adjacent machine numbers of the type ''T''. <span id="I5460"></span><span id="I5461"></span>Constraint_Error is raised if rounding or truncating ''X'' to the precision of the machine numbers results in a value outside the base range of S. A zero result has the sign of ''X'' when S'Signed_Zeros is True. <span id="I5462"></span>The following ''model-oriented attributes'' are defined for any subtype S of a floating point type ''T''. ;  S'Model_Mantissa : <span id="I5463"></span><span id="I5464"></span>If the Numerics Annex is not supported, this attribute yields an implementation defined value that is greater than or equal to ''Ceiling''(''d'' · log(10) / log(''T'''Machine_Radix)) + 1, where ''d'' is the requested decimal precision of ''T'', and less than or equal to the value of ''T'''Machine_Mantissa. See [[Guide:95lrm/RM-G-2-2|G.2.2]] for further requirements that apply to implementations supporting the Numerics Annex. The value of this attribute is of the type ''universal_integer''. ;  S'Model_Emin : <span id="I5465"></span><span id="I5466"></span>If the Numerics Annex is not supported, this attribute yields an implementation defined value that is greater than or equal to the value of ''T'''Machine_Emin. See [[Guide:95lrm/RM-G-2-2|G.2.2]] for further requirements that apply to implementations supporting the Numerics Annex. The value of this attribute is of the type ''universal_integer''. ;  S'Model_Epsilon : <span id="I5467"></span><span id="I5468"></span>Yields the value ''T'''Machine_Radix<sup>1 - ''T'''Model_Mantissa</sup>. The value of this attribute is of the type ''universal_real''. ;  S'Model_Small : <span id="I5469"></span><span id="I5470"></span>Yields the value ''T'''Machine_Radix<sup>''T'''Model_Emin - 1</sup>. The value of this attribute is of the type ''universal_real''. ;  S'Model : <span id="I5471"></span><span id="I5472"></span>S'Model denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Model (X : T)   return T</syntaxhighlight></p> <p><span></span></p> :If the Numerics Annex is not supported, the meaning of this attribute is implementation defined; see [[Guide:95lrm/RM-G-2-2|G.2.2]] for the definition that applies to implementations supporting the Numerics Annex. ;  S'Safe_First : <span id="I5473"></span><span id="I5474"></span>Yields the lower bound of the safe range (see [[Guide:95lrm/RM-3-5-7|3.5.7]]) of the type ''T''. If the Numerics Annex is not supported, the value of this attribute is implementation defined; see [[Guide:95lrm/RM-G-2-2|G.2.2]] for the definition that applies to implementations supporting the Numerics Annex. The value of this attribute is of the type ''universal_real''. ;  S'Safe_Last : <span id="I5475"></span><span id="I5476"></span>Yields the upper bound of the safe range (see [[Guide:95lrm/RM-3-5-7|3.5.7]]) of the type ''T''. If the Numerics Annex is not supported, the value of this attribute is implementation defined; see [[Guide:95lrm/RM-G-2-2|G.2.2]] for the definition that applies to implementations supporting the Numerics Annex. The value of this attribute is of the type ''universal_real''. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-5-2|Previous]] | [[Guide:95lrm/RM-A-5-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 8qe10p774wcq6an1orpcrgmjlacierv Guide:95lrm/RM-A-5-4 4200 1104 4376 2019-04-29T15:48:22Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-5-3|Previous]] | [[Guide:95lrm/RM-A-6|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.5.4 Attributes of Fixed Point Types}} == Static Semantics == <span id="I5477"></span>The following ''representation-oriented'' attributes are defined for every subtype S of a fixed point type ''T''. ; S'Machine_Radix : <span id="I5478"></span><span id="I5479"></span>Yields the radix of the hardware representation of the type ''T''. The value of this attribute is of the type ''universal_integer''. ; S'Machine_Rounds : <span id="I5480"></span><span id="I5481"></span>Yields the value True if rounding is performed on inexact results of every predefined operation that yields a result of the type ''T''; yields the value False otherwise. The value of this attribute is of the predefined type Boolean. ; S'Machine_Overflows : <span id="I5482"></span><span id="I5483"></span>Yields the value True if overflow and divide-by-zero are detected and reported by raising Constraint_Error for every predefined operation that yields a result of the type ''T''; yields the value False otherwise. The value of this attribute is of the predefined type Boolean. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-5-3|Previous]] | [[Guide:95lrm/RM-A-6|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} njhd158er2t1lus729t7fbqzsc0o3zy Guide:95lrm/RM-A-6 4200 1105 4377 2019-04-29T15:48:22Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-5-4|Previous]] | [[Guide:95lrm/RM-A-7|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.6 Input-Output}} <span id="I5484"></span><span id="I5485"></span>Input-output is provided through language-defined packages, each of which is a child of the root package Ada. The generic packages Sequential_IO and Direct_IO define input-output operations applicable to files containing elements of a given type. The generic package Storage_IO supports reading from and writing to an in-memory buffer. Additional operations for text input-output are supplied in the packages Text_IO and Wide_Text_IO. Heterogeneous input-output is provided through the child packages Streams.Stream_IO and Text_IO.Text_Streams (see also [[Guide:95lrm/RM-13-13|13.13]]). The package IO_Exceptions defines the exceptions needed by the predefined input-output packages. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-5-4|Previous]] | [[Guide:95lrm/RM-A-7|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} cgou2tt0ycc2078q7ktiw43tgrz5c9l Guide:95lrm/RM-A-7 4200 1106 4378 2019-05-01T16:33:38Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-6|Previous]] | [[Guide:95lrm/RM-A-8|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.7 External Files and File Objects}} == Static Semantics == <span id="I5486"></span><span id="I5487"></span><span id="I5488"></span>Values input from the external environment of the program, or output to the external environment, are considered to occupy ''external files''. An external file can be anything external to the program that can produce a value to be read or receive a value to be written. An external file is identified by a string (the ''name''). A second string (the ''form'') gives further system-dependent characteristics that may be associated with the file, such as the physical organization or access rights. The conventions governing the interpretation of such strings shall be documented. <span id="I5489"></span>Input and output operations are expressed as operations on objects of some ''file type'', rather than directly in terms of the external files. In the remainder of this section, the term ''file'' is always used to refer to a file object; the term ''external file'' is used otherwise. Input-output for sequential files of values of a single element type is defined by means of the generic package Sequential_IO. In order to define sequential input-output for a given element type, an instantiation of this generic unit, with the given type as actual parameter, has to be declared. The resulting package contains the declaration of a file type (called File_Type) for files of such elements, as well as the operations applicable to these files, such as the Open, Read, and Write procedures. Input-output for direct access files is likewise defined by a generic package called Direct_IO. Input-output in human-readable form is defined by the (nongeneric) packages Text_IO for Character and String data, and Wide_Text_IO for Wide_Character and Wide_String data. Input-output for files containing streams of elements representing values of possibly different types is defined by means of the (nongeneric) package Streams.Stream_IO. Before input or output operations can be performed on a file, the file first has to be associated with an external file. While such an association is in effect, the file is said to be ''open'', and otherwise the file is said to be ''closed''. The language does not define what happens to external files after the completion of the main program and all the library tasks (in particular, if corresponding files have not been closed). <span id="I5490"></span><span id="I5491"></span><span id="I5492"></span>The effect of input-output for access types is unspecified. <span id="I5493"></span>An open file has a ''current mode'', which is a value of one of the following enumeration types: <p><syntaxhighlight lang="Ada"> type File_Mode is (In_File, Inout_File, Out_File);  --  for Direct_IO</syntaxhighlight></p> <p><span></span></p> :These values correspond respectively to the cases where only reading, both reading and writing, or only writing are to be performed. <p><syntaxhighlight lang="Ada"> type File_Mode is (In_File, Out_File, Append_File); --  for Sequential_IO, Text_IO, Wide_Text_IO, and Stream_IO</syntaxhighlight></p> <p><span></span></p> :These values correspond respectively to the cases where only reading, only writing, or only appending are to be performed. <p><span></span></p> :The mode of a file can be changed. Several file management operations are common to Sequential_IO, Direct_IO, Text_IO, and Wide_Text_IO. These operations are described in subclause [[Guide:95lrm/RM-A-8-2|A.8.2]] for sequential and direct files. Any additional effects concerning text input-output are described in subclause [[Guide:95lrm/RM-A-10-2|A.10.2]]. The exceptions that can be propagated by the execution of an input-output subprogram are defined in the package IO_Exceptions; the situations in which they can be propagated are described following the description of the subprogram (and in clause [[Guide:95lrm/RM-A-13|A.13]]). <span id="I5494"></span><span id="I5495"></span>The exceptions Storage_Error and Program_Error may be propagated. (Program_Error can only be propagated due to errors made by the caller of the subprogram.) Finally, exceptions can be propagated in certain implementation-defined situations. == Notes == 18  Each instantiation of the generic packages Sequential_IO and Direct_IO declares a different type File_Type. In the case of Text_IO, Wide_Text_IO, and Streams.Stream_IO, the corresponding type File_Type is unique. 19  A bidirectional device can often be modeled as two sequential files associated with the device, one of mode In_File, and one of mode Out_File. An implementation may restrict the number of files that may be associated with a given external file. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-6|Previous]] | [[Guide:95lrm/RM-A-8|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 19xjf9wp8j5iabynhrwypv5te4s76v7 Guide:95lrm/RM-A-8 4200 1107 4379 2019-04-29T15:48:22Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-7|Previous]] | [[Guide:95lrm/RM-A-8-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.8 Sequential and Direct Files}} == Static Semantics == <span id="I5496"></span><span id="I5497"></span>Two kinds of access to external files are defined in this subclause: ''sequential access'' and ''direct access''. The corresponding file types and the associated operations are provided by the generic packages Sequential_IO and Direct_IO. A file object to be used for sequential access is called a ''sequential file'', and one to be used for direct access is called a ''direct file''. Access to stream files is described in [[Guide:95lrm/RM-A-12-1|A.12.1]]. <span id="I5498"></span>For sequential access, the file is viewed as a sequence of values that are transferred in the order of their appearance (as produced by the program or by the external environment). When the file is opened with mode In_File or Out_File, transfer starts respectively from or to the beginning of the file. When the file is opened with mode Append_File, transfer to the file starts after the last element of the file. <span id="I5499"></span><span id="I5500"></span><span id="I5501"></span>For direct access, the file is viewed as a set of elements occupying consecutive positions in linear order; a value can be transferred to or from an element of the file at any selected position. The position of an element is specified by its ''index'', which is a number, greater than zero, of the implementation-defined integer type Count. The first element, if any, has index one; the index of the last element, if any, is called the ''current size''; the current size is zero if there are no elements. The current size is a property of the external file. <span id="I5502"></span>An open direct file has a ''current index'', which is the index that will be used by the next read or write operation. When a direct file is opened, the current index is set to one. The current index of a direct file is a property of a file object, not of an external file. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-7|Previous]] | [[Guide:95lrm/RM-A-8-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} smcjr7nxvwx406cgde65d27sylmh2xx Guide:95lrm/RM-A-8-1 4200 1108 4380 2019-05-01T16:36:43Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-8|Previous]] | [[Guide:95lrm/RM-A-8-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.8.1 The Generic Package Sequential_IO}} == Static Semantics == The generic library package Sequential_IO has the following declaration: <p><syntaxhighlight lang="Ada"> with Ada.IO_Exceptions; generic type Element_Type(<>) is private; package Ada.Sequential_IO is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type File_Type is limited private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type File_Mode is (In_File, Out_File, Append_File);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- File management</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Create(File : in out File_Type;                  Mode : in File_Mode := Out_File;                  Name : in String := "";                  Form : in String := "");</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Open  (File : in out File_Type;                  Mode : in File_Mode;                  Name : in String;                  Form : in String := "");</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Close (File : in out File_Type); procedure Delete(File : in out File_Type); procedure Reset (File : in out File_Type; Mode : in File_Mode); procedure Reset (File : in out File_Type);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Mode   (File : in File_Type) return File_Mode; function Name   (File : in File_Type) return String; function Form   (File : in File_Type) return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Is_Open(File : in File_Type) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Input and output operations</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Read  (File : in File_Type; Item : out Element_Type); procedure Write (File : in File_Type; Item : in Element_Type);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function End_Of_File(File : in File_Type) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Exceptions</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Status_Error : exception renames IO_Exceptions.Status_Error; Mode_Error   : exception renames IO_Exceptions.Mode_Error; Name_Error   : exception renames IO_Exceptions.Name_Error; Use_Error    : exception renames IO_Exceptions.Use_Error; Device_Error : exception renames IO_Exceptions.Device_Error; End_Error    : exception renames IO_Exceptions.End_Error; Data_Error   : exception renames IO_Exceptions.Data_Error;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> private ... -- not specified by the language end Ada.Sequential_IO;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-8|Previous]] | [[Guide:95lrm/RM-A-8-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} bylquuom7gcfrw98du00sxyk27vsrz7 Guide:95lrm/RM-A-8-2 4200 1109 4381 2019-05-01T16:40:06Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-8-1|Previous]] | [[Guide:95lrm/RM-A-8-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.8.2 File Management}} == Static Semantics == The procedures and functions described in this subclause provide for the control of external files; their declarations are repeated in each of the packages for sequential, direct, text, and stream input-output. For text input-output, the procedures Create, Open, and Reset have additional effects described in subclause [[Guide:95lrm/RM-A-10-2|A.10.2]]. <p><syntaxhighlight lang="Ada"> procedure Create(File : in out File_Type;               Mode : in File_Mode := default_mode;               Name : in String := "";               Form : in String := "");</syntaxhighlight></p> <p><span></span></p> :Establishes a new external file, with the given name and form, and associates this external file with the given file. The given file is left open. The current mode of the given file is set to the given access mode. The default access mode is the mode Out_File for sequential and text input-output; it is the mode Inout_File for direct input-output. For direct access, the size of the created file is implementation defined. <p><span></span></p> :A null string for Name specifies an external file that is not accessible after the completion of the main program (a temporary file). A null string for Form specifies the use of the default options of the implementation for the external file. <p><span></span></p> :The exception Status_Error is propagated if the given file is already open. The exception Name_Error is propagated if the string given as Name does not allow the identification of an external file. The exception Use_Error is propagated if, for the specified mode, the external environment does not support creation of an external file with the given name (in the absence of Name_Error) and form. <p><syntaxhighlight lang="Ada"> procedure Open(File : in out File_Type;             Mode : in File_Mode;             Name : in String;             Form : in String := "");</syntaxhighlight></p> <p><span></span></p> :Associates the given file with an existing external file having the given name and form, and sets the current mode of the given file to the given mode. The given file is left open. <p><span></span></p> :The exception Status_Error is propagated if the given file is already open. The exception Name_Error is propagated if the string given as Name does not allow the identification of an external file; in particular, this exception is propagated if no external file with the given name exists. The exception Use_Error is propagated if, for the specified mode, the external environment does not support opening for an external file with the given name (in the absence of Name_Error) and form. <p><syntaxhighlight lang="Ada"> procedure Close(File : in out File_Type);</syntaxhighlight></p> <p><span></span></p> :Severs the association between the given file and its associated external file. The given file is left closed. In addition, for sequential files, if the file being closed has mode Out_File or Append_File, then the last element written since the most recent open or reset is the last element that can be read from the file. If no elements have been written and the file mode is Out_File, then the closed file is empty. If no elements have been written and the file mode is Append_File, then the closed file is unchanged. <p><span></span></p> :The exception Status_Error is propagated if the given file is not open. <p><syntaxhighlight lang="Ada"> procedure Delete(File : in out File_Type);</syntaxhighlight></p> <p><span></span></p> :Deletes the external file associated with the given file. The given file is closed, and the external file ceases to exist. <p><span></span></p> :The exception Status_Error is propagated if the given file is not open. The exception Use_Error is propagated if deletion of the external file is not supported by the external environment. <p><syntaxhighlight lang="Ada"> procedure Reset(File : in out File_Type; Mode : in File_Mode); procedure Reset(File : in out File_Type);</syntaxhighlight></p> <p><span></span></p> :Resets the given file so that reading from its elements can be restarted from the beginning of the file (for modes In_File and Inout_File), and so that writing to its elements can be restarted at the beginning of the file (for modes Out_File and Inout_File) or after the last element of the file (for mode Append_File). In particular, for direct access this means that the current index is set to one. If a Mode parameter is supplied, the current mode of the given file is set to the given mode. In addition, for sequential files, if the given file has mode Out_File or Append_File when Reset is called, the last element written since the most recent open or reset is the last element that can be read from the file. If no elements have been written and the file mode is Out_File, the reset file is empty. If no elements have been written and the file mode is Append_File, then the reset file is unchanged. <p><span></span></p> :The exception Status_Error is propagated if the file is not open. The exception Use_Error is propagated if the external environment does not support resetting for the external file and, also, if the external environment does not support resetting to the specified mode for the external file. <p><syntaxhighlight lang="Ada"> function Mode(File : in File_Type) return File_Mode;</syntaxhighlight></p> <p><span></span></p> :Returns the current mode of the given file. <p><span></span></p> :The exception Status_Error is propagated if the file is not open. <p><syntaxhighlight lang="Ada"> function Name(File : in File_Type) return String;</syntaxhighlight></p> <p><span></span></p> :Returns a string which uniquely identifies the external file currently associated with the given file (and may thus be used in an Open operation). If an external environment allows alternative specifications of the name (for example, abbreviations), the string returned by the function should correspond to a full specification of the name. <p><span></span></p> :The exception Status_Error is propagated if the given file is not open. The exception Use_Error is propagated if the associated external file is a temporary file that cannot be opened by any name. <p><syntaxhighlight lang="Ada"> function Form(File : in File_Type) return String;</syntaxhighlight></p> <p><span></span></p> :Returns the form string for the external file currently associated with the given file. If an external environment allows alternative specifications of the form (for example, abbreviations using default options), the string returned by the function should correspond to a full specification (that is, it should indicate explicitly all options selected, including default options). <p><span></span></p> :The exception Status_Error is propagated if the given file is not open. <p><syntaxhighlight lang="Ada"> function Is_Open(File : in File_Type) return Boolean;</syntaxhighlight></p> <p><span></span></p> :Returns True if the file is open (that is, if it is associated with an external file), otherwise returns False. == Implementation Permissions == An implementation may propagate Name_Error or Use_Error if an attempt is made to use an I/O feature that cannot be supported by the implementation due to limitations in the external environment. Any such restriction should be documented. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-8-1|Previous]] | [[Guide:95lrm/RM-A-8-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 7rcez0f8tpmaf7ohv18up7jcmddumoo Guide:95lrm/RM-A-8-3 4200 1110 4382 2019-05-01T16:41:19Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-8-2|Previous]] | [[Guide:95lrm/RM-A-8-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.8.3 Sequential Input-Output Operations}} == Static Semantics == The operations available for sequential input and output are described in this subclause. The exception Status_Error is propagated if any of these operations is attempted for a file that is not open. <p><syntaxhighlight lang="Ada"> procedure Read(File : in File_Type; Item : out Element_Type);</syntaxhighlight></p> <p><span></span></p> :Operates on a file of mode In_File. Reads an element from the given file, and returns the value of this element in the Item parameter. <p><span></span></p> :The exception Mode_Error is propagated if the mode is not In_File. The exception End_Error is propagated if no more elements can be read from the given file. The exception Data_Error can be propagated if the element read cannot be interpreted as a value of the subtype Element_Type (see [[Guide:95lrm/RM-A-13|A.13]], ''[[Guide:95lrm/RM-A-13|Exceptions in Input-Output]]''). <p><syntaxhighlight lang="Ada"> procedure Write(File : in File_Type; Item : in Element_Type);</syntaxhighlight></p> <p><span></span></p> :Operates on a file of mode Out_File or Append_File. Writes the value of Item to the given file. <p><span></span></p> :The exception Mode_Error is propagated if the mode is not Out_File or Append_File. The exception Use_Error is propagated if the capacity of the external file is exceeded. <p><syntaxhighlight lang="Ada"> function End_Of_File(File : in File_Type) return Boolean;</syntaxhighlight></p> <p><span></span></p> :Operates on a file of mode In_File. Returns True if no more elements can be read from the given file; otherwise returns False. <p><span></span></p> :The exception Mode_Error is propagated if the mode is not In_File. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-8-2|Previous]] | [[Guide:95lrm/RM-A-8-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 4q6p2dx2qypqz9r6llgb6xuf845xccv Guide:95lrm/RM-A-8-4 4200 1111 4383 2019-05-01T16:44:37Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-8-3|Previous]] | [[Guide:95lrm/RM-A-8-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.8.4 The Generic Package Direct_IO}} == Static Semantics == The generic library package Direct_IO has the following declaration: <p><syntaxhighlight lang="Ada"> with Ada.IO_Exceptions; generic type Element_Type is private; package Ada.Direct_IO is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type File_Type is limited private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type File_Mode is (In_File, Inout_File, Out_File); type Count     is range 0 .. implementation-defined; subtype Positive_Count is Count range 1 .. Count'Last;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- File management</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Create(File : in out File_Type;                  Mode : in File_Mode := Inout_File;                  Name : in String := "";                  Form : in String := "");</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Open  (File : in out File_Type;                  Mode : in File_Mode;                  Name : in String;                  Form : in String := "");</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Close (File : in out File_Type); procedure Delete(File : in out File_Type); procedure Reset (File : in out File_Type; Mode : in File_Mode); procedure Reset (File : in out File_Type);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Mode   (File : in File_Type) return File_Mode; function Name   (File : in File_Type) return String; function Form   (File : in File_Type) return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function Is_Open(File : in File_Type) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Input and output operations</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Read (File : in File_Type; Item : out Element_Type;                                      From : in Positive_Count); procedure Read (File : in File_Type; Item : out Element_Type);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Write(File : in File_Type; Item : in  Element_Type;                                      To   : in Positive_Count); procedure Write(File : in File_Type; Item : in Element_Type);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Set_Index(File : in File_Type; To : in Positive_Count);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Index(File : in File_Type) return Positive_Count; function Size (File : in File_Type) return Count;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function End_Of_File(File : in File_Type) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Exceptions</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   Status_Error : exception renames IO_Exceptions.Status_Error; Mode_Error   : exception renames IO_Exceptions.Mode_Error; Name_Error   : exception renames IO_Exceptions.Name_Error; Use_Error    : exception renames IO_Exceptions.Use_Error; Device_Error : exception renames IO_Exceptions.Device_Error; End_Error    : exception renames IO_Exceptions.End_Error; Data_Error   : exception renames IO_Exceptions.Data_Error;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> private ... -- not specified by the language end Ada.Direct_IO;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-8-3|Previous]] | [[Guide:95lrm/RM-A-8-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} rx1cc4mic85tgm8cigigyfe18m2n1s2 Guide:95lrm/RM-A-8-5 4200 1112 4384 2019-05-01T16:46:42Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-8-4|Previous]] | [[Guide:95lrm/RM-A-9|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.8.5 Direct Input-Output Operations}} == Static Semantics == The operations available for direct input and output are described in this subclause. The exception Status_Error is propagated if any of these operations is attempted for a file that is not open. <p><syntaxhighlight lang="Ada"> procedure Read(File : in File_Type; Item : out Element_Type;                                  From : in  Positive_Count); procedure Read(File : in File_Type; Item : out Element_Type);</syntaxhighlight></p> <p><span></span></p> :Operates on a file of mode In_File or Inout_File. In the case of the first form, sets the current index of the given file to the index value given by the parameter From. Then (for both forms) returns, in the parameter Item, the value of the element whose position in the given file is specified by the current index of the file; finally, increases the current index by one. <p><span></span></p> :The exception Mode_Error is propagated if the mode of the given file is Out_File. The exception End_Error is propagated if the index to be used exceeds the size of the external file. The exception Data_Error can be propagated if the element read cannot be interpreted as a value of the subtype Element_Type (see [[Guide:95lrm/RM-A-13|A.13]]). <p><syntaxhighlight lang="Ada"> procedure Write(File : in File_Type; Item : in Element_Type;                                   To   : in Positive_Count); procedure Write(File : in File_Type; Item : in Element_Type);</syntaxhighlight></p> <p><span></span></p> :Operates on a file of mode Inout_File or Out_File. In the case of the first form, sets the index of the given file to the index value given by the parameter To. Then (for both forms) gives the value of the parameter Item to the element whose position in the given file is specified by the current index of the file; finally, increases the current index by one. <p><span></span></p> :The exception Mode_Error is propagated if the mode of the given file is In_File. The exception Use_Error is propagated if the capacity of the external file is exceeded. <p><syntaxhighlight lang="Ada"> procedure Set_Index(File : in File_Type; To : in Positive_Count);</syntaxhighlight></p> <p><span></span></p> :Operates on a file of any mode. Sets the current index of the given file to the given index value (which may exceed the current size of the file). <p><syntaxhighlight lang="Ada"> function Index(File : in File_Type) return Positive_Count;</syntaxhighlight></p> <p><span></span></p> :Operates on a file of any mode. Returns the current index of the given file. <p><syntaxhighlight lang="Ada"> function Size(File : in File_Type) return Count;</syntaxhighlight></p> <p><span></span></p> :Operates on a file of any mode. Returns the current size of the external file that is associated with the given file. <p><syntaxhighlight lang="Ada"> function End_Of_File(File : in File_Type) return Boolean;</syntaxhighlight></p> <p><span></span></p> :Operates on a file of mode In_File or Inout_File. Returns True if the current index exceeds the size of the external file; otherwise returns False. <p><span></span></p> :The exception Mode_Error is propagated if the mode of the given file is Out_File. == Notes == 20  Append_File mode is not supported for the generic package Direct_IO. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-8-4|Previous]] | [[Guide:95lrm/RM-A-9|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} ms9jdu1iurt6tp8hgw9f5c0iidef002 Guide:95lrm/RM-A-9 4200 1113 4385 2019-05-01T16:48:29Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-8-5|Previous]] | [[Guide:95lrm/RM-A-10|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: A.9 The Generic Package Storage_IO}} The generic package Storage_IO provides for reading from and writing to an in-memory buffer. This generic package supports the construction of user-defined input-output packages. == Static Semantics == The generic library package Storage_IO has the following declaration: <p><syntaxhighlight lang="Ada"> with Ada.IO_Exceptions; with System.Storage_Elements; generic type Element_Type is private; package Ada.Storage_IO is pragma Preelaborate(Storage_IO);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Buffer_Size : constant System.Storage_Elements.Storage_Count :=    implementation-defined; subtype Buffer_Type is    System.Storage_Elements.Storage_Array(1..Buffer_Size);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Input and output operations</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Read (Buffer : in  Buffer_Type; Item : out Element_Type);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Write(Buffer : out Buffer_Type; Item : in  Element_Type);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Exceptions</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Data_Error   : exception renames IO_Exceptions.Data_Error; end Ada.Storage_IO;</syntaxhighlight></p> In each instance, the constant Buffer_Size has a value that is the size (in storage elements) of the buffer required to represent the content of an object of subtype Element_Type, including any implicit levels of indirection used by the implementation. The Read and Write procedures of Storage_IO correspond to the Read and Write procedures of Direct_IO (see [[Guide:95lrm/RM-A-8-4|A.8.4]]), but with the content of the Item parameter being read from or written into the specified Buffer, rather than an external file. == Notes == 21  A buffer used for Storage_IO holds only one element at a time; an external file used for Direct_IO holds a sequence of elements. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-8-5|Previous]] | [[Guide:95lrm/RM-A-10|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 177hooffrpdnzia2ig9y8vhts72hg4m Guide:95lrm/RM-B 4200 1114 4386 2019-05-01T17:59:44Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-15|Previous]] | [[Guide:95lrm/RM-B-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Annex B. Interface to Other Languages}} <div> (normative) </div> <span id="I6023"></span><span id="I6024"></span><span id="I6025"></span>This Annex describes features for writing mixed-language programs. General interface support is presented first; then specific support for C, COBOL, and Fortran is defined, in terms of language interface packages for each of these languages. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-A-15|Previous]] | [[Guide:95lrm/RM-B-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} q7on1s0h5nzpr3kkwb9wtukxnmy266a Guide:95lrm/RM-B-1 4200 1115 4387 2019-05-01T18:04:47Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-B|Previous]] | [[Guide:95lrm/RM-B-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: B.1 Interfacing Pragmas}} A pragma Import is used to import an entity defined in a foreign language into an Ada program, thus allowing a foreign-language subprogram to be called from Ada, or a foreign-language variable to be accessed from Ada. In contrast, a pragma Export is used to export an Ada entity to a foreign language, thus allowing an Ada subprogram to be called from a foreign language, or an Ada object to be accessed from a foreign language. The pragmas Import and Export are intended primarily for objects and subprograms, although implementations are allowed to support other entities. A pragma Convention is used to specify that an Ada entity should use the conventions of another language. It is intended primarily for types and ''callback'' subprograms. For example, '''''pragma''' Convention(Fortran, Matrix);'' implies that Matrix should be represented according to the conventions of the supported Fortran implementation, namely column-major order. A pragma Linker_Options is used to specify the system linker parameters needed when a given compilation unit is included in a partition. == Syntax == <span id="I6026"></span><span id="I6027"></span><span id="I6028"></span><span id="I6029"></span><span id="I6030"></span><span id="I6031"></span><span id="I6032"></span><span id="I6033"></span>An ''interfacing pragma'' is a representation pragma that is one of the pragmas Import, Export, or Convention. Their forms, together with that of the related pragma Linker_Options, are as follows: <p><span></span></p> '''pragma''' <span id="I6034"></span><span id="I6035"></span>Import( [Convention =>] ''convention_''<span id="I6036"></span>identifier, [Entity =>] <span id="I6037"></span>local_name [, [External_Name =>] ''string_''<span id="I6038"></span>expression] [, [Link_Name =>] ''string_''<span id="I6039"></span>expression]); <p><span></span></p> '''pragma''' <span id="I6040"></span><span id="I6041"></span>Export( [Convention =>] ''convention_''<span id="I6042"></span>identifier, [Entity =>] <span id="I6043"></span>local_name [, [External_Name =>] ''string_''<span id="I6044"></span>expression] [, [Link_Name =>] ''string_''<span id="I6045"></span>expression]); <p><span></span></p> '''pragma''' <span id="I6046"></span><span id="I6047"></span>Convention([Convention =>] ''convention_''<span id="I6048"></span>identifier,[Entity =>] <span id="I6049"></span>local_name); <p><span></span></p> '''pragma''' <span id="I6050"></span><span id="I6051"></span>Linker_Options(''string_''<span id="I6052"></span>expression); A pragma Linker_Options is allowed only at the place of a declarative_item. <div> For pragmas Import and Export, the argument for Link_Name shall not be given without the pragma_argument_identifier unless the argument for External_Name is given. </div> == Name Resolution Rules == <span id="I6053"></span>The expected type for a ''string_''<span id="I6054"></span>expression in an interfacing pragma or in pragma Linker_Options is String. == Legality Rules == <span id="I6055"></span>The ''convention_''identifier of an interfacing pragma shall be the name of a ''convention''. The convention names are implementation defined, except for certain language-defined ones, such as Ada and Intrinsic, as explained in [[Guide:95lrm/RM-6-3-1|6.3.1]], ''[[Guide:95lrm/RM-6-3-1|Conformance Rules]]''. Additional convention names generally represent the calling conventions of foreign languages, language implementations, or specific run-time models. <span id="I6056"></span>The convention of a callable entity is its ''calling convention''. <span id="I6057"></span>If ''L'' is a ''convention_''identifier for a language, then a type T is said to be ''compatible with convention L'', (alternatively, is said to be an ''L-compatible type'') if any of the following conditions are met: * T is declared in a language interface package corresponding to ''L'' and is defined to be ''L''-compatible (see [[Guide:95lrm/RM-B-3|B.3]], [[Guide:95lrm/RM-B-3-1|B.3.1]], [[Guide:95lrm/RM-B-3-2|B.3.2]], [[Guide:95lrm/RM-B-4|B.4]], [[Guide:95lrm/RM-B-5|B.5]]), * <span id="I6058"></span>Convention ''L'' has been specified for T in a pragma Convention, and T is ''eligible for convention L''; that is: <p><span></span></p> :* T is an array type with either an unconstrained or statically-constrained first subtype, and its component type is ''L''-compatible, <p><span></span></p> :* T is a record type that has no discriminants and that only has components with statically-constrained subtypes, and each component type is ''L''-compatible, <p><span></span></p> :* T is an access-to-object type, and its designated type is ''L''-compatible, <p><span></span></p> :* T is an access-to-subprogram type, and its designated profile's parameter and result types are all ''L''-compatible. * T is derived from an ''L''-compatible type, * The implementation permits T as an ''L''-compatible type. If pragma Convention applies to a type, then the type shall either be compatible with or eligible for the convention specified in the pragma. A pragma Import shall be the completion of a declaration. <span id="I6059"></span>Notwithstanding any rule to the contrary, a pragma Import may serve as the completion of any kind of (explicit) declaration if supported by an implementation for that kind of declaration. If a completion is a pragma Import, then it shall appear in the same declarative_part, package_specification, task_definition or protected_definition as the declaration. For a library unit, it shall appear in the same compilation, before any subsequent compilation_units other than pragmas. If the local_name denotes more than one entity, then the pragma Import is the completion of all of them. <span id="I6060"></span> <span id="I6061"></span>An entity specified as the Entity argument to a pragma Import (or pragma Export) is said to be ''imported'' (respectively, ''exported''). The declaration of an imported object shall not include an explicit initialization expression. Default initializations are not performed. The type of an imported or exported object shall be compatible with the convention specified in the corresponding pragma. For an imported or exported subprogram, the result and parameter types shall each be compatible with the convention specified in the corresponding pragma. The external name and link name ''string''_expressions of a pragma Import or Export, and the ''string''_expression of a pragma Linker_Options, shall be static. == Static Semantics == <span id="I6062"></span><span id="I6063"></span><span id="I6064"></span><span id="I6065"></span><span id="I6066"></span><span id="I6067"></span><span id="I6068"></span><span id="I6069"></span>Import, Export, and Convention pragmas are representation pragmas that specify the ''convention'' aspect of representation. <span id="I6070"></span><span id="I6071"></span><span id="I6072"></span><span id="I6073"></span>In addition, Import and Export pragmas specify the ''imported'' and ''exported'' aspects of representation, respectively. <span id="I6074"></span><span id="I6075"></span><span id="I6076"></span><span id="I6077"></span><span id="I6078"></span><span id="I6079"></span>An interfacing pragma is a program unit pragma when applied to a program unit (see [[Guide:95lrm/RM-10-1-5|10.1.5]]). An interfacing pragma defines the convention of the entity denoted by the local_name. The convention represents the calling convention or representation convention of the entity. For an access-to-subprogram type, it represents the calling convention of designated subprograms. In addition: * A pragma Import specifies that the entity is defined externally (that is, outside the Ada program). * A pragma Export specifies that the entity is used externally. * A pragma Import or Export optionally specifies an entity's external name, link name, or both. <span id="I6080"></span>An ''external name'' is a string value for the name used by a foreign language program either for an entity that an Ada program imports, or for referring to an entity that an Ada program exports. <span id="I6081"></span>A ''link name'' is a string value for the name of an exported or imported entity, based on the conventions of the foreign language's compiler in interfacing with the system's linker tool. The meaning of link names is implementation defined. If neither a link name nor the Address attribute of an imported or exported entity is specified, then a link name is chosen in an implementation-defined manner, based on the external name if one is specified. Pragma Linker_Options has the effect of passing its string argument as a parameter to the system linker (if one exists), if the immediately enclosing compilation unit is included in the partition being linked. The interpretation of the string argument, and the way in which the string arguments from multiple Linker_Options pragmas are combined, is implementation defined. == Dynamic Semantics == <span id="I6082"></span><span id="I6083"></span>Notwithstanding what this International Standard says elsewhere, the elaboration of a declaration denoted by the local_name of a pragma Import does not create the entity. Such an elaboration has no other effect than to allow the defining name to denote the external entity. == Implementation Advice == If an implementation supports pragma Export to a given language, then it should also allow the main subprogram to be written in that language. It should support some mechanism for invoking the elaboration of the Ada library units included in the system, and for invoking the finalization of the environment task. On typical systems, the recommended mechanism is to provide two subprograms whose link names are "adainit" and "adafinal". Adainit should contain the elaboration code for library units. Adafinal should contain the finalization code. These subprograms should have no effect the second and subsequent time they are called. <span id="I6084"></span><span id="I6085"></span><span id="I6086"></span><span id="I6087"></span> Automatic elaboration of preelaborated packages should be provided when pragma Export is supported. For each supported convention ''L'' other than Intrinsic, an implementation should support Import and Export pragmas for objects of ''L''-compatible types and for subprograms, and pragma Convention for ''L''-eligible types and for subprograms, presuming the other language has corresponding features. Pragma Convention need not be supported for scalar types. == Notes == 1  Implementations may place restrictions on interfacing pragmas; for example, requiring each exported entity to be declared at the library level. 2  A pragma Import specifies the conventions for accessing external entities. It is possible that the actual entity is written in assembly language, but reflects the conventions of a particular language. For example, '''pragma''' Import(Ada, ...) can be used to interface to an assembly language routine that obeys the Ada compiler's calling conventions. 3  To obtain ''call-back'' to an Ada subprogram from a foreign language environment, '''pragma''' Convention should be specified both for the access-to-subprogram type and the specific subprogram(s) to which 'Access is applied. 4  It is illegal to specify more than one of Import, Export, or Convention for a given entity. 5  The local_name in an interfacing pragma can denote more than one entity in the case of overloading. Such a pragma applies to all of the denoted entities. 6  See also [[Guide:95lrm/RM-13-8|13.8]], ''[[Guide:95lrm/RM-13-8|Machine Code Insertions]]''. 7  If both External_Name and Link_Name are specified for an Import or Export pragma, then the External_Name is ignored. 8  An interfacing pragma might result in an effect that violates Ada semantics. == Examples == ''Example of interfacing pragmas:'' <p><syntaxhighlight lang="Ada"> package Fortran_Library is   function Sqrt (X : Float) return Float;   function Exp  (X : Float) return Float; private   pragma Import(Fortran, Sqrt);   pragma Import(Fortran, Exp); end Fortran_Library;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-B|Previous]] | [[Guide:95lrm/RM-B-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} r31ettjf6sxamhgk4sdm9qs8h5btvaf Guide:95lrm/RM-B-2 4200 1116 4388 2019-05-01T18:06:54Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-B-1|Previous]] | [[Guide:95lrm/RM-B-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: B.2 The Package Interfaces}} Package Interfaces is the parent of several library packages that declare types and other entities useful for interfacing to foreign languages. It also contains some implementation-defined types that are useful across more than one language (in particular for interfacing to assembly language). == Static Semantics == The library package Interfaces has the following skeletal declaration: <p><syntaxhighlight lang="Ada"> package Interfaces is pragma Pure(Interfaces);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Integer_n is range -2**(n-1) .. 2**(n-1) - 1;  --2's complement </syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Unsigned_n is mod 2**n;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Shift_Left  (Value : Unsigned_n; Amount : Natural)    return Unsigned_n; function Shift_Right (Value : Unsigned_n; Amount : Natural)    return Unsigned_n; function Shift_Right_Arithmetic (Value : Unsigned_n; Amount : Natural)    return Unsigned_n; function Rotate_Left  (Value : Unsigned_n; Amount : Natural)    return Unsigned_n; function Rotate_Right (Value : Unsigned_n; Amount : Natural)    return Unsigned_n; ...end Interfaces;</syntaxhighlight></p> == Implementation Requirements == An implementation shall provide the following declarations in the visible part of package Interfaces: * Signed and modular integer types of ''n'' bits, if supported by the target architecture, for each ''n'' that is at least the size of a storage element and that is a factor of the word size. The names of these types are of the form Integer_''n'' for the signed types, and Unsigned_''n'' for the modular types; * <span id="I6090"></span><span id="I6091"></span>For each such modular type in Interfaces, shifting and rotating subprograms as specified in the declaration of Interfaces above. These subprograms are Intrinsic. They operate on a bit-by-bit basis, using the binary representation of the value of the operands to yield a binary representation for the result. The Amount parameter gives the number of bits by which to shift or rotate. For shifting, zero bits are shifted in, except in the case of Shift_Right_Arithmetic, where one bits are shifted in if Value is at least half the modulus. * Floating point types corresponding to each floating point format fully supported by the hardware. == Implementation Permissions == An implementation may provide implementation-defined library units that are children of Interfaces, and may add declarations to the visible part of Interfaces in addition to the ones defined above. == Implementation Advice == For each implementation-defined convention identifier, there should be a child package of package Interfaces with the corresponding name. This package should contain any declarations that would be useful for interfacing to the language (implementation) represented by the convention. Any declarations useful for interfacing to any language on the given hardware architecture should be provided directly in Interfaces. An implementation supporting an interface to C, COBOL, or Fortran should provide the corresponding package or packages described in the following clauses. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-B-1|Previous]] | [[Guide:95lrm/RM-B-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} q627u28fxegdi9vitg6paajjr2ganyb Guide:95lrm/RM-B-3 4200 1117 4389 2019-05-01T18:23:14Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-B-2|Previous]] | [[Guide:95lrm/RM-B-3-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: B.3 Interfacing with C}} <span id="I6092"></span><span id="I6093"></span>The facilities relevant to interfacing with the C language are the package Interfaces.C and its children; support for the Import, Export, and Convention pragmas with ''convention''_identifier C; and support for the Convention pragma with ''convention''_identifier C_Pass_By_Copy. The package Interfaces.C contains the basic types, constants and subprograms that allow an Ada program to pass scalars and strings to C functions. == Static Semantics == The library package Interfaces.C has the following declaration: <p><syntaxhighlight lang="Ada"> package Interfaces.C is pragma Pure(C);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Declarations based on C's <limits.h></syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    CHAR_BIT  : constant := implementation-defined;  -- typically 8 SCHAR_MIN : constant := implementation-defined;  -- typically -128 SCHAR_MAX : constant := implementation-defined;  -- typically 127 UCHAR_MAX : constant := implementation-defined;  -- typically 255</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Signed and Unsigned Integers type int   is range implementation-defined; type short is range implementation-defined; type long  is range implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type signed_char is range SCHAR_MIN .. SCHAR_MAX; for signed_char'Size use CHAR_BIT;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type unsigned       is mod implementation-defined; type unsigned_short is mod implementation-defined; type unsigned_long  is mod implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type unsigned_char is mod (UCHAR_MAX+1); for unsigned_char'Size use CHAR_BIT;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    subtype plain_char is implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type ptrdiff_t is range implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type size_t is mod implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Floating Point</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type C_float     is digits implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type double      is digits implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type long_double is digits implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Characters and Strings </syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type char is <implementation-defined character type>;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    nul : constant char := implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_C   (Item : in Character) return char;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Ada (Item : in char) return Character;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     type char_array is array (size_t range <>) of aliased char; pragma Pack(char_array); for char_array'Component_Size use CHAR_BIT;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Is_Nul_Terminated (Item : in char_array) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_C   (Item       : in String;                  Append_Nul : in Boolean := True)    return char_array;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Ada (Item     : in char_array;                  Trim_Nul : in Boolean := True)    return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure To_C (Item       : in String;                 Target     : out char_array;                 Count      : out size_t;                 Append_Nul : in Boolean := True);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure To_Ada (Item     : in char_array;                   Target   : out String;                   Count    : out Natural;                   Trim_Nul : in Boolean := True);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Wide Character and Wide String</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type wchar_t is <implementation-defined character type>;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    wide_nul : constant wchar_t := implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_C   (Item : in Wide_Character) return wchar_t; function To_Ada (Item : in wchar_t       ) return Wide_Character;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type wchar_array is array (size_t range <>) of aliased wchar_t;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    pragma Pack(wchar_array);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Is_Nul_Terminated (Item : in wchar_array) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_C   (Item       : in Wide_String;                  Append_Nul : in Boolean := True)    return wchar_array;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Ada (Item     : in wchar_array;                  Trim_Nul : in Boolean := True)    return Wide_String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     procedure To_C (Item       : in  Wide_String;                 Target     : out wchar_array;                  Count      : out size_t;                  Append_Nul : in  Boolean := True);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure To_Ada (Item     : in  wchar_array;                   Target   : out Wide_String;                   Count    : out Natural;                   Trim_Nul : in  Boolean := True);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Terminator_Error : exception;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> end Interfaces.C;</syntaxhighlight></p> Each of the types declared in Interfaces.C is C-compatible. The types int, short, long, unsigned, ptrdiff_t, size_t, double, char, and wchar_t correspond respectively to the C types having the same names. The types signed_char, unsigned_short, unsigned_long, unsigned_char, C_float, and long_double correspond respectively to the C types signed char, unsigned short, unsigned long, unsigned char, float, and long double. The type of the subtype plain_char is either signed_char or unsigned_char, depending on the C implementation. <p><syntaxhighlight lang="Ada"> function To_C   (Item : in Character) return char; function To_Ada (Item : in char     ) return Character;</syntaxhighlight></p> <p><span></span></p> :The functions To_C and To_Ada map between the Ada type Character and the C type char. <p><syntaxhighlight lang="Ada"> function Is_Nul_Terminated (Item : in char_array) return Boolean;</syntaxhighlight></p> <p><span></span></p> :The result of Is_Nul_Terminated is True if Item contains nul, and is False otherwise. <p><syntaxhighlight lang="Ada"> function To_C   (Item : in String;     Append_Nul : in Boolean := True) return char_array; function To_Ada (Item : in char_array; Trim_Nul   : in Boolean := True) return String;</syntaxhighlight></p> <p><span></span></p> :The result of To_C is a char_array value of length Item'Length (if Append_Nul is False) or Item'Length+1 (if Append_Nul is True). The lower bound is 0. For each component Item(I), the corresponding component in the result is To_C applied to Item(I). The value nul is appended if Append_Nul is True. <p><span></span></p> :The result of To_Ada is a String whose length is Item'Length (if Trim_Nul is False) or the length of the slice of Item preceding the first nul (if Trim_Nul is True). The lower bound of the result is 1. If Trim_Nul is False, then for each component Item(I) the corresponding component in the result is To_Ada applied to Item(I). If Trim_Nul is True, then for each component Item(I) before the first nul the corresponding component in the result is To_Ada applied to Item(I). The function propagates Terminator_Error if Trim_Nul is True and Item does not contain nul. <p><syntaxhighlight lang="Ada"> procedure To_C (Item       : in String;              Target     : out char_array;              Count      : out size_t;              Append_Nul : in Boolean := True); procedure To_Ada (Item     : in char_array;                Target   : out String;                Count    : out Natural;             Trim_Nul : in Boolean := True);</syntaxhighlight></p> <p><span></span></p> :For procedure To_C, each element of Item is converted (via the To_C function) to a char, which is assigned to the corresponding element of Target. If Append_Nul is True, nul is then assigned to the next element of Target. In either case, Count is set to the number of Target elements assigned. <span id="I6168"></span>If Target is not long enough, Constraint_Error is propagated. <p><span></span></p> :For procedure To_Ada, each element of Item (if Trim_Nul is False) or each element of Item preceding the first nul (if Trim_Nul is True) is converted (via the To_Ada function) to a Character, which is assigned to the corresponding element of Target. Count is set to the number of Target elements assigned. <span id="I6169"></span>If Target is not long enough, Constraint_Error is propagated. If Trim_Nul is True and Item does not contain nul, then Terminator_Error is propagated. <p><syntaxhighlight lang="Ada"> function Is_Nul_Terminated (Item : in wchar_array) return Boolean;</syntaxhighlight></p> <p><span></span></p> :The result of Is_Nul_Terminated is True if Item contains wide_nul, and is False otherwise. <p><syntaxhighlight lang="Ada"> function To_C   (Item : in Wide_Character) return wchar_t; function To_Ada (Item : in wchar_t       ) return Wide_Character;</syntaxhighlight></p> <p><span></span></p> :To_C and To_Ada provide the mappings between the Ada and C wide character types. <p><syntaxhighlight lang="Ada"> function To_C   (Item       : in Wide_String;               Append_Nul : in Boolean := True) return wchar_array; function To_Ada (Item     : in wchar_array;               Trim_Nul : in Boolean := True) return Wide_String; procedure To_C (Item       : in Wide_String;              Target     : out wchar_array;              Count      : out size_t;              Append_Nul : in Boolean := True); procedure To_Ada (Item     : in wchar_array;                Target   : out Wide_String;                Count    : out Natural;                Trim_Nul : in Boolean := True);</syntaxhighlight></p> <p><span></span></p> :The To_C and To_Ada subprograms that convert between Wide_String and wchar_array have analogous effects to the To_C and To_Ada subprograms that convert between String and char_array, except that wide_nul is used instead of nul. <div> A Convention pragma with ''convention''_identifier C_Pass_By_Copy shall only be applied to a type. The eligibility rules in [[Guide:95lrm/RM-B-1|B.1]] do not apply to convention C_Pass_By_Copy. Instead, a type T is eligible for convention C_Pass_By_Copy if T is a record type that has no discriminants and that only has components with statically constrained subtypes, and each component is C-compatible. If a type is C_Pass_By_Copy-compatible then it is also C-compatible. </div> == Implementation Requirements == An implementation shall support pragma Convention with a C ''convention''_identifier for a C-eligible type (see [[Guide:95lrm/RM-B-1|B.1]]). An implementation shall support pragma Convention with a C_Pass_By_Copy ''convention''_identifier for a C_Pass_By_Copy-eligible type. == Implementation Permissions == An implementation may provide additional declarations in the C interface packages. == Implementation Advice == <div> The constants nul and wide_nul should have a representation of zero. </div> An implementation should support the following interface correspondences between Ada and C. * An Ada procedure corresponds to a void-returning C function. * An Ada function corresponds to a non-void C function. * An Ada '''in''' scalar parameter is passed as a scalar argument to a C function. * An Ada '''in''' parameter of an access-to-object type with designated type T is passed as a t* argument to a C function, where t is the C type corresponding to the Ada type T. * An Ada '''access''' T parameter, or an Ada '''out''' or '''in out''' parameter of an elementary type T, is passed as a t* argument to a C function, where t is the C type corresponding to the Ada type T. In the case of an elementary '''out''' or '''in out''' parameter, a pointer to a temporary copy is used to preserve by-copy semantics. <div> * An Ada parameter of a C_Pass_By_Copy-compatible (record) type T, of mode '''in''', is passed as a t argument to a C function, where t is the C struct corresponding to the Ada type T. </div> * An Ada parameter of a record type T, of any mode, other than an '''in''' parameter of a C_Pass_By_Copy-compatible type, is passed as a t* argument to a C function, where t is the C struct corresponding to the Ada type T. * An Ada parameter of an array type with component type T, of any mode, is passed as a t* argument to a C function, where t is the C type corresponding to the Ada type T. * An Ada parameter of an access-to-subprogram type is passed as a pointer to a C function whose prototype corresponds to the designated subprogram's specification. == Notes == 9  Values of type char_array are not implicitly terminated with nul. If a char_array is to be passed as a parameter to an imported C function requiring nul termination, it is the programmer's responsibility to obtain this effect. 10  To obtain the effect of C's sizeof(item_type), where Item_Type is the corresponding Ada type, evaluate the expression: size_t(Item_Type'Size/CHAR_BIT). 11  There is no explicit support for C's union types. Unchecked conversions can be used to obtain the effect of C unions. 12  A C function that takes a variable number of arguments can correspond to several Ada subprograms, taking various specific numbers and types of parameters. == Examples == ''Example of using the Interfaces.C package:'' <p><syntaxhighlight lang="Ada"> --Calling the C Library Function strcpy with Interfaces.C; procedure Test is package C renames Interfaces.C; use type C.char_array; -- Call <string.h>strcpy: -- C definition of strcpy:  char *strcpy(char *s1, const char *s2); -- This function copies the string pointed to by s2 (including the terminating null character) -- into the array pointed to by s1. If copying takes place between objects that overlap,  -- the behavior is undefined. The strcpy function returns the value of s1.</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Note: since the C function's return value is of no interest, the Ada interface is a procedure procedure Strcpy (Target : out C.char_array;                   Source : in  C.char_array);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    pragma Import(C, Strcpy, "strcpy");</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Chars1 :  C.char_array(1..20); Chars2 :  C.char_array(1..20);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> begin Chars2(1..6) := "qwert" & C.nul;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Strcpy(Chars1, Chars2);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- Now Chars1(1..6) = "qwert" & C.Nul</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> end Test;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-B-2|Previous]] | [[Guide:95lrm/RM-B-3-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} iw82q0sj0fdqmn575uh2xfxz03o3p8i Guide:95lrm/RM-B-3-1 4200 1118 4390 2019-05-01T21:59:00Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-B-3|Previous]] | [[Guide:95lrm/RM-B-3-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: B.3.1 The Package Interfaces.C.Strings}} The package Interfaces.C.Strings declares types and subprograms allowing an Ada program to allocate, reference, update, and free C-style strings. In particular, the private type chars_ptr corresponds to a common use of ''char *'' in C programs, and an object of this type can be passed to a subprogram to which pragma Import(C,...) has been applied, and for which ''char *'' is the type of the argument of the C function. == Static Semantics == The library package Interfaces.C.Strings has the following declaration: <p><syntaxhighlight lang="Ada"> package Interfaces.C.Strings is pragma Preelaborate(Strings);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type char_array_access is access all char_array;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type chars_ptr is private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type chars_ptr_array is array (size_t range <>) of chars_ptr;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Null_Ptr : constant chars_ptr;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Chars_Ptr (Item      : in char_array_access;                        Nul_Check : in Boolean := False)    return chars_ptr;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function New_Char_Array (Chars   : in char_array) return chars_ptr;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function New_String (Str : in String) return chars_ptr;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Free (Item : in out chars_ptr);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Dereference_Error : exception;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Value (Item : in chars_ptr) return char_array;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Value (Item : in chars_ptr; Length : in size_t)    return char_array;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Value (Item : in chars_ptr) return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Value (Item : in chars_ptr; Length : in size_t)    return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Strlen (Item : in chars_ptr) return size_t;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Update (Item   : in chars_ptr;                   Offset : in size_t;                   Chars  : in char_array;                   Check  : in Boolean := True);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Update (Item   : in chars_ptr;                   Offset : in size_t;                   Str    : in String;                   Check  : in Boolean := True);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Update_Error : exception;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> private ... -- not specified by the language end Interfaces.C.Strings;</syntaxhighlight></p> The type chars_ptr is C-compatible and corresponds to the use of C's ''char *'' for a pointer to the first char in a char array terminated by nul. When an object of type chars_ptr is declared, its value is by default set to Null_Ptr, unless the object is imported (see [[Guide:95lrm/RM-B-1|B.1]]). <p><syntaxhighlight lang="Ada"> function To_Chars_Ptr (Item      : in char_array_access;                     Nul_Check : in Boolean := False) return chars_ptr;</syntaxhighlight></p> <p><span></span></p> :If Item is '''null''', then To_Chars_Ptr returns Null_Ptr. If Item is not '''null''',Nul_Check is True, and Item.'''all''' does not contain nul, then the function propagates Terminator_Error; otherwise To_Chars_Ptr performs a pointer conversion with no allocation of memory. <p><syntaxhighlight lang="Ada"> function New_Char_Array (Chars   : in char_array) return chars_ptr;</syntaxhighlight></p> <p><span></span></p> :This function returns a pointer to an allocated object initialized to Chars(Chars'First .. Index) & nul, where <p><span></span></p> :* Index = Chars'Last if Chars does not contain nul, or <p><span></span></p> :* Index is the smallest size_t value I such that Chars(I+1) = nul. :Storage_Error is propagated if the allocation fails. <p><syntaxhighlight lang="Ada"> function New_String (Str : in String) return chars_ptr;</syntaxhighlight></p> <p><span></span></p> :This function is equivalent to New_Char_Array(To_C(Str)). <p><syntaxhighlight lang="Ada"> procedure Free (Item : in out chars_ptr);</syntaxhighlight></p> <p><span></span></p> :If Item is Null_Ptr, then Free has no effect. Otherwise, Free releases the storage occupied by Value(Item), and resets Item to Null_Ptr. <p><syntaxhighlight lang="Ada"> function Value (Item : in chars_ptr) return char_array;</syntaxhighlight></p> <p><span></span></p> :If Item = Null_Ptr then Value propagates Dereference_Error. Otherwise Value returns the prefix of the array of chars pointed to by Item, up to and including the first nul. The lower bound of the result is 0. If Item does not point to a nul-terminated string, then execution of Value is erroneous. <p><syntaxhighlight lang="Ada"> function Value (Item : in chars_ptr; Length : in size_t) return char_array;</syntaxhighlight></p> <p><span></span></p> :If Item = Null_Ptr then Value propagates Dereference_Error. Otherwise Value returns the shorter of two arrays, either the first Length chars pointed to by Item, or Value(Item). The lower bound of the result is 0. If Length is 0, then Value propagates Constraint_Error. <p><syntaxhighlight lang="Ada"> function Value (Item : in chars_ptr) return String;</syntaxhighlight></p> <p><span></span></p> :Equivalent to To_Ada(Value(Item), Trim_Nul=>True). <p><syntaxhighlight lang="Ada"> function Value (Item : in chars_ptr; Length : in size_t) return String;</syntaxhighlight></p> <p><span></span></p> :Equivalent to To_Ada(Value(Item, Length) & nul, Trim_Nul=>True). <p><syntaxhighlight lang="Ada"> function Strlen (Item : in chars_ptr) return size_t;</syntaxhighlight></p> <p><span></span></p> :Returns ''Val'''Length-1 where ''Val'' = Value(Item); propagates Dereference_Error if Item = Null_Ptr. <p><syntaxhighlight lang="Ada"> procedure Update (Item   : in chars_ptr;                Offset : in size_t;                Chars  : in char_array;                Check  : Boolean := True);</syntaxhighlight></p> <p><span></span></p> :If Item = Null_Ptr, then Update propagates Dereference_Error. Otherwise, this procedure updates the value pointed to by Item, starting at position Offset, using Chars as the data to be copied into the array. Overwriting the nul terminator, and skipping with the Offset past the nul terminator, are both prevented if Check is True, as follows: <p><span></span></p> :* Let N = Strlen(Item). If Check is True, then: <p><span></span></p> ::* If Offset+Chars'Length>N, propagate Update_Error. <p><span></span></p> ::* Otherwise, overwrite the data in the array pointed to by Item, starting at the char at position Offset, with the data in Chars. <p><span></span></p> :* If Check is False, then processing is as above, but with no check that Offset+Chars'Length>N. <p><syntaxhighlight lang="Ada"> procedure Update (Item   : in chars_ptr;                Offset : in size_t;                Str    : in String;                Check  : in Boolean := True);</syntaxhighlight></p> <p><span></span></p> :Equivalent to Update(Item, Offset, To_C(Str), Check). == Erroneous Execution == <span id="I6206"></span>Execution of any of the following is erroneous if the Item parameter is not null_ptr and Item does not point to a nul-terminated array of chars. * a Value function not taking a Length parameter, * the Free procedure, * the Strlen function. <span id="I6207"></span>Execution of Free(X) is also erroneous if the chars_ptr X was not returned by New_Char_Array or New_String. <span id="I6208"></span>Reading or updating a freed char_array is erroneous. <span id="I6209"></span>Execution of Update is erroneous if Check is False and a call with Check equal to True would have propagated Update_Error. == Notes == 13  New_Char_Array and New_String might be implemented either through the allocation function from the C environment (''malloc'') or through Ada dynamic memory allocation (''new''). The key points are * the returned value (a chars_ptr) is represented as a C ''char *'' so that it may be passed to C functions; * the allocated object should be freed by the programmer via a call of Free, not by a called C function. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-B-3|Previous]] | [[Guide:95lrm/RM-B-3-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 92d2mfrdvr8h5x0ih7glox5u44g7cyl Guide:95lrm/RM-B-3-2 4200 1119 4391 2019-05-01T22:08:31Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-B-3-1|Previous]] | [[Guide:95lrm/RM-B-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: B.3.2 The Generic Package Interfaces.C.Pointers}} The generic package Interfaces.C.Pointers allows the Ada programmer to perform C-style operations on pointers. It includes an access type Pointer, Value functions that dereference a Pointer and deliver the designated array, several pointer arithmetic operations, and ''copy'' procedures that copy the contents of a source pointer into the array designated by a destination pointer. As in C, it treats an object Ptr of type Pointer as a pointer to the first element of an array, so that for example, adding 1 to Ptr yields a pointer to the second element of the array. The generic allows two styles of usage: one in which the array is terminated by a special terminator element; and another in which the programmer needs to keep track of the length. == Static Semantics == The generic library package Interfaces.C.Pointers has the following declaration: <p><syntaxhighlight lang="Ada"> generic type Index is (<>); type Element is private; type Element_Array is array (Index range <>) of aliased Element; Default_Terminator : Element; package Interfaces.C.Pointers is pragma Preelaborate(Pointers);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Pointer is access all Element;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Value(Ref        : in Pointer;                Terminator : in Element := Default_Terminator)    return Element_Array;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Value(Ref    : in Pointer;                Length : in ptrdiff_t)    return Element_Array;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Pointer_Error : exception;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- C-style Pointer arithmetic</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "+" (Left : in Pointer;   Right : in ptrdiff_t) return Pointer; function "+" (Left : in ptrdiff_t; Right : in Pointer)   return Pointer; function "-" (Left : in Pointer;   Right : in ptrdiff_t) return Pointer; function "-" (Left : in Pointer;   Right : in Pointer) return ptrdiff_t;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Increment (Ref : in out Pointer); procedure Decrement (Ref : in out Pointer);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    pragma Convention (Intrinsic, "+"); pragma Convention (Intrinsic, "-"); pragma Convention (Intrinsic, Increment); pragma Convention (Intrinsic, Decrement);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Virtual_Length (Ref        : in Pointer;                          Terminator : in Element := Default_Terminator)    return ptrdiff_t;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Copy_Terminated_Array    (Source     : in Pointer;     Target     : in Pointer;     Limit      : in ptrdiff_t := ptrdiff_t'Last;     Terminator : in Element :=  Default_Terminator);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Copy_Array  (Source  : in Pointer;          Target  : in Pointer;          Length  : in ptrdiff_t);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> end Interfaces.C.Pointers;</syntaxhighlight></p> The type Pointer is C-compatible and corresponds to one use of C's ''Element *''. An object of type Pointer is interpreted as a pointer to the initial Element in an Element_Array. Two styles are supported: * Explicit termination of an array value with Default_Terminator (a special terminator value); * Programmer-managed length, with Default_Terminator treated simply as a data element. <p><syntaxhighlight lang="Ada"> function Value(Ref        : in Pointer;             Terminator : in Element := Default_Terminator) return Element_Array;</syntaxhighlight></p> <p><span></span></p> :This function returns an Element_Array whose value is the array pointed to by Ref, up to and including the first Terminator; the lower bound of the array is Index'First. Interfaces.C.Strings.Dereference_Error is propagated if Ref is '''null'''. <p><syntaxhighlight lang="Ada"> function Value(Ref    : in Pointer;             Length : in ptrdiff_t) return Element_Array;</syntaxhighlight></p> <p><span></span></p> :This function returns an Element_Array comprising the first Length elements pointed to by Ref. The exception Interfaces.C.Strings.Dereference_Error is propagated if Ref is '''null'''. The "+" and "-" functions perform arithmetic on Pointer values, based on the Size of the array elements. In each of these functions, Pointer_Error is propagated if a Pointer parameter is '''null'''. <p><syntaxhighlight lang="Ada"> procedure Increment (Ref : in out Pointer);</syntaxhighlight></p> <p><span></span></p> :Equivalent to Ref := Ref+1. <p><syntaxhighlight lang="Ada"> procedure Decrement (Ref : in out Pointer);</syntaxhighlight></p> <p><span></span></p> :Equivalent to Ref := Ref-1. <p><syntaxhighlight lang="Ada"> function Virtual_Length (Ref        : in Pointer;                       Terminator : in Element := Default_Terminator) return ptrdiff_t;</syntaxhighlight></p> <p><span></span></p> :Returns the number of Elements, up to the one just before the first Terminator, in Value(Ref, Terminator). <p><syntaxhighlight lang="Ada"> procedure Copy_Terminated_Array (Source     : in Pointer;  Target     : in Pointer;  Limit      : in ptrdiff_t := ptrdiff_t'Last;  Terminator : in Element := Default_Terminator);</syntaxhighlight></p> <p><span></span></p> :This procedure copies Value(Source, Terminator) into the array pointed to by Target; it stops either after Terminator has been copied, or the number of elements copied is Limit, whichever occurs first. Dereference_Error is propagated if either Source or Target is '''null'''. <p><syntaxhighlight lang="Ada"> procedure Copy_Array (Source  : in Pointer;                    Target  : in Pointer;                    Length  : in ptrdiff_t);</syntaxhighlight></p> <p><span></span></p> :This procedure copies the first Length elements from the array pointed to by Source, into the array pointed to by Target. Dereference_Error is propagated if either Source or Target is '''null'''. == Erroneous Execution == <span id="I6230"></span>It is erroneous to dereference a Pointer that does not designate an aliased Element. <span id="I6231"></span>Execution of Value(Ref, Terminator) is erroneous if Ref does not designate an aliased Element in an Element_Array terminated by Terminator. <span id="I6232"></span>Execution of Value(Ref, Length) is erroneous if Ref does not designate an aliased Element in an Element_Array containing at least Length Elements between the designated Element and the end of the array, inclusive. <span id="I6233"></span>Execution of Virtual_Length(Ref, Terminator) is erroneous if Ref does not designate an aliased Element in an Element_Array terminated by Terminator. <span id="I6234"></span>Execution of Copy_Terminated_Array(Source, Target, Limit, Terminator) is erroneous in either of the following situations: * Execution of both Value(Source,Terminator) and Value(Source,Limit) are erroneous, or * Copying writes past the end of the array containing the Element designated by Target. <span id="I6235"></span>Execution of Copy_Array(Source, Target, Length) is erroneous if either Value(Source, Length) is erroneous, or copying writes past the end of the array containing the Element designated by Target. == Notes == 14  To compose a Pointer from an Element_Array, use 'Access on the first element. For example (assuming appropriate instantiations): <p><syntaxhighlight lang="Ada"> Some_Array   : Element_Array(0..5) ; Some_Pointer : Pointer := Some_Array(0)'Access;</syntaxhighlight></p> == Examples == ''Example of Interfaces.C.Pointers:'' <p><syntaxhighlight lang="Ada"> with Interfaces.C.Pointers; with Interfaces.C.Strings; procedure Test_Pointers is package C renames Interfaces.C; package Char_Ptrs is    new C.Pointers (Index              => C.size_t,                    Element            => C.char,                    Element_Array      => C.char_array,                    Default_Terminator => C.nul);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    use type Char_Ptrs.Pointer; subtype Char_Star is Char_Ptrs.Pointer;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Strcpy (Target_Ptr, Source_Ptr : Char_Star) is    Target_Temp_Ptr : Char_Star := Target_Ptr;    Source_Temp_Ptr : Char_Star := Source_Ptr;    Element : C.char; begin     if Target_Temp_Ptr = null or Source_Temp_Ptr = null then       raise C.Strings.Dereference_Error;    end if;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       loop       Element             := Source_Temp_Ptr.all;       Target_Temp_Ptr.all := Element;       exit when C."="(Element, C.nul);       Char_Ptrs.Increment(Target_Temp_Ptr);       Char_Ptrs.Increment(Source_Temp_Ptr);    end loop; end Strcpy; begin ... end Test_Pointers;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-B-3-1|Previous]] | [[Guide:95lrm/RM-B-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} kczdl9i8ujwn7lkdpbtxv67qxjac2bu Guide:95lrm/RM-B-4 4200 1120 4392 2019-05-01T22:28:43Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-B-3-2|Previous]] | [[Guide:95lrm/RM-B-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: B.4 Interfacing with COBOL}} <span id="I6236"></span><span id="I6237"></span>The facilities relevant to interfacing with the COBOL language are the package Interfaces.COBOL and support for the Import, Export and Convention pragmas with ''convention''_identifier COBOL. The COBOL interface package supplies several sets of facilities: * A set of types corresponding to the native COBOL types of the supported COBOL implementation (so-called ''internal COBOL representations''), allowing Ada data to be passed as parameters to COBOL programs * A set of types and constants reflecting external data representations such as might be found in files or databases, allowing COBOL-generated data to be read by an Ada program, and Ada-generated data to be read by COBOL programs * A generic package for converting between an Ada decimal type value and either an internal or external COBOL representation == Static Semantics == The library package Interfaces.COBOL has the following declaration: <p><syntaxhighlight lang="Ada"> package Interfaces.COBOL is pragma Preelaborate(COBOL);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- Types and operations for internal data representations</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     type Floating      is digits implementation-defined; type Long_Floating is digits implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Binary      is range implementation-defined; type Long_Binary is range implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Max_Digits_Binary      : constant := implementation-defined; Max_Digits_Long_Binary : constant := implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Decimal_Element  is mod implementation-defined; type Packed_Decimal is array (Positive range <>) of Decimal_Element; pragma Pack(Packed_Decimal);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type COBOL_Character is implementation-defined character type;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Ada_To_COBOL : array (Character) of COBOL_Character := implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    COBOL_To_Ada : array (COBOL_Character) of Character := implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Alphanumeric is array (Positive range <>) of COBOL_Character; pragma Pack(Alphanumeric);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_COBOL (Item : in String) return Alphanumeric; function To_Ada   (Item : in Alphanumeric) return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   procedure To_COBOL (Item       : in String;                     Target     : out Alphanumeric;                     Last       : out Natural);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure To_Ada (Item     : in Alphanumeric;                   Target   : out String;                   Last     : out Natural);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Numeric is array (Positive range <>) of COBOL_Character; pragma Pack(Numeric);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- Formats for COBOL data representations</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Display_Format is private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Unsigned             : constant Display_Format; Leading_Separate     : constant Display_Format; Trailing_Separate    : constant Display_Format; Leading_Nonseparate  : constant Display_Format; Trailing_Nonseparate : constant Display_Format;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Binary_Format is private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   High_Order_First  : constant Binary_Format; Low_Order_First   : constant Binary_Format; Native_Binary     : constant Binary_Format;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Packed_Format is private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Packed_Unsigned   : constant Packed_Format; Packed_Signed     : constant Packed_Format;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -- Types for external representation of COBOL binary data</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Byte is mod 2**COBOL_Character'Size; type Byte_Array is array (Positive range <>) of Byte; pragma Pack (Byte_Array);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Conversion_Error : exception;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    generic    type Num is delta <> digits <>; package Decimal_Conversions is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       -- Display Formats: data values are represented as Numeric</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Valid (Item   : in Numeric;                    Format : in Display_Format)  return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Length (Format : in Display_Format) return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function To_Decimal (Item   : in Numeric;                         Format : in Display_Format)  return Num;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function To_Display (Item   : in Num;                         Format : in Display_Format)  return Numeric;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       -- Packed Formats: data values are represented as Packed_Decimal </syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Valid (Item   : in Packed_Decimal;                     Format : in Packed_Format)  return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Length (Format : in Packed_Format) return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function To_Decimal (Item   : in Packed_Decimal;                         Format : in Packed_Format)  return Num;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function To_Packed (Item   : in Num;                        Format : in Packed_Format)  return Packed_Decimal;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       -- Binary Formats: external data values are represented as Byte_Array </syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Valid (Item   : in Byte_Array;                    Format : in Binary_Format) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Length (Format : in Binary_Format) return Natural;    function To_Decimal (Item   : in Byte_Array;                         Format : in Binary_Format)  return Num;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function To_Binary (Item   : in Num;                      Format : in Binary_Format)  return Byte_Array;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       -- Internal Binary formats: data values are of type Binary or Long_Binary </syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function To_Decimal (Item : in Binary)      return Num;    function To_Decimal (Item : in Long_Binary) return Num;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function To_Binary      (Item : in Num)  return Binary;    function To_Long_Binary (Item : in Num)  return Long_Binary;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    end Decimal_Conversions;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> private ... -- not specified by the language end Interfaces.COBOL;</syntaxhighlight></p> Each of the types in Interfaces.COBOL is COBOL-compatible. The types Floating and Long_Floating correspond to the native types in COBOL for data items with computational usage implemented by floating point. The types Binary and Long_Binary correspond to the native types in COBOL for data items with binary usage, or with computational usage implemented by binary. Max_Digits_Binary is the largest number of decimal digits in a numeric value that is represented as Binary. Max_Digits_Long_Binary is the largest number of decimal digits in a numeric value that is represented as Long_Binary. The type Packed_Decimal corresponds to COBOL's packed-decimal usage. The type COBOL_Character defines the run-time character set used in the COBOL implementation. Ada_To_COBOL and COBOL_To_Ada are the mappings between the Ada and COBOL run-time character sets. Type Alphanumeric corresponds to COBOL's alphanumeric data category. Each of the functions To_COBOL and To_Ada converts its parameter based on the mappings Ada_To_COBOL and COBOL_To_Ada, respectively. The length of the result for each is the length of the parameter, and the lower bound of the result is 1. Each component of the result is obtained by applying the relevant mapping to the corresponding component of the parameter. Each of the procedures To_COBOL and To_Ada copies converted elements from Item to Target, using the appropriate mapping (Ada_To_COBOL or COBOL_To_Ada, respectively). The index in Target of the last element assigned is returned in Last (0 if Item is a null array). <span id="I6324"></span>If Item'Length exceeds Target'Length, Constraint_Error is propagated. Type Numeric corresponds to COBOL's numeric data category with display usage. The types Display_Format, Binary_Format, and Packed_Format are used in conversions between Ada decimal type values and COBOL internal or external data representations. The value of the constant Native_Binary is either High_Order_First or Low_Order_First, depending on the implementation. <p><syntaxhighlight lang="Ada"> function Valid (Item   : in Numeric;              Format : in Display_Format) return Boolean;</syntaxhighlight></p> <p><span></span></p> :The function Valid checks that the Item parameter has a value consistent with the value of Format. If the value of Format is other than Unsigned, Leading_Separate, and Trailing_Separate, the effect is implementation defined. If Format does have one of these values, the following rules apply: <p><span></span></p> :* Format=Unsigned: if Item comprises one or more decimal digit characters then Valid returns True, else it returns False. <p><span></span></p> :* Format=Leading_Separate: if Item comprises a single occurrence of the plus or minus sign character, and then one or more decimal digit characters, then Valid returns True, else it returns False. <p><span></span></p> :* Format=Trailing_Separate: if Item comprises one or more decimal digit characters and finally a plus or minus sign character, then Valid returns True, else it returns False. <p><syntaxhighlight lang="Ada"> function Length (Format : in Display_Format) return Natural;</syntaxhighlight></p> <p><span></span></p> :The Length function returns the minimal length of a Numeric value sufficient to hold any value of type Num when represented as Format. <p><syntaxhighlight lang="Ada"> function To_Decimal (Item   : in Numeric;                   Format : in Display_Format) return Num;</syntaxhighlight></p> <p><span></span></p> :Produces a value of type Num corresponding to Item as represented by Format. The number of digits after the assumed radix point in Item is Num'Scale. Conversion_Error is propagated if the value represented by Item is outside the range of Num. <p><syntaxhighlight lang="Ada"> function To_Display (Item   : in Num;                   Format : in Display_Format) return Numeric;</syntaxhighlight></p> <p><span></span></p> :This function returns the Numeric value for Item, represented in accordance with Format. The length of the returned value is Length(Format), and the lower bound is 1. Conversion_Error is propagated if Num is negative and Format is Unsigned. <p><syntaxhighlight lang="Ada"> function Valid (Item   : in Packed_Decimal;              Format : in Packed_Format) return Boolean;</syntaxhighlight></p> <p><span></span></p> :This function returns True if Item has a value consistent with Format, and False otherwise. The rules for the formation of Packed_Decimal values are implementation defined. <p><syntaxhighlight lang="Ada"> function Length (Format : in Packed_Format) return Natural;</syntaxhighlight></p> <p><span></span></p> :This function returns the minimal length of a Packed_Decimal value sufficient to hold any value of type Num when represented as Format. <p><syntaxhighlight lang="Ada"> function To_Decimal (Item   : in Packed_Decimal;                   Format : in Packed_Format) return Num;</syntaxhighlight></p> <p><span></span></p> :Produces a value of type Num corresponding to Item as represented by Format. Num'Scale is the number of digits after the assumed radix point in Item. Conversion_Error is propagated if the value represented by Item is outside the range of Num. <p><syntaxhighlight lang="Ada"> function To_Packed (Item   : in Num;                  Format : in Packed_Format) return Packed_Decimal;</syntaxhighlight></p> <p><span></span></p> :This function returns the Packed_Decimal value for Item, represented in accordance with Format. The length of the returned value is Length(Format), and the lower bound is 1. Conversion_Error is propagated if Num is negative and Format is Packed_Unsigned. <p><syntaxhighlight lang="Ada"> function Valid (Item   : in Byte_Array;              Format : in Binary_Format) return Boolean;</syntaxhighlight></p> <p><span></span></p> :This function returns True if Item has a value consistent with Format, and False otherwise. <p><syntaxhighlight lang="Ada"> function Length (Format : in Binary_Format) return Natural;</syntaxhighlight></p> <p><span></span></p> :This function returns the minimal length of a Byte_Array value sufficient to hold any value of type Num when represented as Format. <p><syntaxhighlight lang="Ada"> function To_Decimal (Item   : in Byte_Array;                   Format : in Binary_Format) return Num;</syntaxhighlight></p> <p><span></span></p> :Produces a value of type Num corresponding to Item as represented by Format. Num'Scale is the number of digits after the assumed radix point in Item. Conversion_Error is propagated if the value represented by Item is outside the range of Num. <p><syntaxhighlight lang="Ada"> function To_Binary (Item   : in Num;                  Format : in Binary_Format) return Byte_Array;</syntaxhighlight></p> <p><span></span></p> :This function returns the Byte_Array value for Item, represented in accordance with Format. The length of the returned value is Length(Format), and the lower bound is 1. <p><syntaxhighlight lang="Ada"> function To_Decimal (Item : in Binary)      return Num; function To_Decimal (Item : in Long_Binary) return Num;</syntaxhighlight></p> <p><span></span></p> :These functions convert from COBOL binary format to a corresponding value of the decimal type Num. Conversion_Error is propagated if Item is too large for Num. <p><syntaxhighlight lang="Ada"> function To_Binary      (Item : in Num)  return Binary; function To_Long_Binary (Item : in Num)  return Long_Binary;</syntaxhighlight></p> <p><span></span></p> :These functions convert from Ada decimal to COBOL binary format. Conversion_Error is propagated if the value of Item is too large to be represented in the result type. == Implementation Requirements == An implementation shall support pragma Convention with a COBOL ''convention''_identifier for a COBOL-eligible type (see [[Guide:95lrm/RM-B-1|B.1]]). == Implementation Permissions == An implementation may provide additional constants of the private types Display_Format, Binary_Format, or Packed_Format. An implementation may provide further floating point and integer types in Interfaces.COBOL to match additional native COBOL types, and may also supply corresponding conversion functions in the generic package Decimal_Conversions. == Implementation Advice == An Ada implementation should support the following interface correspondences between Ada and COBOL. * An Ada '''access''' T parameter is passed as a ''BY REFERENCE'' data item of the COBOL type corresponding to T. * An Ada '''in''' scalar parameter is passed as a ''BY CONTENT'' data item of the corresponding COBOL type. * Any other Ada parameter is passed as a ''BY REFERENCE'' data item of the COBOL type corresponding to the Ada parameter type; for scalars, a local copy is used if necessary to ensure by-copy semantics. == Notes == 15  An implementation is not required to support pragma Convention for access types, nor is it required to support pragma Import, Export or Convention for functions. 16  If an Ada subprogram is exported to COBOL, then a call from COBOL call may specify either ''BY CONTENT'' or ''BY REFERENCE''. == Examples == ''Examples of Interfaces.COBOL:'' <p><syntaxhighlight lang="Ada"> with Interfaces.COBOL; procedure Test_Call is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Calling a foreign COBOL program -- Assume that a COBOL program PROG has the following declaration --  in its LINKAGE section: --  01 Parameter-Area --     05 NAME   PIC X(20). --     05 SSN    PIC X(9). --     05 SALARY PIC 99999V99 USAGE COMP. -- The effect of PROG is to update SALARY based on some algorithm</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    package COBOL renames Interfaces.COBOL;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Salary_Type is delta 0.01 digits 7;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type COBOL_Record is    record       Name   : COBOL.Numeric(1..20);       SSN    : COBOL.Numeric(1..9);       Salary : COBOL.Binary;  -- Assume Binary = 32 bits    end record; pragma Convention (COBOL, COBOL_Record);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Prog (Item : in out COBOL_Record); pragma Import (COBOL, Prog, "PROG");</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    package Salary_Conversions is    new COBOL.Decimal_Conversions(Salary_Type);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Some_Salary : Salary_Type := 12_345.67; Some_Record : COBOL_Record :=    (Name   => "Johnson, John       ",     SSN    => "111223333",     Salary => Salary_Conversions.To_Binary(Some_Salary));</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> begin Prog (Some_Record); ... end Test_Call;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> with Interfaces.COBOL; with COBOL_Sequential_IO; -- Assumed to be supplied by implementation procedure Test_External_Formats is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Using data created by a COBOL program -- Assume that a COBOL program has created a sequential file with --  the following record structure, and that we need to --  process the records in an Ada program --  01 EMPLOYEE-RECORD --     05 NAME    PIC X(20). --     05 SSN     PIC X(9). --     05 SALARY  PIC 99999V99 USAGE COMP. --     05 ADJUST  PIC S999V999 SIGN LEADING SEPARATE. -- The COMP data is binary (32 bits), high-order byte first</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    package COBOL renames Interfaces.COBOL;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Salary_Type      is delta 0.01  digits 7; type Adjustments_Type is delta 0.001 digits 6;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type COBOL_Employee_Record_Type is  -- External representation    record       Name    : COBOL.Alphanumeric(1..20);       SSN     : COBOL.Alphanumeric(1..9);       Salary  : COBOL.Byte_Array(1..4);       Adjust  : COBOL.Numeric(1..7);  -- Sign and 6 digits    end record; pragma Convention (COBOL, COBOL_Employee_Record_Type);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    package COBOL_Employee_IO is    new COBOL_Sequential_IO(COBOL_Employee_Record_Type); use COBOL_Employee_IO;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    COBOL_File : File_Type;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Ada_Employee_Record_Type is  -- Internal representation    record       Name    : String(1..20);       SSN     : String(1..9);       Salary  : Salary_Type;       Adjust  : Adjustments_Type;    end record;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    COBOL_Record : COBOL_Employee_Record_Type; Ada_Record   : Ada_Employee_Record_Type;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   package Salary_Conversions is    new COBOL.Decimal_Conversions(Salary_Type); use Salary_Conversions;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    package Adjustments_Conversions is    new COBOL.Decimal_Conversions(Adjustments_Type); use Adjustments_Conversions;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> begin Open (COBOL_File, Name => "Some_File");</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    loop   Read (COBOL_File, COBOL_Record);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     Ada_Record.Name := To_Ada(COBOL_Record.Name);   Ada_Record.SSN  := To_Ada(COBOL_Record.SSN);   Ada_Record.Salary :=      To_Decimal(COBOL_Record.Salary, COBOL.High_Order_First);   Ada_Record.Adjust :=      To_Decimal(COBOL_Record.Adjust, COBOL.Leading_Separate);   ... -- Process Ada_Record end loop; exception when End_Error => ... end Test_External_Formats;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-B-3-2|Previous]] | [[Guide:95lrm/RM-B-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} r0phuv628zkr2tjjdjtnv48xd8v80x5 Guide:95lrm/RM-B-5 4200 1121 4393 2019-05-01T22:32:42Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-B-4|Previous]] | [[Guide:95lrm/RM-C|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: B.5 Interfacing with Fortran}} <span id="I6325"></span><span id="I6326"></span>The facilities relevant to interfacing with the Fortran language are the package Interfaces.Fortran and support for the Import, Export and Convention pragmas with ''convention''_identifier Fortran. The package Interfaces.Fortran defines Ada types whose representations are identical to the default representations of the Fortran intrinsic types Integer, Real, Double Precision, Complex, Logical, and Character in a supported Fortran implementation. These Ada types can therefore be used to pass objects between Ada and Fortran programs. == Static Semantics == The library package Interfaces.Fortran has the following declaration: <p><syntaxhighlight lang="Ada"> with Ada.Numerics.Generic_Complex_Types;  -- see G.1.1 pragma Elaborate_All(Ada.Numerics.Generic_Complex_Types); package Interfaces.Fortran is pragma Pure(Fortran);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Fortran_Integer is range implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Real             is digits implementation-defined; type Double_Precision is digits implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Logical is new Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    package Single_Precision_Complex_Types is    new Ada.Numerics.Generic_Complex_Types (Real);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Complex is new Single_Precision_Complex_Types.Complex;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    subtype Imaginary is Single_Precision_Complex_Types.Imaginary; i : Imaginary renames Single_Precision_Complex_Types.i; j : Imaginary renames Single_Precision_Complex_Types.j;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Character_Set is implementation-defined character type;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Fortran_Character is array (Positive range <>) of Character_Set; pragma Pack (Fortran_Character);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Fortran (Item : in Character) return Character_Set; function To_Ada (Item : in Character_Set) return Character;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Fortran (Item : in String) return Fortran_Character; function To_Ada     (Item : in Fortran_Character) return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure To_Fortran (Item       : in String;                       Target     : out Fortran_Character;                       Last       : out Natural);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure To_Ada (Item     : in Fortran_Character;                    Target   : out String;                   Last     : out Natural);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> end Interfaces.Fortran;</syntaxhighlight></p> The types Fortran_Integer, Real, Double_Precision, Logical, Complex, and Fortran_Character are Fortran-compatible. The To_Fortran and To_Ada functions map between the Ada type Character and the Fortran type Character_Set, and also between the Ada type String and the Fortran type Fortran_Character. The To_Fortran and To_Ada procedures have analogous effects to the string conversion subprograms found in Interfaces.COBOL. == Implementation Requirements == An implementation shall support pragma Convention with a Fortran ''convention''_identifier for a Fortran-eligible type (see [[Guide:95lrm/RM-B-1|B.1]]). == Implementation Permissions == An implementation may add additional declarations to the Fortran interface packages. For example, the Fortran interface package for an implementation of Fortran 77 (ANSI X3.9-1978) that defines types like Integer*''n'', Real*''n'', Logical*''n'', and Complex*''n'' may contain the declarations of types named Integer_Star_''n'', Real_Star_''n'', Logical_Star_''n'', and Complex_Star_''n''. (This convention should not apply to Character*''n'', for which the Ada analog is the constrained array subtype Fortran_Character (1..''n'').) Similarly, the Fortran interface package for an implementation of Fortran 90 that provides multiple ''kinds'' of intrinsic types, e.g. Integer (Kind=''n''), Real (Kind=''n''), Logical (Kind=''n''), Complex (Kind=''n''), and Character (Kind=''n''), may contain the declarations of types with the recommended names Integer_Kind_''n'', Real_Kind_''n'', Logical_Kind_''n'', Complex_Kind_''n'', and Character_Kind_''n''. == Implementation Advice == An Ada implementation should support the following interface correspondences between Ada and Fortran: * An Ada procedure corresponds to a Fortran subroutine. * An Ada function corresponds to a Fortran function. * An Ada parameter of an elementary, array, or record type T is passed as a T<sub>F</sub> argument to a Fortran procedure, where T<sub>F</sub> is the Fortran type corresponding to the Ada type T, and where the INTENT attribute of the corresponding dummy argument matches the Ada formal parameter mode; the Fortran implementation's parameter passing conventions are used. For elementary types, a local copy is used if necessary to ensure by-copy semantics. * An Ada parameter of an access-to-subprogram type is passed as a reference to a Fortran procedure whose interface corresponds to the designated subprogram's specification. == Notes == 17  An object of a Fortran-compatible record type, declared in a library package or subprogram, can correspond to a Fortran common block; the type also corresponds to a Fortran ''derived type''. == Examples == ''Example of Interfaces.Fortran:'' <p><syntaxhighlight lang="Ada"> with Interfaces.Fortran; use Interfaces.Fortran; procedure Ada_Application is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Fortran_Matrix is array (Integer range <>,                               Integer range <>) of Double_Precision; pragma Convention (Fortran, Fortran_Matrix);    -- stored in Fortran's                                                 -- column-major order procedure Invert (Rank : in Fortran_Integer; X : in out Fortran_Matrix); pragma Import (Fortran, Invert);                -- a Fortran subroutine </syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Rank      : constant Fortran_Integer := 100; My_Matrix : Fortran_Matrix (1 .. Rank, 1 .. Rank);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> begin</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    ... My_Matrix := ...; ... Invert (Rank, My_Matrix); ...</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> end Ada_Application;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-B-4|Previous]] | [[Guide:95lrm/RM-C|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 0pk2dlzrflwi7cj2hz8isph8mzl5mtv Guide:95lrm/RM-C 4200 1122 4394 2019-05-01T22:33:12Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-B-5|Previous]] | [[Guide:95lrm/RM-C-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Annex C. Systems Programming}} <div>(normative)</div> <span id="I6360"></span><span id="I6361"></span><span id="I6362"></span><span id="I6363"></span><span id="I6364"></span><span id="I6365"></span>The Systems Programming Annex specifies additional capabilities provided for low-level programming. These capabilities are also required in many real-time, embedded, distributed, and information systems. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-B-5|Previous]] | [[Guide:95lrm/RM-C-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} hqy7spix0a8fsqhd8oe9879kutn7uar Guide:95lrm/RM-C-1 4200 1123 4395 2019-04-29T15:48:24Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-C|Previous]] | [[Guide:95lrm/RM-C-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: C.1 Access to Machine Operations}} This clause specifies rules regarding access to machine instructions from within an Ada program. == Implementation Requirements == <span id="I6366"></span>The implementation shall support machine code insertions (see [[Guide:95lrm/RM-13-8|13.8]]) or intrinsic subprograms (see [[Guide:95lrm/RM-6-3-1|6.3.1]]) (or both). Implementation-defined attributes shall be provided to allow the use of Ada entities as operands. == Implementation Advice == The machine code or intrinsics support should allow access to all operations normally available to assembly language programmers for the target environment, including privileged instructions, if any. <span id="I6367"></span><span id="I6368"></span><span id="I6369"></span><span id="I6370"></span>The interfacing pragmas (see [[Guide:95lrm/RM-B|Annex B]]) should support interface to assembler; the default assembler should be associated with the convention identifier Assembler. If an entity is exported to assembly language, then the implementation should allocate it at an addressable location, and should ensure that it is retained by the linking process, even if not otherwise referenced from the Ada code. The implementation should assume that any call to a machine code or assembler subprogram is allowed to read or update every object that is specified as exported. == Documentation Requirements == The implementation shall document the overhead associated with calling machine-code or intrinsic subprograms, as compared to a fully-inlined call, and to a regular out-of-line call. The implementation shall document the types of the package System.Machine_Code usable for machine code insertions, and the attributes to be used in machine code insertions for references to Ada entities. The implementation shall document the subprogram calling conventions associated with the convention identifiers available for use with the interfacing pragmas (Ada and Assembler, at a minimum), including register saving, exception propagation, parameter passing, and function value returning. For exported and imported subprograms, the implementation shall document the mapping between the Link_Name string, if specified, or the Ada designator, if not, and the external link name used for such a subprogram. == Implementation Advice == The implementation should ensure that little or no overhead is associated with calling intrinsic and machine-code subprograms. It is recommended that intrinsic subprograms be provided for convenient access to any machine operations that provide special capabilities or efficiency and that are not otherwise available through the language constructs. Examples of such instructions include: * Atomic read-modify-write operations -- e.g., test and set, compare and swap, decrement and test, enqueue/dequeue. * Standard numeric functions -- e.g., ''sin'', ''log''. * String manipulation operations -- e.g., translate and test. * Vector operations -- e.g., compare vector against thresholds. * Direct operations on I/O ports. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-C|Previous]] | [[Guide:95lrm/RM-C-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 0a3lhjwlbky7ytsn0ntgq1fxdmm5a4t Guide:95lrm/RM-C-2 4200 1124 4396 2019-04-29T15:48:24Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-C-1|Previous]] | [[Guide:95lrm/RM-C-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: C.2 Required Representation Support}} This clause specifies minimal requirements on the implementation's support for representation items and related features. == Implementation Requirements == <span id="I6371"></span>The implementation shall support at least the functionality defined by the recommended levels of support in Section 13. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-C-1|Previous]] | [[Guide:95lrm/RM-C-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} dz5lqwoy9akytkxvujlmooec3q7ji9i Guide:95lrm/RM-C-3 4200 1125 4397 2019-04-29T15:48:24Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-C-2|Previous]] | [[Guide:95lrm/RM-C-3-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: C.3 Interrupt Support}} This clause specifies the language-defined model for hardware interrupts in addition to mechanisms for handling interrupts. <span id="I6372"></span> == Dynamic Semantics == <span id="I6373"></span>An ''interrupt'' represents a class of events that are detected by the hardware or the system software. <span id="I6374"></span>Interrupts are said to occur. An ''occurrence'' of an interrupt is separable into generation and delivery. <span id="I6375"></span>''Generation'' of an interrupt is the event in the underlying hardware or system that makes the interrupt available to the program. <span id="I6376"></span>''Delivery'' is the action that invokes part of the program as response to the interrupt occurrence. <span id="I6377"></span>Between generation and delivery, the interrupt occurrence (or interrupt) is ''pending''. <span id="I6378"></span>Some or all interrupts may be ''blocked''. When an interrupt is blocked, all occurrences of that interrupt are prevented from being delivered. <span id="I6379"></span><span id="I6380"></span>Certain interrupts are ''reserved''. The set of reserved interrupts is implementation defined. A reserved interrupt is either an interrupt for which user-defined handlers are not supported, or one which already has an attached handler by some other implementation-defined means. <span id="I6381"></span>Program units can be connected to non-reserved interrupts. While connected, the program unit is said to be ''attached'' to that interrupt. The execution of that program unit, the ''interrupt handler'', is invoked upon delivery of the interrupt occurrence. While a handler is attached to an interrupt, it is called once for each delivered occurrence of that interrupt. While the handler executes, the corresponding interrupt is blocked. While an interrupt is blocked, all occurrences of that interrupt are prevented from being delivered. Whether such occurrences remain pending or are lost is implementation defined. <span id="I6382"></span>Each interrupt has a ''default treatment'' which determines the system's response to an occurrence of that interrupt when no user-defined handler is attached. The set of possible default treatments is implementation defined, as is the method (if one exists) for configuring the default treatments for interrupts. An interrupt is delivered to the handler (or default treatment) that is in effect for that interrupt at the time of delivery. An exception propagated from a handler that is invoked by an interrupt has no effect. If the Ceiling_Locking policy (see [[Guide:95lrm/RM-D-3|D.3]]) is in effect, the interrupt handler executes with the active priority that is the ceiling priority of the corresponding protected object. == Implementation Requirements == The implementation shall provide a mechanism to determine the minimum stack space that is needed for each interrupt handler and to reserve that space for the execution of the handler. This space should accommodate nested invocations of the handler where the system permits this. If the hardware or the underlying system holds pending interrupt occurrences, the implementation shall provide for later delivery of these occurrences to the program. If the Ceiling_Locking policy is not in effect, the implementation shall provide means for the application to specify whether interrupts are to be blocked during protected actions. == Documentation Requirements == The implementation shall document the following items: ;  1. : For each interrupt, which interrupts are blocked from delivery when a handler attached to that interrupt executes (either as a result of an interrupt delivery or of an ordinary call on a procedure of the corresponding protected object). ;  2. : Any interrupts that cannot be blocked, and the effect of attaching handlers to such interrupts, if this is permitted. ;  3. : Which run-time stack an interrupt handler uses when it executes as a result of an interrupt delivery; if this is configurable, what is the mechanism to do so; how to specify how much space to reserve on that stack. ;  4. : Any implementation- or hardware-specific activity that happens before a user-defined interrupt handler gets control (e.g., reading device registers, acknowledging devices). ;  5. : Any timing or other limitations imposed on the execution of interrupt handlers. ;  6. : The state (blocked/unblocked) of the non-reserved interrupts when the program starts; if some interrupts are unblocked, what is the mechanism a program can use to protect itself before it can attach the corresponding handlers. ;  7. : Whether the interrupted task is allowed to resume execution before the interrupt handler returns. ;  8. : The treatment of interrupt occurrences that are generated while the interrupt is blocked; i.e., whether one or more occurrences are held for later delivery, or all are lost. ;  9. : Whether predefined or implementation-defined exceptions are raised as a result of the occurrence of any interrupt, and the mapping between the machine interrupts (or traps) and the predefined exceptions. ;  10. : On a multi-processor, the rules governing the delivery of an interrupt to a particular processor. == Implementation Permissions == If the underlying system or hardware does not allow interrupts to be blocked, then no blocking is required as part of the execution of subprograms of a protected object whose one of its subprograms is an interrupt handler. In a multi-processor with more than one interrupt subsystem, it is implementation defined whether (and how) interrupt sources from separate subsystems share the same Interrupt_ID type (see [[Guide:95lrm/RM-C-3-2|C.3.2]]). In particular, the meaning of a blocked or pending interrupt may then be applicable to one processor only. Implementations are allowed to impose timing or other limitations on the execution of interrupt handlers. Other forms of handlers are allowed to be supported, in which case, the rules of this subclause should be adhered to. The active priority of the execution of an interrupt handler is allowed to vary from one occurrence of the same interrupt to another. == Implementation Advice == If the Ceiling_Locking policy is not in effect, the implementation should provide means for the application to specify which interrupts are to be blocked during protected actions, if the underlying system allows for a finer-grain control of interrupt blocking. == Notes == 1  The default treatment for an interrupt can be to keep the interrupt pending or to deliver it to an implementation-defined handler. Examples of actions that an implementation-defined handler is allowed to perform include aborting the partition, ignoring (i.e., discarding occurrences of) the interrupt, or queuing one or more occurrences of the interrupt for possible later delivery when a user-defined handler is attached to that interrupt. 2  It is a bounded error to call Task_Identification.Current_Task (see [[Guide:95lrm/RM-C-7-1|C.7.1]]) from an interrupt handler. 3  The rule that an exception propagated from an interrupt handler has no effect is modeled after the rule about exceptions propagated out of task bodies. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-C-2|Previous]] | [[Guide:95lrm/RM-C-3-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} dsuxw95ylxsfiyu4e5dop3tchvr8k5p Guide:95lrm/RM-C-3-1 4200 1126 4398 2019-05-01T22:36:33Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-C-3|Previous]] | [[Guide:95lrm/RM-C-3-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: C.3.1 Protected Procedure Handlers}} == Syntax == The form of a pragma Interrupt_Handler is as follows: <p><span></span></p> '''pragma''' <span id="I6383"></span><span id="I6384"></span>Interrupt_Handler(''handler_''<span id="I6385"></span>name); The form of a pragma Attach_Handler is as follows: <p><span></span></p> '''pragma''' <span id="I6386"></span><span id="I6387"></span>Attach_Handler(''handler_''<span id="I6388"></span>name, <span id="I6389"></span>expression); == Name Resolution Rules == For the Interrupt_Handler and Attach_Handler pragmas, the ''handler_''name shall resolve to denote a protected procedure with a parameterless profile. For the Attach_Handler pragma, the expected type for the expression is Interrupts.Interrupt_ID (see [[Guide:95lrm/RM-C-3-2|C.3.2]]). == Legality Rules == The Attach_Handler pragma is only allowed immediately within the protected_definition where the corresponding subprogram is declared. The corresponding protected_type_declaration or single_protected_declaration shall be a library level declaration. The Interrupt_Handler pragma is only allowed immediately within a protected_definition. The corresponding protected_type_declaration shall be a library level declaration. In addition, any object_declaration of such a type shall be a library level declaration. == Dynamic Semantics == If the pragma Interrupt_Handler appears in a protected_definition, then the corresponding procedure can be attached dynamically, as a handler, to interrupts (see [[Guide:95lrm/RM-C-3-2|C.3.2]]). Such procedures are allowed to be attached to multiple interrupts. <span id="I6390"></span><span id="I6391"></span>The expression in the Attach_Handler pragma as evaluated at object creation time specifies an interrupt. As part of the initialization of that object, if the Attach_Handler pragma is specified, the ''handler'' procedure is attached to the specified interrupt. <span id="I6392"></span><span id="I6393"></span>A check is made that the corresponding interrupt is not reserved. <span id="I6394"></span>Program_Error is raised if the check fails, and the existing treatment for the interrupt is not affected. <span id="I6395"></span><span id="I6396"></span><span id="I6397"></span>If the Ceiling_Locking policy (see [[Guide:95lrm/RM-D-3|D.3]]) is in effect then upon the initialization of a protected object that either an Attach_Handler or Interrupt_Handler pragma applies to one of its procedures, a check is made that the ceiling priority defined in the protected_definition is in the range of System.Interrupt_Priority. <span id="I6398"></span>If the check fails, Program_Error is raised. <span id="I6399"></span>When a protected object is finalized, for any of its procedures that are attached to interrupts, the handler is detached. If the handler was attached by a procedure in the Interrupts package or if no user handler was previously attached to the interrupt, the default treatment is restored. If an Attach_Handler pragma was used and the most recently attached handler for the same interrupt is the same as the one that was attached at the time the protected object was initialized, the previous handler is restored. When a handler is attached to an interrupt, the interrupt is blocked (subject to the Implementation Permission in [[Guide:95lrm/RM-C-3|C.3]]) during the execution of every protected action on the protected object containing the handler. == Erroneous Execution == <span id="I6400"></span>If the Ceiling_Locking policy (see [[Guide:95lrm/RM-D-3|D.3]]) is in effect and an interrupt is delivered to a handler, and the interrupt hardware priority is higher than the ceiling priority of the corresponding protected object, the execution of the program is erroneous. <div> <span id="I6401"></span>If the handlers for a given interrupt attached via pragma Attach_Handler are not attached and detached in a stack-like (LIFO) order, program execution is erroneous. In particular, when a protected object is finalized, the execution is erroneous if any of the procedures of the protected object are attached to interrupts via pragma Attach_Handler and the most recently attached handler for the same interrupt is not the same as the one that was attached at the time the protected object was initialized. </div> == Metrics == The following metric shall be documented by the implementation: 1. The worst case overhead for an interrupt handler that is a parameterless protected procedure, in clock cycles. This is the execution time not directly attributable to the handler procedure or the interrupted execution. It is estimated as C - (A+B), where A is how long it takes to complete a given sequence of instructions without any interrupt, B is how long it takes to complete a normal call to a given protected procedure, and C is how long it takes to complete the same sequence of instructions when it is interrupted by one execution of the same procedure called via an interrupt. == Implementation Permissions == When the pragmas Attach_Handler or Interrupt_Handler apply to a protected procedure, the implementation is allowed to impose implementation-defined restrictions on the corresponding protected_type_declaration and protected_body. An implementation may use a different mechanism for invoking a protected procedure in response to a hardware interrupt than is used for a call to that protected procedure from a task. <span id="I6402"></span>Notwithstanding what this subclause says elsewhere, the Attach_Handler and Interrupt_Handler pragmas are allowed to be used for other, implementation defined, forms of interrupt handlers. == Implementation Advice == Whenever possible, the implementation should allow interrupt handlers to be called directly by the hardware. Whenever practical, the implementation should detect violations of any implementation-defined restrictions before run time. == Notes == 4  The Attach_Handler pragma can provide static attachment of handlers to interrupts if the implementation supports preelaboration of protected objects. (See [[Guide:95lrm/RM-C-4|C.4]].) 5  The ceiling priority of a protected object that one of its procedures is attached to an interrupt should be at least as high as the highest processor priority at which that interrupt will ever be delivered. 6  Protected procedures can also be attached dynamically to interrupts via operations declared in the predefined package Interrupts. 7  An example of a possible implementation-defined restriction is disallowing the use of the standard storage pools within the body of a protected procedure that is an interrupt handler. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-C-3|Previous]] | [[Guide:95lrm/RM-C-3-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} giixodbsxpe1u3m2n8aacsa29e46q54 Guide:95lrm/RM-C-3-2 4200 1127 4399 2019-05-01T22:41:33Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-C-3-1|Previous]] | [[Guide:95lrm/RM-C-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: C.3.2 The Package Interrupts}} == Static Semantics == The following language-defined packages exist: <p><syntaxhighlight lang="Ada"> with System; package Ada.Interrupts is type Interrupt_ID is implementation-defined; type Parameterless_Handler is    access protected procedure;</syntaxhighlight></p> ''This paragraph was deleted.'' <p><syntaxhighlight lang="Ada">    function Is_Reserved (Interrupt : Interrupt_ID)    return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Is_Attached (Interrupt : Interrupt_ID)    return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Current_Handler (Interrupt : Interrupt_ID)    return Parameterless_Handler;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Attach_Handler    (New_Handler : in Parameterless_Handler;     Interrupt   : in Interrupt_ID);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Exchange_Handler    (Old_Handler : out Parameterless_Handler;     New_Handler : in Parameterless_Handler;     Interrupt   : in Interrupt_ID);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Detach_Handler    (Interrupt : in Interrupt_ID);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Reference(Interrupt : Interrupt_ID)    return System.Address;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> private ... -- not specified by the language end Ada.Interrupts;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> package Ada.Interrupts.Names is implementation-defined : constant Interrupt_ID :=    implementation-defined;    . . . implementation-defined : constant Interrupt_ID :=   implementation-defined; end Ada.Interrupts.Names;</syntaxhighlight></p> == Dynamic Semantics == The Interrupt_ID type is an implementation-defined discrete type used to identify interrupts. The Is_Reserved function returns True if and only if the specified interrupt is reserved. The Is_Attached function returns True if and only if a user-specified interrupt handler is attached to the interrupt. The Current_Handler function returns a value that represents the attached handler of the interrupt. If no user-defined handler is attached to the interrupt, Current_Handler returns '''null'''. The Attach_Handler procedure attaches the specified handler to the interrupt, overriding any existing treatment (including a user handler) in effect for that interrupt. If New_Handler is '''null''', the default treatment is restored. <span id="I6427"></span>If New_Handler designates a protected procedure to which the pragma Interrupt_Handler does not apply, Program_Error is raised. In this case, the operation does not modify the existing interrupt treatment. The Exchange_Handler procedure operates in the same manner as Attach_Handler with the addition that the value returned in Old_Handler designates the previous treatment for the specified interrupt. If the previous treatment is not a user-defined handler, '''null''' is returned. The Detach_Handler procedure restores the default treatment for the specified interrupt. For all operations defined in this package that take a parameter of type Interrupt_ID, with the exception of Is_Reserved and Reference, a check is made that the specified interrupt is not reserved. <span id="I6428"></span>Program_Error is raised if this check fails. If, by using the Attach_Handler, Detach_Handler, or Exchange_Handler procedures, an attempt is made to detach a handler that was attached statically (using the pragma Attach_Handler), the handler is not detached and Program_Error is raised. <span id="I6429"></span> The Reference function returns a value of type System.Address that can be used to attach a task entry, via an address clause (see [[Guide:95lrm/RM-J-7-1|J.7.1]]) to the interrupt specified by Interrupt. This function raises Program_Error if attaching task entries to interrupts (or to this particular interrupt) is not supported. <span id="I6430"></span> == Implementation Requirements == At no time during attachment or exchange of handlers shall the current handler of the corresponding interrupt be undefined. == Documentation Requirements == If the Ceiling_Locking policy (see [[Guide:95lrm/RM-D-3|D.3]]) is in effect the implementation shall document the default ceiling priority assigned to a protected object that contains either the Attach_Handler or Interrupt_Handler pragmas, but not the Interrupt_Priority pragma. This default need not be the same for all interrupts. == Implementation Advice == If implementation-defined forms of interrupt handler procedures are supported, such as protected procedures with parameters, then for each such form of a handler, a type analogous to Parameterless_Handler should be specified in a child package of Interrupts, with the same operations as in the predefined package Interrupts. == Notes == 8  The package Interrupts.Names contains implementation-defined names (and constant values) for the interrupts that are supported by the implementation. == Examples == ''Example of interrupt handlers:'' <p><syntaxhighlight lang="Ada"> Device_Priority : constant   array (1..5) of System.Interrupt_Priority := ( ... ); protected type Device_Interface   (Int_ID : Ada.Interrupts.Interrupt_ID) is   procedure Handler;   pragma Attach_Handler(Handler, Int_ID);   ...   pragma Interrupt_Priority(Device_Priority(Int_ID)); end Device_Interface;   ... Device_1_Driver : Device_Interface(1);   ... Device_5_Driver : Device_Interface(5);   ...</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-C-3-1|Previous]] | [[Guide:95lrm/RM-C-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} ntopuuotb2c68mqhh1oq2rwbmcezc6f Guide:95lrm/RM-C-4 4200 1128 4400 2019-04-29T15:48:24Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-C-3-2|Previous]] | [[Guide:95lrm/RM-C-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: C.4 Preelaboration Requirements}} This clause specifies additional implementation and documentation requirements for the Preelaborate pragma (see [[Guide:95lrm/RM-10-2-1|10.2.1]]). == Implementation Requirements == The implementation shall not incur any run-time overhead for the elaboration checks of subprograms and protected_bodies declared in preelaborated library units. The implementation shall not execute any memory write operations after load time for the elaboration of constant objects declared immediately within the declarative region of a preelaborated library package, so long as the subtype and initial expression (or default initial expressions if initialized by default) of the object_declaration satisfy the following restrictions. <span id="I6431"></span>The meaning of ''load time'' is implementation defined. * Any subtype_mark denotes a statically constrained subtype, with statically constrained subcomponents, if any; * any constraint is a static constraint; * any allocator is for an access-to-constant type; * any uses of predefined operators appear only within static expressions; * any primaries that are names, other than attribute_references for the Access or Address attributes, appear only within static expressions; * any name that is not part of a static expression is an expanded name or direct_name that statically denotes some entity; * any discrete_choice of an array_aggregate is static; * no language-defined check associated with the elaboration of the object_declaration can fail. == Documentation Requirements == The implementation shall document any circumstances under which the elaboration of a preelaborated package causes code to be executed at run time. The implementation shall document whether the method used for initialization of preelaborated variables allows a partition to be restarted without reloading. == Implementation Advice == It is recommended that preelaborated packages be implemented in such a way that there should be little or no code executed at run time for the elaboration of entities not already covered by the Implementation Requirements. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-C-3-2|Previous]] | [[Guide:95lrm/RM-C-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} mq7g1yargd3wzcu193ykyd93dxr53ng Guide:95lrm/RM-C-5 4200 1129 4401 2019-05-01T22:42:07Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-C-4|Previous]] | [[Guide:95lrm/RM-C-6|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: C.5 Pragma Discard_Names}} A pragma Discard_Names may be used to request a reduction in storage used for the names of certain entities. == Syntax == The form of a pragma Discard_Names is as follows: <p><span></span></p> '''pragma''' <span id="I6432"></span><span id="I6433"></span>Discard_Names[([On => ] <span id="I6434"></span>local_name)]; A pragma Discard_Names is allowed only immediately within a declarative_part, immediately within a package_specification, or as a configuration pragma. == Legality Rules == The local_name (if present) shall denote a non-derived enumeration first subtype, a tagged first subtype, or an exception. The pragma applies to the type or exception. Without a local_name, the pragma applies to all such entities declared after the pragma, within the same declarative region. Alternatively, the pragma can be used as a configuration pragma. If the pragma applies to a type, then it applies also to all descendants of the type. == Static Semantics == <span id="I6435"></span><span id="I6436"></span>If a local_name is given, then a pragma Discard_Names is a representation pragma. If the pragma applies to an enumeration type, then the semantics of the Wide_Image and Wide_Value attributes are implementation defined for that type; the semantics of Image and Value are still defined in terms of Wide_Image and Wide_Value. In addition, the semantics of Text_IO.Enumeration_IO are implementation defined. If the pragma applies to a tagged type, then the semantics of the Tags.Expanded_Name function are implementation defined for that type. If the pragma applies to an exception, then the semantics of the Exceptions.Exception_Name function are implementation defined for that exception. == Implementation Advice == If the pragma applies to an entity, then the implementation should reduce the amount of storage used for storing names associated with that entity. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-C-4|Previous]] | [[Guide:95lrm/RM-C-6|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 5cla86pc26a3k5q89tclrs0mw9z2thw Guide:95lrm/RM-C-6 4200 1130 4402 2019-05-01T22:43:20Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-C-5|Previous]] | [[Guide:95lrm/RM-C-7|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: C.6 Shared Variable Control}} This clause specifies representation pragmas that control the use of shared variables. == Syntax == The form for pragmas Atomic, Volatile, Atomic_Components, and Volatile_Components is as follows: <p><span></span></p> '''pragma''' <span id="I6437"></span><span id="I6438"></span>Atomic(<span id="I6439"></span>local_name); <p><span></span></p> '''pragma''' <span id="I6440"></span><span id="I6441"></span>Volatile(<span id="I6442"></span>local_name); <p><span></span></p> '''pragma''' <span id="I6443"></span><span id="I6444"></span>Atomic_Components(''array_''<span id="I6445"></span>local_name); <p><span></span></p> '''pragma''' <span id="I6446"></span><span id="I6447"></span>Volatile_Components(''array_''<span id="I6448"></span>local_name); <span id="I6449"></span>An ''atomic'' type is one to which a pragma Atomic applies. An ''atomic'' object (including a component) is one to which a pragma Atomic applies, or a component of an array to which a pragma Atomic_Components applies, or any object of an atomic type. <span id="I6450"></span>A ''volatile'' type is one to which a pragma Volatile applies. A ''volatile'' object (including a component) is one to which a pragma Volatile applies, or a component of an array to which a pragma Volatile_Components applies, or any object of a volatile type. In addition, every atomic type or object is also defined to be volatile. Finally, if an object is volatile, then so are all of its subcomponents (the same does not apply to atomic). == Name Resolution Rules == The local_name in an Atomic or Volatile pragma shall resolve to denote either an object_declaration, a non-inherited component_declaration, or a full_type_declaration. The ''array_''local_name in an Atomic_Components or Volatile_Components pragma shall resolve to denote the declaration of an array type or an array object of an anonymous type. == Legality Rules == <span id="I6451"></span>It is illegal to apply either an Atomic or Atomic_Components pragma to an object or type if the implementation cannot support the indivisible reads and updates required by the pragma (see below). It is illegal to specify the Size attribute of an atomic object, the Component_Size attribute for an array type with atomic components, or the layout attributes of an atomic component, in a way that prevents the implementation from performing the required indivisible reads and updates. If an atomic object is passed as a parameter, then the type of the formal parameter shall either be atomic or allow pass by copy (that is, not be a nonatomic by-reference type). If an atomic object is used as an actual for a generic formal object of mode '''in out''', then the type of the generic formal object shall be atomic. If the prefix of an attribute_reference for an Access attribute denotes an atomic object (including a component), then the designated type of the resulting access type shall be atomic. If an atomic type is used as an actual for a generic formal derived type, then the ancestor of the formal type shall be atomic or allow pass by copy. Corresponding rules apply to volatile objects and types. If a pragma Volatile, Volatile_Components, Atomic, or Atomic_Components applies to a stand-alone constant object, then a pragma Import shall also apply to it. == Static Semantics == <span id="I6452"></span><span id="I6453"></span><span id="I6454"></span><span id="I6455"></span><span id="I6456"></span><span id="I6457"></span><span id="I6458"></span><span id="I6459"></span>These pragmas are representation pragmas (see [[Guide:95lrm/RM-13-1|13.1]]). == Dynamic Semantics == For an atomic object (including an atomic component) all reads and updates of the object as a whole are indivisible. For a volatile object all reads and updates of the object as a whole are performed directly to memory. <span id="I6460"></span>Two actions are sequential (see [[Guide:95lrm/RM-9-10|9.10]]) if each is the read or update of the same atomic object. <span id="I6461"></span>If a type is atomic or volatile and it is not a by-copy type, then the type is defined to be a by-reference type. If any subcomponent of a type is atomic or volatile, then the type is defined to be a by-reference type. If an actual parameter is atomic or volatile, and the corresponding formal parameter is not, then the parameter is passed by copy. == Implementation Requirements == <span id="I6462"></span>The external effect of a program (see [[Guide:95lrm/RM-1-1-3|1.1.3]]) is defined to include each read and update of a volatile or atomic object. The implementation shall not generate any memory reads or updates of atomic or volatile objects other than those specified by the program. If a pragma Pack applies to a type any of whose subcomponents are atomic, the implementation shall not pack the atomic subcomponents more tightly than that for which it can support indivisible reads and updates. == Notes == 9  An imported volatile or atomic constant behaves as a constant (i.e. read-only) with respect to other parts of the Ada program, but can still be modified by an ''external source.'' </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-C-5|Previous]] | [[Guide:95lrm/RM-C-7|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} hhj4zjm3m3j30h59l28mp78ipezn6k9 Guide:95lrm/RM-C-7 4200 1131 4403 2019-04-29T15:48:24Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-C-6|Previous]] | [[Guide:95lrm/RM-C-7-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: C.7 Task Identification and Attributes}} This clause describes operations and attributes that can be used to obtain the identity of a task. In addition, a package that associates user-defined information with a task is defined. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-C-6|Previous]] | [[Guide:95lrm/RM-C-7-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} j5sf6zj6kfwkoi9u55atxisvay8y64k Guide:95lrm/RM-C-7-1 4200 1132 4404 2019-05-01T22:44:59Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-C-7|Previous]] | [[Guide:95lrm/RM-C-7-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: C.7.1 The Package Task_Identification}} == Static Semantics == The following language-defined library package exists: <p><syntaxhighlight lang="Ada"> package Ada.Task_Identification is type Task_ID is private; Null_Task_ID : constant Task_ID; function  "=" (Left, Right : Task_ID) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function  Image        (T : Task_ID) return String; function  Current_Task return Task_ID; procedure Abort_Task   (T : in Task_ID);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function  Is_Terminated(T : Task_ID) return Boolean; function  Is_Callable  (T : Task_ID) return Boolean; private ... -- not specified by the language end Ada.Task_Identification;</syntaxhighlight></p> == Dynamic Semantics == A value of the type Task_ID identifies an existent task. The constant Null_Task_ID does not identify any task. Each object of the type Task_ID is default initialized to the value of Null_Task_ID. The function "=" returns True if and only if Left and Right identify the same task or both have the value Null_Task_ID. The function Image returns an implementation-defined string that identifies T. If T equals Null_Task_ID, Image returns an empty string. The function Current_Task returns a value that identifies the calling task. The effect of Abort_Task is the same as the abort_statement for the task identified by T. In addition, if T identifies the environment task, the entire partition is aborted, See [[Guide:95lrm/RM-E-1|E.1]]. The functions Is_Terminated and Is_Callable return the value of the corresponding attribute of the task identified by T. For a prefix T that is of a task type (after any implicit dereference), the following attribute is defined: ;  T'Identity : <span id="I6480"></span><span id="I6481"></span>Yields a value of the type Task_ID that identifies the task denoted by T. For a prefix E that denotes an entry_declaration, the following attribute is defined: ;  E'Caller : <span id="I6482"></span><span id="I6483"></span>Yields a value of the type Task_ID that identifies the task whose call is now being serviced. Use of this attribute is allowed only inside an entry_body or accept_statement corresponding to the entry_declaration denoted by E. <span id="I6484"></span>Program_Error is raised if a value of Null_Task_ID is passed as a parameter to Abort_Task, Is_Terminated, and Is_Callable. <span id="I6485"></span><span id="I6486"></span>Abort_Task is a potentially blocking operation (see [[Guide:95lrm/RM-9-5-1|9.5.1]]). == Bounded (Run-Time) Errors == <span id="I6487"></span>It is a bounded error to call the Current_Task function from an entry body or an interrupt handler. <span id="I6488"></span>Program_Error is raised, or an implementation-defined value of the type Task_ID is returned. == Erroneous Execution == <span id="I6489"></span>If a value of Task_ID is passed as a parameter to any of the operations declared in this package (or any language-defined child of this package), and the corresponding task object no longer exists, the execution of the program is erroneous. == Documentation Requirements == The implementation shall document the effect of calling Current_Task from an entry body or interrupt handler. == Notes == 10  This package is intended for use in writing user-defined task scheduling packages and constructing server tasks. Current_Task can be used in conjunction with other operations requiring a task as an argument such as Set_Priority (see [[Guide:95lrm/RM-D-5|D.5]]). 11  The function Current_Task and the attribute Caller can return a Task_ID value that identifies the environment task. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-C-7|Previous]] | [[Guide:95lrm/RM-C-7-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 351fvi1p7eqfnf6o8i3txmrmudna2ov Guide:95lrm/RM-C-7-2 4200 1133 4405 2019-05-01T22:46:50Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-C-7-1|Previous]] | [[Guide:95lrm/RM-D|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: C.7.2 The Package Task_Attributes}} == Static Semantics == The following language-defined generic library package exists: <p><syntaxhighlight lang="Ada"> with Ada.Task_Identification; use Ada.Task_Identification; generic type Attribute is private; Initial_Value : in Attribute; package Ada.Task_Attributes is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Attribute_Handle is access all Attribute;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Value(T : Task_ID := Current_Task)   return Attribute;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Reference(T : Task_ID := Current_Task)   return Attribute_Handle;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Set_Value(Val : in Attribute;                           T : in Task_ID := Current_Task); procedure Reinitialize(T : in Task_ID := Current_Task);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> end Ada.Task_Attributes;</syntaxhighlight></p> == Dynamic Semantics == When an instance of Task_Attributes is elaborated in a given active partition, an object of the actual type corresponding to the formal type Attribute is implicitly created for each task (of that partition) that exists and is not yet terminated. This object acts as a user-defined attribute of the task. A task created previously in the partition and not yet terminated has this attribute from that point on. Each task subsequently created in the partition will have this attribute when created. In all these cases, the initial value of the given attribute is Initial_Value. The Value operation returns the value of the corresponding attribute of T. The Reference operation returns an access value that designates the corresponding attribute of T. The Set_Value operation performs any finalization on the old value of the attribute of T and assigns Val to that attribute (see [[Guide:95lrm/RM-5-2|5.2]] and [[Guide:95lrm/RM-7-6|7.6]]). The effect of the Reinitialize operation is the same as Set_Value where the Val parameter is replaced with Initial_Value. <span id="I6503"></span>For all the operations declared in this package, Tasking_Error is raised if the task identified by T is terminated. <span id="I6504"></span>Program_Error is raised if the value of T is Null_Task_ID. == Bounded (Run-Time) Errors == <div> <span id="I6505"></span>If the package Ada.Task_Attributes is instantiated with a controlled type and the controlled type has user-defined Adjust or Finalize operations that in turn access task attributes by any of the above operations, then a call of Set_Value of the instantiated package constitutes a bounded error. The call may perform as expected or may result in forever blocking the calling task and subsequently some or all tasks of the partition. </div> == Erroneous Execution == <span id="I6506"></span>It is erroneous to dereference the access value returned by a given call on Reference after a subsequent call on Reinitialize for the same task attribute, or after the associated task terminates. <span id="I6507"></span>If a value of Task_ID is passed as a parameter to any of the operations declared in this package and the corresponding task object no longer exists, the execution of the program is erroneous. <div> <span id="I6508"></span>Accesses to task attributes via a value of type Attribute_Handle are erroneous if executed concurrently with each other or with calls of any of the operations declared in package Task_Attributes. </div> == Implementation Requirements == For a given attribute of a given task, the implementation shall perform the operations declared in this package atomically with respect to any of these operations of the same attribute of the same task. The granularity of any locking mechanism necessary to achieve such atomicity is implementation defined. When a task terminates, the implementation shall finalize all attributes of the task, and reclaim any other storage associated with the attributes. == Documentation Requirements == The implementation shall document the limit on the number of attributes per task, if any, and the limit on the total storage for attribute values per task, if such a limit exists. In addition, if these limits can be configured, the implementation shall document how to configure them. == Metrics == The implementation shall document the following metrics: A task calling the following subprograms shall execute in a sufficiently high priority as to not be preempted during the measurement period. This period shall start just before issuing the call and end just after the call completes. If the attributes of task T are accessed by the measurement tests, no other task shall access attributes of that task during the measurement period. For all measurements described here, the Attribute type shall be a scalar whose size is equal to the size of the predefined integer size. For each measurement, two cases shall be documented: one where the accessed attributes are of the calling task (that is, the default value for the T parameter is used), and the other, where T identifies another, non-terminated, task. The following calls (to subprograms in the Task_Attributes package) shall be measured: * a call to Value, where the return value is Initial_Value; * a call to Value, where the return value is not equal to Initial_Value; * a call to Reference, where the return value designates a value equal to Initial_Value; * a call to Reference, where the return value designates a value not equal to Initial_Value; * a call to Set_Value where the Val parameter is not equal to Initial_Value and the old attribute value is equal to Initial_Value. * a call to Set_Value where the Val parameter is not equal to Initial_Value and the old attribute value is not equal to Initial_Value. == Implementation Permissions == An implementation need not actually create the object corresponding to a task attribute until its value is set to something other than that of Initial_Value, or until Reference is called for the task attribute. Similarly, when the value of the attribute is to be reinitialized to that of Initial_Value, the object may instead be finalized and its storage reclaimed, to be recreated when needed later. While the object does not exist, the function Value may simply return Initial_Value, rather than implicitly creating the object. An implementation is allowed to place restrictions on the maximum number of attributes a task may have, the maximum size of each attribute, and the total storage size allocated for all the attributes of a task. == Implementation Advice == Some implementations are targeted to domains in which memory use at run time must be completely deterministic. For such implementations, it is recommended that the storage for task attributes will be pre-allocated statically and not from the heap. This can be accomplished by either placing restrictions on the number and the size of the task's attributes, or by using the pre-allocated storage for the first N attribute objects, and the heap for the others. In the latter case, N should be documented. == Notes == 12  An attribute always exists (after instantiation), and has the initial value. It need not occupy memory until the first operation that potentially changes the attribute value. The same holds true after Reinitialize. 13  The result of the Reference function should be used with care; it is always safe to use that result in the task body whose attribute is being accessed. However, when the result is being used by another task, the programmer must make sure that the task whose attribute is being accessed is not yet terminated. Failing to do so could make the program execution erroneous. 14  As specified in [[Guide:95lrm/RM-C-7-1|C.7.1]], if the parameter T (in a call on a subprogram of an instance of this package) identifies a nonexistent task, the execution of the program is erroneous. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-C-7-1|Previous]] | [[Guide:95lrm/RM-D|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} jeq4qmm3c5er3ovqtavjfa62es1oj4i Guide:95lrm/RM-D 4200 1134 4406 2019-05-01T22:47:25Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-C-7-2|Previous]] | [[Guide:95lrm/RM-D-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Annex D. Real-Time Systems}} <div>(normative)</div> <span id="I6509"></span><span id="I6510"></span>This Annex specifies additional characteristics of Ada implementations intended for real-time systems software. To conform to this Annex, an implementation shall also conform to the Systems Programming Annex. == Metrics == The metrics are documentation requirements; an implementation shall document the values of the language-defined metrics for at least one configuration of hardware or an underlying system supported by the implementation, and shall document the details of that configuration. The metrics do not necessarily yield a simple number. For some, a range is more suitable, for others a formula dependent on some parameter is appropriate, and for others, it may be more suitable to break the metric into several cases. Unless specified otherwise, the metrics in this annex are expressed in processor clock cycles. For metrics that require documentation of an upper bound, if there is no upper bound, the implementation shall report that the metric is unbounded. == Notes == 1  The specification of the metrics makes a distinction between upper bounds and simple execution times. Where something is just specified as ''the execution time of'' a piece of code, this leaves one the freedom to choose a nonpathological case. This kind of metric is of the form ''there exists a program such that the value of the metric is V''. Conversely, the meaning of upper bounds is ''there is no program such that the value of the metric is greater than V''. This kind of metric can only be partially tested, by finding the value of V for one or more test programs. 2  The metrics do not cover the whole language; they are limited to features that are specified in [[Guide:95lrm/RM-C|Annex C]], ''[[Guide:95lrm/RM-C|Systems Programming]]'' and in this Annex. The metrics are intended to provide guidance to potential users as to whether a particular implementation of such a feature is going to be adequate for a particular real-time application. As such, the metrics are aimed at known implementation choices that can result in significant performance differences. 3  The purpose of the metrics is not necessarily to provide fine-grained quantitative results or to serve as a comparison between different implementations on the same or different platforms. Instead, their goal is rather qualitative; to define a standard set of approximate values that can be measured and used to estimate the general suitability of an implementation, or to evaluate the comparative utility of certain features of an implementation for a particular real-time application. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-C-7-2|Previous]] | [[Guide:95lrm/RM-D-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} aeqrd4uk031ahv6m3yrehhaem310o7n Guide:95lrm/RM-D-1 4200 1135 4407 2019-05-01T22:49:09Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D|Previous]] | [[Guide:95lrm/RM-D-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: D.1 Task Priorities}} This clause specifies the priority model for real-time systems. In addition, the methods for specifying priorities are defined. == Syntax == The form of a pragma Priority is as follows: <p><span></span></p> '''pragma''' <span id="I6511"></span><span id="I6512"></span>Priority(<span id="I6513"></span>expression); The form of a pragma Interrupt_Priority is as follows: <p><span></span></p> '''pragma''' <span id="I6514"></span><span id="I6515"></span>Interrupt_Priority[(<span id="I6516"></span>expression)]; == Name Resolution Rules == <span id="I6517"></span><span id="I6518"></span>The expected type for the expression in a Priority or Interrupt_Priority pragma is Integer. == Legality Rules == A Priority pragma is allowed only immediately within a task_definition, a protected_definition, or the declarative_part of a subprogram_body. An Interrupt_Priority pragma is allowed only immediately within a task_definition or a protected_definition. At most one such pragma shall appear within a given construct. For a Priority pragma that appears in the declarative_part of a subprogram_body, the expression shall be static, and its value shall be in the range of System.Priority. == Static Semantics == The following declarations exist in package System: <p><syntaxhighlight lang="Ada"> subtype Any_Priority is Integer range implementation-defined; subtype Priority is Any_Priority range Any_Priority'First .. implementation-defined; subtype Interrupt_Priority is Any_Priority range Priority'Last+1 .. Any_Priority'Last;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> Default_Priority : constant Priority := (Priority'First + Priority'Last)/2;</syntaxhighlight></p> The full range of priority values supported by an implementation is specified by the subtype Any_Priority. The subrange of priority values that are high enough to require the blocking of one or more interrupts is specified by the subtype Interrupt_Priority. The subrange of priority values below System.Interrupt_Priority'First is specified by the subtype System.Priority. The priority specified by a Priority or Interrupt_Priority pragma is the value of the expression in the pragma, if any. If there is no expression in an Interrupt_Priority pragma, the priority value is Interrupt_Priority'Last. == Dynamic Semantics == A Priority pragma has no effect if it occurs in the declarative_part of the subprogram_body of a subprogram other than the main subprogram. <span id="I6519"></span><span id="I6520"></span><span id="I6521"></span><span id="I6522"></span><span id="I6523"></span>A ''task priority'' is an integer value that indicates a degree of urgency and is the basis for resolving competing demands of tasks for resources. Unless otherwise specified, whenever tasks compete for processors or other implementation-defined resources, the resources are allocated to the task with the highest priority value. The ''base priority'' of a task is the priority with which it was created, or to which it was later set by Dynamic_Priorities.Set_Priority (see [[Guide:95lrm/RM-D-5|D.5]]). At all times, a task also has an ''active priority'', which generally reflects its base priority as well as any priority it inherits from other sources. ''Priority inheritance'' is the process by which the priority of a task or other entity (e.g. a protected object; see [[Guide:95lrm/RM-D-3|D.3]]) is used in the evaluation of another task's active priority. The effect of specifying such a pragma in a protected_definition is discussed in [[Guide:95lrm/RM-D-3|D.3]]. <span id="I6524"></span>The expression in a Priority or Interrupt_Priority pragma that appears in a task_definition is evaluated for each task object (see [[Guide:95lrm/RM-9-1|9.1]]). For a Priority pragma, the value of the expression is converted to the subtype Priority; for an Interrupt_Priority pragma, this value is converted to the subtype Any_Priority. The priority value is then associated with the task object whose task_definition contains the pragma. <span id="I6525"></span><span id="I6526"></span> Likewise, the priority value is associated with the environment task if the pragma appears in the declarative_part of the main subprogram. The initial value of a task's base priority is specified by default or by means of a Priority or Interrupt_Priority pragma. After a task is created, its base priority can be changed only by a call to Dynamic_Priorities.Set_Priority (see [[Guide:95lrm/RM-D-5|D.5]]). The initial base priority of a task in the absence of a pragma is the base priority of the task that creates it at the time of creation (see [[Guide:95lrm/RM-9-1|9.1]]). If a pragma Priority does not apply to the main subprogram, the initial base priority of the environment task is System.Default_Priority. The task's active priority is used when the task competes for processors. Similarly, the task's active priority is used to determine the task's position in any queue when Priority_Queuing is specified (see [[Guide:95lrm/RM-D-4|D.4]]). At any time, the active priority of a task is the maximum of all the priorities the task is inheriting at that instant. For a task that is not held (see [[Guide:95lrm/RM-D-11|D.11]]), its base priority is always a source of priority inheritance. Other sources of priority inheritance are specified under the following conditions: * During activation, a task being activated inherits the active priority that its activator (see [[Guide:95lrm/RM-9-2|9.2]]) had at the time the activation was initiated. * During rendezvous, the task accepting the entry call inherits the priority of the entry call (see [[Guide:95lrm/RM-9-5-3|9.5.3]] and [[Guide:95lrm/RM-D-4|D.4]]). * During a protected action on a protected object, a task inherits the ceiling priority of the protected object (see [[Guide:95lrm/RM-9-5|9.5]] and [[Guide:95lrm/RM-D-3|D.3]]). In all of these cases, the priority ceases to be inherited as soon as the condition calling for the inheritance no longer exists. == Implementation Requirements == The range of System.Interrupt_Priority shall include at least one value. The range of System.Priority shall include at least 30 values. == Notes == 4  The priority expression can include references to discriminants of the enclosing type. 5  It is a consequence of the active priority rules that at the point when a task stops inheriting a priority from another source, its active priority is re-evaluated. This is in addition to other instances described in this Annex for such re-evaluation. 6  An implementation may provide a non-standard mode in which tasks inherit priorities under conditions other than those specified above. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D|Previous]] | [[Guide:95lrm/RM-D-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 0oxm44en8kowhmqi7hzgqrehxpvdg0v Guide:95lrm/RM-D-10 4200 1136 4408 2019-05-01T23:07:49Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-9|Previous]] | [[Guide:95lrm/RM-D-11|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: D.10 Synchronous Task Control}} This clause describes a language-defined private semaphore (suspension object), which can be used for ''two-stage suspend'' operations and as a simple building block for implementing higher-level queues. == Static Semantics == The following language-defined package exists: <p><syntaxhighlight lang="Ada"> package Ada.Synchronous_Task_Control is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   type Suspension_Object is limited private;   procedure Set_True(S : in out Suspension_Object);   procedure Set_False(S : in out Suspension_Object);   function Current_State(S : Suspension_Object) return Boolean;   procedure Suspend_Until_True(S : in out Suspension_Object); private   ... -- not specified by the language end Ada.Synchronous_Task_Control;</syntaxhighlight></p> The type Suspension_Object is a by-reference type. == Dynamic Semantics == An object of the type Suspension_Object has two visible states: true and false. Upon initialization, its value is set to false. The operations Set_True and Set_False are atomic with respect to each other and with respect to Suspend_Until_True; they set the state to true and false respectively. Current_State returns the current state of the object. The procedure Suspend_Until_True blocks the calling task until the state of the object S is true; at that point the task becomes ready and the state of the object becomes false. <span id="I6670"></span><span id="I6671"></span><span id="I6672"></span>Program_Error is raised upon calling Suspend_Until_True if another task is already waiting on that suspension object. Suspend_Until_True is a potentially blocking operation (see [[Guide:95lrm/RM-9-5-1|9.5.1]]). == Implementation Requirements == The implementation is required to allow the calling of Set_False and Set_True during any protected action, even one that has its ceiling priority in the Interrupt_Priority range. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-9|Previous]] | [[Guide:95lrm/RM-D-11|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 4rk5timzs5mvec71zp9bzmll4joopfb Guide:95lrm/RM-D-11 4200 1137 4409 2019-05-01T23:08:31Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-10|Previous]] | [[Guide:95lrm/RM-D-12|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: D.11 Asynchronous Task Control}} This clause introduces a language-defined package to do asynchronous suspend/resume on tasks. It uses a conceptual ''held priority'' value to represent the task's ''held'' state. == Static Semantics == The following language-defined library package exists: <p><syntaxhighlight lang="Ada"> with Ada.Task_Identification; package Ada.Asynchronous_Task_Control is   procedure Hold(T : in Ada.Task_Identification.Task_ID);   procedure Continue(T : in Ada.Task_Identification.Task_ID);   function Is_Held(T : Ada.Task_Identification.Task_ID) return Boolean; end Ada.Asynchronous_Task_Control;</syntaxhighlight></p> == Dynamic Semantics == <span id="I6682"></span><span id="I6683"></span><span id="I6684"></span>After the Hold operation has been applied to a task, the task becomes ''held''. For each processor there is a conceptual ''idle task'', which is always ready. The base priority of the idle task is below System.Any_Priority'First. The ''held priority'' is a constant of the type integer whose value is below the base priority of the idle task. The Hold operation sets the state of T to held. For a held task: the task's own base priority does not constitute an inheritance source (see [[Guide:95lrm/RM-D-1|D.1]]), and the value of the held priority is defined to be such a source instead. The Continue operation resets the state of T to not-held; T's active priority is then reevaluated as described in [[Guide:95lrm/RM-D-1|D.1]]. This time, T's base priority is taken into account. The Is_Held function returns True if and only if T is in the held state. As part of these operations, a check is made that the task identified by T is not terminated. <span id="I6685"></span>Tasking_Error is raised if the check fails. <span id="I6686"></span>Program_Error is raised if the value of T is Null_Task_ID. == Erroneous Execution == <span id="I6687"></span>If any operation in this package is called with a parameter T that specifies a task object that no longer exists, the execution of the program is erroneous. == Implementation Permissions == An implementation need not support Asynchronous_Task_Control if it is infeasible to support it in the target environment. == Notes == 33  It is a consequence of the priority rules that held tasks cannot be dispatched on any processor in a partition (unless they are inheriting priorities) since their priorities are defined to be below the priority of any idle task. 34  The effect of calling Get_Priority and Set_Priority on a Held task is the same as on any other task. 35  Calling Hold on a held task or Continue on a non-held task has no effect. 36  The rules affecting queuing are derived from the above rules, in addition to the normal priority rules: * When a held task is on the ready queue, its priority is so low as to never reach the top of the queue as long as there are other tasks on that queue. * If a task is executing in a protected action, inside a rendezvous, or is inheriting priorities from other sources (e.g. when activated), it continues to execute until it is no longer executing the corresponding construct. * If a task becomes held while waiting (as a caller) for a rendezvous to complete, the active priority of the accepting task is not affected. * If a task becomes held while waiting in a selective_accept, and an entry call is issued to one of the open entries, the corresponding accept_alternative executes. When the rendezvous completes, the active priority of the accepting task is lowered to the held priority (unless it is still inheriting from other sources), and the task does not execute until another Continue. * The same holds if the held task is the only task on a protected entry queue whose barrier becomes open. The corresponding entry body executes. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-10|Previous]] | [[Guide:95lrm/RM-D-12|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} kmvb13t9gu7vc46dna1inaynfko181z Guide:95lrm/RM-D-12 4200 1138 4410 2019-05-01T23:10:42Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-11|Previous]] | [[Guide:95lrm/RM-E|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: D.12 Other Optimizations and Determinism Rules}} This clause describes various requirements for improving the response and determinism in a real-time system. == Implementation Requirements == If the implementation blocks interrupts (see [[Guide:95lrm/RM-C-3|C.3]]) not as a result of direct user action (e.g. an execution of a protected action) there shall be an upper bound on the duration of this blocking. The implementation shall recognize entry-less protected types. The overhead of acquiring the execution resource of an object of such a type (see [[Guide:95lrm/RM-9-5-1|9.5.1]]) shall be minimized. In particular, there should not be any overhead due to evaluating entry_barrier conditions. Unchecked_Deallocation shall be supported for terminated tasks that are designated by access types, and shall have the effect of releasing all the storage associated with the task. This includes any run-time system or heap storage that has been implicitly allocated for the task by the implementation. == Documentation Requirements == The implementation shall document the upper bound on the duration of interrupt blocking caused by the implementation. If this is different for different interrupts or interrupt priority levels, it should be documented for each case. == Metrics == The implementation shall document the following metric: * The overhead associated with obtaining a mutual-exclusive access to an entry-less protected object. This shall be measured in the following way: <p><span></span></p> :For a protected object of the form: <p><syntaxhighlight lang="Ada"> protected Lock is procedure Set; function Read return Boolean; private Flag : Boolean := False; end Lock;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> protected body Lock is procedure Set is begin    Flag := True; end Set; function Read return Boolean Begin    return Flag; end Read; end Lock;</syntaxhighlight></p> <p><span></span></p> :The execution time, in processor clock cycles, of a call to Set. This shall be measured between the point just before issuing the call, and the point just after the call completes. The function Read shall be called later to verify that Set was indeed called (and not optimized away). The calling task shall have sufficiently high priority as to not be preempted during the measurement period. The protected object shall have sufficiently high ceiling priority to allow the task to call Set. <p><span></span></p> :For a multiprocessor, if supported, the metric shall be reported for the case where no contention (on the execution resource) exists from tasks executing on other processors. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-11|Previous]] | [[Guide:95lrm/RM-E|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} abo245dta2tca27f4yv34gpsnn7wm7s Guide:95lrm/RM-D-2 4200 1139 4411 2019-04-29T15:48:25Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-1|Previous]] | [[Guide:95lrm/RM-D-2-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: D.2 Priority Scheduling}} This clause describes the rules that determine which task is selected for execution when more than one task is ready (see [[Guide:95lrm/RM-9-2|9.2]]). The rules have two parts: the task dispatching model (see [[Guide:95lrm/RM-D-2-1|D.2.1]]), and a specific task dispatching policy (see [[Guide:95lrm/RM-D-2-2|D.2.2]]). </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-1|Previous]] | [[Guide:95lrm/RM-D-2-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} qhut2vgukmecykf9a7v0st21xwkqhfa Guide:95lrm/RM-D-2-1 4200 1140 4412 2019-04-29T15:48:25Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-2|Previous]] | [[Guide:95lrm/RM-D-2-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: D.2.1 The Task Dispatching Model}} The task dispatching model specifies preemptive scheduling, based on conceptual priority-ordered ready queues. == Dynamic Semantics == A task runs (that is, it becomes a ''running task'') only when it is ready (see [[Guide:95lrm/RM-9-2|9.2]]) and the execution resources required by that task are available. Processors are allocated to tasks based on each task's active priority. It is implementation defined whether, on a multiprocessor, a task that is waiting for access to a protected object keeps its processor busy. <span id="I6527"></span><span id="I6528"></span><span id="I6529"></span><span id="I6530"></span>''Task dispatching'' is the process by which one ready task is selected for execution on a processor. This selection is done at certain points during the execution of a task called ''task dispatching points''. A task reaches a task dispatching point whenever it becomes blocked, and whenever it becomes ready. In addition, the completion of an accept_statement (see [[Guide:95lrm/RM-9-5-2|9.5.2]]), and task termination are task dispatching points for the executing task. Other task dispatching points are defined throughout this Annex. <span id="I6531"></span><span id="I6532"></span><span id="I6533"></span><span id="I6534"></span><span id="I6535"></span><span id="I6536"></span>''Task dispatching policies'' are specified in terms of conceptual ''ready queues'', task states, and task preemption. A ready queue is an ordered list of ready tasks. The first position in a queue is called the ''head of the queue'', and the last position is called the ''tail of the queue''. A task is ''ready'' if it is in a ready queue, or if it is running. Each processor has one ready queue for each priority value. At any instant, each ready queue of a processor contains exactly the set of tasks of that priority that are ready for execution on that processor, but are not running on any processor; that is, those tasks that are ready, are not running on any processor, and can be executed using that processor and other available resources. A task can be on the ready queues of more than one processor. <span id="I6537"></span>Each processor also has one ''running task'', which is the task currently being executed by that processor. Whenever a task running on a processor reaches a task dispatching point, one task is selected to run on that processor. The task selected is the one at the head of the highest priority nonempty ready queue; this task is then removed from all ready queues to which it belongs. <span id="I6538"></span>A preemptible resource is a resource that while allocated to one task can be allocated (temporarily) to another instead. Processors are preemptible resources. Access to a protected object (see [[Guide:95lrm/RM-9-5-1|9.5.1]]) is a nonpreemptible resource. <span id="I6539"></span>When a higher-priority task is dispatched to the processor, and the previously running task is placed on the appropriate ready queue, the latter task is said to be ''preempted''. <span id="I6540"></span><span id="I6541"></span>A new running task is also selected whenever there is a nonempty ready queue with a higher priority than the priority of the running task, or when the task dispatching policy requires a running task to go back to a ready queue. These are also task dispatching points. == Implementation Permissions == An implementation is allowed to define additional resources as execution resources, and to define the corresponding allocation policies for them. Such resources may have an implementation defined effect on task dispatching (see [[Guide:95lrm/RM-D-2-2|D.2.2]]). An implementation may place implementation-defined restrictions on tasks whose active priority is in the Interrupt_Priority range. == Notes == 7  Section 9 specifies under which circumstances a task becomes ready. The ready state is affected by the rules for task activation and termination, delay statements, and entry calls. <span id="I6542"></span>When a task is not ready, it is said to be blocked. 8  An example of a possible implementation-defined execution resource is a page of physical memory, which needs to be loaded with a particular page of virtual memory before a task can continue execution. 9  The ready queues are purely conceptual; there is no requirement that such lists physically exist in an implementation. 10  While a task is running, it is not on any ready queue. Any time the task that is running on a processor is added to a ready queue, a new running task is selected for that processor. 11  In a multiprocessor system, a task can be on the ready queues of more than one processor. At the extreme, if several processors share the same set of ready tasks, the contents of their ready queues is identical, and so they can be viewed as sharing one ready queue, and can be implemented that way. Thus, the dispatching model covers multiprocessors where dispatching is implemented using a single ready queue, as well as those with separate dispatching domains. 12  The priority of a task is determined by rules specified in this subclause, and under [[Guide:95lrm/RM-D-1|D.1]], ''[[Guide:95lrm/RM-D-1|Task Priorities]]'', [[Guide:95lrm/RM-D-3|D.3]], ''[[Guide:95lrm/RM-D-3|Priority Ceiling Locking]]'', and [[Guide:95lrm/RM-D-5|D.5]], ''[[Guide:95lrm/RM-D-5|Dynamic Priorities]]''. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-2|Previous]] | [[Guide:95lrm/RM-D-2-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} gst0ger6sa769j636jx86cc4qkijedf Guide:95lrm/RM-D-2-2 4200 1141 4413 2019-05-01T22:49:45Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-2-1|Previous]] | [[Guide:95lrm/RM-D-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: D.2.2 The Standard Task Dispatching Policy}} == Syntax == The form of a pragma Task_Dispatching_Policy is as follows: <p><span></span></p> '''pragma''' <span id="I6543"></span><span id="I6544"></span>Task_Dispatching_Policy(''policy_''<span id="I6545"></span>identifier ); == Legality Rules == The ''policy_''<span id="I6546"></span>identifier shall either be FIFO_Within_Priorities or an implementation-defined <span id="I6547"></span>identifier. == Post-Compilation Rules == <span id="I6548"></span><span id="I6549"></span>A Task_Dispatching_Policy pragma is a configuration pragma. If the FIFO_Within_Priorities policy is specified for a partition, then the Ceiling_Locking policy (see [[Guide:95lrm/RM-D-3|D.3]]) shall also be specified for the partition. == Dynamic Semantics == <span id="I6550"></span>A ''task dispatching policy'' specifies the details of task dispatching that are not covered by the basic task dispatching model. These rules govern when tasks are inserted into and deleted from the ready queues, and whether a task is inserted at the head or the tail of the queue for its active priority. The task dispatching policy is specified by a Task_Dispatching_Policy configuration pragma. <span id="I6551"></span>If no such pragma appears in any of the program units comprising a partition, the task dispatching policy for that partition is unspecified. The language defines only one task dispatching policy, FIFO_Within_Priorities; when this policy is in effect, modifications to the ready queues occur only as follows: * When a blocked task becomes ready, it is added at the tail of the ready queue for its active priority. * When the active priority of a ready task that is not running changes, or the setting of its base priority takes effect, the task is removed from the ready queue for its old active priority and is added at the tail of the ready queue for its new active priority, except in the case where the active priority is lowered due to the loss of inherited priority, in which case the task is added at the head of the ready queue for its new active priority. * When the setting of the base priority of a running task takes effect, the task is added to the tail of the ready queue for its active priority. * When a task executes a delay_statement that does not result in blocking, it is added to the tail of the ready queue for its active priority. <span id="I6552"></span><span id="I6553"></span>Each of the events specified above is a task dispatching point (see [[Guide:95lrm/RM-D-2-1|D.2.1]]). In addition, when a task is preempted, it is added at the head of the ready queue for its active priority. == Documentation Requirements == <span id="I6554"></span>''Priority inversion'' is the duration for which a task remains at the head of the highest priority ready queue while the processor executes a lower priority task. The implementation shall document: * The maximum priority inversion a user task can experience due to activity of the implementation (on behalf of lower priority tasks), and * whether execution of a task can be preempted by the implementation processing of delay expirations for lower priority tasks, and if so, for how long. == Implementation Permissions == Implementations are allowed to define other task dispatching policies, but need not support more than one such policy per partition. For optimization purposes, an implementation may alter the points at which task dispatching occurs, in an implementation defined manner. However, a delay_statement always corresponds to at least one task dispatching point. == Notes == 13  If the active priority of a running task is lowered due to loss of inherited priority (as it is on completion of a protected operation) and there is a ready task of the same active priority that is not running, the running task continues to run (provided that there is no higher priority task). 14  The setting of a task's base priority as a result of a call to Set_Priority does not always take effect immediately when Set_Priority is called. The effect of setting the task's base priority is deferred while the affected task performs a protected action. 15  Setting the base priority of a ready task causes the task to move to the end of the queue for its active priority, regardless of whether the active priority of the task actually changes. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-2-1|Previous]] | [[Guide:95lrm/RM-D-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 58lggoqkl1onb3j0zrntjhwxdysrn1n Guide:95lrm/RM-D-3 4200 1142 4414 2019-05-01T22:58:05Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-2-2|Previous]] | [[Guide:95lrm/RM-D-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: D.3 Priority Ceiling Locking}} This clause specifies the interactions between priority task scheduling and protected object ceilings. This interaction is based on the concept of the ''ceiling priority'' of a protected object. == Syntax == The form of a pragma Locking_Policy is as follows: <p><span></span></p> '''pragma''' <span id="I6555"></span><span id="I6556"></span>Locking_Policy(''policy_''<span id="I6557"></span>identifier); == Legality Rules == The ''policy_''<span id="I6558"></span>identifier shall either be Ceiling_Locking or an implementation-defined <span id="I6559"></span>identifier. == Post-Compilation Rules == <span id="I6560"></span><span id="I6561"></span>A Locking_Policy pragma is a configuration pragma. == Dynamic Semantics == <span id="I6562"></span>A locking policy specifies the details of protected object locking. These rules specify whether or not protected objects have priorities, and the relationships between these priorities and task priorities. In addition, the policy specifies the state of a task when it executes a protected action, and how its active priority is affected by the locking. The ''locking policy'' is specified by a Locking_Policy pragma. For implementation-defined locking policies, the effect of a Priority or Interrupt_Priority pragma on a protected object is implementation defined. If no Locking_Policy pragma applies to any of the program units comprising a partition, the locking policy for that partition, as well as the effect of specifying either a Priority or Interrupt_Priority pragma for a protected object, are implementation defined. There is one predefined locking policy, Ceiling_Locking; this policy is defined as follows: * <span id="I6563"></span>Every protected object has a ''ceiling priority'', which is determined by either a Priority or Interrupt_Priority pragma as defined in [[Guide:95lrm/RM-D-1|D.1]]. The ceiling priority of a protected object (or ceiling, for short) is an upper bound on the active priority a task can have when it calls protected operations of that protected object. * The expression of a Priority or Interrupt_Priority pragma is evaluated as part of the creation of the corresponding protected object and converted to the subtype System.Any_Priority or System.Interrupt_Priority, respectively. The value of the expression is the ceiling priority of the corresponding protected object. <span id="I6564"></span><span id="I6565"></span> * If an Interrupt_Handler or Attach_Handler pragma (see [[Guide:95lrm/RM-C-3-1|C.3.1]]) appears in a protected_definition without an Interrupt_Priority pragma, the ceiling priority of protected objects of that type is implementation defined, but in the range of the subtype System.Interrupt_Priority. * If no pragma Priority, Interrupt_Priority, Interrupt_Handler, or Attach_Handler is specified in the protected_definition, then the ceiling priority of the corresponding protected object is System.Priority'Last. * While a task executes a protected action, it inherits the ceiling priority of the corresponding protected object. * <span id="I6566"></span><span id="I6567"></span><span id="I6568"></span>When a task calls a protected operation, a check is made that its active priority is not higher than the ceiling of the corresponding protected object; Program_Error is raised if this check fails. == Implementation Permissions == The implementation is allowed to round all ceilings in a certain subrange of System.Priority or System.Interrupt_Priority up to the top of that subrange, uniformly. Implementations are allowed to define other locking policies, but need not support more than one such policy per partition. Since implementations are allowed to place restrictions on code that runs at an interrupt-level active priority (see [[Guide:95lrm/RM-C-3-1|C.3.1]] and [[Guide:95lrm/RM-D-2-1|D.2.1]]), the implementation may implement a language feature in terms of a protected object with an implementation-defined ceiling, but the ceiling shall be no less than Priority'Last. == Implementation Advice == The implementation should use names that end with ''_Locking'' for implementation-defined locking policies. == Notes == 16  While a task executes in a protected action, it can be preempted only by tasks whose active priorities are higher than the ceiling priority of the protected object. 17  If a protected object has a ceiling priority in the range of Interrupt_Priority, certain interrupts are blocked while protected actions of that object execute. In the extreme, if the ceiling is Interrupt_Priority'Last, all blockable interrupts are blocked during that time. 18  The ceiling priority of a protected object has to be in the Interrupt_Priority range if one of its procedures is to be used as an interrupt handler (see [[Guide:95lrm/RM-C-3|C.3]]). 19  When specifying the ceiling of a protected object, one should choose a value that is at least as high as the highest active priority at which tasks can be executing when they call protected operations of that object. In determining this value the following factors, which can affect active priority, should be considered: the effect of Set_Priority, nested protected operations, entry calls, task activation, and other implementation-defined factors. 20  Attaching a protected procedure whose ceiling is below the interrupt hardware priority to an interrupt causes the execution of the program to be erroneous (see [[Guide:95lrm/RM-C-3-1|C.3.1]]). 21  On a single processor implementation, the ceiling priority rules guarantee that there is no possibility of deadlock involving only protected subprograms (excluding the case where a protected operation calls another protected operation on the same protected object). </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-2-2|Previous]] | [[Guide:95lrm/RM-D-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} fo9mqq1p6etmeqx6pi8vmgpp9agctxn Guide:95lrm/RM-D-4 4200 1143 4415 2019-05-01T22:58:40Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-3|Previous]] | [[Guide:95lrm/RM-D-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: D.4 Entry Queuing Policies}} <span id="I6569"></span>This clause specifies a mechanism for a user to choose an entry ''queuing policy''. It also defines two such policies. Other policies are implementation defined. == Syntax == The form of a pragma Queuing_Policy is as follows: <p><span></span></p> '''pragma''' <span id="I6570"></span><span id="I6571"></span>Queuing_Policy(''policy_''<span id="I6572"></span>identifier); == Legality Rules == The ''policy_''<span id="I6573"></span>identifier shall be either FIFO_Queuing, Priority_Queuing or an implementation-defined <span id="I6574"></span>identifier. == Post-Compilation Rules == <span id="I6575"></span><span id="I6576"></span>A Queuing_Policy pragma is a configuration pragma. == Dynamic Semantics == <span id="I6577"></span>A ''queuing policy'' governs the order in which tasks are queued for entry service, and the order in which different entry queues are considered for service. The queuing policy is specified by a Queuing_Policy pragma. Two queuing policies, FIFO_Queuing and Priority_Queuing, are language defined. If no Queuing_Policy pragma appears in any of the program units comprising the partition, the queuing policy for that partition is FIFO_Queuing. The rules for this policy are specified in [[Guide:95lrm/RM-9-5-3|9.5.3]] and [[Guide:95lrm/RM-9-7-1|9.7.1]]. The Priority_Queuing policy is defined as follows: * <span id="I6578"></span>The calls to an entry (including a member of an entry family) are queued in an order consistent with the priorities of the calls. The ''priority of an entry call'' is initialized from the active priority of the calling task at the time the call is made, but can change later. Within the same priority, the order is consistent with the calling (or requeuing, or priority setting) time (that is, a FIFO order). * After a call is first queued, changes to the active priority of a task do not affect the priority of the call, unless the base priority of the task is set while the task is blocked on an entry call. * When the base priority of a task is set (see [[Guide:95lrm/RM-D-5|D.5]]), if the task is blocked on an entry call, and the call is queued, the priority of the call is updated to the new active priority of the calling task. This causes the call to be removed from and then reinserted in the queue at the new active priority. * When more than one condition of an entry_barrier of a protected object becomes True, and more than one of the respective queues is nonempty, the call with the highest priority is selected. If more than one such call has the same priority, the call that is queued on the entry whose declaration is first in textual order in the protected_definition is selected. For members of the same entry family, the one with the lower family index is selected. * If the expiration time of two or more open delay_alternatives is the same and no other accept_alternatives are open, the sequence_of_statements of the delay_alternative that is first in textual order in the selective_accept is executed. * When more than one alternative of a selective_accept is open and has queued calls, an alternative whose queue has the highest-priority call at its head is selected. If two or more open alternatives have equal-priority queued calls, then a call on the entry in the accept_alternative that is first in textual order in the selective_accept is selected. == Implementation Permissions == Implementations are allowed to define other queuing policies, but need not support more than one such policy per partition. == Implementation Advice == The implementation should use names that end with ''_Queuing'' for implementation-defined queuing policies. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-3|Previous]] | [[Guide:95lrm/RM-D-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} ps7jq1nybqmxo2y59bwrte670a1uf5v Guide:95lrm/RM-D-5 4200 1144 4416 2019-05-01T22:59:50Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-4|Previous]] | [[Guide:95lrm/RM-D-6|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: D.5 Dynamic Priorities}} This clause specifies how the base priority of a task can be modified or queried at run time. == Static Semantics == The following language-defined library package exists: <p><syntaxhighlight lang="Ada"> with System; with Ada.Task_Identification; -- See C.7.1 package Ada.Dynamic_Priorities is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     procedure Set_Priority(Priority : in System.Any_Priority;                         T : in Ada.Task_Identification.Task_ID :=                         Ada.Task_Identification.Current_Task);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     function Get_Priority (T : Ada.Task_Identification.Task_ID :=                         Ada.Task_Identification.Current_Task)                         return System.Any_Priority;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> end Ada.Dynamic_Priorities;</syntaxhighlight></p> == Dynamic Semantics == The procedure Set_Priority sets the base priority of the specified task to the specified Priority value. Set_Priority has no effect if the task is terminated. The function Get_Priority returns T's current base priority. <span id="I6586"></span>Tasking_Error is raised if the task is terminated. <span id="I6587"></span>Program_Error is raised by Set_Priority and Get_Priority if T is equal to Null_Task_ID. Setting the task's base priority to the new value takes place as soon as is practical but not while the task is performing a protected action. This setting occurs no later then the next abort completion point of the task T (see [[Guide:95lrm/RM-9-8|9.8]]). == Bounded (Run-Time) Errors == <span id="I6588"></span>If a task is blocked on a protected entry call, and the call is queued, it is a bounded error to raise its base priority above the ceiling priority of the corresponding protected object. When an entry call is cancelled, it is a bounded error if the priority of the calling task is higher than the ceiling priority of the corresponding protected object. <span id="I6589"></span>In either of these cases, either Program_Error is raised in the task that called the entry, or its priority is temporarily lowered, or both, or neither. == Erroneous Execution == <span id="I6590"></span>If any subprogram in this package is called with a parameter T that specifies a task object that no longer exists, the execution of the program is erroneous. == Metrics == The implementation shall document the following metric: * The execution time of a call to Set_Priority, for the nonpreempting case, in processor clock cycles. This is measured for a call that modifies the priority of a ready task that is not running (which cannot be the calling one), where the new base priority of the affected task is lower than the active priority of the calling task, and the affected task is not on any entry queue and is not executing a protected operation. == Notes == 22  Setting a task's base priority affects task dispatching. First, it can change the task's active priority. Second, under the standard task dispatching policy it always causes the task to move to the tail of the ready queue corresponding to its active priority, even if the new base priority is unchanged. 23  Under the priority queuing policy, setting a task's base priority has an effect on a queued entry call if the task is blocked waiting for the call. That is, setting the base priority of a task causes the priority of a queued entry call from that task to be updated and the call to be removed and then reinserted in the entry queue at the new priority (see [[Guide:95lrm/RM-D-4|D.4]]), unless the call originated from the triggering_statement of an asynchronous_select. 24  The effect of two or more Set_Priority calls executed in parallel on the same task is defined as executing these calls in some serial order. 25  The rule for when Tasking_Error is raised for Set_Priority or Get_Priority is different from the rule for when Tasking_Error is raised on an entry call (see [[Guide:95lrm/RM-9-5-3|9.5.3]]). In particular, setting or querying the priority of a completed or an abnormal task is allowed, so long as the task is not yet terminated. 26  Changing the priorities of a set of tasks can be performed by a series of calls to Set_Priority for each task separately. For this to work reliably, it should be done within a protected operation that has high enough ceiling priority to guarantee that the operation completes without being preempted by any of the affected tasks. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-4|Previous]] | [[Guide:95lrm/RM-D-6|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 726sb7owtw29mre8vkquwkm5pioh7bn Guide:95lrm/RM-D-6 4200 1145 4417 2019-04-29T15:48:25Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-5|Previous]] | [[Guide:95lrm/RM-D-7|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: D.6 Preemptive Abort}} This clause specifies requirements on the immediacy with which an aborted construct is completed. == Dynamic Semantics == On a system with a single processor, an aborted construct is completed immediately at the first point that is outside the execution of an abort-deferred operation. == Documentation Requirements == On a multiprocessor, the implementation shall document any conditions that cause the completion of an aborted construct to be delayed later than what is specified for a single processor. == Metrics == The implementation shall document the following metrics: * The execution time, in processor clock cycles, that it takes for an abort_statement to cause the completion of the aborted task. This is measured in a situation where a task T2 preempts task T1 and aborts T1. T1 does not have any finalization code. T2 shall verify that T1 has terminated, by means of the Terminated attribute. * On a multiprocessor, an upper bound in seconds, on the time that the completion of an aborted task can be delayed beyond the point that it is required for a single processor. * An upper bound on the execution time of an asynchronous_select, in processor clock cycles. This is measured between a point immediately before a task T1 executes a protected operation Pr.Set that makes the condition of an entry_barrier Pr.Wait true, and the point where task T2 resumes execution immediately after an entry call to Pr.Wait in an asynchronous_select. T1 preempts T2 while T2 is executing the abortable part, and then blocks itself so that T2 can execute. The execution time of T1 is measured separately, and subtracted. * An upper bound on the execution time of an asynchronous_select, in the case that no asynchronous transfer of control takes place. This is measured between a point immediately before a task executes the asynchronous_select with a nonnull abortable part, and the point where the task continues execution immediately after it. The execution time of the abortable part is subtracted. == Implementation Advice == Even though the abort_statement is included in the list of potentially blocking operations (see [[Guide:95lrm/RM-9-5-1|9.5.1]]), it is recommended that this statement be implemented in a way that never requires the task executing the abort_statement to block. On a multi-processor, the delay associated with aborting a task on another processor should be bounded; the implementation should use periodic polling, if necessary, to achieve this. == Notes == 27  Abortion does not change the active or base priority of the aborted task. 28  Abortion cannot be more immediate than is allowed by the rules for deferral of abortion during finalization and in protected actions. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-5|Previous]] | [[Guide:95lrm/RM-D-7|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 9cfrpvyoa66jlk817palgdewdfmakme Guide:95lrm/RM-D-7 4200 1146 4418 2019-04-29T15:48:25Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-6|Previous]] | [[Guide:95lrm/RM-D-8|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: D.7 Tasking Restrictions}} This clause defines restrictions that can be used with a pragma Restrictions (see [[Guide:95lrm/RM-13-12|13.12]]) to facilitate the construction of highly efficient tasking run-time systems. == Static Semantics == The following ''restriction_''identifiers are language defined: ; <span id="I6591"></span>No_Task_Hierarchy : All (nonenvironment) tasks depend directly on the environment task of the partition. ;   <span id="I6592"></span>No_Nested_Finalization : Objects with controlled, protected, or task parts and access types that designate such objects, shall be declared only at library level. ; <span id="I6593"></span>No_Abort_Statements : There are no abort_statements, and there are no calls on Task_Identification.Abort_Task. ; <span id="I6594"></span>No_Terminate_Alternatives : There are no selective_accepts with terminate_alternatives. ; <span id="I6595"></span>No_Task_Allocators : There are no allocators for task types or types containing task subcomponents. ; <span id="I6596"></span>No_Implicit_Heap_Allocations : There are no operations that implicitly require heap storage allocation to be performed by the implementation. The operations that implicitly require heap storage allocation are implementation defined. ; No_Dynamic_Priorities : There are no semantic dependences on the package Dynamic_Priorities. <span id="I6597"></span> ;  <span id="I6598"></span>No_Asynchronous_Control : There are no semantic dependences on the package Asynchronous_Task_Control. The following ''restriction_parameter_''identifiers are language defined: ;  <span id="I6599"></span>Max_Select_Alternatives : Specifies the maximum number of alternatives in a selective_accept. ;  <span id="I6600"></span>Max_Task_Entries : Specifies the maximum number of entries per task. The bounds of every entry family of a task unit shall be static, or shall be defined by a discriminant of a subtype whose corresponding bound is static. A value of zero indicates that no rendezvous are possible. ;  Max_Protected_Entries : Specifies the maximum number of entries per protected type. The bounds of every entry family of a protected unit shall be static, or shall be defined by a discriminant of a subtype whose corresponding bound is static. <span id="I6601"></span> == Dynamic Semantics == ''This paragraph was deleted.'' The following ''restriction_parameter_''identifiers are language defined: ;    <span id="I6602"></span>Max_Storage_At_Blocking : Specifies the maximum portion (in storage elements) of a task's Storage_Size that can be retained by a blocked task. If an implementation chooses to detect a violation of this restriction, Storage_Error should be raised; <span id="I6603"></span><span id="I6604"></span><span id="I6605"></span>otherwise, the behavior is implementation defined. ;    <span id="I6606"></span>Max_Asynchronous_Select_Nesting : Specifies the maximum dynamic nesting level of asynchronous_selects. A value of zero prevents the use of any asynchronous_select and, if a program contains an asynchronous_select, it is illegal. If an implementation chooses to detect a violation of this restriction for values other than zero, Storage_Error should be raised; <span id="I6607"></span><span id="I6608"></span><span id="I6609"></span>otherwise, the behavior is implementation defined. ;    <span id="I6610"></span>Max_Tasks : Specifies the maximum number of task creations that may be executed over the lifetime of a partition, not counting the creation of the environment task. A value of zero prevents any task creation and, if a program contains a task creation, it is illegal. If an implementation chooses to detect a violation of this restriction, Storage_Error should be raised; <span id="I6611"></span><span id="I6612"></span><span id="I6613"></span>otherwise, the behavior is implementation defined. It is implementation defined whether the use of pragma Restrictions results in a reduction in executable program size, storage requirements, or execution time. If possible, the implementation should provide quantitative descriptions of such effects for each restriction. == Implementation Advice == When feasible, the implementation should take advantage of the specified restrictions to produce a more efficient implementation. == Notes == 29  The above Storage_Checks can be suppressed with pragma Suppress. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-6|Previous]] | [[Guide:95lrm/RM-D-8|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} b69xdn9jv7lm2r7obd2gyi8spb1n972 Guide:95lrm/RM-D-8 4200 1147 4419 2019-05-01T23:07:02Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-7|Previous]] | [[Guide:95lrm/RM-D-9|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: D.8 Monotonic Time}} This clause specifies a high-resolution, monotonic clock package. == Static Semantics == The following language-defined library package exists: <p><syntaxhighlight lang="Ada"> package Ada.Real_Time is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Time is private;    Time_First : constant Time;    Time_Last : constant Time;    Time_Unit : constant := implementation-defined-real-number;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Time_Span is private;    Time_Span_First : constant Time_Span;    Time_Span_Last : constant Time_Span;    Time_Span_Zero : constant Time_Span;    Time_Span_Unit : constant Time_Span;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Tick : constant Time_Span;    function Clock return Time;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "+" (Left : Time; Right : Time_Span) return Time;    function "+" (Left : Time_Span; Right : Time) return Time;    function "-" (Left : Time; Right : Time_Span) return Time;    function "-" (Left : Time; Right : Time) return Time_Span;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "<" (Left, Right : Time) return Boolean;    function "<="(Left, Right : Time) return Boolean;    function ">" (Left, Right : Time) return Boolean;    function ">="(Left, Right : Time) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "+" (Left, Right : Time_Span) return Time_Span;    function "-" (Left, Right : Time_Span) return Time_Span;    function "-" (Right : Time_Span) return Time_Span;    function "*" (Left : Time_Span; Right : Integer) return Time_Span;    function "*" (Left : Integer; Right : Time_Span) return Time_Span;    function "/" (Left, Right : Time_Span) return Integer;    function "/" (Left : Time_Span; Right : Integer) return Time_Span;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "abs"(Right : Time_Span) return Time_Span;</syntaxhighlight></p> ''This paragraph was deleted.'' <p><syntaxhighlight lang="Ada">     function "<" (Left, Right : Time_Span) return Boolean;     function "<="(Left, Right : Time_Span) return Boolean;     function ">" (Left, Right : Time_Span) return Boolean;     function ">="(Left, Right : Time_Span) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     function To_Duration (TS : Time_Span) return Duration;     function To_Time_Span (D : Duration) return Time_Span;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Nanoseconds  (NS : Integer) return Time_Span;    function Microseconds (US : Integer) return Time_Span;  function Milliseconds (MS : Integer) return Time_Span;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   type Seconds_Count is range implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   procedure Split(T : in Time; SC : out Seconds_Count; TS : out Time_Span);   function Time_Of(SC : Seconds_Count; TS : Time_Span) return Time;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> private ... -- not specified by the language end Ada.Real_Time;</syntaxhighlight></p> <span id="I6647"></span>In this Annex, ''real time'' is defined to be the physical time as observed in the external environment. The type Time is a ''time type'' as defined by [[Guide:95lrm/RM-9-6|9.6]]; values of this type may be used in a delay_until_statement. Values of this type represent segments of an ideal time line. The set of values of the type Time corresponds one-to-one with an implementation-defined range of mathematical integers. <span id="I6648"></span><span id="I6649"></span>The Time value I represents the half-open real time interval that starts with E+I*Time_Unit and is limited by E+(I+1)*Time_Unit, where Time_Unit is an implementation-defined real number and E is an unspecified origin point, the ''epoch'', that is the same for all values of the type Time. It is not specified by the language whether the time values are synchronized with any standard time reference. For example, E can correspond to the time of system initialization or it can correspond to the epoch of some time standard. Values of the type Time_Span represent length of real time duration. The set of values of this type corresponds one-to-one with an implementation-defined range of mathematical integers. The Time_Span value corresponding to the integer I represents the real-time duration I*Time_Unit. Time_First and Time_Last are the smallest and largest values of the Time type, respectively. Similarly, Time_Span_First and Time_Span_Last are the smallest and largest values of the Time_Span type, respectively. A value of type Seconds_Count represents an elapsed time, measured in seconds, since the epoch. == Dynamic Semantics == Time_Unit is the smallest amount of real time representable by the Time type; it is expressed in seconds. Time_Span_Unit is the difference between two successive values of the Time type. It is also the smallest positive value of type Time_Span. Time_Unit and Time_Span_Unit represent the same real time duration. <span id="I6650"></span>A ''clock tick'' is a real time interval during which the clock value (as observed by calling the Clock function) remains constant. Tick is the average length of such intervals. The function To_Duration converts the value TS to a value of type Duration. Similarly, the function To_Time_Span converts the value D to a value of type Time_Span. For both operations, the result is rounded to the nearest exactly representable value (away from zero if exactly halfway between two exactly representable values). To_Duration(Time_Span_Zero) returns 0.0, and To_Time_Span(0.0) returns Time_Span_Zero. The functions Nanoseconds, Microseconds, and Milliseconds convert the input parameter to a value of the type Time_Span. NS, US, and MS are interpreted as a number of nanoseconds, microseconds, and milliseconds respectively. The result is rounded to the nearest exactly representable value (away from zero if exactly halfway between two exactly representable values). The effects of the operators on Time and Time_Span are as for the operators defined for integer types. The function Clock returns the amount of time since the epoch. The effects of the Split and Time_Of operations are defined as follows, treating values of type Time, Time_Span, and Seconds_Count as mathematical integers. The effect of Split(T,SC,TS) is to set SC and TS to values such that T*Time_Unit = SC*1.0 + TS*Time_Unit, and 0.0 <= TS*Time_Unit < 1.0. The value returned by Time_Of(SC,TS) is the value T such that T*Time_Unit = SC*1.0 + TS*Time_Unit. == Implementation Requirements == The range of Time values shall be sufficient to uniquely represent the range of real times from program start-up to 50 years later. Tick shall be no greater than 1 millisecond. Time_Unit shall be less than or equal to 20 microseconds. Time_Span_First shall be no greater than -3600 seconds, and Time_Span_Last shall be no less than 3600 seconds. <span id="I6651"></span>A ''clock jump'' is the difference between two successive distinct values of the clock (as observed by calling the Clock function). There shall be no backward clock jumps. == Documentation Requirements == The implementation shall document the values of Time_First, Time_Last, Time_Span_First, Time_Span_Last, Time_Span_Unit, and Tick. The implementation shall document the properties of the underlying time base used for the clock and for type Time, such as the range of values supported and any relevant aspects of the underlying hardware or operating system facilities used. The implementation shall document whether or not there is any synchronization with external time references, and if such synchronization exists, the sources of synchronization information, the frequency of synchronization, and the synchronization method applied. The implementation shall document any aspects of the external environment that could interfere with the clock behavior as defined in this clause. == Metrics == For the purpose of the metrics defined in this clause, real time is defined to be the International Atomic Time (TAI). The implementation shall document the following metrics: * An upper bound on the real-time duration of a clock tick. This is a value D such that if t1 and t2 are any real times such that t1 < t2 and Clock<sub>t1</sub> = Clock<sub>t2</sub> then t2 - t1 <= D. * An upper bound on the size of a clock jump. * <span id="I6652"></span>An upper bound on the ''drift rate'' of Clock with respect to real time. This is a real number D such that <p><span></span></p> :E*(1-D) <= (Clock<sub>t+E</sub> - Clock<sub>t</sub>) <= E*(1+D)<br />provided that: Clock<sub>t</sub> + E*(1+D) <= Time_Last. * where Clock<sub>t</sub> is the value of Clock at time t, and E is a real time duration not less than 24 hours. The value of E used for this metric shall be reported. * An upper bound on the execution time of a call to the Clock function, in processor clock cycles. * Upper bounds on the execution times of the operators of the types Time and Time_Span, in processor clock cycles. == Implementation Permissions == Implementations targeted to machines with word size smaller than 32 bits need not support the full range and granularity of the Time and Time_Span types. == Implementation Advice == When appropriate, implementations should provide configuration mechanisms to change the value of Tick. It is recommended that Calendar.Clock and Real_Time.Clock be implemented as transformations of the same time base. It is recommended that the ''best'' time base which exists in the underlying system be available to the application through Clock. ''Best'' may mean highest accuracy or largest range. == Notes == 30  The rules in this clause do not imply that the implementation can protect the user from operator or installation errors which could result in the clock being set incorrectly. 31  Time_Unit is the granularity of the Time type. In contrast, Tick represents the granularity of Real_Time.Clock. There is no requirement that these be the same. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-7|Previous]] | [[Guide:95lrm/RM-D-9|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} jqzsovvyw4t44n6ogbjg5r8xnf2wzsu Guide:95lrm/RM-D-9 4200 1148 4420 2019-04-29T15:48:25Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-8|Previous]] | [[Guide:95lrm/RM-D-10|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: D.9 Delay Accuracy}} This clause specifies performance requirements for the delay_statement. The rules apply both to delay_relative_statement and to delay_until_statement. Similarly, they apply equally to a simple delay_statement and to one which appears in a delay_alternative. == Dynamic Semantics == The effect of the delay_statement for Real_Time.Time is defined in terms of Real_Time.Clock: * If C<sub>1</sub> is a value of Clock read before a task executes a delay_relative_statement with duration D, and C<sub>2</sub> is a value of Clock read after the task resumes execution following that delay_statement, then C<sub>2</sub> - C<sub>1</sub> >= D. * If C is a value of Clock read after a task resumes execution following a delay_until_statement with Real_Time.Time value T, then C >= T. <span id="I6653"></span><span id="I6654"></span>A simple delay_statement with a negative or zero value for the expiration time does not cause the calling task to be blocked; it is nevertheless a potentially blocking operation (see [[Guide:95lrm/RM-9-5-1|9.5.1]]). When a delay_statement appears in a delay_alternative of a timed_entry_call the selection of the entry call is attempted, regardless of the specified expiration time. When a delay_statement appears in a selective_accept_alternative, and a call is queued on one of the open entries, the selection of that entry call proceeds, regardless of the value of the delay expression. == Documentation Requirements == The implementation shall document the minimum value of the delay expression of a delay_relative_statement that causes the task to actually be blocked. The implementation shall document the minimum difference between the value of the delay expression of a delay_until_statement and the value of Real_Time.Clock, that causes the task to actually be blocked. == Metrics == The implementation shall document the following metrics: * An upper bound on the execution time, in processor clock cycles, of a delay_relative_statement whose requested value of the delay expression is less than or equal to zero. * An upper bound on the execution time, in processor clock cycles, of a delay_until_statement whose requested value of the delay expression is less than or equal to the value of Real_Time.Clock at the time of executing the statement. Similarly, for Calendar.Clock. * <span id="I6655"></span><span id="I6656"></span>An upper bound on the ''lateness'' of a delay_relative_statement, for a positive value of the delay expression, in a situation where the task has sufficient priority to preempt the processor as soon as it becomes ready, and does not need to wait for any other execution resources. The upper bound is expressed as a function of the value of the delay expression. The lateness is obtained by subtracting the value of the delay expression from the ''actual duration''. The actual duration is measured from a point immediately before a task executes the delay_statement to a point immediately after the task resumes execution following this statement. * An upper bound on the lateness of a delay_until_statement, in a situation where the value of the requested expiration time is after the time the task begins executing the statement, the task has sufficient priority to preempt the processor as soon as it becomes ready, and it does not need to wait for any other execution resources. The upper bound is expressed as a function of the difference between the requested expiration time and the clock value at the time the statement begins execution. The lateness of a delay_until_statement is obtained by subtracting the requested expiration time from the real time that the task resumes execution following this statement. == Notes == 32  The execution time of a delay_statement that does not cause the task to be blocked (e.g. '''''delay''' 0.0;'' ) is of interest in situations where delays are used to achieve voluntary round-robin task dispatching among equal-priority tasks. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-8|Previous]] | [[Guide:95lrm/RM-D-10|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 3f06taejninbegtatzxrtudxkppv6y3 Guide:95lrm/RM-E 4200 1149 4421 2019-05-01T23:11:15Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-12|Previous]] | [[Guide:95lrm/RM-E-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Annex E. Distributed Systems}} <div>(normative)</div> This Annex defines facilities for supporting the implementation of distributed systems using multiple partitions working cooperatively as part of a single Ada program. == Post-Compilation Rules == <span id="I6688"></span><span id="I6689"></span><span id="I6690"></span>A ''distributed system'' is an interconnection of one or more ''processing nodes'' (a system resource that has both computational and storage capabilities), and zero or more ''storage nodes'' (a system resource that has only storage capabilities, with the storage addressable by one or more processing nodes). <span id="I6691"></span>A ''distributed program'' comprises one or more partitions that execute independently (except when they communicate) in a distributed system. <span id="I6692"></span>The process of mapping the partitions of a program to the nodes in a distributed system is called ''configuring the partitions of the program''. == Implementation Requirements == The implementation shall provide means for explicitly assigning library units to a partition and for the configuring and execution of a program consisting of multiple partitions on a distributed system; the means are implementation defined. == Implementation Permissions == An implementation may require that the set of processing nodes of a distributed system be homogeneous. == Notes == 1  The partitions comprising a program may be executed on differently configured distributed systems or on a non-distributed system without requiring recompilation. A distributed program may be partitioned differently from the same set of library units without recompilation. The resulting execution is semantically equivalent. 2  A distributed program retains the same type safety as the equivalent single partition program. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-D-12|Previous]] | [[Guide:95lrm/RM-E-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 6morzg0n2y9qvgeg2zva4h54btz1m9e Guide:95lrm/RM-E-1 4200 1150 4422 2019-04-29T15:48:25Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-E|Previous]] | [[Guide:95lrm/RM-E-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: E.1 Partitions}} The partitions of a distributed program are classified as either active or passive. == Post-Compilation Rules == <span id="I6693"></span><span id="I6694"></span>An ''active partition'' is a partition as defined in [[Guide:95lrm/RM-10-2|10.2]]. A ''passive partition'' is a partition that has no thread of control of its own, whose library units are all preelaborated, and whose data and subprograms are accessible to one or more active partitions. A passive partition shall include only library_items that either are declared pure or are shared passive (see [[Guide:95lrm/RM-10-2-1|10.2.1]] and [[Guide:95lrm/RM-E-2-1|E.2.1]]). An active partition shall be configured on a processing node. A passive partition shall be configured either on a storage node or on a processing node. The configuration of the partitions of a program onto a distributed system shall be consistent with the possibility for data references or calls between the partitions implied by their semantic dependences. <span id="I6695"></span>Any reference to data or call of a subprogram across partitions is called a ''remote access''. == Dynamic Semantics == <span id="I6696"></span>A library_item is elaborated as part of the elaboration of each partition that includes it. If a normal library unit (see [[Guide:95lrm/RM-E-2|E.2]]) has state, then a separate copy of the state exists in each active partition that elaborates it. The state evolves independently in each such partition. <span id="I6697"></span><span id="I6698"></span><span id="I6699"></span><span id="I6700"></span>An active partition ''terminates'' when its environment task terminates. A partition becomes ''inaccessible'' if it terminates or if it is ''aborted''. An active partition is aborted when its environment task is aborted. In addition, if a partition fails during its elaboration, it becomes inaccessible to other partitions. Other implementation-defined events can also result in a partition becoming inaccessible. For a prefix D that denotes a library-level declaration, excepting a declaration of or within a declared-pure library unit, the following attribute is defined: ; D'Partition_ID : <span id="I6701"></span><span id="I6702"></span>Denotes a value of the type ''universal_integer'' that identifies the partition in which D was elaborated. If D denotes the declaration of a remote call interface library unit (see [[Guide:95lrm/RM-E-2-3|E.2.3]]) the given partition is the one where the body of D was elaborated. == Bounded (Run-Time) Errors == <span id="I6703"></span>It is a bounded error for there to be cyclic elaboration dependences between the active partitions of a single distributed program. <span id="I6704"></span>The possible effects are deadlock during elaboration, or the raising of Program_Error in one or all of the active partitions involved. == Implementation Permissions == An implementation may allow multiple active or passive partitions to be configured on a single processing node, and multiple passive partitions to be configured on a single storage node. In these cases, the scheduling policies, treatment of priorities, and management of shared resources between these partitions are implementation defined. An implementation may allow separate copies of an active partition to be configured on different processing nodes, and to provide appropriate interactions between the copies to present a consistent state of the partition to other active partitions. In an implementation, the partitions of a distributed program need not be loaded and elaborated all at the same time; they may be loaded and elaborated one at a time over an extended period of time. An implementation may provide facilities to abort and reload a partition during the execution of a distributed program. An implementation may allow the state of some of the partitions of a distributed program to persist while other partitions of the program terminate and are later reinvoked. == Notes == 3  Library units are grouped into partitions after compile time, but before run time. At compile time, only the relevant library unit properties are identified using categorization pragmas. 4  The value returned by the Partition_ID attribute can be used as a parameter to implementation-provided subprograms in order to query information about the partition. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-E|Previous]] | [[Guide:95lrm/RM-E-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} led8ysao90b4nkgpcbstl07gdp7rhey Guide:95lrm/RM-E-2 4200 1151 4423 2019-04-29T15:48:25Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-E-1|Previous]] | [[Guide:95lrm/RM-E-2-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: E.2 Categorization of Library Units}} Library units can be categorized according to the role they play in a distributed program. Certain restrictions are associated with each category to ensure that the semantics of a distributed program remain close to the semantics for a nondistributed program. <span id="I6705"></span><span id="I6706"></span><span id="I6707"></span><span id="I6708"></span><span id="I6709"></span>A ''categorization pragma'' is a library unit pragma (see [[Guide:95lrm/RM-10-1-5|10.1.5]]) that restricts the declarations, child units, or semantic dependences of the library unit to which it applies. A ''categorized library unit'' is a library unit to which a categorization pragma applies. The pragmas Shared_Passive, Remote_Types, and Remote_Call_Interface are categorization pragmas. In addition, for the purposes of this Annex, the pragma Pure (see [[Guide:95lrm/RM-10-2-1|10.2.1]]) is considered a categorization pragma. <span id="I6710"></span>A library package or generic library package is called a ''shared passive'' library unit if a Shared_Passive pragma applies to it. <span id="I6711"></span>A library package or generic library package is called a ''remote types'' library unit if a Remote_Types pragma applies to it. <span id="I6712"></span>A library unit is called a ''remote call interface'' if a Remote_Call_Interface pragma applies to it. <span id="I6713"></span>A ''normal library unit'' is one to which no categorization pragma applies. The various categories of library units and the associated restrictions are described in this clause and its subclauses. The categories are related hierarchically in that the library units of one category can depend semantically only on library units of that category or an earlier one, except that the body of a remote types or remote call interface library unit is unrestricted. The overall hierarchy (including declared pure) is as follows: ; Declared Pure : Can depend only on other declared pure library units; ; Shared Passive : Can depend only on other shared passive or declared pure library units; ; Remote Types : The declaration of the library unit can depend only on other remote types library units, or one of the above; the body of the library unit is unrestricted; ;  Remote Call Interface : The declaration of the library unit can depend only on other remote call interfaces, or one of the above; the body of the library unit is unrestricted; ;  Normal : Unrestricted. Declared pure and shared passive library units are preelaborated. The declaration of a remote types or remote call interface library unit is required to be preelaborable. == Implementation Requirements == ''This paragraph was deleted.'' == Implementation Permissions == Implementations are allowed to define other categorization pragmas. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-E-1|Previous]] | [[Guide:95lrm/RM-E-2-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} cvhxfwgjc092h0ks5rzax8igsf4jjnq Guide:95lrm/RM-E-2-1 4200 1152 4424 2019-05-01T23:12:48Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-E-2|Previous]] | [[Guide:95lrm/RM-E-2-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: E.2.1 Shared Passive Library Units}} A shared passive library unit is used for managing global data shared between active partitions. The restrictions on shared passive library units prevent the data or tasks of one active partition from being accessible to another active partition through references implicit in objects declared in the shared passive library unit. == Syntax == <span id="I6714"></span><span id="I6715"></span>The form of a pragma Shared_Passive is as follows: <p><span></span></p> '''pragma''' <span id="I6716"></span><span id="I6717"></span>Shared_Passive[(''library_unit_''<span id="I6718"></span>name)]; == Legality Rules == <span id="I6719"></span>A ''shared passive library unit'' is a library unit to which a Shared_Passive pragma applies. The following restrictions apply to such a library unit: * it shall be preelaborable (see [[Guide:95lrm/RM-10-2-1|10.2.1]]); * it shall depend semantically only upon declared pure or shared passive library units; * it shall not contain a library-level declaration of an access type that designates a class-wide type, task type, or protected type with entry_declarations. <span id="I6720"></span><span id="I6721"></span>Notwithstanding the definition of accessibility given in [[Guide:95lrm/RM-3-10-2|3.10.2]], the declaration of a library unit P1 is not accessible from within the declarative region of a shared passive library unit P2, unless the shared passive library unit P2 depends semantically on P1. == Static Semantics == <span id="I6722"></span>A shared passive library unit is preelaborated. == Post-Compilation Rules == A shared passive library unit shall be assigned to at most one partition within a given program. <span id="I6723"></span><span id="I6724"></span><span id="I6725"></span>Notwithstanding the rule given in [[Guide:95lrm/RM-10-2|10.2]], a compilation unit in a given partition does not ''need'' (in the sense of [[Guide:95lrm/RM-10-2|10.2]]) the shared passive library units on which it depends semantically to be included in that same partition; they will typically reside in separate passive partitions. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-E-2|Previous]] | [[Guide:95lrm/RM-E-2-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 116dqka532r9bov814q63gp4njyoguc Guide:95lrm/RM-E-2-2 4200 1153 4425 2019-05-01T23:13:57Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-E-2-1|Previous]] | [[Guide:95lrm/RM-E-2-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: E.2.2 Remote Types Library Units}} A remote types library unit supports the definition of types intended for use in communication between active partitions. == Syntax == <span id="I6726"></span><span id="I6727"></span>The form of a pragma Remote_Types is as follows: <p><span></span></p> '''pragma''' <span id="I6728"></span><span id="I6729"></span>Remote_Types[(''library_unit_''<span id="I6730"></span>name)]; == Legality Rules == <span id="I6731"></span>A ''remote types library unit'' is a library unit to which the pragma Remote_Types applies. The following restrictions apply to the declaration of such a library unit: * it shall be preelaborable; * it shall depend semantically only on declared pure, shared passive, or other remote types library units; * it shall not contain the declaration of any variable within the visible part of the library unit; * if the full view of a type declared in the visible part of the library unit has a part that is of a non-remote access type, then that access type, or the type of some part that includes the access type subcomponent, shall have user-specified Read and Write attributes. <span id="I6732"></span>An access type declared in the visible part of a remote types or remote call interface library unit is called a ''remote access type''. <span id="I6733"></span><span id="I6734"></span>Such a type shall be: <div> * an access-to-subprogram type, or * a general access type that designates a class-wide limited private type or a class-wide private type extension all of whose ancestors are either private type extensions or limited private types. A type that is derived from a remote access type is also a remote access type. </div> The following restrictions apply to the use of a remote access-to-subprogram type: * A value of a remote access-to-subprogram type shall be converted only to another (subtype-conformant) remote access-to-subprogram type; * The prefix of an Access attribute_reference that yields a value of a remote access-to-subprogram type shall statically denote a (subtype-conformant) remote subprogram. The following restrictions apply to the use of a remote access-to-class-wide type: * The primitive subprograms of the corresponding specific limited private type shall only have access parameters if they are controlling formal parameters; each non-controlling formal parameter shall have either a nonlimited type or a type with Read and Write attributes specified via an attribute_definition_clause; * A value of a remote access-to-class-wide type shall be explicitly converted only to another remote access-to-class-wide type; * A value of a remote access-to-class-wide type shall be dereferenced (or implicitly converted to an anonymous access type) only as part of a dispatching call where the value designates a controlling operand of the call (see [[Guide:95lrm/RM-E-4|E.4]], ''[[Guide:95lrm/RM-E-4|Remote Subprogram Calls]]''). * The Storage_Pool and Storage_Size attributes are not defined for remote access-to-class-wide types; the expected type for an allocator shall not be a remote access-to-class-wide type; a remote access-to-class-wide type shall not be an actual parameter for a generic formal access type. == Notes == 5  A remote types library unit need not be pure, and the types it defines may include levels of indirection implemented by using access types. User-specified Read and Write attributes (see [[Guide:95lrm/RM-13-13-2|13.13.2]]) provide for sending values of such a type between active partitions, with Write marshalling the representation, and Read unmarshalling any levels of indirection. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-E-2-1|Previous]] | [[Guide:95lrm/RM-E-2-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} jno90eemiiido1vstwzwqjjsxumdsbu Guide:95lrm/RM-E-2-3 4200 1154 4426 2019-05-01T23:14:43Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-E-2-2|Previous]] | [[Guide:95lrm/RM-E-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: E.2.3 Remote Call Interface Library Units}} A remote call interface library unit can be used as an interface for remote procedure calls (RPCs) (or remote function calls) between active partitions. == Syntax == <span id="I6735"></span><span id="I6736"></span>The form of a pragma Remote_Call_Interface is as follows: <p><span></span></p> '''pragma''' <span id="I6737"></span><span id="I6738"></span>Remote_Call_Interface[(''library_unit_''<span id="I6739"></span>name)]; The form of a pragma All_Calls_Remote is as follows: <p><span></span></p> '''pragma''' <span id="I6740"></span><span id="I6741"></span>All_Calls_Remote[(''library_unit_''<span id="I6742"></span>name)]; <span id="I6743"></span><span id="I6744"></span>A pragma All_Calls_Remote is a library unit pragma. == Legality Rules == <span id="I6745"></span><span id="I6746"></span><span id="I6747"></span><span id="I6748"></span><span id="I6749"></span>A ''remote call interface (RCI)'' is a library unit to which the pragma Remote_Call_Interface applies. A subprogram declared in the visible part of such a library unit, or declared by such a library unit, is called a ''remote subprogram''. The declaration of an RCI library unit shall be preelaborable (see [[Guide:95lrm/RM-10-2-1|10.2.1]]), and shall depend semantically only upon declared pure, shared passive, remote types, or other remote call interface library units. In addition, the following restrictions apply to an RCI library unit: * its visible part shall not contain the declaration of a variable; * its visible part shall not contain the declaration of a limited type; * its visible part shall not contain a nested generic_declaration; * it shall not be, nor shall its visible part contain, the declaration of a subprogram to which a pragma Inline applies; * it shall not be, nor shall its visible part contain, a subprogram (or access-to-subprogram) declaration whose profile has an access parameter, or a formal parameter of a limited type unless that limited type has user-specified Read and Write attributes; * any public child of the library unit shall be a remote call interface library unit. If a pragma All_Calls_Remote applies to a library unit, the library unit shall be a remote call interface. == Post-Compilation Rules == A remote call interface library unit shall be assigned to at most one partition of a given program. A remote call interface library unit whose parent is also an RCI library unit shall be assigned only to the same partition as its parent. <span id="I6750"></span><span id="I6751"></span><span id="I6752"></span>Notwithstanding the rule given in [[Guide:95lrm/RM-10-2|10.2]], a compilation unit in a given partition that semantically depends on the declaration of an RCI library unit, ''needs'' (in the sense of [[Guide:95lrm/RM-10-2|10.2]]) only the declaration of the RCI library unit, not the body, to be included in that same partition. Therefore, the body of an RCI library unit is included only in the partition to which the RCI library unit is explicitly assigned. == Implementation Requirements == If a pragma All_Calls_Remote applies to a given RCI library unit, then the implementation shall route any call to a subprogram of the RCI unit from outside the declarative region of the unit through the Partition Communication Subsystem (PCS); see [[Guide:95lrm/RM-E-5|E.5]]. Calls to such subprograms from within the declarative region of the unit are defined to be local and shall not go through the PCS. == Implementation Permissions == An implementation need not support the Remote_Call_Interface pragma nor the All_Calls_Remote pragma. Explicit message-based communication between active partitions can be supported as an alternative to RPC. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-E-2-2|Previous]] | [[Guide:95lrm/RM-E-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} ox5240opel7kcc5lyha1gkht7tngpmb Guide:95lrm/RM-E-3 4200 1155 4427 2019-05-01T23:15:13Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-E-2-3|Previous]] | [[Guide:95lrm/RM-E-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: E.3 Consistency of a Distributed System}} This clause defines attributes and rules associated with verifying the consistency of a distributed program. == Static Semantics == For a prefix P that statically denotes a program unit, the following attributes are defined: ; P'Version : <span id="I6753"></span><span id="I6754"></span>Yields a value of the predefined type String that identifies the version of the compilation unit that contains the declaration of the program unit. ; P'Body_Version : <span id="I6755"></span><span id="I6756"></span>Yields a value of the predefined type String that identifies the version of the compilation unit that contains the body (but not any subunits) of the program unit. <span id="I6757"></span>The ''version'' of a compilation unit changes whenever the compilation unit changes in a semantically significant way. This International Standard does not define the exact meaning of "semantically significant". It is unspecified whether there are other events (such as recompilation) that result in the version of a compilation unit changing. <span id="I6758"></span> <div> If P is not a library unit, and P has no completion, then P'Body_Version returns the Body_Version of the innermost program unit enclosing the declaration of P. If P is a library unit, and P has no completion, then P'Body_Version returns a value that is different from Body_Version of any version of P that has a completion. </div> == Bounded (Run-Time) Errors == <span id="I6759"></span><span id="I6760"></span>In a distributed program, a library unit is ''consistent'' if the same version of its declaration is used throughout. It is a bounded error to elaborate a partition of a distributed program that contains a compilation unit that depends on a different version of the declaration of a shared passive or RCI library unit than that included in the partition to which the shared passive or RCI library unit was assigned. <span id="I6761"></span>As a result of this error, Program_Error can be raised in one or both partitions during elaboration; in any case, the partitions become inaccessible to one another. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-E-2-3|Previous]] | [[Guide:95lrm/RM-E-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} a7ncozjjtclycc2qcpzjwimbsdajnrc Guide:95lrm/RM-E-4 4200 1156 4428 2019-05-01T23:15:56Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-E-3|Previous]] | [[Guide:95lrm/RM-E-4-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: E.4 Remote Subprogram Calls}} <span id="I6762"></span><span id="I6763"></span><span id="I6764"></span><span id="I6765"></span><span id="I6766"></span>A ''remote subprogram call'' is a subprogram call that invokes the execution of a subprogram in another partition. The partition that originates the remote subprogram call is the ''calling partition'', and the partition that executes the corresponding subprogram body is the ''called partition''. Some remote procedure calls are allowed to return prior to the completion of subprogram execution. These are called ''asynchronous remote procedure calls''. There are three different ways of performing a remote subprogram call: * As a direct call on a (remote) subprogram explicitly declared in a remote call interface; * As an indirect call through a value of a remote access-to-subprogram type; * As a dispatching call with a controlling operand designated by a value of a remote access-to-class-wide type. The first way of calling corresponds to a ''static'' binding between the calling and the called partition. The latter two ways correspond to a ''dynamic'' binding between the calling and the called partition. A remote call interface library unit (see [[Guide:95lrm/RM-E-2-3|E.2.3]]) defines the remote subprograms or remote access types used for remote subprogram calls. == Legality Rules == In a dispatching call with two or more controlling operands, if one controlling operand is designated by a value of a remote access-to-class-wide type, then all shall be. == Dynamic Semantics == <span id="I6767"></span><span id="I6768"></span><span id="I6769"></span>For the execution of a remote subprogram call, subprogram parameters (and later the results, if any) are passed using a stream-oriented representation (see [[Guide:95lrm/RM-13-13-1|13.13.1]]) which is suitable for transmission between partitions. This action is called ''marshalling''. ''Unmarshalling'' is the reverse action of reconstructing the parameters or results from the stream-oriented representation. Marshalling is performed initially as part of the remote subprogram call in the calling partition; unmarshalling is done in the called partition. After the remote subprogram completes, marshalling is performed in the called partition, and finally unmarshalling is done in the calling partition. <span id="I6770"></span><span id="I6771"></span>A ''calling stub'' is the sequence of code that replaces the subprogram body of a remotely called subprogram in the calling partition. A ''receiving stub'' is the sequence of code (the ''wrapper'') that receives a remote subprogram call on the called partition and invokes the appropriate subprogram body. <span id="I6772"></span>Remote subprogram calls are executed at most once, that is, if the subprogram call returns normally, then the called subprogram's body was executed exactly once. The task executing a remote subprogram call blocks until the subprogram in the called partition returns, unless the call is asynchronous. For an asynchronous remote procedure call, the calling task can become ready before the procedure in the called partition returns. <span id="I6773"></span>If a construct containing a remote call is aborted, the remote subprogram call is ''cancelled''. Whether the execution of the remote subprogram is immediately aborted as a result of the cancellation is implementation defined. If a remote subprogram call is received by a called partition before the partition has completed its elaboration, the call is kept pending until the called partition completes its elaboration (unless the call is cancelled by the calling partition prior to that). If an exception is propagated by a remotely called subprogram, and the call is not an asynchronous call, the corresponding exception is reraised at the point of the remote subprogram call. For an asynchronous call, if the remote procedure call returns prior to the completion of the remotely called subprogram, any exception is lost. The exception Communication_Error (see [[Guide:95lrm/RM-E-5|E.5]]) is raised if a remote call cannot be completed due to difficulties in communicating with the called partition. <span id="I6774"></span><span id="I6775"></span>All forms of remote subprogram calls are potentially blocking operations (see [[Guide:95lrm/RM-9-5-1|9.5.1]]). <span id="I6776"></span><span id="I6777"></span>In a remote subprogram call with a formal parameter of a class-wide type, a check is made that the tag of the actual parameter identifies a tagged type declared in a declared-pure or shared passive library unit, or in the visible part of a remote types or remote call interface library unit. <span id="I6778"></span>Program_Error is raised if this check fails. In a remote function call which returns a class-wide type, the same check is made on the function result. <span id="I6779"></span><span id="I6780"></span>In a dispatching call with two or more controlling operands that are designated by values of a remote access-to-class-wide type, a check is made (in addition to the normal Tag_Check -- see [[Guide:95lrm/RM-11-5|11.5]]) that all the remote access-to-class-wide values originated from Access attribute_references that were evaluated by tasks of the same active partition. <span id="I6781"></span>Constraint_Error is raised if this check fails. == Implementation Requirements == The implementation of remote subprogram calls shall conform to the PCS interface as defined by the specification of the language-defined package System.RPC (see [[Guide:95lrm/RM-E-5|E.5]]). The calling stub shall use the Do_RPC procedure unless the remote procedure call is asynchronous in which case Do_APC shall be used. On the receiving side, the corresponding receiving stub shall be invoked by the RPC-receiver. <div> With respect to shared variables in shared passive library units, the execution of the corresponding subprogram body of a synchronous remote procedure call is considered to be part of the execution of the calling task. The execution of the corresponding subprogram body of an asynchronous remote procedure call proceeds in parallel with the calling task and does not signal the next action of the calling task (see [[Guide:95lrm/RM-9-10|9.10]]). </div> == Notes == 6  A given active partition can both make and receive remote subprogram calls. Thus, an active partition can act as both a client and a server. 7  If a given exception is propagated by a remote subprogram call, but the exception does not exist in the calling partition, the exception can be handled by an '''others''' choice or be propagated to and handled by a third partition. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-E-3|Previous]] | [[Guide:95lrm/RM-E-4-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 76kigobe6kc9kktibj662bvmpogkzu9 Guide:95lrm/RM-E-4-1 4200 1157 4429 2019-05-01T23:16:27Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-E-4|Previous]] | [[Guide:95lrm/RM-E-4-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: E.4.1 Pragma Asynchronous}} This subclause introduces the pragma Asynchronous which allows a remote subprogram call to return prior to completion of the execution of the corresponding remote subprogram body. == Syntax == The form of a pragma Asynchronous is as follows: <p><span></span></p> '''pragma''' <span id="I6782"></span><span id="I6783"></span>Asynchronous(<span id="I6784"></span>local_name); == Legality Rules == The local_name of a pragma Asynchronous shall denote either: * One or more remote procedures; the formal parameters of the procedure(s) shall all be of mode '''in'''; * The first subtype of a remote access-to-procedure type; the formal parameters of the designated profile of the type shall all be of mode '''in'''; * The first subtype of a remote access-to-class-wide type. == Static Semantics == <span id="I6785"></span><span id="I6786"></span>A pragma Asynchronous is a representation pragma. When applied to a type, it specifies the type-related ''asynchronous'' aspect of the type. == Dynamic Semantics == <span id="I6787"></span><span id="I6788"></span>A remote call is ''asynchronous'' if it is a call to a procedure, or a call through a value of an access-to-procedure type, to which a pragma Asynchronous applies. In addition, if a pragma Asynchronous applies to a remote access-to-class-wide type, then a dispatching call on a procedure with a controlling operand designated by a value of the type is asynchronous if the formal parameters of the procedure are all of mode '''in'''. == Implementation Requirements == Asynchronous remote procedure calls shall be implemented such that the corresponding body executes at most once as a result of the call. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-E-4|Previous]] | [[Guide:95lrm/RM-E-4-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} he63sckt1e1sk7dpguxc1m1tpk6fn2n Guide:95lrm/RM-E-4-2 4200 1158 4430 2019-05-01T23:22:27Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-E-4-1|Previous]] | [[Guide:95lrm/RM-E-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: E.4.2 Example of Use of a Remote Access-to-Class-Wide Type}} == Examples == ''Example of using a remote access-to-class-wide type to achieve dynamic binding across active partitions:'' <p><syntaxhighlight lang="Ada"> package Tapes is pragma Pure(Tapes); type Tape is abstract tagged limited private; -- Primitive dispatching operations where -- Tape is controlling operand procedure Copy (From, To : access Tape; Num_Recs : in Natural) is abstract; procedure Rewind (T : access Tape) is abstract; -- More operations private type Tape is ... end Tapes;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> with Tapes; package Name_Server is pragma Remote_Call_Interface; -- Dynamic binding to remote operations is achieved -- using the access-to-limited-class-wide type Tape_Ptr type Tape_Ptr is access all Tapes.Tape'Class; -- The following statically bound remote operations -- allow for a name-server capability in this example function  Find     (Name : String) return Tape_Ptr; procedure Register (Name : in String; T : in Tape_Ptr); procedure Remove   (T : in Tape_Ptr); -- More operations end Name_Server;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> package Tape_Driver is   -- Declarations are not shown, they are irrelevant here end Tape_Driver;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> with Tapes, Name_Server; package body Tape_Driver is type New_Tape is new Tapes.Tape with ... procedure Copy  (From, To : access New_Tape; Num_Recs: in Natural) is begin   . . . end Copy; procedure Rewind (T : access New_Tape) is begin   . . . end Rewind; -- Objects remotely accessible through use -- of Name_Server operations Tape1, Tape2 : aliased New_Tape; begin Name_Server.Register ("NINE-TRACK",  Tape1'Access); Name_Server.Register ("SEVEN-TRACK", Tape2'Access); end Tape_Driver;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> with Tapes, Name_Server; -- Tape_Driver is not needed and thus not mentioned in the with_clause procedure Tape_Client is T1, T2 : Name_Server.Tape_Ptr; begin T1 := Name_Server.Find ("NINE-TRACK"); T2 := Name_Server.Find ("SEVEN-TRACK"); Tapes.Rewind (T1); Tapes.Rewind (T2); Tapes.Copy (T1, T2, 3); end Tape_Client;</syntaxhighlight></p> ''Notes on the example'': ''This paragraph was deleted.'' * The package Tapes provides the necessary declarations of the type and its primitive operations. * Name_Server is a remote call interface package and is elaborated in a separate active partition to provide the necessary naming services (such as Register and Find) to the entire distributed program through remote subprogram calls. * Tape_Driver is a normal package that is elaborated in a partition configured on the processing node that is connected to the tape device(s). The abstract operations are overridden to support the locally declared tape devices (Tape1, Tape2). The package is not visible to its clients, but it exports the tape devices (as remote objects) through the services of the Name_Server. This allows for tape devices to be dynamically added, removed or replaced without requiring the modification of the clients' code. * The Tape_Client procedure references only declarations in the Tapes and Name_Server packages. Before using a tape for the first time, it needs to query the Name_Server for a system-wide identity for that tape. From then on, it can use that identity to access the tape device. * Values of remote access type Tape_Ptr include the necessary information to complete the remote dispatching operations that result from dereferencing the controlling operands T1 and T2. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-E-4-1|Previous]] | [[Guide:95lrm/RM-E-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} ekogcz3ck4b0tv4wj9x2t3fu3tp33s5 Guide:95lrm/RM-E-5 4200 1159 4431 2019-05-01T23:26:37Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-E-4-2|Previous]] | [[Guide:95lrm/RM-F|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: E.5 Partition Communication Subsystem}} <span id="I6789"></span><span id="I6790"></span>The ''Partition Communication Subsystem'' (PCS) provides facilities for supporting communication between the active partitions of a distributed program. The package System.RPC is a language-defined interface to the PCS. An implementation conforming to this Annex shall use the RPC interface to implement remote subprogram calls. == Static Semantics == The following language-defined library package exists: <p><syntaxhighlight lang="Ada"> with Ada.Streams; -- see 13.13.1 package System.RPC is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Partition_ID is range 0 .. implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Communication_Error : exception;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Params_Stream_Type (    Initial_Size : Ada.Streams.Stream_Element_Count) is new    Ada.Streams.Root_Stream_Type with private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Read(    Stream : in out Params_Stream_Type;    Item : out Ada.Streams.Stream_Element_Array;    Last : out Ada.Streams.Stream_Element_Offset);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   procedure Write(    Stream : in out Params_Stream_Type;    Item : in Ada.Streams.Stream_Element_Array);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     -- Synchronous call procedure Do_RPC(    Partition  : in Partition_ID;    Params     : access Params_Stream_Type;    Result     : access Params_Stream_Type);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- Asynchronous call procedure Do_APC(    Partition  : in Partition_ID;    Params     : access Params_Stream_Type);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    -- The handler for incoming RPCs type RPC_Receiver is access procedure(    Params     : access Params_Stream_Type;    Result     : access Params_Stream_Type);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   procedure Establish_RPC_Receiver(    Partition : in Partition_ID;    Receiver  : in RPC_Receiver);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> private ... -- not specified by the language end System.RPC;</syntaxhighlight></p> A value of the type Partition_ID is used to identify a partition. An object of the type Params_Stream_Type is used for identifying the particular remote subprogram that is being called, as well as marshalling and unmarshalling the parameters or result of a remote subprogram call, as part of sending them between partitions. The Read and Write procedures override the corresponding abstract operations for the type Params_Stream_Type. == Dynamic Semantics == The Do_RPC and Do_APC procedures send a message to the active partition identified by the Partition parameter. After sending the message, Do_RPC blocks the calling task until a reply message comes back from the called partition or some error is detected by the underlying communication system in which case Communication_Error is raised at the point of the call to Do_RPC. Do_APC operates in the same way as Do_RPC except that it is allowed to return immediately after sending the message. Upon normal return, the stream designated by the Result parameter of Do_RPC contains the reply message. <span id="I6811"></span>The procedure System.RPC.Establish_RPC_Receiver is called once, immediately after elaborating the library units of an active partition (that is, right after the ''elaboration of the partition'') if the partition includes an RCI library unit, but prior to invoking the main subprogram, if any. The Partition parameter is the Partition_ID of the active partition being elaborated. <span id="I6812"></span>The Receiver parameter designates an implementation-provided procedure called the ''RPC-receiver'' which will handle all RPCs received by the partition from the PCS. Establish_RPC_Receiver saves a reference to the RPC-receiver; when a message is received at the called partition, the RPC-receiver is called with the Params stream containing the message. When the RPC-receiver returns, the contents of the stream designated by Result is placed in a message and sent back to the calling partition. If a call on Do_RPC is aborted, a cancellation message is sent to the called partition, to request that the execution of the remotely called subprogram be aborted. <span id="I6813"></span><span id="I6814"></span>The subprograms declared in System.RPC are potentially blocking operations. == Implementation Requirements == The implementation of the RPC-receiver shall be reentrant, thereby allowing concurrent calls on it from the PCS to service concurrent remote subprogram calls into the partition. <div> An implementation shall not restrict the replacement of the body of System.RPC. An implementation shall not restrict children of System.RPC. The related implementation permissions in the introduction to Annex A do not apply. If the implementation of System.RPC is provided by the user, an implementation shall support remote subprogram calls as specified. </div> == Documentation Requirements == The implementation of the PCS shall document whether the RPC-receiver is invoked from concurrent tasks. If there is an upper limit on the number of such tasks, this limit shall be documented as well, together with the mechanisms to configure it (if this is supported). == Implementation Permissions == The PCS is allowed to contain implementation-defined interfaces for explicit message passing, broadcasting, etc. Similarly, it is allowed to provide additional interfaces to query the state of some remote partition (given its partition ID) or of the PCS itself, to set timeouts and retry parameters, to get more detailed error status, etc. These additional interfaces should be provided in child packages of System.RPC. A body for the package System.RPC need not be supplied by the implementation. == Implementation Advice == Whenever possible, the PCS on the called partition should allow for multiple tasks to call the RPC-receiver with different messages and should allow them to block until the corresponding subprogram body returns. The Write operation on a stream of type Params_Stream_Type should raise Storage_Error if it runs out of space trying to write the Item into the stream. == Notes == 8  The package System.RPC is not designed for direct calls by user programs. It is instead designed for use in the implementation of remote subprograms calls, being called by the calling stubs generated for a remote call interface library unit to initiate a remote call, and in turn calling back to an RPC-receiver that dispatches to the receiving stubs generated for the body of a remote call interface, to handle a remote call received from elsewhere. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-E-4-2|Previous]] | [[Guide:95lrm/RM-F|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} he3ejuk5jef4bswazi5tgm8uvekud01 Guide:95lrm/RM-F 4200 1160 4432 2019-05-01T23:27:13Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-E-5|Previous]] | [[Guide:95lrm/RM-F-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Annex F. Information Systems}} <div>(normative) </div> <span id="I6815"></span>This Annex provides a set of facilities relevant to Information Systems programming. These fall into several categories: * an attribute definition clause specifying Machine_Radix for a decimal subtype; * the package Decimal, which declares a set of constants defining the implementation's capacity for decimal types, and a generic procedure for decimal division; and * the child packages Text_IO.Editing and Wide_Text_IO.Editing, which support formatted and localized output of decimal data, based on ''picture String'' values. See also: [[Guide:95lrm/RM-3-5-9|3.5.9]], ''[[Guide:95lrm/RM-3-5-9|Fixed Point Types]]''; [[Guide:95lrm/RM-3-5-10|3.5.10]], ''[[Guide:95lrm/RM-3-5-10|Operations of Fixed Point Types]]''; [[Guide:95lrm/RM-4-6|4.6]], ''[[Guide:95lrm/RM-4-6|Type Conversions]]''; [[Guide:95lrm/RM-13-3|13.3]], ''[[Guide:95lrm/RM-13-3|Operational and Representation Attributes]]''; [[Guide:95lrm/RM-A-10-9|A.10.9]], ''[[Guide:95lrm/RM-A-10-9|Input-Output for Real Types]]''; [[Guide:95lrm/RM-B-4|B.4]], ''[[Guide:95lrm/RM-B-4|Interfacing with COBOL]]''; [[Guide:95lrm/RM-B-3|B.3]], ''[[Guide:95lrm/RM-B-3|Interfacing with C]]''; [[Guide:95lrm/RM-G|Annex G]], ''[[Guide:95lrm/RM-G|Numerics]]''. The character and string handling packages in [[Guide:95lrm/RM-A|Annex A]], ''[[Guide:95lrm/RM-A|Predefined Language Environment]]'' are also relevant for Information Systems. == Implementation Advice == If COBOL (respectively, C) is widely supported in the target environment, implementations supporting the Information Systems Annex should provide the child package Interfaces.COBOL (respectively, Interfaces.C) specified in [[Guide:95lrm/RM-B|Annex B]] and should support a ''convention_''identifier of COBOL (respectively, C) in the interfacing pragmas (see [[Guide:95lrm/RM-B|Annex B]]), thus allowing Ada programs to interface with programs written in that language. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-E-5|Previous]] | [[Guide:95lrm/RM-F-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} dsu15l1bntt1hbb4qh3yxsi783nsme4 Guide:95lrm/RM-F-1 4200 1161 4433 2019-05-01T23:27:33Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-F|Previous]] | [[Guide:95lrm/RM-F-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: F.1 Machine_Radix Attribute Definition Clause}} == Static Semantics == <span id="I6816"></span><span id="I6817"></span>Machine_Radix may be specified for a decimal first subtype (see [[Guide:95lrm/RM-3-5-9|3.5.9]]) via an attribute_definition_clause; the expression of such a clause shall be static, and its value shall be 2 or 10. A value of 2 implies a binary base range; a value of 10 implies a decimal base range. == Implementation Advice == Packed decimal should be used as the internal representation for objects of subtype S when S'Machine_Radix = 10. == Examples == ''Example of Machine_Radix attribute definition clause:'' <p><syntaxhighlight lang="Ada"> type Money is delta 0.01 digits 15; for Money'Machine_Radix use 10;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-F|Previous]] | [[Guide:95lrm/RM-F-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} ha4mmutcp5g6vk7iqu99hdypmqy3678 Guide:95lrm/RM-F-2 4200 1162 4434 2019-05-01T23:29:14Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-F-1|Previous]] | [[Guide:95lrm/RM-F-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: F.2 The Package Decimal}} == Static Semantics == The library package Decimal has the following declaration: <p><syntaxhighlight lang="Ada"> package Ada.Decimal is pragma Pure(Decimal);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Max_Scale : constant := implementation-defined; Min_Scale : constant := implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   Min_Delta : constant := 10.0**(-Max_Scale); Max_Delta : constant := 10.0**(-Min_Scale);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Max_Decimal_Digits : constant := implementation-defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    generic    type Dividend_Type  is delta <> digits <>;    type Divisor_Type   is delta <> digits <>;    type Quotient_Type  is delta <> digits <>;    type Remainder_Type is delta <> digits <>; procedure Divide (Dividend  : in Dividend_Type;                   Divisor   : in Divisor_Type;                   Quotient  : out Quotient_Type;                   Remainder : out Remainder_Type); pragma Convention(Intrinsic, Divide);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> end Ada.Decimal;</syntaxhighlight></p> Max_Scale is the largest N such that 10.0**(-N) is allowed as a decimal type's delta. Its type is ''universal_integer''. Min_Scale is the smallest N such that 10.0**(-N) is allowed as a decimal type's delta. Its type is ''universal_integer''. Min_Delta is the smallest value allowed for ''delta'' in a decimal_fixed_point_definition. Its type is ''universal_real''. Max_Delta is the largest value allowed for ''delta'' in a decimal_fixed_point_definition. Its type is ''universal_real''. Max_Decimal_Digits is the largest value allowed for ''digits'' in a decimal_fixed_point_definition. Its type is ''universal_integer''. == Static Semantics == The effect of Divide is as follows. The value of Quotient is Quotient_Type(Dividend/Divisor). The value of Remainder is Remainder_Type(Intermediate), where Intermediate is the difference between Dividend and the product of Divisor and Quotient; this result is computed exactly. == Implementation Requirements == Decimal.Max_Decimal_Digits shall be at least 18. Decimal.Max_Scale shall be at least 18. Decimal.Min_Scale shall be at most 0. == Notes == 1  The effect of division yielding a quotient with control over rounding versus truncation is obtained by applying either the function attribute Quotient_Type'Round or the conversion Quotient_Type to the expression Dividend/Divisor. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-F-1|Previous]] | [[Guide:95lrm/RM-F-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} l22utz3k87fgend2gykuhgbyhkenj12 Guide:95lrm/RM-F-3 4200 1163 4435 2019-04-29T23:33:45Z imported>WikiVisor 0 Text replacement - "&quot;" to """ wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-F-2|Previous]] | [[Guide:95lrm/RM-F-3-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: F.3 Edited Output for Decimal Types}} The child packages Text_IO.Editing and Wide_Text_IO.Editing provide localizable formatted text output, known as ''edited output'' <span id="I6828"></span>, for decimal types. An edited output string is a function of a numeric value, program-specifiable locale elements, and a format control value. The numeric value is of some decimal type. The locale elements are: * the currency string; * the digits group separator character; * the radix mark character; and * the fill character that replaces leading zeros of the numeric value. For Text_IO.Editing the edited output and currency strings are of type String, and the locale characters are of type Character. For Wide_Text_IO.Editing their types are Wide_String and Wide_Character, respectively. Each of the locale elements has a default value that can be replaced or explicitly overridden. A format-control value is of the private type Picture; it determines the composition of the edited output string and controls the form and placement of the sign, the position of the locale elements and the decimal digits, the presence or absence of a radix mark, suppression of leading zeros, and insertion of particular character values. A Picture object is composed from a String value, known as a ''picture String'', that serves as a template for the edited output string, and a Boolean value that controls whether a string of all space characters is produced when the number's value is zero. A picture String comprises a sequence of one- or two-Character symbols, each serving as a placeholder for a character or string at a corresponding position in the edited output string. The picture String symbols fall into several categories based on their effect on the edited output string: <p><syntaxhighlight lang="Ada"> Decimal Digit:  '9' Radix Control:  '.'  'V' Sign Control:  '+'  '-'  '<'  '>'  "CR"  "DB" Currency Control:  '$'  '#' Zero Suppression:  'Z'  '*' Simple Insertion:  '_'  'B'  '0'  '/'</syntaxhighlight></p> The entries are not case-sensitive. Mixed- or lower-case forms for "CR" and "DB", and lower-case forms for 'V', 'Z', and 'B', have the same effect as the upper-case symbols shown. An occurrence of a '9' Character in the picture String represents a decimal digit position in the edited output string. A radix control Character in the picture String indicates the position of the radix mark in the edited output string: an actual character position for '.', or an assumed position for 'V'. A sign control Character in the picture String affects the form of the sign in the edited output string. The '<' and '>' Character values indicate parentheses for negative values. A Character '+', '-', or '<' appears either singly, signifying a fixed-position sign in the edited output, or repeated, signifying a floating-position sign that is preceded by zero or more space characters and that replaces a leading 0. A currency control Character in the picture String indicates an occurrence of the currency string in the edited output string. The '$' Character represents the complete currency string; the '#' Character represents one character of the currency string. A '$' Character appears either singly, indicating a fixed-position currency string in the edited output, or repeated, indicating a floating-position currency string that occurs in place of a leading 0. A sequence of '#' Character values indicates either a fixed- or floating-position currency string, depending on context. A zero suppression Character in the picture String allows a leading zero to be replaced by either the space character (for 'Z') or the fill character (for '*'). A simple insertion Character in the picture String represents, in general, either itself (if '/' or '0'), the space character (if 'B'), or the digits group separator character (if '_'). In some contexts it is treated as part of a floating sign, floating currency, or zero suppression string. An example of a picture String is "<###Z_ZZ9.99>". If the currency string is "FF", the separator character is ',', and the radix mark is '.' then the edited output string values for the decimal values 32.10 and -5432.10 are "bbFFbbb32.10b" and "(bFF5,432.10)", respectively, where 'b' indicates the space character. The generic packages Text_IO.Decimal_IO and Wide_Text_IO.Decimal_IO (see [[Guide:95lrm/RM-A-10-9|A.10.9]], ''[[Guide:95lrm/RM-A-10-9|Input-Output for Real Types]]'') provide text input and non-edited text output for decimal types. == Notes == 2  A picture String is of type Standard.String, both for Text_IO.Editing and Wide_Text_IO.Editing. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-F-2|Previous]] | [[Guide:95lrm/RM-F-3-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} brwk3v45xyec4kvi0hkqbedofto0dx7 Guide:95lrm/RM-F-3-1 4200 1164 4436 2019-05-01T23:54:11Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-F-3|Previous]] | [[Guide:95lrm/RM-F-3-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: F.3.1 Picture String Formation}} <span id="I6829"></span><span id="I6830"></span>A ''well-formed picture String'', or simply ''picture String'', is a String value that conforms to the syntactic rules, composition constraints, and character replication conventions specified in this clause. == Dynamic Semantics == ''This paragraph was deleted.'' <p><syntaxhighlight lang="Ada"> picture_string ::= fixed_$_picture_string | fixed_#_picture_string | floating_currency_picture_string | non_currency_picture_string</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> fixed_$_picture_string ::= [fixed_LHS_sign] fixed_$_char {direct_insertion} [zero_suppression] number [RHS_sign] | [fixed_LHS_sign {direct_insertion}] [zero_suppression] number fixed_$_char {direct_insertion} [RHS_sign] | floating_LHS_sign number fixed_$_char {direct_insertion} [RHS_sign] | [fixed_LHS_sign] fixed_$_char {direct_insertion} all_zero_suppression_number {direct_insertion}  [RHS_sign] | [fixed_LHS_sign {direct_insertion}] all_zero_suppression_number {direct_insertion} fixed_$_char {direct_insertion} [RHS_sign] | all_sign_number {direct_insertion} fixed_$_char {direct_insertion} [RHS_sign]</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> fixed_#_picture_string ::= [fixed_LHS_sign] single_#_currency {direct_insertion} [zero_suppression] number [RHS_sign] | [fixed_LHS_sign] multiple_#_currency {direct_insertion} zero_suppression number [RHS_sign] | [fixed_LHS_sign {direct_insertion}] [zero_suppression] number fixed_#_currency {direct_insertion} [RHS_sign] | floating_LHS_sign number fixed_#_currency {direct_insertion} [RHS_sign] | [fixed_LHS_sign] single_#_currency {direct_insertion} all_zero_suppression_number {direct_insertion} [RHS_sign] | [fixed_LHS_sign] multiple_#_currency {direct_insertion} all_zero_suppression_number {direct_insertion} [RHS_sign] | [fixed_LHS_sign {direct_insertion}] all_zero_suppression_number {direct_insertion} fixed_#_currency {direct_insertion} [RHS_sign] | all_sign_number {direct_insertion} fixed_#_currency {direct_insertion} [RHS_sign]</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> floating_currency_picture_string ::= [fixed_LHS_sign] {direct_insertion} floating_$_currency number [RHS_sign] | [fixed_LHS_sign] {direct_insertion} floating_#_currency number [RHS_sign] | [fixed_LHS_sign] {direct_insertion} all_currency_number {direct_insertion} [RHS_sign]</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> non_currency_picture_string ::= [fixed_LHS_sign {direct_insertion}] zero_suppression number [RHS_sign] | [floating_LHS_sign] number [RHS_sign] | [fixed_LHS_sign {direct_insertion}] all_zero_suppression_number {direct_insertion} [RHS_sign] | all_sign_number {direct_insertion} | fixed_LHS_sign direct_insertion {direct_insertion} number [RHS_sign]</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> fixed_LHS_sign ::=  LHS_Sign</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> LHS_Sign ::=  + | - | <</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> fixed_$_char ::= $</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> direct_insertion ::=  simple_insertion</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> simple_insertion ::=  _ | B | 0 | /</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> zero_suppression ::=  Z {Z | context_sensitive_insertion} | fill_string</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> context_sensitive_insertion ::=  simple_insertion</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> fill_string ::=  * {* | context_sensitive_insertion}</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> number ::= fore_digits [radix [aft_digits] {direct_insertion}] | radix aft_digits {direct_insertion}</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> fore_digits ::= 9 {9 | direct_insertion}</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> aft_digits ::=  {9 | direct_insertion} 9</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> radix ::= . | V</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> RHS_sign ::= + | - | > | CR | DB</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> floating_LHS_sign ::= LHS_Sign {context_sensitive_insertion} LHS_Sign {LHS_Sign | context_sensitive_insertion} </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> single_#_currency ::= #</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> multiple_#_currency ::= ## {#}</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> fixed_#_currency ::= single_#_currency | multiple_#_currency</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> floating_$_currency ::= $ {context_sensitive_insertion} $ {$ | context_sensitive_insertion}</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> floating_#_currency ::= # {context_sensitive_insertion} # {# | context_sensitive_insertion}</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> all_sign_number ::=  all_sign_fore [radix [all_sign_aft]] [>] </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> all_sign_fore ::= sign_char {context_sensitive_insertion} sign_char {sign_char | context_sensitive_insertion} </syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> all_sign_aft ::= {all_sign_aft_char} sign_char all_sign_aft_char ::=  sign_char | context_sensitive_insertion</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> sign_char ::= + | - | <</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> all_currency_number ::=  all_currency_fore [radix [all_currency_aft]]</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> all_currency_fore ::= currency_char {context_sensitive_insertion} currency_char {currency_char | context_sensitive_insertion}</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> all_currency_aft ::= {all_currency_aft_char} currency_char all_currency_aft_char ::= currency_char | context_sensitive_insertion</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> currency_char ::= $ | #</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> all_zero_suppression_number ::=  all_zero_suppression_fore [ radix [all_zero_suppression_aft]]</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> all_zero_suppression_fore ::= zero_suppression_char {zero_suppression_char | context_sensitive_insertion}</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> all_zero_suppression_aft ::= {all_zero_suppression_aft_char} zero_suppression_char all_zero_suppression_aft_char ::=  zero_suppression_char | context_sensitive_insertion</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> zero_suppression_char ::= Z | *</syntaxhighlight></p> The following composition constraints apply to a picture String: * A floating_LHS_sign does not have occurrences of different LHS_Sign Character values. * If a picture String has '<' as fixed_LHS_sign, then it has '>' as RHS_sign. * If a picture String has '<' in a floating_LHS_sign or in an all_sign_number, then it has an occurrence of '>'. * If a picture String has '+' or '-' as fixed_LHS_sign, in a floating_LHS_sign, or in an all_sign_number, then it has no RHS_sign or '>' character. * An instance of all_sign_number does not have occurrences of different sign_char Character values. * An instance of all_currency_number does not have occurrences of different currency_char Character values. * An instance of all_zero_suppression_number does not have occurrences of different zero_suppression_char Character values, except for possible case differences between 'Z' and 'z'. A ''replicable Character'' is a Character that, by the above rules, can occur in two consecutive positions in a picture String. A ''Character replication'' is a String <p><syntaxhighlight lang="Ada"> char & '(' & spaces & count_string & ')'</syntaxhighlight></p> where ''char'' is a replicable Character, ''spaces'' is a String (possibly empty) comprising only space Character values, and ''count_string'' is a String of one or more decimal digit Character values. A Character replication in a picture String has the same effect as (and is said to be ''equivalent to'') a String comprising ''n'' consecutive occurrences of ''char'', where ''n''=Integer'Value(''count_string''). An ''expanded picture String'' is a picture String containing no Character replications. == Notes == 3  Although a sign to the left of the number can float, a sign to the right of the number is in a fixed position. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-F-3|Previous]] | [[Guide:95lrm/RM-F-3-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} j4jz9iey3qvyczjbie0w8h71tbmy86u Guide:95lrm/RM-F-3-2 4200 1165 4437 2019-05-01T23:57:58Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-F-3-1|Previous]] | [[Guide:95lrm/RM-F-3-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: F.3.2 Edited Output Generation}} == Dynamic Semantics == The contents of an edited output string are based on: * A value, Item, of some decimal type Num, * An expanded picture String Pic_String, * A Boolean value, Blank_When_Zero, * A Currency string, * A Fill character, * A Separator character, and * A Radix_Mark character. The combination of a True value for Blank_When_Zero and a '*' character in Pic_String is inconsistent; no edited output string is defined. A layout error is identified in the rules below if leading non-zero digits of Item, character values of the Currency string, or a negative sign would be truncated; in such cases no edited output string is defined. The edited output string has lower bound 1 and upper bound N where N = Pic_String'Length + Currency_Length_Adjustment - Radix_Adjustment, and * Currency_Length_Adjustment = Currency'Length - 1 if there is some occurrence of '$' in Pic_String, and 0 otherwise. * Radix_Adjustment = 1 if there is an occurrence of 'V' or 'v' in Pic_Str, and 0 otherwise. <span id="I6831"></span>Let the magnitude of Item be expressed as a base-10 number I<sub>p</sub>···I<sub>1</sub>.F<sub>1</sub>···F<sub>q</sub>, called the ''displayed'' ''magnitude'' of Item, where: * q = Min(Max(Num'Scale, 0), n) where n is 0 if Pic_String has no radix and is otherwise the number of digit positions following radix in Pic_String, where a digit position corresponds to an occurrence of '9', a zero_suppression_char (for an all_zero_suppression_number), a currency_char (for an all_currency_number), or a sign_char (for an all_sign_number). * I<sub>p</sub> /= 0 if p>0. If n < Num'Scale, then the above number is the result of rounding (away from 0 if exactly midway between values). If Blank_When_Zero = True and the displayed magnitude of Item is zero, then the edited output string comprises all space character values. Otherwise, the picture String is treated as a sequence of instances of syntactic categories based on the rules in [[Guide:95lrm/RM-F-3-1|F.3.1]], and the edited output string is the concatenation of string values derived from these categories according to the following mapping rules. Table F-1 shows the mapping from a sign control symbol to a corresponding character or string in the edited output. In the columns showing the edited output, a lower-case 'b' represents the space character. If there is no sign control symbol but the value of Item is negative, a layout error occurs and no edited output string is produced. <div> {| class="wikitable" |+ '''Table F-1: Edited Output for Sign Control Symbols''' ! '''Sign Control Symbol''' ! '''Edited Output for Non-Negative Number''' ! '''Edited Output for Negative Number''' |- | '+' | '+' | '-' |- | '-' | 'b' | '-' |- | '<' | 'b' | '(' |- | '>' | 'b' | ')' |- | "CR" | "bb" | "CR" |- | "DB" | "bb" | "DB" |} </div> An instance of fixed_LHS_sign maps to a character as shown in Table F-1. An instance of fixed_$_char maps to Currency. An instance of direct_insertion maps to Separator if direct_insertion = '_', and to the direct_insertion Character otherwise. An instance of number maps to a string ''integer_part'' & ''radix_part'' & ''fraction_part'' where: * The string for ''integer_part'' is obtained as follows: ; 1. : Occurrences of '9' in fore_digits of number are replaced from right to left with the decimal digit character values for I<sub>1</sub>, ..., I<sub>p</sub>, respectively. ; 2. : Each occurrence of '9' in fore_digits to the left of the leftmost '9' replaced according to rule 1 is replaced with '0'. ; 3. : If p exceeds the number of occurrences of '9' in fore_digits of number, then the excess leftmost digits are eligible for use in the mapping of an instance of zero_suppression, floating_LHS_sign, floating_$_currency, or floating_#_currency to the left of number; if there is no such instance, then a layout error occurs and no edited output string is produced. * The ''radix_part'' is: * "" if number does not include a radix, if radix = 'V', or if radix = 'v' * Radix_Mark if number includes '.' as radix * The string for ''fraction_part'' is obtained as follows: ; 1. : Occurrences of '9' in aft_digits of number are replaced from left to right with the decimal digit character values for F<sub>1</sub>, ... F<sub>q</sub>. ; 2. : Each occurrence of '9' in aft_digits to the right of the rightmost '9' replaced according to rule 1 is replaced by '0'. An instance of zero_suppression maps to the string obtained as follows: ;  1. : The rightmost 'Z', 'z', or '*' Character values are replaced with the excess digits (if any) from the ''integer_part'' of the mapping of the number to the right of the zero_suppression instance, ;  2. : A context_sensitive_insertion Character is replaced as though it were a direct_insertion Character, if it occurs to the right of some 'Z', 'z', or '*' in zero_suppression that has been mapped to an excess digit, ;  3. : Each Character to the left of the leftmost Character replaced according to rule 1 above is replaced by: * the space character if the zero suppression Character is 'Z' or 'z', or * the Fill character if the zero suppression Character is '*'. ;  4. : A layout error occurs if some excess digits remain after all 'Z', 'z', and '*' Character values in zero_suppression have been replaced via rule 1; no edited output string is produced. An instance of RHS_sign maps to a character or string as shown in Table F-1. An instance of floating_LHS_sign maps to the string obtained as follows. ;  1. : Up to all but one of the rightmost LHS_Sign Character values are replaced by the excess digits (if any) from the ''integer_part'' of the mapping of the number to the right of the floating_LHS_sign instance. ;  2. : The next Character to the left is replaced with the character given by the entry in Table F-1 corresponding to the LHS_Sign Character. ;  3. : A context_sensitive_insertion Character is replaced as though it were a direct_insertion Character, if it occurs to the right of the leftmost LHS_Sign character replaced according to rule 1. ;  4. : Any other Character is replaced by the space character.. ;  5. : A layout error occurs if some excess digits remain after replacement via rule 1; no edited output string is produced. An instance of fixed_#_currency maps to the Currency string with n space character values concatenated on the left (if the instance does not follow a radix) or on the right (if the instance does follow a radix), where n is the difference between the length of the fixed_#_currency instance and Currency'Length. A layout error occurs if Currency'Length exceeds the length of the fixed_#_currency instance; no edited output string is produced. An instance of floating_$_currency maps to the string obtained as follows: ;  1. : Up to all but one of the rightmost '$' Character values are replaced with the excess digits (if any) from the ''integer_part'' of the mapping of the number to the right of the floating_$_currency instance. ;  2. : The next Character to the left is replaced by the Currency string. ;  3. : A context_sensitive_insertion Character is replaced as though it were a direct_insertion Character, if it occurs to the right of the leftmost '$' Character replaced via rule 1. ;  4. : Each other Character is replaced by the space character. ;  5. : A layout error occurs if some excess digits remain after replacement by rule 1; no edited output string is produced. An instance of floating_#_currency maps to the string obtained as follows: ;  1. : Up to all but one of the rightmost '#' Character values are replaced with the excess digits (if any) from the ''integer_part'' of the mapping of the number to the right of the floating_#_currency instance. ;  2. : The substring whose last Character occurs at the position immediately preceding the leftmost Character replaced via rule 1, and whose length is Currency'Length, is replaced by the Currency string. ;  3. : A context_sensitive_insertion Character is replaced as though it were a direct_insertion Character, if it occurs to the right of the leftmost '#' replaced via rule 1. ;  4. : Any other Character is replaced by the space character. ;  5. : A layout error occurs if some excess digits remain after replacement rule 1, or if there is no substring with the required length for replacement rule 2; no edited output string is produced. An instance of all_zero_suppression_number maps to: * a string of all spaces if the displayed magnitude of Item is zero, the zero_suppression_char is 'Z' or 'z', and the instance of all_zero_suppression_number does not have a radix at its last character position; * a string containing the Fill character in each position except for the character (if any) corresponding to radix, if zero_suppression_char = '*' and the displayed magnitude of Item is zero; * otherwise, the same result as if each zero_suppression_char in all_zero_suppression_aft were '9', interpreting the instance of all_zero_suppression_number as either zero_suppression number (if a radix and all_zero_suppression_aft are present), or as zero_suppression otherwise. An instance of all_sign_number maps to: * a string of all spaces if the displayed magnitude of Item is zero and the instance of all_sign_number does not have a radix at its last character position; * otherwise, the same result as if each sign_char in all_sign_number_aft were '9', interpreting the instance of all_sign_number as either floating_LHS_sign number (if a radix and all_sign_number_aft are present), or as floating_LHS_sign otherwise. An instance of all_currency_number maps to: * a string of all spaces if the displayed magnitude of Item is zero and the instance of all_currency_number does not have a radix at its last character position; * otherwise, the same result as if each currency_char in all_currency_number_aft were '9', interpreting the instance of all_currency_number as floating_$_currency number or floating_#_currency number (if a radix and all_currency_number_aft are present), or as floating_$_currency or floating_#_currency otherwise. == Examples == In the result string values shown below, 'b' represents the space character. <p><syntaxhighlight lang="Ada"> Item:         Picture and Result Strings:</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> 123456.78     Picture:  "-###**_***_**9.99"                      "bbb$***123,456.78"                      "bbFF***123.456,78" (currency = "FF",                                           separator = '.',                                           radix mark = ',')</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> 123456.78     Picture:  "-$**_***_**9.99"            Result:   "b$***123,456.78"                     "bFF***123.456,78" (currency = "FF",                                         separator = '.',                                         radix mark = ',')</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> 0.0           Picture: "-$$$$$$.$$"           Result:  "bbbbbbbbbb"</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> 0.20          Picture: "-$$$$$$.$$"           Result:  "bbbbbb$.20"</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> -1234.565     Picture: "<<<<_<<<.<<###>"           Result:  "bb(1,234.57DMb)"  (currency = "DM")</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> 12345.67      Picture: "###_###_##9.99"           Result:  "bbCHF12,345.67"   (currency = "CHF")</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-F-3-1|Previous]] | [[Guide:95lrm/RM-F-3-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} aclklc19x8bbrb9w0h1lwkpjprw3djp Guide:95lrm/RM-F-3-3 4200 1166 4438 2019-05-02T08:45:14Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-F-3-2|Previous]] | [[Guide:95lrm/RM-F-3-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: F.3.3 The Package Text_IO.Editing}} The package Text_IO.Editing provides a private type Picture with associated operations, and a generic package Decimal_Output. An object of type Picture is composed from a well-formed picture String (see [[Guide:95lrm/RM-F-3-1|F.3.1]]) and a Boolean item indicating whether a zero numeric value will result in an edited output string of all space characters. The package Decimal_Output contains edited output subprograms implementing the effects defined in [[Guide:95lrm/RM-F-3-2|F.3.2]]. == Static Semantics == The library package Text_IO.Editing has the following declaration: <p><syntaxhighlight lang="Ada"> package Ada.Text_IO.Editing is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Picture is private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Valid (Pic_String      : in String;                 Blank_When_Zero : in Boolean := False)  return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function To_Picture (Pic_String      : in String;                      Blank_When_Zero : in Boolean := False)    return Picture;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">     function Pic_String      (Pic : in Picture) return String; function Blank_When_Zero (Pic : in Picture) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Max_Picture_Length  : constant := implementation_defined;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Picture_Error       : exception;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Default_Currency    : constant String    := "$"; Default_Fill        : constant Character := '*'; Default_Separator   : constant Character := ','; Default_Radix_Mark  : constant Character := '.';</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    generic    type Num is delta <> digits <>;    Default_Currency   : in String    := Text_IO.Editing.Default_Currency;    Default_Fill       : in Character := Text_IO.Editing.Default_Fill;    Default_Separator  : in Character :=                            Text_IO.Editing.Default_Separator;    Default_Radix_Mark : in Character :=                            Text_IO.Editing.Default_Radix_Mark; package Decimal_Output is    function Length (Pic      : in Picture;                     Currency : in String := Default_Currency)       return Natural;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Valid (Item     : in Num;                    Pic      : in Picture;                    Currency : in String := Default_Currency)       return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       function Image (Item       : in Num;                    Pic        : in Picture;                    Currency   : in String    := Default_Currency;                    Fill       : in Character := Default_Fill;                    Separator  : in Character := Default_Separator;                    Radix_Mark : in Character := Default_Radix_Mark)       return String;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Put (File       : in File_Type;                   Item       : in Num;                   Pic        : in Picture;                   Currency   : in String    := Default_Currency;                   Fill       : in Character := Default_Fill;                   Separator  : in Character := Default_Separator;                   Radix_Mark : in Character := Default_Radix_Mark);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Put (Item       : in Num;                   Pic        : in Picture;                   Currency   : in String    := Default_Currency;                   Fill       : in Character := Default_Fill;                   Separator  : in Character := Default_Separator;                   Radix_Mark : in Character := Default_Radix_Mark);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">       procedure Put (To         : out String;                   Item       : in Num;                   Pic        : in Picture;                   Currency   : in String    := Default_Currency;                   Fill       : in Character := Default_Fill;                   Separator  : in Character := Default_Separator;                   Radix_Mark : in Character := Default_Radix_Mark); end Decimal_Output; private ... -- not specified by the language end Ada.Text_IO.Editing;</syntaxhighlight></p> The exception Constraint_Error is raised if the Image function or any of the Put procedures is invoked with a null string for Currency. <p><syntaxhighlight lang="Ada"> function Valid (Pic_String      : in String;              Blank_When_Zero : in Boolean := False) return Boolean;</syntaxhighlight></p> <p><span></span></p> :Valid returns True if Pic_String is a well-formed picture String (see [[Guide:95lrm/RM-F-3-1|F.3.1]]) the length of whose expansion does not exceed Max_Picture_Length, and if either Blank_When_Zero is False or Pic_String contains no '*'. <p><syntaxhighlight lang="Ada"> function To_Picture (Pic_String      : in String;                   Blank_When_Zero : in Boolean := False) return Picture;</syntaxhighlight></p> <p><span></span></p> :To_Picture returns a result Picture such that the application of the function Pic_String to this result yields an expanded picture String equivalent to Pic_String, and such that Blank_When_Zero applied to the result Picture is the same value as the parameter Blank_When_Zero. Picture_Error is raised if not Valid(Pic_String, Blank_When_Zero). <p><syntaxhighlight lang="Ada"> function Pic_String      (Pic : in Picture) return String; function Blank_When_Zero (Pic : in Picture) return Boolean;</syntaxhighlight></p> <p><span></span></p> :If Pic is To_Picture(String_Item, Boolean_Item) for some String_Item and Boolean_Item, then: <p><span></span></p> :* Pic_String(Pic) returns an expanded picture String equivalent to String_Item and with any lower-case letter replaced with its corresponding upper-case form, and <p><span></span></p> :* Blank_When_Zero(Pic) returns Boolean_Item. <p><span></span></p> :If Pic_1 and Pic_2 are objects of type Picture, then "="(Pic_1, Pic_2) is True when <p><span></span></p> :* Pic_String(Pic_1) = Pic_String(Pic_2), and <p><span></span></p> :* Blank_When_Zero(Pic_1) = Blank_When_Zero(Pic_2). <p><syntaxhighlight lang="Ada"> function Length (Pic      : in Picture;               Currency : in String := Default_Currency) return Natural;</syntaxhighlight></p> <p><span></span></p> :Length returns Pic_String(Pic)'Length + Currency_Length_Adjustment - Radix_Adjustment where <p><span></span></p> :* Currency_Length_Adjustment}} <p><span></span></p> ::* Currency'Length - 1 if there is some occurrence of '$' in Pic_String(Pic), and <p><span></span></p> ::* 0 otherwise. <p><span></span></p> :* Radix_Adjustment}} <p><span></span></p> ::* 1 if there is an occurrence of 'V' or 'v' in Pic_Str(Pic), and <p><span></span></p> ::* 0 otherwise. <p><syntaxhighlight lang="Ada"> function Valid (Item     : in Num;              Pic      : in Picture;              Currency : in String := Default_Currency) return Boolean;</syntaxhighlight></p> <p><span></span></p> :Valid returns True if Image(Item, Pic, Currency) does not raise Layout_Error, and returns False otherwise. <p><syntaxhighlight lang="Ada"> function Image (Item       : in Num;              Pic        : in Picture;              Currency   : in String    := Default_Currency;              Fill       : in Character := Default_Fill;              Separator  : in Character := Default_Separator;              Radix_Mark : in Character := Default_Radix_Mark) return String;</syntaxhighlight></p> <p><span></span></p> :Image returns the edited output String as defined in [[Guide:95lrm/RM-F-3-2|F.3.2]] for Item, Pic_String(Pic), Blank_When_Zero(Pic), Currency, Fill, Separator, and Radix_Mark. If these rules identify a layout error, then Image raises the exception Layout_Error. <p><syntaxhighlight lang="Ada"> procedure Put (File       : in File_Type;             Item       : in Num;             Pic        : in Picture;             Currency   : in String    := Default_Currency;             Fill       : in Character := Default_Fill;             Separator  : in Character := Default_Separator;             Radix_Mark : in Character := Default_Radix_Mark); procedure Put (Item       : in Num;             Pic        : in Picture;             Currency   : in String    := Default_Currency;             Fill       : in Character := Default_Fill;             Separator  : in Character := Default_Separator;             Radix_Mark : in Character := Default_Radix_Mark);</syntaxhighlight></p> <p><span></span></p> :Each of these Put procedures outputs Image(Item, Pic, Currency, Fill, Separator, Radix_Mark) consistent with the conventions for Put for other real types in case of bounded line length (see [[Guide:95lrm/RM-A-10-6|A.10.6]], ''[[Guide:95lrm/RM-A-10-6|Get and Put Procedures]]''). <p><syntaxhighlight lang="Ada"> procedure Put (To         : out String;             Item       : in Num;             Pic        : in Picture;             Currency   : in String    := Default_Currency;             Fill       : in Character := Default_Fill;             Separator  : in Character := Default_Separator;             Radix_Mark : in Character := Default_Radix_Mark);</syntaxhighlight></p> <p><span></span></p> :Put copies Image(Item, Pic, Currency, Fill, Separator, Radix_Mark) to the given string, right justified. Otherwise unassigned Character values in To are assigned the space character. If To'Length is less than the length of the string resulting from Image, then Layout_Error is raised. == Implementation Requirements == Max_Picture_Length shall be at least 30. The implementation shall support currency strings of length up to at least 10, both for Default_Currency in an instantiation of Decimal_Output, and for Currency in an invocation of Image or any of the Put procedures. == Notes == 4  The rules for edited output are based on COBOL (ANSI X3.23:1985, endorsed by ISO as ISO 1989-1985), with the following differences: * The COBOL provisions for picture string localization and for 'P' format are absent from Ada. * The following Ada facilities are not in COBOL: <p><span></span></p> ::* currency symbol placement after the number, <p><span></span></p> ::* localization of edited output string for multi-character currency string values, including support for both length-preserving and length-expanding currency symbols in picture strings <p><span></span></p> ::* localization of the radix mark, digits separator, and fill character, and <p><span></span></p> ::* parenthesization of negative values. <div> The value of 30 for Max_Picture_Length is the same limit as in COBOL. </div> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-F-3-2|Previous]] | [[Guide:95lrm/RM-F-3-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} axwdoat7hgudo6uzqkgcuo6n72ohzwv Guide:95lrm/RM-F-3-4 4200 1167 4439 2019-04-29T15:48:26Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-F-3-3|Previous]] | [[Guide:95lrm/RM-G|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: F.3.4 The Package Wide_Text_IO.Editing}} == Static Semantics == <span id="I6864"></span><span id="I6865"></span><span id="I6866"></span><span id="I6867"></span>The child package Wide_Text_IO.Editing has the same contents as Text_IO.Editing, except that: * each occurrence of Character is replaced by Wide_Character, * each occurrence of Text_IO is replaced by Wide_Text_IO, * the subtype of Default_Currency is Wide_String rather than String, and * each occurrence of String in the generic package Decimal_Output is replaced by Wide_String. == Notes == 5  Each of the functions Wide_Text_IO.Editing.Valid, To_Picture, and Pic_String has String (versus Wide_String) as its parameter or result subtype, since a picture String is not localizable. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-F-3-3|Previous]] | [[Guide:95lrm/RM-G|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} krac9d6r52mel1wwm07kbl21h7opqic Guide:95lrm/RM-G 4200 1168 4440 2019-05-02T08:45:55Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-F-3-4|Previous]] | [[Guide:95lrm/RM-G-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Annex G. Numerics}} <div>(normative)</div> <span id="I6868"></span>The Numerics Annex specifies * features for complex arithmetic, including complex I/O; * a mode (''strict mode''), in which the predefined arithmetic operations of floating point and fixed point types and the functions and operations of various predefined packages have to provide guaranteed accuracy or conform to other numeric performance requirements, which the Numerics Annex also specifies; * a mode (''relaxed mode''), in which no accuracy or other numeric performance requirements need be satisfied, as for implementations not conforming to the Numerics Annex; * models of floating point and fixed point arithmetic on which the accuracy requirements of strict mode are based; and * the definitions of the model-oriented attributes of floating point types that apply in the strict mode. == Implementation Advice == If Fortran (respectively, C) is widely supported in the target environment, implementations supporting the Numerics Annex should provide the child package Interfaces.Fortran (respectively, Interfaces.C) specified in [[Guide:95lrm/RM-B|Annex B]] and should support a ''convention_''identifier of Fortran (respectively, C) in the interfacing pragmas (see [[Guide:95lrm/RM-B|Annex B]]), thus allowing Ada programs to interface with programs written in that language. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-F-3-4|Previous]] | [[Guide:95lrm/RM-G-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} o9bgpb84pets0dtk6ywmtjicei00ai4 Guide:95lrm/RM-G-1 4200 1169 4441 2019-04-29T15:48:27Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G|Previous]] | [[Guide:95lrm/RM-G-1-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: G.1 Complex Arithmetic}} Types and arithmetic operations for complex arithmetic are provided in Generic_Complex_Types, which is defined in [[Guide:95lrm/RM-G-1-1|G.1.1]]. Implementation-defined approximations to the complex analogs of the mathematical functions known as the ''elementary functions'' are provided by the subprograms in Generic_Complex_Elementary_Functions, which is defined in [[Guide:95lrm/RM-G-1-2|G.1.2]]. Both of these library units are generic children of the predefined package Numerics (see [[Guide:95lrm/RM-A-5|A.5]]). Nongeneric equivalents of these generic packages for each of the predefined floating point types are also provided as children of Numerics. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G|Previous]] | [[Guide:95lrm/RM-G-1-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} njtznilyi8eswalerkh3uq6xtac8qmt Guide:95lrm/RM-G-1-1 4200 1170 4442 2019-05-02T08:51:47Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G-1|Previous]] | [[Guide:95lrm/RM-G-1-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: G.1.1 Complex Types}} == Static Semantics == The generic library package Numerics.Generic_Complex_Types has the following declaration: <p><syntaxhighlight lang="Ada"> generic type Real is digits <>; package Ada.Numerics.Generic_Complex_Types is pragma Pure(Generic_Complex_Types);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Complex is    record       Re, Im : Real'Base;    end record;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Imaginary is private;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    i : constant Imaginary; j : constant Imaginary;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Re (X : Complex)   return Real'Base; function Im (X : Complex)   return Real'Base; function Im (X : Imaginary) return Real'Base;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Set_Re (X  : in out Complex;                   Re : in     Real'Base); procedure Set_Im (X  : in out Complex;                   Im : in     Real'Base); procedure Set_Im (X  :    out Imaginary;                   Im : in     Real'Base);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Compose_From_Cartesian (Re, Im : Real'Base) return Complex; function Compose_From_Cartesian (Re     : Real'Base) return Complex; function Compose_From_Cartesian (Im     : Imaginary) return Complex;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Modulus (X     : Complex) return Real'Base; function "abs"   (Right : Complex) return Real'Base renames Modulus;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Argument (X     : Complex)   return Real'Base; function Argument (X     : Complex;                    Cycle : Real'Base) return Real'Base;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Compose_From_Polar (Modulus, Argument        : Real'Base)    return Complex; function Compose_From_Polar (Modulus, Argument, Cycle : Real'Base)    return Complex;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "+"       (Right : Complex) return Complex; function "-"       (Right : Complex) return Complex; function Conjugate (X     : Complex) return Complex;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "+" (Left, Right : Complex) return Complex; function "-" (Left, Right : Complex) return Complex; function "*" (Left, Right : Complex) return Complex; function "/" (Left, Right : Complex) return Complex;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "**" (Left : Complex; Right : Integer) return Complex;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "+"       (Right : Imaginary) return Imaginary; function "-"       (Right : Imaginary) return Imaginary; function Conjugate (X     : Imaginary) return Imaginary renames "-"; function "abs"     (Right : Imaginary) return Real'Base;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "+" (Left, Right : Imaginary) return Imaginary; function "-" (Left, Right : Imaginary) return Imaginary; function "*" (Left, Right : Imaginary) return Real'Base; function "/" (Left, Right : Imaginary) return Real'Base;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "**" (Left : Imaginary; Right : Integer) return Complex;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "<"  (Left, Right : Imaginary) return Boolean; function "<=" (Left, Right : Imaginary) return Boolean; function ">"  (Left, Right : Imaginary) return Boolean; function ">=" (Left, Right : Imaginary) return Boolean;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "+" (Left : Complex;   Right : Real'Base) return Complex; function "+" (Left : Real'Base; Right : Complex)   return Complex; function "-" (Left : Complex;   Right : Real'Base) return Complex; function "-" (Left : Real'Base; Right : Complex)   return Complex; function "*" (Left : Complex;   Right : Real'Base) return Complex; function "*" (Left : Real'Base; Right : Complex)   return Complex; function "/" (Left : Complex;   Right : Real'Base) return Complex; function "/" (Left : Real'Base; Right : Complex)   return Complex;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "+" (Left : Complex;   Right : Imaginary) return Complex; function "+" (Left : Imaginary; Right : Complex)   return Complex; function "-" (Left : Complex;   Right : Imaginary) return Complex; function "-" (Left : Imaginary; Right : Complex)   return Complex; function "*" (Left : Complex;   Right : Imaginary) return Complex; function "*" (Left : Imaginary; Right : Complex)   return Complex; function "/" (Left : Complex;   Right : Imaginary) return Complex; function "/" (Left : Imaginary; Right : Complex)   return Complex;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function "+" (Left : Imaginary; Right : Real'Base) return Complex; function "+" (Left : Real'Base; Right : Imaginary) return Complex; function "-" (Left : Imaginary; Right : Real'Base) return Complex; function "-" (Left : Real'Base; Right : Imaginary) return Complex; function "*" (Left : Imaginary; Right : Real'Base) return Imaginary; function "*" (Left : Real'Base; Right : Imaginary) return Imaginary; function "/" (Left : Imaginary; Right : Real'Base) return Imaginary; function "/" (Left : Real'Base; Right : Imaginary) return Imaginary;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> private</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    type Imaginary is new Real'Base; i : constant Imaginary := 1.0; j : constant Imaginary := 1.0;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> end Ada.Numerics.Generic_Complex_Types;</syntaxhighlight></p> <span id="I6910"></span><span id="I6911"></span><span id="I6912"></span><span id="I6913"></span>The library package Numerics.Complex_Types is declared pure and defines the same types, constants, and subprograms as Numerics.Generic_Complex_Types, except that the predefined type Float is systematically substituted for Real'Base throughout. Nongeneric equivalents of Numerics.Generic_Complex_Types for each of the other predefined floating point types are defined similarly, with the names Numerics.Short_Complex_Types, Numerics.Long_Complex_Types, etc. Complex is a visible type with cartesian components. Imaginary is a private type; its full type is derived from Real'Base. The arithmetic operations and the Re, Im, Modulus, Argument, and Conjugate functions have their usual mathematical meanings. When applied to a parameter of pure-imaginary type, the ''imaginary-part'' function Im yields the value of its parameter, as the corresponding real value. The remaining subprograms have the following meanings: * The Set_Re and Set_Im procedures replace the designated component of a complex parameter with the given real value; applied to a parameter of pure-imaginary type, the Set_Im procedure replaces the value of that parameter with the imaginary value corresponding to the given real value. * The Compose_From_Cartesian function constructs a complex value from the given real and imaginary components. If only one component is given, the other component is implicitly zero. * The Compose_From_Polar function constructs a complex value from the given modulus (radius) and argument (angle). When the value of the parameter Modulus is positive (resp., negative), the result is the complex value represented by the point in the complex plane lying at a distance from the origin given by the absolute value of Modulus and forming an angle measured counterclockwise from the positive (resp., negative) real axis given by the value of the parameter Argument. When the Cycle parameter is specified, the result of the Argument function and the parameter Argument of the Compose_From_Polar function are measured in units such that a full cycle of revolution has the given value; otherwise, they are measured in radians. The computed results of the mathematically multivalued functions are rendered single-valued by the following conventions, which are meant to imply the principal branch: * The result of the Modulus function is nonnegative. * The result of the Argument function is in the quadrant containing the point in the complex plane represented by the parameter X. This may be any quadrant (I through IV); thus, the range of the Argument function is approximately -PI to PI (-Cycle/2.0 to Cycle/2.0, if the parameter Cycle is specified). When the point represented by the parameter X lies on the negative real axis, the result approximates <p><span></span></p> :* PI (resp., -PI) when the sign of the imaginary component of X is positive (resp., negative), if Real'Signed_Zeros is True; <p><span></span></p> :* PI, if Real'Signed_Zeros is False. * Because a result lying on or near one of the axes may not be exactly representable, the approximation inherent in computing the result may place it in an adjacent quadrant, close to but on the wrong side of the axis. == Dynamic Semantics == The exception Numerics.Argument_Error is raised by the Argument and Compose_From_Polar functions with specified cycle, signaling a parameter value outside the domain of the corresponding mathematical function, when the value of the parameter Cycle is zero or negative. <span id="I6914"></span><span id="I6915"></span><span id="I6916"></span>The exception Constraint_Error is raised by the division operator when the value of the right operand is zero, and by the exponentiation operator when the value of the left operand is zero and the value of the exponent is negative, provided that Real'Machine_Overflows is True; when Real'Machine_Overflows is False, the result is unspecified. <span id="I6917"></span>Constraint_Error can also be raised when a finite result overflows (see [[Guide:95lrm/RM-G-2-6|G.2.6]]). == Implementation Requirements == In the implementation of Numerics.Generic_Complex_Types, the range of intermediate values allowed during the calculation of a final result shall not be affected by any range constraint of the subtype Real. <span id="I6918"></span>In the following cases, evaluation of a complex arithmetic operation shall yield the ''prescribed result'', provided that the preceding rules do not call for an exception to be raised: * The results of the Re, Im, and Compose_From_Cartesian functions are exact. * The real (resp., imaginary) component of the result of a binary addition operator that yields a result of complex type is exact when either of its operands is of pure-imaginary (resp., real) type. * The real (resp., imaginary) component of the result of a binary subtraction operator that yields a result of complex type is exact when its right operand is of pure-imaginary (resp., real) type. * The real component of the result of the Conjugate function for the complex type is exact. * When the point in the complex plane represented by the parameter X lies on the nonnegative real axis, the Argument function yields a result of zero. * When the value of the parameter Modulus is zero, the Compose_From_Polar function yields a result of zero. * When the value of the parameter Argument is equal to a multiple of the quarter cycle, the result of the Compose_From_Polar function with specified cycle lies on one of the axes. In this case, one of its components is zero, and the other has the magnitude of the parameter Modulus. * Exponentiation by a zero exponent yields the value one. Exponentiation by a unit exponent yields the value of the left operand. Exponentiation of the value one yields the value one. Exponentiation of the value zero yields the value zero, provided that the exponent is nonzero. When the left operand is of pure-imaginary type, one component of the result of the exponentiation operator is zero. When the result, or a result component, of any operator of Numerics.Generic_Complex_Types has a mathematical definition in terms of a single arithmetic or relational operation, that result or result component exhibits the accuracy of the corresponding operation of the type Real. Other accuracy requirements for the Modulus, Argument, and Compose_From_Polar functions, and accuracy requirements for the multiplication of a pair of complex operands or for division by a complex operand, all of which apply only in the strict mode, are given in [[Guide:95lrm/RM-G-2-6|G.2.6]]. The sign of a zero result or zero result component yielded by a complex arithmetic operation or function is implementation defined when Real'Signed_Zeros is True. == Implementation Permissions == The nongeneric equivalent packages may, but need not, be actual instantiations of the generic package for the appropriate predefined type. Implementations may obtain the result of exponentiation of a complex or pure-imaginary operand by repeated complex multiplication, with arbitrary association of the factors and with a possible final complex reciprocation (when the exponent is negative). Implementations are also permitted to obtain the result of exponentiation of a complex operand, but not of a pure-imaginary operand, by converting the left operand to a polar representation; exponentiating the modulus by the given exponent; multiplying the argument by the given exponent; and reconverting to a cartesian representation. Because of this implementation freedom, no accuracy requirement is imposed on complex exponentiation (except for the prescribed results given above, which apply regardless of the implementation method chosen). == Implementation Advice == Because the usual mathematical meaning of multiplication of a complex operand and a real operand is that of the scaling of both components of the former by the latter, an implementation should not perform this operation by first promoting the real operand to complex type and then performing a full complex multiplication. In systems that, in the future, support an Ada binding to IEC 559:1989, the latter technique will not generate the required result when one of the components of the complex operand is infinite. (Explicit multiplication of the infinite component by the zero component obtained during promotion yields a NaN that propagates into the final result.) Analogous advice applies in the case of multiplication of a complex operand and a pure-imaginary operand, and in the case of division of a complex operand by a real or pure-imaginary operand. Likewise, because the usual mathematical meaning of addition of a complex operand and a real operand is that the imaginary operand remains unchanged, an implementation should not perform this operation by first promoting the real operand to complex type and then performing a full complex addition. In implementations in which the Signed_Zeros attribute of the component type is True (and which therefore conform to IEC 559:1989 in regard to the handling of the sign of zero in predefined arithmetic operations), the latter technique will not generate the required result when the imaginary component of the complex operand is a negatively signed zero. (Explicit addition of the negative zero to the zero obtained during promotion yields a positive zero.) Analogous advice applies in the case of addition of a complex operand and a pure-imaginary operand, and in the case of subtraction of a complex operand and a real or pure-imaginary operand. Implementations in which Real'Signed_Zeros is True should attempt to provide a rational treatment of the signs of zero results and result components. As one example, the result of the Argument function should have the sign of the imaginary component of the parameter X when the point represented by that parameter lies on the positive real axis; as another, the sign of the imaginary component of the Compose_From_Polar function should be the same as (resp., the opposite of) that of the Argument parameter when that parameter has a value of zero and the Modulus parameter has a nonnegative (resp., negative) value. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G-1|Previous]] | [[Guide:95lrm/RM-G-1-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 1wa52c082wsrfqtufltfu1aho7onffq Guide:95lrm/RM-G-1-2 4200 1171 4443 2019-05-02T08:54:22Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G-1-1|Previous]] | [[Guide:95lrm/RM-G-1-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: G.1.2 Complex Elementary Functions}} == Static Semantics == The generic library package Numerics.Generic_Complex_Elementary_Functions has the following declaration: <p><syntaxhighlight lang="Ada"> with Ada.Numerics.Generic_Complex_Types; generic with package Complex_Types is       new Ada.Numerics.Generic_Complex_Types (<>); use Complex_Types; package Ada.Numerics.Generic_Complex_Elementary_Functions is pragma Pure(Generic_Complex_Elementary_Functions);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Sqrt (X : Complex)   return Complex; function Log  (X : Complex)   return Complex; function Exp  (X : Complex)   return Complex; function Exp  (X : Imaginary) return Complex; function "**" (Left : Complex;   Right : Complex)   return Complex; function "**" (Left : Complex;   Right : Real'Base) return Complex; function "**" (Left : Real'Base; Right : Complex)   return Complex;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Sin (X : Complex) return Complex; function Cos (X : Complex) return Complex; function Tan (X : Complex) return Complex; function Cot (X : Complex) return Complex;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    function Arcsin (X : Complex) return Complex; function Arccos (X : Complex) return Complex; function Arctan (X : Complex) return Complex; function Arccot (X : Complex) return Complex;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function Sinh (X : Complex) return Complex; function Cosh (X : Complex) return Complex; function Tanh (X : Complex) return Complex; function Coth (X : Complex) return Complex;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   function Arcsinh (X : Complex) return Complex; function Arccosh (X : Complex) return Complex; function Arctanh (X : Complex) return Complex; function Arccoth (X : Complex) return Complex;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> end Ada.Numerics.Generic_Complex_Elementary_Functions;</syntaxhighlight></p> <span id="I6962"></span><span id="I6963"></span><span id="I6964"></span><span id="I6965"></span>The library package Numerics.Complex_Elementary_Functions is declared pure and defines the same subprograms as Numerics.Generic_Complex_Elementary_Functions, except that the predefined type Float is systematically substituted for Real'Base, and the Complex and Imaginary types exported by Numerics.Complex_Types are systematically substituted for Complex and Imaginary, throughout. Nongeneric equivalents of Numerics.Generic_Complex_Elementary_Functions corresponding to each of the other predefined floating point types are defined similarly, with the names Numerics.Short_Complex_Elementary_Functions, Numerics.Long_Complex_Elementary_Functions, etc. The overloading of the Exp function for the pure-imaginary type is provided to give the user an alternate way to compose a complex value from a given modulus and argument. In addition to Compose_From_Polar(Rho, Theta) (see [[Guide:95lrm/RM-G-1-1|G.1.1]]), the programmer may write Rho * Exp(i * Theta). The imaginary (resp., real) component of the parameter X of the forward hyperbolic (resp., trigonometric) functions and of the Exp function (and the parameter X, itself, in the case of the overloading of the Exp function for the pure-imaginary type) represents an angle measured in radians, as does the imaginary (resp., real) component of the result of the Log and inverse hyperbolic (resp., trigonometric) functions. The functions have their usual mathematical meanings. However, the arbitrariness inherent in the placement of branch cuts, across which some of the complex elementary functions exhibit discontinuities, is eliminated by the following conventions: * The imaginary component of the result of the Sqrt and Log functions is discontinuous as the parameter X crosses the negative real axis. * The result of the exponentiation operator when the left operand is of complex type is discontinuous as that operand crosses the negative real axis. * The real (resp., imaginary) component of the result of the Arcsin and Arccos (resp., Arctanh) functions is discontinuous as the parameter X crosses the real axis to the left of -1.0 or the right of 1.0. * The real (resp., imaginary) component of the result of the Arctan (resp., Arcsinh) function is discontinuous as the parameter X crosses the imaginary axis below -''i'' or above ''i''. * The real component of the result of the Arccot function is discontinuous as the parameter X crosses the imaginary axis between -''i'' and ''i''. * The imaginary component of the Arccosh function is discontinuous as the parameter X crosses the real axis to the left of 1.0. * The imaginary component of the result of the Arccoth function is discontinuous as the parameter X crosses the real axis between -1.0 and 1.0. The computed results of the mathematically multivalued functions are rendered single-valued by the following conventions, which are meant to imply the principal branch: * The real component of the result of the Sqrt and Arccosh functions is nonnegative. * The same convention applies to the imaginary component of the result of the Log function as applies to the result of the natural-cycle version of the Argument function of Numerics.Generic_Complex_Types (see [[Guide:95lrm/RM-G-1-1|G.1.1]]). * The range of the real (resp., imaginary) component of the result of the Arcsin and Arctan (resp., Arcsinh and Arctanh) functions is approximately -PI/2.0 to PI/2.0. * The real (resp., imaginary) component of the result of the Arccos and Arccot (resp., Arccoth) functions ranges from 0.0 to approximately PI. * The range of the imaginary component of the result of the Arccosh function is approximately -PI to PI. In addition, the exponentiation operator inherits the single-valuedness of the Log function. == Dynamic Semantics == The exception Numerics.Argument_Error is raised by the exponentiation operator, signaling a parameter value outside the domain of the corresponding mathematical function, when the value of the left operand is zero and the real component of the exponent (or the exponent itself, when it is of real type) is zero. <span id="I6966"></span><span id="I6967"></span><span id="I6968"></span>The exception Constraint_Error is raised, signaling a pole of the mathematical function (analogous to dividing by zero), in the following cases, provided that Complex_Types.Real'Machine_Overflows is True: * by the Log, Cot, and Coth functions, when the value of the parameter X is zero; * by the exponentiation operator, when the value of the left operand is zero and the real component of the exponent (or the exponent itself, when it is of real type) is negative; * by the Arctan and Arccot functions, when the value of the parameter X is ± ''i''; * by the Arctanh and Arccoth functions, when the value of the parameter X is ± 1.0. Constraint_Error can also be raised when a finite result overflows (see [[Guide:95lrm/RM-G-2-6|G.2.6]]); this may occur for parameter values sufficiently ''near'' poles, and, in the case of some of the functions, for parameter values having components of sufficiently large magnitude. <span id="I6969"></span>When Complex_Types.Real'Machine_Overflows is False, the result at poles is unspecified. == Implementation Requirements == In the implementation of Numerics.Generic_Complex_Elementary_Functions, the range of intermediate values allowed during the calculation of a final result shall not be affected by any range constraint of the subtype Complex_Types.Real. <span id="I6970"></span>In the following cases, evaluation of a complex elementary function shall yield the ''prescribed result'' (or a result having the prescribed component), provided that the preceding rules do not call for an exception to be raised: * When the parameter X has the value zero, the Sqrt, Sin, Arcsin, Tan, Arctan, Sinh, Arcsinh, Tanh, and Arctanh functions yield a result of zero; the Exp, Cos, and Cosh functions yield a result of one; the Arccos and Arccot functions yield a real result; and the Arccoth function yields an imaginary result. * When the parameter X has the value one, the Sqrt function yields a result of one; the Log, Arccos, and Arccosh functions yield a result of zero; and the Arcsin function yields a real result. * When the parameter X has the value -1.0, the Sqrt function yields the result <p><span></span></p> :* ''i'' (resp., -''i''), when the sign of the imaginary component of X is positive (resp., negative), if Complex_Types.Real'Signed_Zeros is True; <p><span></span></p> :* ''i'', if Complex_Types.Real'Signed_Zeros is False; * the Log function yields an imaginary result; and the Arcsin and Arccos functions yield a real result. * When the parameter X has the value ± ''i'', the Log function yields an imaginary result. * Exponentiation by a zero exponent yields the value one. Exponentiation by a unit exponent yields the value of the left operand (as a complex value). Exponentiation of the value one yields the value one. Exponentiation of the value zero yields the value zero. Other accuracy requirements for the complex elementary functions, which apply only in the strict mode, are given in [[Guide:95lrm/RM-G-2-6|G.2.6]]. The sign of a zero result or zero result component yielded by a complex elementary function is implementation defined when Complex_Types.Real'Signed_Zeros is True. == Implementation Permissions == The nongeneric equivalent packages may, but need not, be actual instantiations of the generic package with the appropriate predefined nongeneric equivalent of Numerics.Generic_Complex_Types; if they are, then the latter shall have been obtained by actual instantiation of Numerics.Generic_Complex_Types. The exponentiation operator may be implemented in terms of the Exp and Log functions. Because this implementation yields poor accuracy in some parts of the domain, no accuracy requirement is imposed on complex exponentiation. <span id="I6971"></span>The implementation of the Exp function of a complex parameter X is allowed to raise the exception Constraint_Error, signaling overflow, when the real component of X exceeds an unspecified threshold that is approximately log(Complex_Types.Real'Safe_Last). This permission recognizes the impracticality of avoiding overflow in the marginal case that the exponential of the real component of X exceeds the safe range of Complex_Types.Real but both components of the final result do not. Similarly, the Sin and Cos (resp., Sinh and Cosh) functions are allowed to raise the exception Constraint_Error, signaling overflow, when the absolute value of the imaginary (resp., real) component of the parameter X exceeds an unspecified threshold that is approximately log(Complex_Types.Real'Safe_Last) + log(2.0). <span id="I6972"></span>This permission recognizes the impracticality of avoiding overflow in the marginal case that the hyperbolic sine or cosine of the imaginary (resp., real) component of X exceeds the safe range of Complex_Types.Real but both components of the final result do not. == Implementation Advice == Implementations in which Complex_Types.Real'Signed_Zeros is True should attempt to provide a rational treatment of the signs of zero results and result components. For example, many of the complex elementary functions have components that are odd functions of one of the parameter components; in these cases, the result component should have the sign of the parameter component at the origin. Other complex elementary functions have zero components whose sign is opposite that of a parameter component at the origin, or is always positive or always negative. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G-1-1|Previous]] | [[Guide:95lrm/RM-G-1-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 7mkk89883vvwr31b6q4auyvn5p34ui6 Guide:95lrm/RM-G-1-3 4200 1172 4444 2019-05-02T09:01:15Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G-1-2|Previous]] | [[Guide:95lrm/RM-G-1-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: G.1.3 Complex Input-Output}} The generic package Text_IO.Complex_IO defines procedures for the formatted input and output of complex values. The generic actual parameter in an instantiation of Text_IO.Complex_IO is an instance of Numerics.Generic_Complex_Types for some floating point subtype. Exceptional conditions are reported by raising the appropriate exception defined in Text_IO. == Static Semantics == The generic library package Text_IO.Complex_IO has the following declaration: <p><syntaxhighlight lang="Ada"> with Ada.Numerics.Generic_Complex_Types; generic with package Complex_Types is      new Ada.Numerics.Generic_Complex_Types (<>); package Ada.Text_IO.Complex_IO is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    use Complex_Types;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    Default_Fore : Field := 2; Default_Aft  : Field := Real'Digits - 1; Default_Exp  : Field := 3;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Get (File  : in  File_Type;                Item  : out Complex;                Width : in  Field := 0); procedure Get (Item  : out Complex;                Width : in  Field := 0);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Put (File : in File_Type;                Item : in Complex;                Fore : in Field := Default_Fore;                Aft  : in Field := Default_Aft;                Exp  : in Field := Default_Exp); procedure Put (Item : in Complex;                Fore : in Field := Default_Fore;                Aft  : in Field := Default_Aft;                Exp  : in Field := Default_Exp);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    procedure Get (From : in  String;                Item : out Complex;                Last : out Positive); procedure Put (To   : out String;                Item : in  Complex;                Aft  : in  Field := Default_Aft;                Exp  : in  Field := Default_Exp);</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> end Ada.Text_IO.Complex_IO;</syntaxhighlight></p> The semantics of the Get and Put procedures are as follows: <p><syntaxhighlight lang="Ada"> procedure Get (File  : in  File_Type;             Item  : out Complex;             Width : in  Field := 0); procedure Get (Item  : out Complex;             Width : in  Field := 0);</syntaxhighlight></p> <p><span></span></p> :The input sequence is a pair of optionally signed real literals representing the real and imaginary components of a complex value These components have the format defined for the corresponding Get procedure of an instance of Text_IO.Float_IO (see [[Guide:95lrm/RM-A-10-9|A.10.9]]) for the base subtype of Complex_Types.Real. The pair of components may be separated by a comma or surrounded by a pair of parentheses or both. Blanks are freely allowed before each of the components and before the parentheses and comma, if either is used. If the value of the parameter Width is zero, then <p><span></span></p> ::* line and page terminators are also allowed in these places; <p><span></span></p> ::* the components shall be separated by at least one blank or line terminator if the comma is omitted; and <p><span></span></p> ::* reading stops when the right parenthesis has been read, if the input sequence includes a left parenthesis, or when the imaginary component has been read, otherwise. :If a nonzero value of Width is supplied, then <p><span></span></p> ::* the components shall be separated by at least one blank if the comma is omitted; and <p><span></span></p> ::* exactly Width characters are read, or the characters (possibly none) up to a line terminator, whichever comes first (blanks are included in the count). <p><span></span></p> :Returns, in the parameter Item, the value of type Complex that corresponds to the input sequence. <p><span></span></p> :The exception Text_IO.Data_Error is raised if the input sequence does not have the required syntax or if the components of the complex value obtained are not of the base subtype of Complex_Types.Real. <p><syntaxhighlight lang="Ada"> procedure Put (File : in File_Type;             Item : in Complex;             Fore : in Field := Default_Fore;             Aft  : in Field := Default_Aft;             Exp  : in Field := Default_Exp); procedure Put (Item : in Complex;             Fore : in Field := Default_Fore;             Aft  : in Field := Default_Aft;             Exp  : in Field := Default_Exp);</syntaxhighlight></p> <p><span></span></p> :Outputs the value of the parameter Item as a pair of decimal literals representing the real and imaginary components of the complex value, using the syntax of an aggregate. More specifically, <p><span></span></p> ::* outputs a left parenthesis; <p><span></span></p> ::* outputs the value of the real component of the parameter Item with the format defined by the corresponding Put procedure of an instance of Text_IO.Float_IO for the base subtype of Complex_Types.Real, using the given values of Fore, Aft, and Exp; <p><span></span></p> ::* outputs a comma; <p><span></span></p> ::* outputs the value of the imaginary component of the parameter Item with the format defined by the corresponding Put procedure of an instance of Text_IO.Float_IO for the base subtype of Complex_Types.Real, using the given values of Fore, Aft, and Exp; <p><span></span></p> ::* outputs a right parenthesis. <p><syntaxhighlight lang="Ada"> procedure Get (From : in  String;             Item : out Complex;             Last : out Positive);</syntaxhighlight></p> <p><span></span></p> :Reads a complex value from the beginning of the given string, following the same rule as the Get procedure that reads a complex value from a file, but treating the end of the string as a line terminator. Returns, in the parameter Item, the value of type Complex that corresponds to the input sequence. Returns in Last the index value such that From(Last) is the last character read. <p><span></span></p> :The exception Text_IO.Data_Error is raised if the input sequence does not have the required syntax or if the components of the complex value obtained are not of the base subtype of Complex_Types.Real. <p><syntaxhighlight lang="Ada"> procedure Put (To   : out String;             Item : in  Complex;             Aft  : in  Field := Default_Aft;             Exp  : in  Field := Default_Exp);</syntaxhighlight></p> <p><span></span></p> :Outputs the value of the parameter Item to the given string as a pair of decimal literals representing the real and imaginary components of the complex value, using the syntax of an aggregate. More specifically, <p><span></span></p> ::* a left parenthesis, the real component, and a comma are left justified in the given string, with the real component having the format defined by the Put procedure (for output to a file) of an instance of Text_IO.Float_IO for the base subtype of Complex_Types.Real, using a value of zero for Fore and the given values of Aft and Exp; <p><span></span></p> ::* the imaginary component and a right parenthesis are right justified in the given string, with the imaginary component having the format defined by the Put procedure (for output to a file) of an instance of Text_IO.Float_IO for the base subtype of Complex_Types.Real, using a value for Fore that completely fills the remainder of the string, together with the given values of Aft and Exp. <p><span></span></p> :The exception Text_IO.Layout_Error is raised if the given string is too short to hold the formatted output. == Implementation Permissions == Other exceptions declared (by renaming) in Text_IO may be raised by the preceding procedures in the appropriate circumstances, as for the corresponding procedures of Text_IO.Float_IO. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G-1-2|Previous]] | [[Guide:95lrm/RM-G-1-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 2bpgez78f63ycvx7o2bc41n5ep40vqw Guide:95lrm/RM-G-1-4 4200 1173 4445 2019-04-29T15:48:27Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G-1-3|Previous]] | [[Guide:95lrm/RM-G-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: G.1.4 The Package Wide_Text_IO.Complex_IO}} == Static Semantics == <span id="I6991"></span><span id="I6992"></span><span id="I6993"></span><span id="I6994"></span>Implementations shall also provide the generic library package Wide_Text_IO.Complex_IO. Its declaration is obtained from that of Text_IO.Complex_IO by systematically replacing Text_IO by Wide_Text_IO and String by Wide_String; the description of its behavior is obtained by additionally replacing references to particular characters (commas, parentheses, etc.) by those for the corresponding wide characters. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G-1-3|Previous]] | [[Guide:95lrm/RM-G-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 2q3hzk6v7ikrwkdrzb2zmevgphirgms Guide:95lrm/RM-G-2 4200 1174 4446 2019-04-29T15:48:27Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G-1-4|Previous]] | [[Guide:95lrm/RM-G-2-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: G.2 Numeric Performance Requirements}} == Implementation Requirements == <span id="I6995"></span><span id="I6996"></span>Implementations shall provide a user-selectable mode in which the accuracy and other numeric performance requirements detailed in the following subclauses are observed. This mode, referred to as the ''strict mode'', may or may not be the default mode; it directly affects the results of the predefined arithmetic operations of real types and the results of the subprograms in children of the Numerics package, and indirectly affects the operations in other language defined packages. <span id="I6997"></span>Implementations shall also provide the opposing mode, which is known as the ''relaxed mode''. == Implementation Permissions == Either mode may be the default mode. The two modes need not actually be different. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G-1-4|Previous]] | [[Guide:95lrm/RM-G-2-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} fskpg7takeyeuv7eaoeewoidyolzlcp Guide:95lrm/RM-G-2-1 4200 1175 4447 2019-04-29T15:48:27Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G-2|Previous]] | [[Guide:95lrm/RM-G-2-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: G.2.1 Model of Floating Point Arithmetic}} In the strict mode, the predefined operations of a floating point type shall satisfy the accuracy requirements specified here and shall avoid or signal overflow in the situations described. This behavior is presented in terms of a model of floating point arithmetic that builds on the concept of the canonical form (see [[Guide:95lrm/RM-A-5-3|A.5.3]]). == Static Semantics == Associated with each floating point type is an infinite set of model numbers. The model numbers of a type are used to define the accuracy requirements that have to be satisfied by certain predefined operations of the type; through certain attributes of the model numbers, they are also used to explain the meaning of a user-declared floating point type declaration. The model numbers of a derived type are those of the parent type; the model numbers of a subtype are those of its type. <span id="I6998"></span>The ''model numbers'' of a floating point type T are zero and all the values expressible in the canonical form (for the type T), in which ''mantissa'' has T'Model_Mantissa digits and ''exponent'' has a value greater than or equal to T'Model_Emin. (These attributes are defined in [[Guide:95lrm/RM-G-2-2|G.2.2]].) <span id="I6999"></span>A ''model interval'' of a floating point type is any interval whose bounds are model numbers of the type. <span id="I7000"></span>The ''model interval'' of a type T ''associated with a value'' ''v'' is the smallest model interval of T that includes ''v''. (The model interval associated with a model number of a type consists of that number only.) == Implementation Requirements == The accuracy requirements for the evaluation of certain predefined operations of floating point types are as follows. <span id="I7001"></span>An ''operand interval'' is the model interval, of the type specified for the operand of an operation, associated with the value of the operand. For any predefined arithmetic operation that yields a result of a floating point type T, the required bounds on the result are given by a model interval of T (called the ''result interval'') defined in terms of the operand values as follows: * <span id="I7002"></span>The result interval is the smallest model interval of T that includes the minimum and the maximum of all the values obtained by applying the (exact) mathematical operation to values arbitrarily selected from the respective operand intervals. The result interval of an exponentiation is obtained by applying the above rule to the sequence of multiplications defined by the exponent, assuming arbitrary association of the factors, and to the final division in the case of a negative exponent. The result interval of a conversion of a numeric value to a floating point type T is the model interval of T associated with the operand value, except when the source expression is of a fixed point type with a ''small'' that is not a power of T'Machine_Radix or is a fixed point multiplication or division either of whose operands has a ''small'' that is not a power of T'Machine_Radix; in these cases, the result interval is implementation defined. <span id="I7003"></span><span id="I7004"></span>For any of the foregoing operations, the implementation shall deliver a value that belongs to the result interval when both bounds of the result interval are in the safe range of the result type T, as determined by the values of T'Safe_First and T'Safe_Last; otherwise, * <span id="I7005"></span>if T'Machine_Overflows is True, the implementation shall either deliver a value that belongs to the result interval or raise Constraint_Error; * if T'Machine_Overflows is False, the result is implementation defined. For any predefined relation on operands of a floating point type T, the implementation may deliver any value (i.e., either True or False) obtained by applying the (exact) mathematical comparison to values arbitrarily chosen from the respective operand intervals. The result of a membership test is defined in terms of comparisons of the operand value with the lower and upper bounds of the given range or type mark (the usual rules apply to these comparisons). == Implementation Permissions == If the underlying floating point hardware implements division as multiplication by a reciprocal, the result interval for division (and exponentiation by a negative exponent) is implementation defined. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G-2|Previous]] | [[Guide:95lrm/RM-G-2-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 81aiuapoporbhmcckl42yubxco1slb7 Guide:95lrm/RM-G-2-2 4200 1176 4448 2019-04-29T15:48:27Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G-2-1|Previous]] | [[Guide:95lrm/RM-G-2-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: G.2.2 Model-Oriented Attributes of Floating Point Types}} In implementations that support the Numerics Annex, the model-oriented attributes of floating point types shall yield the values defined here, in both the strict and the relaxed modes. These definitions add conditions to those in [[Guide:95lrm/RM-A-5-3|A.5.3]]. == Static Semantics == For every subtype S of a floating point type ''T'': ; S'<span id="I7006"></span><span id="I7007"></span>Model_Mantissa : Yields the number of digits in the mantissa of the canonical form of the model numbers of ''T'' (see [[Guide:95lrm/RM-A-5-3|A.5.3]]). The value of this attribute shall be greater than or equal to ''Ceiling''(''d'' · log(10) / log(''T'''Machine_Radix)) + 1, where ''d'' is the requested decimal precision of ''T''. In addition, it shall be less than or equal to the value of ''T'''Machine_Mantissa. This attribute yields a value of the type ''universal_integer''. ; S'<span id="I7008"></span><span id="I7009"></span>Model_Emin : Yields the minimum exponent of the canonical form of the model numbers of ''T'' (see [[Guide:95lrm/RM-A-5-3|A.5.3]]). The value of this attribute shall be greater than or equal to the value of ''T'''Machine_Emin. This attribute yields a value of the type ''universal_integer''. ; S'<span id="I7010"></span><span id="I7011"></span>Safe_First : Yields the lower bound of the safe range of ''T''. The value of this attribute shall be a model number of ''T'' and greater than or equal to the lower bound of the base range of ''T''. In addition, if ''T'' is declared by a floating_point_definition or is derived from such a type, and the floating_point_definition includes a real_range_specification specifying a lower bound of ''lb'', then the value of this attribute shall be less than or equal to ''lb''; otherwise, it shall be less than or equal to -10.0 <sup>4 · ''d''</sup>, where ''d'' is the requested decimal precision of ''T''. This attribute yields a value of the type ''universal_real''. ; S'<span id="I7012"></span><span id="I7013"></span>Safe_Last : Yields the upper bound of the safe range of ''T''. The value of this attribute shall be a model number of ''T'' and less than or equal to the upper bound of the base range of ''T''. In addition, if ''T'' is declared by a floating_point_definition or is derived from such a type, and the floating_point_definition includes a real_range_specification specifying an upper bound of ''ub'', then the value of this attribute shall be greater than or equal to ''ub''; otherwise, it shall be greater than or equal to 10.0 <sup>4 · ''d''</sup>, where d is the requested decimal precision of ''T''. This attribute yields a value of the type ''universal_real''. ; <span id="I7014"></span>S'<span id="I7015"></span><span id="I7016"></span>Model : Denotes a function (of a parameter ''X'') whose specification is given in [[Guide:95lrm/RM-A-5-3|A.5.3]]. If ''X'' is a model number of ''T'', the function yields ''X''; otherwise, it yields the value obtained by rounding or truncating ''X'' to either one of the adjacent model numbers of ''T''. <span id="I7017"></span><span id="I7018"></span>Constraint_Error is raised if the resulting model number is outside the safe range of S. A zero result has the sign of ''X'' when S'Signed_Zeros is True. Subject to the constraints given above, the values of S'Model_Mantissa and S'Safe_Last are to be maximized, and the values of S'Model_Emin and S'Safe_First minimized, by the implementation as follows: * First, S'Model_Mantissa is set to the largest value for which values of S'Model_Emin, S'Safe_First, and S'Safe_Last can be chosen so that the implementation satisfies the strict-mode requirements of [[Guide:95lrm/RM-G-2-1|G.2.1]] in terms of the model numbers and safe range induced by these attributes. * Next, S'Model_Emin is set to the smallest value for which values of S'Safe_First and S'Safe_Last can be chosen so that the implementation satisfies the strict-mode requirements of [[Guide:95lrm/RM-G-2-1|G.2.1]] in terms of the model numbers and safe range induced by these attributes and the previously determined value of S'Model_Mantissa. * Finally, S'Safe_First and S'Safe_last are set (in either order) to the smallest and largest values, respectively, for which the implementation satisfies the strict-mode requirements of [[Guide:95lrm/RM-G-2-1|G.2.1]] in terms of the model numbers and safe range induced by these attributes and the previously determined values of S'Model_Mantissa and S'Model_Emin. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G-2-1|Previous]] | [[Guide:95lrm/RM-G-2-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} fa3jtxes5ztnzf6sedamxyn9kqyvff5 Guide:95lrm/RM-G-2-3 4200 1177 4449 2019-05-02T09:03:09Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G-2-2|Previous]] | [[Guide:95lrm/RM-G-2-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: G.2.3 Model of Fixed Point Arithmetic}} In the strict mode, the predefined arithmetic operations of a fixed point type shall satisfy the accuracy requirements specified here and shall avoid or signal overflow in the situations described. == Implementation Requirements == The accuracy requirements for the predefined fixed point arithmetic operations and conversions, and the results of relations on fixed point operands, are given below. The operands of the fixed point adding operators, absolute value, and comparisons have the same type. These operations are required to yield exact results, unless they overflow. Multiplications and divisions are allowed between operands of any two fixed point types; the result has to be (implicitly or explicitly) converted to some other numeric type. For purposes of defining the accuracy rules, the multiplication or division and the conversion are treated as a single operation whose accuracy depends on three types (those of the operands and the result). For decimal fixed point types, the attribute T'Round may be used to imply explicit conversion with rounding (see [[Guide:95lrm/RM-3-5-10|3.5.10]]). When the result type is a floating point type, the accuracy is as given in [[Guide:95lrm/RM-G-2-1|G.2.1]]. <span id="I7019"></span>For some combinations of the operand and result types in the remaining cases, the result is required to belong to a small set of values called the ''perfect result set''; <span id="I7020"></span>for other combinations, it is required merely to belong to a generally larger and implementation-defined set of values called the ''close result set''. When the result type is a decimal fixed point type, the perfect result set contains a single value; thus, operations on decimal types are always fully specified. When one operand of a fixed-fixed multiplication or division is of type ''universal_real'', that operand is not implicitly converted in the usual sense, since the context does not determine a unique target type, but the accuracy of the result of the multiplication or division (i.e., whether the result has to belong to the perfect result set or merely the close result set) depends on the value of the operand of type ''universal_real'' and on the types of the other operand and of the result. For a fixed point multiplication or division whose (exact) mathematical result is ''v'', and for the conversion of a value ''v'' to a fixed point type, the perfect result set and close result set are defined as follows: * If the result type is an ordinary fixed point type with a ''small'' of ''s'', <p><span></span></p> ::* if ''v'' is an integer multiple of ''s'', then the perfect result set contains only the value ''v''; <p><span></span></p> ::* otherwise, it contains the integer multiple of ''s'' just below ''v'' and the integer multiple of ''s'' just above ''v''. <p><span></span></p> :The close result set is an implementation-defined set of consecutive integer multiples of ''s'' containing the perfect result set as a subset. * If the result type is a decimal type with a ''small'' of ''s'', <p><span></span></p> ::* if ''v'' is an integer multiple of ''s'', then the perfect result set contains only the value ''v''; <p><span></span></p> ::* otherwise, if truncation applies then it contains only the integer multiple of ''s'' in the direction toward zero, whereas if rounding applies then it contains only the nearest integer multiple of ''s'' (with ties broken by rounding away from zero). <p><span></span></p> :The close result set is an implementation-defined set of consecutive integer multiples of ''s'' containing the perfect result set as a subset. * If the result type is an integer type, <p><span></span></p> ::* if ''v'' is an integer, then the perfect result set contains only the value ''v''; <p><span></span></p> ::* otherwise, it contains the integer nearest to the value ''v'' (if ''v'' lies equally distant from two consecutive integers, the perfect result set contains the one that is further from zero). <p><span></span></p> :The close result set is an implementation-defined set of consecutive integers containing the perfect result set as a subset. The result of a fixed point multiplication or division shall belong either to the perfect result set or to the close result set, as described below, if overflow does not occur. In the following cases, if the result type is a fixed point type, let ''s'' be its ''small''; otherwise, i.e. when the result type is an integer type, let ''s'' be 1.0. * For a multiplication or division neither of whose operands is of type ''universal_real'', let ''l'' and ''r'' be the ''smalls'' of the left and right operands. For a multiplication, if (''l'' · ''r'') / ''s'' is an integer or the reciprocal of an integer (the ''smalls'' are said to be ''compatible'' in this case), the result shall belong to the perfect result set; otherwise, it belongs to the close result set. For a division, if ''l'' / (''r'' · ''s'') is an integer or the reciprocal of an integer (i.e., the ''smalls'' are compatible), the result shall belong to the perfect result set; otherwise, it belongs to the close result set. * For a multiplication or division having one ''universal_real'' operand with a value of ''v'', note that it is always possible to factor ''v'' as an integer multiple of a ''compatible'' ''small'', but the integer multiple may be ''too big.'' If there exists a factorization in which that multiple is less than some implementation-defined limit, the result shall belong to the perfect result set; otherwise, it belongs to the close result set. A multiplication P * Q of an operand of a fixed point type F by an operand of an integer type I, or vice-versa, and a division P / Q of an operand of a fixed point type F by an operand of an integer type I, are also allowed. In these cases, the result has a type of F; explicit conversion of the result is never required. The accuracy required in these cases is the same as that required for a multiplication F(P * Q) or a division F(P / Q) obtained by interpreting the operand of the integer type to have a fixed point type with a ''small'' of 1.0. The accuracy of the result of a conversion from an integer or fixed point type to a fixed point type, or from a fixed point type to an integer type, is the same as that of a fixed point multiplication of the source value by a fixed point operand having a ''small'' of 1.0 and a value of 1.0, as given by the foregoing rules. The result of a conversion from a floating point type to a fixed point type shall belong to the close result set. The result of a conversion of a ''universal_real'' operand to a fixed point type shall belong to the perfect result set. The possibility of overflow in the result of a predefined arithmetic operation or conversion yielding a result of a fixed point type T is analogous to that for floating point types, except for being related to the base range instead of the safe range. <span id="I7021"></span><span id="I7022"></span>If all of the permitted results belong to the base range of T, then the implementation shall deliver one of the permitted results; otherwise, * <span id="I7023"></span>if T'Machine_Overflows is True, the implementation shall either deliver one of the permitted results or raise Constraint_Error; * if T'Machine_Overflows is False, the result is implementation defined. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G-2-2|Previous]] | [[Guide:95lrm/RM-G-2-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 4d8u2d2lnvjpv1s2xjnn0iwq039fa42 Guide:95lrm/RM-G-2-4 4200 1178 4450 2019-05-02T09:04:34Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G-2-3|Previous]] | [[Guide:95lrm/RM-G-2-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: G.2.4 Accuracy Requirements for the Elementary Functions}} In the strict mode, the performance of Numerics.Generic_Elementary_Functions shall be as specified here. == Implementation Requirements == <span id="I7024"></span><span id="I7025"></span>When an exception is not raised, the result of evaluating a function in an instance ''EF'' of Numerics.Generic_Elementary_Functions belongs to a ''result interval'', defined as the smallest model interval of ''EF''.Float_Type that contains all the values of the form ''f'' · (1.0 + ''d''), where ''f'' is the exact value of the corresponding mathematical function at the given parameter values, ''d'' is a real number, and |''d''| is less than or equal to the function's ''maximum relative error''. <span id="I7026"></span><span id="I7027"></span>The function delivers a value that belongs to the result interval when both of its bounds belong to the safe range of ''EF''.Float_Type; otherwise, * <span id="I7028"></span>if ''EF''.Float_Type'Machine_Overflows is True, the function either delivers a value that belongs to the result interval or raises Constraint_Error, signaling overflow; * if ''EF''.Float_Type'Machine_Overflows is False, the result is implementation defined. The maximum relative error exhibited by each function is as follows: * 2.0 · ''EF''.Float_Type'Model_Epsilon, in the case of the Sqrt, Sin, and Cos functions; * 4.0 · ''EF''.Float_Type'Model_Epsilon, in the case of the Log, Exp, Tan, Cot, and inverse trigonometric functions; and * 8.0 · ''EF''.Float_Type'Model_Epsilon, in the case of the forward and inverse hyperbolic functions. The maximum relative error exhibited by the exponentiation operator, which depends on the values of the operands, is (4.0 + |Right · log(Left)| / 32.0) · ''EF''.Float_Type'Model_Epsilon. The maximum relative error given above applies throughout the domain of the forward trigonometric functions when the Cycle parameter is specified. <span id="I7029"></span>When the Cycle parameter is omitted, the maximum relative error given above applies only when the absolute value of the angle parameter X is less than or equal to some implementation-defined ''angle threshold'', which shall be at least ''EF''.Float_Type'Machine_Radix <sup>''Floor''(''EF''.Float_Type'Machine_Mantissa/2)</sup>. Beyond the angle threshold, the accuracy of the forward trigonometric functions is implementation defined. The prescribed results specified in [[Guide:95lrm/RM-A-5-1|A.5.1]] for certain functions at particular parameter values take precedence over the maximum relative error bounds; effectively, they narrow to a single value the result interval allowed by the maximum relative error bounds. Additional rules with a similar effect are given by the table below for the inverse trigonometric functions, at particular parameter values for which the mathematical result is possibly not a model number of ''EF''.Float_Type (or is, indeed, even transcendental). In each table entry, the values of the parameters are such that the result lies on the axis between two quadrants; the corresponding accuracy rule, which takes precedence over the maximum relative error bounds, is that the result interval is the model interval of ''EF''.Float_Type associated with the exact mathematical result given in the table. ''This paragraph was deleted.'' The last line of the table is meant to apply when ''EF''.Float_Type'Signed_Zeros is False; the two lines just above it, when ''EF''.Float_Type'Signed_Zeros is True and the parameter Y has a zero value with the indicated sign. The amount by which the result of an inverse trigonometric function is allowed to spill over into a quadrant adjacent to the one corresponding to the principal branch, as given in [[Guide:95lrm/RM-A-5-1|A.5.1]], is limited. The rule is that the result belongs to the smallest model interval of ''EF''.Float_Type that contains both boundaries of the quadrant corresponding to the principal branch. This rule also takes precedence over the maximum relative error bounds, effectively narrowing the result interval allowed by them. <div> {| class="wikitable" |+ '''Tightly Approximated Elementary Function Results''' ! '''Function''' ! '''Value of X''' ! '''Value of Y''' ! '''Exact Result when Cycle Specified''' ! '''Exact Result when Cycle Omitted''' |- | Arcsin | 1.0 | n.a. | Cycle/4.0 | PI/2.0 |- | Arcsin | -1.0 | n.a. | -Cycle/4.0 | -PI/2.0 |- | Arccos | 0.0 | n.a. | Cycle/4.0 | PI/2.0 |- | Arccos | -1.0 | n.a. | Cycle/2.0 | PI |- | Arctan and Arccot | 0.0 | positive | Cycle/4.0 | PI/2.0 |- | Arctan and Arccot | 0.0 | negative | -Cycle/4.0 | -PI/2.0 |- | Arctan and Arccot | negative | +0.0 | Cycle/2.0 | PI |- | Arctan and Arccot | negative | -0.0 | -Cycle/2.0 | -PI |- | Arctan and Arccot | negative | 0.0 | Cycle/2.0 | PI |} </div> Finally, the following specifications also take precedence over the maximum relative error bounds: * The absolute value of the result of the Sin, Cos, and Tanh functions never exceeds one. * The absolute value of the result of the Coth function is never less than one. * The result of the Cosh function is never less than one. == Implementation Advice == The versions of the forward trigonometric functions without a Cycle parameter should not be implemented by calling the corresponding version with a Cycle parameter of 2.0*Numerics.Pi, since this will not provide the required accuracy in some portions of the domain. For the same reason, the version of Log without a Base parameter should not be implemented by calling the corresponding version with a Base parameter of Numerics.e. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G-2-3|Previous]] | [[Guide:95lrm/RM-G-2-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} er0a2m5ibofzpixochktarscjmk5px6 Guide:95lrm/RM-G-2-5 4200 1179 4451 2019-04-29T15:48:27Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G-2-4|Previous]] | [[Guide:95lrm/RM-G-2-6|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: G.2.5 Performance Requirements for Random Number Generation}} In the strict mode, the performance of Numerics.Float_Random and Numerics.Discrete_Random shall be as specified here. == Implementation Requirements == Two different calls to the time-dependent Reset procedure shall reset the generator to different states, provided that the calls are separated in time by at least one second and not more than fifty years. The implementation's representations of generator states and its algorithms for generating random numbers shall yield a period of at least 2<sup>31</sup>-2; much longer periods are desirable but not required. The implementations of Numerics.Float_Random.Random and Numerics.Discrete_Random.Random shall pass at least 85% of the individual trials in a suite of statistical tests. For Numerics.Float_Random, the tests are applied directly to the floating point values generated (i.e., they are not converted to integers first), while for Numerics.Discrete_Random they are applied to the generated values of various discrete types. Each test suite performs 6 different tests, with each test repeated 10 times, yielding a total of 60 individual trials. An individual trial is deemed to pass if the chi-square value (or other statistic) calculated for the observed counts or distribution falls within the range of values corresponding to the 2.5 and 97.5 percentage points for the relevant degrees of freedom (i.e., it shall be neither too high nor too low). For the purpose of determining the degrees of freedom, measurement categories are combined whenever the expected counts are fewer than 5. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G-2-4|Previous]] | [[Guide:95lrm/RM-G-2-6|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} khn17iwha3tfipnfk28o0ma13fgh4x6 Guide:95lrm/RM-G-2-6 4200 1180 4452 2019-05-02T09:05:24Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G-2-5|Previous]] | [[Guide:95lrm/RM-H|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: G.2.6 Accuracy Requirements for Complex Arithmetic}} In the strict mode, the performance of Numerics.Generic_Complex_Types and Numerics.Generic_Complex_Elementary_Functions shall be as specified here. == Implementation Requirements == When an exception is not raised, the result of evaluating a real function of an instance ''CT'' of Numerics.Generic_Complex_Types (i.e., a function that yields a value of subtype ''CT''.Real'Base or ''CT''.Imaginary) belongs to a result interval defined as for a real elementary function (see [[Guide:95lrm/RM-G-2-4|G.2.4]]). <span id="I7030"></span>When an exception is not raised, each component of the result of evaluating a complex function of such an instance, or of an instance of Numerics.Generic_Complex_Elementary_Functions obtained by instantiating the latter with ''CT'' (i.e., a function that yields a value of subtype ''CT''.Complex), also belongs to a ''result interval''. The result intervals for the components of the result are either defined by a ''maximum relative error'' bound or by a ''maximum box error'' bound. <span id="I7031"></span>When the result interval for the real (resp., imaginary) component is defined by maximum relative error, it is defined as for that of a real function, relative to the exact value of the real (resp., imaginary) part of the result of the corresponding mathematical function. <span id="I7032"></span>When defined by maximum box error, the result interval for a component of the result is the smallest model interval of ''CT''.Real that contains all the values of the corresponding part of ''f'' · (1.0 + ''d''), where ''f'' is the exact complex value of the corresponding mathematical function at the given parameter values, ''d'' is complex, and |''d''| is less than or equal to the given maximum box error. <span id="I7033"></span><span id="I7034"></span>The function delivers a value that belongs to the result interval (or a value both of whose components belong to their respective result intervals) when both bounds of the result interval(s) belong to the safe range of ''CT''.Real; otherwise, * <span id="I7035"></span>if ''CT''.Real'Machine_Overflows is True, the function either delivers a value that belongs to the result interval (or a value both of whose components belong to their respective result intervals) or raises Constraint_Error, signaling overflow; * if ''CT''.Real'Machine_Overflows is False, the result is implementation defined. The error bounds for particular complex functions are tabulated below. In the table, the error bound is given as the coefficient of ''CT''.Real'Model_Epsilon. ''This paragraph was deleted.'' The maximum relative error given above applies throughout the domain of the Compose_From_Polar function when the Cycle parameter is specified. When the Cycle parameter is omitted, the maximum relative error applies only when the absolute value of the parameter Argument is less than or equal to the angle threshold (see [[Guide:95lrm/RM-G-2-4|G.2.4]]). For the Exp function, and for the forward hyperbolic (resp., trigonometric) functions, the maximum relative error given above likewise applies only when the absolute value of the imaginary (resp., real) component of the parameter X (or the absolute value of the parameter itself, in the case of the Exp function with a parameter of pure-imaginary type) is less than or equal to the angle threshold. For larger angles, the accuracy is implementation defined. <div> {| class="wikitable" |+ '''Error Bounds for Particular Complex Functions''' ! '''Function or Operator''' ! '''Nature of Result''' ! '''Nature of Bound''' ! '''Error Bound''' |- | Modulus | real | max. rel. error | 3.0 |- | Argument | real | max. rel. error | 4.0 |- | Compose_From_Polar | complex | max. rel. error | 3.0 |- | "*" (both operands complex) | complex | max. box error | 5.0 |- | "/" (right operand complex) | complex | max. box error | 13.0 |- | Sqrt | complex | max. rel. error | 6.0 |- | Log | complex | max. box error | 13.0 |- | Exp (complex parameter) | complex | max. rel. error | 7.0 |- | Exp (imaginary parameter) | complex | max. rel. error | 2.0 |- | Sin, Cos, Sinh, and Cosh | complex | max. rel. error | 11.0 |- | Tan, Cot, Tanh, and Coth | complex | max. rel. error | 35.0 |- | inverse trigonometric | complex | max. rel. error | 14.0 |- | inverse hyperbolic | complex | max. rel. error | 14.0 |} </div> The prescribed results specified in [[Guide:95lrm/RM-G-1-2|G.1.2]] for certain functions at particular parameter values take precedence over the error bounds; effectively, they narrow to a single value the result interval allowed by the error bounds for a component of the result. Additional rules with a similar effect are given below for certain inverse trigonometric and inverse hyperbolic functions, at particular parameter values for which a component of the mathematical result is transcendental. In each case, the accuracy rule, which takes precedence over the error bounds, is that the result interval for the stated result component is the model interval of ''CT''.Real associated with the component's exact mathematical value. The cases in question are as follows: * When the parameter X has the value zero, the real (resp., imaginary) component of the result of the Arccot (resp., Arccoth) function is in the model interval of ''CT''.Real associated with the value PI/2.0. * When the parameter X has the value one, the real component of the result of the Arcsin function is in the model interval of ''CT''.Real associated with the value PI/2.0. * When the parameter X has the value -1.0, the real component of the result of the Arcsin (resp., Arccos) function is in the model interval of ''CT''.Real associated with the value -PI/2.0 (resp., PI). The amount by which a component of the result of an inverse trigonometric or inverse hyperbolic function is allowed to spill over into a quadrant adjacent to the one corresponding to the principal branch, as given in [[Guide:95lrm/RM-G-1-2|G.1.2]], is limited. The rule is that the result belongs to the smallest model interval of ''CT''.Real that contains both boundaries of the quadrant corresponding to the principal branch. This rule also takes precedence to the maximum error bounds, effectively narrowing the result interval allowed by them. Finally, the results allowed by the error bounds are narrowed by one further rule: The absolute value of each component of the result of the Exp function, for a pure-imaginary parameter, never exceeds one. == Implementation Advice == The version of the Compose_From_Polar function without a Cycle parameter should not be implemented by calling the corresponding version with a Cycle parameter of 2.0*Numerics.Pi, since this will not provide the required accuracy in some portions of the domain. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G-2-5|Previous]] | [[Guide:95lrm/RM-H|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} thp8jrdv4rhauc2216yiynizv0hssj6 Guide:95lrm/RM-H 4200 1181 4453 2019-05-02T09:06:13Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G-2-6|Previous]] | [[Guide:95lrm/RM-H-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Annex H. Safety and Security}} <div>(normative)</div> <span id="I7036"></span><span id="I7037"></span>This Annex addresses requirements for systems that are safety critical or have security constraints. It provides facilities and specifies documentation requirements that relate to several needs: * Understanding program execution; * Reviewing object code; * Restricting language constructs whose usage might complicate the demonstration of program correctness <div> Execution understandability is supported by pragma Normalize_Scalars, and also by requirements for the implementation to document the effect of a program in the presence of a bounded error or where the language rules leave the effect unspecified. <span id="I7038"></span> </div> The pragmas Reviewable and Restrictions relate to the other requirements addressed by this Annex. == Notes == 1  The <span id="I7039"></span><span id="I7040"></span>Valid attribute (see [[Guide:95lrm/RM-13-9-2|13.9.2]]) is also useful in addressing these needs, to avoid problems that could otherwise arise from scalars that have values outside their declared range constraints. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-G-2-6|Previous]] | [[Guide:95lrm/RM-H-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 434prpoibwgwhsuqr9n82ha780ay2pn Guide:95lrm/RM-H-1 4200 1182 4454 2019-05-02T09:06:46Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-H|Previous]] | [[Guide:95lrm/RM-H-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: H.1 Pragma Normalize_Scalars}} This pragma ensures that an otherwise uninitialized scalar object is set to a predictable value, but out of range if possible. == Syntax == The form of a pragma Normalize_Scalars is as follows: <p><span></span></p> '''pragma''' <span id="I7041"></span><span id="I7042"></span>Normalize_Scalars; == Post-Compilation Rules == <span id="I7043"></span><span id="I7044"></span>Pragma Normalize_Scalars is a configuration pragma. It applies to all compilation_units included in a partition. == Documentation Requirements == If a pragma Normalize_Scalars applies, the implementation shall document the implicit initial value for scalar subtypes, and shall identify each case in which such a value is used and is not an invalid representation. == Implementation Advice == Whenever possible, the implicit initial value for a scalar subtype should be an invalid representation (see [[Guide:95lrm/RM-13-9-1|13.9.1]]). == Notes == 2  The initialization requirement applies to uninitialized scalar objects that are subcomponents of composite objects, to allocated objects, and to stand-alone objects. It also applies to scalar '''out''' parameters. Scalar subcomponents of composite '''out''' parameters are initialized to the corresponding part of the actual, by virtue of [[Guide:95lrm/RM-6-4-1|6.4.1]]. 3  The initialization requirement does not apply to a scalar for which pragma Import has been specified, since initialization of an imported object is performed solely by the foreign language environment (see [[Guide:95lrm/RM-B-1|B.1]]). 4  The use of pragma Normalize_Scalars in conjunction with Pragma Restrictions(No_Exceptions) may result in erroneous execution (see [[Guide:95lrm/RM-H-4|H.4]]). </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-H|Previous]] | [[Guide:95lrm/RM-H-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 9tbbsmvqogqor8qhnteeswnktyau1kk Guide:95lrm/RM-H-2 4200 1183 4455 2019-04-29T15:48:27Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-H-1|Previous]] | [[Guide:95lrm/RM-H-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: H.2 Documentation of Implementation Decisions}} == Documentation Requirements == <span id="I7045"></span>The implementation shall document the range of effects for each situation that the language rules identify as either a bounded error or as having an unspecified effect. If the implementation can constrain the effects of erroneous execution for a given construct, then it shall document such constraints. The documentation might be provided either independently of any compilation unit or partition, or as part of an annotated listing for a given unit or partition. See also [[Guide:95lrm/RM-1-1-3|1.1.3]], and [[Guide:95lrm/RM-1-1-2|1.1.2]]. == Notes == 5  Among the situations to be documented are the conventions chosen for parameter passing, the methods used for the management of run-time storage, and the method used to evaluate numeric expressions if this involves extended range or extra precision. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-H-1|Previous]] | [[Guide:95lrm/RM-H-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} g0c4uw2ulkda7ktqwl4gu57qtf3npxt Guide:95lrm/RM-H-3 4200 1184 4456 2019-04-29T15:48:27Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-H-2|Previous]] | [[Guide:95lrm/RM-H-3-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: H.3 Reviewable Object Code}} Object code review and validation are supported by pragmas Reviewable and Inspection_Point. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-H-2|Previous]] | [[Guide:95lrm/RM-H-3-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} q0niu3x2zh2r83d4xz88e7pcsad7uwx Guide:95lrm/RM-H-3-1 4200 1185 4457 2019-05-02T09:08:51Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-H-3|Previous]] | [[Guide:95lrm/RM-H-3-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: H.3.1 Pragma Reviewable}} This pragma directs the implementation to provide information to facilitate analysis and review of a program's object code, in particular to allow determination of execution time and storage usage and to identify the correspondence between the source and object programs. == Syntax == The form of a pragma Reviewable is as follows: <p><span></span></p> '''pragma''' <span id="I7046"></span><span id="I7047"></span>Reviewable; == Post-Compilation Rules == <span id="I7048"></span><span id="I7049"></span>Pragma Reviewable is a configuration pragma. It applies to all compilation_units included in a partition. == Implementation Requirements == The implementation shall provide the following information for any compilation unit to which such a pragma applies: * Where compiler-generated run-time checks remain; * An identification of any construct with a language-defined check that is recognized prior to run time as certain to fail if executed (even if the generation of run-time checks has been suppressed); * For each reference to a scalar object, an identification of the reference as either ''known to be initialized,'' or ''possibly uninitialized,'' independent of whether pragma Normalize_Scalars applies; * Where run-time support routines are implicitly invoked; * An object code listing, including: <p><span></span></p> ::* Machine instructions, with relative offsets; <p><span></span></p> ::* Where each data object is stored during its lifetime; <p><span></span></p> ::* Correspondence with the source program, including an identification of the code produced per declaration and per statement. * An identification of each construct for which the implementation detects the possibility of erroneous execution; * For each subprogram, block, task, or other construct implemented by reserving and subsequently freeing an area on a run-time stack, an identification of the length of the fixed-size portion of the area and an indication of whether the non-fixed size portion is reserved on the stack or in a dynamically-managed storage region. The implementation shall provide the following information for any partition to which the pragma applies: * An object code listing of the entire partition, including initialization and finalization code as well as run-time system components, and with an identification of those instructions and data that will be relocated at load time; * A description of the run-time model relevant to the partition. <div> The implementation shall provide control- and data-flow information, both within each compilation unit and across the compilation units of the partition. </div> == Implementation Advice == The implementation should provide the above information in both a human-readable and machine-readable form, and should document the latter so as to ease further processing by automated tools. Object code listings should be provided both in a symbolic format and also in an appropriate numeric format (such as hexadecimal or octal). == Notes == 6  The order of elaboration of library units will be documented even in the absence of pragma Reviewable (see [[Guide:95lrm/RM-10-2|10.2]]). </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-H-3|Previous]] | [[Guide:95lrm/RM-H-3-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 78zbcfqehiwzd4rkj7u6mzo3ashjrrz Guide:95lrm/RM-H-3-2 4200 1186 4458 2019-05-02T09:09:26Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-H-3-1|Previous]] | [[Guide:95lrm/RM-H-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: H.3.2 Pragma Inspection_Point}} An occurrence of a pragma Inspection_Point identifies a set of objects each of whose values is to be available at the point(s) during program execution corresponding to the position of the pragma in the compilation unit. The purpose of such a pragma is to facilitate code validation. == Syntax == The form of a pragma Inspection_Point is as follows: <p><span></span></p> '''pragma''' <span id="I7050"></span><span id="I7051"></span>Inspection_Point[(''object_''<span id="I7052"></span>name {, ''object_''<span id="I7053"></span>name})]; == Legality Rules == A pragma Inspection_Point is allowed wherever a declarative_item or statement is allowed. Each ''object_''name shall statically denote the declaration of an object. == Static Semantics == <span id="I7054"></span>An ''inspection point'' is a point in the object code corresponding to the occurrence of a pragma Inspection_Point in the compilation unit. <span id="I7055"></span>An object is ''inspectable'' at an inspection point if the corresponding pragma Inspection_Point either has an argument denoting that object, or has no arguments and the object is visible at the inspection point. == Dynamic Semantics == Execution of a pragma Inspection_Point has no effect. == Implementation Requirements == Reaching an inspection point is an external interaction with respect to the values of the inspectable objects at that point (see [[Guide:95lrm/RM-1-1-3|1.1.3]]). == Documentation Requirements == For each inspection point, the implementation shall identify a mapping between each inspectable object and the machine resources (such as memory locations or registers) from which the object's value can be obtained. == Notes == 7  The implementation is not allowed to perform ''dead store elimination'' on the last assignment to a variable prior to a point where the variable is inspectable. Thus an inspection point has the effect of an implicit reference to each of its inspectable objects. 8  Inspection points are useful in maintaining a correspondence between the state of the program in source code terms, and the machine state during the program's execution. Assertions about the values of program objects can be tested in machine terms at inspection points. Object code between inspection points can be processed by automated tools to verify programs mechanically. 9  The identification of the mapping from source program objects to machine resources is allowed to be in the form of an annotated object listing, in human-readable or tool-processable form. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-H-3-1|Previous]] | [[Guide:95lrm/RM-H-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} kuhj1v6pa0ni3f69qce7ri0zk9795gq Guide:95lrm/RM-H-4 4200 1187 4459 2019-05-02T09:10:27Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-H-3-2|Previous]] | [[Guide:95lrm/RM-J|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: H.4 Safety and Security Restrictions}} This clause defines restrictions that can be used with pragma Restrictions (see [[Guide:95lrm/RM-13-12|13.12]]); these facilitate the demonstration of program correctness by allowing tailored versions of the run-time system. == Static Semantics == The following restrictions, the same as in [[Guide:95lrm/RM-D-7|D.7]], apply in this Annex: No_Task_Hierarchy, No_Abort_Statement, No_Implicit_Heap_Allocation, Max_Task_Entries is 0, Max_Asynchronous_Select_Nesting is 0, and Max_Tasks is 0. The last three restrictions are checked prior to program execution. The following additional restrictions apply in this Annex. '''Tasking-related restriction:''' ; <span id="I7056"></span>No_Protected_Types : There are no declarations of protected types or protected objects. '''Memory-management related restrictions:''' ; <span id="I7057"></span>No_Allocators : There are no occurrences of an allocator. ;   <span id="I7058"></span>No_Local_Allocators : Allocators are prohibited in subprograms, generic subprograms, tasks, and entry bodies. ; <span id="I7059"></span>No_Unchecked_Deallocation : Semantic dependence on Unchecked_Deallocation is not allowed. ;  Immediate_Reclamation : Except for storage occupied by objects created by allocators and not deallocated via unchecked deallocation, any storage reserved at run time for an object is immediately reclaimed when the object no longer exists. <span id="I7060"></span> '''Exception-related restriction:''' ;  <span id="I7061"></span>No_Exceptions : Raise_statements and exception_handlers are not allowed. No language-defined run-time checks are generated; however, a run-time check performed automatically by the hardware is permitted. '''Other restrictions:''' ;  <span id="I7062"></span>No_Floating_Point : Uses of predefined floating point types and operations, and declarations of new floating point types, are not allowed. ;  <span id="I7063"></span>No_Fixed_Point : Uses of predefined fixed point types and operations, and declarations of new fixed point types, are not allowed. ;  <span id="I7064"></span>No_Unchecked_Conversion : Semantic dependence on the predefined generic Unchecked_Conversion is not allowed. ;  No_Access_Subprograms : The declaration of access-to-subprogram types is not allowed. <span id="I7065"></span> ;  <span id="I7066"></span>No_Unchecked_Access : The <span id="I7067"></span><span id="I7068"></span>Unchecked_Access attribute is not allowed. ;  <span id="I7069"></span>No_Dispatch : Occurrences of T'Class are not allowed, for any (tagged) subtype T. ;  <span id="I7070"></span>No_IO : Semantic dependence on any of the library units Sequential_IO, Direct_IO, Text_IO, Wide_Text_IO, or Stream_IO is not allowed. ;  <span id="I7071"></span>No_Delay : Delay_Statements and semantic dependence on package Calendar are not allowed. ;  <span id="I7072"></span>No_Recursion : As part of the execution of a subprogram, the same subprogram is not invoked. ;  <span id="I7073"></span>No_Reentrancy : During the execution of a subprogram by a task, no other task invokes the same subprogram. == Implementation Requirements == If an implementation supports pragma Restrictions for a particular argument, then except for the restrictions No_Unchecked_Deallocation, No_Unchecked_Conversion, No_Access_Subprograms, and No_Unchecked_Access, the associated restriction applies to the run-time system. == Documentation Requirements == If a pragma Restrictions(No_Exceptions) is specified, the implementation shall document the effects of all constructs where language-defined checks are still performed automatically (for example, an overflow check performed by the processor). == Erroneous Execution == <span id="I7074"></span>Program execution is erroneous if pragma Restrictions(No_Exceptions) has been specified and the conditions arise under which a generated language-defined run-time check would fail. <span id="I7075"></span>Program execution is erroneous if pragma Restrictions(No_Recursion) has been specified and a subprogram is invoked as part of its own execution, or if pragma Restrictions(No_Reentrancy) has been specified and during the execution of a subprogram by a task, another task invokes the same subprogram. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-H-3-2|Previous]] | [[Guide:95lrm/RM-J|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} boz8fsiknlmgcidqtaolh5lzza3d91g Guide:95lrm/RM-J 4200 1188 4460 2019-05-02T09:10:59Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-H-4|Previous]] | [[Guide:95lrm/RM-J-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Annex J. Obsolescent Features}} <div> (normative) </div> <span id="I7076"></span>This Annex contains descriptions of features of the language whose functionality is largely redundant with other features defined by this International Standard. Use of these features is not recommended in newly written programs. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-H-4|Previous]] | [[Guide:95lrm/RM-J-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} bn5p61orwrvjua9ws5ybwxfj43jmi2t Guide:95lrm/RM-J-1 4200 1189 4461 2019-05-02T09:12:15Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-J|Previous]] | [[Guide:95lrm/RM-J-2|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: J.1 Renamings of Ada 83 Library Units}} == Static Semantics == The following library_unit_renaming_declarations exist: <p><syntaxhighlight lang="Ada"> with Ada.Unchecked_Conversion; generic function Unchecked_Conversion renames Ada.Unchecked_Conversion;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> with Ada.Unchecked_Deallocation; generic procedure Unchecked_Deallocation renames Ada.Unchecked_Deallocation;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> with Ada.Sequential_IO; generic package Sequential_IO renames Ada.Sequential_IO;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> with Ada.Direct_IO; generic package Direct_IO renames Ada.Direct_IO;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> with Ada.Text_IO; package Text_IO renames Ada.Text_IO;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> with Ada.IO_Exceptions; package IO_Exceptions renames Ada.IO_Exceptions;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> with Ada.Calendar; package Calendar renames Ada.Calendar;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> with System.Machine_Code; package Machine_Code renames System.Machine_Code; -- If supported.</syntaxhighlight></p> == Implementation Requirements == The implementation shall allow the user to replace these renamings. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-J|Previous]] | [[Guide:95lrm/RM-J-2|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} fkzto4qvgloh4jkusebeq9lkvihuw44 Guide:95lrm/RM-J-2 4200 1190 4462 2019-04-29T23:55:21Z imported>WikiVisor 0 Text replacement - "&quot;" to """ wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-J-1|Previous]] | [[Guide:95lrm/RM-J-3|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: J.2 Allowed Replacements of Characters}} == Syntax == The following replacements are allowed for the vertical line, number sign, and quotation mark characters: * A vertical line character (|) can be replaced by an exclamation mark (!) where used as a delimiter. * The number sign characters (#) of a based_literal can be replaced by colons (:) provided that the replacement is done for both occurrences. * The quotation marks (") used as string brackets at both ends of a string literal can be replaced by percent signs (%) provided that the enclosed sequence of characters contains no quotation mark, and provided that both string brackets are replaced. Any percent sign within the sequence of characters shall then be doubled and each such doubled percent sign is interpreted as a single percent sign character value. These replacements do not change the meaning of the program. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-J-1|Previous]] | [[Guide:95lrm/RM-J-3|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} ru3r6mm8vpvrmvhstrx7id152ou2muw Guide:95lrm/RM-J-3 4200 1191 4463 2019-05-02T09:12:55Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-J-2|Previous]] | [[Guide:95lrm/RM-J-4|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: J.3 Reduced Accuracy Subtypes}} A digits_constraint may be used to define a floating point subtype with a new value for its requested decimal precision, as reflected by its Digits attribute. Similarly, a delta_constraint may be used to define an ordinary fixed point subtype with a new value for its ''delta'', as reflected by its Delta attribute. == Syntax == <p><span></span></p> delta_constraint<span id="I7077"></span> ::= '''delta''' ''static_''<span id="I7078"></span>expression [<span id="I7079"></span>range_constraint] == Name Resolution Rules == <span id="I7080"></span>The expression of a delta_constraint is expected to be of any real type. == Legality Rules == The expression of a delta_constraint shall be static. For a subtype_indication with a delta_constraint, the subtype_mark shall denote an ordinary fixed point subtype. <span id="I7081"></span>For a subtype_indication with a digits_constraint, the subtype_mark shall denote either a decimal fixed point subtype or a floating point subtype (notwithstanding the rule given in [[Guide:95lrm/RM-3-5-9|3.5.9]] that only allows a decimal fixed point subtype). == Static Semantics == A subtype_indication with a subtype_mark that denotes an ordinary fixed point subtype and a delta_constraint defines an ordinary fixed point subtype with a ''delta'' given by the value of the expression of the delta_constraint. If the delta_constraint includes a range_constraint, then the ordinary fixed point subtype is constrained by the range_constraint. A subtype_indication with a subtype_mark that denotes a floating point subtype and a digits_constraint defines a floating point subtype with a requested decimal precision (as reflected by its Digits attribute) given by the value of the expression of the digits_constraint. If the digits_constraint includes a range_constraint, then the floating point subtype is constrained by the range_constraint. == Dynamic Semantics == <span id="I7082"></span>A delta_constraint is ''compatible'' with an ordinary fixed point subtype if the value of the expression is no less than the ''delta'' of the subtype, and the range_constraint, if any, is compatible with the subtype. <span id="I7083"></span>A digits_constraint is ''compatible'' with a floating point subtype if the value of the expression is no greater than the requested decimal precision of the subtype, and the range_constraint, if any, is compatible with the subtype. <span id="I7084"></span>The elaboration of a delta_constraint consists of the elaboration of the range_constraint, if any. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-J-2|Previous]] | [[Guide:95lrm/RM-J-4|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} ima8svut7ximyknla94c8qw2eiz0l3z Guide:95lrm/RM-J-4 4200 1192 4464 2019-04-29T15:48:28Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-J-3|Previous]] | [[Guide:95lrm/RM-J-5|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: J.4 The Constrained Attribute}} == Static Semantics == For every private subtype S, the following attribute is defined: ; S'<span id="I7085"></span><span id="I7086"></span>Constrained : Yields the value False if S denotes an unconstrained nonformal private subtype with discriminants; also yields the value False if S denotes a generic formal private subtype, and the associated actual subtype is either an unconstrained subtype with discriminants or an unconstrained array subtype; yields the value True otherwise. The value of this attribute is of the predefined subtype Boolean. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-J-3|Previous]] | [[Guide:95lrm/RM-J-5|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} jviiqny42j6niznqbpzj6rbbq34v1a3 Guide:95lrm/RM-J-5 4200 1193 4465 2019-05-02T09:14:51Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-J-4|Previous]] | [[Guide:95lrm/RM-J-6|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: J.5 ASCII}} == Static Semantics == The following declaration exists in the declaration of package Standard: <p><syntaxhighlight lang="Ada"> package ASCII is</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   --  Control characters:</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">    NUL   : constant Character := nul;              SOH   : constant Character := soh;  STX   : constant Character := stx;              ETX   : constant Character := etx;   EOT   : constant Character := eot;              ENQ   : constant Character := enq;   ACK   : constant Character := ack;              BEL   : constant Character := bel;   BS    : constant Character := bs;               HT    : constant Character := ht;   LF    : constant Character := lf;               VT    : constant Character := vt;   FF    : constant Character := ff;               CR    : constant Character := cr;   SO    : constant Character := so;               SI    : constant Character := si;   DLE   : constant Character := dle;              DC1   : constant Character := dc1;   DC2   : constant Character := dc2;              DC3   : constant Character := dc3;   DC4   : constant Character := dc4;              NAK   : constant Character := nak;   SYN   : constant Character := syn;              ETB   : constant Character := etb;   CAN   : constant Character := can;              EM    : constant Character := em;   SUB   : constant Character := sub;              ESC   : constant Character := esc;   FS    : constant Character := fs;               GS    : constant Character := gs;   RS    : constant Character := rs;               US    : constant Character := us;   DEL   : constant Character := del;</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   -- Other characters:</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   Exclam   : constant Character:= '!';    Quotation : constant Character:= '"';  Sharp    : constant Character:= '#';            Dollar    : constant Character:= '$';  Percent  : constant Character:= '%';            Ampersand : constant Character:= '&';   Colon    : constant Character:= ':';            Semicolon : constant Character:= ';';   Query    : constant Character:= '?';            At_Sign   : constant Character:= '@';   L_Bracket: constant Character:= '[';            Back_Slash: constant Character:= '\';   R_Bracket: constant Character:= ']';            Circumflex: constant Character:= '^';   Underline: constant Character:= '_';            Grave     : constant Character:= '`';   L_Brace  : constant Character:= '{';            Bar       : constant Character:= '|';   R_Brace  : constant Character:= '}';            Tilde     : constant Character:= '~'; </syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   -- Lower case letters:</syntaxhighlight></p> <p><syntaxhighlight lang="Ada">   LC_A: constant Character:= 'a';   ...   LC_Z: constant Character:= 'z';</syntaxhighlight></p> <p><syntaxhighlight lang="Ada"> end ASCII;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-J-4|Previous]] | [[Guide:95lrm/RM-J-6|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} pbd49sc6batcmtmjh3siv5bwf36pk0y Guide:95lrm/RM-J-6 4200 1194 4466 2019-04-29T15:48:28Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-J-5|Previous]] | [[Guide:95lrm/RM-J-7|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: J.6 Numeric_Error}} == Static Semantics == The following declaration exists in the declaration of package Standard: <p><syntaxhighlight lang="Ada">Numeric_Error : exception renames Constraint_Error;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-J-5|Previous]] | [[Guide:95lrm/RM-J-7|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} l2xvetx2ayaj3ewy9ej6q2pho2avjqt Guide:95lrm/RM-J-7 4200 1195 4467 2019-05-02T09:15:45Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-J-6|Previous]] | [[Guide:95lrm/RM-J-7-1|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: J.7 At Clauses}} == Syntax == <p><span></span></p> at_clause<span id="I7087"></span> ::= '''for''' <span id="I7088"></span>direct_name '''use''' '''at''' <span id="I7089"></span>expression; == Static Semantics == An at_clause of the form ''for ''x'' use at ''y'';'' is equivalent to an attribute_definition_clause of the form ''for ''x'''Address use ''y'';''. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-J-6|Previous]] | [[Guide:95lrm/RM-J-7-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} mpluwvojfgployotjz8q1d4nut75dgb Guide:95lrm/RM-J-7-1 4200 1196 4468 2019-05-02T09:16:32Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-J-7|Previous]] | [[Guide:95lrm/RM-J-8|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: J.7.1 Interrupt Entries}} Implementations are permitted to allow the attachment of task entries to interrupts via the address clause. Such an entry is referred to as an ''interrupt entry''. The address of the task entry corresponds to a hardware interrupt in an implementation-defined manner. (See Ada.Interrupts.Reference in [[Guide:95lrm/RM-C-3-2|C.3.2]].) == Static Semantics == The following attribute is defined: For any task entry X: ; <span id="I7090"></span>X'<span id="I7091"></span><span id="I7092"></span>Address : For a task entry whose address is specified (an ''interrupt entry''), the value refers to the corresponding hardware interrupt. For such an entry, as for any other task entry, the meaning of this value is implementation defined. The value of this attribute is of the type of the subtype System.Address. <span id="I7093"></span>Address may be specified for single entries via an attribute_definition_clause. == Dynamic Semantics == <span id="I7094"></span>As part of the initialization of a task object, the address clause for an interrupt entry is elaborated, which evaluates the expression of the address clause. A check is made that the address specified is associated with some interrupt to which a task entry may be attached. <span id="I7095"></span>If this check fails, Program_Error is raised. Otherwise, the interrupt entry is attached to the interrupt associated with the specified address. <span id="I7096"></span>Upon finalization of the task object, the interrupt entry, if any, is detached from the corresponding interrupt and the default treatment is restored. While an interrupt entry is attached to an interrupt, the interrupt is reserved (see [[Guide:95lrm/RM-C-3|C.3]]). An interrupt delivered to a task entry acts as a call to the entry issued by a hardware task whose priority is in the System.Interrupt_Priority range. It is implementation defined whether the call is performed as an ordinary entry call, a timed entry call, or a conditional entry call; which kind of call is performed can depend on the specific interrupt. == Bounded (Run-Time) Errors == <span id="I7097"></span>It is a bounded error to evaluate E'Caller (see [[Guide:95lrm/RM-C-7-1|C.7.1]]) in an accept_statement for an interrupt entry. The possible effects are the same as for calling Current_Task from an entry body. == Documentation Requirements == The implementation shall document to which interrupts a task entry may be attached. The implementation shall document whether the invocation of an interrupt entry has the effect of an ordinary entry call, conditional call, or a timed call, and whether the effect varies in the presence of pending interrupts. == Implementation Permissions == The support for this subclause is optional. Interrupts to which the implementation allows a task entry to be attached may be designated as reserved for the entire duration of program execution; that is, not just when they have an interrupt entry attached to them. Interrupt entry calls may be implemented by having the hardware execute directly the appropriate accept_statement. Alternatively, the implementation is allowed to provide an internal interrupt handler to simulate the effect of a normal task calling the entry. The implementation is allowed to impose restrictions on the specifications and bodies of tasks that have interrupt entries. It is implementation defined whether direct calls (from the program) to interrupt entries are allowed. If a select_statement contains both a terminate_alternative and an accept_alternative for an interrupt entry, then an implementation is allowed to impose further requirements for the selection of the terminate_alternative in addition to those given in [[Guide:95lrm/RM-9-3|9.3]]. == Notes == 1  Queued interrupts correspond to ordinary entry calls. Interrupts that are lost if not immediately processed correspond to conditional entry calls. It is a consequence of the priority rules that an accept_statement executed in response to an interrupt can be executed with the active priority at which the hardware generates the interrupt, taking precedence over lower priority tasks, without a scheduling action. 2  Control information that is supplied upon an interrupt can be passed to an associated interrupt entry as one or more parameters of mode '''in'''. == Examples == ''Example of an interrupt entry:'' <p><syntaxhighlight lang="Ada"> task Interrupt_Handler is   entry Done;   for Done'Address use Ada.Interrupts.Reference(Ada.Interrupts.Names.Device_Done); end Interrupt_Handler;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-J-7|Previous]] | [[Guide:95lrm/RM-J-8|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} ra8l8pyeke9ry9z87yprl78uecvgxab Guide:95lrm/RM-J-8 4200 1197 4469 2019-05-02T09:17:57Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-J-7-1|Previous]] | [[Guide:95lrm/RM-J-9|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: J.8 Mod Clauses}} == Syntax == <p><span></span></p> mod_clause<span id="I7098"></span> ::= '''at''' '''mod''' ''static_''<span id="I7099"></span>expression; == Static Semantics == A record_representation_clause of the form: <p><syntaxhighlight lang="Ada"> for r use  record at mod a      ...  end record;</syntaxhighlight></p> is equivalent to: <p><syntaxhighlight lang="Ada"> for r'Alignment use a; for r use  record      ...  end record;</syntaxhighlight></p> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-J-7-1|Previous]] | [[Guide:95lrm/RM-J-9|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} pgorn36k5llw1919dqlebwms6d56lev Guide:95lrm/RM-J-9 4200 1198 4470 2019-04-29T15:48:28Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-J-8|Previous]] | [[Guide:95lrm/RM-K|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: J.9 The Storage_Size Attribute}} == Static Semantics == For any task subtype T, the following attribute is defined: ; T'<span id="I7100"></span><span id="I7101"></span>Storage_Size : Denotes an implementation-defined value of type ''universal_integer'' representing the number of storage elements reserved for a task of the subtype T. <span id="I7102"></span>Storage_Size may be specified for a task first subtype via an attribute_definition_clause. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-J-8|Previous]] | [[Guide:95lrm/RM-K|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} q0hlakbrde9xcjl5i0234y9h6di9h0b Guide:95lrm/RM-K 4200 1199 4471 2019-05-02T09:36:44Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-J-9|Previous]] | [[Guide:95lrm/RM-L|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Annex K. Language-Defined Attributes}} <div>(informative)</div> <span id="I7103"></span>This annex summarizes the definitions given elsewhere of the language-defined attributes. ; P'Access : For a prefix P that denotes a subprogram: <p><span></span></p> :P'Access yields an access value that designates the subprogram denoted by P. The type of P'Access is an access-to-subprogram type (''S''), as determined by the expected type. See 3.10.2. ; X'Access : For a prefix X that denotes an aliased view of an object: <p><span></span></p> :X'Access yields an access value that designates the object denoted by X. The type of X'Access is an access-to-object type, as determined by the expected type. The expected type shall be a general access type. See 3.10.2. ;   X'Address : For a prefix X that denotes an object, program unit, or label: <p><span></span></p> :Denotes the address of the first of the storage elements allocated to X. For a program unit or label, this value refers to the machine code associated with the corresponding body or statement. The value of this attribute is of type System.Address. See 13.3. ; S'Adjacent : For every subtype S of a floating point type ''T'': <p><span></span></p> :S'Adjacent denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Adjacent (X, Towards : T)   return T</syntaxhighlight></p> <p><span></span></p> :<span id="I7104"></span>If ''Towards'' = ''X'', the function yields ''X''; otherwise, it yields the machine number of the type ''T'' adjacent to ''X'' in the direction of ''Towards'', if that machine number exists. <span id="I7105"></span><span id="I7106"></span>If the result would be outside the base range of S, Constraint_Error is raised. When ''T'''Signed_Zeros is True, a zero result has the sign of ''X''. When ''Towards'' is zero, its sign has no bearing on the result. See A.5.3. ;  S'Aft : For every fixed point subtype S: <p><span></span></p> :S'Aft yields the number of decimal digits needed after the decimal point to accommodate the ''delta'' of the subtype S, unless the ''delta'' of the subtype S is greater than 0.1, in which case the attribute yields the value one. (S'Aft is the smallest positive integer N for which (10**N)*S'Delta is greater than or equal to one.) The value of this attribute is of the type ''universal_integer''. See 3.5.10. ;    X'Alignment : For a prefix X that denotes a subtype or object: <p><span></span></p> :The Address of an object that is allocated under control of the implementation is an integral multiple of the Alignment of the object (that is, the Address modulo the Alignment is zero). The offset of a record component is a multiple of the Alignment of the component. For an object that is not allocated under control of the implementation (that is, one that is imported, that is allocated by a user-defined allocator, whose Address has been specified, or is designated by an access value returned by an instance of Unchecked_Conversion), the implementation may assume that the Address is an integral multiple of its Alignment. The implementation shall not assume a stricter alignment. <p><span></span></p> :The value of this attribute is of type ''universal_integer'', and nonnegative; zero means that the object is not necessarily aligned on a storage element boundary. See 13.3. ;  S'Base : For every scalar subtype S: <p><span></span></p> :S'Base denotes an unconstrained subtype of the type of S. This unconstrained subtype is called the ''base subtype'' of the type. See 3.5. ;  S'Bit_Order : For every specific record subtype S: <p><span></span></p> :Denotes the bit ordering for the type of S. The value of this attribute is of type System.Bit_Order. See 13.5.3. ;    P'Body_Version : For a prefix P that statically denotes a program unit: <p><span></span></p> :Yields a value of the predefined type String that identifies the version of the compilation unit that contains the body (but not any subunits) of the program unit. See E.3. ;  T'Callable : For a prefix T that is of a task type (after any implicit dereference): <p><span></span></p> :Yields the value True when the task denoted by T is ''callable'', and False otherwise; See 9.9. ;  E'Caller : For a prefix E that denotes an entry_declaration: <p><span></span></p> :Yields a value of the type Task_ID that identifies the task whose call is now being serviced. Use of this attribute is allowed only inside an entry_body or accept_statement corresponding to the entry_declaration denoted by E. See C.7.1. ;  S'Ceiling : For every subtype S of a floating point type ''T'': <p><span></span></p> :S'Ceiling denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Ceiling (X : T)   return T</syntaxhighlight></p> <p><span></span></p> :The function yields the value ''Ceiling''(''X''), i.e., the smallest (most negative) integral value greater than or equal to ''X''. When ''X'' is zero, the result has the sign of ''X''; a zero result otherwise has a negative sign when S'Signed_Zeros is True. See A.5.3. ;  S'Class : For every subtype S of an untagged private type whose full view is tagged: <p><span></span></p> :Denotes the class-wide subtype corresponding to the full view of S. This attribute is allowed only from the beginning of the private part in which the full view is declared, until the declaration of the full view. After the full view, the Class attribute of the full view can be used. See 7.3.1. ;  S'Class : For every subtype S of a tagged type ''T'' (specific or class-wide): <p><span></span></p> :S'Class denotes a subtype of the class-wide type (called ''T'''Class in this International Standard) for the class rooted at ''T'' (or if S already denotes a class-wide subtype, then S'Class is the same as S). <p><span></span></p> :<span id="I7107"></span><span id="I7108"></span>S'Class is unconstrained. However, if S is constrained, then the values of S'Class are only those that when converted to the type ''T'' belong to S. See 3.9. ;    X'Component_Size : For a prefix X that denotes an array subtype or array object (after any implicit dereference): <p><span></span></p> :Denotes the size in bits of components of the type of X. The value of this attribute is of type ''universal_integer''. See 13.3. ;  S'Compose : For every subtype S of a floating point type ''T'': <p><span></span></p> :S'Compose denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Compose (Fraction : T;                  Exponent : universal_integer)   return T</syntaxhighlight></p> <p><span></span></p> :<span id="I7109"></span>Let ''v'' be the value ''Fraction'' · ''T'''Machine_Radix<sup>''Exponent''-''k''</sup>, where ''k'' is the normalized exponent of ''Fraction''. If ''v'' is a machine number of the type ''T'', or if |''v''| >= ''T'''Model_Small, the function yields ''v''; otherwise, it yields either one of the machine numbers of the type ''T'' adjacent to ''v''. <span id="I7110"></span><span id="I7111"></span>Constraint_Error is optionally raised if ''v'' is outside the base range of S. A zero result has the sign of ''Fraction'' when S'Signed_Zeros is True. See A.5.3. ;  A'Constrained : For a prefix A that is of a discriminated type (after any implicit dereference): <p><span></span></p> :Yields the value True if A denotes a constant, a value, or a constrained variable, and False otherwise. See 3.7.2. ;  S'Copy_Sign : For every subtype S of a floating point type ''T'': <p><span></span></p> :S'Copy_Sign denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Copy_Sign (Value, Sign : T)   return T</syntaxhighlight></p> <p><span></span></p> :<span id="I7112"></span>If the value of ''Value'' is nonzero, the function yields a result whose magnitude is that of ''Value'' and whose sign is that of ''Sign''; otherwise, it yields the value zero. <span id="I7113"></span><span id="I7114"></span>Constraint_Error is optionally raised if the result is outside the base range of S. A zero result has the sign of ''Sign'' when S'Signed_Zeros is True. See A.5.3. ;  E'Count : For a prefix E that denotes an entry of a task or protected unit: <p><span></span></p> :Yields the number of calls presently queued on the entry E of the current instance of the unit. The value of this attribute is of the type ''universal_integer''. See 9.9. ;    S'Definite : For a prefix S that denotes a formal indefinite subtype: <p><span></span></p> :S'Definite yields True if the actual subtype corresponding to S is definite; otherwise it yields False. The value of this attribute is of the predefined type Boolean. See 12.5.1. ;  S'Delta : For every fixed point subtype S: <p><span></span></p> :S'Delta denotes the ''delta'' of the fixed point subtype S. The value of this attribute is of the type ''universal_real''. See 3.5.10. ;  S'Denorm : For every subtype S of a floating point type ''T'': <p><span></span></p> :Yields the value True if every value expressible in the form :± ''mantissa'' · ''T'''Machine_Radix<sup>''T'''Machine_Emin</sup> :where ''mantissa'' is a nonzero ''T'''Machine_Mantissa-digit fraction in the number base ''T'''Machine_Radix, the first digit of which is zero, is a machine number (see [[Guide:95lrm/RM-3-5-7|3.5.7]]) of the type ''T''; yields the value False otherwise. The value of this attribute is of the predefined type Boolean. See A.5.3. ;  S'Digits : For every decimal fixed point subtype S: <p><span></span></p> :S'Digits denotes the ''digits'' of the decimal fixed point subtype S, which corresponds to the number of decimal digits that are representable in objects of the subtype. The value of this attribute is of the type ''universal_integer''. See 3.5.10. ;  S'Digits : For every floating point subtype S: <p><span></span></p> :S'Digits denotes the requested decimal precision for the subtype S. The value of this attribute is of the type ''universal_integer''. See 3.5.8. ;  S'Exponent : For every subtype S of a floating point type ''T'': <p><span></span></p> :S'Exponent denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Exponent (X : T)   return universal_integer</syntaxhighlight></p> <p><span></span></p> :The function yields the normalized exponent of ''X''. See A.5.3. ;  S'External_Tag : For every subtype S of a tagged type ''T'' (specific or class-wide): <p><span></span></p> :<span id="I7115"></span><span id="I7116"></span>S'External_Tag denotes an external string representation for S'Tag; it is of the predefined type String. External_Tag may be specified for a specific tagged type via an attribute_definition_clause; the expression of such a clause shall be static. The default external tag representation is implementation defined. See [[Guide:95lrm/RM-3-9-2|3.9.2]] and [[Guide:95lrm/RM-13-13-2|13.13.2]]. See 13.3. ;    A'First : For a prefix A that is of an array type (after any implicit dereference), or denotes a constrained array subtype: <p><span></span></p> :A'First denotes the lower bound of the first index range; its type is the corresponding index type. See 3.6.2. ;  S'First : For every scalar subtype S: <p><span></span></p> :S'First denotes the lower bound of the range of S. The value of this attribute is of the type of S. See 3.5. ;    A'First(N) : For a prefix A that is of an array type (after any implicit dereference), or denotes a constrained array subtype: <p><span></span></p> :A'First(N) denotes the lower bound of the N-th index range; its type is the corresponding index type. See 3.6.2. ;  R.C'First_Bit : For a component C of a composite, non-array object R: <p><span></span></p> :Denotes the offset, from the start of the first of the storage elements occupied by C, of the first bit occupied by C. This offset is measured in bits. The first bit of a storage element is numbered zero. The value of this attribute is of the type ''universal_integer''. See 13.5.2. ;  S'Floor : For every subtype S of a floating point type ''T'': <p><span></span></p> :S'Floor denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Floor (X : T)   return T</syntaxhighlight></p> <p><span></span></p> :The function yields the value ''Floor''(''X''), i.e., the largest (most positive) integral value less than or equal to ''X''. When ''X'' is zero, the result has the sign of ''X''; a zero result otherwise has a positive sign. See A.5.3. ;  S'Fore : For every fixed point subtype S: <p><span></span></p> :S'Fore yields the minimum number of characters needed before the decimal point for the decimal representation of any value of the subtype S, assuming that the representation does not include an exponent, but includes a one-character prefix that is either a minus sign or a space. (This minimum number does not include superfluous zeros or underlines, and is at least 2.) The value of this attribute is of the type ''universal_integer''. See 3.5.10. ;  S'Fraction : For every subtype S of a floating point type ''T'': <p><span></span></p> :S'Fraction denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Fraction (X : T)   return T</syntaxhighlight></p> <p><span></span></p> :The function yields the value ''X'' · ''T'''Machine_Radix<sup>-''k''</sup>, where ''k'' is the normalized exponent of ''X''. A zero result, which can only occur when ''X'' is zero, has the sign of ''X''. See A.5.3. ;  T'Identity : For a prefix T that is of a task type (after any implicit dereference): <p><span></span></p> :Yields a value of the type Task_ID that identifies the task denoted by T. See C.7.1. ;    E'Identity : For a prefix E that denotes an exception: <p><span></span></p> :E'Identity returns the unique identity of the exception. The type of this attribute is Exception_Id. See 11.4.1. ;  S'Image : For every scalar subtype S: <p><span></span></p> :S'Image denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Image(Arg : S'Base)   return String</syntaxhighlight></p> <p><span></span></p> :The function returns an image of the value of ''Arg'' as a String. See 3.5. ;  S'Class'Input : For every subtype S'Class of a class-wide type ''T'''Class: <p><span></span></p> :S'Class'Input denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Class'Input( Stream : access Ada.Streams.Root_Stream_Type'Class) return T'Class</syntaxhighlight></p> <p><span></span></p> :First reads the external tag from ''Stream'' and determines the corresponding internal tag (by calling Tags.Internal_Tag(String'Input(''Stream'')) -- see [[Guide:95lrm/RM-3-9|3.9]]) and then dispatches to the subprogram denoted by the Input attribute of the specific type identified by the internal tag; returns that result. See 13.13.2. ;  S'Input : For every subtype S of a specific type ''T'': <p><span></span></p> :S'Input denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Input( Stream : access Ada.Streams.Root_Stream_Type'Class) return T</syntaxhighlight></p> <p><span></span></p> :S'Input reads and returns one value from ''Stream'', using any bounds or discriminants written by a corresponding S'Output to determine how much to read. See 13.13.2. ; A'Last : For a prefix A that is of an array type (after any implicit dereference), or denotes a constrained array subtype: <p><span></span></p> :A'Last denotes the upper bound of the first index range; its type is the corresponding index type. See 3.6.2. ; S'Last : For every scalar subtype S: <p><span></span></p> :S'Last denotes the upper bound of the range of S. The value of this attribute is of the type of S. See 3.5. ; A'Last(N) : For a prefix A that is of an array type (after any implicit dereference), or denotes a constrained array subtype: <p><span></span></p> :A'Last(N) denotes the upper bound of the N-th index range; its type is the corresponding index type. See 3.6.2. ; R.C'Last_Bit : For a component C of a composite, non-array object R: <p><span></span></p> :Denotes the offset, from the start of the first of the storage elements occupied by C, of the last bit occupied by C. This offset is measured in bits. The value of this attribute is of the type ''universal_integer''. See 13.5.2. ; S'Leading_Part : For every subtype S of a floating point type ''T'': <p><span></span></p> :S'Leading_Part denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Leading_Part (X : T;                       Radix_Digits : universal_integer)   return T</syntaxhighlight></p> <p><span></span></p> :Let ''v'' be the value ''T'''Machine_Radix<sup>''k''-''Radix_Digits''</sup>, where ''k'' is the normalized exponent of ''X''. The function yields the value <p><span></span></p> :* ''Floor''(''X''/''v'') · ''v'', when ''X'' is nonnegative and ''Radix_Digits'' is positive; <p><span></span></p> :* ''Ceiling''(''X''/''v'') · ''v'', when ''X'' is negative and ''Radix_Digits'' is positive. <p><span></span></p> :<span id="I7117"></span><span id="I7118"></span><span id="I7119"></span>Constraint_Error is raised when ''Radix_Digits'' is zero or negative. A zero result, which can only occur when ''X'' is zero, has the sign of ''X''. See A.5.3. ; A'Length : For a prefix A that is of an array type (after any implicit dereference), or denotes a constrained array subtype: <p><span></span></p> :A'Length denotes the number of values of the first index range (zero for a null range); its type is ''universal_integer''. See 3.6.2. ; A'Length(N) : For a prefix A that is of an array type (after any implicit dereference), or denotes a constrained array subtype: <p><span></span></p> :A'Length(N) denotes the number of values of the N-th index range (zero for a null range); its type is ''universal_integer''. See 3.6.2. ; S'Machine : For every subtype S of a floating point type ''T'': <p><span></span></p> :S'Machine denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Machine (X : T)   return T</syntaxhighlight></p> <p><span></span></p> :<span id="I7120"></span>If ''X'' is a machine number of the type ''T'', the function yields ''X''; otherwise, it yields the value obtained by rounding or truncating ''X'' to either one of the adjacent machine numbers of the type ''T''. <span id="I7121"></span><span id="I7122"></span>Constraint_Error is raised if rounding or truncating ''X'' to the precision of the machine numbers results in a value outside the base range of S. A zero result has the sign of ''X'' when S'Signed_Zeros is True. See A.5.3. ;   S'Machine_Emax : For every subtype S of a floating point type ''T'': <p><span></span></p> :Yields the largest (most positive) value of ''exponent'' such that every value expressible in the canonical form (for the type ''T''), having a ''mantissa'' of ''T'''Machine_Mantissa digits, is a machine number (see [[Guide:95lrm/RM-3-5-7|3.5.7]]) of the type ''T''. This attribute yields a value of the type ''universal_integer''. See A.5.3. ;   S'Machine_Emin : For every subtype S of a floating point type ''T'': <p><span></span></p> :Yields the smallest (most negative) value of ''exponent'' such that every value expressible in the canonical form (for the type ''T''), having a ''mantissa'' of ''T'''Machine_Mantissa digits, is a machine number (see [[Guide:95lrm/RM-3-5-7|3.5.7]]) of the type ''T''. This attribute yields a value of the type ''universal_integer''. See A.5.3. ;   S'Machine_Mantissa : For every subtype S of a floating point type ''T'': <p><span></span></p> :Yields the largest value of ''p'' such that every value expressible in the canonical form (for the type ''T''), having a ''p''-digit ''mantissa'' and an ''exponent'' between ''T'''Machine_Emin and ''T'''Machine_Emax, is a machine number (see [[Guide:95lrm/RM-3-5-7|3.5.7]]) of the type ''T''. This attribute yields a value of the type ''universal_integer''. See A.5.3. ;   S'Machine_Overflows : For every subtype S of a fixed point type ''T'': <p><span></span></p> :Yields the value True if overflow and divide-by-zero are detected and reported by raising Constraint_Error for every predefined operation that yields a result of the type ''T''; yields the value False otherwise. The value of this attribute is of the predefined type Boolean. See A.5.4. ;   S'Machine_Overflows : For every subtype S of a floating point type ''T'': <p><span></span></p> :Yields the value True if overflow and divide-by-zero are detected and reported by raising Constraint_Error for every predefined operation that yields a result of the type ''T''; yields the value False otherwise. The value of this attribute is of the predefined type Boolean. See A.5.3. ;   S'Machine_Radix : For every subtype S of a fixed point type ''T'': <p><span></span></p> :Yields the radix of the hardware representation of the type ''T''. The value of this attribute is of the type ''universal_integer''. See A.5.4. ;   S'Machine_Radix : For every subtype S of a floating point type ''T'': <p><span></span></p> :Yields the radix of the hardware representation of the type ''T''. The value of this attribute is of the type ''universal_integer''. See A.5.3. ;   S'Machine_Rounds : For every subtype S of a fixed point type ''T'': <p><span></span></p> :Yields the value True if rounding is performed on inexact results of every predefined operation that yields a result of the type ''T''; yields the value False otherwise. The value of this attribute is of the predefined type Boolean. See A.5.4. ;   S'Machine_Rounds : For every subtype S of a floating point type ''T'': <p><span></span></p> :Yields the value True if rounding is performed on inexact results of every predefined operation that yields a result of the type ''T''; yields the value False otherwise. The value of this attribute is of the predefined type Boolean. See A.5.3. ;   S'Max : For every scalar subtype S: <p><span></span></p> :S'Max denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Max(Left, Right : S'Base)   return S'Base</syntaxhighlight></p> <p><span></span></p> :The function returns the greater of the values of the two parameters. See 3.5. ;   S'Max_Size_In_Storage_Elements : For every subtype S: <p><span></span></p> :Denotes the maximum value for Size_In_Storage_Elements that will be requested via Allocate for an access type whose designated subtype is S. The value of this attribute is of type ''universal_integer''. See 13.11.1. ;   S'Min : For every scalar subtype S: <p><span></span></p> :S'Min denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Min(Left, Right : S'Base)   return S'Base</syntaxhighlight></p> <p><span></span></p> :The function returns the lesser of the values of the two parameters. See 3.5. ;   S'Model : For every subtype S of a floating point type ''T'': <p><span></span></p> :S'Model denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Model (X : T)   return T</syntaxhighlight></p> <p><span></span></p> :If the Numerics Annex is not supported, the meaning of this attribute is implementation defined; see [[Guide:95lrm/RM-G-2-2|G.2.2]] for the definition that applies to implementations supporting the Numerics Annex. See A.5.3. ;   S'Model_Emin : For every subtype S of a floating point type ''T'': <p><span></span></p> :If the Numerics Annex is not supported, this attribute yields an implementation defined value that is greater than or equal to the value of ''T'''Machine_Emin. See [[Guide:95lrm/RM-G-2-2|G.2.2]] for further requirements that apply to implementations supporting the Numerics Annex. The value of this attribute is of the type ''universal_integer''. See A.5.3. ;   S'Model_Epsilon : For every subtype S of a floating point type ''T'': <p><span></span></p> :Yields the value ''T'''Machine_Radix<sup>1 - ''T'''Model_Mantissa</sup>. The value of this attribute is of the type ''universal_real''. See A.5.3. ;   S'Model_Mantissa : For every subtype S of a floating point type ''T'': <p><span></span></p> :If the Numerics Annex is not supported, this attribute yields an implementation defined value that is greater than or equal to ''Ceiling''(''d'' · log(10) / log(''T'''Machine_Radix)) + 1, where ''d'' is the requested decimal precision of ''T'', and less than or equal to the value of ''T'''Machine_Mantissa. See [[Guide:95lrm/RM-G-2-2|G.2.2]] for further requirements that apply to implementations supporting the Numerics Annex. The value of this attribute is of the type ''universal_integer''. See A.5.3. ;   S'Model_Small : For every subtype S of a floating point type ''T'': <p><span></span></p> :Yields the value ''T'''Machine_Radix<sup>''T'''Model_Emin - 1</sup>. The value of this attribute is of the type ''universal_real''. See A.5.3. ;   S'Modulus : For every modular subtype S: <p><span></span></p> :S'Modulus yields the modulus of the type of S, as a value of the type ''universal_integer''. See 3.5.4. ;   S'Class'Output : For every subtype S'Class of a class-wide type ''T'''Class: <p><span></span></p> :S'Class'Output denotes a procedure with the following specification: <p><syntaxhighlight lang="Ada"> procedure S'Class'Output( Stream : access Ada.Streams.Root_Stream_Type'Class; Item   : in T'Class)</syntaxhighlight></p> <p><span></span></p> :First writes the external tag of ''Item'' to ''Stream'' (by calling String'Output(Tags.External_Tag(''Item'''Tag) -- see [[Guide:95lrm/RM-3-9|3.9]]) and then dispatches to the subprogram denoted by the Output attribute of the specific type identified by the tag. See 13.13.2. ;   S'Output : For every subtype S of a specific type ''T'': <p><span></span></p> :S'Output denotes a procedure with the following specification: <p><syntaxhighlight lang="Ada"> procedure S'Output( Stream : access Ada.Streams.Root_Stream_Type'Class; Item : in T)</syntaxhighlight></p> <p><span></span></p> :S'Output writes the value of ''Item'' to ''Stream'', including any bounds or discriminants. See 13.13.2. ;     D'Partition_ID : For a prefix D that denotes a library-level declaration, excepting a declaration of or within a declared-pure library unit: <p><span></span></p> :Denotes a value of the type ''universal_integer'' that identifies the partition in which D was elaborated. If D denotes the declaration of a remote call interface library unit (see [[Guide:95lrm/RM-E-2-3|E.2.3]]) the given partition is the one where the body of D was elaborated. See E.1. ;   S'Pos : For every discrete subtype S: <p><span></span></p> :S'Pos denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Pos(Arg : S'Base)   return universal_integer</syntaxhighlight></p> <p><span></span></p> :This function returns the position number of the value of ''Arg'', as a value of type ''universal_integer''. See 3.5.5. ;   R.C'Position : For a component C of a composite, non-array object R: <p><span></span></p> :Denotes the same value as R.C'Address - R'Address. The value of this attribute is of the type ''universal_integer''. See 13.5.2. ;   S'Pred : For every scalar subtype S: <p><span></span></p> :S'Pred denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Pred(Arg : S'Base)   return S'Base</syntaxhighlight></p> <p><span></span></p> :<span id="I7123"></span>For an enumeration type, the function returns the value whose position number is one less than that of the value of ''Arg''; <span id="I7124"></span><span id="I7125"></span>Constraint_Error is raised if there is no such value of the type. For an integer type, the function returns the result of subtracting one from the value of ''Arg''. For a fixed point type, the function returns the result of subtracting ''small'' from the value of ''Arg''. For a floating point type, the function returns the machine number (as defined in [[Guide:95lrm/RM-3-5-7|3.5.7]]) immediately below the value of ''Arg''; <span id="I7126"></span><span id="I7127"></span>Constraint_Error is raised if there is no such machine number. See 3.5. ; A'Range : For a prefix A that is of an array type (after any implicit dereference), or denotes a constrained array subtype: <p><span></span></p> :A'Range is equivalent to the range A'First .. A'Last, except that the prefix A is only evaluated once. See 3.6.2. ; S'Range : For every scalar subtype S: <p><span></span></p> :S'Range is equivalent to the range S'First .. S'Last. See 3.5. ; A'Range(N) : For a prefix A that is of an array type (after any implicit dereference), or denotes a constrained array subtype: <p><span></span></p> :A'Range(N) is equivalent to the range A'First(N) .. A'Last(N), except that the prefix A is only evaluated once. See 3.6.2. ; S'Class'Read : For every subtype S'Class of a class-wide type ''T'''Class: <p><span></span></p> :S'Class'Read denotes a procedure with the following specification: <p><syntaxhighlight lang="Ada"> procedure S'Class'Read( Stream : access Ada.Streams.Root_Stream_Type'Class; Item : out T'Class)</syntaxhighlight></p> <p><span></span></p> :Dispatches to the subprogram denoted by the Read attribute of the specific type identified by the tag of Item. See 13.13.2. ; S'Read : For every subtype S of a specific type ''T'': <p><span></span></p> :S'Read denotes a procedure with the following specification: <p><syntaxhighlight lang="Ada"> procedure S'Read( Stream : access Ada.Streams.Root_Stream_Type'Class; Item : out T)</syntaxhighlight></p> <p><span></span></p> :S'Read reads the value of ''Item'' from ''Stream''. See 13.13.2. ; S'Remainder : For every subtype S of a floating point type ''T'': <p><span></span></p> :S'Remainder denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Remainder (X, Y : T)   return T</syntaxhighlight></p> <p><span></span></p> :<span id="I7128"></span>For nonzero ''Y'', let ''v'' be the value ''X'' - ''n'' · ''Y'', where ''n'' is the integer nearest to the exact value of ''X''/''Y''; if |''n'' - ''X''/''Y''| = 1/2, then ''n'' is chosen to be even. If ''v'' is a machine number of the type ''T'', the function yields ''v''; otherwise, it yields zero. <span id="I7129"></span><span id="I7130"></span>Constraint_Error is raised if ''Y'' is zero. A zero result has the sign of ''X'' when S'Signed_Zeros is True. See A.5.3. ; S'Round : For every decimal fixed point subtype S: <p><span></span></p> :S'Round denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Round(X : universal_real)   return S'Base</syntaxhighlight></p> <p><span></span></p> :The function returns the value obtained by rounding X (away from 0, if X is midway between two values of the type of S). See 3.5.10. ; S'Rounding : For every subtype S of a floating point type ''T'': <p><span></span></p> :S'Rounding denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Rounding (X : T)   return T</syntaxhighlight></p> <p><span></span></p> :The function yields the integral value nearest to ''X'', rounding away from zero if ''X'' lies exactly halfway between two integers. A zero result has the sign of ''X'' when S'Signed_Zeros is True. See A.5.3. ; S'Safe_First : For every subtype S of a floating point type ''T'': <p><span></span></p> :Yields the lower bound of the safe range (see [[Guide:95lrm/RM-3-5-7|3.5.7]]) of the type ''T''. If the Numerics Annex is not supported, the value of this attribute is implementation defined; see [[Guide:95lrm/RM-G-2-2|G.2.2]] for the definition that applies to implementations supporting the Numerics Annex. The value of this attribute is of the type ''universal_real''. See A.5.3. ; S'Safe_Last : For every subtype S of a floating point type ''T'': <p><span></span></p> :Yields the upper bound of the safe range (see [[Guide:95lrm/RM-3-5-7|3.5.7]]) of the type ''T''. If the Numerics Annex is not supported, the value of this attribute is implementation defined; see [[Guide:95lrm/RM-G-2-2|G.2.2]] for the definition that applies to implementations supporting the Numerics Annex. The value of this attribute is of the type ''universal_real''. See A.5.3. ; S'Scale : For every decimal fixed point subtype S: <p><span></span></p> :S'Scale denotes the ''scale'' of the subtype S, defined as the value N such that S'Delta = 10.0**(-N). <span id="I7131"></span>The scale indicates the position of the point relative to the rightmost significant digits of values of subtype S. The value of this attribute is of the type ''universal_integer''. See 3.5.10. ; S'Scaling : For every subtype S of a floating point type ''T'': <p><span></span></p> :S'Scaling denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Scaling (X : T;                  Adjustment : universal_integer)   return T</syntaxhighlight></p> <p><span></span></p> :<span id="I7132"></span>Let ''v'' be the value ''X'' · ''T'''Machine_Radix<sup>''Adjustment''</sup>. If ''v'' is a machine number of the type ''T'', or if |''v''| >= ''T'''Model_Small, the function yields ''v''; otherwise, it yields either one of the machine numbers of the type ''T'' adjacent to ''v''. <span id="I7133"></span><span id="I7134"></span>Constraint_Error is optionally raised if ''v'' is outside the base range of S. A zero result has the sign of ''X'' when S'Signed_Zeros is True. See A.5.3. ; S'Signed_Zeros : For every subtype S of a floating point type ''T'': <p><span></span></p> :Yields the value True if the hardware representation for the type ''T'' has the capability of representing both positively and negatively signed zeros, these being generated and used by the predefined operations of the type ''T'' as specified in IEC 559:1989; yields the value False otherwise. The value of this attribute is of the predefined type Boolean. See A.5.3. ; S'Size : For every subtype S: <p><span></span></p> :If S is definite, denotes the size (in bits) that the implementation would choose for the following objects of subtype S: <p><span></span></p> :* A record component of subtype S when the record type is packed. <p><span></span></p> :* The formal parameter of an instance of Unchecked_Conversion that converts from subtype S to some other subtype. <p><span></span></p> :If S is indefinite, the meaning is implementation defined. The value of this attribute is of the type ''universal_integer''. See 13.3. ; X'Size : For a prefix X that denotes an object: <p><span></span></p> :Denotes the size in bits of the representation of the object. The value of this attribute is of the type ''universal_integer''. See 13.3. ; S'Small : For every fixed point subtype S: <p><span></span></p> :S'Small denotes the ''small'' of the type of S. The value of this attribute is of the type ''universal_real''. See 3.5.10. ; S'Storage_Pool : For every access subtype S: <p><span></span></p> :Denotes the storage pool of the type of S. The type of this attribute is Root_Storage_Pool'Class. See 13.11. ; S'Storage_Size : For every access subtype S: <p><span></span></p> :Yields the result of calling Storage_Size(S'Storage_Pool), which is intended to be a measure of the number of storage elements reserved for the pool. The type of this attribute is ''universal_integer''. See 13.11. ; T'Storage_Size : For a prefix T that denotes a task object (after any implicit dereference): <p><span></span></p> :Denotes the number of storage elements reserved for the task. The value of this attribute is of the type ''universal_integer''. The Storage_Size includes the size of the task's stack, if any. The language does not specify whether or not it includes other storage associated with the task (such as the ''task control block'' used by some implementations.) See 13.3. ; S'Succ : For every scalar subtype S: <p><span></span></p> :S'Succ denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Succ(Arg : S'Base)   return S'Base</syntaxhighlight></p> <p><span></span></p> :<span id="I7135"></span>For an enumeration type, the function returns the value whose position number is one more than that of the value of ''Arg''; <span id="I7136"></span><span id="I7137"></span>Constraint_Error is raised if there is no such value of the type. For an integer type, the function returns the result of adding one to the value of ''Arg''. For a fixed point type, the function returns the result of adding ''small'' to the value of ''Arg''. For a floating point type, the function returns the machine number (as defined in [[Guide:95lrm/RM-3-5-7|3.5.7]]) immediately above the value of ''Arg''; <span id="I7138"></span><span id="I7139"></span>Constraint_Error is raised if there is no such machine number. See 3.5. ; X'Tag : For a prefix X that is of a class-wide tagged type (after any implicit dereference): <p><span></span></p> :X'Tag denotes the tag of X. The value of this attribute is of type Tag. See 3.9. ; S'Tag : For every subtype S of a tagged type ''T'' (specific or class-wide): <p><span></span></p> :S'Tag denotes the tag of the type ''T'' (or if ''T'' is class-wide, the tag of the root type of the corresponding class). The value of this attribute is of type Tag. See 3.9. ; T'Terminated : For a prefix T that is of a task type (after any implicit dereference): <p><span></span></p> :Yields the value True if the task denoted by T is terminated, and False otherwise. The value of this attribute is of the predefined type Boolean. See 9.9. ; S'Truncation : For every subtype S of a floating point type ''T'': <p><span></span></p> :S'Truncation denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Truncation (X : T)   return T</syntaxhighlight></p> <p><span></span></p> :The function yields the value ''Ceiling''(''X'') when ''X'' is negative, and ''Floor''(''X'') otherwise. A zero result has the sign of ''X'' when S'Signed_Zeros is True. See A.5.3. ; S'Unbiased_Rounding : For every subtype S of a floating point type ''T'': <p><span></span></p> :S'Unbiased_Rounding denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Unbiased_Rounding (X : T)   return T</syntaxhighlight></p> <p><span></span></p> :The function yields the integral value nearest to ''X'', rounding toward the even integer if ''X'' lies exactly halfway between two integers. A zero result has the sign of ''X'' when S'Signed_Zeros is True. See A.5.3. ; X'Unchecked_Access : For a prefix X that denotes an aliased view of an object: <p><span></span></p> :All rules and semantics that apply to X'Access (see [[Guide:95lrm/RM-3-10-2|3.10.2]]) apply also to X'Unchecked_Access, except that, for the purposes of accessibility rules and checks, it is as if X were declared immediately within a library package. See 13.10. ; S'Val : For every discrete subtype S: <p><span></span></p> :S'Val denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Val(Arg : universal_integer)   return S'Base</syntaxhighlight></p> <p><span></span></p> :<span id="I7140"></span><span id="I7141"></span>This function returns a value of the type of S whose position number equals the value of ''Arg''. See 3.5.5. ; X'Valid : For a prefix X that denotes a scalar object (after any implicit dereference): <p><span></span></p> :Yields True if and only if the object denoted by X is normal and has a valid representation. The value of this attribute is of the predefined type Boolean. See 13.9.2. ; S'Value : For every scalar subtype S: <p><span></span></p> :S'Value denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Value(Arg : String)   return S'Base</syntaxhighlight></p> <p><span></span></p> :This function returns a value given an image of the value as a String, ignoring any leading or trailing spaces. See 3.5. ; P'Version : For a prefix P that statically denotes a program unit: <p><span></span></p> :Yields a value of the predefined type String that identifies the version of the compilation unit that contains the declaration of the program unit. See E.3. ; S'Wide_Image : For every scalar subtype S: <p><span></span></p> :S'Wide_Image denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Wide_Image(Arg : S'Base)   return Wide_String</syntaxhighlight></p> <p><span></span></p> :<span id="I7142"></span>The function returns an ''image'' of the value of ''Arg'', that is, a sequence of characters representing the value in display form. See 3.5. ; S'Wide_Value : For every scalar subtype S: <p><span></span></p> :S'Wide_Value denotes a function with the following specification: <p><syntaxhighlight lang="Ada"> function S'Wide_Value(Arg : Wide_String)   return S'Base</syntaxhighlight></p> <p><span></span></p> :This function returns a value given an image of the value as a Wide_String, ignoring any leading or trailing spaces. See 3.5. ; S'Wide_Width : For every scalar subtype S: <p><span></span></p> :S'Wide_Width denotes the maximum length of a Wide_String returned by S'Wide_Image over all values of the subtype S. It denotes zero for a subtype that has a null range. Its type is ''universal_integer''. See 3.5. ; S'Width : For every scalar subtype S: <p><span></span></p> :S'Width denotes the maximum length of a String returned by S'Image over all values of the subtype S. It denotes zero for a subtype that has a null range. Its type is ''universal_integer''. See 3.5. ; S'Class'Write : For every subtype S'Class of a class-wide type ''T'''Class: <p><span></span></p> :S'Class'Write denotes a procedure with the following specification: <p><syntaxhighlight lang="Ada"> procedure S'Class'Write( Stream : access Ada.Streams.Root_Stream_Type'Class; Item   : in T'Class)</syntaxhighlight></p> <p><span></span></p> :Dispatches to the subprogram denoted by the Write attribute of the specific type identified by the tag of Item. See 13.13.2. ; S'Write : For every subtype S of a specific type ''T'': <p><span></span></p> :S'Write denotes a procedure with the following specification: <p><syntaxhighlight lang="Ada"> procedure S'Write( Stream : access Ada.Streams.Root_Stream_Type'Class; Item : in T)</syntaxhighlight></p> <p><span></span></p> :S'Write writes the value of ''Item'' to ''Stream''. See 13.13.2. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-J-9|Previous]] | [[Guide:95lrm/RM-L|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} dlj9cvmsqi1l2urju1kk2zryc9ne972 Guide:95lrm/RM-L 4200 1200 4472 2019-05-02T09:44:03Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-K|Previous]] | [[Guide:95lrm/RM-M|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Annex L. Language-Defined Pragmas}} <div>(informative) </div> <span id="I7143"></span>This Annex summarizes the definitions given elsewhere of the language-defined pragmas. <p><span></span></p> '''pragma''' <span id="I7144"></span><span id="I7145"></span>All_Calls_Remote[(''library_unit_''<span id="I7146"></span>name)]; -- See E.2.3. <p><span></span></p> '''pragma''' <span id="I7147"></span><span id="I7148"></span>Asynchronous(<span id="I7149"></span>local_name); -- See E.4.1. <p><span></span></p> '''pragma''' <span id="I7150"></span><span id="I7151"></span>Atomic(<span id="I7152"></span>local_name); -- See C.6. <p><span></span></p> '''pragma''' <span id="I7153"></span><span id="I7154"></span>Atomic_Components(''array_''<span id="I7155"></span>local_name); -- See C.6. <p><span></span></p> '''pragma''' <span id="I7156"></span><span id="I7157"></span>Attach_Handler(''handler_''<span id="I7158"></span>name, <span id="I7159"></span>expression); -- See C.3.1. <p><span></span></p> '''pragma''' <span id="I7160"></span><span id="I7161"></span>Controlled(''first_subtype_''<span id="I7162"></span>local_name); -- See 13.11.3. <p><span></span></p> '''pragma''' <span id="I7163"></span><span id="I7164"></span>Convention([Convention =>] ''convention_''<span id="I7165"></span>identifier,[Entity =>] <span id="I7166"></span>local_name); -- See B.1. <p><span></span></p> '''pragma''' <span id="I7167"></span><span id="I7168"></span>Discard_Names[([On => ] <span id="I7169"></span>local_name)]; -- See C.5. <p><span></span></p> '''pragma''' <span id="I7170"></span><span id="I7171"></span>Elaborate(''library_unit_''<span id="I7172"></span>name{, ''library_unit_''<span id="I7173"></span>name}); -- See 10.2.1. <p><span></span></p> '''pragma''' <span id="I7174"></span><span id="I7175"></span>Elaborate_All(''library_unit_''<span id="I7176"></span>name{, ''library_unit_''<span id="I7177"></span>name}); -- See 10.2.1. <p><span></span></p> '''pragma''' <span id="I7178"></span><span id="I7179"></span>Elaborate_Body[(''library_unit_''<span id="I7180"></span>name)]; -- See 10.2.1. <p><span></span></p> '''pragma''' <span id="I7181"></span><span id="I7182"></span>Export( [Convention =>] ''convention_''<span id="I7183"></span>identifier, [Entity =>] <span id="I7184"></span>local_name [, [External_Name =>] ''string_''<span id="I7185"></span>expression] [, [Link_Name =>] ''string_''<span id="I7186"></span>expression]); -- See B.1. <p><span></span></p> '''pragma''' <span id="I7187"></span><span id="I7188"></span>Import( [Convention =>] ''convention_''<span id="I7189"></span>identifier, [Entity =>] <span id="I7190"></span>local_name [, [External_Name =>] ''string_''<span id="I7191"></span>expression] [, [Link_Name =>] ''string_''<span id="I7192"></span>expression]); -- See B.1. <p><span></span></p> '''pragma''' <span id="I7193"></span><span id="I7194"></span>Inline(<span id="I7195"></span>name {, <span id="I7196"></span>name}); -- See 6.3.2. <p><span></span></p> '''pragma''' <span id="I7197"></span><span id="I7198"></span>Inspection_Point[(''object_''<span id="I7199"></span>name {, ''object_''<span id="I7200"></span>name})]; -- See H.3.2. <p><span></span></p> '''pragma''' <span id="I7201"></span><span id="I7202"></span>Interrupt_Handler(''handler_''<span id="I7203"></span>name); -- See C.3.1. <p><span></span></p> '''pragma''' <span id="I7204"></span><span id="I7205"></span>Interrupt_Priority[(<span id="I7206"></span>expression)]; -- See D.1. <p><span></span></p> '''pragma''' <span id="I7207"></span><span id="I7208"></span>Linker_Options(''string_''<span id="I7209"></span>expression); -- See B.1. <p><span></span></p> '''pragma''' <span id="I7210"></span><span id="I7211"></span>List(<span id="I7212"></span>identifier); -- See 2.8. <p><span></span></p> '''pragma''' <span id="I7213"></span><span id="I7214"></span>Locking_Policy(''policy_''<span id="I7215"></span>identifier); -- See D.3. <p><span></span></p> '''pragma''' <span id="I7216"></span><span id="I7217"></span>Normalize_Scalars; -- See H.1. <p><span></span></p> '''pragma''' <span id="I7218"></span><span id="I7219"></span>Optimize(<span id="I7220"></span>identifier); -- See 2.8. <p><span></span></p> '''pragma''' <span id="I7221"></span><span id="I7222"></span>Pack(''first_subtype_''<span id="I7223"></span>local_name); -- See 13.2. <p><span></span></p> '''pragma''' <span id="I7224"></span><span id="I7225"></span>Page; -- See 2.8. <p><span></span></p> '''pragma''' <span id="I7226"></span><span id="I7227"></span>Preelaborate[(''library_unit_''<span id="I7228"></span>name)]; -- See 10.2.1. <p><span></span></p> '''pragma''' <span id="I7229"></span><span id="I7230"></span>Priority(<span id="I7231"></span>expression); -- See D.1. <p><span></span></p> '''pragma''' <span id="I7232"></span><span id="I7233"></span>Pure[(''library_unit_''<span id="I7234"></span>name)]; -- See 10.2.1. <p><span></span></p> '''pragma''' <span id="I7235"></span><span id="I7236"></span>Queuing_Policy(''policy_''<span id="I7237"></span>identifier); -- See D.4. <p><span></span></p> '''pragma''' <span id="I7238"></span><span id="I7239"></span>Remote_Call_Interface[(''library_unit_''<span id="I7240"></span>name)]; -- See E.2.3. <p><span></span></p> '''pragma''' <span id="I7241"></span><span id="I7242"></span>Remote_Types[(''library_unit_''<span id="I7243"></span>name)]; -- See E.2.2. <p><span></span></p> '''pragma''' <span id="I7244"></span><span id="I7245"></span>Restrictions(<span id="I7246"></span>restriction{, <span id="I7247"></span>restriction}); -- See 13.12. <p><span></span></p> '''pragma''' <span id="I7248"></span><span id="I7249"></span>Reviewable; -- See H.3.1. <p><span></span></p> '''pragma''' <span id="I7250"></span><span id="I7251"></span>Shared_Passive[(''library_unit_''<span id="I7252"></span>name)]; -- See E.2.1. <p><span></span></p> '''pragma''' <span id="I7253"></span><span id="I7254"></span>Storage_Size(<span id="I7255"></span>expression); -- See 13.3. <p><span></span></p> '''pragma''' <span id="I7256"></span><span id="I7257"></span>Suppress(<span id="I7258"></span>identifier [, [On =>] <span id="I7259"></span>name]); -- See 11.5. <p><span></span></p> '''pragma''' <span id="I7260"></span><span id="I7261"></span>Task_Dispatching_Policy(''policy_''<span id="I7262"></span>identifier ); -- See D.2.2. <p><span></span></p> '''pragma''' <span id="I7263"></span><span id="I7264"></span>Volatile(<span id="I7265"></span>local_name); -- See C.6. <p><span></span></p> '''pragma''' <span id="I7266"></span><span id="I7267"></span>Volatile_Components(''array_''<span id="I7268"></span>local_name); -- See C.6. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-K|Previous]] | [[Guide:95lrm/RM-M|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} qj3b2n047lcx4ns90aexnqo8nj86d6a Guide:95lrm/RM-M 4200 1201 4473 2019-05-02T10:20:57Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-L|Previous]] | [[Guide:95lrm/RM-N|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Annex M. Implementation-Defined Characteristics}} <div>(informative)</div> <span id="I7269"></span>The Ada language allows for certain machine dependences in a controlled manner. <span id="I7270"></span>Each Ada implementation must document all implementation-defined characteristics: * Whether or not each recommendation given in Implementation Advice is followed. See 1.1.2(37). * Capacity limitations of the implementation. See 1.1.3(3). * Variations from the standard that are impractical to avoid given the implementation's execution environment. See 1.1.3(6). * Which code_statements cause external interactions. See 1.1.3(10). * The coded representation for the text of an Ada program. See 2.1(4). * The control functions allowed in comments. See 2.1(14). * The representation for an end of line. See 2.2(2). * Maximum supported line length and lexical element length. See 2.2(14). * Implementation-defined pragmas. See 2.8(14). * Effect of pragma Optimize. See 2.8(27). * The sequence of characters of the value returned by S'Image when some of the graphic characters of S'Wide_Image are not defined in Character. See 3.5(37). * The predefined integer types declared in Standard. See 3.5.4(25). * Any nonstandard integer types and the operators defined for them. See 3.5.4(26). * Any nonstandard real types and the operators defined for them. See 3.5.6(8). * What combinations of requested decimal precision and range are supported for floating point types. See 3.5.7(7). * The predefined floating point types declared in Standard. See 3.5.7(16). * The ''small'' of an ordinary fixed point type. See 3.5.9(8). * What combinations of ''small'', range, and ''digits'' are supported for fixed point types. See 3.5.9(10). * The result of Tags.Expanded_Name for types declared within an unnamed block_statement. See 3.9(10). * Implementation-defined attributes. See 4.1.4(12/1). * Any implementation-defined time types. See 9.6(6). * The time base associated with relative delays. See 9.6(20). * The time base of the type Calendar.Time. See 9.6(23). * The timezone used for package Calendar operations. See 9.6(24). * Any limit on delay_until_statements of select_statements. See 9.6(29). * Whether or not two nonoverlapping parts of a composite object are independently addressable, in the case where packing, record layout, or Component_Size is specified for the object. See 9.10(1). * The representation for a compilation. See 10.1(2). * Any restrictions on compilations that contain multiple compilation_units. See 10.1(4). * The mechanisms for creating an environment and for adding and replacing compilation units. See 10.1.4(3). * The implementation-defined means, if any, of specifying which compilation units are needed by a given compilation unit. See 10.2(2). * The manner of explicitly assigning library units to a partition. See 10.2(2). * The manner of designating the main subprogram of a partition. See 10.2(7). * The order of elaboration of library_items. See 10.2(18). * Parameter passing and function return for the main subprogram. See 10.2(21). * The mechanisms for building and running partitions. See 10.2(24). * The details of program execution, including program termination. See 10.2(25). * The semantics of any nonactive partitions supported by the implementation. See 10.2(28). * The information returned by Exception_Message. See 11.4.1(10). * The result of Exceptions.Exception_Name for types declared within an unnamed block_statement. See 11.4.1(12). * The information returned by Exception_Information. See 11.4.1(13). * Implementation-defined check names. See 11.5(27). * Any restrictions placed upon representation items. See 13.1(20). * The interpretation of each aspect of representation. See 13.1(20). * The meaning of Size for indefinite subtypes. See 13.3(48). * The default external representation for a type tag. See 13.3(75/1). * What determines whether a compilation unit is the same in two different partitions. See 13.3(76). * Implementation-defined components. See 13.5.1(15). * If Word_Size = Storage_Unit, the default bit ordering. See 13.5.3(5). * The contents of the visible part of package System and its language-defined children. See 13.7(2). * The contents of the visible part of package System.Machine_Code, and the meaning of code_statements. See 13.8(7). * The effect of unchecked conversion. See 13.9(11). * Whether or not the implementation provides user-accessible names for the standard pool type(s). See 13.11(17). * The manner of choosing a storage pool for an access type when Storage_Pool is not specified for the type. See 13.11(17). * The meaning of Storage_Size. See 13.11(18). * Implementation-defined aspects of storage pools. See 13.11(22). * The set of restrictions allowed in a pragma Restrictions. See 13.12(7). * The consequences of violating limitations on Restrictions pragmas. See 13.12(9). * The representation used by the Read and Write attributes of elementary types in terms of stream elements. See 13.13.2(9). * The names and characteristics of the numeric subtypes declared in the visible part of package Standard. See A.1(3). * The accuracy actually achieved by the elementary functions. See A.5.1(1). * The sign of a zero result from some of the operators or functions in Numerics.Generic_Elementary_Functions, when Float_Type'Signed_Zeros is True. See A.5.1(46). * The value of Numerics.Discrete_Random.Max_Image_Width. See A.5.2(27). * The value of Numerics.Float_Random.Max_Image_Width. See A.5.2(27). * The algorithms for random number generation. See A.5.2(32). * The string representation of a random number generator's state. See A.5.2(38). * The minimum time interval between calls to the time-dependent Reset procedure that are guaranteed to initiate different random number sequences. See A.5.2(45). * The values of the Model_Mantissa, Model_Emin, Model_Epsilon, Model, Safe_First, and Safe_Last attributes, if the Numerics Annex is not supported. See A.5.3(72). * Any implementation-defined characteristics of the input-output packages. See A.7(14). * The value of Buffer_Size in Storage_IO. See A.9(10). * external files for standard input, standard output, and standard error See A.10(5). * The accuracy of the value produced by Put. See A.10.9(36). <div> * Current size for a stream file for which positioning is not supported. See A.12.1(1.1/1). </div> * The meaning of Argument_Count, Argument, and Command_Name. See A.15(1). * Implementation-defined convention names. See B.1(11). * The manner of choosing link names when neither the link name nor the address of an imported or exported entity is specified. See B.1(36). * The meaning of link names. See B.1(36). * The effect of pragma Linker_Options. See B.1(37). * The contents of the visible part of package Interfaces and its language-defined descendants. See B.2(1). * Implementation-defined children of package Interfaces. The contents of the visible part of package Interfaces. See B.2(11). <div> * The definitions of types and constants in Interfaces.C. See B.3(41). </div> * The types Floating, Long_Floating, Binary, Long_Binary, Decimal_Element, and COBOL_Character; and the initializations of the variables Ada_To_COBOL and COBOL_To_Ada, in Interfaces.COBOL. See B.4(50). <div> * The types Fortran_Integer, Real, Double_Precision, and Character_Set in Interfaces.Fortran. See B.5(17). </div> * Support for access to machine instructions. See C.1(1). * Implementation-defined aspects of access to machine operations. See C.1(9). * Implementation-defined aspects of interrupts. See C.3(2). * Implementation-defined aspects of preelaboration. See C.4(13). * The semantics of pragma Discard_Names. See C.5(7). * The result of the Task_Identification.Image attribute. See C.7.1(7). * The value of Current_Task when in a protected entry or interrupt handler. See C.7.1(17). * The effect of calling Current_Task from an entry body or interrupt handler. See C.7.1(19). <div> * Granularity of locking for Task_Attributes. See C.7.2(16/1). </div> * Limits on the number and size of task attributes, and how to configure them. See C.7.2(19). * Values of all Metrics. See D(2). * The declarations of Any_Priority and Priority. See D.1(11). * Implementation-defined execution resources. See D.1(15). * Whether, on a multiprocessor, a task that is waiting for access to a protected object keeps its processor busy. See D.2.1(3). * The affect of implementation defined execution resources on task dispatching. See D.2.1(9). * Implementation-defined ''policy_''<span id="I7271"></span>identifiers allowed in a pragma Task_Dispatching_Policy. See D.2.2(3). * Implementation-defined aspects of priority inversion. See D.2.2(16). * Implementation defined task dispatching. See D.2.2(18). * Implementation-defined ''policy_''<span id="I7272"></span>identifiers allowed in a pragma Locking_Policy. See D.3(4). * Default ceiling priorities. See D.3(10). * The ceiling of any protected object used internally by the implementation. See D.3(16). * Implementation-defined queuing policies. See D.4(1/1). * On a multiprocessor, any conditions that cause the completion of an aborted construct to be delayed later than what is specified for a single processor. See D.6(3). * Any operations that implicitly require heap storage allocation. See D.7(8). * Implementation-defined aspects of pragma Restrictions. See D.7(20). * Implementation-defined aspects of package Real_Time. See D.8(17). * Implementation-defined aspects of delay_statements. See D.9(8). * The upper bound on the duration of interrupt blocking caused by the implementation. See D.12(5). * The means for creating and executing distributed programs. See E(5). * Any events that can result in a partition becoming inaccessible. See E.1(7). * The scheduling policies, treatment of priorities, and management of shared resources between partitions in certain cases. See E.1(11). * ''This paragraph was deleted.'' * Whether the execution of the remote subprogram is immediately aborted as a result of cancellation. See E.4(13). * Implementation-defined aspects of the PCS. See E.5(25). * Implementation-defined interfaces in the PCS. See E.5(26). * The values of named numbers in the package Decimal. See F.2(7). * The value of Max_Picture_Length in the package Text_IO.Editing See F.3.3(16). * The value of Max_Picture_Length in the package Wide_Text_IO.Editing See F.3.4(5). * The accuracy actually achieved by the complex elementary functions and by other complex arithmetic operations. See G.1(1). * The sign of a zero result (or a component thereof) from any operator or function in Numerics.Generic_Complex_Types, when Real'Signed_Zeros is True. See G.1.1(53). * The sign of a zero result (or a component thereof) from any operator or function in Numerics.Generic_Complex_Elementary_Functions, when Complex_Types.Real'Signed_Zeros is True. See G.1.2(45). * Whether the strict mode or the relaxed mode is the default. See G.2(2). * The result interval in certain cases of fixed-to-float conversion. See G.2.1(10). * The result of a floating point arithmetic operation in overflow situations, when the Machine_Overflows attribute of the result type is False. See G.2.1(13). * The result interval for division (or exponentiation by a negative exponent), when the floating point hardware implements division as multiplication by a reciprocal. See G.2.1(16). * The definition of ''close result set'', which determines the accuracy of certain fixed point multiplications and divisions. See G.2.3(5). * Conditions on a ''universal_real'' operand of a fixed point multiplication or division for which the result shall be in the ''perfect result set''. See G.2.3(22). * The result of a fixed point arithmetic operation in overflow situations, when the Machine_Overflows attribute of the result type is False. See G.2.3(27). * The result of an elementary function reference in overflow situations, when the Machine_Overflows attribute of the result type is False. See G.2.4(4). * The accuracy of certain elementary functions for parameters beyond the angle threshold. See G.2.4(10). * The value of the ''angle threshold'', within which certain elementary functions, complex arithmetic operations, and complex elementary functions yield results conforming to a maximum relative error bound. See G.2.4(10). * The result of a complex arithmetic operation or complex elementary function reference in overflow situations, when the Machine_Overflows attribute of the corresponding real type is False. See G.2.6(5). * The accuracy of certain complex arithmetic operations and certain complex elementary functions for parameters (or components thereof) beyond the angle threshold. See G.2.6(8). * Information regarding bounded errors and erroneous execution. See H.2(1). * Implementation-defined aspects of pragma Inspection_Point. See H.3.2(8). * Implementation-defined aspects of pragma Restrictions. See H.4(25). * Any restrictions on pragma Restrictions. See H.4(27). </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-L|Previous]] | [[Guide:95lrm/RM-N|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} 63d2fqwwen0ipqgo0u55hoxtfwbgeo6 Guide:95lrm/RM-N 4200 1202 4474 2019-05-02T10:21:38Z imported>WikiVisor 0 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-M|Previous]] | [[Guide:95lrm/RM-P|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Annex N. Glossary}} <div>(informative)</div> <span id="I7273"></span>This Annex contains informal descriptions of some terms used in this International Standard. To find more formal definitions, look the term up in the index. <span id="I7274"></span>'''Access type.''' An access type has values that designate aliased objects. Access types correspond to ''pointer types'' or ''reference types'' in some other languages. '''Aliased.''' An aliased view of an object is one that can be designated by an access value. Objects allocated by allocators are aliased. Objects can also be explicitly declared as aliased with the reserved word '''aliased'''. The Access attribute can be used to create an access value designating an aliased object. '''Array type.''' An array type is a composite type whose components are all of the same type. Components are selected by indexing. '''Character type.''' A character type is an enumeration type whose values include characters. '''Class.''' <span id="I7275"></span>A class is a set of types that is closed under derivation, which means that if a given type is in the class, then all types derived from that type are also in the class. The set of types of a class share common properties, such as their primitive operations. '''Compilation unit.''' The text of a program can be submitted to the compiler in one or more compilations. Each compilation is a succession of compilation_units. A compilation_unit contains either the declaration, the body, or a renaming of a program unit. '''Composite type.''' A composite type has components. '''Construct.''' A ''construct'' is a piece of text (explicit or implicit) that is an instance of a syntactic category defined under ''Syntax.'' '''Controlled type.''' A controlled type supports user-defined assignment and finalization. Objects are always finalized before being destroyed. '''Declaration.''' A ''declaration'' is a language construct that associates a name with (a view of) an entity. <span id="I7276"></span><span id="I7277"></span>A declaration may appear explicitly in the program text (an ''explicit'' declaration), or may be supposed to occur at a given place in the text as a consequence of the semantics of another construct (an ''implicit'' declaration). '''Definition.''' <span id="I7278"></span>All declarations contain a ''definition'' for a ''view'' of an entity. A view consists of an identification of the entity (the entity ''of'' the view), plus view-specific characteristics that affect the use of the entity through that view (such as mode of access to an object, formal parameter names and defaults for a subprogram, or visibility to components of a type). In most cases, a declaration also contains the definition for the entity itself (a renaming_declaration is an example of a declaration that does not define a new entity, but instead defines a view of an existing entity (see [[Guide:95lrm/RM-8-5|8.5]])). '''Derived type.''' A derived type is a type defined in terms of another type, which is the parent type of the derived type. Each class containing the parent type also contains the derived type. The derived type inherits properties such as components and primitive operations from the parent. A type together with the types derived from it (directly or indirectly) form a derivation class. '''Discrete type.''' A discrete type is either an integer type or an enumeration type. Discrete types may be used, for example, in case_statements and as array indices. '''Discriminant.''' A discriminant is a parameter of a composite type. It can control, for example, the bounds of a component of the type if that type is an array type. A discriminant of a task type can be used to pass data to a task of the type upon creation. '''Elementary type.''' An elementary type does not have components. '''Enumeration type.''' An enumeration type is defined by an enumeration of its values, which may be named by identifiers or character literals. '''Exception.''' An ''exception'' represents a kind of exceptional situation; an occurrence of such a situation (at run time) is called an ''exception occurrence''. <span id="I7279"></span>To ''raise'' an exception is to abandon normal program execution so as to draw attention to the fact that the corresponding situation has arisen. <span id="I7280"></span>Performing some actions in response to the arising of an exception is called ''handling'' the exception. '''Execution.''' The process by which a construct achieves its run-time effect is called ''execution''. <span id="I7281"></span><span id="I7282"></span>Execution of a declaration is also called ''elaboration''. Execution of an expression is also called ''evaluation''. '''Generic unit.''' A generic unit is a template for a (nongeneric) program unit; the template can be parameterized by objects, types, subprograms, and packages. An instance of a generic unit is created by a generic_instantiation. The rules of the language are enforced when a generic unit is compiled, using a generic contract model; additional checks are performed upon instantiation to verify the contract is met. That is, the declaration of a generic unit represents a contract between the body of the generic and instances of the generic. Generic units can be used to perform the role that macros sometimes play in other languages. '''Integer type.''' Integer types comprise the signed integer types and the modular types. A signed integer type has a base range that includes both positive and negative numbers, and has operations that may raise an exception when the result is outside the base range. A modular type has a base range whose lower bound is zero, and has operations with ''wraparound'' semantics. Modular types subsume what are called ''unsigned types'' in some other languages. '''Library unit.''' A library unit is a separately compiled program unit, and is always a package, subprogram, or generic unit. Library units may have other (logically nested) library units as children, and may have other program units physically nested within them. <span id="I7283"></span>A root library unit, together with its children and grandchildren and so on, form a ''subsystem''. '''Limited type.''' A limited type is (a view of) a type for which the assignment operation is not allowed. A nonlimited type is a (view of a) type for which the assignment operation is allowed. '''Object.''' An object is either a constant or a variable. An object contains a value. An object is created by an object_declaration or by an allocator. A formal parameter is (a view of) an object. A subcomponent of an object is an object. '''Package.''' Packages are program units that allow the specification of groups of logically related entities. Typically, a package contains the declaration of a type (often a private type or private extension) along with the declarations of primitive subprograms of the type, which can be called from outside the package, while their inner workings remain hidden from outside users. '''Partition.''' A ''partition'' is a part of a program. Each partition consists of a set of library units. Each partition may run in a separate address space, possibly on a separate computer. A program may contain just one partition. A distributed program typically contains multiple partitions, which can execute concurrently. '''Pragma.''' A pragma is a compiler directive. There are language-defined pragmas that give instructions for optimization, listing control, etc. An implementation may support additional (implementation-defined) pragmas. '''Primitive operations.''' The primitive operations of a type are the operations (such as subprograms) declared together with the type declaration. They are inherited by other types in the same class of types. For a tagged type, the primitive subprograms are dispatching subprograms, providing run-time polymorphism. A dispatching subprogram may be called with statically tagged operands, in which case the subprogram body invoked is determined at compile time. Alternatively, a dispatching subprogram may be called using a dispatching call, in which case the subprogram body invoked is determined at run time. '''Private extension.''' A private extension is like a record extension, except that the components of the extension part are hidden from its clients. '''Private type.''' A private type is a partial view of a type whose full view is hidden from its clients. '''Program.''' A ''program'' is a set of ''partitions'', each of which may execute in a separate address space, possibly on a separate computer. A partition consists of a set of library units. '''Program unit.''' A ''program unit'' is either a package, a task unit, a protected unit, a protected entry, a generic unit, or an explicitly declared subprogram other than an enumeration literal. Certain kinds of program units can be separately compiled. Alternatively, they can appear physically nested within other program units. '''Protected type.''' A protected type is a composite type whose components are protected from concurrent access by multiple tasks. '''Real type.''' A real type has values that are approximations of the real numbers. Floating point and fixed point types are real types. '''Record extension.''' A record extension is a type that extends another type by adding additional components. '''Record type.''' A record type is a composite type consisting of zero or more named components, possibly of different types. '''Scalar type.''' A scalar type is either a discrete type or a real type. '''Subtype.''' A subtype is a type together with a constraint, which constrains the values of the subtype to satisfy a certain condition. The values of a subtype are a subset of the values of its type. '''Tagged type.''' The objects of a tagged type have a run-time type tag, which indicates the specific type with which the object was originally created. An operand of a class-wide tagged type can be used in a dispatching call; the tag indicates which subprogram body to invoke. Nondispatching calls, in which the subprogram body to invoke is determined at compile time, are also allowed. Tagged types may be extended with additional components. '''Task type.''' A task type is a composite type whose values are tasks, which are active entities that may execute concurrently with other tasks. The top-level task of a partition is called the environment task. '''Type.''' Each object has a type. A ''type'' has an associated set of values, and a set of ''primitive operations'' which implement the fundamental aspects of its semantics. Types are grouped into ''classes''. The types of a given class share a set of primitive operations. <span id="I7284"></span>Classes are closed under derivation; that is, if a type is in a class, then all of its derivatives are in that class. '''View.''' (See '''Definition'''.) </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-M|Previous]] | [[Guide:95lrm/RM-P|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} pn8y2fzhxnxbgpvbrf63ef2s9swjutr Guide:95lrm/RM-P 4200 1203 4499 4475 2019-05-06T00:00:13Z WikiVisor 11 Text replacement - "|Next]] [[Guide:95lrm/RM-TTL|Legal]]" to "|Next]] | [[Guide:95lrm/RM-TTL|Legal]]" wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] [[Guide:95lrm/RM-0-29|Index]] [[Guide:95lrm/RM-N|Previous]] [[Guide:95lrm/RM-0-29|Next]]</div><div class="linenumbers">{{DISPLAYTITLE: Annex P. Syntax Summary}} <div>(informative)</div> <div> <span id="I7285"></span><span id="I7286"></span><span id="I7287"></span><span id="I7288"></span><span id="I7289"></span>This Annex summarizes the complete syntax of the language. See [[Guide:95lrm/RM-1-1-4|1.1.4]] for a description of the notation used. ;[[Guide:95lrm/RM-2-1|2.1]] character::= <span id="I7290"></span>graphic_character | <span id="I7291"></span>format_effector | <span id="I7292"></span>other_control_function ;[[Guide:95lrm/RM-2-1|2.1]] graphic_character::= <span id="I7293"></span>identifier_letter | <span id="I7294"></span>digit | <span id="I7295"></span>space_character | <span id="I7296"></span>special_character ;[[Guide:95lrm/RM-2-3|2.3]] identifier::= <span id="I7297"></span>identifier_letter {[<span id="I7298"></span>underline] <span id="I7299"></span>letter_or_digit} ;[[Guide:95lrm/RM-2-3|2.3]] letter_or_digit::= <span id="I7300"></span>identifier_letter | <span id="I7301"></span>digit ;[[Guide:95lrm/RM-2-4|2.4]] numeric_literal::= <span id="I7302"></span>decimal_literal | <span id="I7303"></span>based_literal ;[[Guide:95lrm/RM-2-4-1|2.4.1]] decimal_literal::= <span id="I7304"></span>numeral [.<span id="I7305"></span>numeral] [<span id="I7306"></span>exponent] ;[[Guide:95lrm/RM-2-4-1|2.4.1]] numeral::= <span id="I7307"></span>digit {[<span id="I7308"></span>underline] <span id="I7309"></span>digit} ;[[Guide:95lrm/RM-2-4-1|2.4.1]] exponent::= E [+] <span id="I7310"></span>numeral | E - <span id="I7311"></span>numeral ;[[Guide:95lrm/RM-2-4-2|2.4.2]] based_literal::= <span id="I7312"></span>base # <span id="I7313"></span>based_numeral [.<span id="I7314"></span>based_numeral] # [<span id="I7315"></span>exponent] ;[[Guide:95lrm/RM-2-4-2|2.4.2]] base::= <span id="I7316"></span>numeral ;[[Guide:95lrm/RM-2-4-2|2.4.2]] based_numeral::= <span id="I7317"></span>extended_digit {[<span id="I7318"></span>underline] <span id="I7319"></span>extended_digit} ;[[Guide:95lrm/RM-2-4-2|2.4.2]] extended_digit::= <span id="I7320"></span>digit | A | B | C | D | E | F ;[[Guide:95lrm/RM-2-5|2.5]] character_literal::= '<span id="I7321"></span>graphic_character' ;[[Guide:95lrm/RM-2-6|2.6]] string_literal::= "{<span id="I7322"></span>string_element}" ;[[Guide:95lrm/RM-2-6|2.6]] string_element::= "" | ''non_quotation_mark_''<span id="I7323"></span>graphic_character ;[[Guide:95lrm/RM-2-7|2.7]] comment::= --{''non_end_of_line_''<span id="I7324"></span>character} ;[[Guide:95lrm/RM-2-8|2.8]] pragma::= '''pragma''' <span id="I7325"></span>identifier [(<span id="I7326"></span>pragma_argument_association {, <span id="I7327"></span>pragma_argument_association})]; ;[[Guide:95lrm/RM-2-8|2.8]] pragma_argument_association::= [''pragma_argument_''<span id="I7328"></span>identifier =>] <span id="I7329"></span>name | [''pragma_argument_''<span id="I7330"></span>identifier =>] <span id="I7331"></span>expression ;[[Guide:95lrm/RM-3-1|3.1]] basic_declaration::= <span id="I7332"></span>type_declaration | <span id="I7333"></span>subtype_declaration | <span id="I7334"></span>object_declaration | <span id="I7335"></span>number_declaration | <span id="I7336"></span>subprogram_declaration | <span id="I7337"></span>abstract_subprogram_declaration | <span id="I7338"></span>package_declaration | <span id="I7339"></span>renaming_declaration | <span id="I7340"></span>exception_declaration | <span id="I7341"></span>generic_declaration | <span id="I7342"></span>generic_instantiation ;[[Guide:95lrm/RM-3-1|3.1]] defining_identifier::= <span id="I7343"></span>identifier ;[[Guide:95lrm/RM-3-2-1|3.2.1]] type_declaration::= <span id="I7344"></span>full_type_declaration | <span id="I7345"></span>incomplete_type_declaration | <span id="I7346"></span>private_type_declaration | <span id="I7347"></span>private_extension_declaration ;[[Guide:95lrm/RM-3-2-1|3.2.1]] full_type_declaration::= '''type''' <span id="I7348"></span>defining_identifier [<span id="I7349"></span>known_discriminant_part] '''is''' <span id="I7350"></span>type_definition; | <span id="I7351"></span>task_type_declaration | <span id="I7352"></span>protected_type_declaration ;[[Guide:95lrm/RM-3-2-1|3.2.1]] type_definition::= <span id="I7353"></span>enumeration_type_definition | <span id="I7354"></span>integer_type_definition | <span id="I7355"></span>real_type_definition | <span id="I7356"></span>array_type_definition | <span id="I7357"></span>record_type_definition | <span id="I7358"></span>access_type_definition | <span id="I7359"></span>derived_type_definition ;[[Guide:95lrm/RM-3-2-2|3.2.2]] subtype_declaration::= '''subtype''' <span id="I7360"></span>defining_identifier '''is''' <span id="I7361"></span>subtype_indication; ;[[Guide:95lrm/RM-3-2-2|3.2.2]] subtype_indication::= <span id="I7362"></span>subtype_mark [<span id="I7363"></span>constraint] ;[[Guide:95lrm/RM-3-2-2|3.2.2]] subtype_mark::= ''subtype_''<span id="I7364"></span>name ;[[Guide:95lrm/RM-3-2-2|3.2.2]] constraint::= <span id="I7365"></span>scalar_constraint | <span id="I7366"></span>composite_constraint ;[[Guide:95lrm/RM-3-2-2|3.2.2]] scalar_constraint::= <span id="I7367"></span>range_constraint | <span id="I7368"></span>digits_constraint | <span id="I7369"></span>delta_constraint ;[[Guide:95lrm/RM-3-2-2|3.2.2]] composite_constraint::= <span id="I7370"></span>index_constraint | <span id="I7371"></span>discriminant_constraint ;[[Guide:95lrm/RM-3-3-1|3.3.1]] object_declaration::= <span id="I7372"></span>defining_identifier_list : ['''aliased'''] ['''constant'''] <span id="I7373"></span>subtype_indication [:= <span id="I7374"></span>expression]; | <span id="I7375"></span>defining_identifier_list : ['''aliased'''] ['''constant'''] <span id="I7376"></span>array_type_definition [:= <span id="I7377"></span>expression]; | <span id="I7378"></span>single_task_declaration | <span id="I7379"></span>single_protected_declaration ;[[Guide:95lrm/RM-3-3-1|3.3.1]] defining_identifier_list::= <span id="I7380"></span>defining_identifier {, <span id="I7381"></span>defining_identifier} ;[[Guide:95lrm/RM-3-3-2|3.3.2]] number_declaration::= <span id="I7382"></span>defining_identifier_list : '''constant''' := ''static_''<span id="I7383"></span>expression; ;[[Guide:95lrm/RM-3-4|3.4]] derived_type_definition::= ['''abstract'''] '''new''' ''parent_''<span id="I7384"></span>subtype_indication [<span id="I7385"></span>record_extension_part] ;[[Guide:95lrm/RM-3-5|3.5]] range_constraint::= '''range''' <span id="I7386"></span>range ;[[Guide:95lrm/RM-3-5|3.5]] range::= <span id="I7387"></span>range_attribute_reference | <span id="I7388"></span>simple_expression .. <span id="I7389"></span>simple_expression ;[[Guide:95lrm/RM-3-5-1|3.5.1]] enumeration_type_definition::= (<span id="I7390"></span>enumeration_literal_specification {, <span id="I7391"></span>enumeration_literal_specification}) ;[[Guide:95lrm/RM-3-5-1|3.5.1]] enumeration_literal_specification::= <span id="I7392"></span>defining_identifier | <span id="I7393"></span>defining_character_literal ;[[Guide:95lrm/RM-3-5-1|3.5.1]] defining_character_literal::= <span id="I7394"></span>character_literal ;[[Guide:95lrm/RM-3-5-4|3.5.4]] integer_type_definition::= <span id="I7395"></span>signed_integer_type_definition | <span id="I7396"></span>modular_type_definition ;[[Guide:95lrm/RM-3-5-4|3.5.4]] signed_integer_type_definition::= '''range''' ''static_''<span id="I7397"></span>simple_expression .. ''static_''<span id="I7398"></span>simple_expression ;[[Guide:95lrm/RM-3-5-4|3.5.4]] modular_type_definition::= '''mod''' ''static_''<span id="I7399"></span>expression ;[[Guide:95lrm/RM-3-5-6|3.5.6]] real_type_definition::= <span id="I7400"></span>floating_point_definition | <span id="I7401"></span>fixed_point_definition ;[[Guide:95lrm/RM-3-5-7|3.5.7]] floating_point_definition::= '''digits''' ''static_''<span id="I7402"></span>expression [<span id="I7403"></span>real_range_specification] ;[[Guide:95lrm/RM-3-5-7|3.5.7]] real_range_specification::= '''range''' ''static_''<span id="I7404"></span>simple_expression .. ''static_''<span id="I7405"></span>simple_expression ;[[Guide:95lrm/RM-3-5-9|3.5.9]] fixed_point_definition::= <span id="I7406"></span>ordinary_fixed_point_definition | <span id="I7407"></span>decimal_fixed_point_definition ;[[Guide:95lrm/RM-3-5-9|3.5.9]] ordinary_fixed_point_definition::= '''delta''' ''static_''<span id="I7408"></span>expression <span id="I7409"></span>real_range_specification ;[[Guide:95lrm/RM-3-5-9|3.5.9]] decimal_fixed_point_definition::= '''delta''' ''static_''<span id="I7410"></span>expression '''digits''' ''static_''<span id="I7411"></span>expression [<span id="I7412"></span>real_range_specification] ;[[Guide:95lrm/RM-3-5-9|3.5.9]] digits_constraint::= '''digits''' ''static_''<span id="I7413"></span>expression [<span id="I7414"></span>range_constraint] ;[[Guide:95lrm/RM-3-6|3.6]] array_type_definition::= <span id="I7415"></span>unconstrained_array_definition | <span id="I7416"></span>constrained_array_definition ;[[Guide:95lrm/RM-3-6|3.6]] unconstrained_array_definition::= '''array'''(<span id="I7417"></span>index_subtype_definition {, <span id="I7418"></span>index_subtype_definition}) '''of''' <span id="I7419"></span>component_definition ;[[Guide:95lrm/RM-3-6|3.6]] index_subtype_definition::= <span id="I7420"></span>subtype_mark '''range''' <> ;[[Guide:95lrm/RM-3-6|3.6]] constrained_array_definition::= '''array''' (<span id="I7421"></span>discrete_subtype_definition {, <span id="I7422"></span>discrete_subtype_definition}) '''of''' <span id="I7423"></span>component_definition ;[[Guide:95lrm/RM-3-6|3.6]] discrete_subtype_definition::= ''discrete_''<span id="I7424"></span>subtype_indication | <span id="I7425"></span>range ;[[Guide:95lrm/RM-3-6|3.6]] component_definition::= ['''aliased'''] <span id="I7426"></span>subtype_indication ;[[Guide:95lrm/RM-3-6-1|3.6.1]] index_constraint::= (<span id="I7427"></span>discrete_range {, <span id="I7428"></span>discrete_range}) ;[[Guide:95lrm/RM-3-6-1|3.6.1]] discrete_range::= ''discrete_''<span id="I7429"></span>subtype_indication | <span id="I7430"></span>range ;[[Guide:95lrm/RM-3-7|3.7]] discriminant_part::= <span id="I7431"></span>unknown_discriminant_part | <span id="I7432"></span>known_discriminant_part ;[[Guide:95lrm/RM-3-7|3.7]] unknown_discriminant_part::= (<>) ;[[Guide:95lrm/RM-3-7|3.7]] known_discriminant_part::= (<span id="I7433"></span>discriminant_specification {; <span id="I7434"></span>discriminant_specification}) ;[[Guide:95lrm/RM-3-7|3.7]] discriminant_specification::= <span id="I7435"></span>defining_identifier_list : <span id="I7436"></span>subtype_mark [:= <span id="I7437"></span>default_expression] | <span id="I7438"></span>defining_identifier_list : <span id="I7439"></span>access_definition [:= <span id="I7440"></span>default_expression] ;[[Guide:95lrm/RM-3-7|3.7]] default_expression::= <span id="I7441"></span>expression ;[[Guide:95lrm/RM-3-7-1|3.7.1]] discriminant_constraint::= (<span id="I7442"></span>discriminant_association {, <span id="I7443"></span>discriminant_association}) ;[[Guide:95lrm/RM-3-7-1|3.7.1]] discriminant_association::= [''discriminant_''<span id="I7444"></span>selector_name {| ''discriminant_''<span id="I7445"></span>selector_name} =>] <span id="I7446"></span>expression ;[[Guide:95lrm/RM-3-8|3.8]] record_type_definition::= [['''abstract'''] '''tagged'''] ['''limited'''] <span id="I7447"></span>record_definition ;[[Guide:95lrm/RM-3-8|3.8]] record_definition::= '''record''' <span id="I7448"></span>component_list '''end''' '''record''' | '''null record''' ;[[Guide:95lrm/RM-3-8|3.8]] component_list::= <span id="I7449"></span>component_item {<span id="I7450"></span>component_item} | {<span id="I7451"></span>component_item} <span id="I7452"></span>variant_part | '''null'''; ;[[Guide:95lrm/RM-3-8|3.8]] component_item::= <span id="I7453"></span>component_declaration | <span id="I7454"></span>aspect_clause ;[[Guide:95lrm/RM-3-8|3.8]] component_declaration::= <span id="I7455"></span>defining_identifier_list : <span id="I7456"></span>component_definition [:= <span id="I7457"></span>default_expression]; ;[[Guide:95lrm/RM-3-8-1|3.8.1]] variant_part::= '''case''' ''discriminant_''<span id="I7458"></span>direct_name '''is''' <span id="I7459"></span>variant {<span id="I7460"></span>variant} '''end''' '''case'''; ;[[Guide:95lrm/RM-3-8-1|3.8.1]] variant::= '''when''' <span id="I7461"></span>discrete_choice_list => <span id="I7462"></span>component_list ;[[Guide:95lrm/RM-3-8-1|3.8.1]] discrete_choice_list::= <span id="I7463"></span>discrete_choice {| <span id="I7464"></span>discrete_choice} ;[[Guide:95lrm/RM-3-8-1|3.8.1]] discrete_choice::= <span id="I7465"></span>expression | <span id="I7466"></span>discrete_range | '''others''' ;[[Guide:95lrm/RM-3-9-1|3.9.1]] record_extension_part::= '''with''' <span id="I7467"></span>record_definition ;[[Guide:95lrm/RM-3-10|3.10]] access_type_definition::= <span id="I7468"></span>access_to_object_definition | <span id="I7469"></span>access_to_subprogram_definition ;[[Guide:95lrm/RM-3-10|3.10]] access_to_object_definition::= '''access''' [<span id="I7470"></span>general_access_modifier] <span id="I7471"></span>subtype_indication ;[[Guide:95lrm/RM-3-10|3.10]] general_access_modifier::= '''all''' | '''constant''' ;[[Guide:95lrm/RM-3-10|3.10]] access_to_subprogram_definition::= '''access''' ['''protected'''] '''procedure''' <span id="I7472"></span>parameter_profile | '''access''' ['''protected'''] '''function''' <span id="I7473"></span>parameter_and_result_profile ;[[Guide:95lrm/RM-3-10|3.10]] access_definition::= '''access''' <span id="I7474"></span>subtype_mark ;[[Guide:95lrm/RM-3-10-1|3.10.1]] incomplete_type_declaration::= '''type''' <span id="I7475"></span>defining_identifier [<span id="I7476"></span>discriminant_part]; ;[[Guide:95lrm/RM-3-11|3.11]] declarative_part::= {<span id="I7477"></span>declarative_item} ;[[Guide:95lrm/RM-3-11|3.11]] declarative_item::= <span id="I7478"></span>basic_declarative_item | <span id="I7479"></span>body ;[[Guide:95lrm/RM-3-11|3.11]] basic_declarative_item::= <span id="I7480"></span>basic_declaration | <span id="I7481"></span>aspect_clause | <span id="I7482"></span>use_clause ;[[Guide:95lrm/RM-3-11|3.11]] body::= <span id="I7483"></span>proper_body | <span id="I7484"></span>body_stub ;[[Guide:95lrm/RM-3-11|3.11]] proper_body::= <span id="I7485"></span>subprogram_body | <span id="I7486"></span>package_body | <span id="I7487"></span>task_body | <span id="I7488"></span>protected_body ;[[Guide:95lrm/RM-4-1|4.1]] name::= <span id="I7489"></span>direct_name | <span id="I7490"></span>explicit_dereference | <span id="I7491"></span>indexed_component | <span id="I7492"></span>slice | <span id="I7493"></span>selected_component | <span id="I7494"></span>attribute_reference | <span id="I7495"></span>type_conversion | <span id="I7496"></span>function_call | <span id="I7497"></span>character_literal ;[[Guide:95lrm/RM-4-1|4.1]] direct_name::= <span id="I7498"></span>identifier | <span id="I7499"></span>operator_symbol ;[[Guide:95lrm/RM-4-1|4.1]] prefix::= <span id="I7500"></span>name | <span id="I7501"></span>implicit_dereference ;[[Guide:95lrm/RM-4-1|4.1]] explicit_dereference::= <span id="I7502"></span>name.'''all''' ;[[Guide:95lrm/RM-4-1|4.1]] implicit_dereference::= <span id="I7503"></span>name ;[[Guide:95lrm/RM-4-1-1|4.1.1]] indexed_component::= <span id="I7504"></span>prefix(<span id="I7505"></span>expression {, <span id="I7506"></span>expression}) ;[[Guide:95lrm/RM-4-1-2|4.1.2]] slice::= <span id="I7507"></span>prefix(<span id="I7508"></span>discrete_range) ;[[Guide:95lrm/RM-4-1-3|4.1.3]] selected_component::= <span id="I7509"></span>prefix . <span id="I7510"></span>selector_name ;[[Guide:95lrm/RM-4-1-3|4.1.3]] selector_name::= <span id="I7511"></span>identifier | <span id="I7512"></span>character_literal | <span id="I7513"></span>operator_symbol ;[[Guide:95lrm/RM-4-1-4|4.1.4]] attribute_reference::= <span id="I7514"></span>prefix'<span id="I7515"></span>attribute_designator ;[[Guide:95lrm/RM-4-1-4|4.1.4]] attribute_designator::= <span id="I7516"></span>identifier[(''static_''<span id="I7517"></span>expression)] | Access | Delta | Digits ;[[Guide:95lrm/RM-4-1-4|4.1.4]] range_attribute_reference::= <span id="I7518"></span>prefix'<span id="I7519"></span>range_attribute_designator ;[[Guide:95lrm/RM-4-1-4|4.1.4]] range_attribute_designator::= Range[(''static_''<span id="I7520"></span>expression)] ;[[Guide:95lrm/RM-4-3|4.3]] aggregate::= <span id="I7521"></span>record_aggregate | <span id="I7522"></span>extension_aggregate | <span id="I7523"></span>array_aggregate ;[[Guide:95lrm/RM-4-3-1|4.3.1]] record_aggregate::= (<span id="I7524"></span>record_component_association_list) ;[[Guide:95lrm/RM-4-3-1|4.3.1]] record_component_association_list::= <span id="I7525"></span>record_component_association {, <span id="I7526"></span>record_component_association} | '''null record''' ;[[Guide:95lrm/RM-4-3-1|4.3.1]] record_component_association::= [ <span id="I7527"></span>component_choice_list => ] <span id="I7528"></span>expression ;[[Guide:95lrm/RM-4-3-1|4.3.1]] component_choice_list::= ''component_''<span id="I7529"></span>selector_name {| ''component_''<span id="I7530"></span>selector_name} | '''others''' ;[[Guide:95lrm/RM-4-3-2|4.3.2]] extension_aggregate::= (<span id="I7531"></span>ancestor_part '''with''' <span id="I7532"></span>record_component_association_list) ;[[Guide:95lrm/RM-4-3-2|4.3.2]] ancestor_part::= <span id="I7533"></span>expression | <span id="I7534"></span>subtype_mark ;[[Guide:95lrm/RM-4-3-3|4.3.3]] array_aggregate::= <span id="I7535"></span>positional_array_aggregate | <span id="I7536"></span>named_array_aggregate ;[[Guide:95lrm/RM-4-3-3|4.3.3]] positional_array_aggregate::= (<span id="I7537"></span>expression, <span id="I7538"></span>expression {, <span id="I7539"></span>expression}) | (<span id="I7540"></span>expression {, <span id="I7541"></span>expression}, '''others''' => <span id="I7542"></span>expression) ;[[Guide:95lrm/RM-4-3-3|4.3.3]] named_array_aggregate::= (<span id="I7543"></span>array_component_association {, <span id="I7544"></span>array_component_association}) ;[[Guide:95lrm/RM-4-3-3|4.3.3]] array_component_association::= <span id="I7545"></span>discrete_choice_list => <span id="I7546"></span>expression ;[[Guide:95lrm/RM-4-4|4.4]] expression::= <span id="I7547"></span>relation {'''and''' <span id="I7548"></span>relation} | <span id="I7549"></span>relation {'''and''' '''then''' <span id="I7550"></span>relation} | <span id="I7551"></span>relation {'''or''' <span id="I7552"></span>relation} | <span id="I7553"></span>relation {'''or''' '''else''' <span id="I7554"></span>relation} | <span id="I7555"></span>relation {'''xor''' <span id="I7556"></span>relation} ;[[Guide:95lrm/RM-4-4|4.4]] relation::= <span id="I7557"></span>simple_expression [<span id="I7558"></span>relational_operator <span id="I7559"></span>simple_expression] | <span id="I7560"></span>simple_expression ['''not'''] '''in''' <span id="I7561"></span>range | <span id="I7562"></span>simple_expression ['''not'''] '''in''' <span id="I7563"></span>subtype_mark ;[[Guide:95lrm/RM-4-4|4.4]] simple_expression::= [<span id="I7564"></span>unary_adding_operator] <span id="I7565"></span>term {<span id="I7566"></span>binary_adding_operator <span id="I7567"></span>term} ;[[Guide:95lrm/RM-4-4|4.4]] term::= <span id="I7568"></span>factor {<span id="I7569"></span>multiplying_operator <span id="I7570"></span>factor} ;[[Guide:95lrm/RM-4-4|4.4]] factor::= <span id="I7571"></span>primary [** <span id="I7572"></span>primary] | '''abs''' <span id="I7573"></span>primary | '''not''' <span id="I7574"></span>primary ;[[Guide:95lrm/RM-4-4|4.4]] primary::= <span id="I7575"></span>numeric_literal | '''null''' | <span id="I7576"></span>string_literal | <span id="I7577"></span>aggregate | <span id="I7578"></span>name | <span id="I7579"></span>qualified_expression | <span id="I7580"></span>allocator | (<span id="I7581"></span>expression) ;[[Guide:95lrm/RM-4-5|4.5]] logical_operator::= '''and''' | '''or''' | '''xor''' ;[[Guide:95lrm/RM-4-5|4.5]] relational_operator::= = | /= | < | <= | > | >= ;[[Guide:95lrm/RM-4-5|4.5]] binary_adding_operator::= + | - | & ;[[Guide:95lrm/RM-4-5|4.5]] unary_adding_operator::= + | - ;[[Guide:95lrm/RM-4-5|4.5]] multiplying_operator::= * | / | '''mod''' | '''rem''' ;[[Guide:95lrm/RM-4-5|4.5]] highest_precedence_operator::= ** | '''abs''' | '''not''' ;[[Guide:95lrm/RM-4-6|4.6]] type_conversion::= <span id="I7582"></span>subtype_mark(<span id="I7583"></span>expression) | <span id="I7584"></span>subtype_mark(<span id="I7585"></span>name) ;[[Guide:95lrm/RM-4-7|4.7]] qualified_expression::= <span id="I7586"></span>subtype_mark'(<span id="I7587"></span>expression) | <span id="I7588"></span>subtype_mark'<span id="I7589"></span>aggregate ;[[Guide:95lrm/RM-4-8|4.8]] allocator::= '''new''' <span id="I7590"></span>subtype_indication | '''new''' <span id="I7591"></span>qualified_expression ;[[Guide:95lrm/RM-5-1|5.1]] sequence_of_statements::= <span id="I7592"></span>statement {<span id="I7593"></span>statement} ;[[Guide:95lrm/RM-5-1|5.1]] statement::= {<span id="I7594"></span>label} <span id="I7595"></span>simple_statement | {<span id="I7596"></span>label} <span id="I7597"></span>compound_statement ;[[Guide:95lrm/RM-5-1|5.1]] simple_statement::= <span id="I7598"></span>null_statement | <span id="I7599"></span>assignment_statement | <span id="I7600"></span>exit_statement | <span id="I7601"></span>goto_statement | <span id="I7602"></span>procedure_call_statement | <span id="I7603"></span>return_statement | <span id="I7604"></span>entry_call_statement | <span id="I7605"></span>requeue_statement | <span id="I7606"></span>delay_statement | <span id="I7607"></span>abort_statement | <span id="I7608"></span>raise_statement | <span id="I7609"></span>code_statement ;[[Guide:95lrm/RM-5-1|5.1]] compound_statement::= <span id="I7610"></span>if_statement | <span id="I7611"></span>case_statement | <span id="I7612"></span>loop_statement | <span id="I7613"></span>block_statement | <span id="I7614"></span>accept_statement | <span id="I7615"></span>select_statement ;[[Guide:95lrm/RM-5-1|5.1]] null_statement::= '''null'''; ;[[Guide:95lrm/RM-5-1|5.1]] label::= <<''label_''<span id="I7616"></span>statement_identifier>> ;[[Guide:95lrm/RM-5-1|5.1]] statement_identifier::= <span id="I7617"></span>direct_name ;[[Guide:95lrm/RM-5-2|5.2]] assignment_statement::= ''variable_''<span id="I7618"></span>name := <span id="I7619"></span>expression; ;[[Guide:95lrm/RM-5-3|5.3]] if_statement::= '''if''' <span id="I7620"></span>condition '''then''' <span id="I7621"></span>sequence_of_statements {'''elsif''' <span id="I7622"></span>condition '''then''' <span id="I7623"></span>sequence_of_statements} ['''else''' <span id="I7624"></span>sequence_of_statements] '''end''' '''if'''; ;[[Guide:95lrm/RM-5-3|5.3]] condition::= ''boolean_''<span id="I7625"></span>expression ;[[Guide:95lrm/RM-5-4|5.4]] case_statement::= '''case''' <span id="I7626"></span>expression '''is''' <span id="I7627"></span>case_statement_alternative {<span id="I7628"></span>case_statement_alternative} '''end''' '''case'''; ;[[Guide:95lrm/RM-5-4|5.4]] case_statement_alternative::= '''when''' <span id="I7629"></span>discrete_choice_list => <span id="I7630"></span>sequence_of_statements ;[[Guide:95lrm/RM-5-5|5.5]] loop_statement::= [''loop_''<span id="I7631"></span>statement_identifier:] [<span id="I7632"></span>iteration_scheme] '''loop''' <span id="I7633"></span>sequence_of_statements '''end''' '''loop''' [''loop_''<span id="I7634"></span>identifier]; ;[[Guide:95lrm/RM-5-5|5.5]] iteration_scheme::= '''while''' <span id="I7635"></span>condition | '''for''' <span id="I7636"></span>loop_parameter_specification ;[[Guide:95lrm/RM-5-5|5.5]] loop_parameter_specification::= <span id="I7637"></span>defining_identifier '''in''' ['''reverse'''] <span id="I7638"></span>discrete_subtype_definition ;[[Guide:95lrm/RM-5-6|5.6]] block_statement::= [''block_''<span id="I7639"></span>statement_identifier:] ['''declare''' <span id="I7640"></span>declarative_part] '''begin''' <span id="I7641"></span>handled_sequence_of_statements '''end''' [''block_''<span id="I7642"></span>identifier]; ;[[Guide:95lrm/RM-5-7|5.7]] exit_statement::= '''exit''' [''loop_''<span id="I7643"></span>name] ['''when''' <span id="I7644"></span>condition]; ;[[Guide:95lrm/RM-5-8|5.8]] goto_statement::= '''goto''' ''label_''<span id="I7645"></span>name; ;[[Guide:95lrm/RM-6-1|6.1]] subprogram_declaration::= <span id="I7646"></span>subprogram_specification; ;[[Guide:95lrm/RM-6-1|6.1]] abstract_subprogram_declaration::= <span id="I7647"></span>subprogram_specification '''is''' '''abstract'''; ;[[Guide:95lrm/RM-6-1|6.1]] subprogram_specification::= '''procedure''' <span id="I7648"></span>defining_program_unit_name <span id="I7649"></span>parameter_profile | '''function''' <span id="I7650"></span>defining_designator <span id="I7651"></span>parameter_and_result_profile ;[[Guide:95lrm/RM-6-1|6.1]] designator::= [<span id="I7652"></span>parent_unit_name . ]<span id="I7653"></span>identifier | <span id="I7654"></span>operator_symbol ;[[Guide:95lrm/RM-6-1|6.1]] defining_designator::= <span id="I7655"></span>defining_program_unit_name | <span id="I7656"></span>defining_operator_symbol ;[[Guide:95lrm/RM-6-1|6.1]] defining_program_unit_name::= [<span id="I7657"></span>parent_unit_name . ]<span id="I7658"></span>defining_identifier ;[[Guide:95lrm/RM-6-1|6.1]] operator_symbol::= <span id="I7659"></span>string_literal ;[[Guide:95lrm/RM-6-1|6.1]] defining_operator_symbol::= <span id="I7660"></span>operator_symbol ;[[Guide:95lrm/RM-6-1|6.1]] parameter_profile::= [<span id="I7661"></span>formal_part] ;[[Guide:95lrm/RM-6-1|6.1]] parameter_and_result_profile::= [<span id="I7662"></span>formal_part] '''return''' <span id="I7663"></span>subtype_mark ;[[Guide:95lrm/RM-6-1|6.1]] formal_part::= (<span id="I7664"></span>parameter_specification {; <span id="I7665"></span>parameter_specification}) ;[[Guide:95lrm/RM-6-1|6.1]] parameter_specification::= <span id="I7666"></span>defining_identifier_list : <span id="I7667"></span>mode <span id="I7668"></span>subtype_mark [:= <span id="I7669"></span>default_expression] | <span id="I7670"></span>defining_identifier_list : <span id="I7671"></span>access_definition [:= <span id="I7672"></span>default_expression] ;[[Guide:95lrm/RM-6-1|6.1]] mode::= ['''in'''] | '''in''' '''out''' | '''out''' ;[[Guide:95lrm/RM-6-3|6.3]] subprogram_body::= <span id="I7673"></span>subprogram_specification '''is''' <span id="I7674"></span>declarative_part '''begin''' <span id="I7675"></span>handled_sequence_of_statements '''end''' [<span id="I7676"></span>designator]; ;[[Guide:95lrm/RM-6-4|6.4]] procedure_call_statement::= ''procedure_''<span id="I7677"></span>name; | ''procedure_''<span id="I7678"></span>prefix <span id="I7679"></span>actual_parameter_part; ;[[Guide:95lrm/RM-6-4|6.4]] function_call::= ''function_''<span id="I7680"></span>name | ''function_''<span id="I7681"></span>prefix <span id="I7682"></span>actual_parameter_part ;[[Guide:95lrm/RM-6-4|6.4]] actual_parameter_part::= (<span id="I7683"></span>parameter_association {, <span id="I7684"></span>parameter_association}) ;[[Guide:95lrm/RM-6-4|6.4]] parameter_association::= [''formal_parameter_''<span id="I7685"></span>selector_name =>] <span id="I7686"></span>explicit_actual_parameter ;[[Guide:95lrm/RM-6-4|6.4]] explicit_actual_parameter::= <span id="I7687"></span>expression | ''variable_''<span id="I7688"></span>name ;[[Guide:95lrm/RM-6-5|6.5]] return_statement::= '''return''' [<span id="I7689"></span>expression]; ;[[Guide:95lrm/RM-7-1|7.1]] package_declaration::= <span id="I7690"></span>package_specification; ;[[Guide:95lrm/RM-7-1|7.1]] package_specification::= '''package''' <span id="I7691"></span>defining_program_unit_name '''is''' {<span id="I7692"></span>basic_declarative_item} ['''private''' {<span id="I7693"></span>basic_declarative_item}] '''end''' [[<span id="I7694"></span>parent_unit_name.]<span id="I7695"></span>identifier] ;[[Guide:95lrm/RM-7-2|7.2]] package_body::= '''package''' '''body''' <span id="I7696"></span>defining_program_unit_name '''is''' <span id="I7697"></span>declarative_part ['''begin''' <span id="I7698"></span>handled_sequence_of_statements] '''end''' [[<span id="I7699"></span>parent_unit_name.]<span id="I7700"></span>identifier]; ;[[Guide:95lrm/RM-7-3|7.3]] private_type_declaration::= '''type''' <span id="I7701"></span>defining_identifier [<span id="I7702"></span>discriminant_part] '''is''' [['''abstract'''] '''tagged'''] ['''limited'''] '''private'''; ;[[Guide:95lrm/RM-7-3|7.3]] private_extension_declaration::= '''type''' <span id="I7703"></span>defining_identifier [<span id="I7704"></span>discriminant_part] '''is''' ['''abstract'''] '''new''' ''ancestor_''<span id="I7705"></span>subtype_indication '''with private'''; ;[[Guide:95lrm/RM-8-4|8.4]] use_clause::= <span id="I7706"></span>use_package_clause | <span id="I7707"></span>use_type_clause ;[[Guide:95lrm/RM-8-4|8.4]] use_package_clause::= '''use''' ''package_''<span id="I7708"></span>name {, ''package_''<span id="I7709"></span>name}; ;[[Guide:95lrm/RM-8-4|8.4]] use_type_clause::= '''use type''' <span id="I7710"></span>subtype_mark {, <span id="I7711"></span>subtype_mark}; ;[[Guide:95lrm/RM-8-5|8.5]] renaming_declaration::= <span id="I7712"></span>object_renaming_declaration | <span id="I7713"></span>exception_renaming_declaration | <span id="I7714"></span>package_renaming_declaration | <span id="I7715"></span>subprogram_renaming_declaration | <span id="I7716"></span>generic_renaming_declaration ;[[Guide:95lrm/RM-8-5-1|8.5.1]] object_renaming_declaration::= <span id="I7717"></span>defining_identifier : <span id="I7718"></span>subtype_mark '''renames''' ''object_''<span id="I7719"></span>name; ;[[Guide:95lrm/RM-8-5-2|8.5.2]] exception_renaming_declaration::= <span id="I7720"></span>defining_identifier : '''exception''' '''renames''' ''exception_''<span id="I7721"></span>name; ;[[Guide:95lrm/RM-8-5-3|8.5.3]] package_renaming_declaration::= '''package''' <span id="I7722"></span>defining_program_unit_name '''renames''' ''package_''<span id="I7723"></span>name; ;[[Guide:95lrm/RM-8-5-4|8.5.4]] subprogram_renaming_declaration::= <span id="I7724"></span>subprogram_specification '''renames''' ''callable_entity_''<span id="I7725"></span>name; ;[[Guide:95lrm/RM-8-5-5|8.5.5]] generic_renaming_declaration::= '''generic package''' <span id="I7726"></span>defining_program_unit_name '''renames''' ''generic_package_''<span id="I7727"></span>name; | '''generic procedure''' <span id="I7728"></span>defining_program_unit_name '''renames''' ''generic_procedure_''<span id="I7729"></span>name; | '''generic function''' <span id="I7730"></span>defining_program_unit_name '''renames''' ''generic_function_''<span id="I7731"></span>name; ;[[Guide:95lrm/RM-9-1|9.1]] task_type_declaration::= '''task''' '''type''' <span id="I7732"></span>defining_identifier [<span id="I7733"></span>known_discriminant_part] ['''is''' <span id="I7734"></span>task_definition]; ;[[Guide:95lrm/RM-9-1|9.1]] single_task_declaration::= '''task''' <span id="I7735"></span>defining_identifier ['''is''' <span id="I7736"></span>task_definition]; ;[[Guide:95lrm/RM-9-1|9.1]] task_definition::= {<span id="I7737"></span>task_item} [ '''private''' {<span id="I7738"></span>task_item}] '''end''' [''task_''<span id="I7739"></span>identifier] ;[[Guide:95lrm/RM-9-1|9.1]] task_item::= <span id="I7740"></span>entry_declaration | <span id="I7741"></span>aspect_clause ;[[Guide:95lrm/RM-9-1|9.1]] task_body::= '''task''' '''body''' <span id="I7742"></span>defining_identifier '''is''' <span id="I7743"></span>declarative_part '''begin''' <span id="I7744"></span>handled_sequence_of_statements '''end''' [''task_''<span id="I7745"></span>identifier]; ;[[Guide:95lrm/RM-9-4|9.4]] protected_type_declaration::= '''protected''' '''type''' <span id="I7746"></span>defining_identifier [<span id="I7747"></span>known_discriminant_part] '''is''' <span id="I7748"></span>protected_definition; ;[[Guide:95lrm/RM-9-4|9.4]] single_protected_declaration::= '''protected''' <span id="I7749"></span>defining_identifier '''is''' <span id="I7750"></span>protected_definition; ;[[Guide:95lrm/RM-9-4|9.4]] protected_definition::= { <span id="I7751"></span>protected_operation_declaration } [ '''private''' { <span id="I7752"></span>protected_element_declaration } ] '''end''' [''protected_''<span id="I7753"></span>identifier] ;[[Guide:95lrm/RM-9-4|9.4]] protected_operation_declaration::= <span id="I7754"></span>subprogram_declaration | <span id="I7755"></span>entry_declaration | <span id="I7756"></span>aspect_clause ;[[Guide:95lrm/RM-9-4|9.4]] protected_element_declaration::= <span id="I7757"></span>protected_operation_declaration | <span id="I7758"></span>component_declaration ;[[Guide:95lrm/RM-9-4|9.4]] protected_body::= '''protected''' '''body''' <span id="I7759"></span>defining_identifier '''is''' { <span id="I7760"></span>protected_operation_item } '''end''' [''protected_''<span id="I7761"></span>identifier]; ;[[Guide:95lrm/RM-9-4|9.4]] protected_operation_item::= <span id="I7762"></span>subprogram_declaration | <span id="I7763"></span>subprogram_body | <span id="I7764"></span>entry_body | <span id="I7765"></span>aspect_clause ;[[Guide:95lrm/RM-9-5-2|9.5.2]] entry_declaration::= '''entry''' <span id="I7766"></span>defining_identifier [(<span id="I7767"></span>discrete_subtype_definition)] <span id="I7768"></span>parameter_profile; ;[[Guide:95lrm/RM-9-5-2|9.5.2]] accept_statement::= '''accept''' ''entry_''<span id="I7769"></span>direct_name [(<span id="I7770"></span>entry_index)] <span id="I7771"></span>parameter_profile ['''do''' <span id="I7772"></span>handled_sequence_of_statements '''end''' [''entry_''<span id="I7773"></span>identifier]]; ;[[Guide:95lrm/RM-9-5-2|9.5.2]] entry_index::= <span id="I7774"></span>expression ;[[Guide:95lrm/RM-9-5-2|9.5.2]] entry_body::= '''entry''' <span id="I7775"></span>defining_identifier <span id="I7776"></span>entry_body_formal_part <span id="I7777"></span>entry_barrier '''is''' <span id="I7778"></span>declarative_part '''begin''' <span id="I7779"></span>handled_sequence_of_statements '''end''' [''entry_''<span id="I7780"></span>identifier]; ;[[Guide:95lrm/RM-9-5-2|9.5.2]] entry_body_formal_part::= [(<span id="I7781"></span>entry_index_specification)] <span id="I7782"></span>parameter_profile ;[[Guide:95lrm/RM-9-5-2|9.5.2]] entry_barrier::= '''when''' <span id="I7783"></span>condition ;[[Guide:95lrm/RM-9-5-2|9.5.2]] entry_index_specification::= '''for''' <span id="I7784"></span>defining_identifier '''in''' <span id="I7785"></span>discrete_subtype_definition ;[[Guide:95lrm/RM-9-5-3|9.5.3]] entry_call_statement::= ''entry_''<span id="I7786"></span>name [<span id="I7787"></span>actual_parameter_part]; ;[[Guide:95lrm/RM-9-5-4|9.5.4]] requeue_statement::= '''requeue''' ''entry_''<span id="I7788"></span>name ['''with''' '''abort''']; ;[[Guide:95lrm/RM-9-6|9.6]] delay_statement::= <span id="I7789"></span>delay_until_statement | <span id="I7790"></span>delay_relative_statement ;[[Guide:95lrm/RM-9-6|9.6]] delay_until_statement::= '''delay until''' ''delay_''<span id="I7791"></span>expression; ;[[Guide:95lrm/RM-9-6|9.6]] delay_relative_statement::= '''delay''' ''delay_''<span id="I7792"></span>expression; ;[[Guide:95lrm/RM-9-7|9.7]] select_statement::= <span id="I7793"></span>selective_accept | <span id="I7794"></span>timed_entry_call | <span id="I7795"></span>conditional_entry_call | <span id="I7796"></span>asynchronous_select ;[[Guide:95lrm/RM-9-7-1|9.7.1]] selective_accept::= '''select''' [<span id="I7797"></span>guard] <span id="I7798"></span>select_alternative { '''or''' [<span id="I7799"></span>guard] <span id="I7800"></span>select_alternative } [ '''else''' <span id="I7801"></span>sequence_of_statements ] '''end select'''; ;[[Guide:95lrm/RM-9-7-1|9.7.1]] guard::= '''when''' <span id="I7802"></span>condition => ;[[Guide:95lrm/RM-9-7-1|9.7.1]] select_alternative::= <span id="I7803"></span>accept_alternative | <span id="I7804"></span>delay_alternative | <span id="I7805"></span>terminate_alternative ;[[Guide:95lrm/RM-9-7-1|9.7.1]] accept_alternative::= <span id="I7806"></span>accept_statement [<span id="I7807"></span>sequence_of_statements] ;[[Guide:95lrm/RM-9-7-1|9.7.1]] delay_alternative::= <span id="I7808"></span>delay_statement [<span id="I7809"></span>sequence_of_statements] ;[[Guide:95lrm/RM-9-7-1|9.7.1]] terminate_alternative::= '''terminate'''; ;[[Guide:95lrm/RM-9-7-2|9.7.2]] timed_entry_call::= '''select''' <span id="I7810"></span>entry_call_alternative '''or''' <span id="I7811"></span>delay_alternative '''end select'''; ;[[Guide:95lrm/RM-9-7-2|9.7.2]] entry_call_alternative::= <span id="I7812"></span>entry_call_statement [<span id="I7813"></span>sequence_of_statements] ;[[Guide:95lrm/RM-9-7-3|9.7.3]] conditional_entry_call::= '''select''' <span id="I7814"></span>entry_call_alternative '''else''' <span id="I7815"></span>sequence_of_statements '''end select'''; ;[[Guide:95lrm/RM-9-7-4|9.7.4]] asynchronous_select::= '''select''' <span id="I7816"></span>triggering_alternative '''then abort''' <span id="I7817"></span>abortable_part '''end select'''; ;[[Guide:95lrm/RM-9-7-4|9.7.4]] triggering_alternative::= <span id="I7818"></span>triggering_statement [<span id="I7819"></span>sequence_of_statements] ;[[Guide:95lrm/RM-9-7-4|9.7.4]] triggering_statement::= <span id="I7820"></span>entry_call_statement | <span id="I7821"></span>delay_statement ;[[Guide:95lrm/RM-9-7-4|9.7.4]] abortable_part::= <span id="I7822"></span>sequence_of_statements ;[[Guide:95lrm/RM-9-8|9.8]] abort_statement::= '''abort''' ''task_''<span id="I7823"></span>name {, ''task_''<span id="I7824"></span>name}; ;[[Guide:95lrm/RM-10-1-1|10.1.1]] compilation::= {<span id="I7825"></span>compilation_unit} ;[[Guide:95lrm/RM-10-1-1|10.1.1]] compilation_unit::= <span id="I7826"></span>context_clause <span id="I7827"></span>library_item | <span id="I7828"></span>context_clause <span id="I7829"></span>subunit ;[[Guide:95lrm/RM-10-1-1|10.1.1]] library_item::= ['''private'''] <span id="I7830"></span>library_unit_declaration | <span id="I7831"></span>library_unit_body | ['''private'''] <span id="I7832"></span>library_unit_renaming_declaration ;[[Guide:95lrm/RM-10-1-1|10.1.1]] library_unit_declaration::= <span id="I7833"></span>subprogram_declaration | <span id="I7834"></span>package_declaration | <span id="I7835"></span>generic_declaration | <span id="I7836"></span>generic_instantiation ;[[Guide:95lrm/RM-10-1-1|10.1.1]] library_unit_renaming_declaration::= <span id="I7837"></span>package_renaming_declaration | <span id="I7838"></span>generic_renaming_declaration | <span id="I7839"></span>subprogram_renaming_declaration ;[[Guide:95lrm/RM-10-1-1|10.1.1]] library_unit_body::= <span id="I7840"></span>subprogram_body | <span id="I7841"></span>package_body ;[[Guide:95lrm/RM-10-1-1|10.1.1]] parent_unit_name::= <span id="I7842"></span>name ;[[Guide:95lrm/RM-10-1-2|10.1.2]] context_clause::= {<span id="I7843"></span>context_item} ;[[Guide:95lrm/RM-10-1-2|10.1.2]] context_item::= <span id="I7844"></span>with_clause | <span id="I7845"></span>use_clause ;[[Guide:95lrm/RM-10-1-2|10.1.2]] with_clause::= '''with''' ''library_unit_''<span id="I7846"></span>name {, ''library_unit_''<span id="I7847"></span>name}; ;[[Guide:95lrm/RM-10-1-3|10.1.3]] body_stub::= <span id="I7848"></span>subprogram_body_stub | <span id="I7849"></span>package_body_stub | <span id="I7850"></span>task_body_stub | <span id="I7851"></span>protected_body_stub ;[[Guide:95lrm/RM-10-1-3|10.1.3]] subprogram_body_stub::= <span id="I7852"></span>subprogram_specification '''is''' '''separate'''; ;[[Guide:95lrm/RM-10-1-3|10.1.3]] package_body_stub::= '''package''' '''body''' <span id="I7853"></span>defining_identifier '''is''' '''separate'''; ;[[Guide:95lrm/RM-10-1-3|10.1.3]] task_body_stub::= '''task''' '''body''' <span id="I7854"></span>defining_identifier '''is''' '''separate'''; ;[[Guide:95lrm/RM-10-1-3|10.1.3]] protected_body_stub::= '''protected''' '''body''' <span id="I7855"></span>defining_identifier '''is''' '''separate'''; ;[[Guide:95lrm/RM-10-1-3|10.1.3]] subunit::= '''separate''' (<span id="I7856"></span>parent_unit_name) <span id="I7857"></span>proper_body ;[[Guide:95lrm/RM-11-1|11.1]] exception_declaration::= <span id="I7858"></span>defining_identifier_list : '''exception'''; ;[[Guide:95lrm/RM-11-2|11.2]] handled_sequence_of_statements::= <span id="I7859"></span>sequence_of_statements ['''exception''' <span id="I7860"></span>exception_handler {<span id="I7861"></span>exception_handler}] ;[[Guide:95lrm/RM-11-2|11.2]] exception_handler::= '''when''' [<span id="I7862"></span>choice_parameter_specification:] <span id="I7863"></span>exception_choice {| <span id="I7864"></span>exception_choice} => <span id="I7865"></span>sequence_of_statements ;[[Guide:95lrm/RM-11-2|11.2]] choice_parameter_specification::= <span id="I7866"></span>defining_identifier ;[[Guide:95lrm/RM-11-2|11.2]] exception_choice::= ''exception_''<span id="I7867"></span>name | '''others''' ;[[Guide:95lrm/RM-11-3|11.3]] raise_statement::= '''raise''' [''exception_''<span id="I7868"></span>name]; ;[[Guide:95lrm/RM-12-1|12.1]] generic_declaration::= <span id="I7869"></span>generic_subprogram_declaration | <span id="I7870"></span>generic_package_declaration ;[[Guide:95lrm/RM-12-1|12.1]] generic_subprogram_declaration::= <span id="I7871"></span>generic_formal_part <span id="I7872"></span>subprogram_specification; ;[[Guide:95lrm/RM-12-1|12.1]] generic_package_declaration::= <span id="I7873"></span>generic_formal_part <span id="I7874"></span>package_specification; ;[[Guide:95lrm/RM-12-1|12.1]] generic_formal_part::= '''generic''' {<span id="I7875"></span>generic_formal_parameter_declaration | <span id="I7876"></span>use_clause} ;[[Guide:95lrm/RM-12-1|12.1]] generic_formal_parameter_declaration::= <span id="I7877"></span>formal_object_declaration | <span id="I7878"></span>formal_type_declaration | <span id="I7879"></span>formal_subprogram_declaration | <span id="I7880"></span>formal_package_declaration ;[[Guide:95lrm/RM-12-3|12.3]] generic_instantiation::= '''package''' <span id="I7881"></span>defining_program_unit_name '''is''' '''new''' ''generic_package_''<span id="I7882"></span>name [<span id="I7883"></span>generic_actual_part]; | '''procedure''' <span id="I7884"></span>defining_program_unit_name '''is''' '''new''' ''generic_procedure_''<span id="I7885"></span>name [<span id="I7886"></span>generic_actual_part]; | '''function''' <span id="I7887"></span>defining_designator '''is''' '''new''' ''generic_function_''<span id="I7888"></span>name [<span id="I7889"></span>generic_actual_part]; ;[[Guide:95lrm/RM-12-3|12.3]] generic_actual_part::= (<span id="I7890"></span>generic_association {, <span id="I7891"></span>generic_association}) ;[[Guide:95lrm/RM-12-3|12.3]] generic_association::= [''generic_formal_parameter_''<span id="I7892"></span>selector_name =>] <span id="I7893"></span>explicit_generic_actual_parameter ;[[Guide:95lrm/RM-12-3|12.3]] explicit_generic_actual_parameter::= <span id="I7894"></span>expression | ''variable_''<span id="I7895"></span>name | ''subprogram_''<span id="I7896"></span>name | ''entry_''<span id="I7897"></span>name | <span id="I7898"></span>subtype_mark | ''package_instance_''<span id="I7899"></span>name ;[[Guide:95lrm/RM-12-4|12.4]] formal_object_declaration::= <span id="I7900"></span>defining_identifier_list : <span id="I7901"></span>mode <span id="I7902"></span>subtype_mark [:= <span id="I7903"></span>default_expression]; ;[[Guide:95lrm/RM-12-5|12.5]] formal_type_declaration::= '''type''' <span id="I7904"></span>defining_identifier[<span id="I7905"></span>discriminant_part] '''is''' <span id="I7906"></span>formal_type_definition; ;[[Guide:95lrm/RM-12-5|12.5]] formal_type_definition::= <span id="I7907"></span>formal_private_type_definition | <span id="I7908"></span>formal_derived_type_definition | <span id="I7909"></span>formal_discrete_type_definition | <span id="I7910"></span>formal_signed_integer_type_definition | <span id="I7911"></span>formal_modular_type_definition | <span id="I7912"></span>formal_floating_point_definition | <span id="I7913"></span>formal_ordinary_fixed_point_definition | <span id="I7914"></span>formal_decimal_fixed_point_definition | <span id="I7915"></span>formal_array_type_definition | <span id="I7916"></span>formal_access_type_definition ;[[Guide:95lrm/RM-12-5-1|12.5.1]] formal_private_type_definition::= [['''abstract'''] '''tagged'''] ['''limited'''] '''private''' ;[[Guide:95lrm/RM-12-5-1|12.5.1]] formal_derived_type_definition::= ['''abstract'''] '''new''' <span id="I7917"></span>subtype_mark ['''with''' '''private'''] ;[[Guide:95lrm/RM-12-5-2|12.5.2]] formal_discrete_type_definition::= (<>) ;[[Guide:95lrm/RM-12-5-2|12.5.2]] formal_signed_integer_type_definition::= '''range''' <> ;[[Guide:95lrm/RM-12-5-2|12.5.2]] formal_modular_type_definition::= '''mod''' <> ;[[Guide:95lrm/RM-12-5-2|12.5.2]] formal_floating_point_definition::= '''digits''' <> ;[[Guide:95lrm/RM-12-5-2|12.5.2]] formal_ordinary_fixed_point_definition::= '''delta''' <> ;[[Guide:95lrm/RM-12-5-2|12.5.2]] formal_decimal_fixed_point_definition::= '''delta''' <> '''digits''' <> ;[[Guide:95lrm/RM-12-5-3|12.5.3]] formal_array_type_definition::= <span id="I7918"></span>array_type_definition ;[[Guide:95lrm/RM-12-5-4|12.5.4]] formal_access_type_definition::= <span id="I7919"></span>access_type_definition ;[[Guide:95lrm/RM-12-6|12.6]] formal_subprogram_declaration::= '''with''' <span id="I7920"></span>subprogram_specification ['''is''' <span id="I7921"></span>subprogram_default]; ;[[Guide:95lrm/RM-12-6|12.6]] subprogram_default::= <span id="I7922"></span>default_name | <> ;[[Guide:95lrm/RM-12-6|12.6]] default_name::= <span id="I7923"></span>name ;[[Guide:95lrm/RM-12-7|12.7]] formal_package_declaration::= '''with''' '''package''' <span id="I7924"></span>defining_identifier '''is''' '''new''' ''generic_package_''<span id="I7925"></span>name <span id="I7926"></span>formal_package_actual_part; ;[[Guide:95lrm/RM-12-7|12.7]] formal_package_actual_part::= (<>) | [<span id="I7927"></span>generic_actual_part] ;[[Guide:95lrm/RM-13-1|13.1]] aspect_clause::= <span id="I7928"></span>attribute_definition_clause | <span id="I7929"></span>enumeration_representation_clause | <span id="I7930"></span>record_representation_clause | <span id="I7931"></span>at_clause ;[[Guide:95lrm/RM-13-1|13.1]] local_name::= <span id="I7932"></span>direct_name | <span id="I7933"></span>direct_name'<span id="I7934"></span>attribute_designator | ''library_unit_''<span id="I7935"></span>name ;[[Guide:95lrm/RM-13-3|13.3]] attribute_definition_clause::= '''for''' <span id="I7936"></span>local_name'<span id="I7937"></span>attribute_designator '''use''' <span id="I7938"></span>expression; | '''for''' <span id="I7939"></span>local_name'<span id="I7940"></span>attribute_designator '''use''' <span id="I7941"></span>name; ;[[Guide:95lrm/RM-13-4|13.4]] enumeration_representation_clause::= '''for''' ''first_subtype_''<span id="I7942"></span>local_name '''use''' <span id="I7943"></span>enumeration_aggregate; ;[[Guide:95lrm/RM-13-4|13.4]] enumeration_aggregate::= <span id="I7944"></span>array_aggregate ;[[Guide:95lrm/RM-13-5-1|13.5.1]] record_representation_clause::= '''for''' ''first_subtype_''<span id="I7945"></span>local_name '''use''' '''record''' [<span id="I7946"></span>mod_clause] {<span id="I7947"></span>component_clause} '''end''' '''record'''; ;[[Guide:95lrm/RM-13-5-1|13.5.1]] component_clause::= ''component_''<span id="I7948"></span>local_name '''at''' <span id="I7949"></span>position '''range''' <span id="I7950"></span>first_bit .. <span id="I7951"></span>last_bit; ;[[Guide:95lrm/RM-13-5-1|13.5.1]] position::= ''static_''<span id="I7952"></span>expression ;[[Guide:95lrm/RM-13-5-1|13.5.1]] first_bit::= ''static_''<span id="I7953"></span>simple_expression ;[[Guide:95lrm/RM-13-5-1|13.5.1]] last_bit::= ''static_''<span id="I7954"></span>simple_expression ;[[Guide:95lrm/RM-13-8|13.8]] code_statement::= <span id="I7955"></span>qualified_expression; ;[[Guide:95lrm/RM-13-12|13.12]] restriction::= ''restriction_''<span id="I7956"></span>identifier | ''restriction_parameter_''<span id="I7957"></span>identifier => <span id="I7958"></span>expression ;[[Guide:95lrm/RM-J-3|J.3]] delta_constraint::= '''delta''' ''static_''<span id="I7959"></span>expression [<span id="I7960"></span>range_constraint] ;[[Guide:95lrm/RM-J-7|J.7]] at_clause::= '''for''' <span id="I7961"></span>direct_name '''use''' '''at''' <span id="I7962"></span>expression; ;[[Guide:95lrm/RM-J-8|J.8]] mod_clause::= '''at''' '''mod''' ''static_''<span id="I7963"></span>expression; == Syntax Cross Reference == <span id="I7964"></span><span id="I7965"></span><span id="I7966"></span><span id="I7967"></span><span id="I7968"></span> ;abort_statement :simple_statement [[Guide:95lrm/RM-5-1|5.1]] ;abortable_part :asynchronous_select [[Guide:95lrm/RM-9-7-4|9.7.4]] ;abstract_subprogram_declaration :basic_declaration [[Guide:95lrm/RM-3-1|3.1]] ;accept_alternative :select_alternative [[Guide:95lrm/RM-9-7-1|9.7.1]] ;accept_statement :accept_alternative [[Guide:95lrm/RM-9-7-1|9.7.1]] :compound_statement [[Guide:95lrm/RM-5-1|5.1]] ;access_definition :discriminant_specification [[Guide:95lrm/RM-3-7|3.7]] :parameter_specification [[Guide:95lrm/RM-6-1|6.1]] ;access_to_object_definition :access_type_definition [[Guide:95lrm/RM-3-10|3.10]] ;access_to_subprogram_definition :access_type_definition [[Guide:95lrm/RM-3-10|3.10]] ;access_type_definition :formal_access_type_definition [[Guide:95lrm/RM-12-5-4|12.5.4]] :type_definition [[Guide:95lrm/RM-3-2-1|3.2.1]] ;actual_parameter_part :entry_call_statement [[Guide:95lrm/RM-9-5-3|9.5.3]] :function_call [[Guide:95lrm/RM-6-4|6.4]] :procedure_call_statement [[Guide:95lrm/RM-6-4|6.4]] ;aggregate :primary [[Guide:95lrm/RM-4-4|4.4]] :qualified_expression [[Guide:95lrm/RM-4-7|4.7]] ;allocator :primary [[Guide:95lrm/RM-4-4|4.4]] ;ancestor_part :extension_aggregate [[Guide:95lrm/RM-4-3-2|4.3.2]] ;array_aggregate :aggregate [[Guide:95lrm/RM-4-3|4.3]] :enumeration_aggregate [[Guide:95lrm/RM-13-4|13.4]] ;array_component_association :named_array_aggregate [[Guide:95lrm/RM-4-3-3|4.3.3]] ;array_type_definition :formal_array_type_definition [[Guide:95lrm/RM-12-5-3|12.5.3]] :object_declaration [[Guide:95lrm/RM-3-3-1|3.3.1]] :type_definition [[Guide:95lrm/RM-3-2-1|3.2.1]] ;aspect_clause :basic_declarative_item [[Guide:95lrm/RM-3-11|3.11]] :component_item [[Guide:95lrm/RM-3-8|3.8]] :protected_operation_declaration [[Guide:95lrm/RM-9-4|9.4]] :protected_operation_item [[Guide:95lrm/RM-9-4|9.4]] :task_item [[Guide:95lrm/RM-9-1|9.1]] ;assignment_statement :simple_statement [[Guide:95lrm/RM-5-1|5.1]] ;asynchronous_select :select_statement [[Guide:95lrm/RM-9-7|9.7]] ;at_clause :aspect_clause [[Guide:95lrm/RM-13-1|13.1]] ;attribute_definition_clause :aspect_clause [[Guide:95lrm/RM-13-1|13.1]] ;attribute_designator :attribute_definition_clause [[Guide:95lrm/RM-13-3|13.3]] :attribute_reference [[Guide:95lrm/RM-4-1-4|4.1.4]] :local_name [[Guide:95lrm/RM-13-1|13.1]] ;attribute_reference :name [[Guide:95lrm/RM-4-1|4.1]] ;base :based_literal [[Guide:95lrm/RM-2-4-2|2.4.2]] ;based_literal :numeric_literal [[Guide:95lrm/RM-2-4|2.4]] ;based_numeral :based_literal [[Guide:95lrm/RM-2-4-2|2.4.2]] ;basic_declaration :basic_declarative_item [[Guide:95lrm/RM-3-11|3.11]] ;basic_declarative_item :declarative_item [[Guide:95lrm/RM-3-11|3.11]] :package_specification [[Guide:95lrm/RM-7-1|7.1]] ;binary_adding_operator :simple_expression [[Guide:95lrm/RM-4-4|4.4]] ;block_statement :compound_statement [[Guide:95lrm/RM-5-1|5.1]] ;body :declarative_item [[Guide:95lrm/RM-3-11|3.11]] ;body_stub :body [[Guide:95lrm/RM-3-11|3.11]] ;case_statement :compound_statement [[Guide:95lrm/RM-5-1|5.1]] ;case_statement_alternative :case_statement [[Guide:95lrm/RM-5-4|5.4]] ;character :comment [[Guide:95lrm/RM-2-7|2.7]] ;character_literal :defining_character_literal [[Guide:95lrm/RM-3-5-1|3.5.1]] :name [[Guide:95lrm/RM-4-1|4.1]] :selector_name [[Guide:95lrm/RM-4-1-3|4.1.3]] ;choice_parameter_specification :exception_handler [[Guide:95lrm/RM-11-2|11.2]] ;code_statement :simple_statement [[Guide:95lrm/RM-5-1|5.1]] ;compilation_unit :compilation [[Guide:95lrm/RM-10-1-1|10.1.1]] ;component_choice_list :record_component_association [[Guide:95lrm/RM-4-3-1|4.3.1]] ;component_clause :record_representation_clause [[Guide:95lrm/RM-13-5-1|13.5.1]] ;component_declaration :component_item [[Guide:95lrm/RM-3-8|3.8]] :protected_element_declaration [[Guide:95lrm/RM-9-4|9.4]] ;component_definition :component_declaration [[Guide:95lrm/RM-3-8|3.8]] :constrained_array_definition [[Guide:95lrm/RM-3-6|3.6]] :unconstrained_array_definition [[Guide:95lrm/RM-3-6|3.6]] ;component_item :component_list [[Guide:95lrm/RM-3-8|3.8]] ;component_list :record_definition [[Guide:95lrm/RM-3-8|3.8]] :variant [[Guide:95lrm/RM-3-8-1|3.8.1]] ;composite_constraint :constraint [[Guide:95lrm/RM-3-2-2|3.2.2]] ;compound_statement :statement [[Guide:95lrm/RM-5-1|5.1]] ;condition :entry_barrier [[Guide:95lrm/RM-9-5-2|9.5.2]] :exit_statement [[Guide:95lrm/RM-5-7|5.7]] :guard [[Guide:95lrm/RM-9-7-1|9.7.1]] :if_statement [[Guide:95lrm/RM-5-3|5.3]] :iteration_scheme [[Guide:95lrm/RM-5-5|5.5]] ;conditional_entry_call :select_statement [[Guide:95lrm/RM-9-7|9.7]] ;constrained_array_definition :array_type_definition [[Guide:95lrm/RM-3-6|3.6]] ;constraint :subtype_indication [[Guide:95lrm/RM-3-2-2|3.2.2]] ;context_clause :compilation_unit [[Guide:95lrm/RM-10-1-1|10.1.1]] ;context_item :context_clause [[Guide:95lrm/RM-10-1-2|10.1.2]] ;decimal_fixed_point_definition :fixed_point_definition [[Guide:95lrm/RM-3-5-9|3.5.9]] ;decimal_literal :numeric_literal [[Guide:95lrm/RM-2-4|2.4]] ;declarative_item :declarative_part [[Guide:95lrm/RM-3-11|3.11]] ;declarative_part :block_statement [[Guide:95lrm/RM-5-6|5.6]] :entry_body [[Guide:95lrm/RM-9-5-2|9.5.2]] :package_body [[Guide:95lrm/RM-7-2|7.2]] :subprogram_body [[Guide:95lrm/RM-6-3|6.3]] :task_body [[Guide:95lrm/RM-9-1|9.1]] ;default_expression :component_declaration [[Guide:95lrm/RM-3-8|3.8]] :discriminant_specification [[Guide:95lrm/RM-3-7|3.7]] :formal_object_declaration [[Guide:95lrm/RM-12-4|12.4]] :parameter_specification [[Guide:95lrm/RM-6-1|6.1]] ;default_name :subprogram_default [[Guide:95lrm/RM-12-6|12.6]] ;defining_character_literal :enumeration_literal_specification [[Guide:95lrm/RM-3-5-1|3.5.1]] ;defining_designator :generic_instantiation [[Guide:95lrm/RM-12-3|12.3]] :subprogram_specification [[Guide:95lrm/RM-6-1|6.1]] ;defining_identifier :choice_parameter_specification [[Guide:95lrm/RM-11-2|11.2]] :defining_identifier_list [[Guide:95lrm/RM-3-3-1|3.3.1]] :defining_program_unit_name [[Guide:95lrm/RM-6-1|6.1]] :entry_body [[Guide:95lrm/RM-9-5-2|9.5.2]] :entry_declaration [[Guide:95lrm/RM-9-5-2|9.5.2]] :entry_index_specification [[Guide:95lrm/RM-9-5-2|9.5.2]] :enumeration_literal_specification [[Guide:95lrm/RM-3-5-1|3.5.1]] :exception_renaming_declaration [[Guide:95lrm/RM-8-5-2|8.5.2]] :formal_package_declaration [[Guide:95lrm/RM-12-7|12.7]] :formal_type_declaration [[Guide:95lrm/RM-12-5|12.5]] :full_type_declaration [[Guide:95lrm/RM-3-2-1|3.2.1]] :incomplete_type_declaration [[Guide:95lrm/RM-3-10-1|3.10.1]] :loop_parameter_specification [[Guide:95lrm/RM-5-5|5.5]] :object_renaming_declaration [[Guide:95lrm/RM-8-5-1|8.5.1]] :package_body_stub [[Guide:95lrm/RM-10-1-3|10.1.3]] :private_extension_declaration [[Guide:95lrm/RM-7-3|7.3]] :private_type_declaration [[Guide:95lrm/RM-7-3|7.3]] :protected_body [[Guide:95lrm/RM-9-4|9.4]] :protected_body_stub [[Guide:95lrm/RM-10-1-3|10.1.3]] :protected_type_declaration [[Guide:95lrm/RM-9-4|9.4]] :single_protected_declaration [[Guide:95lrm/RM-9-4|9.4]] :single_task_declaration [[Guide:95lrm/RM-9-1|9.1]] :subtype_declaration [[Guide:95lrm/RM-3-2-2|3.2.2]] :task_body [[Guide:95lrm/RM-9-1|9.1]] :task_body_stub [[Guide:95lrm/RM-10-1-3|10.1.3]] :task_type_declaration [[Guide:95lrm/RM-9-1|9.1]] ;defining_identifier_list :component_declaration [[Guide:95lrm/RM-3-8|3.8]] :discriminant_specification [[Guide:95lrm/RM-3-7|3.7]] :exception_declaration [[Guide:95lrm/RM-11-1|11.1]] :formal_object_declaration [[Guide:95lrm/RM-12-4|12.4]] :number_declaration [[Guide:95lrm/RM-3-3-2|3.3.2]] :object_declaration [[Guide:95lrm/RM-3-3-1|3.3.1]] :parameter_specification [[Guide:95lrm/RM-6-1|6.1]] ;defining_operator_symbol :defining_designator [[Guide:95lrm/RM-6-1|6.1]] ;defining_program_unit_name :defining_designator [[Guide:95lrm/RM-6-1|6.1]] :generic_instantiation [[Guide:95lrm/RM-12-3|12.3]] :generic_renaming_declaration [[Guide:95lrm/RM-8-5-5|8.5.5]] :package_body [[Guide:95lrm/RM-7-2|7.2]] :package_renaming_declaration [[Guide:95lrm/RM-8-5-3|8.5.3]] :package_specification [[Guide:95lrm/RM-7-1|7.1]] :subprogram_specification [[Guide:95lrm/RM-6-1|6.1]] ;delay_alternative :select_alternative [[Guide:95lrm/RM-9-7-1|9.7.1]] :timed_entry_call [[Guide:95lrm/RM-9-7-2|9.7.2]] ;delay_relative_statement :delay_statement [[Guide:95lrm/RM-9-6|9.6]] ;delay_statement :delay_alternative [[Guide:95lrm/RM-9-7-1|9.7.1]] :simple_statement [[Guide:95lrm/RM-5-1|5.1]] :triggering_statement [[Guide:95lrm/RM-9-7-4|9.7.4]] ;delay_until_statement :delay_statement [[Guide:95lrm/RM-9-6|9.6]] ;delta_constraint :scalar_constraint [[Guide:95lrm/RM-3-2-2|3.2.2]] ;derived_type_definition :type_definition [[Guide:95lrm/RM-3-2-1|3.2.1]] ;designator :subprogram_body [[Guide:95lrm/RM-6-3|6.3]] ;digit :extended_digit [[Guide:95lrm/RM-2-4-2|2.4.2]] :graphic_character [[Guide:95lrm/RM-2-1|2.1]] :letter_or_digit [[Guide:95lrm/RM-2-3|2.3]] :numeral [[Guide:95lrm/RM-2-4-1|2.4.1]] ;digits_constraint :scalar_constraint [[Guide:95lrm/RM-3-2-2|3.2.2]] ;direct_name :accept_statement [[Guide:95lrm/RM-9-5-2|9.5.2]] :at_clause [[Guide:95lrm/RM-J-7|J.7]] :local_name [[Guide:95lrm/RM-13-1|13.1]] :name [[Guide:95lrm/RM-4-1|4.1]] :statement_identifier [[Guide:95lrm/RM-5-1|5.1]] :variant_part [[Guide:95lrm/RM-3-8-1|3.8.1]] ;discrete_choice :discrete_choice_list [[Guide:95lrm/RM-3-8-1|3.8.1]] ;discrete_choice_list :array_component_association [[Guide:95lrm/RM-4-3-3|4.3.3]] :case_statement_alternative [[Guide:95lrm/RM-5-4|5.4]] :variant [[Guide:95lrm/RM-3-8-1|3.8.1]] ;discrete_range :discrete_choice [[Guide:95lrm/RM-3-8-1|3.8.1]] :index_constraint [[Guide:95lrm/RM-3-6-1|3.6.1]] :slice [[Guide:95lrm/RM-4-1-2|4.1.2]] ;discrete_subtype_definition :constrained_array_definition [[Guide:95lrm/RM-3-6|3.6]] :entry_declaration [[Guide:95lrm/RM-9-5-2|9.5.2]] :entry_index_specification [[Guide:95lrm/RM-9-5-2|9.5.2]] :loop_parameter_specification [[Guide:95lrm/RM-5-5|5.5]] ;discriminant_association :discriminant_constraint [[Guide:95lrm/RM-3-7-1|3.7.1]] ;discriminant_constraint :composite_constraint [[Guide:95lrm/RM-3-2-2|3.2.2]] ;discriminant_part :formal_type_declaration [[Guide:95lrm/RM-12-5|12.5]] :incomplete_type_declaration [[Guide:95lrm/RM-3-10-1|3.10.1]] :private_extension_declaration [[Guide:95lrm/RM-7-3|7.3]] :private_type_declaration [[Guide:95lrm/RM-7-3|7.3]] ;discriminant_specification :known_discriminant_part [[Guide:95lrm/RM-3-7|3.7]] ;entry_barrier :entry_body [[Guide:95lrm/RM-9-5-2|9.5.2]] ;entry_body :protected_operation_item [[Guide:95lrm/RM-9-4|9.4]] ;entry_body_formal_part :entry_body [[Guide:95lrm/RM-9-5-2|9.5.2]] ;entry_call_alternative :conditional_entry_call [[Guide:95lrm/RM-9-7-3|9.7.3]] :timed_entry_call [[Guide:95lrm/RM-9-7-2|9.7.2]] ;entry_call_statement :entry_call_alternative [[Guide:95lrm/RM-9-7-2|9.7.2]] :simple_statement [[Guide:95lrm/RM-5-1|5.1]] :triggering_statement [[Guide:95lrm/RM-9-7-4|9.7.4]] ;entry_declaration :protected_operation_declaration [[Guide:95lrm/RM-9-4|9.4]] :task_item [[Guide:95lrm/RM-9-1|9.1]] ;entry_index :accept_statement [[Guide:95lrm/RM-9-5-2|9.5.2]] ;entry_index_specification :entry_body_formal_part [[Guide:95lrm/RM-9-5-2|9.5.2]] ;enumeration_aggregate :enumeration_representation_clause [[Guide:95lrm/RM-13-4|13.4]] ;enumeration_literal_specification :enumeration_type_definition [[Guide:95lrm/RM-3-5-1|3.5.1]] ;enumeration_representation_clause :aspect_clause [[Guide:95lrm/RM-13-1|13.1]] ;enumeration_type_definition :type_definition [[Guide:95lrm/RM-3-2-1|3.2.1]] ;exception_choice :exception_handler [[Guide:95lrm/RM-11-2|11.2]] ;exception_declaration :basic_declaration [[Guide:95lrm/RM-3-1|3.1]] ;exception_handler :handled_sequence_of_statements [[Guide:95lrm/RM-11-2|11.2]] ;exception_renaming_declaration :renaming_declaration [[Guide:95lrm/RM-8-5|8.5]] ;exit_statement :simple_statement [[Guide:95lrm/RM-5-1|5.1]] ;explicit_actual_parameter :parameter_association [[Guide:95lrm/RM-6-4|6.4]] ;explicit_dereference :name [[Guide:95lrm/RM-4-1|4.1]] ;explicit_generic_actual_parameter :generic_association [[Guide:95lrm/RM-12-3|12.3]] ;exponent :based_literal [[Guide:95lrm/RM-2-4-2|2.4.2]] :decimal_literal [[Guide:95lrm/RM-2-4-1|2.4.1]] ;expression :ancestor_part [[Guide:95lrm/RM-4-3-2|4.3.2]] :array_component_association [[Guide:95lrm/RM-4-3-3|4.3.3]] :assignment_statement [[Guide:95lrm/RM-5-2|5.2]] :at_clause [[Guide:95lrm/RM-J-7|J.7]] :attribute_definition_clause [[Guide:95lrm/RM-13-3|13.3]] :attribute_designator [[Guide:95lrm/RM-4-1-4|4.1.4]] :case_statement [[Guide:95lrm/RM-5-4|5.4]] :condition [[Guide:95lrm/RM-5-3|5.3]] :decimal_fixed_point_definition [[Guide:95lrm/RM-3-5-9|3.5.9]] :default_expression [[Guide:95lrm/RM-3-7|3.7]] :delay_relative_statement [[Guide:95lrm/RM-9-6|9.6]] :delay_until_statement [[Guide:95lrm/RM-9-6|9.6]] :delta_constraint [[Guide:95lrm/RM-J-3|J.3]] :digits_constraint [[Guide:95lrm/RM-3-5-9|3.5.9]] :discrete_choice [[Guide:95lrm/RM-3-8-1|3.8.1]] :discriminant_association [[Guide:95lrm/RM-3-7-1|3.7.1]] :entry_index [[Guide:95lrm/RM-9-5-2|9.5.2]] :explicit_actual_parameter [[Guide:95lrm/RM-6-4|6.4]] :explicit_generic_actual_parameter [[Guide:95lrm/RM-12-3|12.3]] :floating_point_definition [[Guide:95lrm/RM-3-5-7|3.5.7]] :indexed_component [[Guide:95lrm/RM-4-1-1|4.1.1]] :mod_clause [[Guide:95lrm/RM-J-8|J.8]] :modular_type_definition [[Guide:95lrm/RM-3-5-4|3.5.4]] :number_declaration [[Guide:95lrm/RM-3-3-2|3.3.2]] :object_declaration [[Guide:95lrm/RM-3-3-1|3.3.1]] :ordinary_fixed_point_definition [[Guide:95lrm/RM-3-5-9|3.5.9]] :position [[Guide:95lrm/RM-13-5-1|13.5.1]] :positional_array_aggregate [[Guide:95lrm/RM-4-3-3|4.3.3]] :pragma_argument_association [[Guide:95lrm/RM-2-8|2.8]] :primary [[Guide:95lrm/RM-4-4|4.4]] :qualified_expression [[Guide:95lrm/RM-4-7|4.7]] :range_attribute_designator [[Guide:95lrm/RM-4-1-4|4.1.4]] :record_component_association [[Guide:95lrm/RM-4-3-1|4.3.1]] :restriction [[Guide:95lrm/RM-13-12|13.12]] :return_statement [[Guide:95lrm/RM-6-5|6.5]] :type_conversion [[Guide:95lrm/RM-4-6|4.6]] ;extended_digit :based_numeral [[Guide:95lrm/RM-2-4-2|2.4.2]] ;extension_aggregate :aggregate [[Guide:95lrm/RM-4-3|4.3]] ;factor :term [[Guide:95lrm/RM-4-4|4.4]] ;first_bit :component_clause [[Guide:95lrm/RM-13-5-1|13.5.1]] ;fixed_point_definition :real_type_definition [[Guide:95lrm/RM-3-5-6|3.5.6]] ;floating_point_definition :real_type_definition [[Guide:95lrm/RM-3-5-6|3.5.6]] ;formal_access_type_definition :formal_type_definition [[Guide:95lrm/RM-12-5|12.5]] ;formal_array_type_definition :formal_type_definition [[Guide:95lrm/RM-12-5|12.5]] ;formal_decimal_fixed_point_definition :formal_type_definition [[Guide:95lrm/RM-12-5|12.5]] ;formal_derived_type_definition :formal_type_definition [[Guide:95lrm/RM-12-5|12.5]] ;formal_discrete_type_definition :formal_type_definition [[Guide:95lrm/RM-12-5|12.5]] ;formal_floating_point_definition :formal_type_definition [[Guide:95lrm/RM-12-5|12.5]] ;formal_modular_type_definition :formal_type_definition [[Guide:95lrm/RM-12-5|12.5]] ;formal_object_declaration :generic_formal_parameter_declaration [[Guide:95lrm/RM-12-1|12.1]] ;formal_ordinary_fixed_point_definition :formal_type_definition [[Guide:95lrm/RM-12-5|12.5]] ;formal_package_actual_part :formal_package_declaration [[Guide:95lrm/RM-12-7|12.7]] ;formal_package_declaration :generic_formal_parameter_declaration [[Guide:95lrm/RM-12-1|12.1]] ;formal_part :parameter_and_result_profile [[Guide:95lrm/RM-6-1|6.1]] :parameter_profile [[Guide:95lrm/RM-6-1|6.1]] ;formal_private_type_definition :formal_type_definition [[Guide:95lrm/RM-12-5|12.5]] ;formal_signed_integer_type_definition :formal_type_definition [[Guide:95lrm/RM-12-5|12.5]] ;formal_subprogram_declaration :generic_formal_parameter_declaration [[Guide:95lrm/RM-12-1|12.1]] ;formal_type_declaration :generic_formal_parameter_declaration [[Guide:95lrm/RM-12-1|12.1]] ;formal_type_definition :formal_type_declaration [[Guide:95lrm/RM-12-5|12.5]] ;format_effector :character [[Guide:95lrm/RM-2-1|2.1]] ;full_type_declaration :type_declaration [[Guide:95lrm/RM-3-2-1|3.2.1]] ;function_call :name [[Guide:95lrm/RM-4-1|4.1]] ;general_access_modifier :access_to_object_definition [[Guide:95lrm/RM-3-10|3.10]] ;generic_actual_part :formal_package_actual_part [[Guide:95lrm/RM-12-7|12.7]] :generic_instantiation [[Guide:95lrm/RM-12-3|12.3]] ;generic_association :generic_actual_part [[Guide:95lrm/RM-12-3|12.3]] ;generic_declaration :basic_declaration [[Guide:95lrm/RM-3-1|3.1]] :library_unit_declaration [[Guide:95lrm/RM-10-1-1|10.1.1]] ;generic_formal_parameter_declaration :generic_formal_part [[Guide:95lrm/RM-12-1|12.1]] ;generic_formal_part :generic_package_declaration [[Guide:95lrm/RM-12-1|12.1]] :generic_subprogram_declaration [[Guide:95lrm/RM-12-1|12.1]] ;generic_instantiation :basic_declaration [[Guide:95lrm/RM-3-1|3.1]] :library_unit_declaration [[Guide:95lrm/RM-10-1-1|10.1.1]] ;generic_package_declaration :generic_declaration [[Guide:95lrm/RM-12-1|12.1]] ;generic_renaming_declaration :library_unit_renaming_declaration [[Guide:95lrm/RM-10-1-1|10.1.1]] :renaming_declaration [[Guide:95lrm/RM-8-5|8.5]] ;generic_subprogram_declaration :generic_declaration [[Guide:95lrm/RM-12-1|12.1]] ;goto_statement :simple_statement [[Guide:95lrm/RM-5-1|5.1]] ;graphic_character :character [[Guide:95lrm/RM-2-1|2.1]] :character_literal [[Guide:95lrm/RM-2-5|2.5]] :string_element [[Guide:95lrm/RM-2-6|2.6]] ;guard :selective_accept [[Guide:95lrm/RM-9-7-1|9.7.1]] ;handled_sequence_of_statements :accept_statement [[Guide:95lrm/RM-9-5-2|9.5.2]] :block_statement [[Guide:95lrm/RM-5-6|5.6]] :entry_body [[Guide:95lrm/RM-9-5-2|9.5.2]] :package_body [[Guide:95lrm/RM-7-2|7.2]] :subprogram_body [[Guide:95lrm/RM-6-3|6.3]] :task_body [[Guide:95lrm/RM-9-1|9.1]] ;identifier :accept_statement [[Guide:95lrm/RM-9-5-2|9.5.2]] :attribute_designator [[Guide:95lrm/RM-4-1-4|4.1.4]] :block_statement [[Guide:95lrm/RM-5-6|5.6]] :defining_identifier [[Guide:95lrm/RM-3-1|3.1]] :designator [[Guide:95lrm/RM-6-1|6.1]] :direct_name [[Guide:95lrm/RM-4-1|4.1]] :entry_body [[Guide:95lrm/RM-9-5-2|9.5.2]] :loop_statement [[Guide:95lrm/RM-5-5|5.5]] :package_body [[Guide:95lrm/RM-7-2|7.2]] :package_specification [[Guide:95lrm/RM-7-1|7.1]] :pragma [[Guide:95lrm/RM-2-8|2.8]] :pragma_argument_association [[Guide:95lrm/RM-2-8|2.8]] :protected_body [[Guide:95lrm/RM-9-4|9.4]] :protected_definition [[Guide:95lrm/RM-9-4|9.4]] :restriction [[Guide:95lrm/RM-13-12|13.12]] :selector_name [[Guide:95lrm/RM-4-1-3|4.1.3]] :task_body [[Guide:95lrm/RM-9-1|9.1]] :task_definition [[Guide:95lrm/RM-9-1|9.1]] ;identifier_letter :graphic_character [[Guide:95lrm/RM-2-1|2.1]] :identifier [[Guide:95lrm/RM-2-3|2.3]] :letter_or_digit [[Guide:95lrm/RM-2-3|2.3]] ;if_statement :compound_statement [[Guide:95lrm/RM-5-1|5.1]] ;implicit_dereference :prefix [[Guide:95lrm/RM-4-1|4.1]] ;incomplete_type_declaration :type_declaration [[Guide:95lrm/RM-3-2-1|3.2.1]] ;index_constraint :composite_constraint [[Guide:95lrm/RM-3-2-2|3.2.2]] ;index_subtype_definition :unconstrained_array_definition [[Guide:95lrm/RM-3-6|3.6]] ;indexed_component :name [[Guide:95lrm/RM-4-1|4.1]] ;integer_type_definition :type_definition [[Guide:95lrm/RM-3-2-1|3.2.1]] ;iteration_scheme :loop_statement [[Guide:95lrm/RM-5-5|5.5]] ;known_discriminant_part :discriminant_part [[Guide:95lrm/RM-3-7|3.7]] :full_type_declaration [[Guide:95lrm/RM-3-2-1|3.2.1]] :protected_type_declaration [[Guide:95lrm/RM-9-4|9.4]] :task_type_declaration [[Guide:95lrm/RM-9-1|9.1]] ;label :statement [[Guide:95lrm/RM-5-1|5.1]] ;last_bit :component_clause [[Guide:95lrm/RM-13-5-1|13.5.1]] ;letter_or_digit :identifier [[Guide:95lrm/RM-2-3|2.3]] ;library_item :compilation_unit [[Guide:95lrm/RM-10-1-1|10.1.1]] ;library_unit_body :library_item [[Guide:95lrm/RM-10-1-1|10.1.1]] ;library_unit_declaration :library_item [[Guide:95lrm/RM-10-1-1|10.1.1]] ;library_unit_renaming_declaration :library_item [[Guide:95lrm/RM-10-1-1|10.1.1]] ;local_name :attribute_definition_clause [[Guide:95lrm/RM-13-3|13.3]] :component_clause [[Guide:95lrm/RM-13-5-1|13.5.1]] :enumeration_representation_clause [[Guide:95lrm/RM-13-4|13.4]] :record_representation_clause [[Guide:95lrm/RM-13-5-1|13.5.1]] ;loop_parameter_specification :iteration_scheme [[Guide:95lrm/RM-5-5|5.5]] ;loop_statement :compound_statement [[Guide:95lrm/RM-5-1|5.1]] ;mod_clause :record_representation_clause [[Guide:95lrm/RM-13-5-1|13.5.1]] ;mode :formal_object_declaration [[Guide:95lrm/RM-12-4|12.4]] :parameter_specification [[Guide:95lrm/RM-6-1|6.1]] ;modular_type_definition :integer_type_definition [[Guide:95lrm/RM-3-5-4|3.5.4]] ;multiplying_operator :term [[Guide:95lrm/RM-4-4|4.4]] ;name :abort_statement [[Guide:95lrm/RM-9-8|9.8]] :assignment_statement [[Guide:95lrm/RM-5-2|5.2]] :attribute_definition_clause [[Guide:95lrm/RM-13-3|13.3]] :default_name [[Guide:95lrm/RM-12-6|12.6]] :entry_call_statement [[Guide:95lrm/RM-9-5-3|9.5.3]] :exception_choice [[Guide:95lrm/RM-11-2|11.2]] :exception_renaming_declaration [[Guide:95lrm/RM-8-5-2|8.5.2]] :exit_statement [[Guide:95lrm/RM-5-7|5.7]] :explicit_actual_parameter [[Guide:95lrm/RM-6-4|6.4]] :explicit_dereference [[Guide:95lrm/RM-4-1|4.1]] :explicit_generic_actual_parameter [[Guide:95lrm/RM-12-3|12.3]] :formal_package_declaration [[Guide:95lrm/RM-12-7|12.7]] :function_call [[Guide:95lrm/RM-6-4|6.4]] :generic_instantiation [[Guide:95lrm/RM-12-3|12.3]] :generic_renaming_declaration [[Guide:95lrm/RM-8-5-5|8.5.5]] :goto_statement [[Guide:95lrm/RM-5-8|5.8]] :implicit_dereference [[Guide:95lrm/RM-4-1|4.1]] :local_name [[Guide:95lrm/RM-13-1|13.1]] :object_renaming_declaration [[Guide:95lrm/RM-8-5-1|8.5.1]] :package_renaming_declaration [[Guide:95lrm/RM-8-5-3|8.5.3]] :parent_unit_name [[Guide:95lrm/RM-10-1-1|10.1.1]] :pragma_argument_association [[Guide:95lrm/RM-2-8|2.8]] :prefix [[Guide:95lrm/RM-4-1|4.1]] :primary [[Guide:95lrm/RM-4-4|4.4]] :procedure_call_statement [[Guide:95lrm/RM-6-4|6.4]] :raise_statement [[Guide:95lrm/RM-11-3|11.3]] :requeue_statement [[Guide:95lrm/RM-9-5-4|9.5.4]] :subprogram_renaming_declaration [[Guide:95lrm/RM-8-5-4|8.5.4]] :subtype_mark [[Guide:95lrm/RM-3-2-2|3.2.2]] :type_conversion [[Guide:95lrm/RM-4-6|4.6]] :use_package_clause [[Guide:95lrm/RM-8-4|8.4]] :with_clause [[Guide:95lrm/RM-10-1-2|10.1.2]] ;named_array_aggregate :array_aggregate [[Guide:95lrm/RM-4-3-3|4.3.3]] ;null_statement :simple_statement [[Guide:95lrm/RM-5-1|5.1]] ;number_declaration :basic_declaration [[Guide:95lrm/RM-3-1|3.1]] ;numeral :base [[Guide:95lrm/RM-2-4-2|2.4.2]] :decimal_literal [[Guide:95lrm/RM-2-4-1|2.4.1]] :exponent [[Guide:95lrm/RM-2-4-1|2.4.1]] ;numeric_literal :primary [[Guide:95lrm/RM-4-4|4.4]] ;object_declaration :basic_declaration [[Guide:95lrm/RM-3-1|3.1]] ;object_renaming_declaration :renaming_declaration [[Guide:95lrm/RM-8-5|8.5]] ;operator_symbol :defining_operator_symbol [[Guide:95lrm/RM-6-1|6.1]] :designator [[Guide:95lrm/RM-6-1|6.1]] :direct_name [[Guide:95lrm/RM-4-1|4.1]] :selector_name [[Guide:95lrm/RM-4-1-3|4.1.3]] ;ordinary_fixed_point_definition :fixed_point_definition [[Guide:95lrm/RM-3-5-9|3.5.9]] ;other_control_function :character [[Guide:95lrm/RM-2-1|2.1]] ;package_body :library_unit_body [[Guide:95lrm/RM-10-1-1|10.1.1]] :proper_body [[Guide:95lrm/RM-3-11|3.11]] ;package_body_stub :body_stub [[Guide:95lrm/RM-10-1-3|10.1.3]] ;package_declaration :basic_declaration [[Guide:95lrm/RM-3-1|3.1]] :library_unit_declaration [[Guide:95lrm/RM-10-1-1|10.1.1]] ;package_renaming_declaration :library_unit_renaming_declaration [[Guide:95lrm/RM-10-1-1|10.1.1]] :renaming_declaration [[Guide:95lrm/RM-8-5|8.5]] ;package_specification :generic_package_declaration [[Guide:95lrm/RM-12-1|12.1]] :package_declaration [[Guide:95lrm/RM-7-1|7.1]] ;parameter_and_result_profile :access_to_subprogram_definition [[Guide:95lrm/RM-3-10|3.10]] :subprogram_specification [[Guide:95lrm/RM-6-1|6.1]] ;parameter_association :actual_parameter_part [[Guide:95lrm/RM-6-4|6.4]] ;parameter_profile :accept_statement [[Guide:95lrm/RM-9-5-2|9.5.2]] :access_to_subprogram_definition [[Guide:95lrm/RM-3-10|3.10]] :entry_body_formal_part [[Guide:95lrm/RM-9-5-2|9.5.2]] :entry_declaration [[Guide:95lrm/RM-9-5-2|9.5.2]] :subprogram_specification [[Guide:95lrm/RM-6-1|6.1]] ;parameter_specification :formal_part [[Guide:95lrm/RM-6-1|6.1]] ;parent_unit_name :defining_program_unit_name [[Guide:95lrm/RM-6-1|6.1]] :designator [[Guide:95lrm/RM-6-1|6.1]] :package_body [[Guide:95lrm/RM-7-2|7.2]] :package_specification [[Guide:95lrm/RM-7-1|7.1]] :subunit [[Guide:95lrm/RM-10-1-3|10.1.3]] ;position :component_clause [[Guide:95lrm/RM-13-5-1|13.5.1]] ;positional_array_aggregate :array_aggregate [[Guide:95lrm/RM-4-3-3|4.3.3]] ;pragma_argument_association :pragma [[Guide:95lrm/RM-2-8|2.8]] ;prefix :attribute_reference [[Guide:95lrm/RM-4-1-4|4.1.4]] :function_call [[Guide:95lrm/RM-6-4|6.4]] :indexed_component [[Guide:95lrm/RM-4-1-1|4.1.1]] :procedure_call_statement [[Guide:95lrm/RM-6-4|6.4]] :range_attribute_reference [[Guide:95lrm/RM-4-1-4|4.1.4]] :selected_component [[Guide:95lrm/RM-4-1-3|4.1.3]] :slice [[Guide:95lrm/RM-4-1-2|4.1.2]] ;primary :factor [[Guide:95lrm/RM-4-4|4.4]] ;private_extension_declaration :type_declaration [[Guide:95lrm/RM-3-2-1|3.2.1]] ;private_type_declaration :type_declaration [[Guide:95lrm/RM-3-2-1|3.2.1]] ;procedure_call_statement :simple_statement [[Guide:95lrm/RM-5-1|5.1]] ;proper_body :body [[Guide:95lrm/RM-3-11|3.11]] :subunit [[Guide:95lrm/RM-10-1-3|10.1.3]] ;protected_body :proper_body [[Guide:95lrm/RM-3-11|3.11]] ;protected_body_stub :body_stub [[Guide:95lrm/RM-10-1-3|10.1.3]] ;protected_definition :protected_type_declaration [[Guide:95lrm/RM-9-4|9.4]] :single_protected_declaration [[Guide:95lrm/RM-9-4|9.4]] ;protected_element_declaration :protected_definition [[Guide:95lrm/RM-9-4|9.4]] ;protected_operation_declaration :protected_definition [[Guide:95lrm/RM-9-4|9.4]] :protected_element_declaration [[Guide:95lrm/RM-9-4|9.4]] ;protected_operation_item :protected_body [[Guide:95lrm/RM-9-4|9.4]] ;protected_type_declaration :full_type_declaration [[Guide:95lrm/RM-3-2-1|3.2.1]] ;qualified_expression :allocator [[Guide:95lrm/RM-4-8|4.8]] :code_statement [[Guide:95lrm/RM-13-8|13.8]] :primary [[Guide:95lrm/RM-4-4|4.4]] ;raise_statement :simple_statement [[Guide:95lrm/RM-5-1|5.1]] ;range :discrete_range [[Guide:95lrm/RM-3-6-1|3.6.1]] :discrete_subtype_definition [[Guide:95lrm/RM-3-6|3.6]] :range_constraint [[Guide:95lrm/RM-3-5|3.5]] :relation [[Guide:95lrm/RM-4-4|4.4]] ;range_attribute_designator :range_attribute_reference [[Guide:95lrm/RM-4-1-4|4.1.4]] ;range_attribute_reference :range [[Guide:95lrm/RM-3-5|3.5]] ;range_constraint :delta_constraint [[Guide:95lrm/RM-J-3|J.3]] :digits_constraint [[Guide:95lrm/RM-3-5-9|3.5.9]] :scalar_constraint [[Guide:95lrm/RM-3-2-2|3.2.2]] ;real_range_specification :decimal_fixed_point_definition [[Guide:95lrm/RM-3-5-9|3.5.9]] :floating_point_definition [[Guide:95lrm/RM-3-5-7|3.5.7]] :ordinary_fixed_point_definition [[Guide:95lrm/RM-3-5-9|3.5.9]] ;real_type_definition :type_definition [[Guide:95lrm/RM-3-2-1|3.2.1]] ;record_aggregate :aggregate [[Guide:95lrm/RM-4-3|4.3]] ;record_component_association :record_component_association_list [[Guide:95lrm/RM-4-3-1|4.3.1]] ;record_component_association_list :extension_aggregate [[Guide:95lrm/RM-4-3-2|4.3.2]] :record_aggregate [[Guide:95lrm/RM-4-3-1|4.3.1]] ;record_definition :record_extension_part [[Guide:95lrm/RM-3-9-1|3.9.1]] :record_type_definition [[Guide:95lrm/RM-3-8|3.8]] ;record_extension_part :derived_type_definition [[Guide:95lrm/RM-3-4|3.4]] ;record_representation_clause :aspect_clause [[Guide:95lrm/RM-13-1|13.1]] ;record_type_definition :type_definition [[Guide:95lrm/RM-3-2-1|3.2.1]] ;relation :expression [[Guide:95lrm/RM-4-4|4.4]] ;relational_operator :relation [[Guide:95lrm/RM-4-4|4.4]] ;renaming_declaration :basic_declaration [[Guide:95lrm/RM-3-1|3.1]] ;requeue_statement :simple_statement [[Guide:95lrm/RM-5-1|5.1]] ;return_statement :simple_statement [[Guide:95lrm/RM-5-1|5.1]] ;scalar_constraint :constraint [[Guide:95lrm/RM-3-2-2|3.2.2]] ;select_alternative :selective_accept [[Guide:95lrm/RM-9-7-1|9.7.1]] ;select_statement :compound_statement [[Guide:95lrm/RM-5-1|5.1]] ;selected_component :name [[Guide:95lrm/RM-4-1|4.1]] ;selective_accept :select_statement [[Guide:95lrm/RM-9-7|9.7]] ;selector_name :component_choice_list [[Guide:95lrm/RM-4-3-1|4.3.1]] :discriminant_association [[Guide:95lrm/RM-3-7-1|3.7.1]] :generic_association [[Guide:95lrm/RM-12-3|12.3]] :parameter_association [[Guide:95lrm/RM-6-4|6.4]] :selected_component [[Guide:95lrm/RM-4-1-3|4.1.3]] ;sequence_of_statements :abortable_part [[Guide:95lrm/RM-9-7-4|9.7.4]] :accept_alternative [[Guide:95lrm/RM-9-7-1|9.7.1]] :case_statement_alternative [[Guide:95lrm/RM-5-4|5.4]] :conditional_entry_call [[Guide:95lrm/RM-9-7-3|9.7.3]] :delay_alternative [[Guide:95lrm/RM-9-7-1|9.7.1]] :entry_call_alternative [[Guide:95lrm/RM-9-7-2|9.7.2]] :exception_handler [[Guide:95lrm/RM-11-2|11.2]] :handled_sequence_of_statements [[Guide:95lrm/RM-11-2|11.2]] :if_statement [[Guide:95lrm/RM-5-3|5.3]] :loop_statement [[Guide:95lrm/RM-5-5|5.5]] :selective_accept [[Guide:95lrm/RM-9-7-1|9.7.1]] :triggering_alternative [[Guide:95lrm/RM-9-7-4|9.7.4]] ;signed_integer_type_definition :integer_type_definition [[Guide:95lrm/RM-3-5-4|3.5.4]] ;simple_expression :first_bit [[Guide:95lrm/RM-13-5-1|13.5.1]] :last_bit [[Guide:95lrm/RM-13-5-1|13.5.1]] :range [[Guide:95lrm/RM-3-5|3.5]] :real_range_specification [[Guide:95lrm/RM-3-5-7|3.5.7]] :relation [[Guide:95lrm/RM-4-4|4.4]] :signed_integer_type_definition [[Guide:95lrm/RM-3-5-4|3.5.4]] ;simple_statement :statement [[Guide:95lrm/RM-5-1|5.1]] ;single_protected_declaration :object_declaration [[Guide:95lrm/RM-3-3-1|3.3.1]] ;single_task_declaration :object_declaration [[Guide:95lrm/RM-3-3-1|3.3.1]] ;slice :name [[Guide:95lrm/RM-4-1|4.1]] ;space_character :graphic_character [[Guide:95lrm/RM-2-1|2.1]] ;special_character :graphic_character [[Guide:95lrm/RM-2-1|2.1]] ;statement :sequence_of_statements [[Guide:95lrm/RM-5-1|5.1]] ;statement_identifier :block_statement [[Guide:95lrm/RM-5-6|5.6]] :label [[Guide:95lrm/RM-5-1|5.1]] :loop_statement [[Guide:95lrm/RM-5-5|5.5]] ;string_element :string_literal [[Guide:95lrm/RM-2-6|2.6]] ;string_literal :operator_symbol [[Guide:95lrm/RM-6-1|6.1]] :primary [[Guide:95lrm/RM-4-4|4.4]] ;subprogram_body :library_unit_body [[Guide:95lrm/RM-10-1-1|10.1.1]] :proper_body [[Guide:95lrm/RM-3-11|3.11]] :protected_operation_item [[Guide:95lrm/RM-9-4|9.4]] ;subprogram_body_stub :body_stub [[Guide:95lrm/RM-10-1-3|10.1.3]] ;subprogram_declaration :basic_declaration [[Guide:95lrm/RM-3-1|3.1]] :library_unit_declaration [[Guide:95lrm/RM-10-1-1|10.1.1]] :protected_operation_declaration [[Guide:95lrm/RM-9-4|9.4]] :protected_operation_item [[Guide:95lrm/RM-9-4|9.4]] ;subprogram_default :formal_subprogram_declaration [[Guide:95lrm/RM-12-6|12.6]] ;subprogram_renaming_declaration :library_unit_renaming_declaration [[Guide:95lrm/RM-10-1-1|10.1.1]] :renaming_declaration [[Guide:95lrm/RM-8-5|8.5]] ;subprogram_specification :abstract_subprogram_declaration [[Guide:95lrm/RM-6-1|6.1]] :formal_subprogram_declaration [[Guide:95lrm/RM-12-6|12.6]] :generic_subprogram_declaration [[Guide:95lrm/RM-12-1|12.1]] :subprogram_body [[Guide:95lrm/RM-6-3|6.3]] :subprogram_body_stub [[Guide:95lrm/RM-10-1-3|10.1.3]] :subprogram_declaration [[Guide:95lrm/RM-6-1|6.1]] :subprogram_renaming_declaration [[Guide:95lrm/RM-8-5-4|8.5.4]] ;subtype_declaration :basic_declaration [[Guide:95lrm/RM-3-1|3.1]] ;subtype_indication :access_to_object_definition [[Guide:95lrm/RM-3-10|3.10]] :allocator [[Guide:95lrm/RM-4-8|4.8]] :component_definition [[Guide:95lrm/RM-3-6|3.6]] :derived_type_definition [[Guide:95lrm/RM-3-4|3.4]] :discrete_range [[Guide:95lrm/RM-3-6-1|3.6.1]] :discrete_subtype_definition [[Guide:95lrm/RM-3-6|3.6]] :object_declaration [[Guide:95lrm/RM-3-3-1|3.3.1]] :private_extension_declaration [[Guide:95lrm/RM-7-3|7.3]] :subtype_declaration [[Guide:95lrm/RM-3-2-2|3.2.2]] ;subtype_mark :access_definition [[Guide:95lrm/RM-3-10|3.10]] :ancestor_part [[Guide:95lrm/RM-4-3-2|4.3.2]] :discriminant_specification [[Guide:95lrm/RM-3-7|3.7]] :explicit_generic_actual_parameter [[Guide:95lrm/RM-12-3|12.3]] :formal_derived_type_definition [[Guide:95lrm/RM-12-5-1|12.5.1]] :formal_object_declaration [[Guide:95lrm/RM-12-4|12.4]] :index_subtype_definition [[Guide:95lrm/RM-3-6|3.6]] :object_renaming_declaration [[Guide:95lrm/RM-8-5-1|8.5.1]] :parameter_and_result_profile [[Guide:95lrm/RM-6-1|6.1]] :parameter_specification [[Guide:95lrm/RM-6-1|6.1]] :qualified_expression [[Guide:95lrm/RM-4-7|4.7]] :relation [[Guide:95lrm/RM-4-4|4.4]] :subtype_indication [[Guide:95lrm/RM-3-2-2|3.2.2]] :type_conversion [[Guide:95lrm/RM-4-6|4.6]] :use_type_clause [[Guide:95lrm/RM-8-4|8.4]] ;subunit :compilation_unit [[Guide:95lrm/RM-10-1-1|10.1.1]] ;task_body :proper_body [[Guide:95lrm/RM-3-11|3.11]] ;task_body_stub :body_stub [[Guide:95lrm/RM-10-1-3|10.1.3]] ;task_definition :single_task_declaration [[Guide:95lrm/RM-9-1|9.1]] :task_type_declaration [[Guide:95lrm/RM-9-1|9.1]] ;task_item :task_definition [[Guide:95lrm/RM-9-1|9.1]] ;task_type_declaration :full_type_declaration [[Guide:95lrm/RM-3-2-1|3.2.1]] ;term :simple_expression [[Guide:95lrm/RM-4-4|4.4]] ;terminate_alternative :select_alternative [[Guide:95lrm/RM-9-7-1|9.7.1]] ;timed_entry_call :select_statement [[Guide:95lrm/RM-9-7|9.7]] ;triggering_alternative :asynchronous_select [[Guide:95lrm/RM-9-7-4|9.7.4]] ;triggering_statement :triggering_alternative [[Guide:95lrm/RM-9-7-4|9.7.4]] ;type_conversion :name [[Guide:95lrm/RM-4-1|4.1]] ;type_declaration :basic_declaration [[Guide:95lrm/RM-3-1|3.1]] ;type_definition :full_type_declaration [[Guide:95lrm/RM-3-2-1|3.2.1]] ;unary_adding_operator :simple_expression [[Guide:95lrm/RM-4-4|4.4]] ;unconstrained_array_definition :array_type_definition [[Guide:95lrm/RM-3-6|3.6]] ;underline :based_numeral [[Guide:95lrm/RM-2-4-2|2.4.2]] :identifier [[Guide:95lrm/RM-2-3|2.3]] :numeral [[Guide:95lrm/RM-2-4-1|2.4.1]] ;unknown_discriminant_part :discriminant_part [[Guide:95lrm/RM-3-7|3.7]] ;use_clause :basic_declarative_item [[Guide:95lrm/RM-3-11|3.11]] :context_item [[Guide:95lrm/RM-10-1-2|10.1.2]] :generic_formal_part [[Guide:95lrm/RM-12-1|12.1]] ;use_package_clause :use_clause [[Guide:95lrm/RM-8-4|8.4]] ;use_type_clause :use_clause [[Guide:95lrm/RM-8-4|8.4]] ;variant :variant_part [[Guide:95lrm/RM-3-8-1|3.8.1]] ;variant_part :component_list [[Guide:95lrm/RM-3-8|3.8]] ;with_clause :context_item [[Guide:95lrm/RM-10-1-2|10.1.2]] </div> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] [[Guide:95lrm/RM-0-29|Index]] [[Guide:95lrm/RM-N|Previous]] [[Guide:95lrm/RM-0-29|Next]] | [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} m11u01kzz3acmu5vg0bqj6oaw1mbihb Guide:95lrm/RM-SRCH 4200 1204 4476 2019-04-29T23:54:38Z imported>WikiVisor 0 Text replacement - "&quot;" to """ wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-0-29|Previous]] === Search the Ada 95 Reference Manual: === Find pages which contain '''All''' of the words: and '''any''' of the words: but '''none''' of the words: Put text in quotes ''"like this"'' for an exact match. </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-0-29|Previous]] {{95lrm}} s2fgexwv0ym0ih2gqalwqbywbgpviqm Guide:95lrm/RM-TOC 4200 1205 4485 4483 2019-05-05T21:04:43Z WikiVisor 11 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-SRCH|Search]]</div> {{DISPLAYTITLE: Table of Contents}} ==== [[Guide:95lrm/RM-0-1|Foreword to this version of the Ada Reference Manual]] ==== ==== [[Guide:95lrm/RM-0-2|Foreword]] ==== ==== [[Guide:95lrm/RM-0-3|Introduction]] ==== == 1. [[Guide:95lrm/RM-1|General]] == ==== 1.1 [[Guide:95lrm/RM-1-1|Scope]] ==== :1.1.1 [[Guide:95lrm/RM-1-1-1|Extent]] :1.1.2 [[Guide:95lrm/RM-1-1-2|Structure]] :1.1.3 [[Guide:95lrm/RM-1-1-3|Conformity of an Implementation with the Standard]] :1.1.4 [[Guide:95lrm/RM-1-1-4|Method of Description and Syntax Notation]] :1.1.5 [[Guide:95lrm/RM-1-1-5|Classification of Errors]] ==== 1.2 [[Guide:95lrm/RM-1-2|Normative References]] ==== ==== 1.3 [[Guide:95lrm/RM-1-3|Definitions]] ==== == 2. [[Guide:95lrm/RM-2|Lexical Elements]] == ==== 2.1 [[Guide:95lrm/RM-2-1|Character Set]] ==== ==== 2.2 [[Guide:95lrm/RM-2-2|Lexical Elements, Separators, and Delimiters]] ==== ==== 2.3 [[Guide:95lrm/RM-2-3|Identifiers]] ==== ==== 2.4 [[Guide:95lrm/RM-2-4|Numeric Literals]] ==== :2.4.1 [[Guide:95lrm/RM-2-4-1|Decimal Literals]] :2.4.2 [[Guide:95lrm/RM-2-4-2|Based Literals]] ==== 2.5 [[Guide:95lrm/RM-2-5|Character Literals]] ==== ==== 2.6 [[Guide:95lrm/RM-2-6|String Literals]] ==== ==== 2.7 [[Guide:95lrm/RM-2-7|Comments]] ==== ==== 2.8 [[Guide:95lrm/RM-2-8|Pragmas]] ==== ==== 2.9 [[Guide:95lrm/RM-2-9|Reserved Words]] ==== == 3. [[Guide:95lrm/RM-3|Declarations and Types]] == ==== 3.1 [[Guide:95lrm/RM-3-1|Declarations]] ==== ==== 3.2 [[Guide:95lrm/RM-3-2|Types and Subtypes]] ==== :3.2.1 [[Guide:95lrm/RM-3-2-1|Type Declarations]] :3.2.2 [[Guide:95lrm/RM-3-2-2|Subtype Declarations]] :3.2.3 [[Guide:95lrm/RM-3-2-3|Classification of Operations]] ==== 3.3 [[Guide:95lrm/RM-3-3|Objects and Named Numbers]] ==== :3.3.1 [[Guide:95lrm/RM-3-3-1|Object Declarations]] :3.3.2 [[Guide:95lrm/RM-3-3-2|Number Declarations]] ==== 3.4 [[Guide:95lrm/RM-3-4|Derived Types and Classes]] ==== :3.4.1 [[Guide:95lrm/RM-3-4-1|Derivation Classes]] ==== 3.5 [[Guide:95lrm/RM-3-5|Scalar Types]] ==== :3.5.1 [[Guide:95lrm/RM-3-5-1|Enumeration Types]] :3.5.2 [[Guide:95lrm/RM-3-5-2|Character Types]] :3.5.3 [[Guide:95lrm/RM-3-5-3|Boolean Types]] :3.5.4 [[Guide:95lrm/RM-3-5-4|Integer Types]] :3.5.5 [[Guide:95lrm/RM-3-5-5|Operations of Discrete Types]] :3.5.6 [[Guide:95lrm/RM-3-5-6|Real Types]] :3.5.7 [[Guide:95lrm/RM-3-5-7|Floating Point Types]] :3.5.8 [[Guide:95lrm/RM-3-5-8|Operations of Floating Point Types]] :3.5.9 [[Guide:95lrm/RM-3-5-9|Fixed Point Types]] :3.5.10 [[Guide:95lrm/RM-3-5-10|Operations of Fixed Point Types]] ==== 3.6 [[Guide:95lrm/RM-3-6|Array Types]] ==== :3.6.1 [[Guide:95lrm/RM-3-6-1|Index Constraints and Discrete Ranges]] :3.6.2 [[Guide:95lrm/RM-3-6-2|Operations of Array Types]] :3.6.3 [[Guide:95lrm/RM-3-6-3|String Types]] ==== 3.7 [[Guide:95lrm/RM-3-7|Discriminants]] ==== :3.7.1 [[Guide:95lrm/RM-3-7-1|Discriminant Constraints]] :3.7.2 [[Guide:95lrm/RM-3-7-2|Operations of Discriminated Types]] ==== 3.8 [[Guide:95lrm/RM-3-8|Record Types]] ==== :3.8.1 [[Guide:95lrm/RM-3-8-1|Variant Parts and Discrete Choices]] ==== 3.9 [[Guide:95lrm/RM-3-9|Tagged Types and Type Extensions]] ==== :3.9.1 [[Guide:95lrm/RM-3-9-1|Type Extensions]] :3.9.2 [[Guide:95lrm/RM-3-9-2|Dispatching Operations of Tagged Types]] :3.9.3 [[Guide:95lrm/RM-3-9-3|Abstract Types and Subprograms]] ==== 3.10 [[Guide:95lrm/RM-3-10|Access Types]] ==== :3.10.1 [[Guide:95lrm/RM-3-10-1|Incomplete Type Declarations]] :3.10.2 [[Guide:95lrm/RM-3-10-2|Operations of Access Types]] ==== 3.11 [[Guide:95lrm/RM-3-11|Declarative Parts]] ==== :3.11.1 [[Guide:95lrm/RM-3-11-1|Completions of Declarations]] == 4. [[Guide:95lrm/RM-4|Names and Expressions]] == ==== 4.1 [[Guide:95lrm/RM-4-1|Names]] ==== :4.1.1 [[Guide:95lrm/RM-4-1-1|Indexed Components]] :4.1.2 [[Guide:95lrm/RM-4-1-2|Slices]] :4.1.3 [[Guide:95lrm/RM-4-1-3|Selected Components]] :4.1.4 [[Guide:95lrm/RM-4-1-4|Attributes]] ==== 4.2 [[Guide:95lrm/RM-4-2|Literals]] ==== ==== 4.3 [[Guide:95lrm/RM-4-3|Aggregates]] ==== :4.3.1 [[Guide:95lrm/RM-4-3-1|Record Aggregates]] :4.3.2 [[Guide:95lrm/RM-4-3-2|Extension Aggregates]] :4.3.3 [[Guide:95lrm/RM-4-3-3|Array Aggregates]] ==== 4.4 [[Guide:95lrm/RM-4-4|Expressions]] ==== ==== 4.5 [[Guide:95lrm/RM-4-5|Operators and Expression Evaluation]] ==== :4.5.1 [[Guide:95lrm/RM-4-5-1|Logical Operators and Short-circuit Control Forms]] :4.5.2 [[Guide:95lrm/RM-4-5-2|Relational Operators and Membership Tests]] :4.5.3 [[Guide:95lrm/RM-4-5-3|Binary Adding Operators]] :4.5.4 [[Guide:95lrm/RM-4-5-4|Unary Adding Operators]] :4.5.5 [[Guide:95lrm/RM-4-5-5|Multiplying Operators]] :4.5.6 [[Guide:95lrm/RM-4-5-6|Highest Precedence Operators]] ==== 4.6 [[Guide:95lrm/RM-4-6|Type Conversions]] ==== ==== 4.7 [[Guide:95lrm/RM-4-7|Qualified Expressions]] ==== ==== 4.8 [[Guide:95lrm/RM-4-8|Allocators]] ==== ==== 4.9 [[Guide:95lrm/RM-4-9|Static Expressions and Static Subtypes]] ==== :4.9.1 [[Guide:95lrm/RM-4-9-1|Statically Matching Constraints and Subtypes]] == 5. [[Guide:95lrm/RM-5|Statements]] == ==== 5.1 [[Guide:95lrm/RM-5-1|Simple and Compound Statements - Sequences of Statements]] ==== ==== 5.2 [[Guide:95lrm/RM-5-2|Assignment Statements]] ==== ==== 5.3 [[Guide:95lrm/RM-5-3|If Statements]] ==== ==== 5.4 [[Guide:95lrm/RM-5-4|Case Statements]] ==== ==== 5.5 [[Guide:95lrm/RM-5-5|Loop Statements]] ==== ==== 5.6 [[Guide:95lrm/RM-5-6|Block Statements]] ==== ==== 5.7 [[Guide:95lrm/RM-5-7|Exit Statements]] ==== ==== 5.8 [[Guide:95lrm/RM-5-8|Goto Statements]] ==== == 6. [[Guide:95lrm/RM-6|Subprograms]] == ==== 6.1 [[Guide:95lrm/RM-6-1|Subprogram Declarations]] ==== ==== 6.2 [[Guide:95lrm/RM-6-2|Formal Parameter Modes]] ==== ==== 6.3 [[Guide:95lrm/RM-6-3|Subprogram Bodies]] ==== :6.3.1 [[Guide:95lrm/RM-6-3-1|Conformance Rules]] :6.3.2 [[Guide:95lrm/RM-6-3-2|Inline Expansion of Subprograms]] ==== 6.4 [[Guide:95lrm/RM-6-4|Subprogram Calls]] ==== :6.4.1 [[Guide:95lrm/RM-6-4-1|Parameter Associations]] ==== 6.5 [[Guide:95lrm/RM-6-5|Return Statements]] ==== ==== 6.6 [[Guide:95lrm/RM-6-6|Overloading of Operators]] ==== == 7. [[Guide:95lrm/RM-7|Packages]] == ==== 7.1 [[Guide:95lrm/RM-7-1|Package Specifications and Declarations]] ==== ==== 7.2 [[Guide:95lrm/RM-7-2|Package Bodies]] ==== ==== 7.3 [[Guide:95lrm/RM-7-3|Private Types and Private Extensions]] ==== :7.3.1 [[Guide:95lrm/RM-7-3-1|Private Operations]] ==== 7.4 [[Guide:95lrm/RM-7-4|Deferred Constants]] ==== ==== 7.5 [[Guide:95lrm/RM-7-5|Limited Types]] ==== ==== 7.6 [[Guide:95lrm/RM-7-6|User-Defined Assignment and Finalization]] ==== :7.6.1 [[Guide:95lrm/RM-7-6-1|Completion and Finalization]] == 8. [[Guide:95lrm/RM-8|Visibility Rules]] == ==== 8.1 [[Guide:95lrm/RM-8-1|Declarative Region]] ==== ==== 8.2 [[Guide:95lrm/RM-8-2|Scope of Declarations]] ==== ==== 8.3 [[Guide:95lrm/RM-8-3|Visibility]] ==== ==== 8.4 [[Guide:95lrm/RM-8-4|Use Clauses]] ==== ==== 8.5 [[Guide:95lrm/RM-8-5|Renaming Declarations]] ==== :8.5.1 [[Guide:95lrm/RM-8-5-1|Object Renaming Declarations]] :8.5.2 [[Guide:95lrm/RM-8-5-2|Exception Renaming Declarations]] :8.5.3 [[Guide:95lrm/RM-8-5-3|Package Renaming Declarations]] :8.5.4 [[Guide:95lrm/RM-8-5-4|Subprogram Renaming Declarations]] :8.5.5 [[Guide:95lrm/RM-8-5-5|Generic Renaming Declarations]] ==== 8.6 [[Guide:95lrm/RM-8-6|The Context of Overload Resolution]] ==== == 9. [[Guide:95lrm/RM-9|Tasks and Synchronization]] == ==== 9.1 [[Guide:95lrm/RM-9-1|Task Units and Task Objects]] ==== ==== 9.2 [[Guide:95lrm/RM-9-2|Task Execution - Task Activation]] ==== ==== 9.3 [[Guide:95lrm/RM-9-3|Task Dependence - Termination of Tasks]] ==== ==== 9.4 [[Guide:95lrm/RM-9-4|Protected Units and Protected Objects]] ==== ==== 9.5 [[Guide:95lrm/RM-9-5|Intertask Communication]] ==== :9.5.1 [[Guide:95lrm/RM-9-5-1|Protected Subprograms and Protected Actions]] :9.5.2 [[Guide:95lrm/RM-9-5-2|Entries and Accept Statements]] :9.5.3 [[Guide:95lrm/RM-9-5-3|Entry Calls]] :9.5.4 [[Guide:95lrm/RM-9-5-4|Requeue Statements]] ==== 9.6 [[Guide:95lrm/RM-9-6|Delay Statements, Duration, and Time]] ==== ==== 9.7 [[Guide:95lrm/RM-9-7|Select Statements]] ==== :9.7.1 [[Guide:95lrm/RM-9-7-1|Selective Accept]] :9.7.2 [[Guide:95lrm/RM-9-7-2|Timed Entry Calls]] :9.7.3 [[Guide:95lrm/RM-9-7-3|Conditional Entry Calls]] :9.7.4 [[Guide:95lrm/RM-9-7-4|Asynchronous Transfer of Control]] ==== 9.8 [[Guide:95lrm/RM-9-8|Abort of a Task - Abort of a Sequence of Statements]] ==== ==== 9.9 [[Guide:95lrm/RM-9-9|Task and Entry Attributes]] ==== ==== 9.10 [[Guide:95lrm/RM-9-10|Shared Variables]] ==== ==== 9.11 [[Guide:95lrm/RM-9-11|Example of Tasking and Synchronization]] ==== == 10. [[Guide:95lrm/RM-10|Program Structure and Compilation Issues]] == ==== 10.1 [[Guide:95lrm/RM-10-1|Separate Compilation]] ==== :10.1.1 [[Guide:95lrm/RM-10-1-1|Compilation Units - Library Units]] :10.1.2 [[Guide:95lrm/RM-10-1-2|Context Clauses - With Clauses]] :10.1.3 [[Guide:95lrm/RM-10-1-3|Subunits of Compilation Units]] :10.1.4 [[Guide:95lrm/RM-10-1-4|The Compilation Process]] :10.1.5 [[Guide:95lrm/RM-10-1-5|Pragmas and Program Units]] :10.1.6 [[Guide:95lrm/RM-10-1-6|Environment-Level Visibility Rules]] ==== 10.2 [[Guide:95lrm/RM-10-2|Program Execution]] ==== :10.2.1 [[Guide:95lrm/RM-10-2-1|Elaboration Control]] == 11. [[Guide:95lrm/RM-11|Exceptions]] == ==== 11.1 [[Guide:95lrm/RM-11-1|Exception Declarations]] ==== ==== 11.2 [[Guide:95lrm/RM-11-2|Exception Handlers]] ==== ==== 11.3 [[Guide:95lrm/RM-11-3|Raise Statements]] ==== ==== 11.4 [[Guide:95lrm/RM-11-4|Exception Handling]] ==== :11.4.1 [[Guide:95lrm/RM-11-4-1|The Package Exceptions]] :11.4.2 [[Guide:95lrm/RM-11-4-2|Example of Exception Handling]] ==== 11.5 [[Guide:95lrm/RM-11-5|Suppressing Checks]] ==== ==== 11.6 [[Guide:95lrm/RM-11-6|Exceptions and Optimization]] ==== == 12. [[Guide:95lrm/RM-12|Generic Units]] == ==== 12.1 [[Guide:95lrm/RM-12-1|Generic Declarations]] ==== ==== 12.2 [[Guide:95lrm/RM-12-2|Generic Bodies]] ==== ==== 12.3 [[Guide:95lrm/RM-12-3|Generic Instantiation]] ==== ==== 12.4 [[Guide:95lrm/RM-12-4|Formal Objects]] ==== ==== 12.5 [[Guide:95lrm/RM-12-5|Formal Types]] ==== :12.5.1 [[Guide:95lrm/RM-12-5-1|Formal Private and Derived Types]] :12.5.2 [[Guide:95lrm/RM-12-5-2|Formal Scalar Types]] :12.5.3 [[Guide:95lrm/RM-12-5-3|Formal Array Types]] :12.5.4 [[Guide:95lrm/RM-12-5-4|Formal Access Types]] ==== 12.6 [[Guide:95lrm/RM-12-6|Formal Subprograms]] ==== ==== 12.7 [[Guide:95lrm/RM-12-7|Formal Packages]] ==== ==== 12.8 [[Guide:95lrm/RM-12-8|Example of a Generic Package]] ==== == 13. [[Guide:95lrm/RM-13|Representation Issues]] == ==== 13.1 [[Guide:95lrm/RM-13-1|Operational and Representation Items]] ==== ==== 13.2 [[Guide:95lrm/RM-13-2|Pragma Pack]] ==== ==== 13.3 [[Guide:95lrm/RM-13-3|Operational and Representation Attributes]] ==== ==== 13.4 [[Guide:95lrm/RM-13-4|Enumeration Representation Clauses]] ==== ==== 13.5 [[Guide:95lrm/RM-13-5|Record Layout]] ==== :13.5.1 [[Guide:95lrm/RM-13-5-1|Record Representation Clauses]] :13.5.2 [[Guide:95lrm/RM-13-5-2|Storage Place Attributes]] :13.5.3 [[Guide:95lrm/RM-13-5-3|Bit Ordering]] ==== 13.6 [[Guide:95lrm/RM-13-6|Change of Representation]] ==== ==== 13.7 [[Guide:95lrm/RM-13-7|The Package System]] ==== :13.7.1 [[Guide:95lrm/RM-13-7-1|The Package System.Storage_Elements]] :13.7.2 [[Guide:95lrm/RM-13-7-2|The Package System.Address_To_Access_Conversions]] ==== 13.8 [[Guide:95lrm/RM-13-8|Machine Code Insertions]] ==== ==== 13.9 [[Guide:95lrm/RM-13-9|Unchecked Type Conversions]] ==== :13.9.1 [[Guide:95lrm/RM-13-9-1|Data Validity]] :13.9.2 [[Guide:95lrm/RM-13-9-2|The Valid Attribute]] ==== 13.10 [[Guide:95lrm/RM-13-10|Unchecked Access Value Creation]] ==== ==== 13.11 [[Guide:95lrm/RM-13-11|Storage Management]] ==== :13.11.1 [[Guide:95lrm/RM-13-11-1|The Max_Size_In_Storage_Elements Attribute]] :13.11.2 [[Guide:95lrm/RM-13-11-2|Unchecked Storage Deallocation]] :13.11.3 [[Guide:95lrm/RM-13-11-3|Pragma Controlled]] ==== 13.12 [[Guide:95lrm/RM-13-12|Pragma Restrictions]] ==== ==== 13.13 [[Guide:95lrm/RM-13-13|Streams]] ==== :13.13.1 [[Guide:95lrm/RM-13-13-1|The Package Streams]] :13.13.2 [[Guide:95lrm/RM-13-13-2|Stream-Oriented Attributes]] ==== 13.14 [[Guide:95lrm/RM-13-14|Freezing Rules]] ==== = [[Guide:95lrm/RM-0-28|The Standard Libraries]] = == A. [[Guide:95lrm/RM-A|Predefined Language Environment]] == ==== A.1 [[Guide:95lrm/RM-A-1|The Package Standard]] ==== ==== A.2 [[Guide:95lrm/RM-A-2|The Package Ada]] ==== ==== A.3 [[Guide:95lrm/RM-A-3|Character Handling]] ==== :A.3.1 [[Guide:95lrm/RM-A-3-1|The Package Characters]] :A.3.2 [[Guide:95lrm/RM-A-3-2|The Package Characters.Handling]] :A.3.3 [[Guide:95lrm/RM-A-3-3|The Package Characters.Latin_1]] ==== A.4 [[Guide:95lrm/RM-A-4|String Handling]] ==== :A.4.1 [[Guide:95lrm/RM-A-4-1|The Package Strings]] :A.4.2 [[Guide:95lrm/RM-A-4-2|The Package Strings.Maps]] :A.4.3 [[Guide:95lrm/RM-A-4-3|Fixed-Length String Handling]] :A.4.4 [[Guide:95lrm/RM-A-4-4|Bounded-Length String Handling]] :A.4.5 [[Guide:95lrm/RM-A-4-5|Unbounded-Length String Handling]] :A.4.6 [[Guide:95lrm/RM-A-4-6|String-Handling Sets and Mappings]] :A.4.7 [[Guide:95lrm/RM-A-4-7|Wide_String Handling]] ==== A.5 [[Guide:95lrm/RM-A-5|The Numerics Packages]] ==== :A.5.1 [[Guide:95lrm/RM-A-5-1|Elementary Functions]] :A.5.2 [[Guide:95lrm/RM-A-5-2|Random Number Generation]] :A.5.3 [[Guide:95lrm/RM-A-5-3|Attributes of Floating Point Types]] :A.5.4 [[Guide:95lrm/RM-A-5-4|Attributes of Fixed Point Types]] ==== A.6 [[Guide:95lrm/RM-A-6|Input-Output]] ==== ==== A.7 [[Guide:95lrm/RM-A-7|External Files and File Objects]] ==== ==== A.8 [[Guide:95lrm/RM-A-8|Sequential and Direct Files]] ==== :A.8.1 [[Guide:95lrm/RM-A-8-1|The Generic Package Sequential_IO]] :A.8.2 [[Guide:95lrm/RM-A-8-2|File Management]] :A.8.3 [[Guide:95lrm/RM-A-8-3|Sequential Input-Output Operations]] :A.8.4 [[Guide:95lrm/RM-A-8-4|The Generic Package Direct_IO]] :A.8.5 [[Guide:95lrm/RM-A-8-5|Direct Input-Output Operations]] ==== A.9 [[Guide:95lrm/RM-A-9|The Generic Package Storage_IO]] ==== ==== A.10 [[Guide:95lrm/RM-A-10|Text Input-Output]] ==== :A.10.1 [[Guide:95lrm/RM-A-10-1|The Package Text_IO]] :A.10.2 [[Guide:95lrm/RM-A-10-2|Text File Management]] :A.10.3 [[Guide:95lrm/RM-A-10-3|Default Input, Output, and Error Files]] :A.10.4 [[Guide:95lrm/RM-A-10-4|Specification of Line and Page Lengths]] :A.10.5 [[Guide:95lrm/RM-A-10-5|Operations on Columns, Lines, and Pages]] :A.10.6 [[Guide:95lrm/RM-A-10-6|Get and Put Procedures]] :A.10.7 [[Guide:95lrm/RM-A-10-7|Input-Output of Characters and Strings]] :A.10.8 [[Guide:95lrm/RM-A-10-8|Input-Output for Integer Types]] :A.10.9 [[Guide:95lrm/RM-A-10-9|Input-Output for Real Types]] :A.10.10 [[Guide:95lrm/RM-A-10-10|Input-Output for Enumeration Types]] ==== A.11 [[Guide:95lrm/RM-A-11|Wide Text Input-Output]] ==== ==== A.12 [[Guide:95lrm/RM-A-12|Stream Input-Output]] ==== :A.12.1 [[Guide:95lrm/RM-A-12-1|The Package Streams.Stream_IO]] :A.12.2 [[Guide:95lrm/RM-A-12-2|The Package Text_IO.Text_Streams]] :A.12.3 [[Guide:95lrm/RM-A-12-3|The Package Wide_Text_IO.Text_Streams]] ==== A.13 [[Guide:95lrm/RM-A-13|Exceptions in Input-Output]] ==== ==== A.14 [[Guide:95lrm/RM-A-14|File Sharing]] ==== ==== A.15 [[Guide:95lrm/RM-A-15|The Package Command_Line]] ==== == B. [[Guide:95lrm/RM-B|Interface to Other Languages]] == ==== B.1 [[Guide:95lrm/RM-B-1|Interfacing Pragmas]] ==== ==== B.2 [[Guide:95lrm/RM-B-2|The Package Interfaces]] ==== ==== B.3 [[Guide:95lrm/RM-B-3|Interfacing with C]] ==== :B.3.1 [[Guide:95lrm/RM-B-3-1|The Package Interfaces.C.Strings]] :B.3.2 [[Guide:95lrm/RM-B-3-2|The Generic Package Interfaces.C.Pointers]] ==== B.4 [[Guide:95lrm/RM-B-4|Interfacing with COBOL]] ==== ==== B.5 [[Guide:95lrm/RM-B-5|Interfacing with Fortran]] ==== == C. [[Guide:95lrm/RM-C|Systems Programming]] == ==== C.1 [[Guide:95lrm/RM-C-1|Access to Machine Operations]] ==== ==== C.2 [[Guide:95lrm/RM-C-2|Required Representation Support]] ==== ==== C.3 [[Guide:95lrm/RM-C-3|Interrupt Support]] ==== :C.3.1 [[Guide:95lrm/RM-C-3-1|Protected Procedure Handlers]] :C.3.2 [[Guide:95lrm/RM-C-3-2|The Package Interrupts]] ==== C.4 [[Guide:95lrm/RM-C-4|Preelaboration Requirements]] ==== ==== C.5 [[Guide:95lrm/RM-C-5|Pragma Discard_Names]] ==== ==== C.6 [[Guide:95lrm/RM-C-6|Shared Variable Control]] ==== ==== C.7 [[Guide:95lrm/RM-C-7|Task Identification and Attributes]] ==== :C.7.1 [[Guide:95lrm/RM-C-7-1|The Package Task_Identification]] :C.7.2 [[Guide:95lrm/RM-C-7-2|The Package Task_Attributes]] == D. [[Guide:95lrm/RM-D|Real-Time Systems]] == ==== D.1 [[Guide:95lrm/RM-D-1|Task Priorities]] ==== ==== D.2 [[Guide:95lrm/RM-D-2|Priority Scheduling]] ==== :D.2.1 [[Guide:95lrm/RM-D-2-1|The Task Dispatching Model]] :D.2.2 [[Guide:95lrm/RM-D-2-2|The Standard Task Dispatching Policy]] ==== D.3 [[Guide:95lrm/RM-D-3|Priority Ceiling Locking]] ==== ==== D.4 [[Guide:95lrm/RM-D-4|Entry Queuing Policies]] ==== ==== D.5 [[Guide:95lrm/RM-D-5|Dynamic Priorities]] ==== ==== D.6 [[Guide:95lrm/RM-D-6|Preemptive Abort]] ==== ==== D.7 [[Guide:95lrm/RM-D-7|Tasking Restrictions]] ==== ==== D.8 [[Guide:95lrm/RM-D-8|Monotonic Time]] ==== ==== D.9 [[Guide:95lrm/RM-D-9|Delay Accuracy]] ==== ==== D.10 [[Guide:95lrm/RM-D-10|Synchronous Task Control]] ==== ==== D.11 [[Guide:95lrm/RM-D-11|Asynchronous Task Control]] ==== ==== D.12 [[Guide:95lrm/RM-D-12|Other Optimizations and Determinism Rules]] ==== == E. [[Guide:95lrm/RM-E|Distributed Systems]] == ==== E.1 [[Guide:95lrm/RM-E-1|Partitions]] ==== ==== E.2 [[Guide:95lrm/RM-E-2|Categorization of Library Units]] ==== :E.2.1 [[Guide:95lrm/RM-E-2-1|Shared Passive Library Units]] :E.2.2 [[Guide:95lrm/RM-E-2-2|Remote Types Library Units]] :E.2.3 [[Guide:95lrm/RM-E-2-3|Remote Call Interface Library Units]] ==== E.3 [[Guide:95lrm/RM-E-3|Consistency of a Distributed System]] ==== ==== E.4 [[Guide:95lrm/RM-E-4|Remote Subprogram Calls]] ==== :E.4.1 [[Guide:95lrm/RM-E-4-1|Pragma Asynchronous]] :E.4.2 [[Guide:95lrm/RM-E-4-2|Example of Use of a Remote Access-to-Class-Wide Type]] ==== E.5 [[Guide:95lrm/RM-E-5|Partition Communication Subsystem]] ==== == F. [[Guide:95lrm/RM-F|Information Systems]] == ==== F.1 [[Guide:95lrm/RM-F-1|Machine_Radix Attribute Definition Clause]] ==== ==== F.2 [[Guide:95lrm/RM-F-2|The Package Decimal]] ==== ==== F.3 [[Guide:95lrm/RM-F-3|Edited Output for Decimal Types]] ==== :F.3.1 [[Guide:95lrm/RM-F-3-1|Picture String Formation]] :F.3.2 [[Guide:95lrm/RM-F-3-2|Edited Output Generation]] :F.3.3 [[Guide:95lrm/RM-F-3-3|The Package Text_IO.Editing]] :F.3.4 [[Guide:95lrm/RM-F-3-4|The Package Wide_Text_IO.Editing]] == G. [[Guide:95lrm/RM-G|Numerics]] == ==== G.1 [[Guide:95lrm/RM-G-1|Complex Arithmetic]] ==== :G.1.1 [[Guide:95lrm/RM-G-1-1|Complex Types]] :G.1.2 [[Guide:95lrm/RM-G-1-2|Complex Elementary Functions]] :G.1.3 [[Guide:95lrm/RM-G-1-3|Complex Input-Output]] :G.1.4 [[Guide:95lrm/RM-G-1-4|The Package Wide_Text_IO.Complex_IO]] ==== G.2 [[Guide:95lrm/RM-G-2|Numeric Performance Requirements]] ==== :G.2.1 [[Guide:95lrm/RM-G-2-1|Model of Floating Point Arithmetic]] :G.2.2 [[Guide:95lrm/RM-G-2-2|Model-Oriented Attributes of Floating Point Types]] :G.2.3 [[Guide:95lrm/RM-G-2-3|Model of Fixed Point Arithmetic]] :G.2.4 [[Guide:95lrm/RM-G-2-4|Accuracy Requirements for the Elementary Functions]] :G.2.5 [[Guide:95lrm/RM-G-2-5|Performance Requirements for Random Number Generation]] :G.2.6 [[Guide:95lrm/RM-G-2-6|Accuracy Requirements for Complex Arithmetic]] == H. [[Guide:95lrm/RM-H|Safety and Security]] == ==== H.1 [[Guide:95lrm/RM-H-1|Pragma Normalize_Scalars]] ==== ==== H.2 [[Guide:95lrm/RM-H-2|Documentation of Implementation Decisions]] ==== ==== H.3 [[Guide:95lrm/RM-H-3|Reviewable Object Code]] ==== :H.3.1 [[Guide:95lrm/RM-H-3-1|Pragma Reviewable]] :H.3.2 [[Guide:95lrm/RM-H-3-2|Pragma Inspection_Point]] ==== H.4 [[Guide:95lrm/RM-H-4|Safety and Security Restrictions]] ==== == J. [[Guide:95lrm/RM-J|Obsolescent Features]] == ==== J.1 [[Guide:95lrm/RM-J-1|Renamings of Ada 83 Library Units]] ==== ==== J.2 [[Guide:95lrm/RM-J-2|Allowed Replacements of Characters]] ==== ==== J.3 [[Guide:95lrm/RM-J-3|Reduced Accuracy Subtypes]] ==== ==== J.4 [[Guide:95lrm/RM-J-4|The Constrained Attribute]] ==== ==== J.5 [[Guide:95lrm/RM-J-5|ASCII]] ==== ==== J.6 [[Guide:95lrm/RM-J-6|Numeric_Error]] ==== ==== J.7 [[Guide:95lrm/RM-J-7|At Clauses]] ==== :J.7.1 [[Guide:95lrm/RM-J-7-1|Interrupt Entries]] ==== J.8 [[Guide:95lrm/RM-J-8|Mod Clauses]] ==== ==== J.9 [[Guide:95lrm/RM-J-9|The Storage_Size Attribute]] ==== == K. [[Guide:95lrm/RM-K|Language-Defined Attributes]] == == L. [[Guide:95lrm/RM-L|Language-Defined Pragmas]] == == M. [[Guide:95lrm/RM-M|Implementation-Defined Characteristics]] == == N. [[Guide:95lrm/RM-N|Glossary]] == == P. [[Guide:95lrm/RM-P|Syntax Summary]] == = <span style="font-size:30px"> [[Guide:95lrm/RM-0-29|Index]]</span> = </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-0-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} c0fz5r4y5ytliqqu351m5fk85xldlvd Guide:95lrm/RM-TTL 4200 1206 4498 4478 2019-05-05T23:58:24Z WikiVisor 11 wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-SRCH|Search]] <div class="text-right"> '''Ada Reference Manual''', ISO/IEC 8652:1995(E) with COR.1:2000 </div> <div class="text-center"> <h1>'''Ada Reference Manual'''</h1> ISO/IEC 8652:1995(E) with Technical Corrigendum 1 Language and Standard Libraries </div> <div style="font-size:small;margin-top:8em"> <p>'''Ada Reference Manual - Language and Standard Libraries'''</p> <hr/> Copyright © 1992, 1993, 1994, 1995, Intermetrics, Inc. This copyright is assigned to the U.S. Government. All rights reserved. This document may be copied, in whole or in part, in any form or by any means, as is or with alterations, provided that (1) alterations are clearly marked as alterations and (2) this copyright notice is included unmodified in any copy. Compiled copies of standard library units and examples need not contain this copyright notice so long as the notice is included in all copies of source code and documentation. <p>'''Technical Corrigendum 1'''</p> <hr/> Copyright © 2000, The MITRE Corporation. All Rights Reserved. This document may be copied, in whole or in part, in any form or by any means, as is, or with alterations, provided that (1) alterations are clearly marked as alterations and (2) this copyright notice is included unmodified in any copy. Any other use or distribution of this document is prohibited without the prior express permission of MITRE. You use this document on the condition that you indemnify and hold harmless MITRE, its Board of Trustees, officers, agents, and employees, from any and all liability or damages to yourself or your hardware or software, or third parties, including attorneys' fees, court costs, and other related costs and expenses, arising out of your use of this document irrespective of the cause of said liability. MITRE MAKES THIS DOCUMENT AVAILABLE ON AN "AS IS" BASIS AND MAKES NO WARRANTY, EXPRESS OR IMPLIED, AS TO THE ACCURACY, CAPABILITY, EFFICIENCY MERCHANTABILITY, OR FUNCTIONING OF THIS DOCUMENT. IN NO EVENT WILL MITRE BE LIABLE FOR ANY GENERAL, CONSEQUENTIAL, INDIRECT, INCIDENTAL, EXEMPLARY, OR SPECIAL DAMAGES, EVEN IF MITRE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. </div> </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} bumyt5jvj3h532tl8urdtwpn9707wbb Guide:95lrm/index 4200 1207 4479 2019-04-29T15:48:31Z imported>WikiVisor 0 1 revision imported wikitext text/x-wiki <div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-SRCH|Search]] {{DISPLAYTITLE: Table of Contents}} [[Guide:95lrm/RM-0-1|Foreword to this version of the Ada Reference Manual]] [[Guide:95lrm/RM-0-2|Foreword]] [[Guide:95lrm/RM-0-3|Introduction]] 1. [[Guide:95lrm/RM-1|General]] 1.1 [[Guide:95lrm/RM-1-1|Scope]] 1.1.1 [[Guide:95lrm/RM-1-1-1|Extent]] 1.1.2 [[Guide:95lrm/RM-1-1-2|Structure]] 1.1.3 [[Guide:95lrm/RM-1-1-3|Conformity of an Implementation with the Standard]] 1.1.4 [[Guide:95lrm/RM-1-1-4|Method of Description and Syntax Notation]] 1.1.5 [[Guide:95lrm/RM-1-1-5|Classification of Errors]] 1.2 [[Guide:95lrm/RM-1-2|Normative References]] 1.3 [[Guide:95lrm/RM-1-3|Definitions]] 2. [[Guide:95lrm/RM-2|Lexical Elements]] 2.1 [[Guide:95lrm/RM-2-1|Character Set]] 2.2 [[Guide:95lrm/RM-2-2|Lexical Elements, Separators, and Delimiters]] 2.3 [[Guide:95lrm/RM-2-3|Identifiers]] 2.4 [[Guide:95lrm/RM-2-4|Numeric Literals]] 2.4.1 [[Guide:95lrm/RM-2-4-1|Decimal Literals]] 2.4.2 [[Guide:95lrm/RM-2-4-2|Based Literals]] 2.5 [[Guide:95lrm/RM-2-5|Character Literals]] 2.6 [[Guide:95lrm/RM-2-6|String Literals]] 2.7 [[Guide:95lrm/RM-2-7|Comments]] 2.8 [[Guide:95lrm/RM-2-8|Pragmas]] 2.9 [[Guide:95lrm/RM-2-9|Reserved Words]] 3. [[Guide:95lrm/RM-3|Declarations and Types]] 3.1 [[Guide:95lrm/RM-3-1|Declarations]] 3.2 [[Guide:95lrm/RM-3-2|Types and Subtypes]] 3.2.1 [[Guide:95lrm/RM-3-2-1|Type Declarations]] 3.2.2 [[Guide:95lrm/RM-3-2-2|Subtype Declarations]] 3.2.3 [[Guide:95lrm/RM-3-2-3|Classification of Operations]] 3.3 [[Guide:95lrm/RM-3-3|Objects and Named Numbers]] 3.3.1 [[Guide:95lrm/RM-3-3-1|Object Declarations]] 3.3.2 [[Guide:95lrm/RM-3-3-2|Number Declarations]] 3.4 [[Guide:95lrm/RM-3-4|Derived Types and Classes]] 3.4.1 [[Guide:95lrm/RM-3-4-1|Derivation Classes]] 3.5 [[Guide:95lrm/RM-3-5|Scalar Types]] 3.5.1 [[Guide:95lrm/RM-3-5-1|Enumeration Types]] 3.5.2 [[Guide:95lrm/RM-3-5-2|Character Types]] 3.5.3 [[Guide:95lrm/RM-3-5-3|Boolean Types]] 3.5.4 [[Guide:95lrm/RM-3-5-4|Integer Types]] 3.5.5 [[Guide:95lrm/RM-3-5-5|Operations of Discrete Types]] 3.5.6 [[Guide:95lrm/RM-3-5-6|Real Types]] 3.5.7 [[Guide:95lrm/RM-3-5-7|Floating Point Types]] 3.5.8 [[Guide:95lrm/RM-3-5-8|Operations of Floating Point Types]] 3.5.9 [[Guide:95lrm/RM-3-5-9|Fixed Point Types]] 3.5.10 [[Guide:95lrm/RM-3-5-10|Operations of Fixed Point Types]] 3.6 [[Guide:95lrm/RM-3-6|Array Types]] 3.6.1 [[Guide:95lrm/RM-3-6-1|Index Constraints and Discrete Ranges]] 3.6.2 [[Guide:95lrm/RM-3-6-2|Operations of Array Types]] 3.6.3 [[Guide:95lrm/RM-3-6-3|String Types]] 3.7 [[Guide:95lrm/RM-3-7|Discriminants]] 3.7.1 [[Guide:95lrm/RM-3-7-1|Discriminant Constraints]] 3.7.2 [[Guide:95lrm/RM-3-7-2|Operations of Discriminated Types]] 3.8 [[Guide:95lrm/RM-3-8|Record Types]] 3.8.1 [[Guide:95lrm/RM-3-8-1|Variant Parts and Discrete Choices]] 3.9 [[Guide:95lrm/RM-3-9|Tagged Types and Type Extensions]] 3.9.1 [[Guide:95lrm/RM-3-9-1|Type Extensions]] 3.9.2 [[Guide:95lrm/RM-3-9-2|Dispatching Operations of Tagged Types]] 3.9.3 [[Guide:95lrm/RM-3-9-3|Abstract Types and Subprograms]] 3.10 [[Guide:95lrm/RM-3-10|Access Types]] 3.10.1 [[Guide:95lrm/RM-3-10-1|Incomplete Type Declarations]] 3.10.2 [[Guide:95lrm/RM-3-10-2|Operations of Access Types]] 3.11 [[Guide:95lrm/RM-3-11|Declarative Parts]] 3.11.1 [[Guide:95lrm/RM-3-11-1|Completions of Declarations]] 4. [[Guide:95lrm/RM-4|Names and Expressions]] 4.1 [[Guide:95lrm/RM-4-1|Names]] 4.1.1 [[Guide:95lrm/RM-4-1-1|Indexed Components]] 4.1.2 [[Guide:95lrm/RM-4-1-2|Slices]] 4.1.3 [[Guide:95lrm/RM-4-1-3|Selected Components]] 4.1.4 [[Guide:95lrm/RM-4-1-4|Attributes]] 4.2 [[Guide:95lrm/RM-4-2|Literals]] 4.3 [[Guide:95lrm/RM-4-3|Aggregates]] 4.3.1 [[Guide:95lrm/RM-4-3-1|Record Aggregates]] 4.3.2 [[Guide:95lrm/RM-4-3-2|Extension Aggregates]] 4.3.3 [[Guide:95lrm/RM-4-3-3|Array Aggregates]] 4.4 [[Guide:95lrm/RM-4-4|Expressions]] 4.5 [[Guide:95lrm/RM-4-5|Operators and Expression Evaluation]] 4.5.1 [[Guide:95lrm/RM-4-5-1|Logical Operators and Short-circuit Control Forms]] 4.5.2 [[Guide:95lrm/RM-4-5-2|Relational Operators and Membership Tests]] 4.5.3 [[Guide:95lrm/RM-4-5-3|Binary Adding Operators]] 4.5.4 [[Guide:95lrm/RM-4-5-4|Unary Adding Operators]] 4.5.5 [[Guide:95lrm/RM-4-5-5|Multiplying Operators]] 4.5.6 [[Guide:95lrm/RM-4-5-6|Highest Precedence Operators]] 4.6 [[Guide:95lrm/RM-4-6|Type Conversions]] 4.7 [[Guide:95lrm/RM-4-7|Qualified Expressions]] 4.8 [[Guide:95lrm/RM-4-8|Allocators]] 4.9 [[Guide:95lrm/RM-4-9|Static Expressions and Static Subtypes]] 4.9.1 [[Guide:95lrm/RM-4-9-1|Statically Matching Constraints and Subtypes]] 5. [[Guide:95lrm/RM-5|Statements]] 5.1 [[Guide:95lrm/RM-5-1|Simple and Compound Statements - Sequences of Statements]] 5.2 [[Guide:95lrm/RM-5-2|Assignment Statements]] 5.3 [[Guide:95lrm/RM-5-3|If Statements]] 5.4 [[Guide:95lrm/RM-5-4|Case Statements]] 5.5 [[Guide:95lrm/RM-5-5|Loop Statements]] 5.6 [[Guide:95lrm/RM-5-6|Block Statements]] 5.7 [[Guide:95lrm/RM-5-7|Exit Statements]] 5.8 [[Guide:95lrm/RM-5-8|Goto Statements]] 6. [[Guide:95lrm/RM-6|Subprograms]] 6.1 [[Guide:95lrm/RM-6-1|Subprogram Declarations]] 6.2 [[Guide:95lrm/RM-6-2|Formal Parameter Modes]] 6.3 [[Guide:95lrm/RM-6-3|Subprogram Bodies]] 6.3.1 [[Guide:95lrm/RM-6-3-1|Conformance Rules]] 6.3.2 [[Guide:95lrm/RM-6-3-2|Inline Expansion of Subprograms]] 6.4 [[Guide:95lrm/RM-6-4|Subprogram Calls]] 6.4.1 [[Guide:95lrm/RM-6-4-1|Parameter Associations]] 6.5 [[Guide:95lrm/RM-6-5|Return Statements]] 6.6 [[Guide:95lrm/RM-6-6|Overloading of Operators]] 7. [[Guide:95lrm/RM-7|Packages]] 7.1 [[Guide:95lrm/RM-7-1|Package Specifications and Declarations]] 7.2 [[Guide:95lrm/RM-7-2|Package Bodies]] 7.3 [[Guide:95lrm/RM-7-3|Private Types and Private Extensions]] 7.3.1 [[Guide:95lrm/RM-7-3-1|Private Operations]] 7.4 [[Guide:95lrm/RM-7-4|Deferred Constants]] 7.5 [[Guide:95lrm/RM-7-5|Limited Types]] 7.6 [[Guide:95lrm/RM-7-6|User-Defined Assignment and Finalization]] 7.6.1 [[Guide:95lrm/RM-7-6-1|Completion and Finalization]] 8. [[Guide:95lrm/RM-8|Visibility Rules]] 8.1 [[Guide:95lrm/RM-8-1|Declarative Region]] 8.2 [[Guide:95lrm/RM-8-2|Scope of Declarations]] 8.3 [[Guide:95lrm/RM-8-3|Visibility]] 8.4 [[Guide:95lrm/RM-8-4|Use Clauses]] 8.5 [[Guide:95lrm/RM-8-5|Renaming Declarations]] 8.5.1 [[Guide:95lrm/RM-8-5-1|Object Renaming Declarations]] 8.5.2 [[Guide:95lrm/RM-8-5-2|Exception Renaming Declarations]] 8.5.3 [[Guide:95lrm/RM-8-5-3|Package Renaming Declarations]] 8.5.4 [[Guide:95lrm/RM-8-5-4|Subprogram Renaming Declarations]] 8.5.5 [[Guide:95lrm/RM-8-5-5|Generic Renaming Declarations]] 8.6 [[Guide:95lrm/RM-8-6|The Context of Overload Resolution]] 9. [[Guide:95lrm/RM-9|Tasks and Synchronization]] 9.1 [[Guide:95lrm/RM-9-1|Task Units and Task Objects]] 9.2 [[Guide:95lrm/RM-9-2|Task Execution - Task Activation]] 9.3 [[Guide:95lrm/RM-9-3|Task Dependence - Termination of Tasks]] 9.4 [[Guide:95lrm/RM-9-4|Protected Units and Protected Objects]] 9.5 [[Guide:95lrm/RM-9-5|Intertask Communication]] 9.5.1 [[Guide:95lrm/RM-9-5-1|Protected Subprograms and Protected Actions]] 9.5.2 [[Guide:95lrm/RM-9-5-2|Entries and Accept Statements]] 9.5.3 [[Guide:95lrm/RM-9-5-3|Entry Calls]] 9.5.4 [[Guide:95lrm/RM-9-5-4|Requeue Statements]] 9.6 [[Guide:95lrm/RM-9-6|Delay Statements, Duration, and Time]] 9.7 [[Guide:95lrm/RM-9-7|Select Statements]] 9.7.1 [[Guide:95lrm/RM-9-7-1|Selective Accept]] 9.7.2 [[Guide:95lrm/RM-9-7-2|Timed Entry Calls]] 9.7.3 [[Guide:95lrm/RM-9-7-3|Conditional Entry Calls]] 9.7.4 [[Guide:95lrm/RM-9-7-4|Asynchronous Transfer of Control]] 9.8 [[Guide:95lrm/RM-9-8|Abort of a Task - Abort of a Sequence of Statements]] 9.9 [[Guide:95lrm/RM-9-9|Task and Entry Attributes]] 9.10 [[Guide:95lrm/RM-9-10|Shared Variables]] 9.11 [[Guide:95lrm/RM-9-11|Example of Tasking and Synchronization]] 10. [[Guide:95lrm/RM-10|Program Structure and Compilation Issues]] 10.1 [[Guide:95lrm/RM-10-1|Separate Compilation]] 10.1.1 [[Guide:95lrm/RM-10-1-1|Compilation Units - Library Units]] 10.1.2 [[Guide:95lrm/RM-10-1-2|Context Clauses - With Clauses]] 10.1.3 [[Guide:95lrm/RM-10-1-3|Subunits of Compilation Units]] 10.1.4 [[Guide:95lrm/RM-10-1-4|The Compilation Process]] 10.1.5 [[Guide:95lrm/RM-10-1-5|Pragmas and Program Units]] 10.1.6 [[Guide:95lrm/RM-10-1-6|Environment-Level Visibility Rules]] 10.2 [[Guide:95lrm/RM-10-2|Program Execution]] 10.2.1 [[Guide:95lrm/RM-10-2-1|Elaboration Control]] 11. [[Guide:95lrm/RM-11|Exceptions]] 11.1 [[Guide:95lrm/RM-11-1|Exception Declarations]] 11.2 [[Guide:95lrm/RM-11-2|Exception Handlers]] 11.3 [[Guide:95lrm/RM-11-3|Raise Statements]] 11.4 [[Guide:95lrm/RM-11-4|Exception Handling]] 11.4.1 [[Guide:95lrm/RM-11-4-1|The Package Exceptions]] 11.4.2 [[Guide:95lrm/RM-11-4-2|Example of Exception Handling]] 11.5 [[Guide:95lrm/RM-11-5|Suppressing Checks]] 11.6 [[Guide:95lrm/RM-11-6|Exceptions and Optimization]] 12. [[Guide:95lrm/RM-12|Generic Units]] 12.1 [[Guide:95lrm/RM-12-1|Generic Declarations]] 12.2 [[Guide:95lrm/RM-12-2|Generic Bodies]] 12.3 [[Guide:95lrm/RM-12-3|Generic Instantiation]] 12.4 [[Guide:95lrm/RM-12-4|Formal Objects]] 12.5 [[Guide:95lrm/RM-12-5|Formal Types]] 12.5.1 [[Guide:95lrm/RM-12-5-1|Formal Private and Derived Types]] 12.5.2 [[Guide:95lrm/RM-12-5-2|Formal Scalar Types]] 12.5.3 [[Guide:95lrm/RM-12-5-3|Formal Array Types]] 12.5.4 [[Guide:95lrm/RM-12-5-4|Formal Access Types]] 12.6 [[Guide:95lrm/RM-12-6|Formal Subprograms]] 12.7 [[Guide:95lrm/RM-12-7|Formal Packages]] 12.8 [[Guide:95lrm/RM-12-8|Example of a Generic Package]] 13. [[Guide:95lrm/RM-13|Representation Issues]] 13.1 [[Guide:95lrm/RM-13-1|Operational and Representation Items]] 13.2 [[Guide:95lrm/RM-13-2|Pragma Pack]] 13.3 [[Guide:95lrm/RM-13-3|Operational and Representation Attributes]] 13.4 [[Guide:95lrm/RM-13-4|Enumeration Representation Clauses]] 13.5 [[Guide:95lrm/RM-13-5|Record Layout]] 13.5.1 [[Guide:95lrm/RM-13-5-1|Record Representation Clauses]] 13.5.2 [[Guide:95lrm/RM-13-5-2|Storage Place Attributes]] 13.5.3 [[Guide:95lrm/RM-13-5-3|Bit Ordering]] 13.6 [[Guide:95lrm/RM-13-6|Change of Representation]] 13.7 [[Guide:95lrm/RM-13-7|The Package System]] 13.7.1 [[Guide:95lrm/RM-13-7-1|The Package System.Storage_Elements]] 13.7.2 [[Guide:95lrm/RM-13-7-2|The Package System.Address_To_Access_Conversions]] 13.8 [[Guide:95lrm/RM-13-8|Machine Code Insertions]] 13.9 [[Guide:95lrm/RM-13-9|Unchecked Type Conversions]] 13.9.1 [[Guide:95lrm/RM-13-9-1|Data Validity]] 13.9.2 [[Guide:95lrm/RM-13-9-2|The Valid Attribute]] 13.10 [[Guide:95lrm/RM-13-10|Unchecked Access Value Creation]] 13.11 [[Guide:95lrm/RM-13-11|Storage Management]] 13.11.1 [[Guide:95lrm/RM-13-11-1|The Max_Size_In_Storage_Elements Attribute]] 13.11.2 [[Guide:95lrm/RM-13-11-2|Unchecked Storage Deallocation]] 13.11.3 [[Guide:95lrm/RM-13-11-3|Pragma Controlled]] 13.12 [[Guide:95lrm/RM-13-12|Pragma Restrictions]] 13.13 [[Guide:95lrm/RM-13-13|Streams]] 13.13.1 [[Guide:95lrm/RM-13-13-1|The Package Streams]] 13.13.2 [[Guide:95lrm/RM-13-13-2|Stream-Oriented Attributes]] 13.14 [[Guide:95lrm/RM-13-14|Freezing Rules]] [[Guide:95lrm/RM-0-28|The Standard Libraries]] A. [[Guide:95lrm/RM-A|Predefined Language Environment]] A.1 [[Guide:95lrm/RM-A-1|The Package Standard]] A.2 [[Guide:95lrm/RM-A-2|The Package Ada]] A.3 [[Guide:95lrm/RM-A-3|Character Handling]] A.3.1 [[Guide:95lrm/RM-A-3-1|The Package Characters]] A.3.2 [[Guide:95lrm/RM-A-3-2|The Package Characters.Handling]] A.3.3 [[Guide:95lrm/RM-A-3-3|The Package Characters.Latin_1]] A.4 [[Guide:95lrm/RM-A-4|String Handling]] A.4.1 [[Guide:95lrm/RM-A-4-1|The Package Strings]] A.4.2 [[Guide:95lrm/RM-A-4-2|The Package Strings.Maps]] A.4.3 [[Guide:95lrm/RM-A-4-3|Fixed-Length String Handling]] A.4.4 [[Guide:95lrm/RM-A-4-4|Bounded-Length String Handling]] A.4.5 [[Guide:95lrm/RM-A-4-5|Unbounded-Length String Handling]] A.4.6 [[Guide:95lrm/RM-A-4-6|String-Handling Sets and Mappings]] A.4.7 [[Guide:95lrm/RM-A-4-7|Wide_String Handling]] A.5 [[Guide:95lrm/RM-A-5|The Numerics Packages]] A.5.1 [[Guide:95lrm/RM-A-5-1|Elementary Functions]] A.5.2 [[Guide:95lrm/RM-A-5-2|Random Number Generation]] A.5.3 [[Guide:95lrm/RM-A-5-3|Attributes of Floating Point Types]] A.5.4 [[Guide:95lrm/RM-A-5-4|Attributes of Fixed Point Types]] A.6 [[Guide:95lrm/RM-A-6|Input-Output]] A.7 [[Guide:95lrm/RM-A-7|External Files and File Objects]] A.8 [[Guide:95lrm/RM-A-8|Sequential and Direct Files]] A.8.1 [[Guide:95lrm/RM-A-8-1|The Generic Package Sequential_IO]] A.8.2 [[Guide:95lrm/RM-A-8-2|File Management]] A.8.3 [[Guide:95lrm/RM-A-8-3|Sequential Input-Output Operations]] A.8.4 [[Guide:95lrm/RM-A-8-4|The Generic Package Direct_IO]] A.8.5 [[Guide:95lrm/RM-A-8-5|Direct Input-Output Operations]] A.9 [[Guide:95lrm/RM-A-9|The Generic Package Storage_IO]] A.10 [[Guide:95lrm/RM-A-10|Text Input-Output]] A.10.1 [[Guide:95lrm/RM-A-10-1|The Package Text_IO]] A.10.2 [[Guide:95lrm/RM-A-10-2|Text File Management]] A.10.3 [[Guide:95lrm/RM-A-10-3|Default Input, Output, and Error Files]] A.10.4 [[Guide:95lrm/RM-A-10-4|Specification of Line and Page Lengths]] A.10.5 [[Guide:95lrm/RM-A-10-5|Operations on Columns, Lines, and Pages]] A.10.6 [[Guide:95lrm/RM-A-10-6|Get and Put Procedures]] A.10.7 [[Guide:95lrm/RM-A-10-7|Input-Output of Characters and Strings]] A.10.8 [[Guide:95lrm/RM-A-10-8|Input-Output for Integer Types]] A.10.9 [[Guide:95lrm/RM-A-10-9|Input-Output for Real Types]] A.10.10 [[Guide:95lrm/RM-A-10-10|Input-Output for Enumeration Types]] A.11 [[Guide:95lrm/RM-A-11|Wide Text Input-Output]] A.12 [[Guide:95lrm/RM-A-12|Stream Input-Output]] A.12.1 [[Guide:95lrm/RM-A-12-1|The Package Streams.Stream_IO]] A.12.2 [[Guide:95lrm/RM-A-12-2|The Package Text_IO.Text_Streams]] A.12.3 [[Guide:95lrm/RM-A-12-3|The Package Wide_Text_IO.Text_Streams]] A.13 [[Guide:95lrm/RM-A-13|Exceptions in Input-Output]] A.14 [[Guide:95lrm/RM-A-14|File Sharing]] A.15 [[Guide:95lrm/RM-A-15|The Package Command_Line]] B. [[Guide:95lrm/RM-B|Interface to Other Languages]] B.1 [[Guide:95lrm/RM-B-1|Interfacing Pragmas]] B.2 [[Guide:95lrm/RM-B-2|The Package Interfaces]] B.3 [[Guide:95lrm/RM-B-3|Interfacing with C]] B.3.1 [[Guide:95lrm/RM-B-3-1|The Package Interfaces.C.Strings]] B.3.2 [[Guide:95lrm/RM-B-3-2|The Generic Package Interfaces.C.Pointers]] B.4 [[Guide:95lrm/RM-B-4|Interfacing with COBOL]] B.5 [[Guide:95lrm/RM-B-5|Interfacing with Fortran]] C. [[Guide:95lrm/RM-C|Systems Programming]] C.1 [[Guide:95lrm/RM-C-1|Access to Machine Operations]] C.2 [[Guide:95lrm/RM-C-2|Required Representation Support]] C.3 [[Guide:95lrm/RM-C-3|Interrupt Support]] C.3.1 [[Guide:95lrm/RM-C-3-1|Protected Procedure Handlers]] C.3.2 [[Guide:95lrm/RM-C-3-2|The Package Interrupts]] C.4 [[Guide:95lrm/RM-C-4|Preelaboration Requirements]] C.5 [[Guide:95lrm/RM-C-5|Pragma Discard_Names]] C.6 [[Guide:95lrm/RM-C-6|Shared Variable Control]] C.7 [[Guide:95lrm/RM-C-7|Task Identification and Attributes]] C.7.1 [[Guide:95lrm/RM-C-7-1|The Package Task_Identification]] C.7.2 [[Guide:95lrm/RM-C-7-2|The Package Task_Attributes]] D. [[Guide:95lrm/RM-D|Real-Time Systems]] D.1 [[Guide:95lrm/RM-D-1|Task Priorities]] D.2 [[Guide:95lrm/RM-D-2|Priority Scheduling]] D.2.1 [[Guide:95lrm/RM-D-2-1|The Task Dispatching Model]] D.2.2 [[Guide:95lrm/RM-D-2-2|The Standard Task Dispatching Policy]] D.3 [[Guide:95lrm/RM-D-3|Priority Ceiling Locking]] D.4 [[Guide:95lrm/RM-D-4|Entry Queuing Policies]] D.5 [[Guide:95lrm/RM-D-5|Dynamic Priorities]] D.6 [[Guide:95lrm/RM-D-6|Preemptive Abort]] D.7 [[Guide:95lrm/RM-D-7|Tasking Restrictions]] D.8 [[Guide:95lrm/RM-D-8|Monotonic Time]] D.9 [[Guide:95lrm/RM-D-9|Delay Accuracy]] D.10 [[Guide:95lrm/RM-D-10|Synchronous Task Control]] D.11 [[Guide:95lrm/RM-D-11|Asynchronous Task Control]] D.12 [[Guide:95lrm/RM-D-12|Other Optimizations and Determinism Rules]] E. [[Guide:95lrm/RM-E|Distributed Systems]] E.1 [[Guide:95lrm/RM-E-1|Partitions]] E.2 [[Guide:95lrm/RM-E-2|Categorization of Library Units]] E.2.1 [[Guide:95lrm/RM-E-2-1|Shared Passive Library Units]] E.2.2 [[Guide:95lrm/RM-E-2-2|Remote Types Library Units]] E.2.3 [[Guide:95lrm/RM-E-2-3|Remote Call Interface Library Units]] E.3 [[Guide:95lrm/RM-E-3|Consistency of a Distributed System]] E.4 [[Guide:95lrm/RM-E-4|Remote Subprogram Calls]] E.4.1 [[Guide:95lrm/RM-E-4-1|Pragma Asynchronous]] E.4.2 [[Guide:95lrm/RM-E-4-2|Example of Use of a Remote Access-to-Class-Wide Type]] E.5 [[Guide:95lrm/RM-E-5|Partition Communication Subsystem]] F. [[Guide:95lrm/RM-F|Information Systems]] F.1 [[Guide:95lrm/RM-F-1|Machine_Radix Attribute Definition Clause]] F.2 [[Guide:95lrm/RM-F-2|The Package Decimal]] F.3 [[Guide:95lrm/RM-F-3|Edited Output for Decimal Types]] F.3.1 [[Guide:95lrm/RM-F-3-1|Picture String Formation]] F.3.2 [[Guide:95lrm/RM-F-3-2|Edited Output Generation]] F.3.3 [[Guide:95lrm/RM-F-3-3|The Package Text_IO.Editing]] F.3.4 [[Guide:95lrm/RM-F-3-4|The Package Wide_Text_IO.Editing]] G. [[Guide:95lrm/RM-G|Numerics]] G.1 [[Guide:95lrm/RM-G-1|Complex Arithmetic]] G.1.1 [[Guide:95lrm/RM-G-1-1|Complex Types]] G.1.2 [[Guide:95lrm/RM-G-1-2|Complex Elementary Functions]] G.1.3 [[Guide:95lrm/RM-G-1-3|Complex Input-Output]] G.1.4 [[Guide:95lrm/RM-G-1-4|The Package Wide_Text_IO.Complex_IO]] G.2 [[Guide:95lrm/RM-G-2|Numeric Performance Requirements]] G.2.1 [[Guide:95lrm/RM-G-2-1|Model of Floating Point Arithmetic]] G.2.2 [[Guide:95lrm/RM-G-2-2|Model-Oriented Attributes of Floating Point Types]] G.2.3 [[Guide:95lrm/RM-G-2-3|Model of Fixed Point Arithmetic]] G.2.4 [[Guide:95lrm/RM-G-2-4|Accuracy Requirements for the Elementary Functions]] G.2.5 [[Guide:95lrm/RM-G-2-5|Performance Requirements for Random Number Generation]] G.2.6 [[Guide:95lrm/RM-G-2-6|Accuracy Requirements for Complex Arithmetic]] H. [[Guide:95lrm/RM-H|Safety and Security]] H.1 [[Guide:95lrm/RM-H-1|Pragma Normalize_Scalars]] H.2 [[Guide:95lrm/RM-H-2|Documentation of Implementation Decisions]] H.3 [[Guide:95lrm/RM-H-3|Reviewable Object Code]] H.3.1 [[Guide:95lrm/RM-H-3-1|Pragma Reviewable]] H.3.2 [[Guide:95lrm/RM-H-3-2|Pragma Inspection_Point]] H.4 [[Guide:95lrm/RM-H-4|Safety and Security Restrictions]] J. [[Guide:95lrm/RM-J|Obsolescent Features]] J.1 [[Guide:95lrm/RM-J-1|Renamings of Ada 83 Library Units]] J.2 [[Guide:95lrm/RM-J-2|Allowed Replacements of Characters]] J.3 [[Guide:95lrm/RM-J-3|Reduced Accuracy Subtypes]] J.4 [[Guide:95lrm/RM-J-4|The Constrained Attribute]] J.5 [[Guide:95lrm/RM-J-5|ASCII]] J.6 [[Guide:95lrm/RM-J-6|Numeric_Error]] J.7 [[Guide:95lrm/RM-J-7|At Clauses]] J.7.1 [[Guide:95lrm/RM-J-7-1|Interrupt Entries]] J.8 [[Guide:95lrm/RM-J-8|Mod Clauses]] J.9 [[Guide:95lrm/RM-J-9|The Storage_Size Attribute]] K. [[Guide:95lrm/RM-K|Language-Defined Attributes]] L. [[Guide:95lrm/RM-L|Language-Defined Pragmas]] M. [[Guide:95lrm/RM-M|Implementation-Defined Characteristics]] N. [[Guide:95lrm/RM-N|Glossary]] P. [[Guide:95lrm/RM-P|Syntax Summary]] [[Guide:95lrm/RM-0-29|Index]] </div><div class="navigator">[[Guide:95lrm/RM-TOC|Contents]] | [[Guide:95lrm/RM-0-29|Index]] | [[Guide:95lrm/RM-0-1|Next]]   [[Guide:95lrm/RM-TTL|Legal]]</div> {{95lrm}} pwsy6rtt6b3l7qreou0njspdqvgnvpi Guide:9x rationale 4200 852 3414 3410 2019-04-24T16:55:33Z WikiVisor 11 wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]]</div> <div class="jumbotron text-center"> = Ada 95 Rationale = by [[Guide:9x_rationale/rat95-author|Laurent Guerby]] </div> <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]]</div> __NOEDITSECTION__ {{DISPLAYTITLE: Guide <span class="hide">- Ada 95 Rationale</span> }} r8cpxn2gkn469ngtii7s2sebtkkcq7f Guide:9x rationale/index 4200 320 1812 1809 2019-04-20T16:18:41Z WikiVisor 11 Text replacement - "[[Guide:9x_rationale/rat95-copyright|Copyright]] | " to "<div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | " wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-preface|Previous]] | [[Guide:9x_rationale/rat95-p1-1|Next]]</div> = Contents = * [[Guide:9x_rationale/rat95-foreword|Foreword]] * [[Guide:9x_rationale/rat95-preface|Preface]] == [[Guide:9x_rationale/rat95-p1|Part One Introduction]] == * [[Guide:9x_rationale/rat95-p1-1|I Evolution of Ada 95]] ** [[Guide:9x_rationale/rat95-p1-1#1|I.1 The Revision Process]] ** [[Guide:9x_rationale/rat95-p1-1#2|I.2 The Requirements]] ** [[Guide:9x_rationale/rat95-p1-1#3|I.3 The Main User Needs]] ** [[Guide:9x_rationale/rat95-p1-1#4|I.4 The Approach]] ** [[Guide:9x_rationale/rat95-p1-1#5|I.5 Using this Document]] * [[Guide:9x_rationale/rat95-p1-2|II Highlights of Ada 95]] ** [[Guide:9x_rationale/rat95-p1-2#1|II.1 Programming by Extension]] ** [[Guide:9x_rationale/rat95-p1-2#2|II.2 Class Wide Programming]] ** [[Guide:9x_rationale/rat95-p1-2#3|II.3 Abstract Types and Subprograms]] ** [[Guide:9x_rationale/rat95-p1-2#4|II.4 Summary of Type Extension]] ** [[Guide:9x_rationale/rat95-p1-2#5|II.5 Dynamic Selection]] ** [[Guide:9x_rationale/rat95-p1-2#6|II.6 Other Access Types]] ** [[Guide:9x_rationale/rat95-p1-2#7|II.7 Hierarchical Libraries]] ** [[Guide:9x_rationale/rat95-p1-2#8|II.8 Private Child Units]] ** [[Guide:9x_rationale/rat95-p1-2#9|II.9 Protected Types]] ** [[Guide:9x_rationale/rat95-p1-2#10|II.10 Task Scheduling and Timing]] ** [[Guide:9x_rationale/rat95-p1-2#11|II.11 Generic Parameters]] ** [[Guide:9x_rationale/rat95-p1-2#12|II.12 Other Improvements]] ** [[Guide:9x_rationale/rat95-p1-2#13|II.13 The Predefined Library]] ** [[Guide:9x_rationale/rat95-p1-2#14|II.14 The Specialized Needs Annexes]] ** [[Guide:9x_rationale/rat95-p1-2#15|II.15 Conclusion]] * [[Guide:9x_rationale/rat95-p1-3|III Overview of the Ada Language]] ** [[Guide:9x_rationale/rat95-p1-3#1|III.1 Objects, Types, Classes and Operations]] ** [[Guide:9x_rationale/rat95-p1-3#2|III.2 Statements, Expressions and Elaboration]] ** [[Guide:9x_rationale/rat95-p1-3#3|III.3 System Construction]] ** [[Guide:9x_rationale/rat95-p1-3#4|III.4 Multitasking]] ** [[Guide:9x_rationale/rat95-p1-3#5|III.5 Exception Handling]] ** [[Guide:9x_rationale/rat95-p1-3#6|III.6 Low Level Programming]] ** [[Guide:9x_rationale/rat95-p1-3#7|III.7 Standard Library]] ** [[Guide:9x_rationale/rat95-p1-3#8|III.8 Application Specific Facilities]] ** [[Guide:9x_rationale/rat95-p1-3#9|III.9 Summary]] == [[Guide:9x_rationale/rat95-p2|Part Two The Core Language]] == * [[Guide:9x_rationale/rat95-p2-1|1 Introduction]] ** [[Guide:9x_rationale/rat95-p2-1#1|1.1 Overall Approach]] ** [[Guide:9x_rationale/rat95-p2-1#2|1.2 The Reference Manual]] ** [[Guide:9x_rationale/rat95-p2-1#3|1.3 Syntax]] ** [[Guide:9x_rationale/rat95-p2-1#4|1.4 Classification of Errors]] ** [[Guide:9x_rationale/rat95-p2-1#5|1.5 Requirements Summary]] * [[Guide:9x_rationale/rat95-p2-2|2 Lexical Elements]] ** [[Guide:9x_rationale/rat95-p2-2#1|2.1 Reserved Words and Identifiers]] ** [[Guide:9x_rationale/rat95-p2-2#2|2.2 Program Text]] ** [[Guide:9x_rationale/rat95-p2-2#3|2.3 Pragmas]] ** [[Guide:9x_rationale/rat95-p2-2#4|2.4 Requirements Summary]] * [[Guide:9x_rationale/rat95-p2-3|3 Types and Expressions]] ** [[Guide:9x_rationale/rat95-p2-3#1|3.1 Types, Classes, Objects and Views]] ** [[Guide:9x_rationale/rat95-p2-3#2|3.2 Character Types]] ** [[Guide:9x_rationale/rat95-p2-3#3|3.3 Numeric Types]] ** [[Guide:9x_rationale/rat95-p2-3#4|3.4 Composite Types]] ** [[Guide:9x_rationale/rat95-p2-3#5|3.5 Array Types]] ** [[Guide:9x_rationale/rat95-p2-3#6|3.6 Record Types]] ** [[Guide:9x_rationale/rat95-p2-3#7|3.7 Access Types]] ** [[Guide:9x_rationale/rat95-p2-3#8|3.8 Type Conversion]] ** [[Guide:9x_rationale/rat95-p2-3#9|3.9 Staticness]] ** [[Guide:9x_rationale/rat95-p2-3#10|3.10 Other Improvements]] ** [[Guide:9x_rationale/rat95-p2-3#11|3.11 Requirements Summary]] * [[Guide:9x_rationale/rat95-p2-4|4 Object Oriented Programming]] ** [[Guide:9x_rationale/rat95-p2-4#1|4.1 Background and Concepts]] ** [[Guide:9x_rationale/rat95-p2-4#1|4.2 General Approach]] ** [[Guide:9x_rationale/rat95-p2-4#1|4.3 Class Wide Types and Operations]] ** [[Guide:9x_rationale/rat95-p2-4#1|4.4 Examples of Use]] ** [[Guide:9x_rationale/rat95-p2-4#1|4.5 Dispatching and Redispatching]] ** [[Guide:9x_rationale/rat95-p2-4#1|4.6 Multiple Inheritance]] ** [[Guide:9x_rationale/rat95-p2-4#1|4.7 Relationship with Previous Work]] ** [[Guide:9x_rationale/rat95-p2-4#1|4.8 Requirements Summary]] * [[Guide:9x_rationale/rat95-p2-5|5 Statements]] * [[Guide:9x_rationale/rat95-p2-6|6 Subprograms]] ** [[Guide:9x_rationale/rat95-p2-6#1|6.1 Parameter and Result Mechanism]] ** [[Guide:9x_rationale/rat95-p2-6#2|6.2 Renaming of Bodies and Conformance]] ** [[Guide:9x_rationale/rat95-p2-6#3|6.3 Overloading of Equality and Inequality Operators]] ** [[Guide:9x_rationale/rat95-p2-6#4|6.4 Requirements Summary]] * [[Guide:9x_rationale/rat95-p2-7|7 Packages]] ** [[Guide:9x_rationale/rat95-p2-7#1|7.1 Private Types and Extensions]] ** [[Guide:9x_rationale/rat95-p2-7#2|7.2 Deferred Constants]] ** [[Guide:9x_rationale/rat95-p2-7#3|7.3 Limited Types]] ** [[Guide:9x_rationale/rat95-p2-7#4|7.4 Controlled Types]] ** [[Guide:9x_rationale/rat95-p2-7#5|7.5 Requirements Summary]] * [[Guide:9x_rationale/rat95-p2-8|8 Visibility Rules]] ** [[Guide:9x_rationale/rat95-p2-8#1|8.1 Scope and Visibility]] ** [[Guide:9x_rationale/rat95-p2-8#2|8.2 Use Clauses]] ** [[Guide:9x_rationale/rat95-p2-8#3|8.3 Renaming]] ** [[Guide:9x_rationale/rat95-p2-8#4|8.4 Other Improvements]] ** [[Guide:9x_rationale/rat95-p2-8#5|8.5 Requirements Summary]] * [[Guide:9x_rationale/rat95-p2-9|9 Tasking]] ** [[Guide:9x_rationale/rat95-p2-9#1|9.1 Protected Types]] ** [[Guide:9x_rationale/rat95-p2-9#2|9.2 The Requeue Statement]] ** [[Guide:9x_rationale/rat95-p2-9#3|9.3 Timing]] ** [[Guide:9x_rationale/rat95-p2-9#4|9.4 Asynchronous Transfer of Control]] ** [[Guide:9x_rationale/rat95-p2-9#5|9.5 The Abort Statement]] * [[Guide:9x_rationale/rat95-p2-10#1|10 Program Structure and Compilation Issues]] ** [[Guide:9x_rationale/rat95-p2-10#1|10.1 The Hierarchical Library]] ** [[Guide:9x_rationale/rat95-p2-10#2|10.2 Program Structure]] ** [[Guide:9x_rationale/rat95-p2-10#3|10.3 Elaboration]] ** [[Guide:9x_rationale/rat95-p2-10#4|10.4 Library Package Bodies]] ** [[Guide:9x_rationale/rat95-p2-10#5|10.5 Other Improvements]] ** [[Guide:9x_rationale/rat95-p2-10#6|10.6 Requirements Summary]] * [[Guide:9x_rationale/rat95-p2-11|11 Exceptions]] ** [[Guide:9x_rationale/rat95-p2-11#1|11.1 Numeric Error]] ** [[Guide:9x_rationale/rat95-p2-11#2|11.2 Exception Occurrences]] ** [[Guide:9x_rationale/rat95-p2-11#3|11.3 Exceptions and Optimization]] ** [[Guide:9x_rationale/rat95-p2-11#4|11.4 Other Improvements]] ** [[Guide:9x_rationale/rat95-p2-11#5|11.5 Requirements Summary]] * [[Guide:9x_rationale/rat95-p2-12|12 Generics]] ** [[Guide:9x_rationale/rat95-p2-12#1|12.1 The Contract Model]] ** [[Guide:9x_rationale/rat95-p2-12#2|12.2 Numeric Types]] ** [[Guide:9x_rationale/rat95-p2-12#3|12.3 Access Types]] ** [[Guide:9x_rationale/rat95-p2-12#4|12.4 Derived Types]] ** [[Guide:9x_rationale/rat95-p2-12#5|12.5 Tagged Types]] ** [[Guide:9x_rationale/rat95-p2-12#6|12.6 Package Parameters]] ** [[Guide:9x_rationale/rat95-p2-12#7|12.7 Other Improvements]] ** [[Guide:9x_rationale/rat95-p2-12#8|12.8 Requirements Summary]] * [[Guide:9x_rationale/rat95-p2-13#1|13 Representation Issues]] ** [[Guide:9x_rationale/rat95-p2-13#1|13.1 Representation of Data]] ** [[Guide:9x_rationale/rat95-p2-13#2|13.2 The Package System]] ** [[Guide:9x_rationale/rat95-p2-13#3|13.3 The Valid Attribute]] ** [[Guide:9x_rationale/rat95-p2-13#4|13.4 Storage Pool Management]] ** [[Guide:9x_rationale/rat95-p2-13#5|13.5 Freezing of Representations]] ** [[Guide:9x_rationale/rat95-p2-13#6|13.6 The Pragma Restrictions]] ** [[Guide:9x_rationale/rat95-p2-13#7|13.7 Requirements Summary]] == [[Guide:9x_rationale/rat95-p3|Part Three The Annexes]] == * [[Guide:9x_rationale/rat95-p3-a|A Predefined Language Environment]] ** [[Guide:9x_rationale/rat95-p3-a#1|A.1 Character Handling]] ** [[Guide:9x_rationale/rat95-p3-a#2|A.2 String Handling]] ** [[Guide:9x_rationale/rat95-p3-a#3|A.3 Numerics Packages and Attributes]] ** [[Guide:9x_rationale/rat95-p3-a#4|A.4 Input and Output]] ** [[Guide:9x_rationale/rat95-p3-a#5|A.5 Command Line]] ** [[Guide:9x_rationale/rat95-p3-a#6|A.6 Requirements Summary]] * [[Guide:9x_rationale/rat95-p3-b|B Interface to Other Languages]] ** [[Guide:9x_rationale/rat95-p3-b#1|B.1 Interfacing Pragmas]] ** [[Guide:9x_rationale/rat95-p3-b#2|B.2 C Interface Packages]] ** [[Guide:9x_rationale/rat95-p3-b#3|B.3 COBOL Interface Package]] ** [[Guide:9x_rationale/rat95-p3-b#4|B.4 Fortran Interface Package]] ** [[Guide:9x_rationale/rat95-p3-b#5|B.5 Requirements Summary]] * [[Guide:9x_rationale/rat95-p3-c|C Systems Programming]] ** [[Guide:9x_rationale/rat95-p3-c#1|C.1 Access to Machine Operations]] ** [[Guide:9x_rationale/rat95-p3-c#2|C.2 Required Representation Support]] ** [[Guide:9x_rationale/rat95-p3-c#3|C.3 Interrupt Support]] ** [[Guide:9x_rationale/rat95-p3-c#4|C.4 Preelaboration Requirements]] ** [[Guide:9x_rationale/rat95-p3-c#5|C.5 Shared Variable Control]] ** [[Guide:9x_rationale/rat95-p3-c#6|C.6 Task Identification and Attributes]] ** [[Guide:9x_rationale/rat95-p3-c#7|C.7 Requirements Summary]] * [[Guide:9x_rationale/rat95-p3-d|D Real-Time Systems]] ** [[Guide:9x_rationale/rat95-p3-d#1|D.1 Task Priorities]] ** [[Guide:9x_rationale/rat95-p3-d#2|D.2 Priority Scheduling]] ** [[Guide:9x_rationale/rat95-p3-d#3|D.3 Priority Ceiling Locking]] ** [[Guide:9x_rationale/rat95-p3-d#4|D.4 Entry Queuing Policies]] ** [[Guide:9x_rationale/rat95-p3-d#5|D.5 Dynamic Priorities]] ** [[Guide:9x_rationale/rat95-p3-d#6|D.6 Preemptive Abort]] ** [[Guide:9x_rationale/rat95-p3-d#7|D.7 Tasking Restrictions]] ** [[Guide:9x_rationale/rat95-p3-d#8|D.8 Monotonic Time]] ** [[Guide:9x_rationale/rat95-p3-d#9|D.9 Delay Accuracy]] ** [[Guide:9x_rationale/rat95-p3-d#10|D.10 Synchronous Task Control]] ** [[Guide:9x_rationale/rat95-p3-d#11|D.11 Asynchronous Task Control]] ** [[Guide:9x_rationale/rat95-p3-d#12|D.12 Special Optimization and Determinism Rules]] ** [[Guide:9x_rationale/rat95-p3-d#13|D.13 Requirements Summary]] * [[Guide:9x_rationale/rat95-p3-e|E Distributed Systems]] ** [[Guide:9x_rationale/rat95-p3-e#1|E.1 The Partition Model]] ** [[Guide:9x_rationale/rat95-p3-e#2|E.2 Categorization of Library Packages]] ** [[Guide:9x_rationale/rat95-p3-e#3|E.3 Consistency of a Distributed System]] ** [[Guide:9x_rationale/rat95-p3-e#4|E.4 Remote Subprogram Calls]] ** [[Guide:9x_rationale/rat95-p3-e#5|E.5 Post-Compilation Partitioning]] ** [[Guide:9x_rationale/rat95-p3-e#6|E.6 Configuring a Distributed System]] ** [[Guide:9x_rationale/rat95-p3-e#7|E.7 Partition Communication Subsystem]] ** [[Guide:9x_rationale/rat95-p3-e#8|E.8 Requirements Summary]] * [[Guide:9x_rationale/rat95-p3-f|F Information Systems]] ** [[Guide:9x_rationale/rat95-p3-f#1|F.1 Decimal Computation]] ** [[Guide:9x_rationale/rat95-p3-f#2|F.2 Edited Output]] ** [[Guide:9x_rationale/rat95-p3-f#3|F.3 Requirements Summary]] * [[Guide:9x_rationale/rat95-p3-g|G Numerics]] ** [[Guide:9x_rationale/rat95-p3-g#1|G.1 Complex Arithmetic]] ** [[Guide:9x_rationale/rat95-p3-g#2|G.2 Floating Point Machine Numbers]] ** [[Guide:9x_rationale/rat95-p3-g#3|G.3 Assignments to Variables of Unconstrained Numeric Types]] ** [[Guide:9x_rationale/rat95-p3-g#4|G.4 Accuracy and Other Performance Issues]] ** [[Guide:9x_rationale/rat95-p3-g#5|G.5 Requirements Summary]] * [[Guide:9x_rationale/rat95-p3-h|H Safety and Security]] ** [[Guide:9x_rationale/rat95-p3-h#1|H.1 Understanding Program Execution]] ** [[Guide:9x_rationale/rat95-p3-h#2|H.2 Reviewable Object Code]] ** [[Guide:9x_rationale/rat95-p3-h#3|H.3 Safety and Security Restrictions]] ** [[Guide:9x_rationale/rat95-p3-h#4|H.4 Validation against the Annex]] ** [[Guide:9x_rationale/rat95-p3-h#5|H.5 Issues outside the Scope of the Standard]] ** [[Guide:9x_rationale/rat95-p3-h#6|H.6 Requirements Summary]] == [[Guide:9x_rationale/rat95-p4|Part Four Appendices]] == * [[Guide:9x_rationale/rat95-p4-x|Appendix X Upward Compatibility]] ** [[Guide:9x_rationale/rat95-p4-x#1|X.1 Reserved Words]] ** [[Guide:9x_rationale/rat95-p4-x#2|X.2 Type Character]] ** [[Guide:9x_rationale/rat95-p4-x#3|X.3 Library Package Bodies]] ** [[Guide:9x_rationale/rat95-p4-x#4|X.4 Indefinite Generic Parameters]] ** [[Guide:9x_rationale/rat95-p4-x#5|X.5 Numeric Error]] ** [[Guide:9x_rationale/rat95-p4-x#6|X.6 Other Incompatibilities]] ** [[Guide:9x_rationale/rat95-p4-x#7|X.7 Conclusion]] * [[Guide:9x_rationale/rat95-p4-y#1|Appendix Y Revisions to Drafts]] ** [[Guide:9x_rationale/rat95-p4-y#1|Y.1 Core Language]] ** [[Guide:9x_rationale/rat95-p4-y#2|Y.2 Predefined Environment]] ** [[Guide:9x_rationale/rat95-p4-y#3|Y.3 Specialized Needs Annexes]] * [[Guide:9x_rationale/rat95-p4-z|Appendix Z Requirements]] ** [[Guide:9x_rationale/rat95-p4-z#1|Z.1 Analysis]] ** [[Guide:9x_rationale/rat95-p4-z#2|Z.2 Conclusion]] * [[Guide:9x_rationale/rat95-references|References]] * [[Guide:9x_rationale/rat95-index|Index]] <p><div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-preface|Previous]] | [[Guide:9x_rationale/rat95-p1-1|Next]]</div></p> <p>[[Guide:9x_rationale/rat95-author|Laurent Guerby]]</p></li></ul> {{9x_rationale|Displaytitle=Table of Contents}} kwnnrgrtrtfxks8znvj4adf7hov9fni Guide:9x rationale/rat95-author 4200 321 1851 1820 2019-04-20T16:19:47Z WikiVisor 11 Text replacement - "[[Guide:9x_rationale/rat95-copyright|Copyright]] | " to "<div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | " wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-index|Previous]] | [[Guide:9x_rationale/rat95-foreword|Next]]</div> I'm a 2d year student at Telecom Bretagne, a french "Grande Ecole". I will ;-) graduate in 1996. My favourite programming language is of course Ada 95 (and my favourite compiler is GNAT) but I don't forget other ones (C, C++, Eiffel, Lisp, SmallTalk ...). I play handball with the school's team (goalkeeper). I'm president of the boardgame (and wargame) club and I play RPG too. And I always respond to e-mails ... ;E-Mail :[mailto:guerby@enstb.enst-bretagne.fr guerby -at- enstb.enst-bretagne.fr] ;Address at school :Laurent Guerby :Telecom Bretagne :29285 BREST (FRANCE) ;Address at home :Laurent Guerby :09140 OUST (FRANCE) <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-index|Previous]] | [[Guide:9x_rationale/rat95-foreword|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=Author}} tvrkjsyv3fndf15tbqzyawthbjte5nq Guide:9x rationale/rat95-contents 4200 322 3412 1886 2019-04-24T16:50:13Z WikiVisor 11 wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale|Previous]] | [[Guide:9x_rationale/rat95-foreword|Next]]</div> == [[Guide:9x_rationale/rat95-foreword|Foreword]] == == [[Guide:9x_rationale/rat95-preface|Preface]] == == [[Guide:9x_rationale/rat95-p1|Part One Introduction]] == ==== [[Guide:9x_rationale/rat95-p1-1|I Evolution of Ada 95]] ==== :: [[Guide:9x_rationale/rat95-p1-1#1|I.1 The Revision Process]] :: [[Guide:9x_rationale/rat95-p1-1#2|I.2 The Requirements]] :: [[Guide:9x_rationale/rat95-p1-1#3|I.3 The Main User Needs]] :: [[Guide:9x_rationale/rat95-p1-1#4|I.4 The Approach]] :: [[Guide:9x_rationale/rat95-p1-1#5|I.5 Using this Document]] ==== [[Guide:9x_rationale/rat95-p1-2|II Highlights of Ada 95]] ==== :: [[Guide:9x_rationale/rat95-p1-2#1|II.1 Programming by Extension]] :: [[Guide:9x_rationale/rat95-p1-2#2|II.2 Class Wide Programming]] :: [[Guide:9x_rationale/rat95-p1-2#3|II.3 Abstract Types and Subprograms]] :: [[Guide:9x_rationale/rat95-p1-2#4|II.4 Summary of Type Extension]] :: [[Guide:9x_rationale/rat95-p1-2#5|II.5 Dynamic Selection]] :: [[Guide:9x_rationale/rat95-p1-2#6|II.6 Other Access Types]] :: [[Guide:9x_rationale/rat95-p1-2#7|II.7 Hierarchical Libraries]] :: [[Guide:9x_rationale/rat95-p1-2#8|II.8 Private Child Units]] :: [[Guide:9x_rationale/rat95-p1-2#9|II.9 Protected Types]] :: [[Guide:9x_rationale/rat95-p1-2#10|II.10 Task Scheduling and Timing]] :: [[Guide:9x_rationale/rat95-p1-2#11|II.11 Generic Parameters]] :: [[Guide:9x_rationale/rat95-p1-2#12|II.12 Other Improvements]] :: [[Guide:9x_rationale/rat95-p1-2#13|II.13 The Predefined Library]] :: [[Guide:9x_rationale/rat95-p1-2#14|II.14 The Specialized Needs Annexes]] :: [[Guide:9x_rationale/rat95-p1-2#15|II.15 Conclusion]] ==== [[Guide:9x_rationale/rat95-p1-3|III Overview of the Ada Language]] ==== :: [[Guide:9x_rationale/rat95-p1-3#1|III.1 Objects, Types, Classes and Operations]] :: [[Guide:9x_rationale/rat95-p1-3#2|III.2 Statements, Expressions and Elaboration]] :: [[Guide:9x_rationale/rat95-p1-3#3|III.3 System Construction]] :: [[Guide:9x_rationale/rat95-p1-3#4|III.4 Multitasking]] :: [[Guide:9x_rationale/rat95-p1-3#5|III.5 Exception Handling]] :: [[Guide:9x_rationale/rat95-p1-3#6|III.6 Low Level Programming]] :: [[Guide:9x_rationale/rat95-p1-3#7|III.7 Standard Library]] :: [[Guide:9x_rationale/rat95-p1-3#8|III.8 Application Specific Facilities]] :: [[Guide:9x_rationale/rat95-p1-3#9|III.9 Summary]] == [[Guide:9x_rationale/rat95-p2|Part Two The Core Language]] == ==== [[Guide:9x_rationale/rat95-p2-1|1 Introduction]] ==== :: [[Guide:9x_rationale/rat95-p2-1#1|1.1 Overall Approach]] :: [[Guide:9x_rationale/rat95-p2-1#2|1.2 The Reference Manual]] :: [[Guide:9x_rationale/rat95-p2-1#3|1.3 Syntax]] :: [[Guide:9x_rationale/rat95-p2-1#4|1.4 Classification of Errors]] :: [[Guide:9x_rationale/rat95-p2-1#5|1.5 Requirements Summary]] ==== [[Guide:9x_rationale/rat95-p2-2|2 Lexical Elements]] ==== :: [[Guide:9x_rationale/rat95-p2-2#1|2.1 Reserved Words and Identifiers]] :: [[Guide:9x_rationale/rat95-p2-2#2|2.2 Program Text]] :: [[Guide:9x_rationale/rat95-p2-2#3|2.3 Pragmas]] :: [[Guide:9x_rationale/rat95-p2-2#4|2.4 Requirements Summary]] ==== [[Guide:9x_rationale/rat95-p2-3|3 Types and Expressions]] ==== :: [[Guide:9x_rationale/rat95-p2-3#1|3.1 Types, Classes, Objects and Views]] :: [[Guide:9x_rationale/rat95-p2-3#2|3.2 Character Types]] :: [[Guide:9x_rationale/rat95-p2-3#3|3.3 Numeric Types]] :: [[Guide:9x_rationale/rat95-p2-3#4|3.4 Composite Types]] :: [[Guide:9x_rationale/rat95-p2-3#5|3.5 Array Types]] :: [[Guide:9x_rationale/rat95-p2-3#6|3.6 Record Types]] :: [[Guide:9x_rationale/rat95-p2-3#7|3.7 Access Types]] :: [[Guide:9x_rationale/rat95-p2-3#8|3.8 Type Conversion]] :: [[Guide:9x_rationale/rat95-p2-3#9|3.9 Staticness]] :: [[Guide:9x_rationale/rat95-p2-3#10|3.10 Other Improvements]] :: [[Guide:9x_rationale/rat95-p2-3#11|3.11 Requirements Summary]] ==== [[Guide:9x_rationale/rat95-p2-4|4 Object Oriented Programming]] ==== :: [[Guide:9x_rationale/rat95-p2-4#1|4.1 Background and Concepts]] :: [[Guide:9x_rationale/rat95-p2-4#1|4.2 General Approach]] :: [[Guide:9x_rationale/rat95-p2-4#1|4.3 Class Wide Types and Operations]] :: [[Guide:9x_rationale/rat95-p2-4#1|4.4 Examples of Use]] :: [[Guide:9x_rationale/rat95-p2-4#1|4.5 Dispatching and Redispatching]] :: [[Guide:9x_rationale/rat95-p2-4#1|4.6 Multiple Inheritance]] :: [[Guide:9x_rationale/rat95-p2-4#1|4.7 Relationship with Previous Work]] :: [[Guide:9x_rationale/rat95-p2-4#1|4.8 Requirements Summary]] ==== [[Guide:9x_rationale/rat95-p2-5|5 Statements]] ==== ==== [[Guide:9x_rationale/rat95-p2-6|6 Subprograms]] ==== :: [[Guide:9x_rationale/rat95-p2-6#1|6.1 Parameter and Result Mechanism]] :: [[Guide:9x_rationale/rat95-p2-6#2|6.2 Renaming of Bodies and Conformance]] :: [[Guide:9x_rationale/rat95-p2-6#3|6.3 Overloading of Equality and Inequality Operators]] :: [[Guide:9x_rationale/rat95-p2-6#4|6.4 Requirements Summary]] ==== [[Guide:9x_rationale/rat95-p2-7|7 Packages]] ==== :: [[Guide:9x_rationale/rat95-p2-7#1|7.1 Private Types and Extensions]] :: [[Guide:9x_rationale/rat95-p2-7#2|7.2 Deferred Constants]] :: [[Guide:9x_rationale/rat95-p2-7#3|7.3 Limited Types]] :: [[Guide:9x_rationale/rat95-p2-7#4|7.4 Controlled Types]] :: [[Guide:9x_rationale/rat95-p2-7#5|7.5 Requirements Summary]] ==== [[Guide:9x_rationale/rat95-p2-8|8 Visibility Rules]] ==== :: [[Guide:9x_rationale/rat95-p2-8#1|8.1 Scope and Visibility]] :: [[Guide:9x_rationale/rat95-p2-8#2|8.2 Use Clauses]] :: [[Guide:9x_rationale/rat95-p2-8#3|8.3 Renaming]] :: [[Guide:9x_rationale/rat95-p2-8#4|8.4 Other Improvements]] :: [[Guide:9x_rationale/rat95-p2-8#5|8.5 Requirements Summary]] ==== [[Guide:9x_rationale/rat95-p2-9|9 Tasking]] ==== :: [[Guide:9x_rationale/rat95-p2-9#1|9.1 Protected Types]] :: [[Guide:9x_rationale/rat95-p2-9#2|9.2 The Requeue Statement]] :: [[Guide:9x_rationale/rat95-p2-9#3|9.3 Timing]] :: [[Guide:9x_rationale/rat95-p2-9#4|9.4 Asynchronous Transfer of Control]] :: [[Guide:9x_rationale/rat95-p2-9#5|9.5 The Abort Statement]] ==== [[Guide:9x_rationale/rat95-p2-10#1|10 Program Structure and Compilation Issues]] ==== :: [[Guide:9x_rationale/rat95-p2-10#1|10.1 The Hierarchical Library]] :: [[Guide:9x_rationale/rat95-p2-10#2|10.2 Program Structure]] :: [[Guide:9x_rationale/rat95-p2-10#3|10.3 Elaboration]] :: [[Guide:9x_rationale/rat95-p2-10#4|10.4 Library Package Bodies]] :: [[Guide:9x_rationale/rat95-p2-10#5|10.5 Other Improvements]] :: [[Guide:9x_rationale/rat95-p2-10#6|10.6 Requirements Summary]] ==== [[Guide:9x_rationale/rat95-p2-11|11 Exceptions]] ==== :: [[Guide:9x_rationale/rat95-p2-11#1|11.1 Numeric Error]] :: [[Guide:9x_rationale/rat95-p2-11#2|11.2 Exception Occurrences]] :: [[Guide:9x_rationale/rat95-p2-11#3|11.3 Exceptions and Optimization]] :: [[Guide:9x_rationale/rat95-p2-11#4|11.4 Other Improvements]] :: [[Guide:9x_rationale/rat95-p2-11#5|11.5 Requirements Summary]] ==== [[Guide:9x_rationale/rat95-p2-12|12 Generics]] ==== :: [[Guide:9x_rationale/rat95-p2-12#1|12.1 The Contract Model]] :: [[Guide:9x_rationale/rat95-p2-12#2|12.2 Numeric Types]] :: [[Guide:9x_rationale/rat95-p2-12#3|12.3 Access Types]] :: [[Guide:9x_rationale/rat95-p2-12#4|12.4 Derived Types]] :: [[Guide:9x_rationale/rat95-p2-12#5|12.5 Tagged Types]] :: [[Guide:9x_rationale/rat95-p2-12#6|12.6 Package Parameters]] :: [[Guide:9x_rationale/rat95-p2-12#7|12.7 Other Improvements]] :: [[Guide:9x_rationale/rat95-p2-12#8|12.8 Requirements Summary]] ==== [[Guide:9x_rationale/rat95-p2-13#1|13 Representation Issues]] ==== :: [[Guide:9x_rationale/rat95-p2-13#1|13.1 Representation of Data]] :: [[Guide:9x_rationale/rat95-p2-13#2|13.2 The Package System]] :: [[Guide:9x_rationale/rat95-p2-13#3|13.3 The Valid Attribute]] :: [[Guide:9x_rationale/rat95-p2-13#4|13.4 Storage Pool Management]] :: [[Guide:9x_rationale/rat95-p2-13#5|13.5 Freezing of Representations]] :: [[Guide:9x_rationale/rat95-p2-13#6|13.6 The Pragma Restrictions]] :: [[Guide:9x_rationale/rat95-p2-13#7|13.7 Requirements Summary]] == [[Guide:9x_rationale/rat95-p3|Part Three The Annexes]] == ==== [[Guide:9x_rationale/rat95-p3-a|A Predefined Language Environment]] ==== :: [[Guide:9x_rationale/rat95-p3-a#1|A.1 Character Handling]] :: [[Guide:9x_rationale/rat95-p3-a#2|A.2 String Handling]] :: [[Guide:9x_rationale/rat95-p3-a#3|A.3 Numerics Packages and Attributes]] :: [[Guide:9x_rationale/rat95-p3-a#4|A.4 Input and Output]] :: [[Guide:9x_rationale/rat95-p3-a#5|A.5 Command Line]] :: [[Guide:9x_rationale/rat95-p3-a#6|A.6 Requirements Summary]] ==== [[Guide:9x_rationale/rat95-p3-b|B Interface to Other Languages]] ==== :: [[Guide:9x_rationale/rat95-p3-b#1|B.1 Interfacing Pragmas]] :: [[Guide:9x_rationale/rat95-p3-b#2|B.2 C Interface Packages]] :: [[Guide:9x_rationale/rat95-p3-b#3|B.3 COBOL Interface Package]] :: [[Guide:9x_rationale/rat95-p3-b#4|B.4 Fortran Interface Package]] :: [[Guide:9x_rationale/rat95-p3-b#5|B.5 Requirements Summary]] ==== [[Guide:9x_rationale/rat95-p3-c|C Systems Programming]] ==== :: [[Guide:9x_rationale/rat95-p3-c#1|C.1 Access to Machine Operations]] :: [[Guide:9x_rationale/rat95-p3-c#2|C.2 Required Representation Support]] :: [[Guide:9x_rationale/rat95-p3-c#3|C.3 Interrupt Support]] :: [[Guide:9x_rationale/rat95-p3-c#4|C.4 Preelaboration Requirements]] :: [[Guide:9x_rationale/rat95-p3-c#5|C.5 Shared Variable Control]] :: [[Guide:9x_rationale/rat95-p3-c#6|C.6 Task Identification and Attributes]] :: [[Guide:9x_rationale/rat95-p3-c#7|C.7 Requirements Summary]] ==== [[Guide:9x_rationale/rat95-p3-d|D Real-Time Systems]] ==== :: [[Guide:9x_rationale/rat95-p3-d#1|D.1 Task Priorities]] :: [[Guide:9x_rationale/rat95-p3-d#2|D.2 Priority Scheduling]] :: [[Guide:9x_rationale/rat95-p3-d#3|D.3 Priority Ceiling Locking]] :: [[Guide:9x_rationale/rat95-p3-d#4|D.4 Entry Queuing Policies]] :: [[Guide:9x_rationale/rat95-p3-d#5|D.5 Dynamic Priorities]] :: [[Guide:9x_rationale/rat95-p3-d#6|D.6 Preemptive Abort]] :: [[Guide:9x_rationale/rat95-p3-d#7|D.7 Tasking Restrictions]] :: [[Guide:9x_rationale/rat95-p3-d#8|D.8 Monotonic Time]] :: [[Guide:9x_rationale/rat95-p3-d#9|D.9 Delay Accuracy]] :: [[Guide:9x_rationale/rat95-p3-d#10|D.10 Synchronous Task Control]] :: [[Guide:9x_rationale/rat95-p3-d#11|D.11 Asynchronous Task Control]] :: [[Guide:9x_rationale/rat95-p3-d#12|D.12 Special Optimization and Determinism Rules]] :: [[Guide:9x_rationale/rat95-p3-d#13|D.13 Requirements Summary]] ==== [[Guide:9x_rationale/rat95-p3-e|E Distributed Systems]] ==== :: [[Guide:9x_rationale/rat95-p3-e#1|E.1 The Partition Model]] :: [[Guide:9x_rationale/rat95-p3-e#2|E.2 Categorization of Library Packages]] :: [[Guide:9x_rationale/rat95-p3-e#3|E.3 Consistency of a Distributed System]] :: [[Guide:9x_rationale/rat95-p3-e#4|E.4 Remote Subprogram Calls]] :: [[Guide:9x_rationale/rat95-p3-e#5|E.5 Post-Compilation Partitioning]] :: [[Guide:9x_rationale/rat95-p3-e#6|E.6 Configuring a Distributed System]] :: [[Guide:9x_rationale/rat95-p3-e#7|E.7 Partition Communication Subsystem]] :: [[Guide:9x_rationale/rat95-p3-e#8|E.8 Requirements Summary]] ==== [[Guide:9x_rationale/rat95-p3-f|F Information Systems]] ==== :: [[Guide:9x_rationale/rat95-p3-f#1|F.1 Decimal Computation]] :: [[Guide:9x_rationale/rat95-p3-f#2|F.2 Edited Output]] :: [[Guide:9x_rationale/rat95-p3-f#3|F.3 Requirements Summary]] ==== [[Guide:9x_rationale/rat95-p3-g|G Numerics]] ==== :: [[Guide:9x_rationale/rat95-p3-g#1|G.1 Complex Arithmetic]] :: [[Guide:9x_rationale/rat95-p3-g#2|G.2 Floating Point Machine Numbers]] :: [[Guide:9x_rationale/rat95-p3-g#3|G.3 Assignments to Variables of Unconstrained Numeric Types]] :: [[Guide:9x_rationale/rat95-p3-g#4|G.4 Accuracy and Other Performance Issues]] :: [[Guide:9x_rationale/rat95-p3-g#5|G.5 Requirements Summary]] ==== [[Guide:9x_rationale/rat95-p3-h|H Safety and Security]] ==== :: [[Guide:9x_rationale/rat95-p3-h#1|H.1 Understanding Program Execution]] :: [[Guide:9x_rationale/rat95-p3-h#2|H.2 Reviewable Object Code]] :: [[Guide:9x_rationale/rat95-p3-h#3|H.3 Safety and Security Restrictions]] :: [[Guide:9x_rationale/rat95-p3-h#4|H.4 Validation against the Annex]] :: [[Guide:9x_rationale/rat95-p3-h#5|H.5 Issues outside the Scope of the Standard]] :: [[Guide:9x_rationale/rat95-p3-h#6|H.6 Requirements Summary]] == [[Guide:9x_rationale/rat95-p4|Part Four Appendices]] == ==== [[Guide:9x_rationale/rat95-p4-x|Appendix X Upward Compatibility]] ==== :: [[Guide:9x_rationale/rat95-p4-x#1|X.1 Reserved Words]] :: [[Guide:9x_rationale/rat95-p4-x#2|X.2 Type Character]] :: [[Guide:9x_rationale/rat95-p4-x#3|X.3 Library Package Bodies]] :: [[Guide:9x_rationale/rat95-p4-x#4|X.4 Indefinite Generic Parameters]] :: [[Guide:9x_rationale/rat95-p4-x#5|X.5 Numeric Error]] :: [[Guide:9x_rationale/rat95-p4-x#6|X.6 Other Incompatibilities]] :: [[Guide:9x_rationale/rat95-p4-x#7|X.7 Conclusion]] ==== [[Guide:9x_rationale/rat95-p4-y#1|Appendix Y Revisions to Drafts]] ==== :: [[Guide:9x_rationale/rat95-p4-y#1|Y.1 Core Language]] :: [[Guide:9x_rationale/rat95-p4-y#2|Y.2 Predefined Environment]] :: [[Guide:9x_rationale/rat95-p4-y#3|Y.3 Specialized Needs Annexes]] ==== [[Guide:9x_rationale/rat95-p4-z|Appendix Z Requirements]] ==== :: [[Guide:9x_rationale/rat95-p4-z#1|Z.1 Analysis]] :: [[Guide:9x_rationale/rat95-p4-z#2|Z.2 Conclusion]] == [[Guide:9x_rationale/rat95-references|References]] == == [[Guide:9x_rationale/rat95-index|Index]] == <p><div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-preface|Previous]] | [[Guide:9x_rationale/rat95-p1-1|Next]]</div></p> <p>[[Guide:9x_rationale/rat95-author|Laurent Guerby]]</p></li></ul> {{9x_rationale|Displaytitle=Contents}} i4od8kqv39zky53xv87lo9piryi9zro Guide:9x rationale/rat95-copyright 4200 323 1852 1833 2019-04-20T16:19:47Z WikiVisor 11 Text replacement - "|Next]]" to "|Next]]</div>" wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-index|Previous]] | [[Guide:9x_rationale/rat95-foreword|Next]]</div> == TERMS AND CONDITIONS FOR COPYING AND DISTRIBUTION == ''The HTML hypertext annotations of the "Hypertext Ada 95 Rationale" are Copyright (C) 1995 by Laurent Guerby. All rights reserved.'' The "Hypertext Ada 95 Rationale" hereafter referred to as the "package", is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This package may be freely copied and distributed, if accompanied by this statement, and provided that integral copies of all files are included (i.e. no change whatsoever is allowed). You are asked to help keep the hypertext annotations consistent, identical everywhere in the world. If you think something needs to be modified, tell me what and why (see my e-mail address below). You may not sell these hypertext annotations but you may include and use them in an application. There are no royalties for such uses of the annotations; I only ask that any documentation acknowledge that it includes or uses the hypertext annotations developed by me. == NO WARRANTY == THERE IS NO WARRANTY FOR THIS PACKAGE, TO THE EXTENT PERMITTED BY APPLICABLE LAW. THE COPYRIGHT HOLDER PROVIDES THE PACKAGE "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT WILL THE COPYRIGHT HOLDER BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PACKAGE (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PACKAGE TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. ''This is the release 1 of the Ada 95 Rationale.'' <pre> Ada 95 Rationale The Language The Standard Libraries January 1995 Intermetrics, Inc. 733 Concord Ave. Cambridge, Massachusetts 02138 (617) 661-1840 Copyright 1994,1995 Intermetrics, Inc. This copyright is assigned to the U.S. Government as represented by the Director, Ada Joint Program Office. All rights reserved. This document may be copied, in whole or in part, in any form or by any means, as is or with alterations, provided that (1) alterations are clearly marked as alterations and (2) this copyright notice is included unmodified in any copy. Compiled copies of standard library units and examples need not contain this copyright notice so long as the notice is included in all copies of source code and documentation.</pre> <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-index|Previous]] | [[Guide:9x_rationale/rat95-foreword|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=Hypertext Ada 95 Copyright}} nscfm9a6szr68fq8nfod3ppwm4fdrgd Guide:9x rationale/rat95-foreword 4200 324 3413 1832 2019-04-24T16:52:59Z WikiVisor 11 wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-contents|Previous]] | [[Guide:9x_rationale/rat95-preface|Next]]</div> I am delighted to write these words of introduction to this important document which accompanies the new Ada International Standard. It is most satisfying to see the efforts of all those involved with the language revision effort bearing fruit, and I am very confident that Ada 95 will prove to be a worthy successor to Ada 83, extending Ada's Software Engineering advantages to new user communities. With modern features such as Object-Oriented Programming and enhanced interfacing capabilities, Ada 95 will enable the flexible and reliable development of major applications in the coming years. The new standard, officially ISO/IEC 8652:1995, thus marks an important milestone in Ada's history. Enormous contributions from some of the world's finest software engineers and programming language experts have gone into the revision effort, reflecting both current and anticipated user requirements. I would therefore like to take this opportunity to acknowledge the sterling efforts of all those involved in developing the new standard and in writing this rationale document. The Ada 95 language revision was prepared by the Ada 9X Design Team based at Intermetrics, Inc., under the direction of William Carlson, Program Manager, and S. Tucker Taft, Technical Director. The Intermetrics team included Robert Duff (Oak Tree Software) and also consultants John Barnes, Ben Brosgol, and Offer Pazy. A team led by John Goodenough (SEI) prepared the technical requirements specification for the Ada revision, based on preliminary work by the Institute for Defense Analyses under Audrey Hook to analyze the more than 750 revision requests submitted by the Ada community. The following consultants to the Ada 9X Project contributed to the Specialized Needs Annexes: Ted Baker (SEI, Florida State Univ.), Ken Dritz (Argonne National Laboratory), Anthony Gargaro (Computer Sciences Corp.), John Goodenough (SEI), John McHugh (consultant), and Brian Wichmann (NPL: UK). This work was regularly reviewed by the Ada 9X Distinguished Reviewers and the members of the ISO Ada 9X Rapporteur Group (XRG): Erhard Ploedereder, Chairman of DRs and XRG (University of Stuttgart: Germany); B. Bardin (Hughes); J. Barnes (consultant: UK); B. Brett (DEC); B. Brosgol (consultant); R. Brukardt (RR Software); N. Cohen (IBM); R. Dewar (NYU); G. Dismukes (Alsys [Telesoft]); A. Evans (consultant); A. Gargaro (Computer Sciences Corp.); M. Gerhardt (ESL); J. Goodenough (SEI); S. Heilbrunner (University of Salzburg: Austria); P. Hilfinger (UC/Berkeley); B. Kallberg (CelsiusTech: Sweden); M. Kamrad II (Unisys); J. van Katwijk (Delft University of Technology: The Netherlands); V. Kaufman (Russia); P. Kruchten (Rational); R. Landwehr (CCI: Germany); C. Lester (Portsmouth Polytechnic: UK); L. Mansson (TELIA Research: Sweden); S. Michell (Multiprocessor Toolsmiths: Canada); M. Mills (US Air Force); D. Pogge (US Navy); K. Power (Boeing); O. Roubine (Verdix: France); A. Strohmeier (Swiss Federal Institute of Technology: Switzerland); W. Taylor (consultant: UK); J. Tokar (Tartan); E. Vasilescu (Grumman); J. Vladik (Prospeks s.r.o.: Czech Republic); S. Van Vlier- berghe (OFFIS: Belgium). Early contributors on the Ada 9X Design Team were C. Garrity, R. Hilliard, D. Rosenfeld, L. Shafer, W. White, and M. Woodger. Other valuable feedback influencing the revision process was provided by the Ada 9X Language Precision Team (Odyssey Research Associates), the Ada 9X User/Implementer Teams (AETECH, Tartan, Alsys [Telesoft]), the Ada 9X Implementation Analysis Team (New York University), and the Volunteer Reviewers group under Art Evans (consultant). The principal authors of this rationale document were John Barnes and Ben Brosgol with valuable contributions from Ken Dritz, Offer Pazy and Brian Wichmann. Many thanks also to Bill Taylor for providing the material upon which Appendix X is based, and to Tucker Taft and Robert Duff for their comments and review. Very special thanks go to Virginia Castor, John Solomond and Don Reifer from the Ada Joint Program Office for supporting and sponsoring the Ada 9X Project since its inception, and to Bob Mathis, Convenor of ISO/IEC JTC1/SC22 Working Group 9, for shepherding the revision through the standardization process. Last but not least, I want to extend my sincerest appreciation to the Ada community at large who have volunteered their time and energy on this project. Without your support we would not have been able to succeed. Ada 95 is here. It is now up to the users, both those who have appreciated the engineering benefits of Ada 83 and others who may be frustrated with the hazards of their current techniques, to move forward and reap the benefits of this new language. ''Christine M. Anderson,<br /> Ada 9X Project Manager'' <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-copyright|Previous]] | [[Guide:9x_rationale/rat95-preface|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=Foreword}} 8pxs70bzw5qm6cc3vzonvxqmu3qxtpy Guide:9x rationale/rat95-index 4200 325 1896 1883 2019-04-20T17:17:26Z WikiVisor 11 wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-references|Previous]] | [[Guide:9x_rationale/rat95-copyright|Next]]</div> <!-- <div class="jumbotron text-center"> [[#a|A]] | [[#b|B]] | [[#c|C]] | [[#d|D]] | [[#e|E]] | [[#f|F]] | [[#g|G]] | [[#h|H]] | [[#i|I]] | J | K | [[#l|L]] | [[#m|M]] | [[#n|N]] | [[#o|O]] | [[#p|P]] | [[#q|Q]] | [[#r|R]] | [[#s|S]] | [[#t|T]] | [[#u|U]] | [[#v|V]] | [[#w|W]] | X | Y | Z</div> --> The entries in this index refer to the section and not to the page number. In identifying an appropriate entry the reader is reminded that references into Chapter II (of part One) are likely to give a general introduction to a new feature, those into Chapter III (of part One) are likely to briefly summarize a feature in the context of the whole language, whereas those in Parts Two and Three (identified by chapters 1 to 13 and A to H respectively) will give further detail of specific aspects of a feature. Furthermore Appendix X concerns incompatibilities with Ada 83 and Appendix Y concerns changes since the Committee Draft and the Draft International Standard. == <span id="a">A</span> == ; abort statement : [[Guide:9x_rationale/rat95-p2-9#5|9.5]] : preemptive [[Guide:9x_rationale/rat95-p3-d#6|D.6]] : with requeue [[Guide:9x_rationale/rat95-p2-9#2|9.2]] ; abstract types : sequences of [[Guide:9x_rationale/rat95-p2-4#6-2|4.6.2]] : and private types [[Guide:9x_rationale/rat95-p2-3#6-2|3.6.2]] : abstract types and subprograms [[Guide:9x_rationale/rat95-p1-2#2|II.3,]] [[Guide:9x_rationale/rat95-p2-3#6-2|3.6.2]] ; abstraction : multiple implementation [[Guide:9x_rationale/rat95-p2-4#4-3|4.4.3]] ; accept statement : exception handler [[Guide:9x_rationale/rat95-p2-11#4|11.4]] ; Access attribute : [[Guide:9x_rationale/rat95-p2-3#7-1|3.7.1]] : restrictions in generics [[Guide:9x_rationale/rat95-p2-12#3|12.3,]] [[Guide:9x_rationale/rat95-p4-y#1|Y.1]] : restriction on components [[Guide:9x_rationale/rat95-p2-3#7-1|3.7.1]] ; access discriminants : [[Guide:9x_rationale/rat95-p2-3#4-1|3.4.1,]] [[Guide:9x_rationale/rat95-p2-3#7-1|3.7.1]] : self referential [[Guide:9x_rationale/rat95-p2-4#6-3|4.6.3]] : and finalization [[Guide:9x_rationale/rat95-p2-7#4|7.4]] : class wide with tasking [[Guide:9x_rationale/rat95-p2-9#6-1|9.6.1]] ; access parameters : [[Guide:9x_rationale/rat95-p2-3#7-1|3.7.1,]] [[Guide:9x_rationale/rat95-p2-6#1-2|6.1.2,]] [[Guide:9x_rationale/rat95-p2-9#6-1|9.6.1]] ; access types : [[Guide:9x_rationale/rat95-p2-3#7|3.7]] : to object [[Guide:9x_rationale/rat95-p1-2#6|II.6,]] [[Guide:9x_rationale/rat95-p2-3#7-1|3.7.1]] : to subprogram [[Guide:9x_rationale/rat95-p1-2#5|II.5,]] [[Guide:9x_rationale/rat95-p2-3#7-2|3.7.2]] ; accessibility : of objects [[Guide:9x_rationale/rat95-p2-3#7-1|3.7.1]] : of parameters [[Guide:9x_rationale/rat95-p2-6#1-2|6.1.2]] : of subprograms [[Guide:9x_rationale/rat95-p2-3#7-2|3.7.2]] : and type extension [[Guide:9x_rationale/rat95-p2-12#5|12.5]] ; accuracy : for real types [[Guide:9x_rationale/rat95-p3-g#4|G.4]] : for the Numerics packages [[Guide:9x_rationale/rat95-p3-g#4-3|G.4.3]] ; active partition : See partition ; active priority : See priority ; Ada (predefined library package) : Ada.Characters [[Guide:9x_rationale/rat95-p3-a|A,]] [[Guide:9x_rationale/rat95-p3-a#1|A.1]] : Ada.Command_Line [[Guide:9x_rationale/rat95-p3-a|A,]] [[Guide:9x_rationale/rat95-p3-a#5|A.5]] : Ada.Numerics [[Guide:9x_rationale/rat95-p3-a|A]] : Ada.Strings [[Guide:9x_rationale/rat95-p3-a|A,]] [[Guide:9x_rationale/rat95-p3-a#2|A.2]] : Ada.Text_IO [[Guide:9x_rationale/rat95-p3-a|A,]] [[Guide:9x_rationale/rat95-p3-a#4-2|A.4.2,]] [[Guide:9x_rationale/rat95-p4-y#2|Y.2]] : Ada.Wide_Text_IO [[Guide:9x_rationale/rat95-p3-a|A,]] [[Guide:9x_rationale/rat95-p3-a#4-2|A.4.2]] ; aliased : [[Guide:9x_rationale/rat95-p1-2#6|II.6,]] [[Guide:9x_rationale/rat95-p2-3#7-1|3.7.1]] ; Alignment attribute : [[Guide:9x_rationale/rat95-p2-13#1|13.1]] ; array aggregates : [[Guide:9x_rationale/rat95-p2-3#5-1|3.5.1]] : with others [[Guide:9x_rationale/rat95-p2-3#5-1|3.5.1,]] [[Guide:9x_rationale/rat95-p2-6#1|6.1]] ; array subtype conversion : [[Guide:9x_rationale/rat95-p1-2#12|II.12]] ; assignment : dispatching [[Guide:9x_rationale/rat95-p2-4#4-3|4.4.3]] : user-defined [[Guide:9x_rationale/rat95-p2-7#4|7.4]] ; asynchronous transfer of control : [[Guide:9x_rationale/rat95-p1-2#10|II.10,]] [[Guide:9x_rationale/rat95-p2-9#4|9.4]] : with controlled types [[Guide:9x_rationale/rat95-p2-9#4|9.4]] ; ATC : [[Guide:9x_rationale/rat95-p1-2#10|II.10,]] [[Guide:9x_rationale/rat95-p2-9#4|9.4]] ; attributes : Alignment [[Guide:9x_rationale/rat95-p2-13#1|13.1]] : Base [[Guide:9x_rationale/rat95-p1-2#12|II.12,]] [[Guide:9x_rationale/rat95-p2-3#1-1|3.1.1,]] [[Guide:9x_rationale/rat95-p2-3#3|3.3]] : Bit_Order [[Guide:9x_rationale/rat95-p2-13#1|13.1]] : of floating point types [[Guide:9x_rationale/rat95-p3-g#2|G.2,]] [[Guide:9x_rationale/rat95-p3-g#4-1|G.4.1]] : Input [[Guide:9x_rationale/rat95-p3-a#4-1|A.4.1]] : Modulus [[Guide:9x_rationale/rat95-p2-3#3-2|3.3.2]] : Normalize_Scalars [[Guide:9x_rationale/rat95-p3-h#1-2|H.1.2]] : Output [[Guide:9x_rationale/rat95-p3-a#4-1|A.4.1]] : Read [[Guide:9x_rationale/rat95-p3-a#4-1|A.4.1]] : Size [[Guide:9x_rationale/rat95-p2-13#1|13.1]] : Tag [[Guide:9x_rationale/rat95-p2-4#3|4.3,]] [[Guide:9x_rationale/rat95-p2-4#5|4.5]] : Valid [[Guide:9x_rationale/rat95-p2-13#3|13.3,]] [[Guide:9x_rationale/rat95-p3-h#1-1|H.1.1]] : Write [[Guide:9x_rationale/rat95-p3-a#4-1|A.4.1]] == <span id="b">B</span> == ; barrier condition : [[Guide:9x_rationale/rat95-p1-2#9|II.9]] ; barriers : [[Guide:9x_rationale/rat95-p2-9#1|9.1,]] [[Guide:9x_rationale/rat95-p2-9#1-2|9.1.2]] ; Base attribute : [[Guide:9x_rationale/rat95-p1-2#12|II.12,]] [[Guide:9x_rationale/rat95-p2-3#1-1|3.1.1,]] [[Guide:9x_rationale/rat95-p2-3#3|3.3]] ; base priority : See priority ; base range : [[Guide:9x_rationale/rat95-p2-3#3|3.3]] ; Bit_Order attribute : [[Guide:9x_rationale/rat95-p2-13#1|13.1]] ; bounded length strings : [[Guide:9x_rationale/rat95-p3-a#2-5|A.2.5]] ; "Brown model" (for floating point accuracy) : [[Guide:9x_rationale/rat95-p3-g#4-1|G.4.1]] == <span id="c">C</span> == ; C (the language) : [[Guide:9x_rationale/rat95-p3-b#2|B.2]] ; categorization (of library units) : [[Guide:9x_rationale/rat95-p3-e#2|E.2]] ; catenation : [[Guide:9x_rationale/rat95-p2-3#5-2|3.5.2]] ; ceiling : See priority ; Character : [[Guide:9x_rationale/rat95-p2-3#2|3.2,]] [[Guide:9x_rationale/rat95-p4-x#2|X.2]] ; character handling : [[Guide:9x_rationale/rat95-p3-a#1|A.1]] ; characters : in program text [[Guide:9x_rationale/rat95-p2-2#2|2.2]] ; Characters : [[Guide:9x_rationale/rat95-p1-2#13|II.13,]] [[Guide:9x_rationale/rat95-p4-y#2|Y.2]] ; child unit : [[Guide:9x_rationale/rat95-p1-2#7|II.7]] ; children, generic : [[Guide:9x_rationale/rat95-p1-2#8|II.8,]] [[Guide:9x_rationale/rat95-p2-4#4-4|4.4.4,]] [[Guide:9x_rationale/rat95-p2-10#1-3|10.1.3]] ; class wide types : [[Guide:9x_rationale/rat95-p1-2#2|II.2,]] [[Guide:9x_rationale/rat95-p2-4#2|4.2]] : initialization [[Guide:9x_rationale/rat95-p2-4#3|4.3]] ; classes : [[Guide:9x_rationale/rat95-p1-3#1-2|III.1.2,]] [[Guide:9x_rationale/rat95-p2-3#1|3.1,]] [[Guide:9x_rationale/rat95-p2-4#2|4.2]] ; clocks : [[Guide:9x_rationale/rat95-p2-9#3|9.3,]] [[Guide:9x_rationale/rat95-p3-d#8|D.8]] ; COBOL : edited output [[Guide:9x_rationale/rat95-p3-f#2-2|F.2.2]] : interface package [[Guide:9x_rationale/rat95-p3-b#3|B.3]] ; command line : [[Guide:9x_rationale/rat95-p3-a#5|A.5,]] [[Guide:9x_rationale/rat95-p4-y#2|Y.2]] ; Complex_IO : [[Guide:9x_rationale/rat95-p3-g#1-3|G.1.3]] ; complex number arithmetic : [[Guide:9x_rationale/rat95-p3-g#1|G.1]] ; concatenation : [[Guide:9x_rationale/rat95-p2-3#5-2|3.5.2]] ; conformance : [[Guide:9x_rationale/rat95-p2-6#2|6.2]] ; contract model : [[Guide:9x_rationale/rat95-p2-12#1|12.1]] ; controlled types : [[Guide:9x_rationale/rat95-p2-7#4|7.4,]] [[Guide:9x_rationale/rat95-p4-y#1|Y.1]] : and ATC [[Guide:9x_rationale/rat95-p2-9#4|9.4]] : storage pool [[Guide:9x_rationale/rat95-p2-13#4|13.4]] ; controlling operands : [[Guide:9x_rationale/rat95-p2-4#2|4.2,]] [[Guide:9x_rationale/rat95-p2-4#5|4.5]] : results [[Guide:9x_rationale/rat95-p2-4#2|4.2]] ; conversion : [[Guide:9x_rationale/rat95-p2-3#8|3.8]] : tagged types [[Guide:9x_rationale/rat95-p2-4#5|4.5]] ; current error file : [[Guide:9x_rationale/rat95-p3-a#4-3|A.4.3]] == <span id="d">D</span> == ; decimal arithmetic : [[Guide:9x_rationale/rat95-p3-f#1|F.1]] ; decimal representation : [[Guide:9x_rationale/rat95-p3-f#1-4|F.1.4,]] [[Guide:9x_rationale/rat95-p3-b#3|B.3]] ; decimal types : [[Guide:9x_rationale/rat95-p2-3#3-3|3.3.3,]] [[Guide:9x_rationale/rat95-p3-f#1-3|F.1.3]] ; deferral of abort : [[Guide:9x_rationale/rat95-p2-9#2|9.2]] ; deferred constants : [[Guide:9x_rationale/rat95-p2-7#2|7.2,]] [[Guide:9x_rationale/rat95-p2-13#5|13.5]] ; definite types : [[Guide:9x_rationale/rat95-p1-2#11|II.11,]] [[Guide:9x_rationale/rat95-p2-12#1|12.1]] ; delay statement : [[Guide:9x_rationale/rat95-p1-2#10|II.10,]] [[Guide:9x_rationale/rat95-p2-9#3|9.3,]] [[Guide:9x_rationale/rat95-p3-d#9|D.9]] ; derived types : [[Guide:9x_rationale/rat95-p2-3#1-2|3.1.2]] ; Discrete_Random : [[Guide:9x_rationale/rat95-p3-a#3-2|A.3.2]] ; discriminants : [[Guide:9x_rationale/rat95-p1-2#12|II.12,]] [[Guide:9x_rationale/rat95-p1-3#1-2|III.1.2,]] [[Guide:9x_rationale/rat95-p2-3#4-1|3.4.1]] : protected types [[Guide:9x_rationale/rat95-p2-9#1|9.1]] : tasks [[Guide:9x_rationale/rat95-p2-9#6|9.6]] : access class wide and tasking [[Guide:9x_rationale/rat95-p2-9#6-1|9.6.1]] ; dispatch table : [[Guide:9x_rationale/rat95-p2-4#3|4.3]] ; dispatching : [[Guide:9x_rationale/rat95-p1-2#2|II.2,]] [[Guide:9x_rationale/rat95-p1-3#1-4|III.1.4,]] [[Guide:9x_rationale/rat95-p2-4#2|4.2,]] [[Guide:9x_rationale/rat95-p2-4#5|4.5]] : equality [[Guide:9x_rationale/rat95-p2-4#4-3|4.4.3]] : assignment [[Guide:9x_rationale/rat95-p2-4#4-3|4.4.3]] : safety of [[Guide:9x_rationale/rat95-p2-4#3|4.3]] : for tasks [[Guide:9x_rationale/rat95-p3-d#2|D.2]] ; Distributed Systems Annex : [[Guide:9x_rationale/rat95-p3-e|E]] ; dynamic binding : [[Guide:9x_rationale/rat95-p1-2#5|II.5,]] [[Guide:9x_rationale/rat95-p3-e#1|E.1,]] [[Guide:9x_rationale/rat95-p3-e#5-1|E.5.1]] == <span id="e">E</span> == ; edited output : [[Guide:9x_rationale/rat95-p3-f#2|F.2,]] [[Guide:9x_rationale/rat95-p4-y#3|Y.3]] ; elaboration order : [[Guide:9x_rationale/rat95-p2-10#3|10.3]] ; entry barriers : [[Guide:9x_rationale/rat95-p2-9#1|9.1,]] [[Guide:9x_rationale/rat95-p2-9#1-2|9.1.2]] ; entry queueing : See queueing policy ; equality : redefinition of [[Guide:9x_rationale/rat95-p1-2#12|II.12,]] [[Guide:9x_rationale/rat95-p2-6#3|6.3]] : for tagged types [[Guide:9x_rationale/rat95-p2-4#3|4.3]] : dispatching [[Guide:9x_rationale/rat95-p2-4#4-3|4.4.3]] ; errors : [[Guide:9x_rationale/rat95-p2-1#1-4|1.4]] ; exception messages : [[Guide:9x_rationale/rat95-p2-11#2|11.2]] ; exception occurrences : [[Guide:9x_rationale/rat95-p2-11#2|11.2,]] ; extension aggregates : [[Guide:9x_rationale/rat95-p2-3#6-1|3.6.1,]] [[Guide:9x_rationale/rat95-p4-y#1|Y.1]] == <span id="f">F</span> == ; File_Access (in Text_IO) : [[Guide:9x_rationale/rat95-p3-a#4-3|A.4.3]] ; finalization : [[Guide:9x_rationale/rat95-p2-7#4|7.4]] : and access discriminants [[Guide:9x_rationale/rat95-p2-7#4|7.4]] ; fixed length strings : See string handling ; fixed point : arithmetic and attributes [[Guide:9x_rationale/rat95-p3-g#4-2|G.4.2]] : operations [[Guide:9x_rationale/rat95-p2-3#3-1|3.3.1]] ; floating point : [[Guide:9x_rationale/rat95-p3-g#2|G.2]] : arithmetic and attributes [[Guide:9x_rationale/rat95-p3-g#4-1|G.4.1]] ; Float_Random : [[Guide:9x_rationale/rat95-p3-a#3-2|A.3.2]] ; Flush (in Text_IO) : [[Guide:9x_rationale/rat95-p3-a#4-2|A.4.2]] ; Fortran : [[Guide:9x_rationale/rat95-p3-b#4|B.4]] ; freezing : [[Guide:9x_rationale/rat95-p2-13#5|13.5]] : tagged types [[Guide:9x_rationale/rat95-p2-13#5-1|13.5.1]] == <span id="g">G</span> == ; generic body restrictions : Access attribute [[Guide:9x_rationale/rat95-p2-12#3|12.3,]] [[Guide:9x_rationale/rat95-p4-y#1|Y.1]] : type extension [[Guide:9x_rationale/rat95-p2-12#5|12.5]] ; generic children : [[Guide:9x_rationale/rat95-p1-2#8|II.8,]] [[Guide:9x_rationale/rat95-p2-4#4-4|4.4.4,]] [[Guide:9x_rationale/rat95-p2-10#1-3|10.1.3]] : renaming [[Guide:9x_rationale/rat95-p2-8#3|8.3]] ; generic parameters : [[Guide:9x_rationale/rat95-p1-2#11|II.11]] : packages [[Guide:9x_rationale/rat95-p1-2#11|II.11,]] [[Guide:9x_rationale/rat95-p2-12#6|12.6]] : access [[Guide:9x_rationale/rat95-p2-12#3|12.3]] : derived untagged [[Guide:9x_rationale/rat95-p2-12#4|12.4]] ; tagged [[Guide:9x_rationale/rat95-p2-12#5|12.5]] : indefinite [[Guide:9x_rationale/rat95-p4-x#4|X.4]] ; Generic_Complex_Types : [[Guide:9x_rationale/rat95-p3-g#1-1|G.1.1]] ; Generic_Complex_Elementary_- : Functions [[Guide:9x_rationale/rat95-p3-g#1-2|G.1.2]] ; Generic_Elementary_Functions [[Guide:9x_rationale/rat95-p3-a#3-1|A.3.1]] : Base attribute [[Guide:9x_rationale/rat95-p2-3#1-1|3.1.1]] ; Get_Immediate (in Text_IO) : [[Guide:9x_rationale/rat95-p3-a#4-2|A.4.2]] == <span id="h">H</span> == ; heterogeneous structures : [[Guide:9x_rationale/rat95-p2-4#4-1|4.4.1,]] [[Guide:9x_rationale/rat95-p2-4#4-2|4.4.2]] ; hierarchical library : [[Guide:9x_rationale/rat95-p1-2#7|II.7,]] [[Guide:9x_rationale/rat95-p1-3#3-6|III.3.6,]] [[Guide:9x_rationale/rat95-p2-10#1|10.1]] == <span id="i">I</span> == ; indefinite generic parameters : [[Guide:9x_rationale/rat95-p4-x#4|X.4]] ; indefinite types : [[Guide:9x_rationale/rat95-p1-2#11|II.11,]] [[Guide:9x_rationale/rat95-p2-12#1|12.1]] : initialization [[Guide:9x_rationale/rat95-p2-3#4|3.4]] ; Information Systems Annex [[Guide:9x_rationale/rat95-p3-f|F]]<br /> initialization of indefinite types : [[Guide:9x_rationale/rat95-p2-3#4|3.4]] ; Input attribute : [[Guide:9x_rationale/rat95-p3-a#4-1|A.4.1]] ; input-output : [[Guide:9x_rationale/rat95-p1-3#7-1|III.7.1,]] [[Guide:9x_rationale/rat95-p3-a#4|A.4]] ; Interfaces : [[Guide:9x_rationale/rat95-p2-3#3|3.3]] : C [[Guide:9x_rationale/rat95-p3-b#2|B.2]] : COBOL [[Guide:9x_rationale/rat95-p3-b#3|B.3]] : Fortran [[Guide:9x_rationale/rat95-p3-b#4|B.4]] ; interfacing to other languages : [[Guide:9x_rationale/rat95-p3-b|B,]] [[Guide:9x_rationale/rat95-p3-c#1|C.1]] ; interrupt handling : [[Guide:9x_rationale/rat95-p3-c#3|C.3]] ; intrinsic subprograms : [[Guide:9x_rationale/rat95-p3-c#1|C.1]] ; iterators : [[Guide:9x_rationale/rat95-p2-3#7-1|3.7.1,]] [[Guide:9x_rationale/rat95-p2-4#4-4|4.4.4]] == <span id="l">L</span> == ; Latin-1 : [[Guide:9x_rationale/rat95-p3-a#1|A.1]] ; library package bodies : [[Guide:9x_rationale/rat95-p1-2#12|II.12,]] [[Guide:9x_rationale/rat95-p2-10#4|10.4,]] [[Guide:9x_rationale/rat95-p4-x#3|X.3]] ; limited types : [[Guide:9x_rationale/rat95-p1-3#1-2|III.1.2,]] [[Guide:9x_rationale/rat95-p2-7#3|7.3]] : access discriminants [[Guide:9x_rationale/rat95-p2-3#4-1|3.4.1]] ; localization (of edited output) : [[Guide:9x_rationale/rat95-p3-f#2|F.2]] ; locks : [[Guide:9x_rationale/rat95-p2-9#1-1|9.1.1,]] [[Guide:9x_rationale/rat95-p2-9#1-2|9.1.2]] : and interrupt handling [[Guide:9x_rationale/rat95-p3-c#3-1|C.3.1]] ; logical operations : on modular types [[Guide:9x_rationale/rat95-p2-3#3-2|3.3.2]] ; Look_Ahead (in Text_IO) : [[Guide:9x_rationale/rat95-p3-a#4-1|A.4.1]] == <span id="m">M</span> == ; membership tests : for tagged types [[Guide:9x_rationale/rat95-p2-4#3|4.3]] ; "mixin" inheritance : [[Guide:9x_rationale/rat95-p2-4#6-2|4.6.2]] ; mode change : [[Guide:9x_rationale/rat95-p1-2#10|II.10]] ; modular types : [[Guide:9x_rationale/rat95-p2-3#3-2|3.3.2,]] [[Guide:9x_rationale/rat95-p4-y#1|Y.1]] ; Modulus attribute : [[Guide:9x_rationale/rat95-p2-3#3-2|3.3.2]] ; multiple inheritance : [[Guide:9x_rationale/rat95-p2-4#6|4.6]] == <span id="n">N</span> == ; Normalize_Scalars attribute : [[Guide:9x_rationale/rat95-p3-h#1-2|H.1.2]] ; normal value (for a scalar object) : [[Guide:9x_rationale/rat95-p3-h#1-2|H.1.2]] ; numeric packages : [[Guide:9x_rationale/rat95-p1-2#12|II.12]] ; numeric types : [[Guide:9x_rationale/rat95-p1-3#1-2|III.1.2,]] [[Guide:9x_rationale/rat95-p2-3#3|3.3]] : accuracy [[Guide:9x_rationale/rat95-p3-g#4|G.4]] : unconstrained, and assignment [[Guide:9x_rationale/rat95-p3-g#3|G.3]] : See also: fixed point, floating point ; Numeric_Error : [[Guide:9x_rationale/rat95-p2-11#1|11.1,]] [[Guide:9x_rationale/rat95-p4-x#5|X.5]] ; Numerics Annex : [[Guide:9x_rationale/rat95-p3-g|G]] == <span id="o">O</span> == ; objects : [[Guide:9x_rationale/rat95-p2-3#1|3.1]] ; OOP, background : [[Guide:9x_rationale/rat95-p2-4#1|4.1,]] [[Guide:9x_rationale/rat95-p2-4#7|4.7]] ; order of declarations : [[Guide:9x_rationale/rat95-p2-3#10|3.10]] ; out parameters : [[Guide:9x_rationale/rat95-p1-2#12|II.12,]] [[Guide:9x_rationale/rat95-p2-6#1-1|6.1.1]] ; Output attribute : [[Guide:9x_rationale/rat95-p3-a#4-1|A.4.1]] == <span id="p">P</span> == ;parameters, of subprograms :[[Guide:9x_rationale/rat95-p2-6#1|6.1]] :access [[Guide:9x_rationale/rat95-p2-6#1-2|6.1.2]] :in out [[Guide:9x_rationale/rat95-p2-6#1-2|6.1.2]] :out [[Guide:9x_rationale/rat95-p2-6#1-1|6.1.1]] ;partitions :[[Guide:9x_rationale/rat95-p1-3#3-7|III.3.7,]] [[Guide:9x_rationale/rat95-p2-10#2|10.2,]] [[Guide:9x_rationale/rat95-p3-e#1|E.1]] :post-compilation partitioning [[Guide:9x_rationale/rat95-p3-e#5|E.5]] ;partition communictaion subsystem (PCS) :[[Guide:9x_rationale/rat95-p3-e#7|E.7]] ;passive partition :See partition ;polymorphism :[[Guide:9x_rationale/rat95-p1-3#1-2|III.1.2]] ;pragmas :[[Guide:9x_rationale/rat95-p2-2#3|2.3]] :All_Calls_Remote [[Guide:9x_rationale/rat95-p3-e#2|E.2]] :Asynchronous [[Guide:9x_rationale/rat95-p3-e#4-1|E.4.1]] :Atomic [[Guide:9x_rationale/rat95-p3-c#5|C.5]] :Convention [[Guide:9x_rationale/rat95-p3-b#1|B.1]] :Elaborate_All [[Guide:9x_rationale/rat95-p2-10#3|10.3]] :Elaborate_Body [[Guide:9x_rationale/rat95-p2-10#3|10.3]] :Import and Export [[Guide:9x_rationale/rat95-p3-b#1|B.1,]] [[Guide:9x_rationale/rat95-p4-y#2|Y.2]] :Inspection_Point [[Guide:9x_rationale/rat95-p3-h#2-2|H.2.2]] :Preelaborate [[Guide:9x_rationale/rat95-p2-10#3|10.3]] :Priority [[Guide:9x_rationale/rat95-p2-9#6|9.6]] :Pure [[Guide:9x_rationale/rat95-p2-10#3|10.3]] :Reviewable [[Guide:9x_rationale/rat95-p3-h#2-1|H.2.1]] :Restrictions [[Guide:9x_rationale/rat95-p2-13#6|13.6,]] [[Guide:9x_rationale/rat95-p3-d#7|D.7,]] [[Guide:9x_rationale/rat95-p3-h|H,]] [[Guide:9x_rationale/rat95-p3-h#1-2|H.1.2,]] [[Guide:9x_rationale/rat95-p3-h#3|H.3]] :Storage_Size [[Guide:9x_rationale/rat95-p2-9#6|9.6,]] [[Guide:9x_rationale/rat95-p4-y#1|Y.1]] :Volatile [[Guide:9x_rationale/rat95-p3-c#5|C.5]] ;predefined library :[[Guide:9x_rationale/rat95-p1-2#12|II.12,]] [[Guide:9x_rationale/rat95-p3-a|A]] ;preelaboration :[[Guide:9x_rationale/rat95-p2-10#3|10.3,]] [[Guide:9x_rationale/rat95-p3-c#4|C.4]] ;preference control :[[Guide:9x_rationale/rat95-p1-2#9|II.9,]] [[Guide:9x_rationale/rat95-p2-9#2-1|9.2.1]] ;preference rule :[[Guide:9x_rationale/rat95-p2-8#4|8.4]] ;primitive function attributes (of floating point types) :[[Guide:9x_rationale/rat95-p3-g#2-3|G.2.3]] ;primitive operations :[[Guide:9x_rationale/rat95-p1-2#1|II.1,]] [[Guide:9x_rationale/rat95-p1-3#1-3|III.1.3,]] [[Guide:9x_rationale/rat95-p2-4#2|4.2,]] [[Guide:9x_rationale/rat95-p2-4#3|4.3]] :private [[Guide:9x_rationale/rat95-p2-7#1-1|7.1.1]] :of untagged generic paramters [[Guide:9x_rationale/rat95-p2-12#4|12.4]] :of tagged generic parameters [[Guide:9x_rationale/rat95-p2-12#5|12.5]] ;priority :[[Guide:9x_rationale/rat95-p3-d#1|D.1]] :ceiling locking [[Guide:9x_rationale/rat95-p3-d#3|D.3]] :ceiling priorities and interrupt handling [[Guide:9x_rationale/rat95-p3-c#3-1|C.3.1]] :dynamic priority [[Guide:9x_rationale/rat95-p3-d#5|D.5]] ;priority inversion :[[Guide:9x_rationale/rat95-p3-d#3-1|D.3.1]] ;private children :[[Guide:9x_rationale/rat95-p1-2#8|II.8,]] [[Guide:9x_rationale/rat95-p2-10#1-1|10.1.1]] ;private extensions :[[Guide:9x_rationale/rat95-p2-7#1|7.1]] :and visibility [[Guide:9x_rationale/rat95-p2-7#1|7.1]] ;private operations :[[Guide:9x_rationale/rat95-p2-7#1-1|7.1.1]] ;private types :[[Guide:9x_rationale/rat95-p2-7#1|7.1]] ;program libraries :[[Guide:9x_rationale/rat95-p2-10#1-5|10.1.5]] ;program text :[[Guide:9x_rationale/rat95-p2-2#2|2.2]] ;protected operations :[[Guide:9x_rationale/rat95-p2-9#1|9.1]] :as interrupt handlers [[Guide:9x_rationale/rat95-p3-c#3-1|C.3.1]] ;protected types :[[Guide:9x_rationale/rat95-p1-2#9|II.9,]] [[Guide:9x_rationale/rat95-p1-3#4-3|III.4.3,]] [[Guide:9x_rationale/rat95-p2-9#1|9.1]] :efficiency [[Guide:9x_rationale/rat95-p2-9#1-3|9.1.3]] ;public children :[[Guide:9x_rationale/rat95-p1-2#7|II.7,]] [[Guide:9x_rationale/rat95-p2-10#1-1|10.1.1]] == <span id="q">Q</span> == ; queueing policy : [[Guide:9x_rationale/rat95-p3-d#4|D.4]] == <span id="r">R</span> == ; random numbers : [[Guide:9x_rationale/rat95-p3-a#3-2|A.3.2,]] [[Guide:9x_rationale/rat95-p4-y#2|Y.2]] ; Read attribute : [[Guide:9x_rationale/rat95-p3-a#4-1|A.4.1]] ; Real-Time Systems Annex : [[Guide:9x_rationale/rat95-p3-d|D]] ; record aggregates : [[Guide:9x_rationale/rat95-p2-3#6-1|3.6.1]] : redispatching [[Guide:9x_rationale/rat95-p2-4#5|4.5]] ; remote call interface (RCI) : [[Guide:9x_rationale/rat95-p3-e#1|E.1]] ; remote subprogram calls (RPC) : [[Guide:9x_rationale/rat95-p3-e#4|E.4]] ; renaming : [[Guide:9x_rationale/rat95-p2-8#3|8.3]] : of class wide objects [[Guide:9x_rationale/rat95-p2-4#5|4.5]] : of subprogram bodies [[Guide:9x_rationale/rat95-p2-6#2|6.2,]] [[Guide:9x_rationale/rat95-p2-8#3|8.3]] : of generic units [[Guide:9x_rationale/rat95-p2-8#3|8.3]] : of generic children [[Guide:9x_rationale/rat95-p2-8#3|8.3]] : of library units [[Guide:9x_rationale/rat95-p2-10#1-2|10.1.2]] ; requeue : [[Guide:9x_rationale/rat95-p1-2#9|II.9,]] [[Guide:9x_rationale/rat95-p2-9#2|9.2]] : with abort [[Guide:9x_rationale/rat95-p2-9#2|9.2]] ; requirements : [[Guide:9x_rationale/rat95-p1-1#2|I.2]] ; reserved words : [[Guide:9x_rationale/rat95-p2-2#1|2.1,]] [[Guide:9x_rationale/rat95-p4-x#1|X.1]] ; restrictions : See pragma Restrictions ; results of functions : [[Guide:9x_rationale/rat95-p2-6#1|6.1]] : as objects [[Guide:9x_rationale/rat95-p2-7#3|7.3]] ; root types : [[Guide:9x_rationale/rat95-p2-3#3|3.3,]] [[Guide:9x_rationale/rat95-p2-8#4|8.4]] ; rounding : [[Guide:9x_rationale/rat95-p1-2#12|II.12,]] [[Guide:9x_rationale/rat95-p4-x#6-1|X.6.1]] == <span id="s">S</span> == ; Safety and Security Annex : [[Guide:9x_rationale/rat95-p3-h|H]] ; scheduling policy : [[Guide:9x_rationale/rat95-p3-d#2|D.2]] ; self referential structure : [[Guide:9x_rationale/rat95-p2-4#6-3|4.6.3]] ; semaphores : [[Guide:9x_rationale/rat95-p1-2#1-9|II.1.9,]] [[Guide:9x_rationale/rat95-p2-9#1|9.1,]] [[Guide:9x_rationale/rat95-p2-9#1-3|9.1.3]] ; shared variables : [[Guide:9x_rationale/rat95-p3-c#5|C.5]] ; shift operations : on modular types [[Guide:9x_rationale/rat95-p2-3#3-2|3.3.2]] ; signed zeros : [[Guide:9x_rationale/rat95-p3-g#2-2|G.2.2]] ; Size atttribute : [[Guide:9x_rationale/rat95-p2-13#1|13.1]] ; sliding : [[Guide:9x_rationale/rat95-p1-2#12|II.12,]] [[Guide:9x_rationale/rat95-p2-3#5-1|3.5.1]] : of parameters and results [[Guide:9x_rationale/rat95-p2-6#1|6.1]] ; specialized needs annexes : overview [[Guide:9x_rationale/rat95-p1-2#14|II.14]] : requirements for [[Guide:9x_rationale/rat95-p1-1#2|I.2]] ; static expression : [[Guide:9x_rationale/rat95-p1-2#12|II.12,]] [[Guide:9x_rationale/rat95-p2-3#9|3.9]] ; static subtype matching : [[Guide:9x_rationale/rat95-p2-3#9|3.9,]] [[Guide:9x_rationale/rat95-p2-12#7|12.7]] ; storage elements : [[Guide:9x_rationale/rat95-p2-13#2|13.2]] ; storage pools : [[Guide:9x_rationale/rat95-p2-13#4|13.4]] ; stream input-output : [[Guide:9x_rationale/rat95-p3-a#4-1|A.4.1]] ; string handling : [[Guide:9x_rationale/rat95-p3-a#2|A.2]] ; subsystem construction : [[Guide:9x_rationale/rat95-p2-10#1-4|10.1.4]] ; subunits : [[Guide:9x_rationale/rat95-p2-10#5|10.5]] ; syntax : [[Guide:9x_rationale/rat95-p2-1#3|1.3]] ; Systems Programming Annex : [[Guide:9x_rationale/rat95-p3-c|C]] == <span id="t">T</span> == ;tag :[[Guide:9x_rationale/rat95-p1-2#1|II.1,]] [[Guide:9x_rationale/rat95-p2-4#3|4.3]] ;Tag attribute :[[Guide:9x_rationale/rat95-p2-4#3|4.3,]] [[Guide:9x_rationale/rat95-p2-4#5|4.5]] ;tagged types :[[Guide:9x_rationale/rat95-p1-2#1|II.1,]] [[Guide:9x_rationale/rat95-p1-3#3-3|III.3.3,]] [[Guide:9x_rationale/rat95-p2-4|4]] ;task priorities :See [[Guide:9x_rationale/rat95-p2-4|priority]] ;tasks :[[Guide:9x_rationale/rat95-p1-3#4|III.4]] :asynchronous control [[Guide:9x_rationale/rat95-p3-d#11|D.11]] :attributes [[Guide:9x_rationale/rat95-p3-c#6-2|C.6.2]] :and discriminants [[Guide:9x_rationale/rat95-p2-9#6|9.6]] :identification [[Guide:9x_rationale/rat95-p3-c#6-1|C.6.1]] :optimizations [[Guide:9x_rationale/rat95-p3-d#12|D.12]] :restrictions [[Guide:9x_rationale/rat95-p3-d#7|D.7]] :synchronous control [[Guide:9x_rationale/rat95-p3-d#10|D.10]] ;Text_IO :See Ada.Text_IO ;time :[[Guide:9x_rationale/rat95-p3-d#8|D.8]] ;Time_Span (in Ada.Real_Time) :[[Guide:9x_rationale/rat95-p3-d#8-5|D.8.5]] ;type classification :[[Guide:9x_rationale/rat95-p1-3#1-2|III.1.2]] ;type conversion :[[Guide:9x_rationale/rat95-p2-3#8|3.8]] :tagged types [[Guide:9x_rationale/rat95-p2-4#5|4.5]] ;type extension :[[Guide:9x_rationale/rat95-p1-2#4|II.4,]] [[Guide:9x_rationale/rat95-p2-3#6|3.6]] ;types and subtypes :[[Guide:9x_rationale/rat95-p2-3#1|3.1]] == <span id="u">U</span> == ; unbounded length strings : [[Guide:9x_rationale/rat95-p3-a#2-6|A.2.6]] ; Unchecked_Access attribute : [[Guide:9x_rationale/rat95-p2-3#7-1|3.7.1,]] [[Guide:9x_rationale/rat95-p2-6#1-2|6.1.2]] ; underlines : [[Guide:9x_rationale/rat95-p4-y#1|Y.1]] ; understandable program execution : [[Guide:9x_rationale/rat95-p3-h#1|H.1]] ; universal types : [[Guide:9x_rationale/rat95-p2-3#1-1|3.1.1]] ; unsigned types : [[Guide:9x_rationale/rat95-p2-3#3-2|3.3.2]] ; up-level (non-local) references : [[Guide:9x_rationale/rat95-p2-3#7-2|3.7.2,]] [[Guide:9x_rationale/rat95-p2-3#10|3.10]] ; use type clause : [[Guide:9x_rationale/rat95-p1-2#12|II.12,]] [[Guide:9x_rationale/rat95-p2-8#2|8.2]] == <span id="v">V</span> == ; Valid attribute : [[Guide:9x_rationale/rat95-p2-13#3|13.3,]] [[Guide:9x_rationale/rat95-p3-h#1-1|H.1.1]] ; views : [[Guide:9x_rationale/rat95-p1-3#1-2|III.1.2,]] [[Guide:9x_rationale/rat95-p2-3#1|3.1]] : conversion [[Guide:9x_rationale/rat95-p2-4#5|4.5]] ; visibility : [[Guide:9x_rationale/rat95-p2-8#1|8.1]] : character literals [[Guide:9x_rationale/rat95-p2-8#1|8.1]] : child units [[Guide:9x_rationale/rat95-p1-2#8|II.8,]] [[Guide:9x_rationale/rat95-p2-10#1-1|10.1.1]] : subunits [[Guide:9x_rationale/rat95-p2-8#1|8.1]] == <span id="w">W</span> == ; Wide_Character : [[Guide:9x_rationale/rat95-p2-3#2|3.2,]] [[Guide:9x_rationale/rat95-p3-a#1|A.1]] ; Wide_String : [[Guide:9x_rationale/rat95-p2-3#2|3.2,]] [[Guide:9x_rationale/rat95-p3-a#2-4|A.2.4,]] [[Guide:9x_rationale/rat95-p3-a#2-7|A.2.7]] ; Write attribute : [[Guide:9x_rationale/rat95-p3-a#4-1|A.4.1]] <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-references|Previous]] | [[Guide:9x_rationale/rat95-copyright|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale |Displaytitle=Index}} cos0gr9sm8q8xtec8gmeq28lag6t5ml Guide:9x rationale/rat95-p1 4200 326 1893 1849 2019-04-20T16:39:12Z WikiVisor 11 wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-contents|Previous]] | [[Guide:9x_rationale/rat95-p1-1|Next]]</div> ''This first part is designed to give the reader a general appreciation of the overall scope and objectives of Ada 95 and its main technical features. The opening chapter describes the background to the development of the requirements leading to the new standard. The two main chapters give a technical view of the language from two different standpoints: one highlights the main new features such as type extension, the hierarchical library and the protected type and contains many illustrative examples; the other gives a complete overview of the whole language. The reader is recommended to read this first part before attempting to read the Ada 95 Reference Manual.'' <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-contents|Previous]] | [[Guide:9x_rationale/rat95-p1-1|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=Part One. Introduction to Ada 95}} dri67gg29punrd8gobcaad22lvqz9y4 Guide:9x rationale/rat95-p1-1 4200 327 2202 1870 2019-04-20T19:29:18Z WikiVisor 11 wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p1|Previous]] | [[Guide:9x_rationale/rat95-p1-2|Next]]</div> Ada is a modern programming language suitable for those application areas which benefit from the discipline of organized development, that is, Software Engineering; it is a general purpose language with special applicability to real-time and embedded systems. Ada was originally developed by an international design team in response to requirements issued by the United States Department of Defense [DoD 78]. Ada 95 is a revised version of Ada updating the 1983 ANSI Ada standard [ANSI 83] and the equivalent 1987 ISO standard [ISO 87] in accordance with ANSI and ISO procedures. (ANSI is the American National Standards Institute and ISO is the International Standards Organization.) This present document describes the overall Rationale for the revision and includes tutorial information for the new features. == <span id="1"> I.1 The Revision Process </span> == Although Ada was originally designed to provide a single flexible yet portable language for real-time embedded systems to meet the needs of the US DoD, its domain of application has expanded to include many other areas, such as large-scale information systems, distributed systems, scientific computation, and systems programming. Furthermore, its user base has expanded to include all major defense agencies of the Western world, the whole of the aerospace community and increasingly many areas in civil and private sectors such as telecommunications, process control and monitoring systems. Indeed, the expansion in the civil sector is such that civil applications now generate the dominant revenues of many vendors. After some years of use and many implementations, a decision was made in 1988 to undertake a revision to Ada, leading to an updated ANSI/ISO standard. It is normal practice to automatically reconsider such standards every 5 or 10 years and to determine whether they should be abandoned, reaffirmed as they are, or updated. In the case of Ada, an update was deemed appropriate. To understand the process it should be explained that ANSI, as the US national standards body, originally proposed that Ada become an ISO standard. It is normal practice that ANSI, as the originating body, should sponsor a revised standard as necessary. The US DoD acted as the agent of ANSI in managing the development of the revised standard. Within the US DoD, the Ada Joint Program Office (AJPO) is responsible for Ada and the Ada Board is a federal advisory committee which advises the AJPO. The revision effort began in January 1988 when the Ada Board was asked to prepare a recommendation to the AJPO on the most appropriate standardization process to use in developing a revised Ada standard, known in the interim as Ada 9X. The recommendation [DoD 88] was delivered in September 1988 to Virginia Castor, the then Director of the Ada Joint Program Office, who subsequently established the Ada 9X Project for conducting the revision of the Ada Standard. Christine M Anderson was appointed Project Manager in October 1988. Close consultation with ISO was important to ensure that the needs of the whole world-wide Ada community (and not just the defense community) were taken into account and to ensure the timely adoption by ISO of the new standard. Accordingly a Memorandum of Understanding was established between the US DoD and ISO [ISO 90]. The Ada 9X program consists of three main phases: the determination of the Requirements for the revised language; the actual Development of the definition of the revised language; and the Transition into use from Ada 83 to Ada 9X. The output of the Requirements Definition phase was the Ada 9X Requirements document [DoD 90], which specified the revision needs which had to be addressed. The Mapping/Revision phase defined the changes to the standard to meet those requirements; it achieved this in practice of course by defining the new standard. The scope of the changes was guided by the overall objective of the Ada 9X effort [DoD 89a]: <blockquote> Revise ANSI/MIL-STD-1815A-1983 to reflect current essential requirements with minimum negative impact and maximum positive impact to the Ada community. </blockquote> It is probably fair to observe that the changes which were deemed necessary are somewhat greater than might have been foreseen when the project first started in 1988. However, technology and man's understanding do not stand still and the changes now incorporated are very appropriate to the foreseen needs of a modern language for Software Engineering into the 21st Century. == <span id="2"> I.2 The Requirements </span> == The development of the requirements was a somewhat iterative process with a number of sub-phases. First, the community of users was invited to submit Revision Requests, secondly, these were sorted and analyzed in order to determine what was really implied by the requests, and finally, a coherent set of requirements was written. Establishing the level of the requirements needed care. Quite naturally an individual user would often perceive a need in a manner which reflected a symptom of an underlying problem rather than the problem itself. It was very important that the requirements reflected the essence of the problem rather than what might in effect be simply one user's suggested solution to a part of a problem. One reason for this concern was to ensure that better, perhaps deeper and simpler, changes were not excluded by shallow requirements. In some cases a complete understanding of a requirement could not be established and this led to the introduction of Study Topics. As its name implies a Study Topic described an area where something ought to be done but for some reason the feasibility of a solution was in doubt; perhaps the needs were changing rapidly or there were conflicting needs or implementing technology was unstable or it was simply that we had an incomplete understanding of some basic principles. The general goal of the revision was thus to satisfy all of the Requirements and to satisfy as many and as much of the Study Topics as possible. Any unsatisfied Study Topics would be set aside for further consideration for a future Ada 0X (that is the next revision due perhaps around 2005). The requirements document described 41 Requirements and 22 Study Topics. These were divided into a number of chapters which themselves form two broad groups. The first group covered topics of widespread applicability, whereas the second group addressed more specialized topics. The first group consisted of the need to support International Character Sets (originally identified by several nations in the 1987 ISO standardization process), support for Programming Paradigms (Object Orientation was included in this category), Real-Time requirements, requirements for System Programming (such as Unsigned Integers), and General requirements. This last topic included specific matters such as error detection and general considerations of efficiency, simplicity and consistency; examples of a number of individually minor but irritating aspects of Ada 83 which fall into this category were given in an appendix. The second, specialized, group consisted of requirements for Parallel Processing, Distributed Processing, Safety- Critical Applications, Information Systems, and Scientific and Mathematical Applications. The breadth of these specialized requirements raised the specter of a language embracing so many application areas that it would become too costly to implement in its entirety for every architecture. On the other hand, one of the strengths of Ada is its uniformity and the last thing desired was a plethora of uncontrolled subsets. Accordingly, the Requirements document recommended the concept of a Core language plus a small number of Specialized Needs Annexes as a sensible way forward (with emphasis on keeping the number of such annexes very small). All validated compilers would have to implement the Core language and vendors could choose to implement zero, one or more annexes according to the needs of their selected market places. The Requirements document also included general guidance on the approach to be taken to avoid unnecessary disruption to the Ada community. This covered vital matters such as the ease of implementation, object code efficiency, keeping a balance between change and need, and upward compatibility. It finally stressed that support for reliability, safety and long-term maintainability should continue to take precedence over short-term coding convenience. Of all these requirements there was strong emphasis on the overriding goal of upward compatibility in order to preserve existing investment by the Ada community as a whole. == <span id="3"> I.3 The Main User Needs </span> == The Requirements reflected a number of underlying User Needs which had become apparent over the years since Ada was first defined. Apart from a small number of very specific matters such as the character set issue, the specialized areas and generally tidying up minor inconsistencies, four main areas stood out as needing attention: * '''Interfacing'''. Ada 83 recognizes the importance of being able to interface to external systems by the provision of features such as representation clauses and pragmas. Nevertheless, it was sometimes not easy to interface certain Ada 83 programs to other language systems. A general need was felt for a more flexible approach allowing, for instance, the secure manipulation of references and the passing of procedures as parameters. An example arises when interfacing into GUI's where it is often necessary to pass a procedure as a parameter for call-back. * '''Programming by Extension'''. This is closely allied to reusability. Although Ada's package and generic capability are an excellent foundation, nevertheless experience with the OO paradigm in other languages had shown the advantages of being able to extend a program without any modification to existing proven components. Not only does this save disturbing existing software thus eliminating the risk of introducing errors but it also reduces recompilation costs. * '''Program Libraries'''. The Ada program library brings important benefits by extending the strong typing across the boundaries between separately compiled units. However, the flat nature of the Ada 83 library gave problems of visibility control; for example, it prevented two library packages from sharing a full view of a private type. A common consequence of the flat structure was that packages become large and monolithic. This hindered understanding and increased the cost of recompilation. A more flexible and hierarchical structure was necessary. * '''Tasking'''. The Ada rendezvous paradigm is a useful model for the abstract description of many tasking problems. But experience had shown that a more static monitor- like approach was also desirable for common shared-data access applications. Furthermore, the Ada priority model needed revision in order to enable users to take advantage of the greater understanding of scheduling theory which had emerged since Ada 83 was defined. The main changes incorporated into Ada 95 reflect the response to the Requirements in meeting these four key needs while at the same time meeting an overriding need for upward compatibility in order to minimize the effort and cost of transition. == <span id="4"> I.4 The Approach </span> == In responding to the revision requirements, the Revision team followed the inspiration of Jean Ichbiah (who led the original design team), both in remaining faithful to the principles underlying the original Ada design, and in the approach to the revision process. To quote Dr Ichbiah in his introduction to John Barnes' textbook on Ada [Barnes 82]: <blockquote> Clearly, further progress can only come by a reappraisal of implicit assumptions underlying certain compromises. Here is the major contradiction in any design work. On the one hand, one can only reach an harmonious integration of several features by immersing oneself into the logic of the existing parts; it is only in this way that one can achieve a perfect combination. On the other hand, this perception of perfection, and the implied acceptance of certain unconscious assumptions, will prevent further progress. </blockquote> Wherever possible, enhanced functionality in Ada 95 has been achieved by seeking and eliminating such unnecessary assumptions, thereby permitting the generalization of features already in Ada, and the removal of special cases and restrictions. A careful analysis was made of Ada 83, of language study notes prepared during the original design process and of the many Ada Issues and other comments that have since been received. Based on this analysis, and on the Ada community's experience in implementing and using Ada during the past ten years, the team identified limitations that, while they were included to simplify implementations and/or to lower risk when the language was first standardized, are no longer necessary. They also drew upon the wealth of practical experience gained during the 1980's in the use of object-oriented design methods, object- oriented programming languages, and real-time programming made possible by Ada. The resulting Ada 95 revision is upwardly compatible for virtually all existing Ada 83 applications. Most incompatibilities are restricted to pathological combinations of features that are rarely used in practice. Total upward compatibility would not have allowed the correction of certain errors and certainly would not have allowed the enhancements needed to satisfy many of the requirements. Indeed, as discussed in Appendix A in more detail, no language revision has ever achieved total upward compatibility. The careful attention to this issue in the design of Ada 95 means that the expected transition costs for existing Ada programs are anticipated to be very low indeed. Following the guidance of the Requirements document, Ada 95 comprises a Core language, which must be implemented in its entirety, plus several Specialized Needs Annexes which provide extended features for specific application areas. These Annexes provide standard definitions for application- specific packages, pragmas, attributes, and capacity and performance characteristics of implementations. The Annexes address the following areas: Systems Programming, Real-Time Systems, Distributed Systems, Information Systems, Numerics, and Safety and Security. It should be noted that the Core language includes a considerably extended predefined environment covering important functionality such as mathematical functions and string handling. Much of the functionality of this predefined environment and the specialized annexes is already provided by implementations of Ada 83 but in non- standard ways; providing this within the standard will thus increase portability between implementations. == <span id="5"> I.5 Using this Document </span> == This document provides a description of the main features of Ada 95 and the rationale for the changes from Ada 83. It follows the inspiration of the rationale for Ada 83 [IBFW 86] by blending exposition with explanation. It is in four parts, this first part is designed to give the reader a general appreciation for the scope and objectives of Ada 95 and its major features. Chapter II highlights the main changes - primarily the four key areas outlined in I.3. The intent is to provide a technically oriented management overview illustrating, with examples, the prime benefits of Ada 95 with respect to Ada 83. By contrast, Chapter III provides an overview of the whole language in a discursive style and introduces new terminology where appropriate. The second and third parts take the discussion a step further. The second part covers the Core language per se; it addresses those important features not discussed in this first part and gives more detail of the rationale including alternatives that were considered and rejected. The third part similarly addresses the predefined environment and the various Specialized Needs Annexes. Finally the fourth part contains three appendices. Appendix X summarizes the incompatibilities thereby giving guidance to existing Ada 83 programmers in order to smooth their transition to Ada 95. Appendix Y summarizes the main differences between the final International Standard (which this edition of the rationale describes) and the previous two drafts, the Draft International Standard [DIS 94] and the Committee Draft [CD 93]. Appendix Z summarizes the original requirements and briefly analyzes how they have been met by Ada 95. It is generally assumed that the reader is familiar with Ada 83. This first part should be read before approaching the Ada 95 Reference Manual [RM95] which should then be read in parallel with Parts Two and Three. It should also be noted that the general intent of all parts of this document is to address the broad picture. The rationale for minute detail is admirably addressed in the Annotated Ada 95 Reference Manual [AARM] which is a version of [RM95] including embedded non-normative discussion mainly of interest to language experts and compiler writers. The chapters in this first part have Roman numbers; the chapters in Parts Two and Three have numbers and letters essentially corresponding to the sections and annexes of [RM 95]. The appendices in Part Four are called X, Y and Z to avoid confusion with the annex chapters. All chapters thus have a unique identifier for ease of cross reference. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p1|Previous]] | [[Guide:9x_rationale/rat95-p1-2|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=I Evolution of Ada 95}} b6ayd693km03xpk191qi5vzpmwse7rm Guide:9x rationale/rat95-p1-2 4200 328 2583 1882 2019-04-23T20:41:57Z WikiVisor 11 wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p1-1|Previous]] | [[Guide:9x_rationale/rat95-p1-3|Next]]</div> The brightest highlights of Ada 95 are its inherent reliability and its ability to provide abstraction through the package and private type. These features already exist in Ada 83 and so in a real sense Ada 83 already contains the best of Ada 95. Indeed, Ada 83 is already a very good language. However, time and technology do not stand still, and Ada 95 is designed to meet increased requirements which have arisen from three directions. These are: feedback from the use of existing paradigms; additional market requirements to match evolving hardware capability; and increased fundamental understanding which has introduced new paradigms. As we will see, Ada 95 follows on from the tradition of excellence of Ada 83 and meets these additional requirements in an outstanding manner. One of the great strengths of Ada 83 is its reliability. The strong typing and related features ensure that programs contain few surprises; most errors are detected at compile time and of those remaining many are detected by runtime constraints. This aspect of Ada considerably reduces the costs and risks of program development compared for example with C or its derivatives such as C++. However, Ada 83 has proved to be somewhat less flexible than might be desired in some circumstances. For example, it has not always proved straightforward to interface to non-Ada systems. Moreover, the type model coupled with the flat library mechanism can cause significant costs through the need for apparently unnecessary recompilation. A prime goal of the design of Ada 95 has thus been to give the language a more open and extensible feel without losing the inherent integrity and efficiency of Ada 83. That is to keep the Software Engineering but allow more flexibility. The additions in Ada 95 which contribute to this more flexible feel are type extension, the hierarchical library and the greater ability to manipulate pointers or references. As a consequence, Ada 95 incorporates the benefits of Object Oriented languages without incurring the pervasive overheads of languages such as SmallTalk or the insecurity brought by the weak C foundation in the case of C++. Ada 95 remains a very strongly typed language but provides the prime benefits of all key aspects of the Object Oriented paradigm. Another area of major change in Ada 95 is in the tasking model where the introduction of protected types allows a more efficient implementation of standard problems of shared data access. This brings the benefits of speed provided by low-level primitives such as semaphores without the risks incurred by the use of such unstructured primitives. Moreover, the clearly data-oriented view brought by the protected types fits in naturally with the general spirit of the Object Oriented paradigm. Other improvements to the tasking model allow a more flexible response to interrupts and other changes of state. Ada 95 also incorporates numerous other minor changes reflecting feedback from the use of existing features as well as specific new features addressing the needs of specialized applications and communities. This chapter highlights the major new features of Ada 95 and the consequential benefits as seen by the general Ada user. == <span id="1"> II.1 Programming by Extension </span> == The key idea of programming by extension is the ability to declare a new type that refines an existing parent type by inheriting, modifying or adding to both the existing components and the operations of the parent type. A major goal is the reuse of existing reliable software without the need for recompilation and retesting. Type extension in Ada 95 builds upon the existing Ada 83 concept of a derived type. In Ada 83, a derived type inherited the operations of its parent and could add new operations; however, it was not possible to add new components to the type. The whole mechanism was thus somewhat static. By contrast, in Ada 95 a derived type can also be extended to add new components. As we will see, the mechanism is much more dynamic and allows greater flexibility through late binding and polymorphism. In Ada 95, record types may be extended on derivation provided that they are marked as tagged. Private types implemented as record types can also be marked as tagged. As the name implies, a tagged type has an associated tag. The word tag is familiar from Pascal where it is used to denote what in Ada is known as a discriminant; as we shall see later, the Ada 95 tag is effectively a hidden discriminant identifying the type and so the term is very appropriate. As a very simple example suppose we wish to manipulate various kinds of geometrical objects which form some sort of hierarchy. All objects will have a position given by their x- and y-coordinates. So we can declare the root of the hierarchy as <syntaxhighlight lang="Ada"> type Object is tagged record X_Coord: Float; Y_Coord: Float; end record;</syntaxhighlight> The other types of geometrical objects will be derived (directly or indirectly) from this type. For example we could have <syntaxhighlight lang="Ada"> type Circle is new Object with record Radius: Float; end record;</syntaxhighlight> and the type Circle then has the three components X_Coord, Y_Coord and Radius. It inherits the two coordinates from the type Object and the component Radius is added explicitly. Sometimes it is convenient to derive a new type without adding any further components. For example <syntaxhighlight lang="Ada"> type Point is new Object with null record;</syntaxhighlight> In this last case we have derived Point from Object but naturally not added any new components. However, since we are dealing with tagged types we have to explicitly add with null record; to indicate that we did not want any new components. This has the advantage that it is always clear from a declaration whether a type is tagged or not. Note that tagged is of course a new reserved word; Ada 95 has a small number (six) of such new reserved words. A private type can also be marked as tagged <syntaxhighlight lang="Ada"> type Shape is tagged private;</syntaxhighlight> and the full type declaration must then (ultimately) be a tagged record <syntaxhighlight lang="Ada"> type Shape is tagged record ...</syntaxhighlight> or derived from a tagged record such as Object. On the other hand we might wish to make visible the fact that the type Shape is derived from Object and yet keep the additional components hidden. In this case we would write <syntaxhighlight lang="Ada"> package Hidden_Shape is type Shape is new Object with private; -- client view ... private type Shape is new Object with -- server view record -- the private components end record; end Hidden_Shape;</syntaxhighlight> In this last case it is not necessary for the full declaration of Shape to be derived directly from the type Object. There might be a chain of intermediate derived types (it could be derived from Circle); all that matters is that Shape is ultimately derived from Object. Just as in Ada 83, derived types inherit the operations which "belong" to the parent type - these are called primitive operations in Ada 95. User-written subprograms are classed as primitive operations if they are declared in the same package specification as the type and have the type as parameter or result. Thus we might have declared a function giving the distance from the origin <syntaxhighlight lang="Ada"> function Distance(O: in Object) return Float is begin return Sqrt(O.X_Coord**2 + O.Y_Coord**2); end Distance;</syntaxhighlight> The type Circle would then sensibly inherit this function. If however, we were concerned with the area of an object then we might start with <syntaxhighlight lang="Ada"> function Area(O: in Object) return Float is begin return 0.0; end Area;</syntaxhighlight> which returns zero since a raw object has no area. This would also be inherited by the type Circle but would be inappropriate; it would be more sensible to explicitly declare <syntaxhighlight lang="Ada"> function Area(C: in Circle) return Float is begin return Pi*C.Radius**2; end Area;</syntaxhighlight> which will override the inherited operation. It is possible to "convert" a value from the type Circle to Object and vice versa. From circle to object is easy, we simply write <syntaxhighlight lang="Ada"> O: Object := (1.0, 0.5); C: Circle := (0.0, 0.0, 12.2); ... O := Object(C);</syntaxhighlight> which effectively ignores the third component. However, conversion in the other direction requires the provision of a value for the extra component and this is done by an extension aggregate thus <syntaxhighlight lang="Ada"> C := (O with 46.8);</syntaxhighlight> where the expression O is extended after with by the values of the extra components written just as in a normal aggregate. In this case we only had to give a value for the radius. We now consider a more practical example which illustrates the use of tagged types to build a system as a hierarchy of types and packages. We will see how this allows the system to be extended without recompilation of the central part of the system. By way of illustration we start by showing the rigid way this had to be programmed in Ada 83 by the use of variants. Our system represents the processing of alerts (alarms) in a ground mission control station. Alerts are of three levels of priority. Low level alerts are merely logged, medium level alerts cause a person to be assigned to deal with the problem and high level alerts cause an alarm bell to ring if the matter is not dealt with by a specified time. In addition, a message is displayed on various devices according to its priority. First consider how this might have be done in Ada 83 <syntaxhighlight lang="Ada"> with Calendar; package Alert_System is type Priority is (Low, Medium, High); type Device is (Teletype, Console, Big_Screen); type Alert(P: Priority) is record Time_Of_Arrival: Calendar.Time; Message: Text; case P is when Low => null; when Medium | High => Action_Officer: Person; case P is when Low | Medium => null; when High => Ring_Alarm_At: Calendar.Time; end case; end case; end record; procedure Display(A: in Alert; On: in Device); procedure Handle(A: in out Alert); procedure Log(A: in Alert); procedure Set_Alarm(A: in Alert); end Alert_System;</syntaxhighlight> Each alert is represented as a discriminated record with the priority as the discriminant. Perhaps surprisingly, the structure and processing depend on this discriminant in a quite complex manner. One immediate difficulty is that we are more or less obliged to use nested variants because of the rule that all the components of a record have to have different identifiers. The body of the procedure Handle might be <syntaxhighlight lang="Ada"> procedure Handle(A: in out Alert) is begin A.Time_Of_Arrival := Calendar.Clock; Log(A); Display(A, Teletype); case A.P is when Low => null; -- nothing special when Medium | High => A.Action_Officer := Assign_Volunteer; Display(A, Console); case A.P is when Low | Medium => null; when High => Display(A, Big_Screen); Set_Alarm(A); end case; end case; end Handle;</syntaxhighlight> One problem with this approach is that the code is curiously complex due to the nested structure and consequently hard to maintain and error-prone. If we try to avoid the nested case statement then we have to repeat some of the code. A more serious problem is that if, for example, we need to add a further alert category, perhaps an emergency alert (which would mean adding another value to the type Priority), then the whole system will have to be modified and recompiled. Existing reliable code will then be disturbed with the risk of subsequent errors. In Ada 95 we can use a series of tagged types with a distinct procedure Handle for each one. This completely eliminates the need for case statements or variants and indeed the type Priority itself is no longer required because it is now inherent in the types themselves (it is implicit in the tag). The package specification now becomes <syntaxhighlight lang="Ada"> with Calendar; package New_Alert_System is type Device is (Teletype, Console, Big_Screen); type Alert is tagged record Time_Of_Arrival: Calendar.Time; Message: Text; end record; procedure Display(A: in Alert; On: in Device); procedure Handle(A: in out Alert); procedure Log(A: in Alert); type Low_Alert is new Alert with null record; type Medium_Alert is new Alert with record Action_Officer: Person; end record; -- now override inherited operation procedure Handle(MA: in out Medium_Alert); type High_Alert is new Medium_Alert with record Ring_Alarm_At: Calendar.Time; end record; procedure Handle(HA: in out High_Alert); procedure Set_Alarm(HA: in High_Alert); end New_Alert_System;</syntaxhighlight> In this formulation the variant record is replaced with the tagged type Alert and three types derived from it. Note that Ada 95 allows a type to be derived in the same package specification as the parent and to inherit all the primitive operations but we cannot add any new primitive operations to the parent after a type has been derived from it. This is different to Ada 83 where the operations were not derivable until after the end of the package specification. This change allows the related types to be conveniently encapsulated all in the same package. The type Low_Alert is simply a copy of Alert (note with null record;) and could be dispensed with although it maintains equivalence with the Ada 83 version; Low_Alert inherits the procedure Handle from Alert. The type Medium_Alert extends Alert and provides its own procedure Handle thus overriding the inherited version. The type High_Alert further extends Medium_Alert and similarly provides its own procedure Handle. Thus instead of a single procedure Handle containing complex case statements the Ada 95 solution distributes the logic for handling alerts to each specific alert type without any redundancy. Note that Low_Alert, Medium_Alert and High_Alert all also inherit the procedures Display and Log but without change. Finally, High_Alert adds the procedure Set_Alarm which is not used by the lower alert levels and thus it seems inappropriate to declare it for them. The package body is as follows <syntaxhighlight lang="Ada"> package body New_Alert_System is procedure Handle(A: in out Alert) is begin A.Time_Of_Arrival := Calendar.Clock; Log(A); Display(A, Teletype); end Handle; procedure Handle(MA: in out Medium_Alert) is begin Handle(Alert(MA)); -- handle as plain alert MA.Action_Officer := Assign_Volunteer; Display(MA, Console); end Handle; procedure Handle(HA: in out High_Alert) is begin Handle(Medium_Alert(HA)); -- conversion Display(HA, Big_Screen); Set_Alarm(HA); end Handle; procedure Display(A: in Alert; On: in Device) is separate; procedure Log(A: in Alert) is separate; procedure Set_Alarm(HA: in High_Alert) is separate; end New_Alert_System;</syntaxhighlight> Each distinct body for Handle contains just the code relevant to the type and delegates additional processing back to its parent using an explicit type conversion. Note carefully that all type checking is static and so no runtime penalties are incurred with this structure (the variant checks have been avoided). In the Ada 95 model a new alert level (perhaps Emergency_Alert) can be added without recompilation (and perhaps more importantly, without retesting) of the existing code. <syntaxhighlight lang="Ada"> with New_Alert_System; package Emergency_Alert_System is type Emergency_Alert is new New_Alert_System.Alert with private; procedure Handle(EA: in out Emergency_Alert); procedure Display(EA: in Emergency_Alert; On: in New_Alert_System.Device); procedure Log(EA: in Emergency_Alert); private ... end Emergency_Alert_System;</syntaxhighlight> In the Ada 83 model extensive recompilation would have been necessary since the variant records would have required redefinition. Thus we see that Ada 95 truly provides Programming by Extension. == <span id="2"> II.2 Class Wide Programming </span> == The facilities we have seen so far have allowed us to define a new type as an extension of an existing one. We have introduced the different kinds of alerts as distinct but related types. What we also need is a means to manipulate any kind of alert and to process it accordingly. We do this through the introduction of the notion of class-wide types. With each tagged type T there is an associated type T'Class. This type comprises the union of all the types in the tree of derived types rooted at T. The values of T'Class are thus the values of T and all its derived types. Moreover a value of any type derived from T can be implicitly converted to the type T'Class. Thus in the case of the type Alert the tree of types is as shown in Figure II-1. <syntaxhighlight lang="Ada"> Alert | | +--------------+----------------+ | | | Low_Alert | Emergency_Alert | | Medium_Alert | | High_Alert Figure II-1: A Tree of Types</syntaxhighlight> A value of any of the alert types can be implicitly converted to Alert'Class. Note carefully that Medium_Alert'Class is not the same as Alert'Class; the former consists just of Medium_Alert and High_Alert. Each value of a class-wide type has a tag which identifies its particular type from other types in the tree of types at runtime. It is the existence of this tag which gives rise to the term tagged types. The type T'Class is treated as an unconstrained type; this is because we cannot possibly know how much space could be required by any value of a class-wide type because the type might be extended. As a consequence, although we can declare an object of a class-wide type we must initialize it and it is then constrained by the tag. However, we can declare an access type referring to a class-wide type in which case the access could designate any value of the class-wide type from time to time. The use of access types is therefore a key factor in class-wide programming. Moreover, a parameter of a procedure can also be of a class-wide type. There is a strong analogy between class-wide types and other unconstrained types such as array types. We can now continue our example by considering how we might buffer up a series of alerts and process them in sequence. The whole essence of the problem is that such a central routine cannot know of the individual types because we need it to work (without recompilation) even if we extend the system by adding a new alert type to it. The central routine could thus take a class-wide value as its parameter so we might have <syntaxhighlight lang="Ada"> procedure Process_Alerts(AC: in out Alert'Class) is ... begin ... Handle(AC); -- dispatch according to tag ... end Process_Alerts;</syntaxhighlight> In this case we do not know which procedure Handle to call until runtime because we do not know which specific type the alert belongs to. However, AC is of a class-wide type and so its value includes a tag indicating the specific type of the value. The choice of Handle is then determined by the value of this tag; the parameter is then implicitly converted to the appropriate specific alert type before being passed to the appropriate procedure Handle. This runtime choice of procedure is called dispatching and is key to the flexibility of class-wide programming. Before being processed, the alerts might be held on a heterogeneous queue using an access type <syntaxhighlight lang="Ada"> type Alert_Ptr is access Alert'Class;</syntaxhighlight> and the central routine could manipulate the alerts directly from such a queue <syntaxhighlight lang="Ada"> procedure Process_Alerts is Next_Alert: Alert_Ptr; begin ... Next_Alert := -- get next alert ... Handle(Next_Alert.all); -- dispatch to appropriate Handle ... end Process_Alerts;</syntaxhighlight> In this case, the value of the object referred to by Next_Alert is of a class-wide type and so includes a tag indicating the specific type. The parameter Next_Alert.all is thus dereferenced, the value of the tag gives the choice of Handle and the parameter is then implicitly converted as before and then passed to the chosen procedure Handle. Dispatching may be implemented as a simple indirect jump through a table of subprograms indexed by the primitive operations such as Handle. This is generally much more efficient than the alternative of variant records and case statements, with their attendant variant checks. == <span id="3"> II.3 Abstract Types and Subprograms </span> == The final topic to be introduced in this brief introduction to the Object Oriented features of Ada 95 is the concept of abstract tagged types and abstract subprograms. These are marked as abstract in their declaration. The purpose of an abstract type is to provide a common foundation upon which useful types can be built by derivation. An abstract subprogram is a sort of place holder for an operation to be provided (it does not have a body). An abstract tagged type can have abstract primitive subprograms and these dispatch. An abstract type on its own is of little use because we cannot declare an object of an abstract type. Upon derivation from an abstract type we can provide actual subprograms for the abstract subprograms of the parent type (and it is in this sense that we said they were place holders). If all the abstract subprograms are replaced by proper subprograms then the type need not be declared as abstract and we can then declare objects of the type in the usual way. (The rules ensure that dispatching always works.) Returning now to our example of processing alerts we could reformulate this so that the root type Alert was just an abstract type and then build the specific types upon this. This would enable us to program and compile all the general infrastructure routines for processing all alerts such as Process_Alerts in the previous section without any concern at all for the individual alerts and indeed before deciding what they should contain. The baseline package could then simply become <syntaxhighlight lang="Ada"> package Base_Alert_System is type Alert is abstract tagged null record; procedure Handle(A: in out Alert) is abstract; end Base_Alert_System;</syntaxhighlight> in which we declare the type Alert as a tagged null record with just the procedure Handle as an abstract subprogram; this does not have a body. (Note the abbreviated form for a null record declaration which saves us having to write record null; end record;) We can now develop our alert infrastructure and then later add the normal alert system containing the three levels of alerts thus <syntaxhighlight lang="Ada"> with Calendar; with Base_Alert_System; package Normal_Alert_System is type Device is (Teletype, Console, Big_Screen); type Low_Alert is new Base_Alert_System.Alert with record Time_Of_Arrival: Calendar.Time; Message: Text; end record; -- now provide actual subprogram for abstract one procedure Handle(LA: in out Low_Alert); procedure Display(LA: in Low_Alert; On: in Device); procedure Log(LA: in Low_Alert); type Medium_Alert is new Low_Alert with record Action_Officer: Person; end record; procedure Handle(MA: in out Medium_Alert); type High_Alert is new Medium_Alert with record Ring_Alarm_At: Calendar.Time; end record; procedure Handle(HA: in out High_Alert); procedure Set_Alarm(HA: in High_Alert); end Normal_Alert_System;</syntaxhighlight> In this revised formulation we must provide a procedure Handle for Low_Alert to meet the promise of the abstract type. The procedures Display and Log now take a parameter of Low_Alert and the type Medium_Alert is more naturally derived from Low_Alert. Note carefully that we did not make Display and Log abstract subprograms in the package Base_Alert_System. There was no need; it is only Handle that is required by the general infrastructure such as the procedure Process_Alerts and to add the others would weaken the abstraction and clutter the base level. Corresponding changes are required to the package body; the procedure Handle previously applying to Alert now applies to Low_Alert and in the procedure Handle for Medium_Alert we need to change the type conversion in the call to the "parent" Handle which is of course now the procedure Handle for Low_Alert. The two procedures thus become <syntaxhighlight lang="Ada"> procedure Handle(LA: in out Low_Alert) is begin LA.Time_Of_Arrival := Calendar.Clock; Log(LA); Display(LA, Teletype); end Handle; procedure Handle(MA: in out Medium_Alert) is begin Handle(Low_Alert(MA)); -- handle as low alert MA.Action_Officer := Assign_Volunteer; Display(MA, Console); end Handle;</syntaxhighlight> When we now add our Emergency_Alert we can choose to derive this from the baseline Alert as before or perhaps from some other point in the tree picking up the existing facilities of one of the other levels. == <span id="4"> II.4 Summary of Type Extension </span> == The key points we have seen are as follows. Ada 95 introduces the notion of tagged types. Only record (and private) types can be tagged. Values of tagged types carry a tag with them. The tag indicates the specific type. A tagged type can be extended on derivation with additional components. Primitive operations of a type are inherited on derivation. The primitive operations are those implicitly declared, plus, in the case of a type declared in a package specification, all subprograms with a parameter or result of that type also declared in the package specification. Primitive operations can be overridden on derivation and further ones added. A tagged type can be declared as abstract and can have abstract primitive subprograms. An abstract subprogram does not have a body but one can be provided on derivation. An abstract type provides a foundation for building specific types with some common protocol. T'Class denotes the class-wide type rooted at T. Implicit conversion is allowed to values of T'Class. Objects and parameters of T'Class are treated as unconstrained. An appropriate access type can designate any value of T'Class. Calling a primitive operation with an actual parameter of a class-wide type results in dispatching: that is the runtime selection of the operation according to the tag. This is often called late binding - a key property of Object Oriented languages. Another term commonly encountered is polymorphism. Class-wide types are said to be polymorphic because their values are of different "shapes" (from the Greek poly, many, and morphe, form). Polymorphism is another property of Object Oriented languages. One of the main advantages of type extension is that it can be done without recompiling and retesting an existing stable system. This is perhaps the most important overall characteristic of Object Oriented languages. == <span id="5"> II.5 Dynamic Selection </span> == In the previous section we mentioned late binding; this simply means that the procedure to be called is identified late in the compile-link-run process. All procedure calls were bound early in Ada 83 and this was one reason why the language felt so static; even the generic mechanism only deferred binding to instantiation which is still essentially a compile time process. There were a number of reasons for taking such a static approach in Ada 83. There was concern for the implementation cost of dynamic binding, it was also clear that the presence of dynamic binding would reduce the provability of programs, and moreover it was felt that the introduction of generics where subprograms could be passed as parameters would cater for practical situations where formal procedure parameters were used in other languages. However, the absence of dynamic binding in Ada 83 has been unfortunate. It is now realized that implementation costs are trivial and not necessarily pervasive; provability is not a relevant argument because we now know that in any safety-critical software where mathematical provability is a real issue, we only use a small subset of the language. And furthermore, the generic mechanism has proved not to be a sufficiently flexible alternative anyway. We have seen how dispatching in Ada 95 is one mechanism for late binding. Another is provided by the manipulation of subprogram values through an extension of access types. In Ada 95 an access type can refer to a subprogram; an access-to-subprogram value can be created by the Access attribute and a subprogram can be called indirectly by dereferencing such an access value. Thus we can write <syntaxhighlight lang="Ada"> type Trig_Function is access function(F: Float) return Float; T: Trig_Function; X, Theta: Float;</syntaxhighlight> and T can then "point to" functions such as Sin, Cos and Tan. We can then assign an appropriate access-to-subprogram value to T by for example <syntaxhighlight lang="Ada"> T := Sin'Access;</syntaxhighlight> and later indirectly call the subprogram currently referred to by T as expected <syntaxhighlight lang="Ada"> X := T(Theta);</syntaxhighlight> which is really an abbreviation for <syntaxhighlight lang="Ada"> X := T.all(Theta);</syntaxhighlight> Just as with many other uses of access types the .all is not usually required but it would be necessary if there were no parameters. The access to subprogram mechanism can be used to program general dynamic selection and to pass subprograms as parameters. It allows program call-back to be implemented in a natural and efficient manner. There are a number of rules which ensure that access to subprogram values cannot be misused. Conformance matching ensures that the subprogram always has the correct number and type of parameters and there are rules about accessibility that ensure that a subprogram is not called out of context. Flexibility is thus gained without loss of integrity. Simple classic numerical algorithms can now be implemented in Ada 95 in the same way as in languages such as Fortran but with complete security. Thus an integration routine might have the following specification <syntaxhighlight lang="Ada"> type Integrand is access function(X: Float) return Float; function Integrate(F: Integrand; From, To: Float; Accuracy: Float := 1.0E-7) return Float;</syntaxhighlight> and we might then write <syntaxhighlight lang="Ada"> Area := Integrate(Log'Access, 1.0, 2.0);</syntaxhighlight> which will compute the area under the curve for log(x) from 1.0 to 2.0. Within the body of the function Integrate there will be calls of the actual subprogram passed as a parameter; this is a simple form of call-back. A common paradigm within the process industry is to implement sequencing control through successive calls of a number of interpreter actions. A sequence compiler might interactively build an array of such actions which are then obeyed. Thus we might have <syntaxhighlight lang="Ada"> type Action is access procedure; Action_Sequence: array(1 .. N) of Action; ... -- build the array -- and then obey it for I in Action_Sequence'Range loop Action_Sequence(I).all; end loop;</syntaxhighlight> It is of course possible for a record (possibly private) to contain components whose types are access to subprogram types. Consider the following example of a package which provides facilities associated with the actions obtained when we press keys on our keyboard or perhaps click our mouse on a window button. <syntaxhighlight lang="Ada"> package Push_Buttons is type Button is private; type Button_Response is access procedure(B: in out Button); function Create(...) return Button; procedure Push(B: in out Button); procedure Set_Response(B: in out Button; R: in Button_Response); procedure Default_Response(B: in out Button); ... private type Button is record Response: Button_Response := Default_Response'Access; ... -- other aspects of the button end record; end Push_Buttons;</syntaxhighlight> A button is represented as a private record containing a number of components describing properties of the button (position on screen for example). One component is an access to a procedure which is the action to be executed when the button is pushed. Note carefully that the button value is passed to this procedure as a parameter so that the procedure can obtain access to the other components of the record describing the button. The procedure Create fills in these other components and other functions (not shown) provide access to them. The procedure Push invokes the action of clicking the mouse and an appropriate default procedure is provided which warns the user if the button has not been set. The body might be as follows <syntaxhighlight lang="Ada"> package body Push_Buttons is procedure Push(B: in out Button) is begin B.Response(B); -- indirect call end Push; procedure Set_Response(B: in out Button; R: in Button_Response) is begin B.Response := R; -- set procedure value in record end Set_Response; procedure Default_Response(B: in out Button) is begin Put("Button not set"); Monitor.Beep; end Default_Response; ... end Push_Buttons;</syntaxhighlight> We can now set the specific actions we want when a button is pushed. Thus we might want some emergency action to take place when a big red button is pushed. <syntaxhighlight lang="Ada"> Big_Red_Button: Button; procedure Emergency(B: in out Button) is begin -- call fire brigade etc end Emergency; ... Set_Response(Big_Red_Button, Emergency'Access); ... Push(Big_Red_Button);</syntaxhighlight> The reader will realize that the access to subprogram mechanism coupled with the inheritance and dispatching facilities described earlier enable very flexible yet secure dynamic structures to be programmed. == <span id="6"> II.6 Other Access Types </span> == We have just seen how access types in Ada 95 have been extended to provide a means of manipulating subprogram values. Access types have also been extended to provide more flexible access to objects. In Ada 83, access values could only refer to objects dynamically created through the allocator mechanism (using new). It was not possible to access objects declared in the normal way. This approach was inherited from Pascal which had similar restrictions and was a reaction against the very flexible approach adopted by Algol 68 and C which can give rise to dangerous dangling references. However, the ability to manipulate pointers is very valuable provided the risks can be overcome. The view taken by Ada 83 has proved unnecessarily inflexible, especially when interfacing to external systems possibly written in other languages. In Ada 95 we can declare a general access type such as <syntaxhighlight lang="Ada"> type Int_Ptr is access all Integer;</syntaxhighlight> and we can then assign the "address" of any variable of type Integer to a variable of type Int_Ptr provided that the designated variable is marked as aliased. So we can write <syntaxhighlight lang="Ada"> IP: Int_Ptr; I: aliased Integer; ... IP := I'Access;</syntaxhighlight> and we can then read and update the variable I through the access variable IP. Note once more the use of 'Access. Note also that aliased is another new reserved word. As with access to subprogram values there are rules that (at compile time) ensure that dangling references cannot arise. A variation is that we can restrict the access to be read-only by replacing all in the type definition by constant. This allows read-only access to any variable and also to a constant thus <syntaxhighlight lang="Ada"> type Const_Int_Ptr is access constant Integer; CIP: Const_Int_Ptr; I: aliased Integer; C: aliased constant Integer := 1815;</syntaxhighlight> followed by <syntaxhighlight lang="Ada"> CIP := I'Access; -- access to a variable, or CIP := C'Access; -- access to a constant</syntaxhighlight> The type accessed by a general access type can of course be any type such as an array or record. We can thus build chains from records statically declared. Note that we can also use an allocator to generate general access values. Our chain could thus include a mixture of records from both storage mechanisms. Finally note that the accessed object could be a component of a composite type. Thus we could point into the middle of a record (provided the component is marked as aliased). In a fast implementation of Conway's Game of Life a cell might contain access values directly referencing the component of its eight neighbors containing the counter saying whether the cell is alive or dead. <syntaxhighlight lang="Ada"> type Ref_Count is access constant Integer range 0 .. 1; type Ref_Count_Array is array (Integer range <>) of Ref_Count; type Cell is record Life_Count: aliased Integer range 0 .. 1; Total_Neighbor_Count: Integer range 0 .. 8; Neighbor_Count: Ref_Count_Array(1 .. 8); ... end record;</syntaxhighlight> We can now link the cells together according to our model by statements such as <syntaxhighlight lang="Ada"> This_Cell.Neighbor_Count(1) := Cell_To_The_North.Life_Count'Access;</syntaxhighlight> and then the heart of the computation which computes the sum of the life counts in the neighbors might be <syntaxhighlight lang="Ada"> C.Total_Neighbor_Count := 0; for I in C.Neighbor_Count'Range loop C.Total_Neighbor_Count := C.Total_Neighbor_Count + C.Neighbor_Count(I).all; end loop;</syntaxhighlight> Observe that we have given the type Ref_Count and the component Life_Count the same static subtypes so that they can be checked at compile time; this is not essential but avoids a run-time check that would otherwise be required if they did not statically match. General access types can also be used to program static ragged arrays as for example a table of messages of different lengths. The key to this is that the accessed type can be unconstrained (such as String) and thus we can have an array of pointers to strings of different lengths. In Ada 83 we would have had to allocate all the strings dynamically using an allocator. In conclusion we have seen how the access types of Ada 83 have been considerably enhanced in Ada 95 to allow much more flexible programming which is especially important in open systems while nevertheless retaining the inherent security missing in languages such as C and C++. == <span id="7"> II.7 Hierarchical Libraries </span> == One of the great strengths of Ada is the library package where the distinct specification and body decouple the user interface to a package (the specification) from its implementation (the body). This enables the details of the implementation and the clients to be recompiled separately without interference provided the specification remains stable. However, although this works well for smallish programs it has proved cumbersome when programs become large or complex. There are two aspects of the problem: the coarse control of visibility of private types and the inability to extend without recompilation. There are occasions when we wish to write two logically distinct packages which nevertheless share a private type. We could not do this in Ada 83. We either had to make the type not private so that both packages could see it with the unfortunate consequence that all the client packages could also see the type; this broke the abstraction. Or, on the other hand, if we wished to keep the abstraction, then we had to merge the two packages together and this resulted in a large monolithic package with increased recompilation costs. (We discount as naughty the use of tricks such as Unchecked_Conversion to get at the details of private types.) The other aspect of the difficulty arose when we wished to extend an existing system by adding more facilities to it. If we add to a package specification then naturally we have to recompile it but moreover we also have to recompile all existing clients even if the additions have no impact upon them. In Ada 95 these and other similar problems are solved by the introduction of a hierarchical library structure containing child packages and child subprograms. There are two kinds of children: public children and private children. We will just consider public children for the moment; private children are discussed in the next section. Consider first the familiar example of a package for the manipulation of complex numbers. It might contain the private type itself plus the four standard operations and also subprograms to construct and decompose a complex number taking a cartesian view. Thus we might have <syntaxhighlight lang="Ada"> package Complex_Numbers is type Complex is private; function "+" (Left, Right: Complex) return Complex; ... -- similarly "-", "*" and "/" function Cartesian_To_Complex(Real, Imag: Float) return Complex; function Real_Part(X: Complex) return Float; function Imag_Part(X: Complex) return Float; private ... end Complex_Numbers;</syntaxhighlight> We have deliberately not shown the completion of the private type since it is immaterial how it is implemented. Although this package gives the user a cartesian view of the type, nevertheless it certainly does not have to be implemented that way. Some time later we might need to additionally provide a polar view by the provision of subprograms which construct and decompose a complex number from and to its polar coordinates. In Ada 83 we could only do this by adding to the existing package and this forced us to recompile all the existing clients. In Ada 95, however, we can add a child package as follows <syntaxhighlight lang="Ada"> package Complex_Numbers.Polar is function Polar_To_Complex(R, Theta: Float) return Complex; function "abs" (Right: Complex) return Float; function Arg(X: Complex) return Float; end Complex_Numbers.Polar;</syntaxhighlight> and within the body of this package we can access the private type Complex itself. Note the notation, a package having the name P.Q is a child package of its parent package P. We can think of the child package as being declared inside the declarative region of its parent but after the end of the specification of its parent; most of the visibility rules stem from this model. In other words the declarative region defined by the parent (which is primarily both the specification and body of the parent) also includes the space occupied by the text of the children; but it is important to realize that the children are inside that region and do not just extend it. Observe that the child does not need a with clause for the parent and that the entities of the parent are directly visible without a use clause. In just the same way, library packages in Ada 95 can be thought of as being declared in the declarative region of the package Standard and after the end of its specification. Note that a child subprogram is not a primitive operation of a type declared in its parent's specification because the child is not declared in the specification but after it. The important special visibility rule is that the private part (if any) and the body of the child have visibility of the private part of their parent. (They naturally also have visibility of the visible part.) However, the visible part of a (public) child package does not have visibility of the private part of its parent; if it did it would allow renaming and hence the export of the hidden private details to any client; this would break the abstraction of the private type (this rule does not apply to private children as explained later). The body of the child package for our complex number example could simply be <syntaxhighlight lang="Ada"> package body Complex_Numbers.Polar is -- bodies of Polar_To_Complex etc end Complex_Numbers.Polar;</syntaxhighlight> In order to access the procedures of the child package the client must have a with clause for the child package. However this also implicitly provides a with clause for the parent as well thereby saving us the burden of having to write one separately. Thus we might have <syntaxhighlight lang="Ada"> with Complex_Numbers.Polar; package Client is ...</syntaxhighlight> and then within Client we can access the various subprograms in the usual way by writing Complex_Numbers.Real_Part or Complex_Numbers.Polar.Arg and so on. Direct visibility can be obtained by use clauses as expected. However, a use clause for the child does not imply one for the parent; but, because of the model that the child is in the declarative region of the parent, a use clause for the parent makes the child name itself directly visible. So writing <syntaxhighlight lang="Ada"> with Complex_Numbers.Polar; use Complex_Numbers;</syntaxhighlight> now allows us to refer to the subprograms as Real_Part and Polar.Arg respectively. We could of course have added <syntaxhighlight lang="Ada"> use Complex_Numbers.Polar;</syntaxhighlight> and we would then be able to refer to the subprogram Polar.Arg as just Arg. Child packages thus neatly solve both the problem of sharing a private type over several compilation units and the problem of extending a package without recompiling the clients. They thus provide another form of programming by extension. A package may of course have several children. In fact with hindsight it might have been more logical to have developed our complex number package as three packages: a parent containing the private type and the four arithmetic operations and then two child packages, one giving the cartesian view and the other giving the polar view of the type. At a later date we could add yet another package providing perhaps the trigonometric functions on complex numbers and again this can be done without recompiling what has already been written and thus without the risk of introducing errors. The extension mechanism provided by child packages fits neatly together with that provided by tagged types. Thus a child package might itself have a private part and then within that part we might derive and extend a private type from the parent package. This is illustrated by the following example which relates to the processing of widgets in a window system. <syntaxhighlight lang="Ada"> package XTK is type Widget is tagged private; type Widget_Access is access Widget'Class; ... private type Widget is tagged record Parent: Widget_Access; ... end record; end XTK; -- now extend the Widget package XTK.Color is type Colored_Widget is new Widget with private; ... private type Colored_Widget is new Widget with record Color: ... end record; end XTK.Color;</syntaxhighlight> An interesting point with this construction is that clients at the parent level (those just withing XTK) only see the external properties common to all widgets, although by class-wide programming using Widget_Access, they may be manipulating colored widgets. However, a client of XTK.Color also has access to the external properties of colored widgets because we have made the extended type visible (although still private of course). It should be noted that in fact the private part of XTK.Color does not actually access the private part of XTK although it has visibility of it. But of course the body of XTK.Color undoubtedly will and that is why we need a child package. Another example is provided by the alert system discussed in II.1. It would probably be better if the additional package concerning emergency alerts was actually a child of the main package thus <syntaxhighlight lang="Ada"> package New_Alert_System.Emergency is type Emergency_Alert is new Alert with private; ... end New_Alert_System.Emergency;</syntaxhighlight> The advantages are manifold. The commonality of naming makes it clear that the child is indeed just a part of the total system; this is emphasized by not needing a with clause for the parent and that the entities in the parent are immediately visible. In addition, although not required in this example, any private mechanisms in the private part of the parent would be visible to the child. The alternative structure in II.3 where the baseline used an abstract type could also be rearranged. The benefit of just the commonality of naming is very important since it prevents the inadvertent interference between different parts of subsystems. This is used to good advantage in the arrangement of the Ada 95 predefined library as will be seen in II.13. Finally, it is very important to realize that the child mechanism is hierarchical. Children may have children to any level so we can build a complete tree providing decomposition of facilities in a natural manner. A child may have a private part and this is then visible from its children but not its parent. With regard to siblings a child can obviously only have visibility of a previously compiled sibling anyway. And then the normal rules apply: a child can only see the visible part of its siblings. A parent body may access (via with clauses) and thus depend upon its children and grandchildren. A child body automatically depends upon its parent (and grandparent) and needs no with clause for them. A child body can depend upon its siblings (again via with clauses). == <span id="8"> II.8 Private Child Units </span> == In the previous section we introduced the concept of hierarchical child packages and showed how these allowed extension and continued privacy of private types without recompilation. However, the whole idea was based on the provision of additional facilities for the client. The specifications of the additional packages were all visible to the client. In the development of large subsystems it often happens that we would like to decompose the system for implementation reasons but without giving any additional visibility to clients. Ada 83 had a problem in this area which we have not yet addressed. In Ada 83 the only means at our disposal for the decomposition of a body was the subunit. However, although a subunit could be recompiled without affecting other subunits at the same level, any change to the top level body (which of course includes the stubs of the subunits) required all subunits to be recompiled. Ada 95 also solves this problem by the provision of a form of child unit that is totally private to its parent. In order to illustrate this idea consider the following outline of an operating system. <syntaxhighlight lang="Ada"> package OS is -- parent package defines types used throughout the system type File_Descriptor is private; ... private type File_Descriptor is new Integer; end OS; package OS.Exceptions is -- exceptions used throughout the system File_Descriptor_Error, File_Name_Error, Permission_Error: exception; end OS.Exceptions; with OS.Exceptions; package OS.File_Manager is type File_Mode is (Read_Only, Write_Only, Read_Write); function Open(File_Name: String; Mode: File_Mode) return File_Descriptor; procedure Close(File: in File_Descriptor); ... end OS.File_Manager; procedure OS.Interpret(Command: String); private package OS.Internals is ... end OS.Internals; private package OS.Internals_Debug is ... end OS.Internals_Debug;</syntaxhighlight> In this example the parent package contains the types used throughout the system. There are then three public child units, the package OS.Exceptions containing various exceptions, the package OS.File_Manager which provides file open/close routines (note the explicit with clause for its sibling OS.Exceptions) and a procedure OS.Interpret which interprets a command line passed as a parameter. (Incidentally this illustrates that a child unit can be a subprogram as well as a package. It can actually be any library unit and that includes a generic declaration and a generic instantiation.) Finally we have two private child packages called OS.Internals and OS.Internals_Debug. A private child (distinguished by starting with the word private) can be declared at any point in the child hierarchy. The visibility rules for private children are similar to those for public children but there are two extra rules. The first extra rule is that a private child is only visible within the subtree of the hierarchy whose root is its parent. And moreover within that tree it is not visible to the specifications of any public siblings (although it is visible to their bodies). In our example, since the private child is a direct child of the package OS, the package OS.Internals is visible to the bodies of OS itself, of OS.File_Manager and of OS.Interpret (OS.Exceptions has no body anyway) and it is also visible to both body and specification of OS.Internals_Debug. But it is not visible outside OS and a client package certainly cannot access OS.Internals at all. The other extra rule is that the visible part of the private child can access the private part of its parent. This is quite safe because it cannot export information about a private type to a client because it is not itself visible. Nor can it export information indirectly via its public siblings because, as mentioned above, it is not visible to the visible parts of their specifications but only to their private parts and bodies. We can now safely implement our system in the package OS.Internals and we can create a subtree for the convenience of development and extensibility. We would then have a third level in the hierarchy containing packages such as OS.Internals.Devices, OS.Internals.Access_Rights and so on. It might be helpful just to summarize the various visibility rules which are actually quite simple and mostly follow from the model of the child being located after the end of the specification of its parent but inside the parent's declarative region. (We use "to with" for brevity.) * A specification never needs to with its parent; it may with a sibling except that a public child specification may not with a private sibling; it may not with its own child (it has not been compiled yet!). * A body never needs to with its parent; it may with a sibling (private or not); it may with its own child (and grandchild...). * The entities of the parent are accessible by simple name within a child; a use clause is not required. * The context clause of the parent also applies to a child. * A private child is never visible outside the tree rooted at its parent. And within that tree it is not visible to the specifications of public siblings. * The private part and body of any child can access the private part of its parent (and grandparent...). * In addition the visible part of a private child can also access the private part of its parent (and grandparent...). * A with clause for a child automatically implies with clauses for all its ancestors. * A use clause for a library unit makes the child units accessible by simple name (this only applies to child units for which there is also a with clause). These rules may seem a bit complex but actually stem from just a few considerations of consistency. Questions regarding access to children of sibling units and other remote relatives follow by analogy with an external client viewing the appropriate subtree. We conclude our discussion of hierarchical libraries by considering their interaction with generics. Genericity is also an important tool in the construction of subsystems and it is essential that it be usable with the child concept. Any parent unit may have generic children but a generic parent can only have generic children. If the parent unit is not generic then a generic child may be instantiated in the usual way at any point where it is visible. On the other hand, if the parent unit is itself generic, then a generic child can be instantiated outside the parent hierarchy provided the parent is first instantiated and the child is mentioned in a with clause; the instantiation of the child then refers to the instantiation of the parent. Note that although the original generic hierarchy consists of library units, the instantiations need not be library units. As a simple example, we might wish to make the package Complex_Numbers of the previous section generic with respect to the underlying floating point type. We would write <syntaxhighlight lang="Ada"> generic type Float_Type is digits <>; package Complex_Numbers is ... end Complex_Numbers; generic package Complex_Numbers.Polar is ... end Complex_Numbers.Polar;</syntaxhighlight> and then the instantiations might be <syntaxhighlight lang="Ada"> with Complex_Numbers; package Real_Complex_Numbers is new Complex_Numbers(Real); with Complex_Numbers.Polar; package Real_Complex_Numbers.Real_Polar is new Real_Complex_Numbers.Polar;</syntaxhighlight> We thus have to instantiate the generic hierarchy (or as much of it as we want) unit by unit. This avoids a number of problems that would arise with a more liberal approach but enables complete subsystems to be built in a generic manner. In the above example we chose to make the instantiated packages into a corresponding hierarchy but as mentioned they could equally have been instantiated as local packages with unrelated names. But an important point is that the instantiation of the child refers to the instantiation of the parent and not to the generic parent. This ensures that the instantiation of the child has visibility of the correct instantiation of the parent. The reader will now appreciate that the hierarchical library system of Ada 95 provides a very powerful and convenient tool for the development of large systems from component subsystems. This is of particular value in developing bindings to systems such as POSIX in a very elegantly organized manner. == <span id="9"> II.9 Protected Types </span> == The rendezvous model of Ada 83 provided an advanced high level approach to task synchronization which avoided the methodological difficulties encountered by the use of low- level primitives such as semaphores and signals. As is well-known, such low-level primitives suffer from similar problems as gotos; it is obvious what they do and they are trivial to implement but in practice easy to misuse and can lead to programs which are difficult to maintain. Unfortunately the rendezvous has not proved entirely satisfactory. It required additional tasks to manage shared data and this often led to poor performance. Moreover, in some situations, awkward race conditions arose essentially because of abstraction inversion. And from a methodological viewpoint the rendezvous is clearly control oriented and thus out-of-line with a modern object oriented approach. In Ada 95 we introduce the concept of a protected type which encapsulates and provides synchronized access to the private data of objects of the type without the introduction of an additional task. Protected types are very similar in spirit to the shared objects of the Orca language developed by Bal, Kaashoek and Tanenbaum of Amsterdam [Bal 92]. A protected type has a distinct specification and body in a similar style to a package or task. The specification provides the access protocol and the body provides the implementation details. We can also have a single protected object by analogy with a single task. As a simple example consider the following <syntaxhighlight lang="Ada"> protected Variable is function Read return Item; procedure Write(New_Value: Item); private Data: Item; end Variable; protected body Variable is function Read return Item is begin return Data; end Read; procedure Write(New_Value: Item) is begin Data := New_Value; end Write; end Variable;</syntaxhighlight> The protected object Variable provides controlled access to the private variable Data of some type Item. The function Read enables us to read the current value whereas the procedure Write enables us to update the value. Calls use the familiar dotted notation. <syntaxhighlight lang="Ada"> X := Variable.Read; ... Variable.Write(New_Value => Y);</syntaxhighlight> Within a protected body we can have a number of subprograms and the implementation is such that (like a monitor) calls of the subprograms are mutually exclusive and thus cannot interfere with each other. A procedure in the protected body can access the private data in an arbitrary manner whereas a function is only allowed read access to the private data. The implementation is consequently permitted to perform the useful optimization of allowing multiple calls of functions at the same time. By analogy with entries in tasks, a protected type may also have entries. The action of an entry call is provided by an entry body which has a barrier condition which must be true before the entry body can be executed. There is a strong parallel between an accept statement with a guard in a task body and an entry body with a barrier in a protected body, although, as we shall see in a moment, the timing of the evaluation of barriers is quite different to that of guards. A good illustration of the use of barriers is given by a protected type implementing the classic bounded buffer. Consider <syntaxhighlight lang="Ada"> protected type Bounded_Buffer is entry Put(X: in Item); entry Get(X: out Item); private A: Item_Array(1 .. Max); I, J: Integer range 1 .. Max := 1; Count: Integer range 0 .. Max := 0; end Bounded_Buffer; protected body Bounded_Buffer is entry Put(X: in Item) when Count < Max is begin A(I) := X; I := I mod Max + 1; Count := Count + 1; end Put; entry Get(X: out Item) when Count > 0 is begin X := A(J); J := J mod Max + 1; Count := Count - 1; end Get; end Bounded_Buffer;</syntaxhighlight> This provides a cyclic bounded buffer holding up to Max values of the type Item with access through the entries Put and Get. We can declare an object of the protected type and access it as expected <syntaxhighlight lang="Ada"> My_Buffer: Bounded_Buffer; ... My_Buffer.Put(X);</syntaxhighlight> The behavior of the protected type is controlled by the barriers. When an entry is called its barrier is evaluated; if the barrier is false then the call is queued in much the same way that calls on entries in tasks are queued. When My_Buffer is declared, the buffer is empty and so the barrier for Put is true whereas the barrier for Get is false. So initially only a call of Put can be executed and a task issuing a call of Get will be queued. At the end of the execution of an entry body (or a procedure body) of the protected object all barriers which have queued tasks are reevaluated thus possibly permitting the processing of an entry call which had been queued on a false barrier. So at the end of the first call of Put, if a call of Get had been queued, then the barrier is reevaluated thus permitting a waiting call of Get to be serviced at once. It is important to realize that there is no task associated with the buffer itself; the evaluation of barriers is effectively performed by the runtime system. Barriers are evaluated when an entry is first called and when something happens which could sensibly change the state of a barrier with a waiting task. Thus barriers are only reevaluated at the end of an entry or procedure body and not at the end of a protected function call because a function call cannot change the state of the protected object and so is not expected to change the values of barriers. These rules ensure that a protected object can be implemented efficiently. Note that a barrier could refer to a global variable; such a variable might get changed other than through a call of a protected procedure or entry - it could be changed by another task or even by a call of a protected function; such changes will thus not be acted upon promptly. The programmer needs to be aware of this and should not use global variables in barriers without due consideration. It must be understood that the barrier protection mechanism is superimposed upon the natural mutual exclusion of the protected construct thus giving two distinct levels of protection. At the end of a protected call, already queued entries (whose barriers are now true) take precedence over other calls contending for the protected object. On the other hand, a new entry call cannot even evaluate its barrier if the protected object is busy with another call until that call (and any processible queued calls) have finished. This has the following important consequence: if the state of a protected resource changes and there is a task waiting for the new state, then this task will gain access to the resource and be guaranteed that the state of the resource when it gets it is the same as when the decision to release the task was made. Unsatisfactory polling and race conditions are completely avoided. Protected objects are very similar to monitors in general concept; they are passive constructions with synchronization provided by the language runtime system. However, they have a great advantage over monitors in that the protocols are described by barrier conditions (which are fairly easy to prove correct) rather than the low-level and unstructured signals internal to monitors as found in Modula. In other words protected objects have the essential advantages of the high level guards of the rendezvous model but without the overhead of an active task. Protected types enable very efficient implementations of various semaphore and similar paradigms. For example a counting semaphore might be implemented as follows <syntaxhighlight lang="Ada"> protected type Counting_Semaphore(Start_Count: Integer := 1) is entry Secure; procedure Release; function Count return Integer; private Current_Count: Integer := Start_Count; end Counting_Semaphore; protected body Counting_Semaphore is entry Secure when Current_Count > 0 is begin Current_Count := Current_Count - 1; end Secure; procedure Release is begin Current_Count := Current_Count + 1; end Release; function Count return Integer is begin return Current_Count; end Count; end Counting_Semaphore;</syntaxhighlight> This implements the general form of Dijkstra's semaphore. It illustrates the use of all three forms of protected operations: a function, a procedure and an entry. The entry Secure and the procedure Release correspond to the P and V operations (from the Dutch Passeren and Vrijmaken) and the function Count gives the current value of the semaphore. This example also illustrates that a protected type can have a discriminant which is here used to provide the initial value of the semaphore or in other words the number of items of the resource being guarded by the semaphore. It is important to note that a task type may also have a discriminant in Ada 95 and this can similarly be used to initialize a task. This can for example be used to tell a task who it is (perhaps from among an array of tasks) without introducing a special entry just for that purpose. Our final example introduces the ability to requeue a call on another entry. It sometimes happens that a service needs to be provided in two parts and that the calling task has to be suspended after the first part until conditions are such that the second part can be done. Two entry calls are then necessary but attempts to program this in Ada 83 usually run into difficulties; race conditions can arise in the interval between the calls and there is often unnecessary visibility of the internal protocol. The example is of a broadcast signal. Tasks wait for some event and then when it occurs all the waiting tasks are released and the event reset. The difficulty is to prevent tasks that call the wait operation after the event has occurred, but before the signal can be reset, from getting through. In other words, we must reset the signal in preference to letting new tasks through. The requeue statement allows us to program such preference control. An implementation is <syntaxhighlight lang="Ada"> protected Event is entry Wait; entry Signal; private entry Reset; Occurred: Boolean := False; end Event; protected body Event is entry Wait when Occurred is begin null; -- note null body end Wait; entry Signal when True is -- barrier is always true begin if Wait'Count > 0 then Occurred := True; requeue Reset; end if; end Signal; entry Reset when Wait'Count = 0 is begin Occurred := False; end Reset; end Event;</syntaxhighlight> Tasks indicate that they wish to wait for the event by the call <syntaxhighlight lang="Ada"> Event.Wait;</syntaxhighlight> and the happening of the event is notified by some task calling <syntaxhighlight lang="Ada"> Event.Signal;</syntaxhighlight> whereupon all the waiting tasks are allowed to proceed and the event is reset so that future calls of Wait work properly. The Boolean variable Occurred is normally false and is only true while tasks are being released. The entry Wait has no body but just exists so that calling tasks can suspend themselves on its queue while waiting for Occurred to become true. The entry Signal is interesting. It has a permanently true barrier and so is always processed. If there are no tasks on the queue of Wait (that is no tasks are waiting), then there is nothing to do and so it exits. On the other hand if there are tasks waiting then it must release them in such a way that no further tasks can get on the queue but then regain control so that it can reset the flag. It does this by requeuing itself on the entry Reset after setting Occurred to true to indicate that the event has occurred. The semantics of requeue are such that this completes the action of Signal. However, remember that at the end of the body of a protected entry or procedure the barriers are reevaluated for those entries which have tasks queued. In this case there are indeed tasks on the queue for Wait and there is also a task on the queue for Reset (the task that called Signal in the first place); the barrier for Wait is now true but of course the barrier for Reset is false since there are still tasks on the queue for Wait. A waiting task is thus allowed to execute the body of Wait (being null this does nothing) and the task thus proceeds and then the barrier evaluation repeats. The same process continues until all the waiting tasks have gone when finally the barrier of Reset also becomes true. The original task which called signal now executes the body of Reset thus resetting Occurred to false so that the system is once more in its initial state. The protected object as a whole is now finally left since there are no waiting tasks on any of the barriers. Note carefully that if any tasks had tried to call Wait or Signal while the whole process was in progress then they would not have been able to do so because the protected object as a whole was busy. This illustrates the two levels of protection and is the underlying reason why a race condition does not arise. Another consequence of the two levels is that it still all works properly even in the face of such difficulties as timed and conditional calls and aborts. The reader may recall, for example, that by contrast, the Count attribute for entries in tasks cannot be relied upon in the face of timed entry calls. A minor point to note is that the entry Reset is declared in the private part of the protected type and thus cannot be called from outside. Ada 95 also allows a task to have a private part containing private entries. The above example has been used for illustration only. The astute reader will have observed that the condition is not strictly needed inside Signal; without it the caller will simply always requeue and then immediately be processed if there are no waiting tasks. But the condition clarifies the description. Indeed, the very astute reader might care to note that we can actually program this example in Ada 95 without using requeue at all. A more realistic classic example is the disk scheduler where a caller is requeued if the head is currently over the wrong track. In this section we have outlined the main features of protected types. There are a number of detailed aspects that we have not covered. The general intent, however, should be clear. Protected types provide a data-oriented approach to synchronization which couples the high-level conditions (the barriers) with the efficiency of monitors. Furthermore the requeue statement provides a means of programming preference control and thus enables race conditions to be avoided. It must be remembered, of course, that the existing task model remains; the rendezvous will continue to be a necessary approach in many circumstances of a general nature (such as for directly passing messages). But the protected object provides a better paradigm for most data-oriented situations. == <span id="10"> II.10 Task Scheduling and Timing </span> == A criticism of Ada 83 has been that its scheduling rules are unsatisfactory especially with regard to the rendezvous. First-in-first-out queuing on entries and the arbitrary selection from several open alternatives in a select statement lead to conflict with the normal preemptive priority rules. For example, priority inversion occurs when a high priority task is on an entry queue behind a lower priority task. Furthermore, mode changes may require the ability to dynamically change priorities and this conflicts with the simple static model of Ada 83. In addition, advances in the design of scheduling techniques based on Rate Monotonic Scheduling prescribe a variety of techniques to be used in different circumstances according to the arrival pattern of events; see [Sha 90a] and [Klein 93]. Ada 95 allows much more freedom in the choice of priority and scheduling rules. However, because this is a specialized area (and may not be appropriate on some host architectures), the details are contained in the Real-Time Systems annex to which the reader is referred for more details. Timing is another important aspect of scheduling and the delay statement of Ada 83 has not proved adequate in all circumstances. For example, an attempt to wait until a specific time by a sequence such as <syntaxhighlight lang="Ada"> Next_Time: Time; ... Next_Time := time_to_be_woken_up; delay Next_Time - Clock;</syntaxhighlight> which is intended to stop the task until the time given by the variable Next_Time, is not foolproof. The problem is that there is a race condition. Between calling the function Clock and issuing the delay statement, it is possible for the task to be preempted by a higher priority task. The result is that when the delay is finally issued, the Duration value will be inappropriate and the task will be delayed for too long. This difficulty is overcome in Ada 95 by the introduction of a complementary delay until statement which takes a Time (rather than a Duration) as its argument. We can then simply write <syntaxhighlight lang="Ada"> delay until Next_Time;</syntaxhighlight> and all will be well. The final new tasking facility to be introduced in this section is the ability to perform an asynchronous transfer of control. This enables an activity to be abandoned if some condition arises (such as running out of time) and an alternative sequence of statements to be executed instead. This gives the capability of performing mode changes. This could of course be programmed in Ada 83 by the introduction of an agent task and the use of the abort statement but this was a heavy solution not at all appropriate for most applications needing a mode change. Asynchronous transfer of control is achieved by a new form of select statement which comprises two parts: an abortable part and a triggering alternative. As a simple example consider <syntaxhighlight lang="Ada"> select delay 5.0; -- triggering alternative Put_Line("Calculation did not complete"); then abort Invert_Giant_Matrix(M); -- abortable part end select;</syntaxhighlight> The general idea is that if the statements between then abort and end select do not complete before the expiry of the delay then they are abandoned and the statements following the delay executed instead. Thus if we cannot invert our large matrix in five seconds we give up and print a message. The statement that triggers the abandonment can alternatively be an entry call instead of a delay statement. If the call returns before the computation is complete then again the computation is abandoned and any statements following the entry call are executed instead. On the other hand if the computation completes before the entry call, then the entry call is itself abandoned. The entry call can, of course, be to a task or to a protected object as described in the previous section. Indeed, Ada 95 allows an entry call to be to a protected object or to a task in all contexts. Other refinements to the Ada tasking model include a better description of the behavior of the abort statement and a more useful approach to shared variables by the introduction of a number of pragmas. == <span id="11"> II.11 Generic Parameters </span> == The generic facility in Ada 83 has proved very useful for developing reusable software particularly with regard to its type parameterization capability. However, there were a few anomalies which have been rectified in Ada 95. In addition a number of further parameter models have been added to match the object oriented facilities. In Ada 83 the so-called contract model was broken because of the lack of distinction between constrained and unconstrained formal parameters. Thus if we had <syntaxhighlight lang="Ada"> generic type T is private; package P is ... package body P is X: T; ...</syntaxhighlight> then in Ada 83 we could instantiate this with a type such as Integer which was fine. However we could also supply an unconstrained type such as String and this failed because when we came to declare the object T we found that there were no constraints and we could not declare an object as an unconstrained array. The problem was that the error was not detected through a mismatch in the instantiation mechanism but as an error in the body itself. But the whole essence of the contract model is that if the actual parameter satisfies the requirements of the formal then any body which matches the formal specification will work. The poor user might not have had access to the source of the body but nevertheless found errors reported in it despite the instantiation apparently working. This serious violation of the contract model is repaired in Ada 95. The parameter matching rules for the example above no longer accept an unconstrained type such as String but require a type such as Integer or a constrained type or a record type with default discriminants (these are collectively known as definite types in Ada 95). If we wish to write a generic package that will indeed accept an unconstrained type then we have to use a new form of notation as follows <syntaxhighlight lang="Ada"> generic type T(<>) is private; package P ...</syntaxhighlight> In this case we are not allowed to declare an (uninitialized) object of type T in the body; we can only use T in ways which do not require a constrained type. The actual parameter can now be any unconstrained type such as String; it could, of course, also be a constrained type. Other new parameter models are useful for combining genericity with type extension and for writing class-wide generic packages. The formal declaration <syntaxhighlight lang="Ada"> type T is tagged private;</syntaxhighlight> requires that the actual type be tagged. We can also write <syntaxhighlight lang="Ada"> type T is new S;</syntaxhighlight> or <syntaxhighlight lang="Ada"> type T is new S with private;</syntaxhighlight> In both cases the actual type must be S or derived directly or indirectly from S. If we add with private then both S and the actual type must be tagged. (Remember the rule that all tagged types have tagged or with in their declaration.) In all these cases we can also follow the formal type name with (<>) to indicate that the actual may be unconstrained (strictly, indefinite to use the terminology introduced above). Furthermore if we follow is by abstract then the actual type can also be abstract (but it need not be). The last new kind of formal generic parameter is the formal generic package. This greatly simplifies the composition of generic packages. It allows one package to be used as a parameter to another so that a hierarchy of facilities can be created. Examples are inevitably a bit long but consider first the following two packages in Ada 83. The first defines a private type for complex numbers and the basic operations upon them. The second builds on the first and provides various vector operations on complex numbers. The whole system is generic with respect to the underlying floating point type used for the complex numbers. <syntaxhighlight lang="Ada"> generic type Float_Type is digits <>; package Generic_Complex_Numbers is type Complex is private; function "+" (Left, Right: Complex) return Complex; function "-" (Left, Right: Complex) return Complex; -- etc end Generic_Complex_Numbers; generic type Float_Type is digits <>; type Complex is private; with function "+" (Left, Right: Complex) return Complex is <>; with function "-" (Left, Right: Complex) return Complex is <>; -- and so on package Generic_Complex_Vectors is -- types and operations on vectors end Generic_Complex_Vectors; and we can then instantiate these two packages by for example package Long_Complex is new Generic_Complex_Numbers(Long_Float); use Long_Complex; package Long_Complex_Vectors is new Generic_Complex_Vectors(Long_Float, Complex);</syntaxhighlight> In this Ada 83 formulation we had to pass the type Complex and all its operations exported from Complex_Numbers back into the vector package as distinct formal parameters so that we could use them in that package. The burden was somewhat reduced by using the default mechanism for the operations but this incurred the slight risk that the user might have redefined one of them with incorrect properties (it also forced us to write a use clause or lots of renamings). This burden is completely alleviated in Ada 95 by the ability to declare generic formal packages. In the generic formal part we can write <syntaxhighlight lang="Ada"> with package P is new Q(<>);</syntaxhighlight> and then the actual parameter corresponding to P must be any package which has been obtained by instantiating Q which must itself be a generic package. Returning to our example, in Ada 95, having written Generic_Complex_Numbers as before, we can now write <syntaxhighlight lang="Ada"> with Generic_Complex_Numbers; generic with package Complex_Numbers is new Generic_Complex_Numbers (<>); package Generic_Complex_Vectors is -- as before end Generic_Complex_Vectors;</syntaxhighlight> where the actual package must be any instantiation of Generic_Complex_Numbers. Hence our previous instantiations can now be simplified and we can write <syntaxhighlight lang="Ada"> package Long_Complex is new Generic_Complex_Numbers(Long_Float); package Long_Complex_Vectors is new Generic_Complex_Vectors(Long_Complex);</syntaxhighlight> The key point is that we no longer have to import (explicitly or implicitly) the type and operators exported by the instantiation of Generic_Complex_Numbers. Hence the parameter list of Generic_Complex_Vectors is reduced to merely the one parameter which is the package Long_Complex obtained by the instantiation of Generic_Complex_Numbers. We no longer even have to pass the underlying type Long_Float. Although this example has been couched in terms of a numerical application, the general approach is applicable to many examples of building a hierarchy of generic packages. == <span id="12"> II.12 Other Improvements </span> == We have now covered most of the major improvements which give Ada 95 so much extra power over Ada 83. But the discussion has not been complete; we have omitted important facilities such as the introduction of controlled types giving initialization, finalization and user defined assignment and the use of access discriminants to give the functionality of multiple inheritance. There are also a number of minor changes which remove various irritations and which together make Ada 95 a major improvement within existing paradigms. We will now briefly mention the more notable of these improvements. The attribute T'Base can now be used as a type mark. So if Float_Type is a generic formal parameter we can then declare <syntaxhighlight lang="Ada"> Local: Float_Type'Base;</syntaxhighlight> and any constraints imposed by the actual parameter will not then apply to the working variable Local. This is important for certain numeric algorithms where we wish to be unconstrained in intermediate computations. The underlying model for the numeric types is slightly changed by the introduction of fictitious types root_integer and root_real. This brings a number of simplifications and improvements regarding implicit type conversions and one is the removal of the notorious irritation that <syntaxhighlight lang="Ada"> for I in -1 .. 100 loop</syntaxhighlight> was not allowed in Ada 83. It is allowed in Ada 95. The rule distinguishing basic declarative items from later declarative items has been removed (this essentially said that little declarations cannot follow big declarations and was intended to prevent little ones getting lost visually but it backfired). As a consequence declarations can now be in any order. This often helps with the placing of representation clauses. Another irritation in Ada 83 was the problem of use clauses and operators. There was a dilemma between, on the one hand, disallowing a use clause and then having to use prefix notation for operators or introduce a lot of renaming or, on the other hand, allowing a use clause so that infixed operators could be used but then allowing visibility of everything and running the risk that package name prefixes might be omitted with a consequent serious loss of readability. Many organizations have imposed a complete ban on use clauses and burdened themselves with lots of renaming. This is solved in Ada 95 by the introduction of a use type clause. If we have a package Complex_Numbers which declares a type Complex and various operators "+", "-" and so on, we can write <syntaxhighlight lang="Ada"> with Complex_Numbers; use type Complex_Numbers.Complex;</syntaxhighlight> and then within our package we can use the operators belonging to the type Complex in infix notation. Other identifiers in Complex_Numbers will still have to use the full dotted notation so we can see from which package they come. Predefined operators such as "=" are also made directly visible by an appropriate use type clause. Concerning "=" the rules regarding its redefinition are now completely relaxed. It may be redefined for any type at all and need not necessarily return a result of type Boolean. The only remaining rule in this area is that if the redefined "=" does return a result of type Boolean then a corresponding "/=" is also implicitly declared. On the other hand, "/=" may itself be redefined only if its result is not type Boolean. The rules regarding static expressions are improved and allow further sensible expressions to be treated as static. A static expression may now contain membership tests, attributes, conversions and so on. Moreover, an expression which looks static but occurs in a context not demanding a static expression will be evaluated statically; this was surprisingly not the case in Ada 83 - an expression such as 2 + 3 was only required to be evaluated at compile time if it occurred in a context demanding a static expression. Note also that rounding of odd halves is now defined as away from zero so Integer(1.5) is now 2. A small change which will be welcomed is that a subprogram body may now be provided by renaming. This avoids tediously writing code which merely calls another subprogram. Renaming is now also allowed for generic units and a library unit may now be renamed as a library unit; these facilities will be found to be particularly useful with child units. Another change which will bring a sigh of relief is that out parameters can now be read. They are treated just like a variable that happens not to be explicitly initialized; this change will save the introduction of many local variables and much frustration. A related change is that the restriction that it was not possible to declare a subprogram with out parameters of a limited type is also lifted. Some restrictions regarding arrays are also relaxed. It is now possible to deduce the bounds of a variable (as well as a constant) from an appropriate initial value, such as in <syntaxhighlight lang="Ada"> S: String := Get_Message; -- a function call</syntaxhighlight> which avoids having to write the tedious <syntaxhighlight lang="Ada"> Message: constant String := Get_Message; S: String(Message'Range) := Message;</syntaxhighlight> It is also possible to use a named aggregate with an "others" component as an initial value or in an assignment. Sliding is now permitted for subprogram parameters and function results in return statements which are treated like assignment with regard to array bound matching. There are also improvements in the treatment of discriminants. A private type can now have a discriminated type with defaults as its full type thus <syntaxhighlight lang="Ada"> package P is type T is private; private type T(N: Natural := 1) is ... end P;</syntaxhighlight> Infuriatingly this was not allowed in Ada 83 although the corresponding problem with matching generic parameters was eliminated many years ago. An important improvement in exception handlers is the ability to access information regarding the occurrence of an exception. This is done by declaring a "choice parameter" in the handler and we can then use that to get hold of, for example, the exception name for debugging purposes. We can write <syntaxhighlight lang="Ada"> when Event: others => Put_Line("Unexpected exception: " & Exception_Name(Event));</syntaxhighlight> where the function Exception_Name returns the name of the exception as a string (such as "Constraint_Error"). Other functions provide further useful diagnostic information regarding the cause of the exception. An important improvement which will be a great relief to systems programmers is that the language now includes support for unsigned integer types (modular types). This provides shift and logical operations as well as modular arithmetic operations and thus enables unsigned integer values to be manipulated as sequences of bits. Another improvement worth mentioning in this brief summary concerns library package bodies. In Ada 83 a package body was optional if it was not required by the language (for providing subprogram bodies for example). However, this rule, which was meant to be a helpful convenience, seriously misfired sometimes when a library package was recompiled and bodies which just did initialization could get inadvertently lost without any warning. In Ada 95, a library package is only allowed to have a body if it is required by language rules; the pragma Elaborate_Body is one way of indicating that a body is required. Finally, in order to meet the needs of the international community, the type Character has been changed to the full 8-bit ISO set (Latin-1) and the type Wide_Character representing the 16-bit ISO Basic Multilingual Plane has been added. The type Wide_String is also defined by analogy. == <span id="13"> II.13 The Predefined Library </span> == There are many additional predefined packages in the standard library which has been restructured in order to take advantage of the facilities offered by the hierarchical library. As mentioned above, root library packages behave as children of Standard. There are just three such predefined child packages of Standard, namely System, Interfaces and Ada and these in turn have a number of child packages. Those of System are concerned with intrinsic language capability such as the control of storage. Those of Interfaces concern the interfaces to other languages. The remaining more general predefined packages are children of the package Ada. An important reason for the new structure is that it avoids potential name conflicts with packages written by the user; thus only the names Ada and Interfaces could conflict with existing Ada 83 code. Without this structure the risk of conflict would have been high especially given the many new predefined packages in Ada 95. The existing packages such as Calendar, Unchecked_Conversion and Text_IO are now child packages of Ada. Compatibility with Ada 83 is achieved by the use of library unit renaming (itself a new feature in Ada 95) thus <syntaxhighlight lang="Ada"> with Ada.Text_IO; package Text_IO renames Ada.Text_IO;</syntaxhighlight> We will now briefly summarize the more notable packages in the predefined library in order to give the reader an appreciation of the breadth of standard facilities provided. The package Ada itself is simply <syntaxhighlight lang="Ada"> package Ada is pragma Pure(Ada); -- as white as driven snow! end Ada;</syntaxhighlight> where the pragma indicates that Ada has no variable state; (this concept is important for sharing in distributed systems). Input-output is provided by the existing packages Ada.Text_IO, Ada.Sequential_IO, Ada.Direct_IO and Ada.IO_Exceptions plus a number of new packages. The package Ada.Wide_Text_IO is identical to Text_IO except that it handles the types Wide_Character and Wide_String. General stream input-output is provided by Ada.Streams and Ada.Streams.Stream_IO; these enable heterogeneous files of arbitrary types to be manipulated (remember that Direct_IO and Sequential_IO manipulate files whose items are all of the same type). The package Ada.Text_IO.Text_Streams gives access to the stream associated with Text_IO; this allows mixed binary and text input-output and the use of the standard files with streams. There are also nongeneric versions of the packages Text_IO.Integer_IO and Text_IO.Float_IO for the predefined types such as Integer and Float. Their names are Ada.Integer_Text_IO and Ada.Float_Text_IO and so on for other predefined types; there are also corresponding wide versions. These nongeneric packages will be found useful for training and overcome the need to teach genericity on day one of every Ada course. The package Ada.Characters.Handling provides classification and conversion functions for characters. Examples are Is_Letter which returns an appropriate Boolean value and To_Wide_Character which converts a character to the corresponding wide character. The package Ada.Characters.Latin_1 contains named constants in a similar style to Standard.ASCII which is now obsolescent. General string handling is provided by the package Ada.Strings. Three different forms of string are handled by packages Strings.Fixed, Strings.Bounded and Strings.Unbounded. In addition, packages such as Strings.Wide_Fixed perform similar operations on wide strings. Extensive mathematical facilities are provided by the package Ada.Numerics. This parent package is just <syntaxhighlight lang="Ada"> package Ada.Numerics is pragma Pure(Numerics); Argument_Error: exception; Pi: constant := 3.14159_26535_ ... ; e: constant := 2.71828_18284_ ... ; end Ada.Numerics;</syntaxhighlight> and includes the generic child package Ada.Numerics.Generic_Elementary_Functions which is similar to the corresponding standard ISO/IEC 11430:1994 for Ada 83 [ISO 94a]. There are also nongeneric versions such as Ada.Numerics.Elementary_Functions for the predefined types Float and so on. Facilities for manipulating complex types and complex elementary functions are provided by other child packages defined in the Numerics annex. The package Ada.Numerics.Float_Random enables the user to produce streams of pseudo-random floating point numbers with ease. There is also a generic package Ada.Numerics.Discrete_Random which provides for streams of discrete values (both integer and enumeration types). The package Ada.Exceptions defines facilities for manipulating exception occurrences such as the function Exception_Name mentioned above. The package System has child packages System.Storage_Elements and System.Storage_Pools which are concerned with storage allocation. The package Interfaces has child packages Interfaces.C, Interfaces.COBOL and Interfaces.Fortran which provide facilities for interfacing to programs in those languages. It also contains declarations of hardware supported numeric types. Implementations are encouraged to add further child packages for interfacing to other languages. == <span id="14"> II.14 The Specialized Needs Annexes </span> == There are six Specialized Needs annexes. In this summary we cannot go into detail but their content covers the following topics: ; Systems Programming : This covers a number of low-level features such as in- line machine instructions, interrupt handling, shared variable access and task identification. This annex is a prior requirement for the Real-Time Systems annex. ; Real-Time Systems : As mentioned above this annex addresses various scheduling and priority issues including setting priorities dynamically, scheduling algorithms and entry queue protocols. It also includes detailed requirements on the abort statement for single and multiple processor systems and a monotonic time package (as distinct from Calendar which might go backwards because of time-zone or daylight-saving changes). ; Distributed Systems : The core language introduces the idea of a partition whereby one coherent "program" is distributed over a number of partitions each with its own environment task. This annex defines two forms of partitions and inter-partition communication using statically and dynamically bound remote subprogram calls. ; Information Systems : The core language extends fixed point types to include basic support for decimal types. This annex defines a number of packages providing detailed facilities for manipulating decimal values and conversion to external format using picture strings. ; Numerics : This annex addresses the special needs of the numeric community. One significant change is the basis for model numbers. These are no longer described in the core language but in this annex. Moreover, model numbers in 95 are essentially what were called safe numbers in Ada 83 and the old model numbers and the term safe numbers have been abandoned. Having both safe and model numbers did not bring benefit commensurate with the complexity and confusion thereby introduced. This annex also includes packages for manipulating complex numbers. ; Safety and Security : This annex addresses restrictions on the use of the language and requirements of compilation systems for programs to be used in safety-critical and related applications where program security is vital. == <span id="15"> II.15 Conclusion </span> == The discussion in this chapter has been designed to give the reader a general feel for the scope of Ada 95 and some of the detail. Although we have not addressed all the many improvements that Ada 95 provides, nevertheless, it will be clear that Ada 95 is an outstanding language. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p1-1|Previous]] | [[Guide:9x_rationale/rat95-p1-3|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=II Highlights of Ada 95 <span class="hide">- 9x_rationale</span>}} c6go1gtarlp5znney9rqih43phzeo3x Guide:9x rationale/rat95-p1-3 4200 329 1879 1872 2019-04-20T16:20:57Z WikiVisor 11 Text replacement - "[[Guide:9x_rationale/rat95-copyright|Copyright]] | " to "<div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | " wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p1-2|Previous]] | [[Guide:9x_rationale/rat95-p2|Next]]</div> In addition to these aspects, the language supports real-time programming, with facilities to define the invocation, synchronization, and timing of parallel tasks. It also supports systems programming, with facilities that allow access to system-dependent properties, and precise control over the representation of data. The fact that the limited and predominantly upward compatible enhancements incorported in Ada 95 allow it to support state-of-the-art programming in the nineties and beyond, reconfirms the validity of Ada's underlying principles, and is a proof of the excellent foundation provided by the original design. == <span id="1"> III.1 Objects, Types, Classes and Operations </span> == This describes two fundamental concepts of Ada: types, which determine a set of values with associated operations, and objects, which are instances of those types. Objects hold values. Variables are objects whose values can be changed; constants are objects whose values cannot be changed. === <span id="1-1">III.1.1 Objects and Their Types</span> === Every object has an associated type. The type determines a set of possible values that the object can contain, and the operations that can be applied to it. Users write declarations to define new types and objects. Ada is a block-structured language in which the scope of declarations, including object and type declarations, is static. Static scoping means that the visibility of names does not depend on the input data when the program is run, but only on the textual structure of the program. Static properties such as visibility can be changed only by modifying and recompiling the source code. Objects are created when the executing program enters the scope where they are declared (elaboration); they are deleted when the execution leaves that scope (finalization). In addition, allocators are executable operations that create objects dynamically. An allocator produces an access value (a value of an access type), which provides access to the dynamically created object. An access value is said to designate an object. Access objects are only allowed to designate objects of the type specified by the access type. Access types correspond to pointer types or references in other programming languages. A type, together with a (possibly null) constraint, forms a subtype. User-defined subtypes constrain the values of the subtype to a subset of the values of the type. Subtype constraints are useful for run-time error detection, because they show the programmer's intent. Subtypes also allow an optimizing compiler to make more efficient use of hardware resources, because they give the compiler more information about the behavior of the program. User-defined types provide a finer classification of objects than the predefined types, and hence greater assurance that operations are applied to only those objects for which the operations are meaningful. === <span id="1-2">III.1.2 Types, Classes and Views</span> === Types in Ada can be categorized in a number of different ways. There are elementary types, which cannot be decomposed further, and composite types which, as the term implies, are composed of a number of components. The most important form of composite type is the record which comprises a number of named components themselves of arbitrary and possibly different types. Records in Ada 95 are generalized to be extensible and form the basis for object-oriented programming. Such extensible record types are known as tagged types; values of such types include a tag denoting the type which is used at runtime to distinguish between different types. Record types not marked as tagged may not be extended and correspond to the record types of Ada 83. New types may be formed by derivation from any existing type which is then known as the parent type. A derived type inherits the components and primitive operations of the parent type. In the case of deriving from a tagged record type, new components can be added thereby extending the type. In all cases new operations can be added and existing operations replaced. The set of types derived directly or indirectly from a specific type, together with that type form a derivation class. The types in a class share certain properties (they all have the components of the common ancestor or root type for example) and this may be exploited in a number of ways. Treating the types in a class interchangeably by taking advantage of such common properties is termed polymorphism. There are two means of using polymorphism in Ada. Static polymorphism is provided through the generic parameter mechanism whereby a generic unit may at compile time be instantiated with any type from a class of types. Dynamic polymorphism is provided through the use of so-called class-wide types and the distinction is then made at runtime on the basis of the value of a tag. A class-wide type is declared implicitly whenever a tagged record type is defined. The set of values of the class-wide type is the union of the sets of values of all the types of the class. Values of class-wide types are distinguished at runtime by the value of the tag giving class-wide programming or dynamic polymorphism. The class-wide type associated with a tagged record type T is denoted by the attribute T'Class. Objects and operations may be defined for such class-wide types in the usual way. As well as derivation classes, Ada also groups types into a number of predefined classes with common operations. This aids the description of the language and, moreover, the common properties of certain of these predefined classes may be exploited through the generic mechanism. A broad hierarchical classification of Ada types is illustrated in Figure III-1. The following summary of the various types gives their key properties. <ul> <li>A type is either an elementary type or a composite type. Elementary types cannot be decomposed further whereas the composite types have an inner structure. The elementary types can be further categorized into the scalar types and access types. The composite types comprise familiar array and record types plus the protected and task types which are concerned with multitasking.</li> <li>Scalar types are themselves subdivided into the discrete types and the real types. The discrete types have certain important common properties; for example, they may be used to index array types. The discrete types are the enumeration types and the integer types. The integer types in turn comprise signed integer types and modular (unsigned) types. The real types comprise the other forms of numeric types.</li> <li><p>An enumeration type defines an ordered set of distinct enumeration literals, for example a list of states or an alphabet of characters. The enumeration types Boolean, Character (the 8-bit ISO standard character set) and Wide_Character (the 16-bit ISO standard character set) are predefined.</p> <syntaxhighlight lang="Ada"> All Types | +---------------+-----------+ | | Elementary Types Composite Types | | +-------+--+ +------+---+---+---------+ | | | | | | access scalar array record protected task | +------+----------------+ | | | +====================================+ discrete | real | | | | | +---------------+ +---+----------+ | | | | | | | Numeric Types enumeration | integer float fixed | | | | | | +--+----+ +----+--+ | | | | | | | |signed modular decimal ordinary | +====================================+ Figure III-1: Ada Type Hierarchy</syntaxhighlight></li> <li>The numeric types do not exactly fit the hierarchy as presented, but there are certain properties that are common to all numeric types (such as the availability of arithmetic operations), so we have indicated this by a double box surrounding the numeric types. Numeric types provide a means of performing approximate or exact numerical computations. Approximate computations may be performed using either fixed point types with absolute error bounds, or floating point types with relative error bounds. Exact computations may be performed with either integer types, which denote sets of consecutive integers, or with decimal fixed point types. The numeric types Integer, Float and Duration are predefined.</li> <li>Access types, the remaining form of elementary type, allow the construction of linked data structures. The value of an access type is, in essence, a pointer to an object of another type, the accessed type. The accessed type may be any type. In particular the accessed type may be a class-wide type thereby allowing the construction of heterogeneous linked data structures. Access types may be used to designate objects created by allocators, declared objects (provided they are marked as aliased) and subprograms.</li> <li>Array types allow definitions of composite objects with indexable components all of the same subtype. Array types may be of one or more dimensions. The types of the indexes must be discrete. The array types String and Wide_String are predefined.</li> <li>Record types are composite types with named components not necessarily of the same type. Record types may be tagged or untagged. A tagged record type may be extended upon derivation and gives rise to a class-wide type which forms the basis for dynamic polymorphism. A tagged record type may also be marked abstract in which case no objects of the type may be declared; an abstract type may have abstract subprograms (these have no body). Abstract types and subprograms form a foundation from which concrete types may be derived.</li> <li>Protected types are composite types that provide synchronized access to their inner components via a number of protected operations. Objects of protected types are passive and do not have a distinct thread of control; the mutual exclusion is provided automatically.</li> <li>Task types are composite types which are used to define active units of processing. Each object of a task type has its own thread of control.</li></ul> Record, protected and task types may be parameterized by special components called discriminants. A discriminant may be either of a discrete type or of an access type. A discriminant of a discrete type may be used to control the structure or size of an object. More generally, a discriminant of an access type may be used to parameterize a type with a reference to an object of another type. A discriminant may also be used in the initialization of an object of a protected or task type. Ada provides a special syntax for defining new types within the various categories as illustrated by the following examples. <syntaxhighlight lang="Ada"> type Display_Color is -- an enumeration type (Red, Orange, Yellow, Green, Blue, Violet); type Color_Mask is -- an array type array (Display_Color) of Boolean; type Money is -- a decimal fixed type delta 0.01 digits 18; type Payment is -- a record type record Amount: Money; Due_Date: Date; Paid: Boolean; end record; task type Device is -- a task type entry Reset; end Device; type Dev is access Device; -- an access type protected type Semaphore is -- a protected type procedure Release; entry Seize; private Mutex: Boolean := False; end Semaphore;</syntaxhighlight> The following example illustrates a tagged type and type extension. A tagged type declaration takes the form <syntaxhighlight lang="Ada"> type Animal is tagged record Species: Species_Name; Weight: Grams; end record;</syntaxhighlight> and we may then declare <syntaxhighlight lang="Ada"> function Image(A: Animal) return String; -- Returns a human-readable identification of an Animal The type Animal could then be extended as follows type Mammal is new Animal with record Hair_Color: Color_Enum; end record;</syntaxhighlight> and a corresponding <syntaxhighlight lang="Ada"> function Image(M: Mammal) return String; -- Returns a human-readable identification of a Mammal</syntaxhighlight> The type Mammal has all the components of Animal and adds an additional component to describe the color of the mammal's hair. The process of extension and refinement could continue with other types such as Reptile and Primate leading to a tree-structured hierarchy of classes as depicted in Figure III-2. <syntaxhighlight lang="Ada"> Animal'Class | +-------------+ | | Reptile'Class Mammal'Class | | | Primate'Class Figure III-2: A Derivation Class Hierarchy</syntaxhighlight> It is important to observe that we have shown the hierarchy in terms of the class-wide types such as Mammal'Class rather than the specific types such as Mammal. This is to emphasize the fact that the type Mammal is not a subtype of Animal; Mammal and Animal are distinct types and values of one type cannot be directly assigned to objects of the other type. However, a value can be converted to an ancestor type (any type if untagged) of the same derivation class by using a type conversion; a value of a descendant tagged type can be formed by using an extension aggregate. There are a number of other important concepts concerning types regarding the visibility of their components and operations which may be described as providing different views of a type. For example, a private type is a type defined in a package whereby the full details of the implementation of the type are only visible inside the body and private part of the package. Private types are of fundamental importance in providing data abstraction. Furthermore, a limited type is a type for which certain operations such as predefined assignment are not available. A type may be inherently limited (such as a task type or a protected type or a record type marked explicitly as limited) or it may be that just a certain view is limited. Thus a private type may be declared as limited and the full type as seen by the body need not be limited. === <span id="1-3">III.1.3 Operations and Overloading</span> === There is a set of operations associated with each type. An operation is associated with a type if it takes parameters of the type, or returns a result of the type. Some operations are implicitly provided when a type is defined; others are explicitly declared by the user. A set of operations is implicitly provided for each type declaration. Which operations are implicitly provided depends on the type, and may include any of the following * Syntactic constructs, such as assignment, component selection, literals and attributes. These use special syntax specific to the operation. For example, an attribute takes the form X'Attr, where X is the name of an entity, and Attr is the name of an attribute of that entity. Thus, Integer'First yields the lower bound of the type Integer. * Predefined operators. These are taken from this set of 21 operator symbols ** Logical operators: and or xor ** Relational operators: = /= < <= > >= ** Binary adding operators: + - & ** Unary adding operators: + - ** Multiplying operators: * / mod rem ** Highest precedence operators: ** abs not * Enumeration literals. * Derived operations, which are inherited by a derived type from its parent type (as explained below). The explicitly declared operations of the type are the subprograms that are explicitly declared to take a parameter of the type, or to return a result of the type. There are two kinds of subprograms: procedures and functions. A procedure defines a sequence of actions; a procedure call is a statement that invokes those actions. A function is like a procedure, but also returns a result; a function call is an expression that produces the result when evaluated. Subprogram calls may be indirect, through an access value. Procedures may take parameters of mode in, which allows reading of the parameters, mode out, which allows writing of the parameters, and mode in out, which allows both reading and writing of the parameters. In Ada 95, a parameter of mode out behaves like a variable and both reading and writing are allowed; however, it is not initialized by the actual parameter. All function parameters are of mode in. An in parameter may be an access parameter. Within the subprogram, an access parameter may be dereferenced to allow reading and writing of the designated object. The primitive operations of a type are the implicitly provided operations of the type, and, for a type immediately declared within a package specification, those subprograms of the type that are also explicitly declared immediately within the same package specification. A derived type inherits the primitive operations of its parent type, which may then be overridden. The name of an explicitly declared subprogram is a designator, that is, an identifier or an operator symbol (see the list of operator symbols above). Operators are a syntactic convenience; the operator notation is always equivalent to a function call. For example, X + 1 is equivalent to "+"(X, 1). When defining new types, users can supply their own implementations for any or all of these operators, and use the new operators in expressions in the same way that predefined operators are used. The benefits of being able to use the operator symbol "+" to refer to the addition function for every numeric type are apparent. The alternative of having to create a unique name for each type's addition function would be cumbersome at best. The operators are just one example of overloading, where a designator (e.g., "+") is used as the name for more than one entity. Another example of overloading occurs whenever a new type is derived from an existing one. The new type inherits operations from the parent type, including the designators by which the operations are named; these designators are overloaded on the old and new types. Finally, the user may introduce overloading simply by defining several subprograms that have the same name. Overloaded subprograms must be distinguishable by their parameter and result types. The user can also provide new meanings for existing operators. For example, a new meaning of "=" can be provided for all types (only for limited types in Ada 83). Ada compilers must determine a unique meaning for every designator in a program. The process of making this determination is called overload resolution. The compiler uses the context in which the designator is used, including the parameter and result types of subprograms, to perform the overload resolution. If a designator cannot be resolved to a single meaning, then the program is illegal; such ambiguities can be avoided by specifying the types of subexpressions explicitly. Many attributes are defined by the language. Attributes denote various properties, often defined for various classes of Ada's type hierarchy. In some cases, attributes are user-specifiable via an attribute definition clause, allowing users to specify a property of an entity that would otherwise be chosen by default. For example, the ability to read and write values of a type from an external medium is provided by the operations T'Read and T'Write. By writing <syntaxhighlight lang="Ada"> type Matrix is ... for Matrix'Read use My_Matrix_Reader; for Matrix'Write use My_Matrix_Writer;</syntaxhighlight> the predefined operations are overridden by the user's own subprograms. === <span id="1-4">III.1.4 Class Wide Types and Dispatching</span> === Associated with each tagged type T is a class-wide type T'Class. Class- wide types have no operations of their own. However, users may define explicit operations on class-wide types. For example <syntaxhighlight lang="Ada"> procedure Print(A: in Animal'Class); -- Print human-readable information about an Animal</syntaxhighlight> The procedure Print may be applied to any object within the class of animals described above. A programmer can define several operations having the same name, even though each operation has a different implementation. The ability to give distinct operations the same name can be used to indicate that these operations have similar, or related, semantics. When the intended operation can be determined at compile time, based on its parameter and result types, overloading of subprogram names is used. For example, the predefined package Text_IO contains many operations called Put, all of which write a value of some type to a file. The implementation of Put is different for different types. Dispatching provides run-time selection of the proper implementation in situations where the type of an argument to an operation cannot be determined until the program is executed, and in fact might be different each time the operation is invoked. Ada 95 provides dispatching on the primitive operations of tagged types. When a primitive operation of a tagged type is called with an actual parameter of a class-wide type, the appropriate implementation is chosen based on the tag of the actual value. This choice is made at run time and represents the essence of dynamic polymorphism. (Note that, in some cases, the tag can be determined at compile time; this is simply regarded as an optimization.) Continuing the example from above, we demonstrate both overloading and dispatching <syntaxhighlight lang="Ada"> procedure Print(S: in String); -- Print a string procedure Print(A: in Animal'Class) is -- Print information on an animal begin Print(Image(A)); end Print;</syntaxhighlight> The Print operation is overloaded. One version is defined for String and a second is defined for Animal'Class. The call to Print within the second version resolves at compile time to the version of Print defined on String (because Image returns a String); no dispatching is involved. On the other hand, Image (see example in III.1.2) is indeed a dispatching operation: depending on the tag of A the version of Image associated with Animal or Mammal etc, will be called and this choice is made at runtime. === <span id="1-5">III.1.5 Abstraction and Static Evaluation</span> === The emphasis on high performance in Ada applications, and the requirement to support interfacing to special hardware devices, mean that Ada programmers must be able to engineer the low-level mapping of algorithms and data structures onto physical hardware. On the other hand, to build large systems, programmers must operate at a high level of abstraction and compose systems from understandable building blocks. The Ada type system and facilities for separate compilation are ideally suited to reconciling these seemingly conflicting requirements. Ada's support for static checking and evaluation make it a powerful tool, both for the abstract specification of algorithms, and for low- level systems programming and the coding of hardware-dependent algorithms. By static, we mean computations whose results can be determined by analyzing the source code without knowing the values of input data or any other environmental parameters that can change between executions of the program. Ada requires static type checking. The "scope" (applicability or lifetime) of declarations is determined by the source code. Careful attention is given to when the sizes of objects are determined. Some objects' sizes are static, and other objects' sizes are not known until run time, but are fixed when the objects are created. The size of an object is only allowed to change during program execution if the object's size depends on discriminant values, and the discriminants have a default value. Other variable-size data structures can be created using dynamically allocated objects and access types. Ada supports users who want to express their algorithms at the abstract level and depend on the compiler to choose efficient implementations, as well as users who need to specify implementation details but also want to declare the associated abstractions to the compiler to facilitate checking during both initial development and maintenance. == <span id="2"> III.2 Statements, Expressions and Elaboration </span> == Statements are executed at run time to cause an action to occur. Expressions are evaluated at run time to produce a value of some type. Names are also evaluated at run time in the general case; names refer to objects (containing values) or to other entities such as subprograms and types. Declarations are elaborated at run time to produce a new entity with a given name. Many expressions and subtype constraints are statically known. Indeed, the Ada compiler is required to evaluate certain expressions and subtypes at compile time. For example, it is common that all information about a declaration is known at compile time; in such cases, the run-time elaboration need not actually execute any machine code. The language defines a mechanism that allows Ada compilers to preelaborate certain kinds of units; i.e., the actual actions needed to do the elaboration are done once before the program is ever run instead of many times, each time it is run. === <span id="2-1">III.2.1 Declarative Parts</span> === Several constructs of the language contain a declarative part followed by a sequence of statements. For example, a procedure body takes the form <syntaxhighlight lang="Ada"> procedure P(...) is I: Integer := 1; -- this is the declarative part ... begin ... -- this is the statement sequence I := I * 2; ... end P;</syntaxhighlight> The execution of the procedure body first elaborates all of the declarations given in the declarative part in the order given. It then executes the sequence of statements in the order given (unless a transfer of control causes execution to go somewhere other than to the next statement in the sequence). The effect of elaborating the declarations is to cause the declared entities to come into existence, and to perform other declaration- specific actions. For example, the elaboration of a variable declaration may initialize the variable to the value of some expression. Often, such expressions are evaluated at compile time. However, if the declarations contain non-static expressions, then the elaboration will need to evaluate those expressions at run-time. Controlled types allow programmers a means to define what happens to objects at the beginning and end of their lifetimes. For such types, the programmer may define an initialization operation, to be automatically invoked when an object of the type is elaborated, and a finalization operation to be automatically invoked when the object becomes inaccessible. (Declared objects become inaccessible when their scope is left. Objects created by allocators become inaccessible when Unchecked_Deallocation is called, or when the scope of the access type is left.) Controlled types provide a means to reliably program dynamic data structures, prevent storage leakage, and leave resources in a consistent state. === <span id="2-2">III.2.2 Assignments and Control Structures</span> === An assignment statement causes the value of a variable to be replaced by that of an expression of the same type. Assignment is normally performed by a simple bit copy of the value provided by the expression. However, in the case of nonlimited controlled types, assignment can be redefined by the user. Case statements and if statements allow selection of an enclosed sequence of statements based on the value of an expression. The loop statement allows an enclosed sequence of statements to be executed repeatedly, as directed by an iteration scheme, or until an exit statement is encountered. A goto statement transfers control to a place marked with a label. Additional control mechanisms associated with multitasking and exception handling are discussed below (see III.4 and III.5). === <span id="2-3">III.2.3 Expressions</span> === Expressions may appear in many contexts, within both declarations and statements. Expressions are similar to expressions in most programming languages: they may refer to variables, constants and literals, and they may use any of the value-returning operations described in III.1.3. An expression produces a value. Every expression has a type that is known at compile time. == <span id="3"> III.3 System Construction </span> == Ada was designed specifically to support the construction of large, complex, software systems. Therefore, it must allow the composition of programs from small, understandable building blocks, while still allowing programmers to engineer the low-level mapping of algorithms and data structures onto physical hardware. Ada provides support for modern software development techniques with the following capabilities * Packaging, the grouping together of logically related entities into packages. * Information hiding, where the programmer defines the interface of a program unit for the users of that unit, and separately defines the implementation of the unit. * Object-oriented programming, where objects can be defined in terms of preexisting objects with possible extension, overload resolution can be used to select operations at compile time, and dispatching can be used to select operations at run time. * Construction of software systems from large numbers of separately compiled units stored in a library, with full compile-time checking of interfaces between separately compiled units. * Class-wide programming. * Construction of mixed language systems, that is programs written in more than one programming language. The following subsections describe this support in more detail. === <span id="3-1">III.3.1 Program Units</span> === Ada programs are composed of the following kinds of program units * Subprograms - functions and procedures. * Packages - groups of logically related entities. * Generic units - parameterized templates for subprograms and packages. * Tasks - active entities that may run in parallel with each other. * Protected objects - passive entities that protect data shared by multiple tasks. Program units may be nested within each other, in the same way as in other block-structured languages. Furthermore, they may be separately compiled. As we shall see later, packages at the so-called library level may have child units. Ada has a hierarchical structure both at the external level of compilation and internal to a program unit. Each program unit may be given in two parts: The specification defines the interface between the unit (the "server") and its users ("clients"). The body defines the implementation of the unit; users do not depend on the implementation details. For packages, the specification consists of the visible part and the private part. The visible part defines the logical interface to the package. The private part defines the physical interface to the package, which is needed to generate efficient code, but has no effect on the logical properties of the entities exported by the package. Thus, the private part may be thought of as part of the implementation of the package, although it is syntactically part of the specification in order to ease the generation of efficient code. The various parts of a package take the following form <syntaxhighlight lang="Ada"> -- this is a package specification: package Example is -- this is the visible part -- declarations of exported entities appear here type Counter is private; procedure Reset(C: in out Counter); procedure Increment(C: in out Counter); -- private -- this is the private part -- declarations appearing here are not exported type Counter is range 0 .. Max; end Example; -- this is the corresponding package body: package body Example is -- implementations of exported subprograms appear here -- entities that are used only in the implementation -- are also declared here Zero: constant Counter := 0; -- declaration of constant only used in the body procedure Reset(C: in out Counter) is begin C := Zero; end Reset; procedure Increment(C: in out Counter) is begin C := C + 1; end Increment; end Example;</syntaxhighlight> Tasks and protected objects may also have a private part. === <span id="3-2">III.3.2 Private Types and Information Hiding</span> === Packages support information hiding in the sense that users of the package cannot depend on the implementation details that appear in the package body. Private types provide additional information-hiding capability. By declaring a type and its operations in the visible part of a package specification, the user can create a new abstract data type. When a type is declared in a package specification, its implementation details may be hidden by declaring the type to be private. The implementation details are given later, as a full type declaration in the private part of the package. The user of a private type is not allowed to use information about the full type. Users may declare objects of the private type, use the assignment and equality operations, and use any operations declared as subprograms in the visible part of the package. The private type declaration may allow users to refer to discriminants of the type, or it may keep them hidden. A private type may also be declared as limited, in which case even assignment and predefined equality operations are not available (although the programmer may define an equality operation and export it from the package where the type is declared). In the private part, in the body of the package, and in the appropriate parts of child library units (see III.3.6), the type is not private: all operations of the type may be used in these places. For example, if the full type declaration declares an array type, then outside users of the type are not allowed to index array components, because these implementation details are hidden. However, code in the package body is allowed the complete set of array operations, because it can see the full type declaration. === <span id="3-3">III.3.3 Object Oriented Programming</span> === Modern software development practices call for building programs from reusable parts, and for extending existing systems. Ada supports such practices through object oriented programming features. The basic principle of object oriented programming is to be able to define one part of a program as an extension of another, pre-existing, part. The basic building blocks of object-oriented programming were discussed in III.1. Abstract data types may be defined in Ada using packages and private types. Types may be extended by adding new packages, deriving from existing types, and adding new operations to derived types. For non- tagged types, such extension is "static" in the sense that the compiler determines which operations apply to which objects according to the typing and overloading rules. For tagged types, however, operation selection is determined at run time, using the tag carried by each such object. This allows easy extension of existing types. To add a new tagged type, the programmer derives from an existing tagged parent type, possibly adding new record components. The programmer may override existing operations with new implementations. Then, all calls to the existing operation will automatically call the new operation in the appropriate cases; there is no need to change or even to recompile such pre-existing code. For tagged types, it is possible to write class-wide operations by defining subprograms that take parameters of a class-wide type. Class-wide programming allows the programmer to avoid redundancy in cases where an operation makes sense for all types in a class, and where the implementation of that operation is essentially the same for all types in the class. === <span id="3-4">III.3.4 Generic Units</span> === Generic program units allow parameterization of program units. The parameters can be types and subprograms as well as objects. A normal (non-generic) program unit is produced by instantiating a generic unit; the normal program unit is said to be an instance of the generic unit. An instance of a generic package is a package; an instance of a generic subprogram is a subprogram. The instance is a copy of the generic unit, with actual parameters substituted for generic formal parameters. Generic units may be implemented by actually generating new code for each instance, or by sharing the code for multiple instances, and passing information about the parameters at run time. An example of a generic package is a generic linked list package that works for any element type. The data type of the elements would be passed in as a parameter. The algorithms for manipulating the lists are independent of the actual element type. Instances of the generic package would support linked lists with a particular element type. If the element type is a tagged class-wide type, then heterogeneous lists can be created, containing elements of any type in the class. Generic formal derived types permit generic units to be developed for derivation classes. Generic formal packages allow a generic unit to be parameterized by an instance of another generic package. === <span id="3-5">III.3.5 Separate Compilation</span> === Ada allows the specifications and bodies of program units to be separately compiled. A separately compiled piece of code is called a compilation unit. The Ada compiler provides the same level of compile- time checking across compilation units as it does within a single compilation unit. For example, in a procedure call, the actual parameters must match the types declared for the formal parameters. This rule is checked whether the procedure declaration and the procedure call are in the same compilation unit, or different compilation units. Ada compilers work within the context of a program environment, which contains information about the compilation units in a program. This information is used in part to check rules across compilation unit boundaries. There are rules about order of compilation that ensure that the compiler always has enough information to check all the rules. For example, a specification must be within the environment before all units that have visibility to names declared in that specification can be compiled. === <span id="3-6">III.3.6 Library Units</span> === A program environment contains information concerning a collection of library units. Library units may be packages, subprograms, or generic units. Package library units may have child library units. Thus, an entire hierarchy of library units may be created: the root of each tree is called a root library unit; the tree contains the root library unit, plus all of its children and their descendants. A library unit specification and its body are compilation units; that is, they may be compiled separately. Visibility among library units is achieved using context clauses; a compilation unit can see a particular library unit if it names that library unit in a context clause. Both root library units and child units may be named in a context clause. In addition, the child library units of a parent can see the parent, including the parent's private declarations, and the body of a unit always has visibility into its specification. Child units may be used to reduce recompilation costs. Apart from dependencies created by context clauses, the immediate children of a given unit may be recompiled in any order. Therefore, if an existing library unit is extended by adding a child unit, the existing unit need not be recompiled; adding a child is accomplished without changing the source code of the parent. More importantly, other units that depend on the existing parent unit will not need to be recompiled. The root library units are considered to be children of package Standard: context clauses and compilation ordering rules work the same way. Thus, child units are a straightforward generalization of Ada 83 library units. As an example consider the following <syntaxhighlight lang="Ada"> package Root is -- specification of a root library unit ... end Root; ------------------------------- package Root.Child is -- specification of a child library unit ... end Root.Child; ------------------------------- package body Root.Child is -- body of the child library unit ... end Root.Child; ------------------------------- private package Root.Local_Definitions is -- a private child package specification ... end Root.Local_Definitions; ------------------------------- package body Root is -- body of the root library unit ... end Root;</syntaxhighlight> The lines in the above example indicate the separate compilation units; they may be submitted to the compiler separately. Note that the child library units are clearly distinguishable by their expanded names (based on the parent's name). The example also shows a private child package - a private child unit is visible only within the hierarchy of units rooted at its parent. Sometimes, the body of a library unit becomes very large, because it contains one or more nested bodies. In such cases, Ada allows the nested bodies to be separately compiled as subunits. The nested body is replaced by a body stub. The subunit, which is given separately, must name its parent unit. Visibility within the subunit is as if it had appeared at the place where its body stub occurs. Subunits also support an incremental style of top-down development, because a unit may be compiled with one or more body stubs - allowing the development of those bodies to be deferred. === <span id="3-7">III.3.7 Program Composition</span> === An executable software system is known in Ada as a program. A program is composed of one or more compilation units. A program may be divided into separate partitions, which may represent separate address spaces. Implementations may provide mechanisms for user-defined inter-partition communication. The Distributed Systems annex defines a minimal standard interface for such communication. Partitions are intended to support distributed processing, as explained in the annex. Of course, many programs will not be partitioned; such programs consist of a single partition. To build a partition, the user identifies a set of library units to be included. The partition consists of those library units, plus other library units depended on by the named units. The Ada implementation automatically constructs this set of units before run time. Each partition has an environment task, which is provided automatically by the Ada implementation. A partition may have a main subprogram, which must be a library unit subprogram. The environment task elaborates all of the library units that are part of the partition, and their bodies, in an appropriate order, and then calls the main subprogram, if any. The library units and the main program may create other tasks. Thus, an executing partition may contain a hierarchy of tasks, rooted at the environment task. === <span id="3-8">III.3.8 Interfacing to Other Languages</span> === Large programs are often composed of parts written in several languages. Ada supports this by allowing inter-language subprogram calls, in both directions, and inter-language variable references, in both directions. The user specifies these interfaces using pragmas. == <span id="4"> III.4 Multitasking </span> == Ada tasking provides a structured approach to concurrent processing under the control of an Ada run-time system, which provides services such as scheduling and synchronization. This describes tasks and the methods that are used for synchronizing task execution and for communicating between tasks. Tasking is intended to support tightly coupled systems in which the communication mechanisms may be implemented in terms of shared memory. Distributed processing, where the processors are loosely coupled, is addressed in the Distributed Systems annex. === <span id="4-1">III.4.1 Tasks</span> === Tasks are entities whose execution may proceed in parallel. A task has a thread of control. Different tasks proceed independently, except at points where they synchronize. If there is a sufficient number of processors, then all tasks may execute in parallel. Usually, however, there are more tasks than processors; in this case, the tasks will time-share the existing processors, and the execution of multiple tasks will be interleaved on the same processor. A task is an object of a task type. There may be more than one object of a given task type. All objects of a given task type have the same entries (interface), and share the same code (body). As a result they all execute the same algorithm. Different task objects of the same type may be parameterized using discriminants. Task types are inherently limited types; assignment and equality operations are forbidden. Task objects are created in the same ways as other objects: they may be declared by an object declaration, or created dynamically using an allocator. Tasks may be nested within other program units, in the same manner as subprograms and packages. All tasks created by a given declarative part or allocator are activated in parallel. This means that they can logically start running in parallel with each other. The task that created these tasks waits until they have all finished elaborating their declarative parts; it then continues running in parallel with the tasks it created. Every task has a master, which is the task, subprogram, block statement, or accept statement which contains the declaration of the task object (or an access type designating the task type, in some circumstances). The task is said to depend on its master. The task executing the master is called the parent task. Before leaving a master, the parent task waits for all dependent tasks. When all of those have been terminated, or are ready to terminate, the parent task proceeds. Tasks may be terminated prematurely with the abort statement. === <span id="4-2">III.4.2 Communication and Synchronization</span> === For multiple tasks to cooperate, there must be mechanisms that allow the tasks to communicate and to synchronize their execution. Synchronization and communication usually go hand-in-hand. Ada tasks synchronize and communicate in the following situations * Tasks synchronize during activation and termination (as just explained). * Protected objects provide synchronized access to shared data. * Rendezvous are used for synchronous communication between a pair of tasks. * Finally, unprotected access to shared variables is allowed, but requires a disciplined protocol to be followed by the communicating tasks. This flexibility allows the user to choose the appropriate synchronization and communication mechanisms for the problem at hand. They are depicted in Table III-1. <syntaxhighlight lang="Ada">+----------------------------------------------------------------------+ | Ada feature Synchronization Communication | |----------------------------------------------------------------------| | | |Task Creation (not needed) Creator initializes | | discriminants | | of new task | | | |Task Activation Creator waits for tasks Activation failure | | being activated might be reported | | | |Task Termination Master waits for (none) | | children | | | |Rendezvous Entry caller and acceptor Entry parameters are | | wait for each other passed between the | | entry callerand the | | acceptor | | | |Protected Object Mutual exclusion during Tasks communicate | | data access; queued indirectly by | | waiting for entry barriers reading and writing the| | components of | | protected objects | | | |Unprotected User-defined, low-level Reading and writing of | |Shared Variables synchronization shared variables | +----------------------------------------------------------------------+ Table III-1: Summary of Communication and Synchronization</syntaxhighlight> === <span id="4-3">III.4.3 Protected Objects</span> === Protected types are used to synchronize access to shared data. A protected type may contain components in a private part. Moreover, a protected type may also contain functions, procedures, and entries - the protected operations of the protected type. The data being shared is declared either as components of the protected type, or as global variables, possibly designated by the components of the protected type. Protected types are inherently limited. Calls to the protected operations are synchronized as follows. Protected functions provide shared read-only access to the shared data. Multiple tasks may execute protected functions at the same time. Protected procedures and entries provide exclusive read/write access to the shared data. If any task is executing a protected procedure or entry, then no other tasks are allowed to execute any protected operation at the same time; if they try, they must wait. Protected objects provide a safe and efficient method of synchronizing shared data access. They are safe, because they perform the necessary synchronization operations automatically, and because all synchronizing operations are collected together syntactically. (This is in contrast to lower-level mechanisms such as semaphores, where the user of the shared data must remember to lock and unlock the semaphore.) They are efficient, because their intended implementation is close to the hardware: such as spin-locks in multiprocessor systems. === <span id="4-4">III.4.4 Protected Operations and Entries</span> === Protected types may export functions, procedures, and entries as described above. Tasks may export entries. All of these operations are called using similar syntax: OBJ.OP(...), where OBJ is the name of the task or protected object, OP is the name of the operation, and (...) represents any actual parameters. Information is passed back and forth using in, in out, out parameters. It is the responsibility of the programmer to ensure that operations of protected objects execute for a bounded and short period of time. A client task which calls an entry of a server task or protected object may be blocked and placed on a queue. When a server task accepts the entry call from a client task, we say that the two tasks are in rendezvous. At the beginning and the end of the rendezvous, data may be exchanged via parameters. When the rendezvous is over, the two tasks each continue execution in parallel. Entries of protected objects are controlled by barrier expressions. When a task calls the entry, it can execute the operation immediately if the barrier expression is true; otherwise, the caller is placed on a queue until the barrier has become true. Protected functions and procedures do not have barrier expressions and, therefore, calls on them need not be queued. From within a rendezvous or the entry body of a protected type it is possible to complete the interaction by requeuing on a further entry; this avoids race conditions which might occur with two quite distinct interactions. Entries may also be declared in the private part of a task or protected object and thus not visible to external clients. Such entries may be called by internal tasks or by requeuing. === <span id="4-5">III.4.5 Select Statements</span> === Select statements are used to specify that a task is willing to wait for any of a number of alternative events. Select statements take various forms. Select statements used by a server task may contain * One or more accept alternatives, which indicate that the task is willing to accept one of several entries; that is, the task waits for another task to call one of those entries. * An optional terminate alternative, which allows a server task to specify that it is willing to terminate if there is no more work to do (i.e., all other tasks that depend on the same master are either terminated or are waiting at terminate alternatives). Select statements used by a client task may contain * One entry call alternative, which indicates that the task is waiting for an entry to be executed. That is, the task waits either for the server task to accept the entry, or for the protected object barrier to become true. Both of these forms of select statement can also contain, either * A delay alternative, which allows a task to specify an action to be taken if communication is not started within a given period of time, or * An else part, which allows a task to specify an action to be taken if communication is not immediately possible. Whichever alternative becomes available first is chosen. Each alternative specifies an action to be executed if and when the alternative is chosen. The final form of select statement provides for an asynchronous transfer of control; it contains * A triggering alternative, which may be a delay alternative or an entry call followed by a sequence of statements, and * An abortable part, which is aborted if the triggering alternative completes before the abortable part itself completes. Control is then asynchronously transferred from somewhere in the abortable part to the statements of the triggering alternative. If the abortable part completes before being aborted, then the triggering alternative is cancelled and execution continues at the next statement after the select statement. === <span id="4-6">III.4.6 Timing</span> === Ada provides features for measuring real time. A task may read the clock to find out what time it is. A task may delay for a certain period of time, or until a specific time. As mentioned above, a delay alternative may be used to provide a time- out for communication or as a triggering event for initiating an asynchronous transfer of control. === <span id="4-7">III.4.7 Scheduling</span> === Ada separates the concepts of synchronization and scheduling. Synchronization operations determine when tasks must block, and when they are ready to run. Scheduling is the method of allocating processors to ready tasks. The default scheduling policy is defined by the language. The Real-Time Systems annex defines another, priority-based, scheduling policy, based on a dispatching model. Finally, implementations are allowed to add their own policies, which can be specified by pragmas. == <span id="5"> III.5 Exception Handling </span> == Most programs need to recover gracefully from errors that occur during execution. Exception handling allows programs to handle such error situations without ceasing to operate. An exception is used to name a particular kind of error situation. Some exceptions are predefined by the language; others may be defined by the user. Exceptions are declared in the same way as other entities <syntaxhighlight lang="Ada"> Buffer_Full_Error: exception;</syntaxhighlight> This exception might be used to represent the situation of a program trying to insert data into a buffer which is already full. When the exceptional situation happens, the exception is raised. Language-defined exceptions are raised for errors in using predefined features of the language. These exceptions correspond to run-time errors in other languages. For example, the language-defined exception Constraint_Error is raised when a subtype constraint is violated at run time. User-defined exceptions are raised by the raise statement. To continue the Buffer_Full_Error example above, the implementation of the buffer data type might contain statements such as <syntaxhighlight lang="Ada"> if Buffer_Index > Max_Buffer_Size then raise Buffer_Full_Error; end if;</syntaxhighlight> Subprograms, package bodies, block statements, task bodies, entry bodies, and accept statements may have exception handlers. An exception handler specifies an action that should be performed when a particular exception is raised. When an exception is raised, the execution of the current sequence of statements is abandoned, and control is transferred to the exception handler, if there is one. Thus, the action of the exception handler replaces the rest of the execution of the sequence of statements that caused the error condition. If there is no exception handler in a particular scope, then the exception is propagated to the calling scope. If the exception is propagated all the way out to the scope of the environment task, then execution of the program is abandoned; this is similar to the way in which program execution is abandoned in other languages when run-time errors are detected. The following example shows a block with two exception handlers <syntaxhighlight lang="Ada"> begin ... exception when Buffer_Full_Error => Reset_Buffer; when Error: others => Put_Line("Unexpected exception raised:"); Put_Line(Ada.Exceptions.Exception_Information(Error)); end;</syntaxhighlight> The handlers recognize two situations: if Buffer_Full_Error is raised, the buffer is reset. If any other exception is raised, information about that exception is printed. For many applications, it is useful to get such information about an exception when it occurs. A handler may have a choice parameter (Error in the example above) of type Exception_Occurrence. The predefined function Exception_Information takes a parameter of this type and returns a String, providing information (including the name) about the exception. These and other related facilities are defined in a child of package Ada. == <span id="6"> III.6 Low Level Programming </span> == Although the majority of program text can be written in a machine- independent manner, most large software systems contain small portions that need to depend on low-level machine characteristics. Ada allows such dependence, while still allowing the high-level aspects of the algorithms and data structures to be described in an abstract manner. Many of an implementation's machine-specific characteristics are accessible through the package System. This defines storage-related types, an Address type, and relational and arithmetic operations on addresses. === <span id="6-1">III.6.1 Pragmas</span> === A pragma is used to convey information to the compiler; it is similar to a compiler directive supported by other languages. A pragma begins with the reserved word pragma, an identifier which is the name of the pragma, and optionally one or more arguments. Some pragmas are defined by the language. For example, pragma Inline indicates to the compiler that the code for a subprogram is to be expanded inline at each call whenever possible. Most pragmas apply to a single object, type, or program unit. Configuration pragmas are used to specify partition-wide or program-wide options. Implementations may provide additional pragmas, as long as they do not syntactically conflict with existing ones or use reserved words. Unrecognized pragmas have no effect on a program, but their presence must be signaled with a warning message. === <span id="6-2">III.6.2 Specifying Representations</span> === Normally, the programmer lets the Ada compiler choose the most efficient way of representing objects. However, Ada also provides representation clauses, which allow the user to specify the representation of an individual object, or of all objects of a type. Other representation clauses apply to program units. The programmer may need to specify that the representation matches the representation used by some hardware or software external to the Ada program, in order to interface to that external entity. Or, the programmer may wish to specify a more efficient representation of certain objects in cases where the compiler does not have enough information to determine the best (most efficient) representation. In either case, data types and objects are first declared in the normal manner, giving their logical properties. Later in the same declarative part, the programmer gives the representation clauses. In addition to representation clauses, the language defines certain pragmas that control aspects of representation. Implementations may provide additional representation pragmas. There are predefined attributes that allow users to query aspects of representation. These are useful when the programmer needs to write code that depends upon the representation, although the user might not need to control the representation. In the absence of representation clauses or pragmas, the compiler is free to choose any representation. === <span id="6-3">III.6.3 Unprotected Shared Variables</span> === In Ada, variables may be shared among tasks according to the normal visibility rules: if two tasks can see the name of the same variable, then they may use that variable as shared data. However, it is up to the programmer to properly synchronize access to these shared variables. In most cases, data sharing can be achieved more safely with protected objects; unprotected shared variables are primarily used in low-level systems programming. Ada allows the user to specify certain aspects of memory allocation and code generation that may affect synchronization by specifying variables as volatile or atomic. === <span id="6-4">III.6.4 Unchecked Programming</span> === Ada provides features for bypassing certain language restrictions. These features are unchecked; it is the programmer's responsibility to make sure that they do not violate the assumptions of the rest of the program. For example, there are mechanisms for manipulating access types that might leave dangling pointers, and there is a mechanism for converting data from one type to another, bypassing the type-checking rules. The generic function Unchecked_Deallocation frees storage allocated by an allocator. It is unchecked in the sense that it can leave dangling pointers. The generic function Unchecked_Conversion converts data from one type to another, bypassing all type-checking rules. The conversion is done simply by reinterpreting the bit pattern as a value of the target type; no conversion actually happens at run time (except possibly bit padding or truncation). The attribute P'Unchecked_Access returns a typed access value to any aliased object of the appropriate type, bypassing the accessibility checking rules (but not the type rules). == <span id="7"> III.7 Standard Library </span> == All implementations provide a standard library of various packages. This includes the predefined package Standard which defines the predefined types such as Integer, and the package System which defines various entities relating to the implementation. The standard library also includes packages Ada and Interfaces. The package Ada includes child packages for computing elementary functions and generating random numbers as well as child packages for string handling and character manipulation. The package Interfaces defines facilities for interfacing to other languages. === <span id="7-1">III.7.1 Input Output</span> === Input-output capabilities are provided in Ada by predefined packages and generic packages. * Sequential files present a logical view of files as sequences of elements. Successive read or write operations to a sequential file result in the transfer of consecutive elements. The generic package Sequential_IO may be instantiated for any type to provide operations for creating, opening, closing, deleting, reading and writing sequential files. All elements of a Sequential_IO file are of the same type, although if the type is a tagged class-wide type, the elements may have different tags. * Direct files present a logical view of files as indexed sets of elements. The index allows elements to be read or written at any position within a file. The generic package Direct_IO provides operations similar to Sequential_IO. In addition, Direct_IO provides operations for determining the current position and size of a file, and setting the position in the file, in terms of element numbers. * The Text_IO package provides facilities for input and output in a human-readable form. * A stream presents a logical view of a file (or other external medium such as a buffer or network channel) as a sequence of stream elements. Stream input and output are predefined through attributes for all nonlimited types. Users may override these default attributes and the stream operations. == <span id="8"> III.8 Application Specific Facilities </span> == Previous sections of this Overview have focused on the Core of the Ada language. Implementations may provide additional features, not by extending the language itself, but by providing specialized packages and implementation-defined pragmas and attributes. In order to encourage uniformity among implementations, without restricting functionality, the Specialized Needs Annexes define standards for such additional functionality for specific application areas. Implementations are not required to support all of these features. For example, an implementation specifically targeted to embedded machines might support the application-specific features for Real-Time Systems, but not the application-specific features for Information Systems. The application areas discussed in the Annexes are * Systems Programming, including access to machine operations, interrupts, elaboration control, low-level shared variables, and task identification facilities. * Real-Time Systems, including priorities, queuing and scheduling policies, monotonic time, delay accuracy, immediate abort and a simple tasking model. * Distributed Systems, including a model for Ada program distribution into partitions and inter-partition communication. * Information Systems, including detailed support for decimal types and picture formatting. * Numerics, including a model of real arithmetic plus packages for complex numbers. * Safety and Security, including pragmas relating to the proof of correctness of programs. == <span id="9"> III.9 Summary </span> == The goal of this chapter has been to provide a broad overview of the whole of the Ada language. It also demonstrates that the changes to the language represent a natural extension to the original design of Ada. As a consequence, the incompatibilities between Ada 83 and Ada 95 are minimal. Those of practical significance are described in detail in Appendix X. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p1-2|Previous]] | [[Guide:9x_rationale/rat95-p2|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=III Overview of the Ada Language }} sejcf0gfeynd233cu7hcgd79ulvdfuj Guide:9x rationale/rat95-p2 4200 330 1848 1815 2019-04-20T16:19:35Z WikiVisor 11 Text replacement - "|Next]]" to "|Next]]</div>" wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p1-3|Previous]] | [[Guide:9x_rationale/rat95-p2-1|Next]]</div> ''Part One should have given the reader an overall appreciation of the scope and some of the details of Ada 95. The discussion included some rationale for the main features but did not go into all the details. This second part takes the discussion of the Core language a step further. It covers those important features not discussed in Part One and gives more detail of the rationale including alternatives that were considered and rejected. It is assumed that the reader is familiar with the material in Part One which will be referred to from time to time. It is recommended that this part be read in conjunction with the Ada 95 Reference Manual.'' <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p1-3|Previous]] | [[Guide:9x_rationale/rat95-p2-1|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=Part Two. The Core Language}} ann5ujmm0ur415xt59gq52hxpigt5uw Guide:9x rationale/rat95-p2-1 4200 331 1846 1823 2019-04-20T16:19:35Z WikiVisor 11 Text replacement - "|Next]]" to "|Next]]</div>" wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2|Previous]] | [[Guide:9x_rationale/rat95-p2-2|Next]]</div> This second part of the rationale is arranged to generally correspond to the sections in the Ada 95 Reference Manual [RM95]. Thus the discussion on exceptions which is covered in section 11 of [RM95] will be found in Chapter 11 of this part. The only exception to this is that the material covered by sections 3 and 4 of [RM95] is subdivided differently. Chapter 3 of this volume covers types and expressions in general whereas Chapter 4 concentrates on the object oriented features such as type extension and class-wide types. In a similar way the chapters of the third part correspond to the annexes of [RM 95]; thus chapter C discusses the Systems Programming Annex which is annex C of [RM 95]. Each chapter of this second part starts with a brief summary of the changes, there are then a number of sections addressing the various topics, and finally there is a summary of the requirements addressed by the chapter. This first chapter briefly covers the following general issues * The description of Ada 95 uses more defined terms and there is less reliance on informal English. * The syntax is expanded to bring more rules into the syntax and to increase clarity. * The categorization of errors is revised and includes the introduction of the concept of bounded errors. However, before getting down to detail it is appropriate to start with a few words about the approach adopted in the development of Ada 95. == <span id="1">1.1 Overall Approach</span> == Ada 95 is based on a building block approach. Rather than providing a number of new language features to directly solve each identified application problem, the extra capability of Ada 95 is provided by a few primitive language building blocks. In combination, these building blocks enable programmers to solve more application problems efficiently and productively. Thus in the case of the object oriented area, much of the capability is provided by the interweaving of the properties of type extension, the child libraries and generic packages. Great care has been taken to ensure that the additional building blocks work together in a cohesive and helpful manner. Nevertheless implementation and understandability considerations have sometimes caused some restrictions to be imposed. An example is that type extension of a formal generic parameter is not permitted in a generic body (which would either break the contract model or pose an intolerable pervasive implementation burden). An area of particular difficulty in tasking is the provision of mutual exclusion (which is done in implementation terms by imposing semaphores and locks at appropriate places). Much of the difficulty with Ada 83 tasking lay in the composition of facilities to provide general paradigms and especially the provision of guarded services. Attempts to solve such problems often resulted in race conditions precisely because the facilities did not compose properly. The only solution was paradigm inversion whereby the high level tasking model was used to provide, in essence, some low-level semaphore which could then be used in a medieval fashion. The introduction of protected types, barriers and the requeue statement with two distinct levels of locking is designed to overcome these difficulties. Together, these building blocks may be used to program natural and efficient solutions to problems involving a myriad of real-time paradigms, including asynchronous communication, efficient mutual exclusion, barrier synchronization, counting semaphores, and broadcast of a signal. To have provided separate features to solve each of these problems would have resulted in a baroque language which would have run into difficulties whenever a problem immediately outside the original goals was encountered. As mentioned in I.3 (in part one), there are four main areas where it was felt that users needed additional functionality: Interfacing to other systems, Programming by Extension (OOP), Programming in the Large (Program Libraries), and Tasking. Broadly speaking these needs are met in Ada 95 by the following main features and are largely discussed in the chapters indicated. * Interfacing: by new forms of access types, pragmas and interface packages (Chapters 3 and B). * Programming by Extension: by type extension and class-wide types (Chapter 4). * Programming in the Large: by child library units (Chapter 10). * Tasking: by protected objects (Chapter 9). Chapters 3, 4, 9 and 10 constitute the bulk of this part of the rationale mainly because they contain a number of quite long examples. The changes described in the other chapters are more concerned with supporting detail and less pervasive improvements. == <span id="2">1.2 The Reference Manual</span> == The Ada 83 Reference Manual [RM83] is a remarkable document in that it is one of the few definitions of a programming language that is regularly read by normal programmers. It achieves this by using natural English wherever possible. A corollary of this success is, however, that it has not proved to be quite so precise as desired by compiler writers. Of course, there are many more programmers than compiler writers and so the importance of the programmer should not be underestimated. However, it is vital that the compiler writer be given as precise a description of the language as is reasonably possible. At the end of the day, provided that the compiler is correct, then any misunderstanding of some subtle point on the part of the programmer will generally give rise to an appropriate message from the compiler. Furthermore, textbooks and other material such as this rationale are available to give pedagogic information to the programmer. The Ada 95 Reference Manual [RM95] thus continues the tradition of readability and accessibility of the Ada 83 document wherever possible but achieves greater precision by the careful introduction of more specific terminology. Different typography is also used to distinguish normal English words from defined terms and syntax thereby increasing clarity but retaining readability. In addition to the definitive standard, the Annotated Ada Reference Manual [AARM] is an annotated form containing much additional information aimed largely at compiler writers, language lawyers and others with a need for additional detailed information. This contains such matters as advice for implementers, rationale on fine detail, further awkward examples and so on. Both forms of the reference manual as well as this rationale and other material are available in machine readable form on the sw-eng.falls-church.va.us host in the public/ada9x/rm9x directory. == <span id="3">1.3 Syntax</span> == The syntax is expressed in the same notation as for Ada 83. However, the diligent reader will observe a considerable number of changes to the description of the syntax. Apart from those changes required by the new parts of the language, the changes have been made in order to increase clarity of the exposition. This increased clarity has been achieved at the cost of introducing rather more new syntax rules than the increased size of the language would suggest. However, the extra clarity achieved brings major benefits not only in understanding the syntax itself but also by some reduction in the need for English text to explain rules which are now expressed by the syntax. Examples of more notable changes (other than those corresponding to completely new material) are as follows * The rules for the characters used in the program text have been completely rewritten in a more structured manner. The previous rules were not hierarchical and contained a curious imbalance between upper and lower case letters which is no longer appropriate. * The category integer is now called numeral. The term integer was somewhat inappropriate for what is simply a syntactic sequence of digits not specifically related to the integer types. * Reserved words are no longer considered as identifiers. A consequence is that the syntax now explicitly includes those attributes which double as reserved words, namely Delta, Digits, Range and Access (the last being a further such attribute in Ada 95). * Categories such as defining_identifier are introduced for those occurrences of identifiers which define an entity. Usage occurrences use direct_name or selector_name according to the visibility rules. The term simple_name is no longer used. In Ada 83 the term simple_name was used confusingly for just some usage occurrences. * The category type_declaration now properly includes both task and protected types. Surprisingly, task type declarations were excluded in Ada 83 probably because of a lack of reconsideration of the rules subsequent to the introduction of task types in around 1980. * The category type_mark is replaced by subtype_mark because all names of types are now considered to actually denote the first named subtype. * Scalar and composite constraints are now distinguished. * A real change is that the category name is broadened to include function_call and type_conversion in accordance with changes to the concept of a name. This causes a number of consequential changes to other definitions such as primary and prefix. * The one previous category aggregate has now been replaced by some nine syntax rules thereby bringing into the syntax the various distinctions between array and record aggregates and their various rules which were previously expressed by English text. * The new category handled_sequence_of_statements avoids much repetition in a number of other rules, and clarifies the region of text in which a given handler applies. * The categories body_stub and renaming_declaration are both broken down into named subcategories for ease of exposition. * The previous category generic_parameter_declaration which confusingly reused other categories from other contexts is now replaced by some twenty individual categories describing the various classes of generic parameters in a hierarchical manner. The statistically minded might be interested to observe that Ada 83 is described by 180 rules whereas Ada 95 has about 270. However, the rules introduced for clarity account for about 50 of this increase and so in real terms the syntax for Ada 95 is about one seventh bigger than Ada 83. A major part of this increase is simply due to the introduction of protected types. == <span id="4">1.4 Classification of Errors</span> == The classification of errors in Ada 95 is somewhat different to that in Ada 83. The primary reason for the new classification is to be more realistic and practical regarding the possible consequences of undefined behavior. The effect is often to indicate that the range of possible outcomes of a program execution is less than the Ada 83 rules led one to believe (in practice there is little change). The most significant new classification is the introduction of the category called bounded errors. The general idea is that the behavior is not fully determined but nevertheless falls within well-defined bounds. Many errors which were previously classed as erroneous (which implied completely undefined behavior) are now simply bounded errors. An obvious example is the consequence of evaluating an uninitialized scalar variable; this could result in the raising of Program_Error or Constraint_Error or the production of a value not in the subtype, see [RM95 4.4, 11.6]. A rather different approach is taken regarding unportable behavior. A program whose behavior depends upon some order of evaluation is no longer classed as incorrect but simply as being not portable. As a consequence the category of error called incorrect order dependences is deleted. There are also cases where the language has been changed so that a run-time error in Ada 83 is now detected during compilation in Ada 95. Thus static subtype matching is required in some situations as described in 3.9. The language also allows a compiler to have different modes of operation according to the detection of suspicious situations such as too many warnings. This specifically meets one of the requirements for early detection of errors where possible. == <span id="5">1.5 Requirements Summary</span> == The requirements * R 2.1-A(1) - Incorporate Approved Commentaries * R 2.1-A(2) - Review Other Presentation Suggestions are both addressed by the extra attention given to terminology and by the incorporation of improved text recommended by the Ada Rapporteur Group. The requirements * R 2.1-B(1) - Maintain Format of Existing Standard * R 2.1-C(1) - Machine-Readable Version of the Standard have also been met as explained in 1.2. Furthermore, the requirement * R 2.2-B(1) - Understandability is also addressed by the greatly improved terminology as well as by the revisions to the syntax described in 1.3. However, it should be noted that, as expressed in [DoD 90], this particular requirement was perhaps slanted more at certain specific language features rather than clarity of description in general. In the case of error detection the requirement and study topic * R 2.3-A(2) - Limit Consequences of Erroneous Execution * S 2.3-A(1) - Improve Early Detection of Errors are addressed by the introduction of the concept of bounded errors and more compilation checking such as static subtype matching. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2|Previous]] | [[Guide:9x_rationale/rat95-p2-2|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=1 Introduction}} 4cmp6drhy44viqiq43albgock2bubzz Guide:9x rationale/rat95-p2-10 4200 332 1854 1839 2019-04-20T16:19:54Z WikiVisor 11 Text replacement - "[[Guide:9x_rationale/rat95-copyright|Copyright]] | " to "<div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | " wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-9|Previous]] | [[Guide:9x_rationale/rat95-p2-11|Next]]</div> There are a number of important changes in this overall structural area of the language. These include the introduction of the hierarchical library which was discussed in some detail in Part One. In this chapter we provide some more examples and also discuss other topics of a structural nature. The main changes are * The introduction of the hierarchical library provides decomposition of a library unit with possibly distinct views of the hierarchy for the client and implementor. * The overall program structure is enhanced by the concept of partitions. * More control of elaboration order is provided. * A library package is only permitted to have a body if one is required by language rules. * The mechanism of the program library is no longer specified so precisely. The main issue is that partitions must be consistent. * Minor changes include the relaxation of a restriction on subunit names. In addition to the core language changes which introduce the concept of partitions, the Distributed Systems annex describes the concepts of active and passive partitions plus various packages which provide communication between partitions. These are discussed in detail in Part Three. == <span id="1">10.1 The Hierarchical Library</span> == This topic has already been discussed in Sections II.7 and II.8 of Part One where we saw how the introduction of a hierarchical library with public and private child units overcame a number of problems. We recapitulate some of that discussion here in order to bring further insight into the ways in which the hierarchical library may be used. In Ada 83, there were a number of situations where relatively small changes result in large numbers of recompilations. For example, it was not possible to define an additional operation for a private type without recompiling the package where the type was declared. This forced all clients of the package to become obsolete and thus also need recompiling, even if they did not use the new operation. Massive recompilations could result from what was fundamentally a very small change. As we have seen, this is overcome in Ada 95 by allowing a library unit package to be effectively extended with child library units. A child library unit is an independent library unit in that it is not visible unless referenced in a with clause. However, a child library unit may be used to define new operations on types defined in the parent package, because the private part and body of the child unit have visibility onto the private declarations of the parent package. The name of a child library unit indicates its position in the hierarchy. Its name is an expanded name, with the prefix identifying its parent package. Furthermore, when a child library unit is referenced in a with clause, it "looks like" a unit nested in its parent package. This allows the existing naming and visibility rules of nested units to be carried over directly when using child library units. If a child library unit is not mentioned in a with clause, it is as if it did not exist at all. Adding a new child library unit never causes any immediate recompilation of existing compilation units. Of course, eventually some number of other library units will come to depend on this child library unit, and then recompiling the child will affect these client units. But by distributing the set of operations across multiple children, the number of clients affected by any single change can be kept to a minimum. Furthermore, the with clause provides explicit and detailed indications of interdependences, helping to document the overall structure of the system. Separate compilation of program unit specifications and bodies is a powerful facility in Ada. It supports good software engineering practice by separating the abstract interface of the unit from its implementation. Clients of the program unit need only know about its specification - changes to the body do not affect such clients, and do not necessitate a client's recompilation. This separation of interface from implementation also applies to private types. Private types have an interface in the visible part of the package in which they are declared and an implementation in the private part of that package. Declarations in the private part were only visible within that private part and in the package body in Ada 83. For very complex type definitions, the relationship between private types and packages in Ada 83 introduced an unnecessary coupling between abstractions. Consider, for example, a system that implements two private types, File_Descriptor and Executable_File_Descriptor. The first supports general file operations, and the second supports special file operations for executable files. Thus Executable_File_Descriptor might have a write operation that uses scattering writes to write out an entire executable file very quickly. In Ada 83, if Executable_File_Descriptor must have access to the implementation of File_Descriptor, perhaps for reasons of performance, then both File_Descriptor and Executable_File_Descriptor must be defined in the same package. Clients of either File_Descriptor or Executable_File_Descriptor will depend on this package. If the definition of Executable_File_Descriptor is changed, all units that depend on the common package must be recompiled, even those that only utilize File_Descriptor. The unnecessary coupling between Executable_File_Descriptor and File_Descriptor forces more recompilations than are logically necessary. The following example shows how to alleviate this situation using child library units <syntaxhighlight lang="Ada"> package File_IO is type File_Descriptor is private; -- Operations on File_Descriptor... private ... end File_IO; package File_IO.Executable_IO is type Executable_File_Descriptor is private; -- Operations on Executable_File_Descriptor... private ... end File_IO.Executable_IO;</syntaxhighlight> As a child of package File_IO, File_IO.Executable_IO can use the full declaration of the private type File_Descriptor in the declaration of the private type Executable_File_Descriptor. Clients of the package File_IO do not require recompilation if a child package changes, and new child units can be added without disturbing existing clients. Another way of looking at the example above is to observe a distinction between the different clients of a package. The traditional clients of a package use the package's visible definitions as their interface. There are other clients that extend the package's abstractions. These extending clients may add functionality to the original abstraction, or export a different interface, or do both. Extending clients will require details of the original package's implementation. Packages that are extending clients are tightly coupled to the original package in terms of implementation, but their logical coupling may be looser - the extending client may be an alternative to the original for other clients. It should be possible to use either package independently. In Ada 95, one or more child library units can share access to the declarations of their parent's private part - to extend their parent's visible interface or provide an alternate view of it. The distinction between packages that extend another package and packages that simply use the definitions of another package gives rise to the notion of subsystems. A set of packages that share a set of private types can be viewed as a subsystem or subassembly. This concept is recognized by many design methodologies [Booch 87] and is supported by several implementations in their program library facilities. Subsystems are a useful tool for structured code reuse - very large software systems can be designed and built by decomposing the total system into more manageable-sized pieces that are related, but independent, components. In summary, child library units provide a combination of compilation independence and hierarchical structuring. This combination results in an extremely flexible building block for constructing subsystems of library units that collectively implement complex abstractions and directly model the structure of the subsystems within the language. As an example, the package OS in II.8 illustrates the use of a hierarchy of library units in implementing a subsystem representing an operating system interface. === <span id="1-1">10.1.1 Summary of Mechanism</span> === In Ada 95, a library package (or a generic library package) may have child library units. Child library units have the following properties * Child units are logically dependent on their parent and have visibility of their parent's visible and private parts. * Child library units are named like nested units; with an expanded name consisting of a unique identifier and their parent's name as prefix. * A child may be any kind of library unit including a generic unit or instantiation. * This structure may be iterated - child units that are packages (or generic packages) may themselves have children, yielding a tree-like hierarchical structure, beginning at a root library unit. Note however that a generic unit may only have generic children. Child library units may be separately compiled. They may also be separately "withed" by clients. A context clause that names a child unit necessarily names all of the child unit's ancestors as well (with clauses are hence implicit for the ancestors). Within the private part of File_IO.Executable_IO, declarations in the private part of File_IO are visible. Hence the definition of Executable_File_Descriptor can use the full declaration of File_Descriptor. There are two kinds of child units - private child units and public child units. Private children are those declared using the reserved word private. <syntaxhighlight lang="Ada"> private package File_IO.System_File_IO is type System_File_Descriptor is private; private ... end File_IO.System_File_IO;</syntaxhighlight> The visibility rules for private child units are designed such that they cannot be used outside the subsystem defined by their parent. A unit's specification may depend on a private child unit only if the unit is itself private and it is a descendant of the original private child's parent. A unit body may depend on a private child unit if it is a descendant of the private child unit's parent. Public child packages are intended to provide facilities that are available outside the subsystems defined by their parent packages. In the example, File_IO.Executable_IO is a public child generally available to clients. Private child packages are intended "for internal use" in a larger definition. In the example, File_IO.System_File_IO is meant to be private to the hierarchy of units rooted at File_IO. Child library units observe the following visibility rules. * A parent unit's visible definitions are visible everywhere in any child unit, whether the unit is public or private. * A parent unit's private definitions are visible in the private part of a child unit, whether the child unit is public or private. * A parent unit's private definitions are visible everywhere in a private child unit, since the child package is never visible outside of the parent. * The entities in a parent's body are never visible in a child unit. A principal design consideration for child library units was that it should not be possible for a private view to be violated by indirect means such as renaming. As can be seen this has been achieved since a child unit cannot export a parent unit's private definition by renaming it in the visible part. Note that for root units, private has the effect of making them invisible to the specifications of public root units. Thus private root units concern the internal implementation of the total system and not its public interface. Moreover, we anticipate that some implementations may provide means for one program library to be referenced from another program library, and in this case the private marking might naturally be used to limit visibility across program libraries. See 10.1.5. In conclusion, the ability to mark a library unit private is extremely valuable in establishing the same separation between interface and implementation at the subsystem level as is provided in Ada 83 at the individual program unit level. The private library units of a hierarchy, plus the bodies of both the private and public library units of the hierarchy, make up the "implementation" of a subsystem. The "interface" to the subsystem is the declaration of the root package in the hierarchy, plus all of the public descendant child library units. === <span id="1-2">10.1.2 Context Clauses and Renaming</span> === As in Ada 83, a with clause is used to make other library units visible within a compilation unit. In Ada 95, in order to support the identification of a child library unit, the with clause syntax is augmented to allow the use of an expanded name (the familiar dotted notation) rather than just a single identifier. Once the child library unit has been identified with its full name in the with clause, normal renaming or use clauses may be used within the compilation unit to shorten the name needed to refer to the child. In addition to renaming from within a unit, renaming may be used at the library unit level to provide a shorter name for a child library unit, or to hide the hierarchical position of a child unit when appropriate. For example, a library unit may be defined as a child unit to gain special visibility on a parent unit, but this visibility may be irrelevant to most users of the child unit. Other reasons for library unit renaming are * Essentially all hierarchical naming systems provide some kind of "alias" capability, because of the advantages of allowing the same entity to appear in multiple places within the hierarchy (such as symbolic links in Unix file systems); * Helper packages that use unchecked conversion to overcome the restrictions on private types may already exist; through the use of library unit renaming, such helper packages can remain available by their current root library unit names, while moving their actual definition into the appropriate place in the library unit hierarchy reflecting their access patterns; * It is a common practice to establish standard package renaming conventions throughout a project; without library-level renaming, each unit that withs a package must include a copy of the appropriate renaming declaration for the package; this introduces the possibility of nonconformities, and, if done in the specification, overrides the useful lack of transitivity provided for names introduced by with clauses; the program library manager keeps a central record of the project-wide renaming declarations; * When integrating independently developed libraries into a single library, the hierarchical name space may be used to avoid collisions, and renaming may be used to selectively "export" units from their local name spaces into the root name space for a given user's library; * Given a large program library, it may be useful to have a flexible subsystem that includes withs for a certain set of units, and then use renaming to select the particular implementations of those units to be used in the particular subsystem configuration appropriate at a given time; * Renaming can be used to hide from clients the parent child relationship between two packages. Withing a child via a root-level renaming does not give visibility of the parent. * Renaming is used in the predefined library so that compatibility is preserved for Ada 83 programs. Thus Ada.Text_IO is renamed as Text_IO as mentioned in II.13. Some of the capabilities provided by library unit renaming are currently supported by some proprietary program library managers. However, by standardizing these renaming capabilities, very large systems can be built and maintained and rehosted without becoming overly dependent on non-standard program library features. === <span id="1-3">10.1.3 Children of Generic Packages</span> === As mentioned in II.8, a child may also be generic. However there are a number of important rules to be remembered. Children of a nongeneric unit may be generic or not but children of a generic unit must always be generic. One of the main problems to be solved in the design of the interaction between genericity and children is the impact of new children on existing instantiations. One possibility would be to say that adding a new child automatically added further corresponding children to all the existing instantiations; this would undoubtedly lead to many surprises and would typically not be what was required since at the time of instantiation the children did not exist and presumably the existing instantiation met the requirements at the time. On the other hand one might decide that existing instantiations did not become extended; however, this would sometimes not be what was wanted either. Clearly a means is required to enable the user to specify just which units of the hierarchy are to be instantiated. Insisting that all children of a generic unit are themselves generic makes this particularly straightforward and natural; the user just instantiates the units required. The existence of nongeneric children would be a problem because there would not be a natural means to indicate that they were required. One consequence is that it is very common for generic children not to have any generic parameters of their own. See for example the package Sets in 3.7.1. So a typical pattern is <syntaxhighlight lang="Ada"> generic type T is private; package Parent is ... end Parent; generic package Parent.Child is ... end Parent.Child;</syntaxhighlight> Since the child has visibility of the formal parameters of its parent it is necessary that the instantiation of the child also has visibility of the corresponding actual parameter of the instantiation of the parent. There are two situations to be considered, instantiation within the parent hierarchy and instantiation outside the hierarchy. Instantiation inside the parent hierarchy poses no problem since the instantiation has visibility of the parent's formal parameters in the usual way. Instantiation outside requires that the actual parameter corresponding to the formal parameter of the parent is correspondingly visible to the instantiation of the child. This is assured by requiring that the child is instantiated using the name of the instance of the parent; a with clause for the generic child is necessary in order for the child to be visible. So we might write <syntaxhighlight lang="Ada"> with Parent; package Parent_Instance is new Parent(T => Integer); with Parent.Child; package Child_Instance is new Parent_Instance.Child;</syntaxhighlight> In a sense the with clause for the child makes the generic child visible in every instantiation of the parent and so we can then instantiate it in the usual way. Note carefully that the instantiations need not be at the library level. An earlier version of Ada 95 did require all instantiations to be at the library level but this was very restrictive for many applications. Of course if we do make the instantiations at the libraray level then the instantiations can themselves form a child hierarchy. However it will be necessary for the child names to be different to those in the generic hierarchy. So we might have <syntaxhighlight lang="Ada"> with Parent.Child; package Parent_Instance.Child_Instance is new Parent_Instance.Child;</syntaxhighlight> Finally note that there are no restrictions on the instantiation of a generic child of a non-generic parent. === <span id="1-4">10.1.4 Examples of Interfaces</span> === Programs may use child library units to implement several different kinds of structures. Some possibilities which will now be illustrated are * A child package may be used to create specialized interfaces to, or views of, an abstraction. This allows independent abstractions to be combined into larger subsystems. The bit-vector and list-based sets example below illustrates this. * The interface to a system may be organized into subsystems if it is too large to be conveniently implemented as a single package, or if clients do not often need all of the facilities that the package provides. See the discussion of CAIS-A below. * A hierarchical organization of library units may be used to permit vendor extensions. The form of such extensions can distinguish clearly by package names which parts are standard, and which parts are vendor extensions. * Child library units may be used to define an extensible, reusable, library of components. Users are encouraged to extend or modify the components by adding new children. An example of this was shown in II.7 as part of a windowing system. Our first example could be part of a transaction control system for a database. It shows how to use child library units to structure definitions in order to reduce recompilation. <syntaxhighlight lang="Ada"> package Transaction_Mgt is type Transaction is limited private; procedure Start_Transaction(Trans: out Transaction); procedure Complete_Transaction(Trans: in Transaction); procedure Abort_Transaction(Trans: in Transaction); private ... end Transaction_Mgt; package Transaction_Mgt.Auditing is type Transaction_Record is private; procedure Log(Rec: in Transaction_Record); private ... end Transaction_Mgt.Auditing;</syntaxhighlight> In the example, some clients require facilities for controlling transactions. Other clients need to be able to log a record of each transaction for auditing purposes. These facilities are logically separate, but transaction records require intimate knowledge of the full structure of a transaction. The solution with child library units is to make a child library unit to support the type Transaction_Record. Each unit may be compiled separately. Changes to Transaction_Mgt.Auditing do not require recompilation of the parent, Transaction_Mgt, nor its clients. But note that withing the child implicitly withs the parent; if this is not desired then, as mentioned above, the child could be renamed thus <syntaxhighlight lang="Ada"> package Transaction_Auditing renames Transaction_Mgt.Auditing;</syntaxhighlight> and then withing Transaction_Auditing will not give visibility of Transaction_Mgt. The next example illustrates how child library units can be used to add new interfaces to an existing abstraction. This is useful, for example, when conversion functions are needed between types in independently developed abstractions. Imagine that two packages exist implementing sets, one using bit vectors, and the other linked lists. The bit vector abstraction may not have an iterator in its interface (a means of taking one element from the set), and hence a function cannot be written to convert from the bit vector set to the linked list set. A child package can be added to the bit vector set package that provides an iterator. A new package could then be written to provide the conversion functions, implemented using the iterator interface. <syntaxhighlight lang="Ada"> package Bit_Vector_Set is type Set is private; function Union(A, B: Set) return Set; function Intersect(A, B: Set) return Set; function Unit(E: Element) return Set; function Empty return Set; private ... end Bit_Vector_Set; package List_Set is type Set is private; function Union(A, B: Set) return Set; function Intersect(A, B: Set) return Set; function Unit(E: Element) return Set function Empty return Set; procedure Take(S: in out Set; E: out Element); function Is_Empty(S: Set) return Boolean; private ... end List_Set; package Bit_Vector_Set.Iterator is procedure Take(S: in out Set; E: out Element); function Is_Empty(S: Set) return Boolean; end Bit_Vector_Set.Iterator; with List_Set; with Bit_Vector_Set; package Set_Conversion is function Convert(From: in List_Set.Set) return Bit_Vector_Set.Set; function Convert(From: in Bit_Vector_Set.Set) return List_Set.Set; end Set_Conversion;</syntaxhighlight> The child package Bit_Vector_Set.Iterator adds the two missing subprograms needed in order to iterate over the set. The body of the child package has visibility of the private part of its parent and thus can access the details of the set. This example should be compared with that in 4.4.3 which used class-wide types. Note also that it might be infeasible to modify the body of Bit_Vector_Set anyway since it might have been supplied by a third party in encrypted form (such as object code!). A larger example is provided by CAIS-A [DoD 89b]; this is an interface that provides operating system services in a portable way. The CAIS has a very large specification, with hundreds of packages. The central type, which is manipulated by much of the system, is called Node_Type. It is a limited private type defined in a package called Cais_Definitions. It is needed throughout the CAIS, but its implementation should be hidden from CAIS application developers. The implementation uses Unchecked_Conversion inside packages that manipulate the type. There are a number of subsystems, the largest of which are for manipulating Nodes, Attributes, and I/O. These subsystems also share common types. These common types are implemented using visible types declared in support packages. Only packages in the subsystem are supposed to depend on these support packages. Using Unchecked_Conversion has several disadvantages. First, the replicated type definitions must match exactly, which creates a maintenance problem. Secondly, the compiler must represent each type definition in the same way, which would require a representation clause or good luck. Finally, if the data type is a record, the components may themselves be private types whose definitions may need to be replicated. This propagated need for visibility may cause many or all private type definitions to be replicated in several places. Child library units could be used to restructure these definitions. The type Node_Type might be defined at the root of the hierarchy. Packages that contain types and operations for manipulating Nodes, I/O, and Attributes might be child packages of the root library package. The common types would be private, and the support packages would be child packages of the packages that contain the type definitions. The Ada binding to POSIX [IEEE 92] is another system with many packages and many types. Some of these types are system independent, and some are explicitly system defined. When designing portable programs it is useful to know when programs depend on system defined definitions, to eliminate such dependencies where possible, and to contain them when they are necessary. The POSIX-Ada binding attempts to preserve the principle of with list portability: users should be able to determine if a program depends on system defined features by examining the names of the packages in its with clauses. At the same time, the system dependent packages often require visibility on the private types of the standard packages, and in Ada 83 this could only be accomplished by nesting them within the standard packages. Since a nested package never appears in a with clause, the visibility needs of such system dependent packages is in conflict with the principle of with list portability. Child library units offer precisely what is needed to resolve this conflict. === <span id="1-5">10.1.5 Existing Program Libraries</span> === We anticipate that implementations will continue to support library unit references between program libraries. The hierarchical library unit naming may allow these inter-library references to be handled more naturally within the language, for example, by treating the library units of one program library as child units of an empty package within the referencing library. This would provide automatic name-space separation between the two libraries, since the names of the units of the referenced library would all be prefixed by a hypothetical parent package identifier. This approach would eliminate any need for global uniqueness of library unit names when two or more program libraries are (conceptually) combined in this way. It should also be noted that this provides a good use for private top level library units. Marking a top level library unit as private such as <syntaxhighlight lang="Ada"> private package PP is ...</syntaxhighlight> means that it is not visible to the specifications of public units in the library but only to their bodies. Hence it cannot be accessed directly but only as a slave to other units. Considering the whole library as a hypothetical unit such as Your_Lib means that in effect the package becomes <syntaxhighlight lang="Ada"> private package Your_Lib.PP is ...</syntaxhighlight> and then (correctly) cannot be accessed from outside the package Your_Lib. We have avoided specifying standard mechanisms for such inter-program- library references, as implementations vary widely in what they choose to provide in this area. However, the universal availability of hierarchical library unit naming will ensure that a program built out of units from multiple libraries will have a natural and portable representation by using a hierarchical naming approach. === <span id="1-6">10.1.6 Relationship with Previous Work</span> === We conclude our discussion of hierarchical libraries by mentioning three alternative approaches which were considered and rejected: * Voyeurism. (The term "voyeurism" is due to D. Emery.) This allows packages to request visibility on another package's private declarations via some kind of enhanced context clause (such as with all X; or with private X;) * Friends. This allows packages to specify exactly which other packages may have enhanced visibility. * DAG Inheritance. This allows a more general form of hierarchical organization, where packages can, in effect, "nest" within several other packages, without an explicit indication in the parent. This is called "DAG inheritance", since the dependence graph must be a directed acyclic graph. The voyeur approach has the unsettling characteristic of making the privacy of types a property of other packages' context clauses, instead of a feature of the package that is declaring the type. This inverts the Ada 83 notion of privacy. With child library units, privacy becomes a feature of package hierarchies, which is a generalization of Ada 83's subunit facility. Although many of the same effects can be achieved with either approach, the mechanisms are fundamentally different, and child library units are consistent with this Ada model. There are serious problems with the with private approach - without additional rules, private declarations may be easily reexported to units that do not have a with private clause for the unit. This could happen, for example, via a renaming declaration or deriving from a private type as in the following example <syntaxhighlight lang="Ada"> package Closed is type T is private; private type T is Full_Implementation; end Closed; with private Closed; -- not Ada 95 package Open is type D is new Closed.T; -- from full declaration of T end Open; with Open; package Surprise is type S is new Open.D; -- gets full type declaration of T via D end Surprise;</syntaxhighlight> whereby the package Surprise gets visibility of the full declaration of T via the type D declared in the package Open. The real difficulty with the with private approach is that dependence can subsequently become diffused. One of the important advantages of using private types in a package is that the compiler ensures that clients of the package do not become dependent on the details of the type's implementation. This makes it much easier to safely maintain and enhance the implementation of the package, even if the set of clients is large. With child units, if a given client needs more operations on a private type, they must identify those operations and declare them in a public child of the package. When the private type's implementation is revised, only the children of the package need be checked and updated as necessary. The with private approach results in a very different scenario. If a client needs additional access to a private type, they need not separately declare operations on that type in some child. Instead they can simply change their with to with private. This means that the dependence is now open ended rather than being encapsulated in a child. After a period of use, it is clear that there could be sufficiently widespread and diffuse dependence on the implementation of the private type so that any change will be unacceptably expensive to the clients (since the amount of client code can easily exceed the size of the package), thereby totally defeating the original purpose of private types. The "friends" approach is used in C++. This solution was considered and was rejected because it does not allow for unplanned extension of a package without requiring modification and recompilation of that package, conflicting with the requirement to reduce recompilation. In the X and CAIS-A examples above we discussed situations where unplanned extension is desirable. It is highly advantageous that Ada 95 support it with this same mechanism. Furthermore, the "friends" approach inverts Ada's usual client/server philosophy. In general it is not possible to tell at the point of a particular declaration where that declaration will be used. For example, the declaration of a type does not specify the type's users, a task declaration does not specify the task's callers, a library unit's declaration does not specify which other units depend on it, and a generic unit's declaration does not specify where the generic will be instantiated. Allowing a package's declaration to specify which other units may extend that package is inconsistent with this model. Although on the surface the voyeurism and friends concepts appear simple, the issue of transitivity is problematical. In Ada, context clauses are not transitive. Presumably this would also be the case for voyeur context clauses as well. In that case the meaning of the following program becomes unclear. <syntaxhighlight lang="Ada"> with private X; -- not Ada 95 package Y is ... end Y; with private Y; with X; package Q is ... end Q;</syntaxhighlight> Here Q has visibility to Y's private declarations which in turn may refer to X's private declarations. However, Q does not have visibility to X's private declarations through its context clause. Any proposal would have to address in this case whether or not Q has visibility to X. The DAG inheritance approach has characteristics of both child library units and voyeurism. If there is more than one private type involved, it is possible that a tree structured hierarchy cannot provide the exact visibility needed. However, the DAG approach is complex and its ramifications far-reaching. We concluded that such a solution was too ambitious for the Ada 9X revision. == <span id="2">10.2 Program Structure</span> == In Ada 83, an executable program consisted of a main subprogram and all other library units reachable from this main subprogram. Execution proceeded by elaborating the entire program, running the main subprogram to completion, waiting for all library-level tasks to complete, and then terminating. Although this model for a program was appropriate in some environments, for many programming environments, a much more dynamic and distributed model is preferable. In Ada 95, a program may be formed from a cooperating set of partitions. The core language simply says that partitions elaborate independently, communicate, and then terminate in some implementation- defined manner. Each partition has its own environment task to act as the thread of control for library-level elaboration, and to act as the master for library-level tasks. The description in the core language is kept purposefully non-specific to allow for many different approaches to dynamic and distributed program construction. However, the Distributed Systems annex describes additional standard pragmas and attributes which form the basis for a standard, portable approach to distribution. == <span id="3">10.3 Elaboration</span> == Because Ada allows essentially arbitrary code to execute during the elaboration of library units, it is difficult for the user to ensure that no subprogram is called before it is elaborated. Ada 83 required that access before elaboration be detected, and Program_Error raised. This could incur significant overhead at run-time. Ada 95 addresses both the problem of controlling library unit elaboration order, and the run-time overhead of access-before-elaboration checks. In Ada 95 the Elaborate pragma is effectively replaced by the transitive Elaborate_All pragma. Elaborate_All on a library unit causes not only the body of that library unit to be elaborated, but also causes the bodies of the library units reachable from that library unit's body to be elaborated. This ensures that any call performed during elaboration on a subprogram defined in the unit to which pragma Elaborate_All applies, will not result in an access-before-elaboration error. The pragma Elaborate_Body in a package specifies that the body of the package must be elaborated immediately after its declaration. No intervening elaborations are permitted. This allows the compiler to know whether or not any elaboration-time code exists between a visible subprogram declaration and its body. If there is no such elaboration- time code, or it can be proved to not call the subprogram, then there is no opportunity for access-before-elaboration, and the check may be completely eliminated for the subprogram. Without this pragma, the compiler must assume that other library units might be elaborated between the elaboration of the library unit's declaration and its body, meaning that the check in a visible subprogram cannot be removed by the compiler. Ada 95 also contains two further pragmas concerned with elaboration. The pragma Pure in a package specifies that the package does not have any library-level "state", and may depend only on other pure packages. Pure packages are important for distributed systems. Finally, the pragma Preelaborate indicates that a unit is to be preelaborated; that is elaborated before other units not so indicated; there are restrictions on the actions of a unit which is preelaborated. A unit marked as Pure is also preelaborated. The general intent is that certain structures can be set up at link-time (before program execution begins) and then perhaps loaded into RAM. It is good advice to give all library units one of the pragmas Pure, Preelaborate, or Elaborate_Body in that order of preference, wherever possible. This will ensure the benefits of possible check eliminations as mentioned above. Further support for preelaboration is described in the Systems Programming annex. == <span id="4">10.4 Library Package Bodies</span> == In Ada 83, if a package does not require a body, but has one nevertheless (perhaps to do some initialization), its body can become out-of-date, and be silently omitted from a subsequent build of an executable program. This can lead to mysterious run-time failures due to the lack of the package body. Ada 95 overcomes this difficulty by allowing a library package to have a body only if a body is required by some language rule. An obvious rule requiring a body is that a subprogram specification in a package specification requires a corresponding subprogram body in the package body. Another rule which is more convenient for ensuring that a body is required in cases where we wish to use the body just for initialization is that the pragma Elaborate_Body rather obviously requires a body. Note that an early version of Ada 95 proposed that a library package always have a body; this was eventually rejected because of the irritating incompatibility problems that would have arisen in moving programs from Ada 83. == <span id="5">10.5 Other Improvements</span> == Child library units take over some of the applications of subunits. However, subunits remain the only way for separately compiling a unit that has visibility to the declarative part of the enclosing unit's body. They are also appropriate for providing bodies for individual units that may be undergoing more active development or maintenance than surrounding units. To simplify the use of subunits, Ada 95 eliminates the requirement on uniqueness of their simple name within an enclosing library unit. Only the expanded name need be unique. Thus subunits P.Q.T and P.S.T where P is the library package name are allowed in Ada 95 whereas this was forbidden in Ada 83. This is in line with the rules for naming child units. == <span id="6">10.6 Requirements Summary</span> == The requirements includes two study topics * S4.3-A(1) - Reducing the Need for Recompilation * S4.3-C(1) - Enhanced Library Support which are specifically addressed and well satisfied by the hierarchical library mechanism. In addition the further study topic * S4.3-B(1) - Programming by Specialization/Extension is also addressed by the hierarchical library in conjunction with type extension. The requirements * R8.1-A(1) - Facilitating Software Distribution * R8.2-A(1) - Dynamic Reconfiguration are addressed by the concept of partitions described in 10.2 and elaboration discussed in 10.3. However, this is really the domain of the Distributed Systems annex and the reader is thus referred to Part Three of this rationale for further details. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-9|Previous]] | [[Guide:9x_rationale/rat95-p2-11|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=10 Program Structure and Compilation Issues}} lus4gnp5ekbncsyrlphsurtbr1w9ycq Guide:9x rationale/rat95-p2-11 4200 333 1847 1825 2019-04-20T16:19:35Z WikiVisor 11 Text replacement - "|Next]]" to "|Next]]</div>" wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-10|Previous]] | [[Guide:9x_rationale/rat95-p2-12|Next]]</div> The changes to exception handling from Ada 83 are quite small. The main changes are * The exception Numeric_Error is now a renaming of Constraint_Error and is also obsolescent. * The notion of an exception occurrence is introduced. This refers to an instance of raising an exception. The package Ada.Exceptions contains procedures providing additional information regarding an exception occurrence. * The interaction between exceptions and optimization is clarified. * A minor improvement is that an accept statement may now directly have an exception handler. == <span id="1">11.1 Numeric Error</span> == Those familiar with the early use of Ada 83 will recall that there was considerable confusion between Numeric_Error and Constraint_Error in a number of corner situations. As a consequence the ARG ruled that implementations should raise Constraint_Error in all situations for which Numeric_Error was originally intended. This was a non-binding interpretation with the intention of making it binding in due course. Essentially all implementations of Ada 83 now raise Constraint_Error although for historic reasons some programs may contain dormant handlers for Numeric_Error. The development of Ada 95 provided an opportunity to remove this historic wart once and for all. It was thus proposed that Numeric_Error be completely removed. However, many reviewers pointed out that those programs which had conformed to the advice of AI-387 by consistently writing <syntaxhighlight lang="Ada"> when Constraint_Error | Numeric_Error =></syntaxhighlight> would then become illegal. Accordingly, in Ada 95, Numeric_Error is simply a renaming of Constraint_Error. Such a change alone would still have made the above illegal because, in Ada 83, all the exceptions in a handler had to be distinct; a supplementary change is thus that an exception may appear more than once in a handler in Ada 95. Allowing multiple instances of an exception in a given handler has benefits in other areas. It now allows sequences such as <syntaxhighlight lang="Ada"> when Text_IO.Data_Error | Integer_IO.Data_Error =></syntaxhighlight> where there may be documentation advantages in revealing the potential causes of the exception. Of course if the user had deliberately relied upon a distinction between Numeric_Error and Constraint_Error then the program will now become incorrect. It may be simply incompatible but may also be inconsistent if the handlers are in different frames. For a more detailed discussion see A-4.5. Despite this possibility it was concluded that the perhaps safer alternative of completely removing Numeric_Error was not appropriate for this revision although it should be reconsidered at the next revision. == <span id="2">11.2 Exception Occurrences</span> == It is important in many programs to be able to recover from all exceptions and to continue processing in some way. All exceptions including unexpected exceptions can be caught by an others handler. Unfortunately, however, Ada 83 provided no way of identifying the particular exception and it was thus not possible to log the details or take specific appropriate action. This is overcome in Ada 95 by the introduction of the concept of an exception occurrence and a number of subprograms to access information regarding the occurrence. The type Exception_Occurrence and the subprograms are declared in the package Ada.Exceptions. The user can then declare a choice parameter in a handler through which the particular occurrence can be identified. For example a fragment of a continuous embedded system might take the form <syntaxhighlight lang="Ada"> with Ada.Exceptions; task body Control is ... begin loop begin ... -- main algorithm exception when Error: others => -- unhandled exception; log it Log("Unknown error in task Control" & Ada.Exceptions.Exception_Information(Error)); -- reset data structures as necessary end; -- loop around to restart the task end loop; end Control;</syntaxhighlight> The choice parameter Error is a constant of the type Exception_Occurrence. The function Exception_Information returns a printable string describing the exception and details of the cause of the occurrence. The actual details depend on the implementation. Two other functions in Ada.Exceptions are Exception_Name and Exception_Message. Exception_Name just returns the name of the exception (the expanded name) and Exception_Message returns a one-liner giving further details (it excludes the name). Thus Exception_Name, Exception_Message and Exception_Information provide a hierarchy of strings appropriate to different requirements. The purpose of the three functions is to provide information suitable for output and subsequent analysis in a standard way. Although the details of the strings will depend upon the implementation nevertheless they should be appropriate for analysis on that system. Exception occurrences can be saved for later analysis by the two subprograms Save_Occurrence. Note that the type Exception_Occurrence is limited; using subprograms rather than allowing the user to save values through assignment gives better control over the use of storage for saved exception occurrences (which could of course be large since they may contain full trace back information). The procedure Save_Occurrence may truncate the message to 200 characters whereas the function Save_Occurrence (which returns an access value) is not permitted to truncate the message. (Note that 200 corresponds to the minimum size of line length required to be supported, see 2.2.) An occurrence may be reraised by calling the procedure Reraise_Occurrence. This is precisely equivalent to reraising an exception by a raise statement without an exception name and does not create a new occurrence (thus ensuring that the original cause is not lost). An advantage of Reraise_Occurrence is that it can be used to reraise an occurrence that was stored by Save_Occurrence. It is possible to attach a specific message to the raising of an exception by the procedure Raise_Exception. The first parameter is a value of the type Exception_Id which identifies the exception; this value can be obtained by applying the attribute Identity to the identifier of the exception. The second parameter is the message (a string) which can then be retrieved by calling Exception_Message. This provides a convenient means of identifying the cause of an exception during program debugging. Consider <syntaxhighlight lang="Ada"> declare O_Rats: exception; begin ... Raise_Exception(O_Rats'Identity, "Hard cheese"); ... Raise_Exception(O_Rats'Identity, "Rat poison"); ... exception when Event: O_Rats => Put("O_Rats raised because of "); Put(Exception_Message(Event)); end;</syntaxhighlight> Calling Raise_Exception raises the exception O_Rats with the string attached as the message. The second call of Put in the handler will output Hard cheese or Rat poison according to which occurrence of O_Rats was raised. See also the example in 9.6.1. Note that the system messages do not include the name so user and system messages can be processed in a similar manner without the user having to insert the exception name in the message. == <span id="3">11.3 Exceptions and Optimization</span> == The general objective is to strike a sensible balance between prescribing the language so rigorously that no optimizations are possible (which would make the language uncompetitive) and allowing so much freedom that the language semantics are almost non-existent (which would impact on portability and provability). A progressive approach is required that enables different degrees to be permitted in different circumstances. Much of the difficulty lies with exceptions and ensuring that they are still raised in the appropriate frame. In particular we have ensured that calls to subprograms in other library units are not disrupted. For details of the approach taken the reader is referred to [RM95 11.6]. A more detailed discussion of the rationale will be found in [AARM]. == <span id="4">11.4 Other Improvements</span> == As mentioned in 1.3, the description of exception handling has been simplified by the introduction of a new syntactic category handled_sequence_of_statements which embraces a sequence of statements plus associated exception handlers and is used for all situations where handlers are allowed. An incidental minor improvement following from this change to the syntax is that an accept statement can now have a handler without the necessity for an inner block, thus <syntaxhighlight lang="Ada"> accept E do ... ... exception ... end E;</syntaxhighlight> A further practical improvement is that the concept of a current error file is introduced. This can conveniently be used to log error messages without cluttering other output. This is discussed in more detail in Part Three. == <span id="5">11.5 Requirements Summary</span> == The specific requirement * R 4.5-A(1) - Accessing an Exception Name is met by the introduction of exception occurrences. The requirement * R2.2-C(1) - Minimize Special Case Restrictions mentions as an example the curious fact that an accept statement cannot have an exception handler. This has been rectified. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-10|Previous]] | [[Guide:9x_rationale/rat95-p2-12|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=11 Exceptions}} 3q0nv5mwp1h7gs8wim5m08ayiy7qdg4 Guide:9x rationale/rat95-p2-12 4200 334 1865 1821 2019-04-20T16:20:32Z WikiVisor 11 Text replacement - "[[Guide:9x_rationale/rat95-copyright|Copyright]] | " to "<div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | " wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-11|Previous]] | [[Guide:9x_rationale/rat95-p2-13|Next]]</div> There are a number of important improvements and extensions to the generic model in Ada 95. The extensions are mainly concerned with providing appropriate new parameter mechanisms to match the additional functionality provided by tagged and other new types. In addition problems with flaws in the contract model are cured. The main changes are * A distinct formal notation (<>) is introduced that enables definite and indefinite subtypes to be treated separately. This cures a major flaw in the contract model. The (<>) notation is also used in private types to indicate that they have unknown discriminants. * There are new formal notations for modular and decimal types. * The rules for access type matching are extended to accommodate the additional forms of access types. * There is a new formal notation indicating that the actual type must be derived from a given type. Moreover, in both this case and the existing private formal notation, it is possible to indicate that the type must be tagged. * There is a new formal notation for package parameters. The generic actual parameter must be an instantiation of a given generic package. * Minor changes are that static subtype matching is now required for array and access types, and that the order of evaluation of generic actual and default parameters is not so rigidly specified. == <span id="1">12.1 The Contract Model</span> == As mentioned in Part One, there are a number of new forms of generic parameter in Ada 95. Some of these are introduced to correspond to new types such as tagged types, modular types and decimal types. In addition there are new forms for derived types in general and for package parameters; these simplify program composition. All these new forms were introduced in Part One and are discussed in detail in the following sections. As was discussed in II.11, Ada 83 had a serious violation of the contract model because of the lack of distinction between unconstrained and constrained formal parameters. The exact distinction is between subtypes for which objects can be declared (without giving any constraints directly or from an initialization) and those for which they cannot. The former category covers scalar subtypes such as Integer, constrained array and record subtypes and unconstrained record subtypes which have default discriminants. The term definite is introduced for these subtypes. Ada 95 cures this flaw in the contract model by requiring that the formal parameter include an unknown discriminant part (<>) if an indefinite subtype is to be allowed as actual parameter. In this case the body cannot use the subtype in a context requiring a definite subtype. On the other hand the existing notation without (<>) now indicates that the actual parameter must be definite. The two notations are illustrated by the following example <syntaxhighlight lang="Ada"> generic type Key(<>) is private; type Item is private; package Keyed_Index is ... end;</syntaxhighlight> The subtype String, because it is an unconstrained array subtype, could be associated with Key, but not with Item. Within the generic, Key must not be used to declare a component or uninitialized object. This is an incompatibility as mentioned in I-4.4 but straightforward to detect and fix. If existing instantiations fail to compile under Ada 95, then the generic unit must be modified to specify that the relevant generic formal allows indefinite subtypes. This new distinction between definite and indefinite parameters eliminates the primary source of situations in Ada 83 where an otherwise legal instantiation is made illegal by a particular usage pattern of a formal type within the body of the generic unit. In other words this distinction eliminates the major gap in the generic contract model of Ada 83. Having plugged the major gap in the Ada 83 generic contract model, Ada 95 goes further and ensures that the legality of an instantiation never depends on the parameter usage patterns present in the generic body. This is achieved in various ways. We have just seen how the addition of further information in the formal parameter enables a satisfactory distinction between usage patterns to be made in the case of definite and indefinite subtypes. However, it is impracticable to impose all pattern matching requirements through the parameter matching rules. Another approach is to impose certain restrictions in the generic body which in essence assume the "worst" regarding the possible instantiations. An example is that if the generic parameter is nonlimited then all the components in an extension of it also have to be nonlimited. This rule is checked in the instance. For further details of this and other ways in which the contract is ensured see [RM95 12.3] The general principle is to assume the "best" in the generic specification and then to check the assumptions again at the instantiation, and to assume the "worst" in the body so that legality does not depend upon the instantiation. This of course means that full freedom is not possible in the body but the constraints will not generally be found irksome. A common workaround is to move material from the generic body into the private part. In conclusion, a tight contract model has several desirable properties. It allows implementations to share generics more easily, it leads to the early detection of programming errors, and it eliminates the need to recheck all existing instantiations when a new body is compiled. Ada 95 strengthens the contract model by requiring that the specification of a generic formal private type indicate whether a corresponding actual may be an unconstrained composite subtype. This simplifies the checking required when a new generic body is compiled, since its legality will not depend on the nature of the existing instantiations. As pointed out in [DoD 90] in the discussion of Study Topic S4.4-B(2), both tight and loose contract models are desirable, each for its own reasons. This tension has been resolved in Ada 95, by specifying that certain checks in the generic specification are only performed at instantiation time. Our general goal has been to aim towards the ideal situation whereby within the body of the generic, all checks are performed when the generic body is compiled, and these checks fail if any possible instantiation could fail the checks. This goal has generally been achieved, (although some errors in the instance are detected at runtime; an example is the use of the Access attribute, see 12.3). Ada 95 thus achieves the prime goals associated with a tight contract model, and yet still provides the flexibility required to use generics to their best advantage. Improving the contract model eases the problems of code sharing for those implementations that use this technique. However, it should be noted that many of the applications of generics where code sharing seemed important can now be done using other techniques such as access to subprogram parameters and tagged types. Moreover, we have not provided an explicit pragma as suggested by the Requirements to control whether code sharing should be used or not since an implementation can use the pragma Optimize as suggested in [AARM 2.8(27)]. == <span id="2">12.2 Numeric Types</span> == Additional formal types are provided corresponding to unsigned integer types (modular types) and to decimal fixed point types as already mention in 3.3. The modular types form a subclass of the integer types. They have additional operations such as the logical operations that do not apply to all integer types. As a consequence a signed integer type cannot match a formal modular type. On the other hand modular types behave differently to signed integer types with regard to overflow since by definition they wrap around. And so a modular type cannot match a formal signed integer type. Similarly the decimal types form a subclass of the fixed point types. Again they are a distinct subclass to the ordinary fixed point types and one cannot match the other. The reason is that an implementation is allowed to use a significantly different representation (such as packed decimal) for decimal types as opposed to ordinary fixed types; it would impose unacceptable inefficiencies on implementations using shared generic bodies to accommodate both kinds of actual via one kind of formal. == <span id="3">12.3 Access Types</span> == Access types are considerably extended in Ada 95 as discussed in 3.7. They may access general objects not created by allocators; they may be marked as constant and there are also access to subprogram types. Accordingly, the matching rules for generic access parameters are adapted to allow for the proper matching of these other forms. For example if the formal type is <syntaxhighlight lang="Ada"> type A is access constant T;</syntaxhighlight> then the actual type must also be a general access type with the modifier constant. Similarly, if the formal type is <syntaxhighlight lang="Ada"> type A is access all T;</syntaxhighlight> then the actual type must also be a general access type (with all but not constant) that has the type T as its accessed type. In the case of access to subprogram types, the profiles of the formal and actual types have to be mode conformant (see 6.2). This is the same category of conformance as for renaming of subprograms (not renaming bodies) and thus naturally continues the general model that generic parameter matching is renaming. Note that there are restrictions on the use of the Access attribute in a generic body; these are different for access to subprogram and access to object types. The objective is of course to ensure that an access cannot be created to an entity at an inner level. In the case of an access to subprogram type, the access attribute is not allowed to be applied to a subprogram in a generic body if the access type is external to the generic unit because of worst case considerations. A possible workaround is to move the declaration of the subprogram P to the private part and to declare a constant in the private part thus <syntaxhighlight lang="Ada"> P_Access: constant Global_Access_Type := P'Access;</syntaxhighlight> and this will then be checked in the instance of the specification. In the case of access to object types a different approach is taken. The access attribute is allowed in a generic body but the check occurs dynamically if the access type is external to the body. This check is therefore similar to that for anonymous access parameters and Program_Error is raised if it fails. The different approach relates to the fact that anonymous access types are not allowed for subprogram parameters as discussed in 3.7.2. Also the workaround applicable to access to subprogam types of moving the use of Access to the specification cannot usually be applied in the case of access to object types. == <span id="4">12.4 Derived Types</span> == The class-wide programming features of Ada 95 reduce the need to use generics to deal with different types derived from the same root type. However, class-wide programming does not address the important capability, only provided by generics, of defining a new data structure that is parameterized by one or more component types. It is instructive to note that the object oriented programming languages C++, Eiffel, and Modula-3 all include some sort of generic or template mechanism in their latest incarnations. A new kind of generic formal parameter is provided for derived types. As mentioned above, we see an important role for generics in the definition of new data structures parameterized by one or more component types. For linked data structures, it is often necessary to take advantage of the structure of the components to efficiently implement the (composite) data structure. By using a generic formal derived type, the implementation of the generic can take advantage of the structure and operations of the ancestor type specified for the formal derived type definition. In the remainder of this section we consider formal (untagged) derived types; tagged types are considered in the next section. The new notation is <syntaxhighlight lang="Ada"> type T is new S;</syntaxhighlight> which indicates that the actual type must be derived directly or indirectly from S. For a generic formal derived type, the primitive operations available on the type in the generic are determined by the specified ancestor type. Analogous to the rule for formal numeric types, the primitive operations available on an untagged formal derived type use the ancestor operation implementations, even if they have been overridden or hidden for the actual type. This rule is necessary for untagged types, because there is no limitation on the kinds of alterations made to the subtype or mode of the formal parameters when overriding a subprogram inherited by derivation. This contrast strongly with tagged types where the whole essence of the concept is to use replaced operations as described in the next section. Generic formal derived types permit generic units to be parameterized by a user-defined class - the set of all types derived from the parent type specified in the generic parameter declaration. Within the generic template, the operations of the specified parent type are available. This provides support for user-defined classes that is comparable to that available for language-defined classes, such as discrete, integer, fixed and float. In a sense therefore the formal parameter notation <syntaxhighlight lang="Ada"> type T is range <>;</syntaxhighlight> is approximately equivalent to <syntaxhighlight lang="Ada"> type T is new root_integer;</syntaxhighlight> although we cannot actually write the latter. One use of generic formal derived types is to parameterize a generic with a record type but without having to introduce a specific notation for formal record types which would be unwieldy. The following example is a generic package for providing I/O for types in a user-defined rational class. <syntaxhighlight lang="Ada"> package Rational_Arithmetic is -- this package defines a rational number type type Rational is private; function "+" (Left, Right: Rational) return Rational; ... end Rational_Arithmetic; with Rational_Arithmetic; use Rational_Arithmetic; with Text_IO; generic -- this package provides I/O for any type derived from Rational type Num is new Rational; package Rational_IO is procedure Get(File: in Text_IO.File_Type; Item: out Num; Width: in Text_IO.Field := 0); procedure Put(File: in Text_IO.File_Type; Item: in Num; Fore: in Text_IO.Field; Aft: in Text_IO.Field; Exp: in Text_IO.Field); end Rational_IO;</syntaxhighlight> The generic formal parameter Num will only match Rational and its derivatives. Since Rational and its derivatives all share the primitive operations of the Rational type, those operations are available within Rational_IO for implementing the Get and Put subprograms. == <span id="5">12.5 Tagged Types</span> == Other forms of formal parameters apply to tagged types. Thus <syntaxhighlight lang="Ada"> type T is tagged private;</syntaxhighlight> which simply indicates that the actual type can be any tagged type, and <syntaxhighlight lang="Ada"> type T is new S with private;</syntaxhighlight> which indicates that the actual type can be any extension of the type S (or the type S itself). This last form is very important. A form of multiple inheritance is obtained by defining a generic package that extends a formal type with additional components and operations (see 4.6.2). Because type extension is only permitted for tagged types, allowing the reserved word tagged in a generic formal private type declaration makes it clear in the parameter specification that extension might be performed. But note that it is possible to declare a type extension (of a parameter) only in the generic specification; it is not allowed in the generic body. However, as illustrated in 4.6.2 this fits in with typical patterns of use. The above restriction is an interesting example of the best and worst case contract principle. The underlying rule that we must not violate is that a type extension must be accessible from the parent type declaration as discussed in 4.3. It is thus necessary that an extension in any instantiation also satisfies this rule. In the case of the specification we assume the best and allow an extension. At the point of the instantiation the resulting specification is checked to ensure that the extension does not violate the rule. In the case of the body the general contract principle is that the body must work for any instantiation and accordingly it is not permitted to allow an error to be discovered in the body for a particular instantiation. Thus we assume the worst and forbid any extension since the instantiation might be at a deeper level at which an extension would violate the accessibility rule. This restriction may seem a burden but a commonly applicable workaround is simply to move the type extension and its operations to the private part. An example where this would be necessary is discussed in 4.4.4. For tagged types, the primitive operations use the implementations defined for the actual type, though this is expressed for consistency in terms of the normal dispatching behavior of the operations of the parent type. For a tagged type it is possible to use the overriding definitions, because these overriding operations must be subtype conformant with the inherited one. A further refinement is that the formal type can be declared as abstract. In such a case the actual type can also be abstract but it need not. If the formal is abstract then no objects can be declared. The parameter matching rules are designed to ensure that abstract subprograms are never called. If a type is abstract it does not follow that all its primitive subprograms are abstract. Non-dispatching calls are allowed in the generic unit on only those primitive operations of the formal type which are not abstract. In order to ensure that any instantiation still correctly works it is necessary that the corresponding primitive operations of the actual type are also not abstract. Consider again the package P in 7.4. <syntaxhighlight lang="Ada"> generic type Parent is abstract new Limited_Controlled with private; package P is type T is new Parent with private; ... private type T is new Parent with record -- additional components end record; procedure Finalize(Object: in out T); end P;</syntaxhighlight> then although Limited_Controlled is abstract, its primitive operations such as Finalize are not abstract and thus calls on Finalize are allowed in the body. For this to always work it is essential that the actual type has not replaced the inherited procedure Finalize by an abstract one [RM95 3.9.3]. The following is thus illegal <syntaxhighlight lang="Ada"> type Nasty is abstract new Limited_Controlled with null record; procedure Finalize(Object: in out Nasty) is abstract; ... package Q is new P(Parent => Nasty); -- illegal</syntaxhighlight> Class-wide programming and type extension, in combination with generic units, provides many useful facilities. Generic units may be parameterized by user-defined classes, allowing abstractions to be built around such classes. In this example, Any_Account will be matched by any type derived from Account_With_Interest. Within the template, the primitive operations of Account_With_Interest are available. <syntaxhighlight lang="Ada"> generic type Account_Type(<>) is new Account_With_Interest with private; package Set_Of_Accounts is procedure Add_New_Account(A: in Account_Type); procedure Remove_Account(A: in Account_Type); function Balance_Of_Accounts return Money; ... -- other operations (e.g. an iterator) end Set_Of_Accounts;</syntaxhighlight> This generic package could be instantiated with a specific derivative of Account_With_Interest, in which case it would be a homogeneous set of such accounts. Alternatively, the generic could be instantiated with a class-wide type like Account_With_Interest'Class, in which case it would allow a heterogeneous set of accounts. The notation (<>) specifies that the actual account type may have any number of discriminants, or be a class-wide type (that is, it can be indefinite). == <span id="6">12.6 Package Parameters</span> == The final new kind of generic formal parameter is the formal package. A formal package parameter matches any instance of a specified generic package. Generic formal packages are appropriate in two different circumstances. In the first circumstance, the generic is defining additional operations, or a new abstraction, in terms of some preexisting abstraction defined by some preexisting generic. This kind of "layering" of functionality can be extremely cumbersome if all of the types and operations defined by the preexisting generic must be imported into the new generic. The generic formal package provides a direct way to import all of the types and operations defined in an instance of the preexisting generic. In other words, generic formal packages allow generics to be parameterized by other generics, which allows for safer and simpler composition of generic abstractions. In particular it allows for one generic to easily extend the abstraction provided by another generic, without requiring the programmer to enumerate all the operations of the first in the formal part of the second. A simple example of the use of this technique was illustrated by the package Generic_Complex_Vectors in II.11. In more elaborate circumstances, there may need to be several formal packages. It then proves convenient to augment the notation <syntaxhighlight lang="Ada"> with package P is new Q(<>);</syntaxhighlight> which indicates that the actual parameter corresponding to P can be any package which has been obtained by instantiating Q by the notation <syntaxhighlight lang="Ada"> with package R is new Q(P1, P2, ...);</syntaxhighlight> which indicates that the actual package corresponding to R must have been instantiated with the given parameters. Returning to our example of complex numbers, we can now write a package which exports standard mathematical functions operating on complex numbers and which takes two packages as parameters. One package defines the complex numbers (as in II.11) and the other package is the standard package Generic_Elementary_Functions which provides mathematical functions on normal real (that is not complex) numbers. We write <syntaxhighlight lang="Ada"> with Generic_Complex_Numbers; with Generic_Elementary_Functions; generic with package Complex_Numbers is new Generic_Complex_Numbers(<>); with package Elementary_Functions is new Generic_Elementary_Functions(Complex_Numbers.Float_Type); package Generic_Complex_Functions is use Complex_Numbers; function Sqrt(X: Complex) return Complex; function Log (X: Complex) return Complex; function Exp (X: Complex) return Complex; function Sin (X: Complex) return Complex; function Cos (X: Complex) return Complex; end Generic_Complex_Functions;</syntaxhighlight> The actual packages must be instantiations of Generic_Complex_Numbers and Generic_Elementary_Functions respectively. Note that both forms of formal package are used. Any instantiation of Generic_Complex_Numbers is allowed but the instantiation of Generic_Elementary_Functions must have Complex_Numbers.Float_Type as its actual parameter. This ensures that both packages are instantiated with the same floating type. Note carefully that we are using the formal exported from the first instantiation as the required parameter for the second instantiation. The formal parameters are only accessible in this way when the default form (<>) is used. Finally, instantiations might be <syntaxhighlight lang="Ada"> package Long_Complex_Numbers is new Generic_Complex_Numbers(Long_Float); package Long_Elementary_Functions is new Generic_Elementary_Functions(Long_Float); package Long_Complex_Functions is new Generic_Complex_Functions (Long_Complex_Numbers, Long_Elementary_Functions);</syntaxhighlight> A second circumstance where a generic formal package is appropriate is when the same abstraction is implemented in several different ways. For example, the abstraction of a "mapping" from a key type to a value type is very general, and admits to many different implementation approaches. In most cases, a mapping abstraction can be characterized by a key type, a value type, and operations for adding to the mapping, removing from the mapping, and applying the mapping. This represents a "signature" for the mapping abstraction, and any combination of types and operations that satisfy such a signature syntactically and semantically can be considered a mapping. A generic package can be used to define a signature, and then a given implementation for the signature is established by instantiating the signature. Once the signature is defined, a generic formal package for this signature can be used in a generic formal part as a short-hand for a type and a set of operations. We can thus define a generic package Mapping that defines the signature of a mapping, and then other generics can be defined with a formal package parameter. The mapping package might be <syntaxhighlight lang="Ada"> generic -- define signature for a Mapping type Mapping_Type is limited private; type Key is limited private; type Value is limited private; with procedure Add_Pair(M: in out Mapping_Type; K: in Key; V: in Value); with procedure Remove_Pair(M: in out Mapping_Type; K: in Key; V: in Value); with procedure Apply(M: in out Mapping_Type; K: in Key; V: out Value); package Mapping is end;</syntaxhighlight> We can now define a generic that takes an instance of a Mapping as a parameter; for example <syntaxhighlight lang="Ada"> generic with package Some_Mapping is new Mapping(<>); with procedure Do_Something_With_Value(V: Some_Mapping.Value) procedure Do_Something_With_Key(K: Some_Mapping.Key); procedure Do_Something_With_Key(K: Some_Mapping.Key) is V: Some_Mapping.Value; begin -- translate key to value, and then do something with value Some_Mapping.Apply(K, V); Do_Something_With_Value(V); end Do_Something_With_Key;</syntaxhighlight> The reader will note the tedious repetition of Some_Mapping in the generic unit. This can be avoided since a use clause is permitted in a generic formal part in Ada 95; the specification can thus be written as <syntaxhighlight lang="Ada"> generic with package Some_Mapping is new Mapping(<>); use Some_Mapping; with procedure Do_Something_With_Value(V: Value) procedure Do_Something_With_Key(K: Key);</syntaxhighlight> with similar changes to the generic body. Another and more mathematical example is provided by the following which defines the signature of a group. <syntaxhighlight lang="Ada"> generic type Group_Element is private; Identity: in Group_Element; with function Op(X, Y: Group_Element) return Group_Element with function Inverse(X: Group_Element) return Group_Element; package Group_Signature is end;</syntaxhighlight> The following generic function applies the group operation to the given group element the specified number of times. If the right operand is negative, the inverse of the result is returned; if it is zero, the identity is returned. <syntaxhighlight lang="Ada"> generic with package Group is new Group_Signature(<>); use Group; function Power(X: Group_Element; N: Integer) return Group_Element; function Power(X: Group_Element; N: Integer) return Group_Element is Result: Group_Element := Identity; begin for I in 1 .. abs N loop Result := Op(Result, X); end loop; if N < 0 then return Inverse(Result); else return Result; end if; end Power;</syntaxhighlight> The following instantiation ensures that the long complex numbers are a group over addition <syntaxhighlight lang="Ada"> package Long_Complex_Addition_Group is new Group_Signature(Group_Element => Long_Complex.Complex, Identity => (0.0, 0.0); Op => Long_Complex."+"; Inverse => Long_Complex."-");</syntaxhighlight> and then finally we can instantiate the power function for the long complex addition group as follows <syntaxhighlight lang="Ada"> function Complex_Multiplication is new Power(Long_Complex_Addition_Group);</syntaxhighlight> Note that we have assumed that the type Complex is not a private type so that the aggregate is available for the identity element. == <span id="7">12.7 Other Improvements</span> == A small change is that the matching of subtypes in array and access types now requires static matching as mentioned in 3.10. Another minor change is that generic actual parameters are evaluated in an arbitrary order consistent with any dependences whereas in Ada 83 all default parameters were evaluated after all explicit parameters. The relaxation of this ordering requirement brings the rules for generic parameters into line with those for ordinary subprogram parameters. == <span id="8">12.8 Requirements Summary</span> == There were a number of requirements in this area. The study topic * S4.4-A(1) - Generic Formal Parameters is satisfied by the provision of extra kinds of generic parameters (for derived types and especially package parameters) to enable better abstraction and composition. The study topic * S4.4-B(2) - Tighten the "Contract Model" has been met by the provision of separate templates for definite and indefinite types and other modifications to the rules as discussed in 12.1. The requirement * R4.4-B(1) - Dependence of Instantiations on Bodies has also been met by the improvements to the contract model. The requirement * R4.4-C(1) - Generic Code Sharing is discussed in 12.1 where it is noted that the pragma Optimize can be used to control whether sharing is required or not. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-11|Previous]] | [[Guide:9x_rationale/rat95-p2-13|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=12 Generics}} e3dyxlvrot0m764r5jtli683mtgvvym Guide:9x rationale/rat95-p2-13 4200 335 1868 1834 2019-04-20T16:20:37Z WikiVisor 11 Text replacement - "[[Guide:9x_rationale/rat95-copyright|Copyright]] | " to "<div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | " wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-12|Previous]] | [[Guide:9x_rationale/rat95-p3|Next]]</div> This part of the reference manual has always been a pot-pourri of bits and pieces often neglected by users and implementors alike. However, it is an important area especially for embedded systems where tight control of the implementation is required. The changes in Ada 95 are designed to make the vague control promised by Ada 83 into a reality. The main changes are * The mechanism for specifying representations such as size and alignment is generalized and their meaning is clarified. * Additional types and operations are provided for address and offset manipulation. * The Valid attribute enables a potentially dubious value (such as might be obtained through calling Unchecked_Conversion or interfacing to another language) to be checked for validity. * Facilities are provided for the more detailed control of heap storage for allocated objects. * The rules regarding the freezing of representations are properly defined. * The pragma Restrictions is provided for specifying that only a subset of the language is to be used. * The concept of streams and various stream attributes are introduced. By their nature, these features of the language concern fine detail for which the reader is referred to [RM95]. In this chapter we will only discuss the broad principles involved. Note that the material on interfacing to other languages is now described in a separate annex of [RM95]; see Chapter B in Part Three. Note also that although the general concept of streams and the stream attributes are defined in section 13 of [RM95], their main application is for input-output and they are therefore discussed in A-1.4. == <span id="1">13.1 Representation of Data</span> == The first point to note is that the notation has been unified so that the attribute form can be used for setting all specifiable attributes. Thus <syntaxhighlight lang="Ada"> for X'Address use 8#100#;</syntaxhighlight> rather than for X use at 8#100#, and <syntaxhighlight lang="Ada"> for R'Alignment use 2;</syntaxhighlight> rather than at mod 2 in a record representation clause. (The old notations are allowed for compatibility although considered obsolete.) An important reason for the unified notation is that we wish to allow implementations to define additional user-specifiable attributes in a consistent manner. Furthermore the annexes define many additional attributes as discussed in Part Three. The Alignment attribute can be applied to all first subtypes and objects whereas the mod clause only applied to records in Ada 83. An overall rule is that the Address of an object must be an integral multiple of its Alignment. In the case of internal objects the user must ensure that this is not violated if one or both attributes are specified. In the case of external objects, the attributes may also be specified but then they are more in the nature of an assertion; again it is assumed that the relationship holds. It is now possible to specify the order of numbering bits. This is particularly important when using record representation clauses to ensure that we know which way round the bits are numbered. For example <syntaxhighlight lang="Ada"> for R'Bit_Order use Low_Order_First;</syntaxhighlight> where R is a record type indicates that the first bit (bit 0) is the least significant. There was much confusion in Ada 83 over the Size attribute. This is now clarified and the reader is referred to the discussion in [RM95] for details. An important point is that the Size attribute may now be set for individual objects rather than just to types as in Ada 83. == <span id="2">13.2 The Package System</span> == The package System.Storage_Elements contains additional types and operations to enable addresses and offsets to be manipulated in a standard manner. The comparison operators are defined for the type Address in the package System itself whereas other facilities are in the child package System.Storage_Elements. This latter package includes a type Storage_Offset and operations to add and subtract such values to and from values of type Address. Storage offsets are of course relative whereas addresses are absolute (echoes of duration and time) and so adding a storage offset to an address returns an address and so on. The generic child package System.Address_To_Access_Conversions provides the ability to convert neatly between values of the type Address and values of a given general access type; this enables "peeking" and "poking" to be done in a consistent manner. Finally note that the pragmas System_Name, Storage_Unit and Memory_Size are now obsolete. They were not uniformly implemented in Ada 83 and it was not at all clear what they should mean. For example, in most implementations, it does not make sense to change the number of bits in a storage unit, and even if it did, it would not be sufficient to make only the package System obsolete; clearly all generated code depends on this value. Consequently we no longer require implementations to support these pragmas. Of course, implementations that already support them with some particular meaning can continue to do so (as implementation defined pragmas) for upward compatibility. On the other hand the corresponding named numbers in package System are quite useful as queries and so remain. == <span id="3">13.3 The Valid Attribute</span> == There are occasions when Unchecked_Conversion is very valuable although inherently dangerous. The Valid attribute enables the programmer to ensure that the result of an unchecked conversion is at least a valid value for the subtype concerned (even if not what the programmer hoped for). Some risks of catastrophe are thereby avoided. The [RM95 13.9.2] lists the ways in which invalid data could be obtained. As well as unchecked conversion this includes results obtain through interfacing to another language and uninitialized data. Note that Valid is only defined for objects of scalar types. == <span id="4">13.4 Storage Pool Management</span> == For Ada 95, we have provided the user with the ability to override the default algorithms for allocating and deallocating heap storage. This is done by the introduction of the concept of a storage pool which provides the storage for objects created by allocators. Every access to object type is associated with some storage pool which is a pool of memory from which the storage for allocated objects is obtained. The storage pool for an access type may be shared with other access types. In particular, any derivative of an access type shares the same storage pool as the parent access type. More importantly, an implementation might use a common global heap by default. An allocator for an access type allocates storage from the associated storage pool. The package System.Storage_Pools provides mechanisms for defining a storage pool type as an extension of the abstract type Root_Storage_Pool. We can then associate a storage pool with a particular access type by specifying the Storage_Pool attribute for the access type. Alternatively, a bounded storage pool may be requested by specifying the Storage_Size attribute for an access type, as in Ada 83. In the absence of a specification of either the Storage_Pool or Storage_Size attribute of an access type, the implementation chooses an appropriate storage pool for the type. Pool-specific access values never point outside of their storage pool (in the absence of unchecked conversion and the like). On the other hand, general access values may be assigned to point to any aliased object of an appropriate type and scope, either through the use of the Access attribute or explicit access type conversion. The storage pool concept makes explicit the notion of a "heap", and when combined with the ability to specify a Storage_Pool object for an access type, gives the user better control over dynamic allocation. The use of storage pools is illustrated by the following example which shows how an application can use a special allocator algorithm to meet its precise storage requirements. The storage pool associated with the access type supports mark and release operations, allowing rapid reclamation of all storage allocated from the pool during some phase of processing. <syntaxhighlight lang="Ada"> with System.Storage_Pools; with System.Storage_Elements; use System; package Mark_Release_Storage is type Mark_Release_Pool(Size: Storage_Elements.Storage_Count) is new Storage_Pools.Root_Storage_Pool with private; type Pool_Mark is limited private; -- now provide the controlled operations procedure Initialize(Pool: in out Mark_Release_Pool); procedure Finalize(Pool: in out Mark_Release_Pool); -- now provide the storage pool operations procedure Allocate( Pool : in out Mark_Release_Pool; Storage_Address: out Address; Size_In_Storage_Elements: in Storage_Elements.Storage_Count; Alignment : in Storage_Elements.Storage_Count); procedure Deallocate( Pool : in out Mark_Release_Pool; Storage_Address: in Address; Size_In_Storage_Elements: in Storage_Elements.Storage_Count; Alignment : in Storage_Elements.Storage_Count); function Storage_Size(Pool: Mark_Release_Pool) return Storage_Elements.Storage_Count; -- additional subprograms for the Mark_Release_Pool procedure Set_Mark( Pool: in Mark_Release_Pool; Mark: out Pool_Mark); -- marks the current state of the pool for later release procedure Release_To_Mark( Pool: in out Mark_Release_Pool; Mark: in Pool_Mark); -- frees everything allocated from the Pool since Set_Mark. -- all access values designating objects allocated since then -- become invalid. private ... end Mark_Release_Storage;</syntaxhighlight> This example demonstrates how a package defines a special type of mark/release storage pool, derived from System.Storage_Pools.Root_Storage_Pool (see [RM95 13.11]). Note carefully that the procedures Allocate and Deallocate are invoked implicitly by the Ada 95 allocator and Unchecked_Deallocation facilities in much the same way as Initialize, Adjust and Finalize are implicitly called by the run-time system for controlled types (see 7.4). Moreover, the type Root_Storage_Pool is itself a limited controlled type and so the procedures Initialize and Finalize are provided. This example includes two additional operations on the storage pool type, which the user can use to set a mark and then later release the pool to a marked state, and thereby reclaim all recently allocated storage. The declaration of Mark_Release_Pool indicates that it is also extended with additional private components that would be supplied in the private part. In order to use the above package we first have to declare a particular pool and then specify it as the pool for the access type concerned. We might write <syntaxhighlight lang="Ada"> use Mark_Release_Storage; Big_Pool: Mark_Release_Pool(50_000); type Some_Type is ...; type Some_Access is access Some_Type; for Some_Access'Storage_Pool use Big_Pool;</syntaxhighlight> This declares the pool Big_Pool of the type Mark_Release_Pool and then associates it with the access type Some_Access by the representation clause. The discriminant of 50,000 acts as an initialization parameter perhaps indicating the total size of the pool. We can then allocate and use objects in the usual way. We can also use the special mark and release capabilities provided by this particular type of pool. <syntaxhighlight lang="Ada"> declare Mark: Pool_Mark; Done: Boolean := False; begin -- set mark prior to commencing the loop Set_Mark(Big_Pool, Mark); while not Done loop -- each iteration allocates a data structure composed of -- objects of Some_Type, which may be discarded -- before the next iteration. declare X, Y : Some_Access; begin -- algorithm that allocates various objects from -- the mark/release storage pool X := new Some_Type; ... Y := new Some_Type; ... -- release storage each time through the loop Release_To_Mark(Big_Pool, Mark); exception when others => -- release storage then reraise the exception Release_To_Mark(Big_Pool, Mark); raise; end; end loop; end;</syntaxhighlight> Note carefully that the assignments such as <syntaxhighlight lang="Ada"> X := new Some_Type;</syntaxhighlight> implicitly call the Allocate procedure thus <syntaxhighlight lang="Ada"> Mark_Release_Storage.Allocate(Pool => Big_Pool,...);</syntaxhighlight> Any calls on Unchecked_Deallocation will similarly result in an implicit call of Deallocate. == <span id="5">13.5 Freezing of Representations</span> == Certain uses of an entity or the type of an entity cause it to be frozen; these are situations where the representation has to be known (and if none has been specified the implementation will then choose a representation by default). These uses were called forcing occurrences in Ada 83 (the name has been changed because not all the situations causing freezing are actual occurrences of the name of the entity). The forcing occurrence rules of Ada 83 did not really achieve their objective; sometimes they were too lax and sometimes too rigid; the freezing rules of Ada 95 are intended to more exactly satisfy the objective of identifying when the representation has to be determined. The situations causing freezing and the operations not allowed on a frozen entity are described in [RM95 13.14]. There seems little point in repeating the discussion here but one point of difference worth emphasizing is that the loophole in deferred constants in Ada 83 which allowed uninitialized access values is now blocked. The new rules were designed to overcome this and similar problems with the Ada 83 rules. === <span id="5-1">13.5.1 Freezing and Tagged Types</span> === The freezing rules for tagged types are important. The two main ones are that a record extension freezes the parent and a primitive subprogram cannot be declared for a frozen tagged type - this applies to both new ones and overridden ones. Using the illustrative model of the tag and dispatch table in 4.3 this means that the contents of the dispatch table can be determined as soon as the type is frozen. A consequence of these freezing rules is that we cannot declare further primitive subprograms for a tagged type after a record extension of it has been defined. This was mentioned in II.1 during the discussion of the alert system when we noted the practical benefit of being able to declare a sequence of derived types in one package. But note that although a record extension freezes the parent type a private extension does not. In the private case the parent type is frozen at the full type declaration (which will be a record extension anyway). So in the following <syntaxhighlight lang="Ada"> package P is type T is tagged ...; type NT is new T with private; procedure Op(X: T); private type NT is new T with ...; end P;</syntaxhighlight> the partial declaration of NT does not freeze T and so the further operation Op can be added. This operation is also inherited by NT although it is not visible for the partial view of NT (since its declaration was after that of the partial view); it effectively gets added at the full declaration. So <syntaxhighlight lang="Ada"> A: NT'Class := ...; Op(A);</syntaxhighlight> is illegal outside P but legal in the body of P. Note that we can add an operation, OpN for NT before the new operation Op for T thus <syntaxhighlight lang="Ada"> package P is type T is tagged ...; type NT is new T with private; procedure OpN(X: NT); procedure Op(X: T); private type NT is new T with ...; end P;</syntaxhighlight> and in this case, perhaps surprisingly, we have added a new operation for the dispatch table of NT before knowing all about the dispatch table of T (which of course forms the first part of the table for NT). However, the full declaration of NT will freeze T and prevent further operations being added for T. It is instructive to reconsider the alert system discussed in Part One and to rearrange the declarations to minimize spurious visibility. The details of the various types need not be visible externally (we can imagine that they are initialized by operations in some child package). Moreover, it is only necessary for the procedure Handle to be visible externally since Display, Log and Set_Alarm are only called internally from the procedures Handle. However, in the case of Display it is important that it be a dispatching operation if the redispatching discussed in 4.5 is to be possible. The package could thus be reconstructed as follows <syntaxhighlight lang="Ada"> with Calendar; package New_Alert_System is type Alert is abstract tagged private; procedure Handle(A: in out Alert); type Low_Alert is new Alert with private; type Medium_Alert is new Alert with private; type High_Alert is new Alert with private; private type Device is (Teletype, Console, Big_Screen); type Alert is tagged record Time_Of_Arrival: Calendar.Time; Message: Text; end record; procedure Display(A: in Alert; On: in Device); -- also dispatches procedure Log(A: in Alert); type Low_Alert is new Alert with null record; type Medium_Alert is new Alert with record Action_Officer: Person; end record; -- now override inherited operations procedure Handle(MA: in out Medium_Alert); procedure Display(MA: in Medium_Alert; On: in Device); type High_Alert is new Medium_Alert with record Ring_Alarm_At: Calendar.Time; end record; procedure Handle(HA: in out High_Alert); procedure Display(HA: in High_Alert; On: in Device); procedure Set_Alarm(HA: in High_Alert); end New_Alert_System;</syntaxhighlight> In this formulation all the alerts are private and the visible part consists of a series of private extensions. If the private extensions froze the parent type Alert then it would not be possible to add the private dispatching operation Display in the private part. The deferral of freezing until the full type declaration is thus important. Note that we have also hidden the fact that the High_Alert is actually derived from Medium_Alert. Remember that the full type declaration only has to have the type given in the private extension as some ancestor and not necessarily as the immediate parent. We can now add a child package for the emergency alert as suggested in II.7 and this will enable a new Display and Handle to be added. <syntaxhighlight lang="Ada"> package New_Alert_System.Emergency is type Emergency_Alert is new Alert with private; private type Emergency_Alert is new Alert with record ... end record; procedure Handle(EA: in out Emergency_Alert); procedure Display(EA: in Emergency_Alert; On: in Device); end New_Alert_System.Emergency;</syntaxhighlight> We could make the procedure Display visible by declaring it in the visible part; it would still override the inherited version even though the inherited version is private as mentioned in 7.1.1. == <span id="6">13.6 The Pragma Restrictions</span> == There are some application areas where it is useful to impose restrictions on the use of certain features of the language. Thus it might be desirable to know that only certain simple uses of tasking are made in a particular program; this might allow the program to be linked with an especially efficient run-time system for use in a hard real time application. Another area where more severe restrictions are relevant is for safety-critical applications where it is required that application programs are written using only simple parts of the language so that they are more amenable to mathematical proof. Restrictions on the use of the language may be imposed by the pragma Restrictions. The possible arguments to this pragma are defined in the Real-Time Systems and Safety and Security annexes [RM95 D7, H3]. == <span id="7">13.7 Requirements Summary</span> == The requirement * R6.2-A(1) - Data Interoperability is partially met by the provision of better control over representations such as the alignment of objects. The study topic * S6.4-B(1) - Low-Level Pointer Operations is addressed by the attribute Unchecked_Access and address and offset operations in the package System.Address_To_Access_Conversions. The requirement * R4.2-A(1) - Allocation and Reclamation of Storage is met by the storage pool mechanism described in 13.4. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-12|Previous]] | [[Guide:9x_rationale/rat95-p3|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=13 Representation Issues}} 9wym6m2dlalfz9lw2k6ajx90d8cyzlf Guide:9x rationale/rat95-p2-2 4200 336 1875 1836 2019-04-20T16:20:48Z WikiVisor 11 Text replacement - "|Next]]" to "|Next]]</div>" wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-1|Previous]] | [[Guide:9x_rationale/rat95-p2-3|Next]]</div> There are only a small number of changes in this part of the language but they are important. The following are worth noting * There are six more reserved words. * The program text character set is extended. * The rules regarding pragmas are improved. == <span id="1">2.1 Reserved Words and Identifiers</span> == Ada 95 has six more reserved words which are abstract, aliased, protected, requeue, tagged, and until. In addition the word "access" is also used as both an attribute and a reserved word. The introduction of new reserved words poses a potential incompatibility problem. However, the new words are not likely to have been particularly popular as program identifiers and so little problem should arise. It was suggested by some reviewers that new reserved words should be avoided by the subtle reuse of existing words in various contexts. This might have led to a bizarre and unnatural language for the sake of avoiding very occasional incompatibility. It would certainly have made the language seem strange and unattractive especially to those not familiar with the background to the development. The smooth integration of the new and important features such as type extension and protected types could not have been achieved without the introduction of additional reserved words. There are some changes to the terminology in order to clarify the exposition. For example, reserved words are no longer formally classed as identifiers; this has some impact on the syntax as mentioned in 1.3. Also the term numeral is introduced in the discussion of literals. == <span id="2">2.2 Program Text</span> == As part of the original agreement between ISO and ANSI to accept ANSI/MIL-STD-1815A as an international standard, ANSI agreed to provide better support for international character sets in the first revision of Ada. Therefore, Ada 95 uses an 8-bit character set based on ISO-8859, and a 16-bit character set based on ISO-10646. These extended character sets are usable in character and string literals and also in comments. The text of a program (outside literals) is typically written in the Latin-1 set, ISO-8859-1 and thereby allows accented characters in identifiers. Moreover, an implementation is allowed to support other character sets provided that it has a mode in which the "standard" sets are supported. This enables national variations to support sets such as those used in Japan. See [RM95 2.1]. In order to promote portability all implementations are required to support a line length of at least 200 characters. == <span id="3">2.3 Pragmas</span> == In order to improve error detection when dealing with implementation defined pragmas, we require that compilers produce a warning when a pragma is unrecognized, and identify as an error a pragma that is misplaced or malformed. In Ada 83, it was permissible for compilers to ignore such pragmas without a warning, which could lead to unexpected behavior. We have formalized the definition of configuration pragmas to specify options that affect more than a single compilation unit (often an entire program). There are a number of additional pragmas in Ada 95 which will be mentioned in the course of the discussion. == <span id="4">2.4 Requirements Summary</span> == The requirement and study topic * R3.1-A(4) - Extended Comment Syntax * S3.1-A(5) - Extended Identifier Syntax are both addressed and met by the changes mentioned above. Indeed, recently approved Ada Issues permit Ada 83 compilers to meet these requirements on a voluntary (non-binding) basis. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-1|Previous]] | [[Guide:9x_rationale/rat95-p2-3|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=2 Lexical Elements}} 7nv5bk5xdus6jbnz0z0g19skoisxi20 Guide:9x rationale/rat95-p2-3 4200 337 1876 1831 2019-04-20T16:20:48Z WikiVisor 11 Text replacement - "[[Guide:9x_rationale/rat95-copyright|Copyright]] | " to "<div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | " wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-2|Previous]] | [[Guide:9x_rationale/rat95-p2-4|Next]]</div> This chapter covers a number of changes. Some are essentially functional changes in their own right such as the addition of modular types, but many of the changes are more to provide a better framework for the establishment of the object oriented programming facilities which are described in the next chapter. The main changes are * The foundation concepts and terminology are improved. The idea of a view is formalized. The concepts of a type and class are clarified. The concept of an object is generalized. * The rules for derived types and their operations are changed to accommodate type extension. * Character types are changed to conform to the requirements for 8-bit and wider character sets. * The numeric model is revised to provide a closer mapping to actual machine architectures; the types root_integer and root_real are added to aid the description. * Modular (unsigned integer) and decimal fixed point types are added. * Discriminants are generalized and the concepts of definite and indefinite subtypes introduced. This is particularly relevant to generic parameter matching. * The rules for implicit array subtype conversion are liberalized to allow sliding in all contexts except qualification (and, of course, membership tests). * Array aggregates with others are allowed in more contexts. * Access types are greatly generalized to provide general access types and access to subprogram types. * The rules for type conversion are extended to cover the new features in the language. * The rules for staticness are more liberal thereby allowing more expressions to be considered static. * There are a number of minor improvements such as the removal of the irritating rule regarding the order of declarations. It be should be noted that the enhanced forms of access types constitute a major extension to the language in their own right. They provide the more flexible interfacing which was highlighted as one of the four main areas of User Need in I.3. Type extension, class-wide types and polymorphism are discussed in the next chapter. == <span id="1">3.1 Types, Classes, Objects and Views</span> == The term view is widely used in the description to make it easier to separate properties associated with an entity from properties associated with a particular reference to an entity. For example, a type may have two views, one in places where its full declaration is visible, and one where the type is private. Another example occurs in renaming where two subprogram names may denote the same subprogram, but with different formal parameter names associated with these two different views. We have generalized the term class to include user-defined classes defined by a type and all its direct and indirect derivatives; we call these derivation classes. The concept of language-defined type classes (such as the discrete class or the real class) allowed the description of Ada 83 to be more economical, and easier to understand. This same economy of definition and understanding is valuable for a user-defined type hierarchy forming a class. There is a strong distinction between specific types and class-wide types. Specific types are those declared by type declarations, and correspond to Ada 83 types. Each specific tagged type T has an associated class-wide type, T'Class. Class-wide types enable class-wide (polymorphic) programming, because a subprogram with a formal parameter of a class-wide type like T'Class accepts actual parameters for any type covered by the class-wide type (that is, T or any of its derivatives). In the implementation of such a subprogram, the operations of the root type (T in this case) are available. It is also possible to write dispatching operations, which automatically dispatch to the appropriate implementation based on the type tag of the actual parameter. A class- wide operation of a tagged class-wide type usually calls one or more dispatching operations of the specific type. The universal types which existed in Ada 83 remain and act much as class-wide types for the numeric classes. However, there are important differences which are discussed in 3.3. To simplify and unify the description of the Ada 95 type model, we have adopted the terms elementary and composite for describing the two major categories of Ada types. Elementary types have no internal structure, and are used to represent simple values. Composite types are made up of components and other internal state, and are used to represent more complex values and objects. There are a number of existing Ada 83 rules, and new Ada 95 rules, that are made simpler by expressing them only in terms of elementary and composite types, rather than by enumerating more specific type classes. There was much confusion in Ada 83 regarding the distinction between types and subtypes. In Ada 95, only subtypes have names. A type declaration such as <syntaxhighlight lang="Ada"> type A is array (Integer range <>) of Float;</syntaxhighlight> introduces a first subtype named A. The underlying type has no name. In this case the first subtype is unconstrained. (We now say first subtype rather than first named subtype.) On the other hand a declaration such as <syntaxhighlight lang="Ada"> type B is array (Integer range 1 .. 10) of Float;</syntaxhighlight> introduces a first subtype named B which is constrained. Another point is that in Ada 83 a type was also a subtype; this is not the case in Ada 95. This change of nomenclature has no semantic effect; it is designed to simplify later description. In particular, the term type mark is now replaced by subtype mark since it is always the name of a subtype, and one need never say "type or subtype". The idea of an object is generalized. The result of a function and of evaluating an aggregate are now considered to be (anonymous) constant objects. One consequence of this is that the result of a function call can be renamed; this is particularly useful for limited types, see 7.3. Some things are not objects, for example named numbers are not objects. === <span id="1-1">3.1.1 Classification of Operations</span> === We have introduced the term primitive operations to encompass that set of operations that are "tightly bound" to a type, being either explicitly or implicitly declared at the point of the type declaration, and inherited by derivatives of the type. These operations are the closed set that effectively define the semantics of the type. The more general term "operation" of a type is no longer formally used. Ada 83 used "implicit conversion" to explain how integer literals were usable with any integer type, and how real literals were usable with any real type. For Ada 95, we have adopted a similar mechanism as the basis for class-wide programming. However, rather than using the concept of implicit conversion, the static semantic rules are defined in terms of type resolution between actual parameters and formal parameters. (The implicit conversions still happen but are not part of overload resolution.) As in Ada 83, if the actual parameter and the formal parameter are of the same type, then the actual matches the formal. However, the type resolution rules also allow certain other combinations. In particular, if a formal parameter is of a class-wide type, then the actual parameter may be of any type in the class. This allows the definition of class- wide operations. A similar approach is taken with universal types. A formal parameter of a universal type is matched by any type of the corresponding numeric class. Thus the Val attribute (which accepts an operand of type universal_integer) can be matched by any integer type. There is a change to the rules for fixed point multiplication and division which now take universal_fixed operands as explained in 3.3.1 and can thus be matched by any fixed point type. In addition to class-wide matching, the type resolution rules cover the use of access parameters (not to be confused with parameters of an access type, see 3.7.1). When a formal is an access parameter, only the designated type of the actual parameter is considered for matching purposes. The actual matches the formal if their designated types are the same, or, in the case of tagged types, one is T while the other is T'Class. In addition, for tagged types, changes of representation are not permitted for derived types, so an actual also matches a formal access parameter if the designated type of the actual is covered by the designated type of the formal. Access parameters allow operations to be defined that take access values rather than designated objects, while still keeping the operation a primitive operation of the designated type. With tagged types, this allows "dispatching on access types" without requiring the access value to be dereferenced first. Another important change is that the attribute S'Base may be used as a subtype mark generally, rather than strictly as a prefix for other attributes. S'Base denotes an unconstrained subtype of the type of S and is only allowed for elementary types. It is particularly useful within a generic package that might be instantiated with a constrained numeric subtype, since the temporary variables used to perform a calculation might need to be unconstrained, even if the parameters and final result of an operation must satisfy the constraints of the actual constrained subtype. For example consider the implementation of Generic_Elementary_Functions. We need to allow the user to instantiate the package with a constrained subtype corresponding to Float_Type, but do not wish the calculations to be constrained. Accordingly the parameters and results of the various functions are of the subtype Float_Type'Base. One potential problem with allowing the declaration of objects of subtype S'Base is that the first subtype (for example S) may have a size clause that takes advantage of the constraints on S. Objects of subtype S'Base cannot generally be limited by the size specified for S. There are several reasons why this problem is not serious in practice: * Many compilers already use different sizes for different subtypes of the same type; * The construct for B in S'Base'First .. S'Base'Last loop ... is already legal in Ada-83 (presuming S is discrete), and is an existing way to effectively create an object (B) of subtype S'Base; === <span id="1-2">3.1.2 Derived Types</span> === For Ada 95, we have chosen to build upon the Ada 83 derived type mechanism to provide for type extension (single inheritance) and run-time polymorphism, two fundamental features of object-oriented programming. (Derived types were the existing type inheritance mechanism in Ada 83.) If a new inheritance mechanism had been introduced, perhaps based on "package types" or an explicit "class" construct, inheritance based on derived types would still remain as an almost redundant and complicating alternative inheritance mechanism. Choosing to enhance the basic derived type mechanism provides a single robust inheritance mechanism rather than two potentially conflicting and weaker ones. Rather than introducing an explicit class construct, we have instead chosen to support user-defined classes via a hierarchy of derived types. The (derivation) class rooted at a type T consists of T and all of its direct and indirect derivatives. The existing Ada 83 rules for derived types ensure that all of the types in the class rooted at T have at least the same set of primitive operations as T, because a derivative may override and add operations, but it cannot eliminate an operation inherited from the parent type. Having a set of operations that are well defined for all types in a class rooted at some type T makes it meaningful to construct class-wide operations that take advantage of this commonality. Much of the power and economy of object-oriented programming comes from the ability to write such class-wide operations easily. If an operation is explicitly defined on a class-wide type, then it is a class-wide operation via the type resolution rules. The existing universal types behave very much as class-wide numeric types. In fact we introduce types root_integer and root_real as the numeric types from which all other numeric types are descended and then the universal types can be considered to be the class-wide types corresponding to these root types. Ada 83 already had existing operations such as the Val attribute that took an operand of any integer type; in Ada 95 this is described by saying that Val takes an operand of the universal_integer type. These are therefore like class-wide operations. == <span id="2">3.2 Character Types</span> == We mentioned in Chapter 2 that the text of an Ada 95 program can be written using more liberal character sets. In this section we consider the support for character types in the executing program. As part of providing better support for international character sets, the fundamental character set of Ada 95 is changed from the seven-bit ISO 646 standard, to the eight-bit ISO 8859 standard (which includes Latin- 1). This means that the type Character in package Standard is now an enumeration type with 256 positions, rather than just 128. This change is not upward compatible for programs that have arrays indexed by Character, or case statements over Character. However, the benefits of accommodating international character sets were felt to outweigh the costs of this upward incompatibility. See X.2. To facilitate direct use of character literals and string literals from all languages in the international community, a type Wide_Character is declared in package Standard. The type Wide_Character has 2**16 positions, and starts with the 256 enumeration literals of the type Character. The predefined library package Ada.Characters has a child package Characters.Handling containing useful classification and conversion functions (such as Is_Letter and To_Lower) and a child package Characters.Latin_1 containing constants for the Latin-1 symbol set. There is also a string type Wide_String indexed by subtype Positive, with component subtype Wide_Character. == <span id="3">3.3 Numeric Types</span> == The model of numeric types is somewhat different in Ada 95. The overall goal of the change is to give the implementation more freedom for optimizations such as keeping intermediate results and local variables in registers. Most of the change is fine detail that need not concern the normal user and is addressed in the Numerics annex. However, one area that is important in the core language is the somewhat different treatment of universal types and the introduction of the anonymous types root_integer and root_real. The essence of the root types is that they can be considered as the types from which all other integer and real types are derived. The base range of root_integer is thus System.Min_Int .. System.Max_Int. We will first discuss the integer types and then indicate where the floating types differ. We have introduced the term base range for the implemented range of a type whereas range refers to the requested range of a particular subtype. Range checks only apply to constrained subtypes; overflow checks always apply. An important consequence is that we either get the mathematically correct answer or Constraint_Error is raised. Thus if we write <syntaxhighlight lang="Ada"> type My_Integer is range -20_000 .. +20_000; MI: My_Integer; MIB: My_Integer'Base;</syntaxhighlight> then My_Integer'Range will be -20_000 .. +20_000 and all assignments to variables of the subtype My_Integer such as MI will be checked to ensure that the range is not violated; Constraint_Error is raised if the check fails. On the other hand, the base range of My_Integer is the range of My_Integer'Base and this will be that of the implemented range which might reflect that of a 16-bit word and thus be -2**15 .. +2**15-1. No range checks apply to assignments to the variable MIB. However, as an optimization, it might be the case that a particular variable of the subtype My_Integer'Base is held in a register and this could have a wider range than the base range of the subtype. The base range is thus the guaranteed minimum implemented range. Nevertheless overflow checks will always apply and MIB will never have a mathematically incorrect value although the value could be outside the base range. For example, consider <syntaxhighlight lang="Ada"> X: My_Integer := 18_000; Y: My_Integer := 15_000; ... MIB := X + Y;</syntaxhighlight> where we will assume that the computation is not all optimized away by a smart compiler! (Note that no explicit conversion is needed because My_Integer and My_Integer'Base are both subtypes of the same (unnamed) type. Remember that all types are unnamed.) If MIB is implemented with its base range then an overflow will occur and result in Constraint_Error because the result is outside the base range. If, however, MIB is held in a 32-bit register, then no overflow will occur and MIB will have the mathematically correct result. On the other hand <syntaxhighlight lang="Ada"> MI := X + Y;</syntaxhighlight> will always result in Constraint_Error being raised because of the range check upon the assignment. In the case of the predefined types such as Integer the same rules apply; the subtype Integer is constrained whereas Integer'Base is not. The base range and range happen to be the same. So the declarations <syntaxhighlight lang="Ada"> I: Integer; IB: Integer'Base;</syntaxhighlight> have a different effect. Checks will apply to assignments to I but not to assignments to IB (but remember that an implementation is always free to add checks if convenient; they may be automatic). Another possibility for optimization is that an intermediate expression might be computed with a larger range. This is why the predefined operators such as "+" on the predefined types such as Integer have parameters and result of Integer'Base rather than Integer. There are no range checks on these operations (just overflow checks). Now consider <syntaxhighlight lang="Ada"> MI := X * Y / 30_000;</syntaxhighlight> in which we will assume that the computation is done with the operations of type Integer which has a 16-bit base range on this implementation. If the operations are done from left to right and the operations are performed in 16-bit registers then overflow will occur and Constraint_Error will be raised. On the other hand, the operations might be performed in 32-bit registers in which case overflow will not occur and the correct result will be assigned to MI after successfully performing a range check on the result. The universal types are types which can be matched by any specific numeric type of their class. We see therefore that the universal types are rather like class-wide types of the respective classes. So universal_integer is thus effectively root_integer'Class. The integer literals are, of course, of the type universal_integer and so, as in Ada 83, can be implicitly converted to any integer type including the anonymous root_integer. An important distinction between universal and tagged class-wide types is that the latter carry a tag and explicit conversion to a specific type is required which is checked at runtime to ensure that the tag is appropriate, see 3.8. One consequence of treating universal_integer as matching any integer type is that the rules for the initial expression in a number declaration are more liberal than they were in Ada 83. The initial expression can be of any integer type whereas in Ada 83 it had to be universal; it still of course has to be static. Similar remarks apply to real types. In the case of floating point types a range check is only applied if the definition contains a range (this is the same rule as for integer type definitions but they always have range anyway). So given <syntaxhighlight lang="Ada"> type My_Float is digits 7; type Your_Float is digits 7 range -1.0E-20 .. +1.0E+20;</syntaxhighlight> then My_Float is an unconstrained subtype whereas Your_Float is constrained. Range checks will apply on assignments to Your_Float but not to My_Float. The predefined types such as Float are unconstrained; it is considered that their notional definition does not include a range. Overflow checks apply to floating point computations only if the attribute Machine_Overflows is true as in Ada 83. By introducing root numeric types, the special Ada 83 rules regarding convertible universal operands are eliminated (only certain simple expressions could be automatically converted in Ada 83). Instead, the distinction between convertible and non-convertible universal operands corresponds directly to the distinction between the universal and specific root numeric types. The operators of the root numeric types return specific root numeric types, and hence their result is not universal (not "implicitly convertible" using Ada 83 terminology). The type resolution rules ensure that these operators accept operands of the universal types, so they may be used on literals and named numbers. There is an important change to the visibility rules concerning a preference for the root types in the case of an ambiguity. This is discussed in 8.4. In order to promote precise use of specific hardware the library package Interfaces defines signed integer types corresponding to the hardware supported types with names such as Integer_32 and Integer_16 plus corresponding modular types (see 3.3.2). This package also predefines similar floating types corresponding to the hardware although no names are prescribed. The description of the real numbers is greatly simplified. The model and safe numbers of Ada 83 have been abandoned because they were not well understood, did not truly provide the portability they sought and obscured the real machine from the specialist. Accordingly the definition of floating point is now in terms of model numbers which roughly correspond to the old safe numbers and are close to the represented numbers. In the case of fixed point the definition is entirely in terms of small and the notion of model numbers no longer applies. To avoid confusion and to improve the correspondence between the real type attributes and the machine attributes, the attributes are completely redefined so that they more closely correspond to the capabilities of the machine. The description of model numbers is moved to the Numerics annex because of its specialist nature. For more details consult Part Three of this rationale. We considered removing floating point and fixed point accuracy constraints from the syntax so that delta and digits would only be specified as part of a real type definition. Indeed, AI-571 concluded that reduced accuracy real subtypes should not be represented with reduced accuracy, making their usefulness in the language questionable. However, they are retained (although considered obsolete) for compatibility because of the different format obtained with Text_IO. === <span id="3-1">3.3.1 Operations</span> === The mixed multiplying operators of the Ada 83 universal numeric types are redefined in Ada 95 in terms of the root numeric types. There were some essentially unnecessary restrictions on the use of literals in fixed point multiplication and division in Ada 83. These operations now take universal_fixed as their operands and return universal_fixed as the result. However the result must be in a context which provides a specific expected type. As a consequence literals may now be used more freely in fixed point operations and a multiplication or division need not be followed by conversion to a specific type if the context supplies such a type. So given two fixed point types Fixed1 and Fixed2, we can now write sequences such as X, Y: Fixed1; Z: Fixed2; ... X := 2.0 * X; X := Y * Z; which were forbidden in Ada 83. Note that multiple operations as in <syntaxhighlight lang="Ada"> X := X * Y / Z;</syntaxhighlight> remain forbidden since the context does not provide a type (and therefore an accuracy and range) for the intermediate result. === <span id="3-2">3.3.2 Modular Types</span> === In Ada 95 the integer types are subdivided into signed integer types and modular types. The signed integer types are those with which we are already familiar from Ada 83 such as Integer and so on. The modular types are new to Ada 95. The modular types are unsigned integer types which exhibit cyclic arithmetic. (They thus correspond to the unsigned types of some other languages such as C.) A strong need has been felt for some form of unsigned integer types in Ada and most compiler vendors have provided their own distinct implementations. This of course has caused an unnecessary lack of portability which the introduction of modular types in Ada 95 will overcome. As an example consider unsigned 8-bit arithmetic (that is byte arithmetic). We can declare <syntaxhighlight lang="Ada"> type Unsigned_Byte is mod 256; -- or mod 2**8;</syntaxhighlight> and then the range of values supported by Unsigned_Byte is 0 .. 255. The normal arithmetic operations apply but all arithmetic is performed modulo 256 and overflow cannot occur. The modulus of a modular type need not be a power of two although it often will be. It might, however, be convenient to use some obscure prime number as the modulus perhaps in the implementation of hash tables. The logical operations and, or, xor and not are also available on modular types; the binary operations naturally treat the values as bit patterns; the not operation subtracts the value from its maximum. No problems arise with mixing these logical operations with arithmetic operations because negative values are not involved. The logical operations will be most useful if the modulus is a power of two; they are well defined for other moduli but there are some surprising effects. For example DeMorgan's theorem that <syntaxhighlight lang="Ada"> not(A and B) = not A or not B</syntaxhighlight> does not hold if the modulus is not a power of two. The package Interfaces defines modular types corresponding to each predefined signed integer type with names such as Unsigned_16 and Unsigned_32. For these modular types (which inevitably have a modulus which is a power of two) a number of shift and rotate operations are also provided. It is an important principle that conversion between numeric types should not change the value (other than rounding). Conversion from modular to signed integer types and vice versa is thus allowed provided the value is in the range of the destination; if it is not then Constraint_Error is raised. Thus suppose we had <syntaxhighlight lang="Ada"> type Signed_Byte is range -128 .. +127; U: Unsigned_Byte := 150; S: Signed_Byte := Signed_Byte(U);</syntaxhighlight> then Constraint_Error will be raised. Unchecked conversion can be used to convert patterns out of range. We could neatly write <syntaxhighlight lang="Ada"> function Convert_Byte is new Unchecked_Conversion(Signed_Byte, Unsigned_Byte); function Convert_Byte is new Unchecked_Conversion(Unsigned_Byte, Signed_Byte);</syntaxhighlight> providing conversions in both directions and then <syntaxhighlight lang="Ada"> S := Convert_Byte(U);</syntaxhighlight> would result in S having the value -106. The modular types form a distinct class of types to the signed integer types. There is thus a distinct form for a generic formal parameter of a modular type namely <syntaxhighlight lang="Ada"> type T is mod <>;</syntaxhighlight> and this cannot be matched by a type such as Integer. Nor indeed can the signed integer form with range <> be matched by a modular type such as Unsigned_32. The new attribute Modulus applies to a modular type and returns its modulus. This is of particular value with generic parameters. === <span id="3-3">3.3.3 Decimal Types</span> === Decimal types are used in specialized commercial applications and are dealt with in depth in the Information Systems annex. However, the basic syntax of decimal types is in the core language. A decimal type is a form of fixed point type. The declaration provides a value of delta as for an ordinary fixed point type (except that in this case it must be a power of 10) and also prescribes the number of significant decimal digits. So we can write <syntaxhighlight lang="Ada"> type Money is delta 0.01 digits 18;</syntaxhighlight> which will cope with values of a typical decimal currency. This allows 2 digits for the cents and 16 for the dollars so that the maximum allowed value is <syntaxhighlight lang="Ada"> 9,999,999,999,999,999.99</syntaxhighlight> The usual operations apply to decimal types as to other fixed point types. Furthermore the Information Systems annex describes a number of special packages for decimal types including conversion to human readable output using picture strings. Much as with modular types there is also a special form for a generic parameter of a decimal type which is <syntaxhighlight lang="Ada"> type T is delta <> digits <>;</syntaxhighlight> This cannot be matched by an ordinary fixed point type and similarly the form with just delta <> cannot be matched by a decimal type such as Money. == <span id="4">3.4 Composite Types</span> == In Ada 95, the concept of composite types is broadened to include task and protected types. This is partly a presentation issue and partly reflects the generalization of the semantics to allow discriminants on task and protected types as well as on records. The terms definite and indefinite subtypes are introduced as explained in II.11 when we discussed the generic parameter mechanism. Recall that a definite subtype is one for which an uninitialized object can be declared such as Integer or a constrained array subtype or a record subtype with discriminants with defaults. An indefinite subtype is an unconstrained array subtype or an unconstrained record, protected or task subtype which does not have defaults for the discriminants, or a class- wide subtype or a subtype with unknown discriminants. As a simple generalization to Ada 83, we have allowed both variables and constants of an indefinite subtype to be declared, so long as an initial value is specified; the object then takes its bounds or discriminants from the initial value. In Ada 83, only initialized constants of such a subtype could be declared. However, the implementation considerations are essentially identical for constants and variables, so eliminating the restriction against variables imposes no extra implementation burden, and simplifies the model. Here is an example of use <syntaxhighlight lang="Ada"> if Answer /= Correct_Answer then declare Image: String := Answer_Enum'Image(Correct_Answer); begin Set_To_Lower_Case(Image); Put_Line("The correct answer is " & Image & '.'); end; end if;</syntaxhighlight> Allowing composite variables without a specified constraint to be declared, if initialized, is particularly important for class-wide types and (formal) private types with discriminant part (<>) since such types have an unknown set of discriminants and thus cannot be constrained. For example, in the case of class-wide types, it would otherwise be hard if not impossible to write the procedure Convert in 4.4.3 since we would not be able to declare the temporary variable Temp. === <span id="4-1">3.4.1 Discriminants</span> === A private type can now be marked as having an unknown number of discriminants thus <syntaxhighlight lang="Ada"> type T(<>) is private;</syntaxhighlight> The main impact of this is that the partial view does not allow uninitialized objects to be declared. If the partial view is also limited then objects cannot be declared at all (since they cannot be initialized). The gives the writer of an abstraction rather more control over the use of the abstraction. As we have already noted, discriminants are also allowed on task and protected types in Ada 95. (An early draft of Ada 9X also permitted discriminants on arrays and discriminants to be of any nonlimited type. This was, however, felt to be too much of a burden for existing implementations.) Discriminants are the primary means of parameterizing a type in Ada, and therefore we have tried to make them as general as possible within transition constraints. Task and protected types in particular benefit from discriminants acting as more general type parameters. In Ada 83, an instance of a task type had to go through an initial rendezvous to get parameters to control its execution. In Ada 95, the parameters may be supplied as discriminant values at the task object declaration, eliminating the need for the extra rendezvous. Variables introduced in the declarative part of the task body can also depend on the task type discriminants, as can the expression defining the initial priority of the task via a Priority pragma. See 9.6 for some detailed examples. In addition to allowing discrete types as discriminants as in Ada 83, we now also permit discriminants to be of an access type. There are two quite distinct situations. A discriminant can be of a named access type or it can be an access discriminant in which case the type is anonymous. Thus we can declare <syntaxhighlight lang="Ada"> type R1(D: access T) is ... type AT is access T; type R2(D: AT) is ...</syntaxhighlight> and then the discriminant of R1 is an access discriminant whereas the discriminant of R2 is a discriminant of a named access type. A similar nomenclature applies to subprogram parameters which can be access parameters (without a type name) or simply parameters of a named access type (which was allowed in Ada 83). Access discriminants provide several important capabilities. Because they impose minimal accessibility checking restrictions, an access discriminant may be initialized to refer to an enclosing object, or to refer to another object of at least the same lifetime as the object containing the discriminant. Access discriminants can only be applied to limited types. Note also that a task and a protected object can have access discriminants. When an object might be on multiple linked lists, it is typical that one link points to the next link. However, it is also essential to be able to gain access to the object enclosing the link as well. With access discriminants, this reference from a component that is a link on a chain, to the enclosing object, can be initialized as part of the default initialization of the link component. This is discussed further in 4.6.3. For a fuller discussion on how access discriminants avoid accessibility problems see 3.7.1. Further examples of the use of access discriminants will be found in 7.4 and 9.6. Finally, a derived type may specify a new set of discriminants. For untagged types, these new discriminants are not considered an extension of the original type, but rather act as renamings or constraints on the original discriminants. As such, these discriminants must be used to specify the value of one of the original discriminants of the parent type. The new discriminant is tightly linked to the parent's discriminant it specifies, since on conversion from the parent type, the new discriminant takes its value from that discriminant (presuming Constraint_Error is not raised). The implementation model is that the new discriminants occupy the space of the old. The new type could actually have less discriminants than the old. The following are possible <syntaxhighlight lang="Ada"> type S1(I: Integer) is ...; type S2(I: Integer; J: Integer) is ...; type T1(N: Integer) is new S1(N); type T2(N: Integer) is new S2(N, 37); type T3(N: Integer) is new S2(N, N);</syntaxhighlight> The last case is interesting because the new discriminant is mapped onto both the old ones. A conversion from type S2 to T3 checks that both discriminants of the S2 value are the same. A practical use of new discriminants for non-tagged types is so that we can make use of an existing type for the full type corresponding to a private type with discriminants. <syntaxhighlight lang="Ada"> type T(D: DT) is private; private type T(D: DT) is new S(D);</syntaxhighlight> In the case of a tagged type, we can either inherit all the discriminants or provide a completely new set. In the latter case the parent must be constrained and the new discriminants can (but need not) be used to supply the constraints. Thus a type extension can have more discriminants than its parent, which is not true in the untagged case. == <span id="5">3.5 Array Types</span> == A very minor change is that an index specification of an anonymous array type in an initialized declaration can also take the unconstrained form <syntaxhighlight lang="Ada"> V: array (Integer range <>) of Float := (3 .. 5 => 1.0, 6 | 7 => 2.0);</syntaxhighlight> in which case the bounds are deduced from the initial expression. === <span id="5-1">3.5.1 Array Aggregates</span> === Ada 83 had a rule that determined where a named array aggregate with an others choice was permitted; see [RM83 4.3.2(6)]. There were a related set of rules that governed where implicit array subtype conversion ("sliding") was permitted for an array value; see [RM83 3.2.1(16) and 5.2.1(1)]. These rules were constructed to ensure that named array aggregates with others and array sliding were not both permitted in the same context. However, the lack of array sliding in certain contexts could result in the unanticipated raising of Constraint_Error because the bounds did not match the applicable constraint. For Ada 95, we have relaxed the restrictions on both array sliding and named array aggregates with others, so that both are permitted in all contexts where an array aggregate with just an others choice was legal in Ada 83. This corresponds to all situations where an expression of the array type was permitted, and there was an applicable index constraint; see [RM83 4.3.2(4-8)]. This ensures that sliding takes place as necessary to avoid Constraint_Error, and simplifies the rules on array aggregates with an others choice. The original Ada 83 restrictions were related to the possible ambiguity between determining the bounds of an aggregate and sliding. In Ada 95, this ambiguity is resolved by stipulating that sliding never takes place on an array aggregate with an others choice. The applicable index constraint determines the bounds of the aggregate. As an example consider <syntaxhighlight lang="Ada"> type Vector is array (Integer range <>) of Float; V: Vector(1 .. 5) := (3 .. 5 => 1.0, 6 | 7 => 2.0);</syntaxhighlight> which shows a named aggregate being assigned to V. The bounds of the named aggregate are 3 and 7 and the assignment causes the aggregate to slide with the net result that the components V(1) .. V(3) have the value 1.0 and V(4) and V(5) have the value 2.0. On the other hand writing <syntaxhighlight lang="Ada"> V := (3 .. 5 => 1.0, others => 2.0);</syntaxhighlight> has a rather different effect. It was not allowed in Ada 83 but in Ada 95 has the effect of setting V(3) .. V(5) to 1.0 and V(1) and V(2) to 2.0. The point is that the bounds of the aggregate are taken from the context and there is no sliding. Aggregates with others never slide. Similarly no sliding occurs in <syntaxhighlight lang="Ada"> V := (1.0, 1.0, 1.0, others => 2.0);</syntaxhighlight> and this results in setting V(1) .. V(3) to 1.0 and V(4) and V(5) to 2.0. === <span id="5-2">3.5.2 Concatenation</span> === The rules for concatenate (we now use this more familiar term rather than catenate) are changed so that it works usefully in the case of arrays with a constrained first subtype. In Ada 83 the following raised Constraint_Error, while in Ada 95 it produces the desired result <syntaxhighlight lang="Ada"> X: array (1..10) of Integer; begin X := X(6..10) & X(1..5);</syntaxhighlight> In Ada 83, the bounds of the result of the concatenate were 6 .. 15, which caused Constraint_Error to be raised since 15 is greater than the upper bound of the index subtype. In Ada 95, the lower bound of the result (in this constrained case) is the lower bound of the index subtype so the bounds of the result are 1 .. 10, as required. == <span id="6">3.6 Record Types</span> == A record type may be specified as tagged or limited (or both) in its definition. This makes record types consistent with private types, and allows a tagged record type to be declared limited even if none of its components are limited. This is important because only limited types can be extended with components that are limited. A derived type is a record extension if it includes a record extension part, which has the same syntax as a normal record type definition preceded by the reserved word with. For example <syntaxhighlight lang="Ada"> type Labelled_Window(Length : Natural) is new Window with record Label: String(1..Length); end record;</syntaxhighlight> Record extension is the fundamental type extension (type inheritance) mechanism in Ada 95. A private extension must be defined in terms of a record extension. The new discriminants in a discriminant extension are normally used to control the new components defined in the record extension part (as illustrated in the above example). Record extension is a natural evolution of the Ada 83 concept of derived types. From an implementation perspective, it is relatively straightforward, since the new components may all be simply added at the end of the record, after the components inherited from the parent type. We considered having other kinds of type extension, including enumeration type extension, task type extension, and protected type extension. However, none of these seemed clearly as useful as record extension, and all introduced additional implementation complexities. In any case, the automatic assignment of tags to type extensions lessens the need for enumeration types, and the added flexibility associated with access to subprogram and dispatching operations makes it less critical to allow task types to be extended. Type extension of protected objects was another interesting possibility. However, certain implementation approaches do not easily support extension of the set of protected operations, or the changing of the barrier expressions. With some regret therefore it was decided that the benefit of extending protected types was not worth the considerable implementation burden. This is an obvious topic for review at the next revision of Ada. Type extension is only permitted if the parent type is tagged. Originally we considered allowing any record or private type to be extended, but this introduced additional complexity, particularly inside generics. Furthermore, extending an untagged type breaks the general model that a class-wide type can faithfully represent any value in the class. An object of an untagged class-wide type would not have any provision for holding a value of a type extension, since it would lack a run-time type tag to describe the value. === <span id="6-1">3.6.1 Record Aggregates</span> === Record aggregates are only permitted for a type extension if both the extension part and the parent part are fully visible. This corresponds to the principle that if part of a type is private, then it must be assumed to have an unknown set of components in that part. In other words we can only use an aggregate where we can view all the components. However, extension aggregates can be used provided only that the components in the extension part are visible; we do not need a full view of the type of the ancestor expression. Typically we can provide an expression for the ancestor part. Thus suppose we have <syntaxhighlight lang="Ada"> type T is tagged private; ... T_Obj: T := ...; type NT is new T with record I, J: Integer; end record;</syntaxhighlight> then we can write an extension aggregate such as <syntaxhighlight lang="Ada"> (T_Obj with I => 10, J => 20)</syntaxhighlight> A variation is that we can also simply give the subtype name as the ancestor part thus <syntaxhighlight lang="Ada"> (T with I => 10, J => 20)</syntaxhighlight> which is essentially equivalent to declaring a temporary default initialized object of the type and then using it as the ancestor expression (this includes calling Initialize in the case of a controlled type, see 7.4). This is allowed even if the ancestor type is abstract and thereby permits the creation of aggregates for types derived from abstract types. === <span id="6-2">3.6.2 Abstract Types and Subprograms</span> === As we have already discussed in II.3, a tagged type may be declared as abstract by the appearance of abstract in its declaration. A subprogram which is a primitive operation of an abstract tagged type may be specified as abstract. An abstract subprogram has no body, and cannot be called directly or indirectly. A dispatching call will always call some subprogram body that overrides the abstract one because it is not possible to create an object of an abstract type. If a type is derived from an abstract type and not declared as abstract then any inherited abstract subprograms must be overridden with proper subprograms. Note, of course, that an abstract type need not have any abstract subprograms. The interaction between abstract types and private types is interesting. It will usually be the case that both views are abstract or not abstract. However, it is possible for a partial view to be abstract and the full view not to be abstract thus <syntaxhighlight lang="Ada"> package P is type T is abstract tagged private; private type T is tagged ...; end P;</syntaxhighlight> In this case, objects of the type can only be declared for the full view and abstract primitive operations cannot be declared at all. This is because an abstract operation in the visible part would still apply in the private part and would thus be abstract for the nonabstract view. It is of course not possible for the full view to be abstract and the partial view not to be abstract. This is quite similar to the rules for limitedness. A partial view can be limited and a full view not limited but not vice versa; the key point is that the partial view cannot promise more properties than the full view (the truth) actually has. Of more interest is private extension where again the partial view could be declared abstract and the full view not abstract. An inherited abstract subprogram would need to be overridden. If this were done in the private part then the partial view of the subprogram would still be abstract although the full view would be of the overriding subprogram and thus not abstract. Thus <syntaxhighlight lang="Ada"> package P is type T is abstract tagged null record; procedure Op(X: T) is abstract; end P; with P; package NP is type NT is abstract new P.T with private; private type NT is new T with ...; procedure Op(X: T); -- overrides end NP;</syntaxhighlight> The overriding is essential since otherwise we might dispatch to an abstract operation. Another point is that an abstract type is not allowed to have an invisible abstract operation since otherwise it could not be overridden. The following difficulty is thus avoided. <syntaxhighlight lang="Ada"> package P is type T is abstract ...; procedure Nasty(X: T'Class); private procedure Op(X: T) is abstract; -- illegal end P; package body P is procedure Nasty(X: T'Class) is begin Op(X); end Nasty; end P; with P; package Q is type NT is new P.T with ...; -- not abstract -- cannot see Op in order to override it end Q;</syntaxhighlight> The problem is that we must override Op since by declaring an object of type NT we can then dispatch to Op by calling the procedure Nasty. The overall motivation for the rules is to ensure that it is never possible to dispatch to a non-existent subprogram body. A rather different problem arises when we extend a type which is not abstract but which has a function with a controlling result. The old function cannot be used as the inherited version because it cannot provide values for the type extension when returning the result (parameters are not a problem because they only involve conversion towards the root). As a consequence the type must be declared as abstract unless we provide a new function. A related restriction is that a function with a controlling result cannot be declared as a private operation since otherwise a similar difficulty to that discussed above would arise on type extension. If extension were performed using the partial view then the function would become abstract for the extended type and yet, being private, could not be overridden. Observe also that since we do not require every abstract subprogram to be explicit, it is possible for a generic package specification to define an abstract record extension of a formal tagged type without knowing exactly which functions with controlling results exist for the actual type. Finally, note that it is possible to have an abstract operation of a nontagged type. This is fairly useless since dispatching is not possible and static calls are illegal. However, it would be harder to formulate the rules to avoid this largely because an operation can be primitive of both a tagged and nontagged type (although not of two tagged types, see 4.5). == <span id="7">3.7 Access Types</span> == As we have already seen in II.5 and II.6, access types in Ada 95 have been generalized so that they may be used to designate subprograms and also declared objects. A new attribute designator, Access, has been defined for creating an access value designating a subprogram or object specified in the prefix. For example: <syntaxhighlight lang="Ada"> A := Object'Access; -- point to a declared object B := Subprogram'Access; -- point to a subprogram</syntaxhighlight> Full type checking is performed as part of interpreting the Access attribute. An additional accessibility check is performed to ensure that the lifetime of the designated subprogram or object will not end before that of the access type, eliminating the possibility of dangling references. Although these two extensions to access types share some common terminology and concepts the details are rather different and so we will now discuss them separately in the following sections. === <span id="7-1">3.7.1 Access to General Objects</span> === Access types that may designate declared objects are called general access types, as distinguished from pool-specific access types, which correspond to those which were provided by Ada 83. There are two steps to the use of general access types * Objects that are to be designated by access values must be aliased. This can be done by using the reserved word aliased in their declaration. This serves various purposes. It documents the fact that an object is to be designated by an access value. It forces the object to be properly aligned in memory and informs the compiler that the representation of the object should correspond to that used for objects created by an allocator. In addition, the optimizer is informed that this object is likely to be accessible via one or more access values, and therefore its value might change as a result of an update via an access value. * The attributes Access and Unchecked_Access, when applied to an object, return an access value that designates the object. Unless the subtype is tagged or has unconstrained discriminants, the subtype of the object must statically match the designated subtype of the access type. The access values which are formed by the Access attribute must obey certain accessibility restrictions, which are generally checked at compile time (at runtime in the case of access parameters). They cannot be used to create access values of a type whose lifetime is longer than the lifetime of the designated object; this prevents an access value from being stored in a global and then leaving the region where the designated object is declared. The access values that are formed by the Unchecked_Access attribute are not subject to such restrictions. It is the responsibility of the programmer who uses such unchecked access values to avoid dangling references. General access types have the reserved word all or constant in their definition. We originally considered allowing any (object) access type to designate a declared object (as opposed to an allocated object), but this would have forced all access types to be represented as full addresses. By distinguishing general access types from pool-specific access types, we preserve the possibility of optimizing the representation of a pool-specific access type, by taking advantage of its limited storage-pool size. A value of a general access type declared with the reserved word all can only designate variables (not constants), and may be used to read and update the designated object. If the reserved word constant is used, then access values may designate constants, as well as variables. An object designated by an access-to-constant value may not be updated via the access value. An allocator for an access-to-constant type requires an initial value and might generally reserve storage in a read-only part of the address space. There are two important cases where a view is deemed to be aliased (and thus Access can be applied) even though the word aliased does not appear. One is that a parameter of a tagged type is considered to be aliased (see 6.1.2) and the other is where an inner component refers to the current instance of an outer limited type (see 4.6.3). There is a restriction concerning discriminated records which ensures that we cannot apply the Access attribute to a component that might disappear. This is similar to the rule for renaming which prevents the renaming of a component of an unconstrained variable whose existence depends upon a discriminant. Indirect access to declared objects is useful for avoiding dynamic allocation, while still allowing objects to be inserted into linked data structures. This is particularly useful for systems requiring link-time elaboration of large tables, which may use levels of indirection in their representation. Such access types are also convenient for returning a reference to a large global object from a function, allowing the object to be updated through the returned reference if desired. Finally, rather than relying on allocators, it is sometimes appropriate to use a statically allocated array of objects, managed explicitly by the application. However, it may still be more convenient to reference components of the array using access values. By declaring the array components as aliased, the Access attribute may be used to produce an access value designating a particular component. An interesting example is provided by the following which illustrates the static creation of ragged arrays <syntaxhighlight lang="Ada"> package Message_Services is type Message_Code_Type is range 0..100; subtype Message is String; function Get_Message(Message_Code: Message_Code_Type) return Message; pragma Inline(Get_Message); end Message_Services; package body Message_Services is type Message_Handle is access constant Message; Message_0: aliased constant Message := "OK"; Message_1: aliased constant Message := "Up"; Message_2: aliased constant Message := "Shutdown"; Message_3: aliased constant Message := "Shutup"; ... Message_Table: array (Message_Code_Type) of Message_Handle := (0 => Message_0'Access, 1 => Message_1'Access, 2 => Message_2'Access, 3 => Message_3'Access, -- etc. ); function Get_Message(Message_Code: Message_Code_Type) return Message is begin return Message_Table(Message_Code).all; end Get_Message; end Message_Services;</syntaxhighlight> This example is based on Revision Request 018 and declares a static ragged array. The elements of the array point to strings, the lengths of which may differ. The access values are generated by the Access attribute; no dynamic allocation is needed to create the values. Access types are used extensively in object-oriented applications. To enable the use of access types with the run-time dispatching provided for the primitive operations of tagged types, Ada 95 includes a new kind of in parameter, called an access parameter. We can thus write <syntaxhighlight lang="Ada"> procedure P(A: access T);</syntaxhighlight> This is to be distinguished from a parameter of a named access type which already existed in Ada 83. A similar distinction arises with access discriminants as we saw in 3.4.1. An access parameter is matched by an actual operand of any access type with the same designated type. Furthermore, if a subprogram has an access parameter with designated type T, and the subprogram is defined in the same package specification as the type T, then the subprogram is a primitive operation of T, and dispatches on the tag of the object designated by the access parameter. Inside the subprogram, an access parameter is of an anonymous general access type, and must either be dereferenced or explicitly converted on each use, or passed to another operation as an access parameter. An important property of access parameters is that they can never have a null value. It is not permitted to pass null as an actual parameter (this is checked on the call) and of course being of an anonymous type another such object cannot be declared inside the subprogram. As a consequence within the subprogram there is no need to check for a null value of the type (neither in the program text nor in the compiled code). Note also that since other objects of the type cannot be declared, assignment and equality do not apply to access parameters. For a tagged type T and an aliased object X of type T, X'Access and new T are overloaded on all access to T, on all access to T'Class, and on all other access to class-wide types that cover T. These overloadings on access to class-wide types allow allocators and the Access attribute to be used conveniently when calling class-wide operations, or building heterogeneous linked data structures. Access parameters and access discriminants are important with respect to accessibility which we will now discuss in more detail. The accessibility rules ensure that a dangling reference can never arise; in general this is determined statically. Suppose we have a library package P containing a globally declared access type and a global variable <syntaxhighlight lang="Ada"> package P is type T is ...; type T_Ptr is access all T; Global: T_Ptr; end P;</syntaxhighlight> then we must ensure that the variable Global is never assigned an access to a variable that is local. So consider <syntaxhighlight lang="Ada"> procedure Q is X: aliased T; Local: T_Ptr := X'Access; -- illegal begin Global := X'Access; -- illegal ... Global := Local; ... end Q;</syntaxhighlight> in which we have declared a local variable X and a local access variable. The assignment of X'Access to Global is clearly illegal since on leaving the procedure Q, this would result in Global referring to a non-existent variable. However, because we can freely assign access values, we must not assign X'Access to Local either since although that would be safe in the short term, nevertheless we could later assign Local to Global as shown. Since we do not wish to impose accessibility checks at run-time on normal access assignment (this would be a heavy burden), we have to impose the restriction that the Access attribute can only be applied to objects with at least the lifetime of the access type. The rules that ensure this are phrased in terms of accessibility levels and the basic rule is that the access attribute can only be applied to an object at a level which is not deeper than that of the access type; this is, of course, known at compile time and so this basic accessibility rule is static. This may seem rather surprising since the concept of lifetime is dynamic and so one might expect the rules to be dynamic. However, it can be shown that in the case of named access types, the static rule is precisely equivalent to the intuitive dynamic rule. The reason for this is that the access attribute can only be applied at places where both the object and the access type are in scope; see [Barnes 95] for a detailed analysis. As discussed below, the situation is quite different for access parameters where the type has no name and the checks then have to be dynamic. (In the case of generic bodies, the rule is also dynamic as discussed in 12.3.) Similar problems arise with discriminants and parameters of named access types. Thus we could not declare a local record with a component of the type T_Ptr. However, access discriminants and access parameters behave differently. * The anonymous type is essentially declared inside the object or subprogram itself. * It is not possible to have other components or objects of the same type (since it is anonymous) and they are treated as constants. * Records with access discriminants have to be limited. The net result is that the accessibility problems we encountered above do not arise. Revisiting the above example we can write <syntaxhighlight lang="Ada"> package P is type T is ...; type T_Ptr is access all T; type Rec(D: access T) is limited record ... end record; Global: T_Ptr; Global_Rec: Rec(...); end P;</syntaxhighlight> where we have added the record type Rec with an access discriminant D plus a global record variable of that type. Now consider <syntaxhighlight lang="Ada"> procedure Q is X: aliased T; Local_Rec: Rec(D => X'Access); -- OK begin Global := Local_Rec.D; -- illegal, type mismatch Global := T_Ptr(Local_Rec.D); -- illegal, accessibility check Global_Rec := Local_Rec; -- illegal, assignment limited type ... end Q;</syntaxhighlight> in which we have declared a local record variable with its access discriminant initialized to access the local variable X. This is now legal and the various attempts to assign the reference to X to a more global variable or component are thwarted for the various reasons shown. The straight assignment of the discriminant fails because of a type mismatch. The attempt to circumvent this problem by converting the access type also fails because of an accessibility check on conversions between access types [RM95 4.6]. And the attempt to assign the whole record fails because it is limited. Access parameters are particularly important since they are the one case where an accessibility check is dynamic (other than in generic bodies). An access parameter carries with it an indication of the accessibility level of the actual parameter. Dynamic checks can then be made when necessary as for example when converting to an external named access type. Consider <syntaxhighlight lang="Ada"> procedure Main is type T is ...; type A is access all T; Ptr: A := null; procedure P(XP: access T) is begin Ptr := A(XP); -- conversion with dynamic check end P; X: aliased T; begin P(X'Access); end Main;</syntaxhighlight> The conversion compares the accessibility level of the object X passed as parameter with that of the destination type A; they are both the same and so the check passes. Observe that if the destination type A were declared inside P then the check can be (and is) performed statically. So not all conversions of access parameters require dynamic checks. Another possibility is where one access parameter is passed on as an actual parameter to another access parameter. There are a number of different situations that can arise acording to the relative positions of the subprograms concerned; the various possibilities are analysed in detail in [Barnes 95] where it is shown that the implementation technique given in [AARM 3.10.2(22)] precisely meets the requirements of the rules. The rules themselves are in [RM95 3.10.2 and 4.6]. Without access parameters, the manipulation of access discriminants would be difficult. Given <syntaxhighlight lang="Ada"> procedure P(A: access T);</syntaxhighlight> then we can satisfactorily make calls such as <syntaxhighlight lang="Ada"> P(Local_Rec.D);</syntaxhighlight> in order to manipulate the data referenced by the discriminant. On the other hand declaring <syntaxhighlight lang="Ada"> procedure P(A: T_Ptr);</syntaxhighlight> would be useless for the manipulation of the discriminant because the necessary type conversion on the call would inevitably be illegal for reasons of accessibility mentioned above. As a first example of the use of access discriminants we will consider the case of an iterator over a set. This is typical of a situation where we want a reference from one object to another. The iterator contains a means of referring to the set in question and the element within it to be operated upon next. Consider <syntaxhighlight lang="Ada"> generic type Element is private; package Sets is type Set is limited private; ... -- various set operations type Iterator(S: access Set) is limited private; procedure Start(I: Iterator); function Done(I: Iterator) return Boolean; procedure Next(I: in out Iterator); function Get_Element(I: Iterator) return Element; procedure Set_Element(I: in out Iterator; E: Element); private type Node; type Ptr is access Node; type Node is record E: Element; Next: Ptr; end record; type Set is new Ptr; -- implement as singly-linked list type Iterator(S: access Set) is record This: Ptr; end record; end Sets; package body Sets is ... -- bodies of the various set operations procedure Start(I: in out Iterator) is begin I.This := Ptr(I.S.all); end Start; function Done(I: Iterator) return Boolean is begin return I.This = null; end Done; procedure Next(I: in out Iterator) is begin I.This := I.This.Next; end Next; function Get_Element(I: Iterator) return Element is begin return I.This.E; end Get_Element; procedure Set_Element(I: in out Iterator; E: Element) is begin I.This.E := E; end Set_Element; end Sets;</syntaxhighlight> The subprograms Start, Next and Done enable us to iterate over the elements of the set with the component This of the iterator object accessing the current element; the subprograms Get_Element and Set_Element provide access to the current element. The iterator could then be used to perform any operation on the values of the elements of the set. As a trivial example the following child function Sets.Count simply counts the number of elements in the set. (Incidentally note that the child has to be generic because its parent is generic.) <syntaxhighlight lang="Ada"> generic function Sets.Count(S: access Set) return Natural; -- Return the number of elements of S. function Sets.Count(S: access Set) return Natural is I: Iterator(S); Result: Natural := 0; begin Start(I); while not Done(I) loop Result := Result + 1; Next(I); end loop; return Result; end Sets.Count; In the more general case the loop might be Start(I); while not Done(I) loop declare E: Element := Get_Element(I); -- get old value begin ... -- do something with it Set_Element(I, E); -- put new value back Next(I); end; end loop;</syntaxhighlight> Note that if Iterator.S were a normal component rather than an access discriminant then we would not be able to initialize it at its point of declaration and moreover we could not make it point to Sets.Count.S without using Unchecked_Access. Finally note that the procedure Start could be eliminated by declaring the type Iterator as <syntaxhighlight lang="Ada"> type Iterator(S: access Set) is record This: Ptr := Ptr(S.all); end record;</syntaxhighlight> and this would have the advantage of preventing errors caused by forgetting to call Start. === <span id="7-2">3.7.2 Access to Subprograms</span> === Ada 95 provides access-to-subprogram types. A value of such a type can designate any subprogram matching the profile in the type declaration, whose lifetime does not end before that of the access type. By providing access-to-subprogram types, Ada 95 provides efficient means to * dynamically select and invoke a subprogram with appropriate arguments, * store references to subprograms in data structures, * parameterize subprograms with other subprograms (at run-time). Access-to-subprogram values are created by the Access attribute. Compile-time accessibility rules ensure that a subprogram designated by an access value cannot be called after its enclosing scope has exited. This ensures that up-level references from within the subprogram will be meaningful when the subprogram is ultimately called via the access value. It also allows implementations to create and dereference these access-to- subprogram values very efficiently, since they can be a single address, or an address plus a "static link". For Subprogram'Access, the designated subprogram must have formal parameter and result subtypes and a calling convention that statically match those of the access type. This allows the compiler to emit the correct constraint checks, and use the correct parameter passing conventions when calling via an access-to-subprogram value, without knowing statically which subprogram is being called. We call this subtype conformance. Overload resolution of the Access attribute applied to an overloaded subprogram name represents a new situation in Ada. In Ada 83, the prefix of an attribute was required to be resolvable without context. However, for the Access attribute to be useful on overloaded subprograms, it was necessary to allow the Access attribute to use context to resolve the prefix. Therefore, if the prefix of Access is overloaded, then context is used to determine the specific access-to-subprogram type, and then the parameter and result type profile associated with that access type is used to resolve the prefix. Indirect access to a subprogram is extremely useful for table-driven programming, using, for example, a state machine model. It is also useful for installing call-backs in a separate subsystem (like the X window system). Finally, it often provides an alternative to generic instantiation, allowing a non-generic parameter to be a pointer to a subprogram, such as for applying an operation to every element of a list, or integrating a function using a numerical integration algorithm. A number of examples of the use of access to subprogram types will be found in II.5. However a very important use is to provide much better ways of interfacing to programs written in other languages. This is done in conjunction with the pragma Import (essentially replacing Interface) and new pragmas Export and Convention. For details see Part Three. It should be noted that there is no equivalent to access discriminants or access parameters for access to subprogram types. Apart from any aesthetic consideration of writing such an in situ definition, the key reason concerns the implementation problems associated with keeping track of the environment of such a "subprogram value". As a consequence we cannot, for example, use the access to a local procedure as a parameter of a more globally declared procedure. Such values would in any case not be safely assignable into a global. The accessibility restrictions mean that access to subprogram values do not provide a mechanism to solve the general iterator problem where the essence is usually to apply some inner procedure over every element of a set with the inner procedure having access to more global variables. One alternative approach is to use access discriminants as discussed in 3.7.1; another, perhaps better, approach is to use type extension as illustrated in 4.4.4. Generic formal subprograms remain the most general means of parameterizing an algorithm by an arbitrary externally specified subprogram. Moreover they are often necessary anyway. For example, consider a typical mathematical problem such as integration briefly mentioned in II.5. In practice the integration function would inevitably be generic with respect to the floating point type. So a more realistic specification would be <syntaxhighlight lang="Ada"> generic type Float_Type is digits <>; package Generic_Integration is type Integrand is access function(X: Float_Type) return Float_Type; function Integrate(F: Integrand; From, To: Float_Type; Accuracy: Float_Type := 10.0*Float_Type'Model_Epsilon) return Float_Type; end Generic_Integration;</syntaxhighlight> Suppose now that we wish to integrate a function whose value depends upon non-local variables and that therefore has to be declared at an inner level. All that has to be done is to instantiate the generic at the same inner level and then no accessibility problems arise. So <syntaxhighlight lang="Ada"> with Generic_Integration; procedure Try_Estimate(External_Data: Data_Type; Lower, Upper: Float; Answer: out Float) is -- external data set by other means function Residue(X: Float) return Float is Result: Float; begin -- compute function value dependent upon external data return Result; end Residue; package Float_Integration is new Generic_Integration(Float_Type => Float); use Float_Integration; begin ... Answer := Integrate(Residue'Access, Lower, Upper); end Try_Estimate;</syntaxhighlight> The key point is that the instantiated access type Integrand is at the same level as the local function Residue and therefore the Access attribute can be applied. This technique can of course be used even when there are no generic parameters. == <span id="8">3.8 Type Conversion</span> == Because Ada 95 supports type extension and has more flexible access types, the possibilities and needs for type conversion become much more extensive than in Ada 83. In Ada 83, type conversion involved only a possible representation change and a possible constraint check. If the conversion succeeded, no components were lost or added, and the conversion was always reversible. There were only three kinds of conversions, between derived types, between numeric types and between array types. Note in particular that there were no conversions between access types (except for the case where the type itself was derived from another access type). Conversions in Ada 95 are classified as view conversions and value conversions. The general idea is that a view conversion doesn't really perform a conversion but just provides a different view of the object. View conversions arise in two situations, where the operand is an object of a tagged type, and where the conversion is used as an actual parameter corresponding to a formal in out or out parameter. Other conversions are value conversions. Another way of looking at the difference is that view conversions are for situations where an object is being converted whereas a value conversion can apply to an expression. The use of a view conversion as a parameter existed in Ada 83; for example where a conversion of an object of say type Integer was used as an actual parameter corresponding to a formal in out parameter of type Float. Such view conversions cause a real change of representation in both directions and indeed view conversions of nontagged types are always reversible. View conversions of tagged types are different; no change of representation ever occurs; we merely get a different view seeing different properties of the same object. And view conversions of tagged types are generally not reversible because of the possibility of type extension. For tagged specific types there is an important rule that conversion can only be towards the root type. Conversion of a specific type away from the root type is not possible because additional components will generally be required. Such additional components can be provided by an extension aggregate. As we saw in the example of type Object and its extension Circle from II.1 we can write <syntaxhighlight lang="Ada"> Object(C)</syntaxhighlight> as an acceptable conversion towards the root but must write <syntaxhighlight lang="Ada"> C: Circle; O: Object; ... C := (O with Radius => 12.0);</syntaxhighlight> to perform the operation away from the root. (In an early draft of Ada 9X a form of conversion was used for such an extension but it was felt to be confusing and overcomplicate the rules for conversion; it also had generic contract problems.) Note that we have used the named notation for the additional components (in this case only one). Another important point is that the ancestor expression (before with) need not be the immediate ancestor of the target type but can be any ancestor. See also 3.6.1. The same principle applies in the case of conversions from a tagged class-wide type to a specific type; conversion is only allowed if the tag of the current value of the class-wide object is such that conversion is not away from the root. This is not known statically and so a tag check verifies that the type identified by the tag of the operand matches that of the target type, or is a derivative of it. Constraint_Error is raised if this check fails. Conversion from a specific type to a class wide type is always allowed implicitly (that is no conversion need be explicitly stated); of course the specific type must be in the class concerned. We could not convert a Low_Alert to Medium_Alert'Class; any attempt would be detected at compile time. Conversion from one class-wide type to another is also possible. The classes obviously have to have a common ancestor and it may be necessary to check the tag at runtime. If the source class is the same as or a subclass of the target class then clearly no check is necessary. We will consider the conversion of tagged types in more detail when we discuss redispatching in the next chapter (see 4.5). Conversion between access types was not possible in Ada 83 (unless one was derived from another); each access type was considered unrelated (even if the accessed types were the same). Another issue was that access values need not necessarily be held as addresses but could be indexes into the relevant pool. However, the introduction of general access types and access parameters means that the conversion between access types is very necessary. Conversion from pool specific types to general access types and between general access types is therefore permitted provided the accessed types are the same or are suitably related. But we cannot convert from an access to constant type to an access to variable type because we might thereby obtain write access to a constant. In general a conversion may involve constraint and accessibility checks. Conversions are particularly useful for programming with access types designating tagged types. Essentially, an access type conversion is permitted if access values of the target type may "safely" designate the object designated by the operand access value; or in other words providing the new view is acceptable for the designated object. Thus a conversion from an access to class-wide type to an access to specific type will require a dynamic check to ensure that the designated object is of the specific type (or derived from it). Generally, conversions between access types to tagged types follow exactly the same rules and involve the same checks as conversions between the designated types. Both conversions effectively give new views of the object concerned. Conversions between access types (in general) may require accessibility checks to ensure that the new value could not give rise to a dangling reference. It is possible to convert between any general access types (including anonymous access types used as access parameters and discriminants) provided the designated types are the same. An example of access type conversion where an accessibility check is required occurs in 3.7.1. Conversions between access types may also require constraint checks to ensure that any constraints on the accessed subtype are satisfied. As explained above we have generalized implicit subtype conversions on arrays ("sliding") to apply in more circumstances. These new rules should minimize the times when an unexpected Constraint_Error arises when the length of the array value is appropriate, but the upper and lower bounds do not match the applicable index constraint. In effect, we are treating the bounds as properties of array objects rather than of array values. Array values have a length for each dimension, but the bounds may be freely readjusted to fit the context. Note also that array conversions require that the component subtypes statically match in Ada 95 whereas the check was dynamic in Ada 83. This is a minor incompatibility but avoids unnecessary runtime checks. == <span id="9">3.9 Staticness</span> == In Ada 83, static expressions were limited to predefined operators applied to static operands, to static attributes or to static qualified expressions. For Ada 95, we have extended the rules so that a static expression can also include items such as membership tests and attributes with static constituents. See [RM95 4.9] for details. By allowing more constructs in static expressions, the programmer has more freedom in contexts where static values are required. In addition, we ensure more uniformity in what expressions are evaluated at compile- time. Some Ada 83 compilers were aggressive in evaluating compile-time known expressions, while others only evaluated those expressions that were "officially" static. By shifting the definition of static to more closely correspond to compile-time-known, uniformity of efficiency is enhanced. In addition to generalizing the rules for static expressions, we also require that all static evaluation be performed exactly. Although many compilers already perform all compile-time arithmetic with arbitrary precision, this rule will provide more predictability for the value of a static expression. Note that the exact static value must still be converted to a machine manipulable representation when combined in an expression with non-static values. Static strings are also introduced for use as parameters of pragmas. There are no other contexts in the standard which require static strings. Staticness is also relevant in other situations such as subtype conformance (see 6.2). This kind of conformance is required between the parameter and result specifications given in an access to subprogram type definition, and the specification of a potential designated subprogram. Subtype conformance is based on a static match between the subtypes of corresponding parameters and the result, if any. This is necessary because when calling a subprogram via an access to subprogram type, the actual parameters must be prepared and the call must be performed given only the address (and perhaps a static link) for the target subprogram. The way parameters are passed, the constraints that need to be checked, the way the result is returned, and any other calling conventions must be determined completely knowing only the definition of the access-to- subprogram type. A static subtype match is required for access-to-subprogram matching so that no additional checks on the actual parameters are required when calling indirectly through an access to subprogram type. There is a general philosophy that static matching is required when two subtypes are involved whereas when only one subtype and a value are involved (as in assignment) then dynamic matching (possibly resulting in Constraint_Error) is applied as it was in Ada 83. Thus static matching is also required in matching the component subtypes in array conversions and matching the subtype indication in deferred constants. This change of philosophy eliminates a number of run-time checks and makes for the earlier detection of errors in such situations. == <span id="10">3.10 Other Improvements</span> == Ada 83 had a restriction that type, subtype, and object declarations were not permitted after bodies (including body stubs) within a declarative part. This restriction has been removed in Ada 95. The original restriction reflected Ada's Pascal heritage, where the ordering restrictions between declarations are even more restrictive. However, in retrospect, the restriction seems somewhat arbitrary, and forces the separation of declarative items that might more naturally be grouped together, particularly in a package body declarative part. By removing this restriction, it becomes legal to move local variable declarations of a subprogram body to the end of its declarative part. This ensures that such variables are not accessible for up-level references from nested subprograms declared in the same declarative part. By so doing, it makes it easier for a compiler to allocate such variables to hardware registers, rather than having to keep them in memory locations to support possible up-level references. Having removed this restriction, it is necessary to rely more heavily on the Ada 83 rule [RM83 13.1(5-7)] that the representation for a type is "frozen" by the appearance of a body (including a body stub). This rule precludes the separation of a representation clause from its associated declaration by a body. In Ada 83, this requirement was a ramification of the syntax, since representation clauses were not allowed to follow bodies syntactically. In Ada 95, the requirement becomes more relevant, since representation clauses are syntactically allowed to appear anywhere in a declarative part. == <span id="11">3.11 Requirements Summary</span> == The requirements for international users * R3.1-A(1) - Base Character Set * R3.1-A(2) - Extended Graphic Literals * R3.1-A(3) - Extended Character Set Support are met by the changes to the type Character and the introduction of Wide_Character and associated packages as discussed in 3.2. The study topic and two requirements regarding subprograms * S4.1-A(1) - Subprograms as Objects * R4.1-B(1) - Passing Subprograms as Parameters * R4.1-B(2) - Pragma Interface are met by access to subprogram types and the pragmas Import, Export and Convention as discussed in 3.7.2. The requirement * R6.1-A(1) - Unsigned Integer Operations is met by the modular types described in 3.3.2. The requirement * R6.4-A(1) - Access Values Designating Global Objects is met by general access types and the study topic * S6.4-B(1) - Low-Level Pointer Operations is also addressed by general access types and the attribute Unchecked_Access. The requirement * R10.1-A(1) - Decimal-Based Types is met by the decimal types mentioned in 3.3.3. Full support for decimal types is provided by the Information Systems annex to which the reader is referred for further details. The requirement * S2.3-A(1) - Improve Early Detection of Errors is addressed by the introduction of static subtype matching. The requirement * R2.2-A(1) - Reduce Deterrents to Efficiency is addressed by the introduction of the concept of base range for numeric types as discussed in 3.3 and by the removal of the restriction on the order of declarations mentioned in 3.10. The requirement * R2.4-A(1) - Minimize Implementation Dependencies is addressed by the stipulation that all static expressions are evaluated exactly and that rounding of odd halves is always away from zero; see 3.9 and II.12. Finally we have mentioned one of the items listed under the general requirement * R2.2-B(1) - Understandability which is that the restriction on order of declarations is now removed. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-2|Previous]] | [[Guide:9x_rationale/rat95-p2-4|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=3 Types and Expressions}} pc4k1x4hgvkxuiudphyb2rsq92knqol Guide:9x rationale/rat95-p2-4 4200 338 1880 1862 2019-04-20T16:21:00Z WikiVisor 11 Text replacement - "[[Guide:9x_rationale/rat95-copyright|Copyright]] | " to "<div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | " wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-3|Previous]] | [[Guide:9x_rationale/rat95-p2-5|Next]]</div> This chapter describes the various ways in which object oriented programming is achieved in Ada 95. The main facilities upon which this is based are * Record types which are marked as tagged may be extended with additional components on derivation. * The Class attribute may be applied to a tagged type and denotes the corresponding class-wide type. * Subprogram calls with formal parameters of a specific type called with actual parameters of a class-wide type are dispatching calls. * Types and subprograms may be specified as abstract. * There are various new forms of generic parameter corresponding to derived and tagged types. These topics were discussed in some detail in Part One and are further discussed in other chapters in this part (see Chapter 3 for types, including abstract types and abstract subprograms, and Chapter 12 for generic parameters). The discussion in this chapter is more idiomatic and concentrates on how the features are used in Ada 95 and briefly contrasts the approach with that of other object oriented languages. == <span id="1">4.1 Background and Concepts</span> == Ada has been traditionally associated with object oriented design [Booch 86], which advocates the design of systems in terms of abstract data types using objects, operations on objects, and their encapsulation as private types within packages. The "ingredients" of object oriented design may be summarized as follows: * Objects. Entities that have structure and state. * Operations. Actions on objects that may access or manipulate that state. * Encapsulation. Some means of defining objects and their operations and providing an abstract interface to them, while hiding their implementation details. Ada 83 was well suited to supporting the paradigm of object oriented design. Object oriented programming, as that term has evolved over the past decade, builds upon the base of object oriented design, adding two other ingredients: inheritance and polymorphism. While the specific properties of these two facilities vary from one programming language to another, their essential characteristics may be stated as * Inheritance. A means for incrementally building new abstractions from existing ones by "inheriting" their properties - without disturbing the implementation of the original abstraction or the existing clients. * Polymorphism. A means of factoring out the differences among a collection of abstractions, such that programs may be written in terms of their common properties. Ada 83 has been described as an object based language; it does not have the support for inheritance and polymorphism found in fully object oriented languages (see 4.7). Recognizing this, the Ada 9X Requirements reflect the need to provide improved support for this paradigm through three Study Topics [DoD 90] as follows. <blockquote> '''S4.1-A(1) - Subprograms as Objects''': Ada 9X should provide: # an easily implemented and efficient mechanism for dynamically selecting a subprogram that is to be called with a particular argument list; # a means of separating the set of subprograms that can be selected dynamically from the code that makes the selection. '''S4.3-A(1) - Reducing the Need for Recompilation''': Ada 9X recompilation and related rules should be revised so it is easier for implementations to minimize the need for recompilation and for programs to use program structures that reduce the need for recompilation. '''S4.3-B(1) - Programming by Specialization/Extension''': Ada 9X shall make it possible to define new declared entities whose properties are adapted from those of existing entities by the addition or modification of properties or operations in such a way that: * the original entity's definition and implementation are not modified; * the new entity (or instances thereof) can be used anywhere the original one could be, in exactly the same way. </blockquote> Each of these Study topics can be understood in relation to object oriented programming. S4.1-A(1) seeks the ability to associate operations (subprograms) with objects, and to dynamically select and execute those operations. This is one basis on which to develop run-time polymorphism. Among the various causes of excessive recompilation addressed by S4.3- A(1) are those arising from the breakage of an existing abstraction for the purpose of extending or otherwise reusing it to build a new abstraction. The topic S4.3-B(1) implies the essence of object oriented programming as defined above. Alternatively, one might think of this in terms of two programming paradigms * Variant programming. New abstractions may be constructed from existing ones such that the programmer need only specify the differences between the new and old abstractions. * Class-wide programming. Classes of related abstractions may be handled in a unified fashion, such that the programmer may systematically ignore their differences when appropriate. Finally, it should be mentioned that there are two rather awkward problems to be addressed and solved in designing a compiled language for object oriented programming which retains efficiency and avoids unnecessary run-time decisions. * Dispatching. The means of indicating in the program text when dispatching and especially redispatching is used as opposed to static resolution. * Multiple Inheritance. The means of inheriting components and operations from two or more parent types. As will be seen, the solution adopted to these problems in Ada 95 illustrates our concern for clarity and the advantages of the building block approach. == <span id="2">4.2 General Approach</span> == Ada 95 generalizes the type facilities of Ada 83 in order to provide more powerful mechanisms for variant and class-wide program development and composition. Derived types in Ada 83 provided a simple inheritance mechanism: they inherited exactly the structure, operations, and values of their parent type. This "inheritance" could be augmented with additional operations but not with additional components. Ada 95 generalizes type derivation to permit type extension as we saw in II.1. A tagged record or private type may be extended with additional components on derivation. Tagged objects are self-identifying; the tag indicates their specific type. Tagged types provide a mechanism for single inheritance as found in object oriented programming languages such as Simula [Birtwistle 73] and Smalltalk [Goldberg 83]. The following example of type extension is inspired by [Seidewitz 91]. We first declare <syntaxhighlight lang="Ada"> type Account_With_Interest is tagged record Identity: Account_Number := None; Balance : Money := 0.00; Rate : Interest_Rate := 0.05; Interest: Money := 0.00; end record; procedure Accrue_Interest(On_Account: in out Account_With_Interest; Over_Time : in Integer); procedure Deduct_Charges(From: in out Account_With_Interest);</syntaxhighlight> and can then extend it <syntaxhighlight lang="Ada"> type Free_Checking_Account is new Account_With_Interest with record Minimum_Balance: Money := 500.00; Transactions : Natural := 0; end record; procedure Deposit(Into : in out Free_Checking_Account; Amount: in Money); procedure Withdraw(From : in out Free_Checking_Account; Amount: in Money); Insufficient_Funds: exception; -- raised by Withdraw procedure Deduct_Charges(From: in out Free_Checking_Account);</syntaxhighlight> The type Account_With_Interest is a tagged type. The type Free_Checking_Account is derived from it, inheriting copies of its components (Identity, Balance, Rate, Interest) and its operations (Accrue_Interest and Deduct_Charges). The derived type declaration has a record extension part that adds two additional components (Minimum_Balance and Transactions) to those inherited from the parent. The type adds some new operations (Deposit and Withdraw) and also overrides Deduct_Charges such that if the Balance was above the Minimum_Balance, no charges would be deducted. All components of the type, whether inherited or declared as a part of the extension, are equally accessible (unlike "nested" record types). In Ada 83, the types declared in the visible part of a package had special significance for Ada's abstraction mechanisms. Such operations on user-defined types were first-class in a manner that parallels those of the predefined types. For derived types, these operations, together with the implicitly declared basic operations, were the derivable operations on a type. With the increased importance of derived types for object oriented programming in Ada 95, the notion of the operations closely related to a type in this manner is generalized. The primitive operations of a type are those that are implicitly provided for the type and, for types immediately declared in a package specification, all subprograms with an operand or result of the type declared anywhere in that package specification. The domain is therefore extended to include the private part (but not the body). Thus, in Ada 95, the derivable operations of Ada 83 have become "primitive operations" and the restriction of these operations to the visible part of a package has been eliminated. These changes support added capability: primitive operations may be private and a type and its derivatives may be declared in the same declarative region (this property is useful for building related abstractions and was used in the package New_Alert_System of Part One). Primitive operations clarify the notion of an abstract data type for purposes of object oriented programming (inheritance and polymorphism) and genericity. They are distinguished from the other operations of a type in the following ways * Inheritance. Primitive operations are the derivable (inherited) operations. * Polymorphism. Primitive operations are dispatching operations on tagged types. * Genericity. Primitive operations are the ones available within generic templates parameterized by a class. Ada 83 used the term "class" (see [RM83 3.3]) to characterize collections of related types. The class of a type determines how the type is declared, the types it can be converted to, its predefined operations, and its structure. The class of a generic formal type parameter determines the operations that are available within the generic template. Types within a class have common structure and operations (see III.1.2 for a further description of the class structure of Ada). Ada 95 formalizes the Ada 83 notion of class. A type and its direct and indirect derivatives, whether or not extended, constitute a derivation class. This definition allows for user-defined classes based on derivation. User-defined classes, like the language-defined classes, support type conversion, may be used to parameterize generic units and, in the case of tagged types, provide class-wide programming. Explicit conversion is defined among types within a class, as it was in Ada 83 for types related by derivation, except that conversion is not allowed away from the root since additional components may be required. Such transformations require an extension aggregate as described in 3.8. Thus, continuing the previous example, a value of Account_With_Interest can be extended to a value of Free_Checking_Account by providing values for the additional components Minimum_Balance and Transactions. <syntaxhighlight lang="Ada"> Old_Account: Account_With_Interest; ... New_Account: Free_Checking_Account := (Old_Account with Minimum_Balance => 0.00, Transactions => 0);</syntaxhighlight> The Ada 95 rules for conversion between types in a class define the semantics of inherited operations in Ada 95 and are consistent with the semantics of inherited operations in Ada 83. Calling an inherited operation is equivalent to calling the parent's corresponding operation with a conversion of the actual to the parent type. Thus, inherited operations "ignore" the extension part. User-defined classes may be employed to parameterize generic units. A new kind of generic formal, a generic formal derived type, may be used. This kind of formal is matched by any type in the class rooted at the generic formal's specified ancestor type. For each tagged type T, there is an associated class-wide type T'Class. The set of values of T'Class is the discriminated union of the sets of values of T and all types derived directly or indirectly from T. Discrimination between the different specific types is with a type tag. This tag, associated with each value of a class-wide type, is the basis for run-time polymorphism in Ada 95. Note that ordinary types are referred to as specific types to distinguish them from class-wide types. The associated class-wide type T'Class is "dynamic" in the sense of [Abadi 91]. The values of the class-wide type can be thought of as pairs consisting of * A tag. A type descriptor ranging over the types that are members of the class; and * A value. The value taken from the specific type with the given tag. Such tag and value pairs are strongly typed, consistent with the philosophy of Ada. But only the class, and not necessarily the type within that class, will generally be known statically. Class-wide types have no primitive operations of their own. However, explicit operations may be declared for such types, using T'Class as a subtype mark. Such operations are "class-wide" and can be applied to objects of any specific type within the class as well as to objects of the class-wide type or a descendent class-wide type. Thus the following functions <syntaxhighlight lang="Ada"> function Size_In_Bytes(Any_File: File'Class) return Natural; function Get_File_From_User return File'Class;</syntaxhighlight> are class-wide operations and can be applied to all specific types of the class of types derived from the tagged type File. No dispatching is involved; the one same function is called whatever the tag of the actual parameter. On the other hand, when a primitive operation of a tagged type is called with an operand of the class-wide type, the operation to be executed is selected at run time based on the type tag of the operand. As mentioned before, this run-time selection is called dispatching, so primitive operations of tagged types are called dispatching operations. Dispatching provides a natural form of run-time polymorphism within classes of related (derived) types. This variety of polymorphism is known as "inclusion polymorphism" [Cardelli 85]. <syntaxhighlight lang="Ada"> +----------+---------------------------------+ | | formal | | actual | specific | class-wide | +----------+----------------+----------------+ | | | | | specific | static binding| class-wide op | | | | | |----------+----------------+----------------| | | | | |class-wide| dispatching | class-wide op | | | | | +----------+---------------------------------+ Table 4-1: Kinds of Binding</syntaxhighlight> An operand used to control dispatching is called a controlling operand. A primitive operation may have several controlling operands; a primitive function may also have a controlling result. For a further discussion on controlling operands and results see 4.5. The different kinds of binding corresponding to the various combinations of actual and formal parameters are summarized in Table 4-1. The following example shows how a type File might be the basis for a class of types relating to the implementation of an Ada library <syntaxhighlight lang="Ada"> type File is tagged private; procedure View(F: File); -- display file F on screen type Directory is new File with private; procedure View(D: Directory); -- list directory D type Ada_File is new File with private; procedure View(A: Ada_File); -- open A with Ada sensitive editor type Ada_Library is new Directory with private; procedure View(L: Ada_Library); -- list library units of L and their status declare A_File: File'Class := Get_File_From_User; begin View(A_File); -- dispatches according to specific type of file end;</syntaxhighlight> The above example presents a user-defined class of File types. The type File is tagged and hence the primitive operation View is dispatching. View is overridden for each type in the class in order to provide a unique behavior for each type of File. When View is called with a parameter that is of type File'Class, the tag will be used to determine the actual type within the class, and the call will dispatch to the View procedure for that type. On the other hand if View is called with a specific type then the choice of View procedure to be called is determined at compile time. The hierarchy of types in the above example is illustrated in Figure 4-1. <syntaxhighlight lang="Ada"> File | | +-------------------+ | | Directory Ada_File | | | | Ada_Library Figure 4-1: The File Hierarchy</syntaxhighlight> An earlier version of Ada 9X introduced class-wide types through the Class attribute for all derivation classes and not just those for tagged types. This was discarded since many reviewers felt that the added flexibility was unwise. Note also that universal types (for numeric types) behave much as class-wide types although there are differences, see 3.3. When building an abstraction that is to form the basis of a class of types, it is often convenient not to provide actual subprograms for the root type but just abstract subprograms which can be replaced when inherited. This is only allowed if the root type is declared as abstract; objects of an abstract type cannot exist. This technique enables common class-wide parts of a system to be written without being dependent on the properties of any specific type at all. Dispatching always works because it is known that there can never be any objects of the abstract type and so the abstract subprograms could never be called. This technique is illustrated in II.3. === <span id="2-1">4.2.1 Benefits of Approach</span> === A number of important practical criteria of concern to both existing and new users were taken into account when designing the object oriented facilities of Ada 95. <dl> <dt>Compatibility</dt> <dd><p>Legal Ada 83 programs should remain legal in Ada 95. Ideally, existing Abstract Data Types (ADTs) should be reusable with newly developed ones - the new facilities should not be so radically different from mechanisms of Ada 83 that existing ADTs must be rebuilt before being reused.</p> <p>Tagged type extension and class-wide types are built upon the Ada 83 model of derived types. Their use is optional, and their presence in the language does not affect Ada 83 programs. Existing ADTs may be combined in some ways with new object oriented abstractions without modification. In other cases, it may be sufficient to add "tagged" to a type declaration, or to make other simple modifications such as changing an access type declaration to designate a class-wide type. Of course, in order to exploit these facilities to the full, it will be necessary to take them into account during the design process.</p></dd> <dt>Consistency</dt> <dd><p>The solution should be conceptually consistent with existing Ada programming models. Intuitions about objects, types, subprograms, generic units, and so on should be preserved.</p> <p>Ada 95 provides new capabilities in the context of a unified programming model: including types, operations and generic units. Class- wide programming generalizes the classes developed in Ada 83 to user- defined classes.</p></dd> <dt>Efficiency</dt> <dd><p>The solution should offer efficient performance for users of the facility with, ideally, no distributed overhead for non-users.</p> <p>The introduction of tagged types, and a distinct class-wide type associated with each specific type as the mechanism for dispatch, makes run-time polymorphism optional to programmers (in contrast to languages like Smalltalk), in two senses.</p> <ul> <li>Programmers can choose whether or not to use object oriented programming, by employing tagged and class-wide types. Types without tags incur no space or time overhead. Only class-wide types allow for class-wide type matching.</li> <li>Dispatching occurs only on primitive operations of tagged types and only when an actual operand is of a class-wide type.</li></ul> </dd> <dt>Implementability</dt> <dd><p>The solution should be readily implementable within current compiler technology, and provide opportunities for optimizations.</p> <p>Dispatching may be implemented as an indirect jump through a table of subprograms indexed by the primitive operations. This compares favorably with method look-up in many object oriented languages, and with the alternative of variant records and case statements, with their attendant variant checks, both in implementability and run-time efficiency.</p></dd></dl> == <span id="3">4.3 Class Wide Types and Operations</span> == We have seen that a record or private type marked as tagged may be extended on derivation with additional components. The run-time tag identifies information that allows class-wide operations on the class- wide type to allocate, copy, compare for equality, and perform any other primitive operations on objects of the class-wide type, in accordance with the requirements of the specific type identified by the tag. The tag is thus important to the inner workings of type extension and class-wide types in Ada 95 and is brought to the fore by using the reserved word tagged in the declaration of the type. The concept of a tag is of course not new to programming languages but has a long precedent of use in Pascal (where it is used in the sense of discriminant in Ada) and is discussed by Hoare in [Dahl 72]. More recently the phrase type tag has been used by Wirth in connection with type extension [Wirth 88]. The reader might find it helpful to understand the concept of the tag and the dispatching rules by considering the implementation model alluded to at the end of the last section. We emphasize that this is just a possible model and does not imply that an implementation has to be done this way. In this model the tag is a pointer to a dispatch table. Each entry in the table points to the body of the subprogram for a primitive operation. Dispatching is performed as an indirect jump through the table using the primitive operation as an index into the table. As an illustration consider the class of Alert types declared in II.1 in the package New_Alert_System. These types form a tree as illustrated in II.2. Recall that the root type Alert has primitive operations, Display, Handle and Log. These are inherited by Low_Alert without any changes. Medium_Alert inherits them from Alert but overrides Handle. High_Alert inherits from Medium_Alert and again overrides Handle and also adds Set_Alarm. (For simplicity, we will ignore other predefined operations which also have "slots" in the dispatch table; such as assignment, the equality operator and the application of the Size attribute.) The tags for the various types are illustrated in Figure 4-2. A dispatching call, such as to Handle, is very cheaply implemented. The code simply jumps indirectly to the contents of the table indexed by the fixed offset corresponding to Handle (one word in this example). The base of the table is simply the value of the tag and this is part of the value of the class-wide object. Note moreover that the dispatch table does not contain any class-wide operations (such as Process_Alerts in II.2) since these are not dispatching operations. In addition to being used as formal parameters to class-wide operations, class-wide types may also be used as the designated type for an access type, and as the type of a declared object. Access types designating a class-wide type are very important, since they allow the creation of heterogeneous linked data structures, such as trees and queues. <syntaxhighlight lang="Ada"> +---------------+ +----------+ | Alert'Tag | --> | Display | --> Display of Alert +---------------+ |----------| | Handle | --> Handle of Alert |----------| | Log | --> Log of Alert +----------+ +---------------+ +----------+ | Low_Alert'Tag | --> | Display | --> Display of Alert +---------------+ |----------| | Handle | --> Handle of Alert |----------| | Log | --> Log of Alert +----------+ +----------------+ +----------+ |Medium_Alert'Tag| --> | Display | --> Display of Alert +----------------+ |----------| | Handle | --> Handle of Medium_Alert |----------| | Log | --> Log of Alert +----------+ +---------------+ +----------+ |High_Alert'Tag | --> | Display | --> Display of Alert +---------------+ |-----------| | Handle | --> Handle of High_Alert |-----------| | Log | --> Log of Alert |-----------| | Set_Alarm | --> Set_Alarm of High_Alert +----------+ Figure 4-2: Tags and Dispatch Tables</syntaxhighlight> Declared objects of a class-wide type are not as frequently used as are formal parameters and heap objects, but they are useful as intermediates in larger computations. However, because there is no upper bound on the size of types in a class, a declared object of a class-wide type must be explicitly initialized. This determines the size, the tag, and any discriminants for the object, and thereafter neither the tag nor the discriminants may be changed. Of course, it is necessary for all class-wide objects to have a tag so that dispatching works without any unnecessary tests. We have chosen to specify the tag by requiring an explicit initial value. This indirectly provides a capability somewhat akin to declaration by association using like in Eiffel [Meyer 88]. We can thereby ensure, for example, that a locally declared class-wide object has the same tag as an actual parameter. Note that discriminants of tagged types are not permitted to have defaults; this would have increased the complexity of the language to no great benefit since the tag of an object (specific and class-wide) cannot be changed and the tag is treated as a (hidden) discriminant. It would be inconsistent to allow discriminants to be changed but not tags. If assignment were allowed to change the tag or the discriminants, then the size of the class-wide object might have to grow, requiring a deallocation and reallocation as part of assignment. We have avoided introducing operations in Ada 95 that involve this kind of implicit dynamic allocation at run-time. Therefore, an explicit access value with explicit deallocation and reallocation is required if a programmer desires to have the equivalent of an unconstrained object of a class-wide type. Note that Ada 83 required a similar approach for handling unconstrained arrays and unconstrained discriminated types without defaults for the discriminants. In general, the way unconstrained composite types and their associated bounds or discriminants were handled in Ada 83 is a good model for how class-wide types and their associated type tags are handled in Ada 95. The predefined equality operators and the membership tests are generalized to apply to class-wide types. Like other predefined operations on such types, the implementation will depend on the particular specific type of the operands. Unlike normal dispatching operations, however, Constraint_Error is not raised if the tags of the operands do not match. For equality, tag mismatch is treated as inequality. Only if the tags match is a dispatch then performed to the type-specific equality checking operation. This approach allows a program to safely compare two values of a class-wide tagged type for equality, without first checking that their tags match. The fact that no exception is raised in such an equality check is consistent with the other predefined relational operators, as noted in [RM83 4.5.2(12)]. For a membership test such as X in S, where X is of a class-wide type, the tag of the value of the simple expression X is checked to see whether it belongs to the subtype mark S. If the subtype mark S identifies a class-wide type, then the membership test determines whether the tag of the value identifies a specific type covered by the class-wide type. If the subtype mark S identifies a specific tagged type, then the membership test determines whether the tag of the value equals the tag of that type. In any case, to be considered a member, the value must satisfy any constraints associated with the subtype mark. The Tag attribute is defined for querying the tag of a specific type, or of an object of a class-wide type. This allows two class-wide objects to be checked to see whether they have the same tag. It is also possible to compare the tag of a class-wide object with the tag of a specific type; such a comparison is equivalent to a membership test. Thus (using the alert example from Part One), the test <syntaxhighlight lang="Ada"> AC in Medium_Alert</syntaxhighlight> is identical to <syntaxhighlight lang="Ada"> AC'Tag = Medium_Alert'Tag</syntaxhighlight> but note that the test <syntaxhighlight lang="Ada"> AC in Medium_Alert'Class</syntaxhighlight> has no generally applicable equivalent in terms of explicit user checks on tags because we cannot talk about possible future extensions in terms of tags. It is thus preferable to use membership tests rather than explicit testing of tags in order to ensure that our program is extensible. The rules for membership tests on class-wide types are constructed so that certain simple type-specific behavior may be performed in a class- wide operation, without the need to declare and define a new primitive operation on all types within the class. For example, given <syntaxhighlight lang="Ada"> type Expression_Node is tagged... type Binary_Operator is new Expression_Node with ... type Node_Ptr is access Expression_Node'Class;</syntaxhighlight> one could define the following operation Display on the access to class- wide type Node_Ptr <syntaxhighlight lang="Ada"> procedure Display(Expr: Node_Ptr; Prec: Positive := 1) is -- display expr, parenthesized if necessary begin if Expr.all in Binary_Operator'Class then -- handle the binary operator subclass declare Binop: constant Bin_Op_Ptr := Bin_Op_Ptr(Expr); -- convert parameter to ptr to Binary_Operator -- to gain access to its subclass operations begin if Precedence(Binop) < Prec then -- parenthesize if lower precedence Put('('); end if; -- display left, op, right, passing down precedence Display(Binop.Left, Precedence(Binop)); Put(Symbol(Binop)); Display(Binop.Right, Precedence(Binop)); if Precedence(Binop) < Prec then -- closing parenthesis if necessary Put(')'); end if; end; else -- handle the other kinds of expressions ... end if; end Display;</syntaxhighlight> An alternative, more "object-oriented" approach would be to define a separate Display primitive operation for each distinct type within the class. See for example [Taft 93]. We conclude this section by discussing a number of important general principles regarding primitive operations and dispatching. It is instructive to map these principles into the implementation model of the tag and dispatch table mentioned above; but remember that this is only a possible model although a very natural one. We can refer to the entries in the dispatch table as "slots". The first general principle is that dispatching always works without any checking at runtime; in other words that the subprogram referred to by the dispatch table for the tag value can always be safely called. A number of individual rules ensure that this is true. Perhaps the most important is that operations cannot be removed when deriving a new type; they can only be added or replaced. This means that if an operation is primitive for a type then it is necessarily available for all (nonabstract) types in the class rooted at that type. Another vital rule is that we cannot create an object of an abstract type; this prevents dispatching to an abstract subprogram (see 3.6.2). Moreover, as discussed further in 4.5, the tag of an object can never be changed, so the tag of a declared object cannot be changed into the tag corresponding to a type without the appropriate operations. Another important rule is that type extension is not allowed at a place which is not accessible from the parent type such as within an inner block. This rule ensures that the accessibility of all specific types in a (tagged) class is the same and prevents a value from being assigned to a class wide object and thereby outlive its specific type. A further consequence is that we cannot dispatch to a subprogram which is at an inner level and which might thereby attempt to access non-existent data. Consider <syntaxhighlight lang="Ada"> package Outer is type T is tagged ...; procedure P(Object: T); -- a dispatching operation type A is access T'Class; Global: A; end Outer; procedure Dodgy is package Inner is type NT is new T with ...; -- an illegal extension procedure P(Object: NT); -- override end; package body Inner is I: Integer := 0; procedure P(Object: NT) is begin I := I + 1; -- assign to variable local to Inner end P; end Inner; begin Global := new Inner.NT'( ...); end Dodgy; procedure Disaster is begin Dodgy; P(Global.all); -- dispatch to non-existent P end Disaster;</syntaxhighlight> The procedure Dodgy attempts to declare the type NT and then assign an access to an object of the specific type to the class wide access variable Global. If this were allowed then the call of P in the procedure Disaster would attempt to dispatch to the procedure inside Inner and thereby access the variable I which no longer exists. Disallowing extensions at an inner level prevents this sort of difficulty. Note also that having all the types at the same accessibility level ensures that the "subprogram values" in the dispatch table can be implemented just as simple addresses; no level information is required. There is an analogy with access to subprogram values discussed in 3.7.2. Another important principle is that the dispatch table is the same for all views of a type; in other words there is just one dispatch table common to both a partial view and a full view. However, it can be the case that some operations are not visible from a partial view. This is discussed further in 7.1.1. Interestingly, it is also possible to have two operations of the same name (and profile), one visible from one view and the other from another view in such a way that they are never both visible from the same view; in this case they would occupy different slots in the dispatch table. These and related possibilities are also illustrated in detail in 7.1.1. The freezing rules have an important impact on type extension. The basic idea is that a record extension freezes the parent; the key impact is that further primitive operations cannot then be declared for the parent. However, a private extension does not freeze the parent; freezing is postponed until the later full declaration. See 13.5.1. Finally, we summarize the rules regarding which operations are primitive. The main rule is that only those operations with an operand or result of the type and declared immediately in the package specification with the type declaration (or type extension) are primitive operations. (This general rule applies to both tagged and other types.) Note that if a type is not declared in a package specification then any operations declared in the same declarative region are not primitive and thus not inherited. Because this might give rise to surprises, especially in the case of tagged types, it is in fact forbidden to call a nonprimitive operation in a dispatching way (that is with a class-wide actual); this eliminates the risk of accidentally declaring a tagged type and then finding that what were presumed to be primitive operations do not dispatch. Note moreover that, in the case of a type extension, although new primitive operations cannot be added except in a package specification, primitive operations inherited from the parent may be overridden wherever the extension is declared and these overridden versions will of course be inherited by any further extension. Thus new slots can only be created by a type declared or extended in a package specification, but existing slots may be overridden wherever a type extension is declared. Consider <syntaxhighlight lang="Ada"> package P is type T is tagged ...; procedure Op1(X: T); -- primitive of T end P; with P; use P; package Q is type NTQ is new T with ...; procedure Op1(X: NTQ); -- overrides inherited Op1 from T procedure Op2(X: NTQ); -- additional primitive of NTQ end Q; package body P is type NTP is new T with ...; procedure Op1(X: NTP); -- overrides inherited Op1 from T procedure Op2(X: NTP); -- not a primitive of NTP end P;</syntaxhighlight> The type NTQ is declared immediately inside the specification of package Q and thus the operation Op2 is primitive. On the other hand NTP is declared in the body of package P and thus although Op1 overrides the inherited Op1, nevertheless the operation Op2 is not primitive. These rules are designed to give flexibility with minimum burden. Many type extensions will simply replace existing operations rather than add new ones and it seems a heavy burden to insist that these be in a package specification. Indeed, in the case of the leaves of the tree of types, there is no need to add further primitive operations (if a type is a leaf then any new operation is not inherited by another type and thus there is no need to dispatch); but it is important to be able to override existing operations wherever the type is declared. See the example in 4.4.4. A minor difference between tagged and nontagged types concerns the parameter modes of overriding operations. In the case of tagged types an overriding operation must have the same parameter modes otherwise dispatching would not work. In the case of nontagged types this does not matter and for compatibility with Ada 83, the modes need not be the same; note that overload resolution ignores parameter modes. == <span id="4">4.4 Examples of Use</span> == This section presents some of the ways in which Ada 95's object oriented programming features may be used and combined with other facilities to address a number of programming paradigms. An important use of object oriented programming is variant programming. This was amply illustrated by the example of processing alerts in Part One. As we saw, the use of variant records can be both cumbersome and error prone [Wirth 88] whereas the use of type extension is both more flexible and entirely secure. In this section we give other typical paradigms of use * An example of different approaches to a standard queue package that can be used as a basis for a wide range of applications. * An example of a more elaborate heterogeneous doubly linked list abstraction. * An example showing how alternative implementations can be provided for the same abstraction. * An example showing how type extension and dispatching can be used to program iterators and similar applications. === <span id="4-1">4.4.1 Queues</span> === In dealing with the alert example in II.2 we mentioned that the various alerts might be held on a queue ready for processing. Such a queue must have the capability to be heterogeneous because the alerts are of different specific types. This is a common requirement and it is therefore appropriate to develop a package that can be reused for a variety of applications. However, the strong typing model of Ada 83 made it very difficult to write a common abstraction that could be reused without alteration even through the use of generics. (Only homogeneous structures could be constructed with Ada 83 generic units. Variant records could be used to provide some heterogeneity, but source code changes and possibly extensive recompilation were required to add new variants.) There are several approaches that can be taken which have a different balance between convenience and efficiency. We will explore a number of these in order to illustrate various considerations and potential pitfalls to be avoided. We will start at the convenient end of the spectrum by considering a package which is generic with respect to the type of data on the queue. The specification might be <syntaxhighlight lang="Ada"> generic type Q_Data(<>) is private; package Generic_Queues is type Queue is limited private; function Is_Empty(Q: Queue) return Boolean; procedure Add_To_Queue(Q: access Queue; X: in Q_Data); function Remove_From_Queue(Q: access Queue) return Q_Data; Queue_Empty: exception; private ... end Generic_Queues;</syntaxhighlight> It is important to note that the formal type has an unknown discriminant part. It can then be matched by a specific type or by a class wide type (see 12.5). If we use a specific type then of course the queue is homogeneous but using a class wide type provides a heterogeneous queue. Note also that the exported type Queue is limited private; the implementation will inevitably be in terms of pointers to a chained list and making it limited prevents the user from making a copy which might subsequently become nonsense; we will return to the implementation details in a moment. Values are added to the queue by calling the procedure Add_To_Queue and removed by calling the function Remove_From_Queue. Making the latter a procedure with profile <syntaxhighlight lang="Ada"> procedure Remove_From_Queue(Q: access Queue; X: out Q_Data);</syntaxhighlight> is rather restrictive because we cannot call the procedure with an uninitialized class-wide object (they are not allowed) and an initialized one will be constrained by its initial value. Such a procedure is therefore only useful if we always know (by some other means) the anticipated specific type of the item being removed. Using a function works because the returned result provides the initial value and thus the constraint. Incidentally we made the parameter Q of the function an access parameter largely because an in out parameter is not allowed for functions. We could have made it an in parameter but the internal implementation of the queue would then need an extra level of indirection. See 6.1.2 for a fuller discussion on the merits of access versus in out parameters. We also have to choose between declaring a queue directly and making it aliased or creating the queue with an allocator. We choose the latter. So for the alerts, we can write <syntaxhighlight lang="Ada"> package Alert_Queues is new Generic_Queues(Q_Data => Alert'Class); use Alert_Queues; type Queue_Ptr is access all Queue; The_Queue: Queue_Ptr := new Queue; ... MA: Medium_Alert := ...; ... Add_To_Queue(The_Queue, MA);</syntaxhighlight> and a value could be retrieved by <syntaxhighlight lang="Ada"> Any_Alert: Alert'Class := Remove_From_Queue(The_Queue);</syntaxhighlight> where the result provides the constraint for Any_Alert. Returning to the example in II.2, we could then call the first form of Process_Alerts by <syntaxhighlight lang="Ada"> Process_Alerts(Any_Alert);</syntaxhighlight> and indeed we could directly write <syntaxhighlight lang="Ada"> Process_Alerts(Remove_From_Queue(The_Queue));</syntaxhighlight> It is often preferable to manipulate access values to tagged types rather than tagged type values themselves; partly because this avoids the cost of copying and perhaps more important it overcomes the problem of not knowing the size of the object in the case of a class wide type. So an alternative approach would be to write <syntaxhighlight lang="Ada"> type Alert_Ptr is access all Alert'Class; package Alert_Ptr_Queues is new Generic_Queues(Alert_Ptr); use Alert_Ptr_Queues; type Queue_Ptr is access all Queue; The_Queue: Queue_Ptr := new Queue; ... New_Alert: Alert_Ptr := new Medium_Alert'(...); ... Add_To_Queue(The_Queue, New_Alert);</syntaxhighlight> and then in the body of the second form of Process_Alerts we could have <syntaxhighlight lang="Ada"> Next_Alert: Alert_Ptr := Remove_From_Queue(The_Queue); ... Handle(Next_Alert.all);</syntaxhighlight> This second formulation is very straightforward since the queue is really homogeneous; all the elements are of the same access type and the heterogeneity comes from the nature of the accessed type. We now return to consider how the generic package might be implemented. An important point is that since the formal type is indefinite, we cannot declare an uninitialized object of the type or a record with a component of the type. This forces us to use dynamic storage. As a first attempt the private part might be <syntaxhighlight lang="Ada"> private type Data_Ptr is access Q_Data; type Node; type Node_Ptr is access Node; type Node is record D: Data_Ptr; Next: Node_Ptr; end record; type Queue is record Head: Node_Ptr; Tail: Node_Ptr; end record; end Generic_Queues;</syntaxhighlight> This is an obvious approach although slightly cumbersome because of the double levels of indirection. This causes a double allocation whenever a new data item is added; one for the node and one for the data itself. Care is also needed in discarding storage when an item is removed. The details are left to the reader. A problem with the above approach is the encapsulation of the storage management. Although the generic is very reusable it is somewhat costly because of the storage allocation overheads. Of course if the queue were homogeneous and had a definite parameter without <> then it would be simpler because the values could be stored directly; we are paying for the generality. Insisting that the parameter be definite would not be unreasonable because, as shown above, the client can always pass an access type. A completely different approach is to arrange things so that the user's type provides the storage for the linking mechanism through type extension; this avoids the overheads of storage management but requires a little more effort on the part of the user. Consider the following <syntaxhighlight lang="Ada"> package Queues is type Queue is limited private; type Queue_Element is abstract tagged private; type Element_Ptr is access all Queue_Element'Class; function Is_Empty(Q: Queue) return Boolean; procedure Add_To_Queue(Q: access Queue; E: in Element_Ptr); function Remove_From_Queue(Q: access Queue) return Element_Ptr; Queue_Error: exception; private type Queue_Element is tagged record Next: Element_Ptr := null; end record; type Queue is limited record Head: Element_Ptr := null; Tail: Element_Ptr := null; end record; end Queues;</syntaxhighlight> The general idea is that the user extends the type Queue_Element with the data to be queued. The linking is then done through the private component Next of which the user is not aware. The body might be as follows <syntaxhighlight lang="Ada"> package body Queues is function Is_Empty(Q: Queue) return Boolean is begin return Q.Head = null; end Is_Empty; procedure Add_To_Queue(Q: access Queue; E: in Element_Ptr) is begin if E.Next /= null then raise Queue_Error: -- already on a queue end if; if Q.Head = null then -- list was empty Q.Head := E; Q.Tail := E; else Q.Tail.Next := E; Q.Tail := E; end if; end Add_To_Queue; function Remove_From_Queue(Q: access Queue) return Element_Ptr is Result: Element_Ptr; begin if Is_Empty(Q) then raise Queue_Error; end if; Result := Q.Head; Q.Head := Result.Next; Result.Next := null; return Result; end Remove_From_Queue; end Queues;</syntaxhighlight> Heterogeneous queues can be made because the type Element_Ptr is an access to class wide type. There are a number of ways in which this approach can be used which we will now explore using the alert example. The first point is that we cannot extend the queue element with a class wide type and so we cannot just make a single extension which directly contains any alert. We could of course just extend with a component of the type Alert_Ptr and then add and remove alerts as follows <syntaxhighlight lang="Ada"> type Alert_Element is new Queue_Element with record The_Ptr: Alert_Ptr; end record; ... type Queue_Ptr is access all Queue; The_Queue: Queue_Ptr := new Queue; ... New_Alert: Alert_Ptr := new Medium_Alert'(...); New_Element: Element_Ptr := new Alert_Element'(Queue_Element with New_Alert); Add_To_Queue(The_Queue, New_Element); ... Next_Alert := Alert_Element(Remove_From_Queue(The_Queue)).The_Ptr;</syntaxhighlight> Note the use of the extension aggregate with the subtype name as the ancestor part, see 3.6.1. We could create distinct element types for each alert level although this has its own problems as will soon become apparent. If we write <syntaxhighlight lang="Ada"> type Low_Element is new Queue_Element with record LA: Low_Alert; end record; type Medium_Element is new Queue_Element with record MA: Medium_Alert; end record; ...</syntaxhighlight> then adding alerts to the queue is relatively straightforward. <syntaxhighlight lang="Ada"> MA: Medium_Alert := ...; New_Element: Element_Ptr := new Medium_Element'(Queue_Element with MA); Add_To_Queue(The_Queue, New_Element);</syntaxhighlight> Removing an alert in this formulation is less straightforward since we have to identify its specific type by interrogating the tag thus <syntaxhighlight lang="Ada"> Next_Element: Element_Ptr := Remove_From_Queue(The_Queue); ... if Next_Element'Tag = Low_Element'Tag then Process_Alerts(Low_Element(Next_Element).LA);</syntaxhighlight> Unfortunately this brings us back to variant programming which we try to avoid. The essence of the difficulty is that we have dispersed the alerts into the different queue elements and lost their commonality. There are two possible different approaches. The best is to plan ahead and ensure that the complete alert hierarchy is developed with the common queue element already in place. Following II.3, we can write <syntaxhighlight lang="Ada"> with Queues; use Queues; package Base_Alert_System is type Alert is abstract new Queue_Element with null record; procedure Handle(A: in out Alert) is abstract; end Base_Alert_System;</syntaxhighlight> and then we develop all the rest of the alert structure as before. Now all alerts themselves have the linking mechanism already in them and can be directly placed on a queue. So we can now simply write <syntaxhighlight lang="Ada"> New_Alert: Alert_Ptr := new Medium_Alert'(...); Add_To_Queue(Queue, New_Alert); ... Next_Alert := Alert_Ptr(Remove_From_Queue(The_Queue));</syntaxhighlight> Note that we have to convert the result to the type Alert_Ptr. This conversion requires a runtime check which always passes (because we have only placed alerts on the queue). An important point to note with this approach is that each element can be on only one queue at a time. An attempt to place an element on a second queue will result in Queue_Error. Note that when an element is removed from a queue, its Next component is set to null so that it can then be placed on another queue. Observe that if we consider the elements as like real objects then they can only be in one place at a time and hence only on one queue at a time; so the restriction should not be unrealistic. If it is quite impossible to modify an existing hierarchy to incorporate the link in the root (perhaps because we do not have the source), then it is still possible to avoid the variant difficulty when removing elements from the queue. The idea is to add a dispatching operation which can extract the particular alert; we can write <syntaxhighlight lang="Ada"> with Queues; use Queues; package Alert_Elements is type Data_Element is abstract new Queue_Element with null record; type Data_Element_Ptr is access all Data_Element'Class; function Extract(D: Data_Element) return Alert'Class is abstract; end Alert_Elements;</syntaxhighlight> By introducing the type Data_Element we provide a place to attach the required dispatching operation. Note of course that Extract only applies to the class rooted at Data_Element and not the class rooted at Queue_Element. We can now declare the various types such as Low_Element for each alert type as extensions of Data_Element and provide an appropriate function Extract for each such as <syntaxhighlight lang="Ada"> type Low_Element is new Data_Element with record LA: Low_Alert; end record; function Extract(D: access Low_Element) return Alert'Class is begin return D.LA; end Extract;</syntaxhighlight> We can add alerts to the queue much as before but removing alerts is now much simpler. Having copied the pointer to the removed element into Next_Element we can then convert to the type Data_Element and then call Extract thus <syntaxhighlight lang="Ada"> Next_Element: Element_Ptr := Remove_From_Queue(The_Queue); Any_Alert: Alert'Class := Extract(Data_Element_Ptr(Next_Element));</syntaxhighlight> so that dispatching to the appropriate function Extract occurs thereby overcoming the need for variant programming. Although this mechanism works, it is vulnerable to error if the alert structure is extended. There is a risk that the corresponding extension to the element structure might be forgotten in which case a value of an extended type will not be extracted properly. We continue this rather long discussion by considering how the original generic queue package could be implemented in terms of the second package. The private part and body might be <syntaxhighlight lang="Ada"> private type Data_Ptr is access Q_Data; type Q_Element is new Queues.Queue_Element with record D: Data_Ptr; end record; type Queue is new Queues.Queue; end Generic_Queues; package body Generic_Queues is function Is_Empty(Q: Queue) return Boolean is begin return Queues.Is_Empty(Queues.Queue(Q)); end Is_Empty; procedure Add_To_Queue(Q: access Queue; X: in Q_Data) is begin Queues.Add_To_Queue(Queues.Queue(Q), new Q_Element'(Queues.Queue_Element with new Q_Data'(X))); end Add_To_Queue; function Remove_From_Queue(Q: access Queue) return Q_Data is begin if Is_Empty(Q) then raise Queue_Empty; end if; declare Q_E_P: Queues.Element_Ptr := Queues.Remove_From_Queue(Queues.Queue(Q)); D_P: Data_Ptr := Q_Element(Q_E_P.all).D; Result: Q.Data := D_P.all; begin -- can now discard storage occupied by the queue element -- and the data; assuming suitable unchecked conversions Free(Q_E_P); Free(D_P); return Result; end; end Remove_From_Queue; end Generic_Queues;</syntaxhighlight> Note that we have to take care not to lose access to the storage so that it can be freed. In particular the result is copied into a local variable; this is allowed despite the type being indefinite because the variable is initialized. Another point is that Is_Empty, Add_To_Queue and Remove_From_Queue can be slightly simplified since Queue is derived from Queues.Queue and therefore inherits subprograms with the same identifiers (although different profiles). For example we could simply write <syntaxhighlight lang="Ada"> procedure Add_To_Queue(Q: access Queue; X: in Q_Data) is begin Add_To_Queue(Q, new Q_Element'(Queues.Queue_Element with new Q_Data'(X))); end Add_To_Queue;</syntaxhighlight> The implementation of the generic queue package involves much copying of the data; nevertheless it provides a clean interface and hides all the problems. However, the lower level package is almost as easy to use if the data is structured correctly. Intermediate designs are also possible; for example a generic package that accepts any definite type. The two subprograms could then both be procedures with in out parameters and less indirection would be required. We conclude with some general observations. It is much easier to manipulate access values when dealing with class wide data. This is largely because of the difficulties of storing such data. We also note that object oriented programming requires thought especially if variant programming is to be avoided. There is a general difficulty in finding out what is coming which is particularly obvious with input-output; it is easy to write dispatching output operations but generally impossible for input. === <span id="4-2">4.4.2 Heterogeneous Lists</span> === For the next example we consider doubly-linked lists which are a common programming technique. The implementation shown below uses tagged types and somewhat similar techniques to the second queue package in the last section although at a lower level of abstraction. <syntaxhighlight lang="Ada"> package Doubly_Linked is type Node_Type is tagged limited private; type Node_Ptr is access all Node_Type'Class; -- define add/remove operations, -- assuming head of list is a single Node_Ptr procedure Add(Item: Node_Ptr; Head: in out Node_Ptr); -- add new node at head of list procedure Remove(Item: Node_Ptr; Head: in out Node_Ptr); -- remove node from list, update Head if necessary -- define functions to iterate forward or backward over list function Next(Item: Node_Ptr) return Node_Ptr; function Prev(Item: Node_Ptr) return Node_Ptr; private type Node_Type is tagged limited record Prev: Node_Ptr := null; Next: Node_Ptr := null; -- other components to be added by extension end record; end Doubly_Linked;</syntaxhighlight> This illustrates the specification of a simple doubly linked list abstraction that may be extended with additional components and operations to create useful heterogeneous linked lists. It is similar to the second queue example in that the user extends the type Node_Type to contain the required data and it allows heterogeneous lists because the type Node_Ptr is an access to class wide type and thus allows the various nodes of different specific types to be linked together. A difference is that the user refers to the list through the parameter Head which is also of the type Node_Ptr. Being doubly linked there is no need to separately maintain a reference to the tail of the list. And indeed it is possible to create variations which deal with circular lists. The procedure Add places a new item at the start of the list but in contrast to the queue example, the procedure Remove takes the given item from wherever it is in the list. The procedures Next and Prev enable the user to move over the list as required. The details of the implementation are not shown but should ensure correct behavior when dealing with an empty list and should also guard against adding an item which is already on the list (or another list) or removing something not on the list. We can now use the Doubly_Linked abstraction to demonstrate programming by extension. We implement a keyed association abstraction using an extension of Doubly_Linked.Node_Type. The generic package Association takes a Key_Type, an equality operation defined on the Key_Type and a hash function defined on the Key_Type. The exported type Element_Type is intended to be further extended with the data to be associated with the key. <syntaxhighlight lang="Ada"> with Doubly_Linked; generic type Key_Type is limited private; with function "="(Left, Right: Key_Type) return Boolean is <>; with function Hash(Key: Key_Type) return Integer is <>; package Association is type Element_Type is new Doubly_Linked.Node_Type with record Key: Key_Type; end record; type Element_Ptr is new Doubly_Linked.Node_Ptr; function Key(E: Element_Ptr) return Key_Type; type Association_Table(Size: Positive) is limited private; -- size determines size of hash table procedure Enter(Table : in out Association_Table; Element: in Element_Ptr); function Lookup(Table: in Association_Table; Key : in Key_Type) return Element_Ptr; -- other operations on Association_Table (eg, an iterator)... private type Element_Ptr_Array is array (Integer range <>) of Element_Ptr; type Association_Table(Size: Positive) is record Buckets: Element_Ptr_Array(1 .. Size); end record; end Association;</syntaxhighlight> An Association_Table is a hash table, where each hash value has an associated doubly-linked list of elements. The elements may be of any type derived from Element_Type. The head of each list is of the type Element_Ptr which is itself derived from Node_Ptr (an untagged derived type). All the primitive operations (Add, Remove etc) which apply to Node_Ptr are thus inherited by Element_Ptr. The function Key returns the key component of the object referred to as parameter. We can now go on to define a symbol table for a simple language with types, objects, and functions using the association structure. The symbol table allows different types of entries for each of types, objects and functions. <syntaxhighlight lang="Ada"> with Association; package Symbol_Table_Pkg is type Identifier is access String; -- symbol table key is pointer to string -- allowing arbitrary length identifiers function Equal(Left, Right: Identifier) return Boolean; function Hash(Key: Identifier) return Integer; -- instantiate Association to produce symbol table package Symbol_Association is new Association(Identifier, Equal, Hash); subtype Symbol_Table is Symbol_Association.Association_Table; -- define the three kinds of symbol table elements -- using type extension type Type_Symbol is new Symbol_Association.Element_Type with record Category: Type_Category; Size : Natural; end record; type Type_Ptr is access Type_Symbol; type Object_Symbol is new Symbol_Association.Element_Type with record Object_Type : Type_Ptr; Stack_Offset: Integer; end record; type Function_Symbol is new Symbol_Association.Element_Type with record Return_Type : Type_Ptr; Formals : Symbol_Table(5); -- very small hash table Locals : Symbol_Table(19); -- bigger hash table Function_Body: Statement_List; end record; end Symbol_Table_Pkg;</syntaxhighlight> A type Symbol_Table is produced by instantiating the generic Association with a key that is a pointer to a string. Then three extensions of Element_Type are declared, each of which may be entered into the symbol table. An interesting point is that the elements for the type Function_Symbol each themselves contain internal symbol tables. The body of the generic Association package might be as follows <syntaxhighlight lang="Ada"> package body Association is procedure Enter(Table: in out Association_Table; Element: Element_Ptr) is -- enter new element into association table. Hash_Index: constant Integer := (Hash(Element.Key) mod Table.Size) + 1; use Doubly_Linked; begin -- add to linked list of appropriate bucket Add(Element, Table.Buckets(Hash_Index)); end Enter; function Key(E: Element_Ptr) return Key_Type is begin return Element_Type(E.all).Key; end Key; function Lookup(Table: Association_Table; Key: Key_Type) return Element_Ptr is -- look up element in association table. Hash_Index: constant Integer := (Hash(Key) mod Table.Size) + 1; Ptr: Element_Ptr := Table.Buckets(Hash_Index); -- head of list use Doubly_Linked; begin -- Scan doubly-linked list for element with -- matching key. Return null if none found. while Ptr /= null loop if Key(Ptr).Key = Key then return Ptr; -- matching element found and returned end if; Ptr := Next(Ptr); end loop; return null; -- no matching element found end Lookup; end Association;</syntaxhighlight> The operations Enter and Lookup are implemented in a straightforward manner using the operations of the type Element_Ptr inherited from Node_Ptr. The function Key is interesting. Note first that since Element_Ptr is derived from Node_Ptr its accessed type is also Node_Type'Class (this is a nontagged derivation and when we derive from an access type the accessed type of the derived type is the same as its parent as in Ada 83). So the expression E.all is of the type Node_Type'Class. It is then converted to the specific type Element_Type (this is away from the root and so involves a run-time check which will always succeed in this example) and the component is then selected. Note that since the type Node_Ptr is visible we could declare an object directly and pass an access to it as parameter to the function Key; this would raise Constraint_Error because the function Key is designed to operate on elements and not on nodes in general. We could overcome this by making the types Element_Type and Element_Ptr private so that the underlying relationship to the type Node_Type is hidden. === <span id="4-3">4.4.3 Multiple Implementations</span> === A very important aspect of object oriented programming is the ability to provide different implementations of the one abstraction. One can do this to some extent in Ada 83 in that one package could have alternate bodies. But only one implementation can be used in one program. It is worth noting that the possibility of multiple implementations of an abstraction has been recognized for some time [Guttag 77]. However, when abstraction facilities were incorporated into conventional compiled languages, a single implementation per interface was typically adopted for pragmatic reasons [Dijkstra 72]. This is illustrated by CLU [Liskov 77] and Modula [Wirth 77] as well as Ada 83. It was really C++ [Stroustrup 91] that was the first main-stream systems programming language that recognized that the dynamic binding inherent in having objects identify their own implementation could be provided while preserving performance. Thus, with a true object oriented language, the common structure of the types and their operations provided by inheritance enable different types to be treated as different realizations of a common abstraction. The tag of an object indicates its implementation and allows a dynamic binding between the client and the appropriate implementation. We can thus develop different implementations of a single abstraction, such as a family of list types [LaLonde 89], matrices (dense or sparse), or set types, as in the next example. The specification of an Abstract_Sets package might be <syntaxhighlight lang="Ada"> -- Given subtype Set_Element is Natural; package Abstract_Sets is type Set is abstract tagged private; -- empty set function Empty return Set is abstract; -- build set with 1 element function Unit(Element: Set_Element) return Set is abstract; -- union of two sets function Union(Left, Right: Set) return Set is abstract; -- intersection of two sets function Intersection(Left, Right: Set) return Set is abstract; -- remove an element from a set procedure Take(From: in out Set; Element: out Set_Element) is abstract; Element_Too_Large: exception; private type Set is abstract tagged null record; end Abstract_Sets;</syntaxhighlight> The package provides an abstract specification of sets. The Set type definition is an abstract tagged private type, whose full type declaration is a null record. It defines a set of primitive operations on Set that are abstract subprograms. Abstract subprograms do not have bodies and cannot be called directly. However, as primitive operations, they are inherited. Derivatives of Set must override these abstract operations to provide their own implementations. Derivatives of Set can extend the root type with components providing the desired data representation, and can then implement the primitive operations for that representation. As an example, one might build an implementation using bit vectors <syntaxhighlight lang="Ada"> with Abstract_Sets; package Bit_Vector_Sets is type Bit_Set is new Abstract_Sets.Set with private; -- Override the abstract operations function Empty return Bit_Set; function Unit(Element: Set_Element) return Bit_Set; function Union(Left, Right: Bit_Set) return Bit_Set; function Intersection(Left, Right: Bit_Set) return Bit_Set; procedure Take(From: in out Bit_Set; Element: out Set_Element); private Bit_Set_Size: constant := 64; type Bit_Vector is array (Set_Element range 0 .. Bit_Set_Size-1) of Boolean; pragma Pack(Bit_Vector); type Bit_Set is new Abstract_Sets.Set with record Data: Bit_Vector; end record; end Bit_Vector_Sets; package body Bit_Vector_Sets is function Empty return Bit_Set is begin return (Data => (others => False)); end; function Unit(Element: Set_Element) return Bit_Set is S: Bit_Set := Empty; begin S.Data(Element) := True; return S; end; function Union(Left, Right: Bit_Set) return Bit_Set is begin return (Data => Left.Data or Right.Data); end; ... end Bit_Vector_Sets;</syntaxhighlight> An alternative implementation more appropriate to very sparse sets might be based on using linked records containing the elements present in a set. We could then write a program which contained both forms of sets; we could convert from one representation to any other by using <syntaxhighlight lang="Ada"> procedure Convert(From: in Set'Class; To: out Set'Class) is Temp: Set'Class := From; Elem: Set_Element; begin -- build up target set, one element at a time To := Empty; while Temp /= Empty loop Take(Temp, Elem); To := Union(To, Unit(Elem)); end loop; end Convert;</syntaxhighlight> This procedure dispatches onto the appropriate operations according to the specific type of its parameters. Remember that all variables of class-wide types (such as Temp) have to be initialized since class-wide subtypes are indefinite and the tag is given by the tag of the initial value. Note that the equality operators are also dispatching operations so that the expression Temp /= Empty uses the equality operation for the type of From. Furthermore, assignment is also a dispatching operation although this is not often apparent. In this example, however, if the type of From were a linked list then a deep copy would be required otherwise the original value could be damaged when the copy is decomposed. Such a deep copy can be performed by using a controlled type for the inner implementation of the list as explained in 7.4. Finally, note that the abstract sets package could have been generic <syntaxhighlight lang="Ada"> generic type Set_Element is private; package Abstract_Sets is ...</syntaxhighlight> and this would have added an extra dimension for the possibility of reuse. === <span id="4-4">4.4.4 Iterators</span> === It is a common requirement to wish to apply some operation over all members of a set. One approach was discussed in 3.7.1 using access discriminants. In this section we show a rather different technique using type extension and dispatching. (We start by assuming the example is not generic and consider the impact of genericity later.) Consider <syntaxhighlight lang="Ada"> type Element is ... package Sets is type Set is limited private; ... -- various set operations type Iterator is abstract tagged null record; procedure Iterate(S: Set; IC: Iterator'Class); procedure Action(E: in out Element; I: in out Iterator) is abstract; private type Node; type Ptr is access Node; type Node is record E: Element; Next: Ptr; end record; type Set is new Ptr; -- implement as singly-linked list end Sets; package body Sets is ... -- bodies of the various set operations procedure Iterate(S: Set; IC: Iterator'Class) is This: Ptr := Ptr(S); begin while This /= null loop Action(This.E, IC); -- dispatch This := This.Next; end loop; end Iterate: end Sets;</syntaxhighlight> This introduces an abstract type Iterator which has a primitive subprogram Action. The procedure Iterate loops over the set and calls by dispatching the procedure Action corresponding to the specific type of the object of the Iterator class. The main purpose of the Iterator type therefore is to identify by dispatching the particular Action to be performed. The simple example of counting the number of elements in a set can now be written as follows. <syntaxhighlight lang="Ada"> package Sets.Stuff is function Count(S: Set) return Natural; end Sets.Stuff; package body Sets.Stuff is type Count_Iterator is new Iterator with record Result: Natural := 0; end record; procedure Action(E: in out Element; I: in out Count_Iterator) is begin I.Result := I.Result + 1; end Action; function Count(S: Set) return Natural is I: Count_Iterator; begin Iterate(S, I); return I.Result; end Count; end Sets.Stuff;</syntaxhighlight> The type Count_Iterator is an extension of the abstract type Iterator and the specific procedure Action does the counting. The result is accumulated in a component of the type Count_Iterator and is thereby made accessible to the procedure Action; this component is initialized to zero when the Count_Iterator is declared inside the function Count. Observe that the type extension is not immediately within a package specification and so it is not possible to add new primitive operations to it. Nevertheless it is possible to override inherited operations such as Action as explained in 4.3. If, for some reason, we wanted to declare additional primitive operations then we would have to introduce an internal package. Note also that we cannot put the type extension inside the function Count because this would break the accessibility rules by making the type extension at a deeper level than the parent type as explained in 3.4. A further point is that if the parent package Sets were generic with the type Element being a formal parameter as in the example with access discriminants in 3.7.1, then the child package Sets.Stuff would also have to be generic. In that case it would be necessary to move the type extension and the overriding operation Action into the private part of Sets.Stuff for reasons explained in 12.5. More general actions can be written in a similar manner. Any parameters or results for the action are passed as components in the iterator type. A general procedure to perform some action might be <syntaxhighlight lang="Ada"> procedure General(S: Set; P: Parameters) is I: General_Iterator; begin ... -- copy parameters into iterator Iterate(S, I); ... -- copy any results from iterator back to parameters end General;</syntaxhighlight> and the type General_Iterator and the corresponding Action procedure take the form <syntaxhighlight lang="Ada"> type General_Iterator is new Iterator with record ... -- components for parameters and workspace end record; procedure Action(E: in out Element; I: in out General_Iterator) is begin E := ...; -- do something to element using data from iterator end Action;</syntaxhighlight> It is instructive to compare this example with the corresponding example using access discriminants in 3.7.1. Wherever possible similar identifiers have been used to make the analogy easier. The analogy could be made closer by putting the function Sets.Count of 3.7.1 inside a package as here. Perhaps the most striking difference is that the two mechanisms are "inside out" to each other in some sense. A notable thing about the access discriminant approach is that the looping mechanism has to be written out for each action. Using type extension the loop is written out once and the dispatching call of Action reaches out to the specific routine required. The type extension approach has a close similarity to the potential method using an access to subprogram value as a parameter. We would like to write something like <syntaxhighlight lang="Ada"> procedure Iterate(S: Set; Action: access procedure(E: in out Element)) is This: Ptr := Ptr(S); begin while This /= null loop Action(This.E); This := This.Next; end loop; end Iterate;</syntaxhighlight> and then <syntaxhighlight lang="Ada"> function Count(S: Set) return Natural is Result: Natural := 0; procedure Count_Action(E: in out Element) is begin Result := Result + 1; end Count_Action; begin Iterate(S, Count_Action'Access); return Result; end Count;</syntaxhighlight> but unfortunately we cannot have anonymous access to subprogram parameters as explained in 3.7.2. Declaring a named access type so that the above starts <syntaxhighlight lang="Ada"> type Action_Type is access procedure(E: in out Element); ... procedure Iterate(S: Set; Action: Action_Type) is ...</syntaxhighlight> does not work either because then the access to the internal procedure Count_Action is illegal. We have to make the procedure internal so that it can manipulate the variable Result. Note that we would not wish to make Result global because that would not work in multitasking programs. See the further discussion in 3.7.2 which also shows how the difficulties can be overcome with generics. The reason for disallowing more general access to subprogram values is that they would require extra information regarding the environment of the procedure (in this case giving addressability of the variable Result). The call of the formal procedure and the dispatching call both serve similar purposes; they enable the iterate procedure to call out to the specific action procedure. In both cases extra information is required; the type extension method enables it to be passed in the type itself. The formal procedure method needs it within the underlying implementation and for a number of reasons this is considered too heavy a burden in the general case. As mentioned earlier, there is a close analogy between the restrictions which ensure that a procedure value is (nearly) always a single address and those which ensure that a dispatching value is always a single address. == <span id="5">4.5 Dispatching and Redispatching</span> == It is important to understand exactly when dispatching (dynamic binding) is used as opposed to the static resolution of binding familiar from Ada 83. The basic principle is that dispatching is used only when a controlling operand is of a class-wide type. In order to facilitate the discussion we will reconsider the New_Alert_System introduced in II.1. The call <syntaxhighlight lang="Ada"> Handle(A); -- A of type Alert'Class</syntaxhighlight> in the procedure Process_Alerts in II.2 is a dispatching call. The value of the tag of A is used to determine which procedure Handle to call and this is determined at run time. On the other hand a call such as <syntaxhighlight lang="Ada"> Handle(Alert(MA));</syntaxhighlight> in the procedure Handle belonging to the type Medium_Alert is not a dispatching call because the type of the operand is the specific type Alert as a result of the explicit type conversion. It is also possible to dispatch on the result of a function when the context of the call determines the tag. Such a result is called a controlling result. It is an important principle that all controlling operands and results of a call must have the same tag. If they are statically determined then, of course, this is checked at compile time. If they are dynamically determined (for example, variables of a class-wide type) then again the actual values must all have the same tag and of course this check has to be made at run time; Constraint_Error is raised if the check fails. In order to avoid confusion a mixed situation whereby some tags are statically determined and some are dynamically determined is not allowed. Thus in the case of the sets example in the previous section, it is illegal to write <syntaxhighlight lang="Ada"> S: Bit_Set := ... T: Set'Class := ... ... S := Union(S, T); -- illegal</syntaxhighlight> even though at run-time it might be the case that the tag of the value of T might be Bit_Set'Tag. But we could write <syntaxhighlight lang="Ada"> S := Union(S, Bit_Set(T));</syntaxhighlight> and the view conversion will check that T is in Bit_Set'Class (the tag of T does not have to be Bit_Set'Tag; it could be of any specific type that can be converted to Bit_Set). A special case arises when the tag is indeterminate. Consider for example the statement <syntaxhighlight lang="Ada"> To := Empty;</syntaxhighlight> in the procedure Convert. The parameterless function Empty has a controlling result but there is no controlling operand to determine the tag. Consequently the tag is determined from the class-wide parameter To which is the destination of the assignment. Of course, the tag of To is dynamically determined and this value is used for dispatching on Empty. The statement <syntaxhighlight lang="Ada"> To := Union(To, Unit(Elem));</syntaxhighlight> similarly causes dispatching on both Union and Unit according to the tag of To. Another rule designed to avoid complexity is that it is not legal for a subprogram to have controlling operands or result of different tagged types. Although it is legal to declare two tagged types in the same package, it is not legal to declare a subprogram that has operands or result of both types in that same package. This can, of course, be done outside the package but then the subprogram is not a primitive operation of the types and does not dispatch anyway. The difficulty with allowing such mixed controlling operands is that it would not be clear how to achieve the various possible combinations of derived operations if both types were derived. If the effect of such mixed operands is required then one type can be replaced by the corresponding class-wide type. See [RM95 3.9.2]. The rules for type conversion (see 3.8) are also designed for clarity. Type conversion is always allowed towards the root of a tree of tagged types and so we can convert a Medium_Alert into an Alert as in the call <syntaxhighlight lang="Ada"> Handle(Alert(MA));</syntaxhighlight> On the other hand we cannot convert a specific type away from the root (there might be missing components); we have to use an extension aggregate even if there are no extra components. So we can "extend" an Alert into a Low_Alert by <syntaxhighlight lang="Ada"> LA := (A with null record);</syntaxhighlight> where we have to write null record because there are no extra components. We can however convert a value of a class-wide type to a specific type as in <syntaxhighlight lang="Ada"> MA: Medium_Alert := Medium_Alert(AC);</syntaxhighlight> where AC is of the type Alert'Class. In such a case there is a run-time check that the current value of the class-wide parameter AC has a tag that identifies a specific type for which the conversion is possible. Hence it must identify the type Medium_Alert or a type derived from it so that the conversion is not away from the root of the tree. In other words we check that the value of AC is actually in Medium_Alert'Class. As mentioned in 3.8 some conversions are what is known as view conversions. This means that the underlying object is not changed but we merely get a different view of it. Almost all conversions of tagged types are view conversions. For example the conversion in <syntaxhighlight lang="Ada"> Handle(Alert(MA));</syntaxhighlight> is a view conversion. The value passed on to the call of Handle (that with parameter of type Alert) is in fact the same value as held in MA but the components relating to the type Medium_Alert are no longer visible. And in fact the tag still relates to the underlying value and this might even be the tag for High_Alert because it could have been view converted all the way down the tree. Remember also that tagged types are passed by reference. However, if we did an assignment as in <syntaxhighlight lang="Ada"> MA := Medium_Alert(HA);</syntaxhighlight> then the tag of MA would not be changed and would not reflect that of the value in HA. All that happens is that the values of the components appropriate to the type of MA are copied from the object HA. Other components are of course ignored. Furthermore, if MA were not a locally declared variable but an out or in out parameter, then again the tag of MA would not be changed. Remember, however, that the tag of MA in this case need not itself be Medium_Alert'Tag since a formal parameter is simply giving a view of the actual parameter and the tag of that could be of any type derived from Medium_Alert. But we do know that both sides of the assignment have the components appropriate to Medium_Alert and so the assignment works. Note moreover that conversions of tagged types are allowed as the target of an assignment; thus <syntaxhighlight lang="Ada"> AC: Alert'Class := ... ... Medium_Alert(AC) := MA;</syntaxhighlight> will check that the tag of AC corresponds to Medium_Alert or a type derived from it (or in other words checks that AC in Medium_Alert'Class is true) and then copies just those components corresponding to the Medium_Alert view from the right hand side to the left hand side. It might help to summarize the golden rules * the tag of an object never changes; this applies to both specific and class-wide types, * conversion can never be away from the root, conversion never changes the tag. The fact that a view conversion does not change the tag is absolutely vital for the implementation of what is known as redispatching. There are often situations where one would like "multiple dispatch" either within a class, or between two or more classes. Ingalls cites a number of canonical examples such as displaying various kinds of graphical objects on different kinds of displays, event types and handlers, and unification and pattern matching [Ingalls 86]; he suggests a solution for Smalltalk-80 that is more modular than a single dispatch on one parameter, followed by a case statement on the dynamic type of a second parameter. Multiple dispatch is possible in Ada 95 via class-wide types. We first consider the simple case of redispatching within the same class. It often happens that after one dispatching operation we apply a further common (and inherited) operation and so need to dispatch once more to an operation of the original type. If the original tag were lost then this would not be possible. Consider again (from II.1) <syntaxhighlight lang="Ada"> procedure Handle(MA: in out Medium_Alert) is begin Handle(Alert(MA)); -- handle as plain Alert MA.Action_Officer := Assign_Volunteer; Display(MA, Console); end Handle;</syntaxhighlight> in which there is a call of the procedure Display. This call is not a dispatching call because the parameter is of a specific type (and indeed there is only one procedure Display which is inherited by all the types). As written it has been assumed that the display operation is the same for all alerts. However, suppose that in fact it was desired to express the message in different ways according to the level of the alert (in different colors perhaps or flashing). It would be possible to do this by using the Tag attribute to look at the original value of the tag by writing <syntaxhighlight lang="Ada"> procedure Display(A: Alert; On: Device) is AC: Alert'Class renames Alert'Class(A); begin if AC'Tag = Low_Alert'Tag then -- display a low alert elsif AC'Tag = Medium_Alert'Tag then -- display a medium alert else -- display a high alert end if; end Display;</syntaxhighlight> Note that we could have written <syntaxhighlight lang="Ada"> AC: Alert'Class := A;</syntaxhighlight> rather than the renaming but this would cause an unnecessary assignment. Note moreover that we cannot apply the Tag attribute to an object of a specific type; it would be rather surprising for A'Tag not to be Alert'Tag. However, using tags in this way inside the body of Display is quite inappropriate since it has reintroduced the rigid nature of variant programming and could not specifically recognize an alert which is a later extension. The proper approach is to use redispatching. If we need a different display mechanism for the different alert levels then we write distinct procedures for each one (thus overriding the procedure inherited from the root level) and then redispatch in the various procedures Handle as follows <syntaxhighlight lang="Ada"> procedure Handle(MA: in out Medium_Alert) is begin Handle(Alert(MA)); -- handle as plain Alert MA.Action_Officer := Assign_Volunteer; Display(Medium_Alert'Class(MA), Console); -- redispatch end Handle;</syntaxhighlight> This will work properly and the message will be displayed according to the specific type of the original alert. Another possibility is that the type Device might not be represented as a simple enumeration, but instead as a record type, with components representing various aspects of the device. A class of device types could be constructed using tagged types and type extension. Each kind of device must implement an Output operation that each kind of alert will use to implement its Display operation. In order to call the appropriate Output procedure two dispatching operations are involved. First, the type of the alert parameter controls the dispatch to the Display procedure, and then within that procedure a dispatch on the Device parameter will select the appropriate Output operation for the device being used as a display. This double dispatching can be accommodated by making Display a class-wide operation of the device class. The Display procedure for Alert then becomes <syntaxhighlight lang="Ada"> procedure Display(A: Alert; On: Device'Class) is begin ... Output(On); -- dispatch on On ... end Display;</syntaxhighlight> so that within each Display procedure, a call to Output, with parameter On will dispatch to the appropriate operation for the Device. Note once more that it would not have been legal for the specification of Display to have been <syntaxhighlight lang="Ada"> procedure Display(A: Alert; On: Device);</syntaxhighlight> since a procedure cannot have controlling operands of more than one tagged type. == <span id="6">4.6 Multiple Inheritance</span> == Some languages permit a derived type, or class, to have more than one parent. These languages are said to support "multiple inheritance". Multiple inheritance is a second-generation object oriented programming mechanism. It originated in MIT's FLAVORS extension to LISP; a precursor to the Common Lisp Object System. Multiple inheritance poses awkward problems if approached naively, as pointed out by [Budd 91]. There are two conceptual difficulties; what to do if an operation with a given profile belongs to both parents - which, if any, is inherited and how could we distinguish them; and what to do if the same component belongs to both parents from a common ancestor - are there two copies or only one? There are also implementation difficulties associated with these conceptual difficulties. However, most uses of multiple inheritance fall into one of three idioms each of which can be implemented in Ada 95 using facilities such as access discriminants, generic units and type composition in conjunction with the Ada 95 type extension as will be illustrated in the next few sections. Given the need to balance the benefits of language defined multiple inheritance with the complexity of the revised language, the potential for distributed overhead caused by multiple inheritance, and the scope of the revision, we chose to support multiple inheritance with a building block approach rather than an extra language construct. === <span id="6-1">4.6.1 Combining Implementation and Abstraction</span> === The first form of multiple inheritance is, to quote N. Guimaraes of AT&T, "to combine two classes, one that defines the protocol of the component, and another that provides an implementation" [Guimaraes 91]. In languages such as Eiffel and C++, where classes are the only form of module, inheritance is the most common mechanism for combining abstractions. For instance, an Eiffel class Bounded_Stack[T], could be constructed by inheriting from an abstract class Stack[T] and a second class Array[T]. Class Array[T] would then be used to implement the abstract operations not defined by class Stack[T]. The programmer must specify the implementation of each such operation, and ideally, the array operations should also be hidden from users of Bounded_Stack[T]. The effect of this idiom of multiple inheritance could be achieved in Ada 83 through type composition - inheritance is not required. In Ada, one may implement one type in terms of another, and hide that implementation as a private type. <syntaxhighlight lang="Ada"> package Bounded is type Bounded_Stack(Size: Natural := 0) is private; procedure Push(S: in out Bounded_Stack; Element: T); procedure Pop(S: in out Bounded_Stack); function Top(S: Bounded_Stack) return T; private type T_Array is array (Integer range <>) of T; type Bounded_Stack(Size: Natural := 0) is record Data: T_Array(1..Size); end record; end Bounded;</syntaxhighlight> Using the idiom of section 4.4.3 where we discussed the set abstraction, we could derive from a tagged abstract type Stack, and implement bounded stacks as arrays. In either case, the operations on Bounded_Stack must be explicitly declared, whether being defined or overridden. === <span id="6-2">4.6.2 Mixin Inheritance</span> === A second idiomatic use of multiple inheritance can be termed mixin inheritance. In mixin inheritance, one of the parent classes cannot have instances of its own and exists only to provide a set of properties for classes inheriting from it. Typically, this abstract, mixin class has been isolated solely for the purpose of combining with other classes. Ada 95 can provide mixin inheritance using tagged type extension (single inheritance) and generic units. The generic template defines the mixin. The type supplied as generic actual parameter determines the parent. Thus we can write <syntaxhighlight lang="Ada"> generic type S is abstract tagged private; package P is type T is abstract new S with private; -- operations on T private type T is abstract new S with record -- additional components end record; end P;</syntaxhighlight> where the body provides the operations and the specification exports the extended type. We can then use an instantiation of P to add the operations of T to any existing tagged type and the resulting type will of course still be in the class of the type passed as actual parameter. Note that in this idiom we have specified both the formal type and the exported type as abstract. This enables the supplied actual type to be abstract. We could declare a cascade of types in this manner thereby adding an unbounded sequence of properties to the original type. We would finally make one further extension in order to declare a type which was not abstract. As a concrete example, the following generic package adds the property of having multiple versions to any tagged type. <syntaxhighlight lang="Ada"> with OM; -- Object Manager provides unique object IDs with VM; -- Version Manager provides version control generic type Parent is abstract tagged private; package Versioned is -- A versioned object has an ID, which identifies -- the set of versions of that object, plus a version -- number that, combined with the ID, identifies an -- object uniquely. type Versioned_Object is abstract new Parent with private; -- given an object, return a new version of that object procedure Create_New_Version(O : in Versioned_Object New_O: out Versioned_Object); -- given an object, returns its version number function Version_Number(O: Versioned_Object) return VM.Version_Number; -- given an object and a version number, return that -- version of the object procedure Get_Version( ID_From: in Versioned_Object; Version: in VM.Version_Number; Object : out Versioned_Object); private type Versioned_Object is abstract new Parent with record ID : OM.Object_ID := OM.Unique_ID; Version: VM.Version_Number := VM.Initial_Version; end record; end Versioned;</syntaxhighlight> An important variation on this approach allows us to extend a type privately with generic operations that the client cannot see. This relies on the fact that the full type corresponding to a private extension need not be directly derived from the given ancestor. Thus the full type corresponding to <syntaxhighlight lang="Ada"> type Special_Object is new Ancestor with private;</syntaxhighlight> need not be directly derived from Ancestor; it could be indirectly derived from Ancestor. We can therefore write <syntaxhighlight lang="Ada"> private package Q is new P(Ancestor); type Special_Object is new Q.T with null record;</syntaxhighlight> and then the type Special_Object will also have all the components and properties of the type T in the generic package P. As written, these are, of course, not visible to the client but subprograms in the visible part of the package in which Special_Object is declared could be implemented in terms of them. Note also that the type Special_Object is not abstract even though the type Q.T is abstract. As another example of mixin inheritance reconsider the second queue package in 4.4.1. We could make it generic thus <syntaxhighlight lang="Ada"> generic type Data(<>) is abstract tagged private; package Queues is type Queue is limited private; type Queue_Element is abstract new Data with private; type Element_Ptr is access all Queue_Element'Class; function Is_Empty(Q: Queue) return Boolean; procedure Add_To_Queue(Q: access Queue; E: in Element_Ptr); function Remove_From_Queue(Q: access Queue) return Element_Ptr; Queue_Error: exception; private</syntaxhighlight> and then the modified base of the alert system could be <syntaxhighlight lang="Ada"> with Queues; package Base_Alert_System is type Root_Alert is abstract tagged null record; package Alert_Queues is new Queues(Root_Alert); subtype Alert_Queue is Alert_Queues.Queue; type Alert is abstract new Alert_Queues.Queue_Element with null record; procedure Handle(A in out Alert) is abstract; end Base_Alert_System;</syntaxhighlight> with the rest of the structure much as before. The major difference is that only alerts can be placed on an alert queue declared as <syntaxhighlight lang="Ada"> type Alert_Queue_Ptr is access all Alert_Queue; The_Queue: Alert_Queue_Ptr := new Alert_Queue; ...</syntaxhighlight> whereas previously all queues were quite general. With this formulation there is no risk of placing an alert on a queue of some other type such as animals. Thus although the queue is heterogeneous, nevertheless it is constrained to accept only objects of the appropriate class. This example also illustrates the use of a series of abstract types. We start with Root_Alert which is abstract and exists in order to characterize the queues; add the queue element property and thus export Queue_Element which is itself abstract; we then derive the abstract Alert which forms the true base of the alert system and provides the ability to declare the dispatching operation Handle. Only then do we develop specific types for the alerts themselves. Our final example shows how a window system could be constructed and illustrates the cascade of mixins mentioned above. We start with a basic window and various operations <syntaxhighlight lang="Ada"> type Basic_Window is tagged limited private; procedure Display(W: in Basic_Window); procedure Mouse_Click(W: in out Basic_Window; Where: in Mouse_Coords); ...</syntaxhighlight> and then we define a number of mixin generics of the familiar pattern such as <syntaxhighlight lang="Ada"> generic type Some_Window is abstract new Basic_Window with private; package Label_Mixin is type Window_With_Label is abstract new Some_Window with private; -- override some operations procedure Display(W: in Window_With_Label); -- add some new ones procedure Set_Label(W: in out Window_With_Label; S: in String); function Label(W: Window_With_Label) return String; private type Window_With_Label is abstract new Some_Window with record Label: String_Quark := Null_Quark; -- an X-Windows like unique ID for a string end record; end Label_Mixin;</syntaxhighlight> Note that this is slightly different to our previous examples since it can only be applied to the type Basic_Window or a type derived from Basic_Window. In the generic body we can implement the overriden and new operations, using any inherited operations as necessary. Thus the new version of Display applicable to a Window_With_Label might be <syntaxhighlight lang="Ada"> procedure Display(W: Window_With_Label) is begin Display(Some_Window(W)); -- display normally using operation of parent type if W.Label /= Null_Quark then -- now display the label if not null Display_On_Screen(XCoord(W), YCoord(W)-5, Value(W.Label)); end if; end Display;</syntaxhighlight> where the functions XCoord and YCoord are inherited from Basic_Window and give the coordinates for where to display the label. We might declare a whole series of such packages and then finally write <syntaxhighlight lang="Ada"> package Frame is type My_Window is new Basic_Window with private; ...-- exported operations private package Add_Label is new Label_Mixin(Basic_Window); package Add_Border is new Border_Mixin(Add_Label.Window_With_Label); package Add_Menu_Bar is new Menu_Bar_Mixin(Add_Border.Window_With_Border); type My_Window is new Add_Menu_Bar.Window_With_Menu_Bar with null record; end Frame;</syntaxhighlight> Observe that the final declaration has a null extension; it could add further components if required. The various operations exported from the individual mixins can be exported selectively from the package Frame by suitable renamings in the package body. === <span id="6-3">4.6.3 Multiple Views</span> === Finally, there are uses of multiple inheritance where the derived type or class is truly a derivative of more than one parent and clients of that type want to "view it" as any of its parents. This may be accomplished in Ada 95 using access discriminants which effectively enable us to parameterize one record with another. An access discriminant can be used to enable a component of a record to obtain the identity of the record in which it is embedded (see 3.4.1). This enables complex chained structures to be created and can provide multiple views of a structure. Consider <syntaxhighlight lang="Ada"> type Outer is limited private; private type Inner(Ptr: access Outer) is limited ... type Outer is limited record ... Component: Inner(Outer'Access); ... end record;</syntaxhighlight> The Component of type Inner has an access discriminant Ptr which refers back to the enclosing instance of the record Outer. This is because the attribute Access applied to the name of a record type inside its declaration refers to the current instance of the type. This is similar to the way in which the name of a task type refers to the current task inside its own body rather than to the type itself; see [RM83 9.1(4)]. If we now declare an object of the type Outer <syntaxhighlight lang="Ada"> Obj: Outer;</syntaxhighlight> then the self-referential structure created is as shown in Figure 4-3. Note that the structure becomes self-referential automatically. This is not the same as the effect that would be obtained with a record in which an instance might happen to have a component referring to itself as a consequence of an assignment. All instances of the type Outer will refer to themselves; Ptr cannot change because discriminants are constant. This simple example on its own is of little interest. However, the types Inner and Outer can both be extensions of other types and these other types might themselves be chained structures. For example, the type Inner might be an extension of some type Node containing components which access other objects of the type Node in order to create a tree. Note in particular that Inner could also be <syntaxhighlight lang="Ada"> type Inner(Ptr: access Outer'Class) is new Node with ...</syntaxhighlight> so that heterogeneous chains can be constructed. (Outer has to be tagged in this case.) The important point is that we can navigate over the tree which consists of the components of type Inner linked together but at any point in the tree we can reach to the enclosing Outer record as a whole by the access discriminant Ptr. It should be noted that an access discriminant is only allowed for a limited type. This avoids copying problems with the self-referring components and dangling references. We now return to the window example of the previous section and show how access discriminants can be used to effectively mix together two hierarchies. Suppose that as well as the hierarchy of windows which concern areas on the screen, we also have a hierarchy of monitors. <syntaxhighlight lang="Ada"> +--------------------------+ | | | | | | | | | +-------------+ | -+ +----> | | | | +- |-------------| | | | | Ptr |-----+ | | |-------------| | Component | | | | of type -| |.............| | Object Inner | | | |-- of type | |.............| | Outer | | | | +- |-------------| | | | | | | | | | | +-------------+ -+ Figure 4-3: A Self-Referential Structure</syntaxhighlight> A monitor is a type which is designed to respond to change; it has a primitive operation Update which is called to perform the response. An object that wishes to be monitored keeps a linked list of monitors and calls their Update operation whenever necessary; the chain may contain many different monitors according to what might need to be updated. If we were doing a complex modelling application concerned with molecular structure then when we change the object we might wish to redraw some representation on the screen, make a record of the previous state, recompute the molecular weight and so on. The various monitors each contain a reference to the monitored object. The type monitored object itself contains a pointer to the start of the chain and is extended with additional information as needed by the application. Thus we have <syntaxhighlight lang="Ada"> type Monitor; type Monitor_Ptr is access all Monitor'Class; type Monitored_Object is abstract tagged limited record First: Monitor_Ptr; -- list of monitors -- more components to be added by extension -- according to the needs of the specific application end record; type Monitored_Object_Ptr is access all Monitored_Object'Class; type Monitor is abstract tagged limited record Next: Monitor_Ptr; Obj: Monitored_Object_Ptr; -- more components to be added by extension -- according to the needs of the specific monitor end record; procedure Update(M: in out Monitor) is abstract; ... procedure Notify(MO: Monitored_Object'Class) is This_Mon: Monitor_Ptr := MO.First; begin while This_Mon /= null loop Update(This_Mon.all); -- dispatch for each monitor This_Mon := This_Mon.Next; end loop; end Notify;</syntaxhighlight> where Notify is a class wide operation of the type Monitored_Object and calls all the Update operations of the monitors on the chain. If our object representing the molecule has type Molecule then we would write <syntaxhighlight lang="Ada"> type Monitored_Molecule is new Monitored_Object with record M: Molecule; end record; ... Proposed_Immortality_Drug: Monitored_Molecule;</syntaxhighlight> and then perform all our work on the monitored molecule and from time to time invoke the updates by calling <syntaxhighlight lang="Ada"> Notify(Proposed_Immortality_Drug);</syntaxhighlight> The configuration might be as in Figure 4-4. <syntaxhighlight lang="Ada"> +------------------+<-----------------+ | | | | | | | +----------+ | +----------+ | +----------+ +-->| First |---+-->| Next |---+-->| | |----------| | |----------| | |----------| | The | +---| Obj | +---| | | molecule | |----------| |----------| | | | Special | | | | | | data for | | | +----------+ | this | | | | monitor | | | +----------+ +----------+ The object Two monitors on the chain Figure 4-4: A Monitor Chain</syntaxhighlight> Now suppose we want to use one of our windows as part of the updating process so that, for example, the picture of the molecule is displayed within a window rather than directly on the raw screen. In order to do this we need to hang the window display mechanism on the monitor chain so that an appropriate update causes the Display operation to be called. In other words we need to create a Window that can act as a Monitor as well as a Window. First we define a mixin that is a monitor and override its Update operation thus <syntaxhighlight lang="Ada"> type Monitor_Mixin(Win: access Basic_Window'Class) is new Monitor with null record; procedure Update(M: in out Monitor_Mixin);</syntaxhighlight> The body for this might be <syntaxhighlight lang="Ada"> procedure Update(M: in out Monitor_Mixin) is -- simply redisplay the window begin Display(M.Win.all); -- this is a dispatching call end Update;</syntaxhighlight> and now we can mix this Monitor_Mixin into any window type by writing <syntaxhighlight lang="Ada"> type Window_That_Monitors is new My_Window with record Mon: Monitor_Mixin(Window_That_Monitors'Access); end record;</syntaxhighlight> where the inner component Mon has a discriminant that refers to the outer type. The monitor component of this can now be linked into the chain as shown in Figure 4-5. Calling Notify on the monitored molecule results in the various procedures Update being called. The Update for the type Monitor_Mixin calls the Display for the type Window_That_Monitors of which it is part and this has access to all the information about the window as well as the information about being a monitor. <syntaxhighlight lang="Ada"> +-------------------+ | | | +----------+ | +--->|These | | |are the | | |components| | |for | | |My_Window | | +------------------+ | | | | | |----------| | | | | Win |---+ | +----------+ | |----------| +-->| First |---+---->| Next |----------> |----------| | |----------| | The | +-----| Obj | | molecule | +----------+ | | | | +----------+ Figure 4-5: The Window-that-Monitors in the Chain</syntaxhighlight> We could of course define a more sophisticated type Monitor_Mixin that did other things as well as simply calling the Display operation of the associated window. The examples in this and the previous section show that Ada 95 provides support for the construction of effectively arbitrary multiple inheritance hierarchies. This has been achieved without having intrinsic multiple inheritance which could be a pervasive implementation burden on simple single inheritance applications. == <span id="7">4.7 Relationship with Previous Work</span> == Object oriented programming originated with Simula [Birtwistle 73]. Simula was designed to be an almost upward compatible extension of Algol 60, inspired by the application domain of simulation, although it is really a general purpose programming language. The key insights from simulation were that it is useful to think of a complex simulation as being organized around a collection of autonomous, interacting objects, and that the construction of such simulations could be facilitated by abstracting this notion of object into a language construct. Simula introduced the notion of a class as an abstraction mechanism over objects. A class is a template for creating objects with a common data structure and operations on that data structure. These operations determine the possible behavior of the objects of the class. Operations may be sensitive to the current state of the object, and may update that state by changing the values of the data structure. A Simula class definition specifies a data structure for the class, the operations on that data, and a body used to initialize objects of the class upon their creation, like the sequence of statements in a package body. The data definition and procedure declarations constitute the class's interface to programmers. The Simula class is somewhere between a data type and a module. Instances of the class may be declared, assigned to variables, and passed as parameters, like values of a typical data type. Simula introduced a means to define new classes from old ones; a class could "inherit" from another class, deriving its structure and operations from that "parent". The new class could augment or override its inheritance, adding new data and new operations, or replacing one or more of its operations. Data could not be removed. Smalltalk [Goldberg 83] was influenced by Simula's notion of class and subclassing. While Simula was a compiled language, Smalltalk was interpreted. It was originally intended as an interactive, systems programming language for Alan Kay's Dynabook project. Smalltalk introduced the "message-passing" style of invoking operations. A message is a request to an object to invoke an operation. The set of messages that an object recognizes and is capable of responding to is called its "protocol" and is determined by the class of the object. When an object is sent a message, a search begins in the class of the object class for a method (operation definition) corresponding to the message. If not found, the search continues in the parent class (superclass), this continues upward in the class hierarchy until either an appropriate method is found or the root of the hierarchy is reached without success, in which case an error is signaled. The historical fact that some early object oriented languages were interpreted has contributed to the impression that their mechanisms are necessarily too inefficient for real-time or production use. Many object oriented languages (including Simula) also use implicit reference semantics (in which all variables are really pointers), thereby raising the issue of run-time storage management. It was these efficiency considerations that apparently prevented Ada 83 from providing inheritance and polymorphism, given Ada's overriding concerns with run- time efficiency, and type safety [Brosgol 89]. More recently, there have been a number of languages developed that support object oriented programming in a relatively safe, compiled, and efficient style, including Trellis/Owl [Schaffert 86], Eiffel [Meyer 88], Modula-3 [Nelson 91] and C++ [Ellis 90]. The essence of the evolution of OOPLs has thus been to obtain an appropriate balance between compile-time and run-time identification of the operations to be performed. If the identification is at run-time then the operations are usually called methods; alternative terms are virtual functions (C++, Simula) and dispatching operations (the Ada 95 term). In Smalltalk-80, for example, method invocations have the form <syntaxhighlight lang="Ada"> receiver Methodname Argstomethod</syntaxhighlight> where receiver is the name of the target object. This syntax simplifies dispatch; the dispatch is determined solely by the class of the receiver of the message. Eiffel and C++ also use the "distinguished receiver" approach. In languages where a function or procedure call syntax is permitted, and where more than one argument of the call may be of the class, the situation is more complex. Trellis/Owl [Schaffert 86]) follows the Smalltalk-80 tradition and arbitrarily designates the first parameter of the call as determining the dispatch. Some languages distinguish this parameter by its appearance as a prefix in the call. Other possible schemes include # All controlled parameters within the class must share the same type tag. # The programmer must select a parameter as the controlling one, as a part of the declaration of the parameter's mode. # All controlled parameters must share the same code for the operation (their dispatch tables must all point to the same code body for that operation). # The most specific type within the class ("nearest ancestor") applicable to all of the parameters is used. # The most general type within the class ("furthest ancestor", the root) applicable to all of the parameters is used. Ada 95 has adopted (1). This is a logical choice, given that the dispatching operations of a type are the primitive operations of that type and are derived from those of the root type with systematic replacement. So, in Ada 95, more than one operand, or even the result, may control the dispatch. For a primitive operation of a type T, the dispatching is controlled by the operands of type T, and the result if it is of type T. There are a number of other important differences between Ada 95 and other languages; these differences are designed to add clarity (which encourages programmers to write the correct code) and safety (which prevents disaster if they do not). The first difference is that in Ada 95, an operation is only dispatching when applied to an actual parameter of a class-wide type. In other OOPLs, a dispatch is possible whenever an object reference or pointer is used as the prefix to the operation. In Ada 95 terms, this means that references/pointers in such OOPLs are always treated as though they designate a class-wide type. Ada 95 allows a formal parameter or an access value to have a specific type as its "referent" (this is the default, preserving upward compatibility and safety). Ada 95 also allows an actual parameter or an access value to have a class-wide type as its referent, in which case dispatching is also possible. A second difference is that, in Ada 95, if a type T is tagged, then all of its primitive operations are dispatching operations; when passed a class-wide operand, they dispatch. In C++, only those particular member functions identified as virtual involve a run-time dispatch. In Ada 95, a (non-dispatching) class-wide operation may be defined by explicitly declaring it with a formal parameter of type T'Class. No dispatch is performed in this case, because the body of a class-wide operation expects its actual parameter to still be class-wide. Note that, as in C++, a run-time dispatch may ultimately occur, when such an operation calls a dispatching operation somewhere within its body. This is illustrated by the procedure Process_Alerts in II.2. A final and important difference between Ada 95 and some other OOPLs is that dispatching is safe in the sense that a call to a dispatching operation always has a well-defined implementation to dispatch to. In some OOPLs, such as Smalltalk, it is possible to send a message to an object that has no method for handling that message; a run-time error results. In Ada, such errors are always detected at compile time. When a primitive operation is called with class-wide operands in all controlling positions, a run-time check is made that all of these controlling operands have the same tag value, and the result is defined to return this same tag value. This common tag value is called the controlling tag value for the call, and identifies the specific type whose corresponding primitive operation is used to implement this call. This requirement that all controlling operands have the same tag value reflects an existing Ada 83 rule for derived types. The type of all operands of a parent type are systematically replaced with the derived type when inheriting a primitive operation. A primitive operation can only be a primitive operation of one tagged type. It is possible but unusual for a primitive operation to also operate on another type within the same class (but it would not be primitive for that other type). Typically, each primitive operation operates only on one type within the class, and may return this same type. By treating all controlling operands symmetrically, we avoid some of the difficulties and anomalies encountered in other OOPLs with binary operations. For example, taking the intersection of two sets is viewed as a symmetric operation as opposed to thinking of one set as being special (the "receiver"), with the other set being a mere argument. By allowing the result context to control the dispatch, we allow parameterless functions to be used to represent type-specific literals, like an empty set in a tagged set class. See the discussion on the procedure Convert in 4.5. There is no need to use run-time dispatch when a controlling operand or result has a statically known specific type. (A mixture of static and dynamically determined tags is not allowed.) In this case, the specific type's implementation of the primitive operation is then called directly (this is effectively a case of "static" binding). As discussed in 4.3, the canonical implementation model for a type tag is a pointer to a run-time type descriptor, containing pointers to subprogram bodies implementing each of the primitive operations. This implementation model means that the call on a dispatching operation involves only tag-equality checks (if there is more than one controlling operand), and then a call through the appropriate subprogram pointer. The overhead for such a call is bounded, and can be kept to two or three instructions in most cases, ensuring that dispatching operations can be used even in demanding real-time applications. Note that this overhead is typically less than the overhead of using case statements and variant records. For a tagged type T, even the implicitly provided operations (such as Object'Size and assignment if nonlimited) use dispatching internally when applied to a class-wide operand, to allow for new components that might be added by type extension. Generally, for each primitive operation of a parent type, a type extension may either inherit the original implementation, or it may override it. For an operation that had an operand of the parent type, if not overridden it becomes an operation with an operand of the type extension, which simply ignores (and does not affect) the extension part of the operand. However, for an operation that returned a result of the parent type, if not overridden, it becomes an abstract operation that has no implementation for the extension. This is because the extension part of the result would not be defined for such an operation. Abstract operations allow a type to have a specification for an operation but no implementation for it, effectively requiring that each derivative define its own. Such operations have no default implementation, preventing a derivative from mistakenly inheriting a meaningless implementation. Abstract operations correspond to deferred methods or virtual methods in Smalltalk and C++. The corresponding class is called an abstract superclass. If a tagged type has an abstract primitive operation, then it must be declared as an abstract type, and no objects with a tag identifying that type may be created. This means that a call to an abstract operation will always dispatch to some non-abstract implementation that is defined for some derivative. No run-time check is needed to detect whether an operation is abstract, because no objects with the tag for an abstract type can ever be created. To conclude, the model of type extension and polymorphism in Ada 95 combines efficiency of implementation, clarity of program text and security in a cohesive manner. It provides the additional flexibility sought in an object oriented language without compromising the security which was the cornerstone of Ada 83. == <span id="8">4.8 Requirements Summary</span> == The three major study topics * S4.1-A(1) - Subprograms as Objects * S4.3-A(1) - Reducing the Need for Recompilation * S4.3-B(1) - Programming by Specialization/Extension are directly addressed and satisfied by the facilities discussed in this chapter. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-3|Previous]] | [[Guide:9x_rationale/rat95-p2-5|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=4 Object Oriented Programming}} a70a1zkh2azwbk6j4r6d4gawqzgici0 Guide:9x rationale/rat95-p2-5 4200 339 1863 1844 2019-04-20T16:20:26Z WikiVisor 11 Text replacement - "[[Guide:9x_rationale/rat95-copyright|Copyright]] | " to "<div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | " wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-4|Previous]] | [[Guide:9x_rationale/rat95-p2-6|Next]]</div> There is naturally very little change in this classical area of the language. The only additional statement is the requeue statement and that is addressed in Chapter 9. There are also additional forms of the delay and select statements and these are also discussed in Chapter 9. The mechanism of assignment including user-defined assignment is closely associated with controlled types and these are discussed in 7.4. The return statement is now moved to Chapter 6 where it properly belongs. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-4|Previous]] | [[Guide:9x_rationale/rat95-p2-6|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=5 Statements}} 8azyn5mfu74dyvyp57pcfyi03wd59v0 Guide:9x rationale/rat95-p2-6 4200 340 1892 1891 2019-04-20T16:34:06Z WikiVisor 11 wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-5|Previous]] | [[Guide:9x_rationale/rat95-p2-7|Next]]</div> Perhaps the most important change to subprograms and their use in Ada 95 is the fact that they are more nearly first class types since they may be manipulated as the target of access types. However, this topic is dealt with in Chapter 3 and we concern ourselves here with other relatively minor improvements to subprograms. These are * Various aspects of the parameter and result mechanism are improved. The notions of by-copy and by-reference parameters are made more formal. Parameters of mode out may now be read. Subprograms may have parameters of mode out for a limited view of a type. * A parameter may also be of an anonymous access type. * A subprogram body may now be provided by renaming; this and other changes increases the categories of conformance rules. * The rules for new overloadings of "=" and "/=" are relaxed. Other related matters are the calling conventions for interfacing with other languages; these are discussed in Part Three. Abstract subprograms are discussed in Chapter 3. == <span id="1">6.1 Parameter and Result Mechanism</span> == For Ada 95, we define by-copy parameter passing in terms of a subtype conversion and an assignment. This minimizes the number of special rules associated with parameter passing. For by-reference parameters, the formal parameter is considered a view of the actual. Certain types are called by-copy types and are always passed by copy. Some other types are called by-reference types and are always passed by reference. For the remaining types the implementation is free to choose either mechanism. Note that the parameter mechanism is independent of the view; thus a private type is always passed by the mechanism appropriate to the full view of the type. Note that tagged types, task types and protected types are by- reference types. A similar approach is taken with function results. Certain types are classified as return-by-reference types. Again these include task types and protected types (and most other limited types, see 7.3). In the case of a result returned by reference the function call denotes a constant view of the object denoted by the return expression. In other cases a copy is made. Remember that the result of a function call is treated as an object in Ada 95. A difference between parameters and results is that tagged types are always by reference as parameters but only returned by reference if limited. For all modes and both mechanisms of parameters and for results, a subtype conversion is performed if necessary (to provide sliding). Note in particular that sliding is used for array parameters and results whereas Ada 83 required the more restrictive exact matching of bounds. An array aggregate with others is still allowed as a parameter or as a result and with the same meaning although for different reasons. In Ada 83 it was allowed because the matching rules provide the bounds whereas in Ada 95 it is allowed because the rules for others in assignment are relaxed but there is the overriding rule that aggregates with others never slide. In Ada 95 it is not erroneous to depend on the parameter passing mechanism (by-reference versus by-copy) for those types that allow both, though it is nonportable. This is an example of reducing totally unpredictable behavior (see 1.3). === <span id="1-1">6.1.1 Out Parameters</span> === In Ada 83 a formal parameter of mode out could not be read, even after being initialized within the procedure. This forced certain algorithms to include a local variable just to accumulate a result and which was then assigned to the out parameter. Introducing such a local variable is error prone, because the final assignment may be mistakenly omitted. Similarly, if an out parameter is passed to a second procedure to be filled in, the value returned cannot be checked prior to returning from the first procedure. For Ada 95, we have removed the restrictions on the use of out parameters. Specifying that a formal parameter is of mode out indicates that the caller need not initialize it prior to the call. However, within the procedure, once the parameter has been initialized, it may be read and updated like any other variable. As with a normal variable, it is an error to depend on the value of an out parameter prior to its being initialized. The added simplicity and flexibility provided by removing the restrictions on reading an out parameter allows many of the special cases associated with out parameters to be eliminated, including the restriction regarding their use with limited types. Safety is preserved by ensuring that a subcomponent does not become "deinitialized" by being passed as an out parameter. If any subcomponent of a type passed by copy has default initialization, then the whole object is copied in at the start of the call so that the value of such a subcomponent is not lost as a result of a subprogram call during which no assignment is made to the subcomponent. But in practice records are usually passed by reference anyway. === <span id="1-2">6.1.2 Access Parameters</span> === A formal in parameter may be specified with an access definition. Such a parameter is of a general access type that is totally anonymous (has no nameable subtypes), but is convertible to other general access types with the same designated subtype. Access parameters are valuable because they allow dispatching on access values; they are also convenient for use with access discriminants; see 3.7.1. Access parameters are often an alternative to in out parameters especially for tagged types. Thus suppose we have a tagged type and an access type referring to it and appropriate variables such as <syntaxhighlight lang="Ada"> type T is tagged record ... type Access_T is access T; Obj: T; Obj_Ptr: Access_T := new T'(...);</syntaxhighlight> plus subprograms taking parameters thus <syntaxhighlight lang="Ada"> procedure P(X: in out T); procedure PA(XA: access T);</syntaxhighlight> then within the body of both P and PA we have read and write access to the components of the record. Indeed because of automatic dereferencing the components are referred to in the same way. And since tagged types are all always passed by reference and never by copy, the effect is much the same for many situations. For example dispatching is possible in both cases. However, there are a number of important differences. In the case of the in out parameter, the actual parameter could be Obj or Obj_Ptr.all thus <syntaxhighlight lang="Ada"> P(Obj); P(Obj_Ptr.all);</syntaxhighlight> whereas in the case of the access parameter, the actual parameter has to be Obj'Access or Obj_Ptr. Moreover in the former case the variable Obj must be marked as aliased <syntaxhighlight lang="Ada"> Obj: aliased T; PA(Obj'Access); PA(Obj_Ptr);</syntaxhighlight> Remember also that an actual parameter corresponding to an access parameter cannot be null. Moreover, accessibility checks for access parameters are dynamic and the parameter carries with it an indication of its accessibility. A vital difference is that a function cannot have an in out parameter and so an access parameter is essential if we need a function. We recall from 4.4.1 that the alternative of a procedure with an out parameter corresponding to the function result is not possible in some cases such as where the result type is class wide and we do not know the anticipated specific type. Other important considerations occur if we have a sequence of nested calls. Thus suppose we have other procedures Q and QA and that in their bodies we wish to call the procedures P and PA with the parameter passed on. There are four possible combinations of calls to consider. We have <syntaxhighlight lang="Ada"> procedure Q(X: in out T) is begin P(X); -- in out passed on to in out ... PA(X'Access); -- in out passed on to access end Q; procedure QA(XA: access T) is begin P(XA.all); -- access passed on to in out ... PA(XA); -- access passed on to access end QA;</syntaxhighlight> All of these calls are legal. The call of PA from within Q is legal because formal parameters of a tagged type are considered aliased and treated just like an aliased local variable. Hence X'Access is allowed but the accessibility level is that of a variable local to Q. This means that the accessibility level passed to PA indicates that Q.X is local to Q and will not reflect the accessibility level of the original actual parameter passed to Q (and of course that information was not passed to Q anyway). In the reverse situation where QA calls P no accessibility information is passed on. Moreover, it should be noted that the parameter XA.all creates a view of the original parameter and this view is passed on; no local object is created. Thus the information passed on is simply the original "reference" minus the accessibility information. The uniform cases where Q calls P or QA calls PA are straightforward. The parameter is passed on unchanged, in the first case there is no accessibility information and in the second it is passed on intact. There is a lot of merit in using access parameters because they pass the correct accessibility level and avoid the risk of an illegal program or unexpectedly raising Program_Error when attempting a conversion to a named access type. For example, assuming T and Access_T are declared at the same level as the procedures and that Q and QA are called with actual parameter Obj or Obj'Access respectively, then it would be illegal to write <syntaxhighlight lang="Ada"> Obj_Ptr := Access_T(X'Access);</syntaxhighlight> inside Q since the static accessibility check fails, whereas it is legal to write the corresponding <syntaxhighlight lang="Ada"> Obj_Ptr := Access_T(XA);</syntaxhighlight> inside QA, and the dynamic accessibility check succeeds. Furthermore if we also had a procedure <syntaxhighlight lang="Ada"> procedure RA(XA: access T) is begin ... Obj_Ptr := Access_T(XA); ... end RA;</syntaxhighlight> in which a similar conversion is performed, then calling RA from Q by <syntaxhighlight lang="Ada"> RA(X'Access);</syntaxhighlight> results in raising Program_Error on the attempted conversion in RA whereas calling RA from QA by <syntaxhighlight lang="Ada"> RA(XA);</syntaxhighlight> works successfully because the original accessibility level is preserved. However, remember that we can always use Unchecked_Access which avoids the accessibility checks. This would overcome the difficulties in the above examples but of course the use of Unchecked_Access in general can result in dangling references; the responsibility lies with the user to ensure that this does not happen. For a further discussion on access parameters and a comparison between them and parameters of a named access type see 3.7.1. == <span id="2">6.2 Renaming of Bodies and Conformance</span> == In Ada 95, we allow a subprogram body to be provided by renaming another subprogram. This is a great convenience in those many cases in Ada 83 where the programmer was forced to provide a body which simply called some other existing subprogram. In order that the implementation can be just a jump instruction, the subprogram specification must be "subtype conformant" with the body used to implement it. Subtype conformance is required because the caller sees only the subprogram specification, and therefore has prepared the parameters, performed constraint checks, and followed the parameter passing conventions determined by the specification. Several different rules existed in Ada 83 governing matching between subprogram specifications. For the purposes of hiding the name of the subprogram, only the types of the formal parameters and the result, if any, were relevant (see [RM83 8.3(15)]). For renaming and generic instantiation, the modes also had to match (see [RM83 8.5(7)] and [RM83 12.3.6(1)]). Between a specification and its body, syntactic equivalence was required ([RM83 6.3.1(5)]). For Ada 95, in order to support access to subprogram types, and to support the provision of a body by a renaming, an intermediate level of matching is needed. This intermediate level requires static subtype matching, but allows formal parameter names and defaults to differ. To improve the presentation in Ada 95, the descriptions of these various levels of subprogram matching are gathered into the section on Conformance Rules [RM95 6.3.1]. Each level of matching is given a name and they can be arranged in a strictly ascending order of strength as follows * Type conformance. This is the matching that controls hiding. * Mode conformance. This is the matching required for renaming and generic formal subprograms. * Subtype conformance. This is the matching required for access to subprogram types, and for specifying a body via renaming. * Full conformance. This is the matching required between the declaration and body of a subprogram, and between multiple specifications of a discriminant part. In addition to centralizing these definitions, we have also relaxed the full conformance rules, in order to make them represent static semantic equivalence, rather than syntactic equivalence. This has the effect of eliminating certain anomalies (such as the non-transitivity of Ada 83 conformance), as well as being more natural for the programmer and easier to implement. == <span id="3">6.3 Overloading of Equality and Inequality Operators</span> == In Ada 83, the "=" operator could be explicitly defined only for limited types (other than via a devious method based on a curious loophole in generic instantiation). This restriction was justified largely on methodological grounds. However, experience with Ada has illustrated several circumstances where it is very natural to provide a user-defined equality operator for nonlimited types. For example, within a three- value logic abstraction, "=" should return either True, False, or Unknown. For vector processing, it is natural to define a component-wise "=" operator for vectors, producing a vector of Boolean values as the result. In such cases, it is also important to be able to explicitly define "/=", since it is not the simple Boolean complement of "=". In Ada 95, we allow "=" to be treated like any other relational operator. But note that when the result type of a user-defined "=" operator is Standard.Boolean, a complementary definition for "/=" is automatically provided. Explicit definitions for "/=" are also permitted, so long as the result type is not Standard.Boolean. A "/=" operator with a result type of Standard.Boolean may thus become defined only as an implicit side-effect of a definition for "=". Of course, dispatching can occur on "=". For example in the procedure Convert in 4.4.3, the comparison in <syntaxhighlight lang="Ada"> while Temp /= Empty loop</syntaxhighlight> dispatches. Typically the equality will be predefined but of course it might not be. == <span id="4">6.4 Requirements Summary</span> == Many of the changes in this chapter are consequences of the general requirement * R2.2-C(1) - Minimize Special Case Restrictions discussed in [DoD 90 A.3]; this lists three examples which have been met by this chapter. They are the ability to redefine "=", the ability to read out parameters and the use of sliding (array subtype conversion). <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-5|Previous]] | [[Guide:9x_rationale/rat95-p2-7|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=6 Subprograms}} bbjtbu5uftwt0kqw5d4gaeu6fgbuemg Guide:9x rationale/rat95-p2-7 4200 341 1843 1811 2019-04-20T16:19:31Z WikiVisor 11 Text replacement - "[[Guide:9x_rationale/rat95-copyright|Copyright]] | " to "<div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | " wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-6|Previous]] | [[Guide:9x_rationale/rat95-p2-8|Next]]</div> There are a number of important changes to the language addressed in this chapter. Many of these are associated with tagged types such as the addition of private extensions. Another important change is the introduction of controlled types which are implemented using tagged types. In summary the changes are * A private type may be marked as tagged. The rules regarding private types and discriminants are considerably relaxed. * Private extensions are introduced in order to allow type extension of tagged types where the extension part is private. * A deferred constant can be of any type, not just a private type. * The property of being limited is now separated from that of being private. They are both view properties. * Controlled types are added. These permit finalization and the user definition of assignment. An important change regarding library packages is that they can have a body only when one is required; this is discussed in 10.4. == <span id="1">7.1 Private Types and Extensions</span> == To allow for the extension of private types, the modifier tagged may be specified in a private type declaration. A tagged private type must be implemented with a tagged record type, or by deriving from some other tagged type. We considered allowing a tagged private type to be derived from an untagged type. However, this added potential implementation complexity because the parent type might not have a layout optimized for referencing components added in later extensions. There is a simple work-around; the tagged private type can be implemented as a tagged record type with a single component of the desired parent type. In Ada 95, we consider a private type to be a composite type outside the scope of its full type declaration. This is primarily a matter of presentation. Although a private tagged type must be implemented as a tagged type, the reverse is not the case. A private untagged type can be implemented as a tagged or untagged type. In other words if the partial view is tagged then the full view must be tagged; if the partial view is untagged then the full view may or may not be tagged. We thus have to be careful when saying that a type is tagged, strictly we should talk about the view being tagged. The relationship between the full and partial view of a type is discussed further in 7.3 when we also consider limited types. A good example of the use of a tagged type to implement a private type which is not tagged is given by the type Unbounded_String in the package Ada.Strings.Unbounded. The sample implementation discussed in A.2.6 shows how Unbounded_String is controlled and thus derived from Finalization.Controlled. We have generalized discriminants so that a derived type declaration may include a discriminant part. Therefore, it is now permissible for a private type with discriminants to be implemented by a derived type declaration. This was not possible in Ada 83. In addition, a discriminant part may be provided in a task or protected type declaration. As a consequence, a limited private type with discriminants may be implemented as a task or protected type. Another improvement mentioned in II.12 is that a private type without discriminants may now be implemented as any definite type including a discriminated record type with defaulted discriminants. A tagged (parent) type may be extended with a private extension part. This allows one type to visibly extend another, while keeping the names and types of the components in the extension part private to the package where the extension is defined. For a private extension in the visible part, a corresponding record extension must be defined in the private part. Note that the record extension part may be simply <syntaxhighlight lang="Ada"> with null record</syntaxhighlight> which uses an abbreviated form of syntax for null records. This abbreviated form was introduced precisely because null extensions are fairly common. An extension aggregate is only allowed where the full view of the extended type is visible even if the extension part is null. Note that a private extension may always be (view) converted to its parent type. See also 3.6.1 for the case where the ancestor part is abstract. The interplay between type extension and visibility is illustrated by the following somewhat contrived example <syntaxhighlight lang="Ada"> package P1 is type T is tagged record A: Type_A; end record; type T1 is new T with private; private type T1 is new T with record B: Type_B; end record; end P1; with P1; use P1; package P2 is type T2 is new T1 with record C: Type_C; end record; end P2; with P2; use T2 package body P1 is X1: T1; -- can write X1.B X2: T2; -- cannot write X2.B XX: T1 renames T1(X2); ... XX.B := -- changes B component of X2 end P1;</syntaxhighlight> The type T has a component A. The type T1 is extended from T with the additional component B but the extension is not visible outside the private part and body of P1. The type T2 is in turn extended from T1 with a further component C. However, although T2 has a component B it is not visible for any view of T2, since the declaration of T2 sees only the partial view of its parent T1. So the B component of T2 is not visible in the package body P1 even though that component of its parent is indeed visible from there. But of course we can do a view conversion of an object of the type T2 and then obtain access to the component B provided we are at a place that has the full view of T1. It is important that the invisible B component of T2 be invisible for all views since otherwise we would run into a problem if the additional component of T2 were also called B (this is allowed because the existing B component is not visible at the point where the additional component is declared and the potential clash could not be known to the writer of P2). But if there were a view such that all components of T2 were visible (such as perhaps might be expected in the body of P1) then X2.B would be ambiguous. The important general principle is that the view we get of a type is the view relating to the declaration of it that is visible to us rather than simply where we are looking from. === <span id="1-1">7.1.1 Private Operations</span> === A tagged type may have primitive operations declared in a private part. These operations will then not be available to all views of the type although nevertheless they will always be in the dispatch table. We noted in 3.6.2 that an abstract type can never have private abstract operations. A private operation can be overridden even if the overriding operation actually occurs at a place where the private operation is not visible. Consider <syntaxhighlight lang="Ada"> package P is type A is tagged ...; private procedure Op(X: A); end P; package P.Child is type B is new A with ...; procedure Op(X: B); private -- the old Op would have been visible here end P.Child;</syntaxhighlight> The type A has a private dispatching operation Op. The type B is an extension of A and declares an operation Op. This overrides the private inherited operation of the same name despite the fact that the private operation is not visible at the point of the declaration of the new operation. But the key point is that within the private part of the child package, the old Op would have become visible and this is still within the region where it is possible to add primitive operations for B. It is not possible for both operations to be primitive and visible at the same place and it would be impossible for them to share the same slot in the dispatch table. Accordingly the new operation overrides the old. Moreover, they must conform. For a practical example see 13.5.1. On the other hand if the new operation is declared at a point such that the visibility of the two never clash in this way such as in the following <syntaxhighlight lang="Ada"> package P is type A is tagged ...; procedure Curious(X: A'Class); private procedure Op(X: A); -- first one end P; with P; use P; package Outside is type B is new A with ...; procedure Op(X: B); -- second one end Outside;</syntaxhighlight> then the two operations do not clash and occupy different slots in the dispatch table. Moreover they need not conform since they are quite independent. So in fact B does actually have both operations; it inherits the private one from A and has its own different one. We will dispatch to one or the other according to how a dispatching call is made. The first one is of course a dispatching operation of A'Class whereas the second is a dispatching operation of B'Class. The procedure Curious might be <syntaxhighlight lang="Ada"> procedure Curious(X: A'Class) is begin Op(X); -- dispatch to first Op end Curious;</syntaxhighlight> and then <syntaxhighlight lang="Ada"> Object: B; ... Curious(Object);</syntaxhighlight> will call the inherited hidden operation of B which will apply itself to the part of B inherited from A. This hidden operation is of course just that inherited from A; it cannot be changed and hence can know nothing of the additional components of B. Note further that we could declare a further type extension from B at a place where the operation of A is also visible. This could be in the private part of a child of P or in a package inner to the body of P. For example <syntaxhighlight lang="Ada"> with Outside; use Outside; package P.Child is private type C is new B with ...; end P.Child;</syntaxhighlight> In such a case C inherits both operations from B in the sense that they both occupy slots in the dispatch table. But again the operation acquired indirectly from A is totally invisible; it does not matter that the operation of A is visible at this point; all that matters is that C cannot see the corresponding operation of B. This is another example of the principle mentioned at the end of the previous section that the view we get of a type is the view relating to the declaration of it that is visible to us rather than where we are looking from; or in other words the history of how B got its operations is irrelevant. == <span id="2">7.2 Deferred Constants</span> == In Ada 83, deferred constants were only permitted in the visible part of a package and only if their type was private and was declared in the same visible part [RM83 7.4(4)]. In Ada 95, this restriction is relaxed, so that a deferred constant of any type may be declared immediately within the visible part of a package, provided that the full constant declaration is given in the private part of the package. This eliminates the anomaly that prevented a constant of a composite type with a component of a private type from being declared, if the composite type was declared in the same visible part as the private type. Another advantage of deferred constants is that in some cases, the initial value depends on attributes of objects or types that are declared in the private part. For example, one might want to export an access to constant value designating a variable in the private part. This prevents the external user from changing the value although the package of course can change the value. This is another example of having two different views of an entity; in this case a constant view and a variable view. <syntaxhighlight lang="Ada"> type Int_Ptr is access constant Integer; The_Ptr: constant Int_Ptr; -- deferred constant private Actual_Int: aliased Integer; -- is a variable so we do not need an initial value The_Ptr: constant Int_Ptr := Actual_Int'Access; -- full definition of deferred constant</syntaxhighlight> Note that a deferred constant can also be completed by an Import pragma thereby indicating that the object is external to the Ada program. See Part Three for details. A small point regarding deferred constants is that they no longer have to be declared with just a subtype mark; a subtype indication including an explicit constraint is allowed. Such a constraint must statically match that in the full constant declaration. == <span id="3">7.3 Limited Types</span> == As in Ada 83, a limited type is one for which assignment is not allowed (user-defined assignment is not allowed either, see 7.4). However, the property of being limited is no longer tied to private types. Any record type can be declared as limited by the inclusion of limited in its definition. Thus the type Outer in 6.4.3 is limited. Task and protected types are also limited and a type is limited if it has any components that are limited. Only a limited type can have access discriminants. Finally, a derived type is limited if its parent is limited. Limited is a sort of view property in that whether a type is limited or not may depend upon from where it is viewed. This is obvious with a limited private type where the full view might not be limited. However, it can occur even in the nonprivate case. Consider <syntaxhighlight lang="Ada"> package P is type T is limited private; type A is array (...) of T; private type T is new Integer; -- at this point A becomes nonlimited end P;</syntaxhighlight> where the type A starts off being limited because its components are limited. However, after the full declaration of T, its components are no longer limited and so A becomes nonlimited. Note that in the case of a tagged type, it must have limited in its definition (or that of its ancestor) if it has limited components. This prevents a tagged type from the phenomenon of becoming nonlimited. Otherwise one might extend from a limited view with a limited component (such as a task) and then in the full view try to do assignment as in the following variation of the previous example. <syntaxhighlight lang="Ada"> package P is type T is limited private; type R is tagged -- illegal, must have explicit limited record X: T; end record; private type T is new Integer; -- at this point R would become nonlimited end P; package Q is type T2 is new R with record A: Some_Task; end record; end Q;</syntaxhighlight> The problem is that the body of P would see a nonlimited view of T and hence assignment would be defined for T'Class and so it would be possible to do an assignment on the type T2 by a dispatching operation in the body of P. So, in the case of a tagged private type (that is a type for which both partial and full views are tagged), both partial and full views must be limited or not together; it is not possible for the partial view to be limited and the full view not to be limited. On the other hand if the partial view is untagged and limited then the full view can be any combination including tagged and nonlimited. The various possibilities are illustrated in Table 7-1; only those combinations marked as OK are legal. <syntaxhighlight lang="Ada"> +----------------------------------------------------------+ | | partial view | | full view | untagged | tagged | | | limited |nonlimited| limited |nonlimited| +-----------------------------------------------+----------+ | untagged | O | | | | | limited | K | | | | |--------------+----------+----------+----------+----------| | untagged | O | O | | | | nonlimited | K | K | | | |--------------+----------+----------+----------+----------| | tagged | O | | O | | | limited | K | | K | | |--------------+----------+----------+----------+----------| | tagged | O | O | | O | | nonlimited | K | K | | K | +----------------------------------------------------------+ Table 7-1: Full and Partial Views</syntaxhighlight> A consequence of the rules is that, in the case of type extension, if the parent type is not limited, then the extension part cannot have any limited components. (Note that the rules regarding actual and formal generic parameters are somewhat different; the actual type corresponding to a formal limited tagged type does not have to be limited. This is because type extension is not permitted in the generic body.) There was a pathological situation in Ada 83 whereby a function could return a local task (all one could do with it outside was apply the attributes Terminated and Callable); this was a nuisance because all the storage for the local task could not be properly relinquished on the return. In Ada 95 there is an accessibility check that prevents such difficulties. In essence we are not allowed to return a local object of a limited type (there are some subtle exceptions for which see [RM95 6.5]). An important consequence of a function result being treated as an object is that it can be renamed. This means that we can "remember" the result of a function even in the case of a limited type. For example, the function Text_IO.Current_Output returns the current default output file. In Ada 83 it was difficult to remember this and then reset the default value back after having used some other file as current output in the meantime; it could be done but only with a contorted use of parameters. In Ada 95 we can write <syntaxhighlight lang="Ada"> Old_File: File_Type renames Current_Output; ... Set_Output(Old_File);</syntaxhighlight> and the renaming holds onto the object which behaves much as an in parameter. But see also Part Three for a more general solution to the problem of remembering a current file. == <span id="4">7.4 Controlled Types</span> == To preserve abstraction, while providing automatic reclamation of resources, Ada 95 provides controlled types that have initialization and finalization operations associated with them. A number of different approaches were considered and rejected during the evolution of Ada 95. The final solution has the merit of allowing user-defined assignment and also solves the problem of returning limited types mentioned in the previous section. The general principle is that there are three distinct primitive activities concerning the control of objects * initialization after creation, * finalization before destruction (includes overwriting), * adjustment after assignment. and the user is given the ability to provide appropriate procedures which are called to perform whatever is necessary at various points in the life of an object. These procedures are Initialize, Finalize and Adjust and take the object as an in out parameter. To see how this works, consider <syntaxhighlight lang="Ada"> declare A: T; -- create A, Initialize(A) begin A := E; -- Finalize(A), copy value, Adjust(A) ... end; -- Finalize(A)</syntaxhighlight> After A is declared and any normal default initialization carried out, the Initialize procedure is called. On the assignment, Finalize is first called to tidy up the old object about to be overwritten and thus destroyed, the physical copy is then made and finally Adjust is called to do whatever might be required for the new copy. At the end of the block Finalize is called once more before the object is destroyed. Note, of course, that the user does not have to physically write the calls of the three control procedures, they are called automatically by the compiled code. In the case of a nested structure where inner components might themselves be controlled, the rules are that components are initialized and adjusted before the object as a whole and on finalization everything is done in the reverse order. There are many other situations where the control procedures are invoked such as when calling allocators, evaluating aggregates and so on; for details the reader should consult [RM95]. In order for a type to be controlled it has to be derived from one of two tagged types declared in the library package Ada.Finalization whose specification is given in [RM95 7.6] and which is repeated here for convenience <syntaxhighlight lang="Ada"> package Ada.Finalization is pragma Preelaborate(Finalization); type Controlled is abstract tagged private; procedure Initialize(Object: in out Controlled); procedure Adjust(Object: in out Controlled); procedure Finalize(Object: in out Controlled); type Limited_Controlled is abstract tagged limited private; procedure Initialize(Object: in out Limited_Controlled); procedure Finalize(Object: in out Limited_Controlled); private ... end Ada.Finalization;</syntaxhighlight> There are distinct abstract types for nonlimited and limited types. Naturally enough the Adjust procedure does not exist in the case of limited types because they cannot be copied. Although the types Controlled and Limited_Controlled are abstract, nevertheless the procedures Initialize, Adjust and Finalize are not abstract. However they all do nothing which will often prove to be appropriate. A typical declaration of a controlled type might take the form <syntaxhighlight lang="Ada"> type T is new Controlled with ...</syntaxhighlight> and the user would then provide new versions of the controlling procedures as required. Note incidentally that the form of an extension aggregate mentioned in 3.6.1 where the ancestor part is a subtype name is useful for controlled types since we can write <syntaxhighlight lang="Ada"> X: T := (Controlled with ...);</syntaxhighlight> whereas we cannot use an expression as the ancestor part because its type is abstract. The capabilities provided take a building block approach and give the programmer fine control of resources. In particular they allow the implementor of an abstraction to ensure that proper cleanup is performed prior to the object becoming permanently inaccessible. The ability to associate automatic finalization actions with an abstraction is extremely important for Ada, given the orientation toward information hiding, coupled with the many ways that a scope may be exited in Ada (exception, exit, return, abort, asynchronous transfer of control, etc). In many cases, the need for finalization is more of a safety or reliability issue than a part of the visible specification of an abstraction. Most users of an abstraction should not need to know whether the abstraction uses finalization. A related observation concerns the use of controlled types as generic parameters. We can write a package which adds some properties to an arbitrary controlled type in the manner outlined in 4.6.2. Typically we will call the Finalize of the parent as part of the Finalize operation of the new type. Consider <syntaxhighlight lang="Ada"> generic type Parent is abstract new Limited_Controlled with private; package P is type T is new Parent with private; ... private type T is new Parent with record -- additional components end record; procedure Finalize(Object: in out T); end P; package body P is ... procedure Finalize(Object: in out T) is begin ... -- operations to finalize the additional components Finalize(Parent(Object)); -- finalize the parent end Finalize; end P;</syntaxhighlight> This will always work even if the implementation of the actual type corresponding to Parent has no overriding Finalize itself since the inherited null version from Limited_Controlled will then be harmlessly called. See also 12.5. The approach we have adopted enables the implementation difficulties presented by, for example, exceptions to be overcome. Thus suppose an exception is raised in the middle of a sequence of declarations of controlled objects. Only those already elaborated will need to be finalized and some mechanism is required in order to record this. Such a mechanism can conveniently be implemented using links which are components of the private types Controlled and Limited_Controlled; these components are of course quite invisible to the user. Incidentally, this illustrates that an abstract type need not be null. The following example is of a generic package that defines a sparse array type. The array is extended automatically as new components are assigned into it. Empty_Value is returned on dereferencing a never- assigned component. On scope exit, automatic finalization calls Finalize, which reclaims any storage allocated to the sparse array. <syntaxhighlight lang="Ada"> with Ada.Finalization; use Ada; generic type Index_Type is (<>); -- index type must be some discrete type type Element_Type is private; -- component type for sparse array Empty_Value : in Element_Type; -- value to return for never-assigned components package Sparse_Array_Pkg is -- this generic package defines a sparse array type type Sparse_Array_Type is new Finalization.Limited_Controlled with private; procedure Set_Element(Arr: in out Sparse_Array_Type; Index: in Index_Type; Value: in Element_Type); -- set value of an element -- extend array as necessary function Element(Arr: Sparse_Array_Type; Index: Index_Type) return Element_Type; -- return element of array -- return Empty_Value if never assigned procedure Finalize(Arr: in out Sparse_Array_Type); -- reset array to be completely empty -- use default Initialize implementation (no action) -- no Adjust for limited types private -- implement using a B-tree-like representation type Array_Chunk; -- type completed in package body type Array_Chunk_Ptr is access Array_Chunk; type Sparse_Array_Type is new Finalization.Limited_Controlled with record Number_Of_Levels: Natural := 0; Root_Chunk : Array_Chunk_Ptr; end record; end Sparse_Array_Pkg; package body Sparse_Array_Pkg is type Array_Chunk is ... -- complete the incomplete type definition procedure Set_Element( ... function Element(Arr: Sparse_Array_Type; Index: Index_Type) return Element_Type is begin if Arr.Root_Chunk = null then -- entire array is empty return Empty_Value; else -- look up to see if Index appears -- in array somewhere ... end if; end Element; procedure Finalize(Arr: in out Sparse_Array_Type) is begin if Arr.Root_Chunk /= null then -- release all chunks of array ... -- reinitialize array back to initial state Arr.Root_Chunk := null; Arr.Number_Of_Levels := 0; end if; end Finalize; end Sparse_Array_Pkg;</syntaxhighlight> Since the sparse array type is derived from a library level tagged type (Ada.Finalization.Limited_Controlled), the generic unit must also be instantiated at the library level. However, an object of the sparse array type defined in the instantiation may be declared in any scope. When that scope is exited, for whatever reason, the storage dynamically allocated to the array will be reclaimed, via an implicit call on Sparse_Array_Type.Finalize. Such a sparse array type may safely be used by subprograms of a long- running program, without concern for progressive loss of storage. When such subprograms return, the storage will always be reclaimed, whether completed by an exception, return, abort, or asynchronous transfer of control. Our next example illustrates user-defined assignment. Incidentally, it should be noted that many of the cases where user-defined assignment was felt to be necessary in Ada 83 no longer apply because the ability to redefine "=" has been generalized. Many Ada 83 applications using limited types did so in order to redefine "=" and as a consequence lost predefined assignment. Their need for user-defined assignment was simply to get back the predefined assignment. An instance where user-defined assignment would be appropriate occurs in the implementation of abstract sets using linked lists where a deep copy is required as mentioned in 4.4.3. The general idea is that the set is implemented as a record containing one inner component which is controlled; this controlled component is an access to a linked list containing the various elements. Whenever the controlled component is assigned it makes a new copy of the linked list. Note that the type Linked_Set as a whole cannot be controlled because it is derived directly from Abstract_Sets.Set. However, assigning a value of the Linked_Set causes the inner component to be assigned and then invokes the procedure Adjust on the inner component. The implementation might be as follows <syntaxhighlight lang="Ada"> with Abstract_Sets; with Ada.Finalization; use Ada.Finalization; package Linked_Sets is type Linked_Set is new Abstract_Sets.Set with private; ... -- the various operations on Linked_Set private type Node; type Ptr is access Node; type Node is record Element: Set_Element; Next: Ptr; end record; function Copy(P: Ptr) return Ptr; -- deep copy type Inner is new Controlled with record The_Set: Ptr; end record; procedure Adjust(Object: in out Inner); type Linked_Set is new Abstract_Sets.Set with record Component: Inner; end record; end Linked_Sets; package body Linked_Sets is function Copy(P: Ptr) return Ptr is begin if P = null then return null; else return new Node'(P.Element, Copy(P.Next)); end if; end Copy; procedure Adjust(Object: in out Inner) is begin Object.The_Set := Copy(Object.The_Set); end Adjust; ... end Linked_Sets;</syntaxhighlight> The types Node and Ptr form the usual linked list containing the elements; Node is of course not tagged or controlled. The function Copy performs a deep copy of the list passed as parameter. The type Inner is controlled and contains a single component referring to the linked list. The procedure Adjust for Inner performs a deep copy on this single component. The visible type Linked_Set is then simply a record containing a component of the controlled type Inner. As mentioned above, performing an assignment on the type Linked_Set causes Adjust to be called on its inner component thereby making the deep copy. But none of this is visible to the user of the package Linked_Sets. Observe that we do not need to provide a procedure Initialize and that we have not bothered to provide Finalize although it would be appropriate to do so in order to discard the unused space. Finally, we show a canonical example of the use of initialization and finalization and access discriminants for the completely safe control of resources. Consider the following: <syntaxhighlight lang="Ada"> type Handle(Resource: access Some_Thing) is new Finalization.Limited_Controlled with null record; procedure Initialize(H: in out Handle) is begin Lock(H.Resource); end Initialize; procedure Finalize(H: in out Handle) is begin Unlock(H.Resource); end Finalize; ... procedure P(T: access Some_Thing) is H: Handle(T); begin ... -- process T safely end P;</syntaxhighlight> The declaration of H inside the procedure P causes Initialize to be called which in turn calls Lock with the object referred to by the handle as parameter. The general idea is that since we know that Finalize will be called no matter how we leave the procedure P (including because of an exception or abort) then we will be assured that the unlock operation will always be done. This is a useful technique for ensuring that typical pairs of operations are performed correctly such as opening and closing files. Note that we have to declare the handle locally because that is where the locking is required and hence an access discriminant has to be used in order to avoid accessibility problems. We have to have a handle in the first place so that its declaration is tied to the vital finalization. Some examples of the use of finalization with asynchronous transfer of control will be found in 9.4. == <span id="5">7.5 Requirements Summary</span> == The major study topic * S4.2-A(2) - Preservation of Abstraction is directly addressed and satisfied by the introduction of controlled types as discussed in 7.4. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-6|Previous]] | [[Guide:9x_rationale/rat95-p2-8|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=7 Packages}} 8ikkdcud261aij6lbjubyrypr2h3vci Guide:9x rationale/rat95-p2-8 4200 342 1877 1824 2019-04-20T16:20:56Z WikiVisor 11 Text replacement - "|Next]]" to "|Next]]</div>" wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-7|Previous]] | [[Guide:9x_rationale/rat95-p2-9|Next]]</div> This is an area of the language which is largely ignored by the normal programmer except when it produces surprising or frustrating consequences. The changes have thus been directed largely towards making the rules clear and consistent and with more helpful consequences. The changes are * The visibility and scope rules are rewritten to make them consistent and clearer. They also incorporate the consequences of the introduction of the hierarchical library. * The use type clause is introduced for operators. * Renaming is now allowed for subprogram bodies, generic units and library units. * There are also a number of minor improvements such as the preference rules for overload resolution. == <span id="1">8.1 Scope and Visibility</span> == This is an area where there is no substitute for a precise description of the rules. Suffice it to say that the rules for Ada 83 were obscure and probably not truly understood by anybody; a consequence was subtle variation between compilers to the detriment of portability. We will not attempt to summarize the 95 rules but refer the reader to [RM95] for the details. One important change is that character literals are now treated like other literals with regard to visibility. This means that they are always visible although the legality of their use will depend upon the context. So <syntaxhighlight lang="Ada"> package P is type Roman_Digit is ('I', 'V', 'X', 'L', 'C', 'D', 'M'); end P; with P; package Q is ... Five: constant P.Roman_Digit := 'V'; ... end Q;</syntaxhighlight> is allowed in Ada 95 although in Ada 83 we would have had to write P.'V' or alternatively supplied a use clause for P. The visibility rules now also take account of the introduction of child packages. Most of the changes are straightforward but there is one interesting interaction with subunits. Consider <syntaxhighlight lang="Ada"> package P is ... end P; package P.Q is ... end P.Q; package body P is Q: Integer; -- legal procedure Sub is separate; end P; with P.Q; -- illegal separate(P) procedure Sub is ... end Sub;</syntaxhighlight> The declaration of Q in the body of P is permitted because the body does not have a with clause for P.Q. But the with clause makes the subunit illegal because it could otherwise see both P.Q the child package and P.Q the variable in the body, and they are not overloadable. == <span id="2">8.2 Use Clauses</span> == As mentioned in Part One the use of operators in Ada 83 caused problems. Many groups of users recognized that the use clause could make programs hard to understand because the origin of identifiers became obscure. Accordingly many organizations banned use clauses. This meant that either operators of user defined types had to be called with prefix notation such as Complex."+"(P, Q) or else had to be locally renamed. This difficulty also occurred with predefined operators. Thus given an access type T declared in a package P, it was very annoying to find that one could not write <syntaxhighlight lang="Ada"> with P; procedure Q is X: P.T; begin ... if X /= null then ... end Q;</syntaxhighlight> but had to provide a use clause for P or a renaming for "=" or write the diabolical <syntaxhighlight lang="Ada"> if P."/="(X, null) then</syntaxhighlight> This problem is overcome in Ada 95 by the introduction of the use type clause which just provides visibility of the operators of a type and thereby allows them to be used in the natural infixed form. This ensures that a use package clause is not needed and hence the full name is still required for other identifiers. The introduction of child units causes some extension to the rules for packages. As explained in Chapter 10, child units are treated like separately compiled but logically nested units. Like nested units, the name of a child mentioned in a with clause becomes directly visible when the logically enclosing parent package is specified in a use clause. And so, using the example from II.8 <syntaxhighlight lang="Ada"> with OS.File_Manager; procedure Hello is use OS; -- makes File_Manager directly visible -- as well as other declarations in package OS File: File_Descriptor := File_Manager.Open("Hello.Txt", File_Manager.Write_Only); begin File_Manager.Write(File, "Hello world."); File_Manager.Close(File); end Hello;</syntaxhighlight> == <span id="3">8.3 Renaming</span> == To enhance the usefulness of renaming, the body of a subprogram may be provided by a renaming declaration. If the subprogram declaration is in a package specification while the subprogram definition via a renaming is in a package body, the renaming must be of a subprogram that has subtype conformance (see 6.2) with the subprogram's declaration. This ensures that the caller of the subprogram will perform the correct constraint checks on the actual parameters, and pass the parameters following the correct calling convention seeing only the subprogram's specification. A normal subprogram renaming requires only mode conformance. This kind of conformance is too weak for a renaming provided in the body. Given only mode conformance, the caller might perform constraint checks that were too stringent or too lax, and might pass parameters following the wrong calling conventions, putting them in the wrong place on the stack, or in the wrong register. We considered requiring subtype conformance for all subprogram renaming. However, this introduces upward incompatibilities, particularly given the existing equivalence between generic formal subprogram matching and renaming. Furthermore, it is not always possible to statically match the subtype of a formal parameter of a subprogram, if the subprogram is implicitly declared as part of the type definition. In particular, if the subprogram is derived from a parent type, then the formal parameter subtypes have the constraints that were present on the parent type's subprogram. If the derived type definition itself imposes a constraint, then it is likely that the constraint on the formal parameter of the derived subprogram is actually looser than the constraint on the first subtype of the derived type. This means there is no nameable subtype that has constraints as loose as those on the formal parameter. In the case of a primitive operation of a tagged type, renaming will cause a new slot in the dispatch table to be created if the renaming is itself primitive (that is in the same package specification as the type). If the original primitive operation is overridden then the renamed view will naturally depend upon whether renaming occurs before or after the overriding. Consider <syntaxhighlight lang="Ada"> package P is type T is tagged ...; function Predefined_Equal(X, Y: T) return Boolean renames "="; function "="(X, Y: T) return Boolean: -- overrides function User_Defined_Equal(X, Y: T) return Boolean renames "="; end P;</syntaxhighlight> where we have renamed the predefined equality both before and after overriding it. Both renamings create new slots which are then initialized with the current meaning of equality. That for Predefined_Equal thus refers to the predefined equal whereas that for User_Defined_Equal refers to the overridden version. The consequence is that renaming can be used to hang on to an old primitive operation irrespective of whether that old operation is subsequently overridden. Such a renaming is itself a distinct primitive operation which could later be overridden for any subsequently derived type. On the other hand a renaming which is not a primitive operation will not create a new slot but will simply refer to the operation at the point of the renaming. Thus if User_Defined_Equal is declared in a distinct package Q (after P), then it will not be primitive but will still refer to the overridden operation. This will occur even if the overriding is in the private part and thus not visible to Q. For a further discussion see [AARM 8.5.4]. This ability of renaming to create a new slot may be considered surprising because the general purpose of renaming is simply to create a new name for an existing entity; but there is of course no new entity being created but just a different way of accessing an existing entity. Another very useful change is the ability to rename a library unit as a library unit. (It was possible to rename a library unit in Ada 83 but only as a local unit.) Library unit renaming is particularly important with the hierarchical library; this is discussed in detail in 10.1.2. A related change is the ability to rename a generic unit. Curiously enough this was not permitted in Ada 83 although most other entities could be renamed. Thus we can write <syntaxhighlight lang="Ada"> generic package Enum_IO renames Ada.Text_IO.Enumeration_IO;</syntaxhighlight> as mentioned in [RM95 8.5.5]. In order to prevent difficulties with generic children, a child of a generic parent (such a child must be generic) can only be renamed if the renaming occurs inside the declarative region of its parent; it could be renamed as a child. This is consistent with the rules regarding the instantiation of such generic child units mentioned in II.8. == <span id="4">8.4 Other Improvements</span> == The overload resolution rules of Ada 83 were confusing and unclear and this section of the reference manual has been completely rewritten. An important new rule is the preference rule for operators and ranges of root numeric types (see 3.3). Briefly this says that an ambiguity can be resolved by preferring the operator of the root type. This rule coupled with automatic conversion from a universal type removes the need for the special rules in Ada 83 regarding universal convertible operands. As an example, consider <syntaxhighlight lang="Ada"> C: constant := 2 + 3;</syntaxhighlight> which was allowed in Ada 83 because the expression was required to be universal and so no question of ambiguity arose. It is not ambiguous in Ada 95 either but for different reasons; the expression 2 + 3 is considered to be of type root_integer (it could otherwise be Integer or Long_Integer). The root_integer is then converted implicitly to universal_integer as required for the initial value. The special rule regarding ranges in loops and for array indexes (which are in the distinct syntactic category discrete_subtype_definition) which result in them by treated as of type Integer if no specific subtype mark is specified is changed in Ada 95. The new rule is that if the range resolves to be of the type root_integer then it is taken to be of type Integer. One outcome of all this is that we can now write <syntaxhighlight lang="Ada"> for I in -1 .. 100 loop</syntaxhighlight> as we have already mentioned in Part One. The interpretation is that -1 resolves to root_integer because of the preference rules and then the special rule just mentioned is used so that the range is finally treated as of type Integer. == <span id="5">8.5 Requirements Summary</span> == Many of the changes in this area of the language are aimed at making the language more precise and easier to understand as requested by the general requirement * R2.2-B(1) - Understandability and we note in particular that the example in [DoD 90 A.2.3] concerning visibility of literals and operations has been addressed and satisfied. The related requirement * R2.2-C(1) - Minimize Special Case Restrictions discussed in [DoD 90 A.3.12] contains the example of negative literals in loops which has also been satisfied. The requirement * R2.2-A(1) - Reduce Deterrents to Efficiency is addressed by the elimination of the problem of returning task objects explicitly mentioned in the requirement in [DoD 90]. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-7|Previous]] | [[Guide:9x_rationale/rat95-p2-9|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=8 Visibility Rules}} jcrqnh7dtswpjpjewgdsb81hhypdxbj Guide:9x rationale/rat95-p2-9 4200 343 1841 1813 2019-04-20T16:19:23Z WikiVisor 11 Text replacement - "[[Guide:9x_rationale/rat95-copyright|Copyright]] | " to "<div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | " wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-8|Previous]] | [[Guide:9x_rationale/rat95-p2-10|Next]]</div> As explained in Part One, experience with Ada 83 showed that although the innovative rendezvous provided a good overall model for task communication, nevertheless it had not proved adequate for problems of shared data access. Accordingly, as outlined in Chapter II, this part of the language is considerably enhanced with the major additions being the introduction of protected types, the requeue statement and asynchronous transfer of control. In this chapter we add further examples and discussion to that already given. The main changes to the core language are * The protected type is introduced as a new form of program unit with distinct specification and body in a similar style to packages and tasks. * The requeue statement is added to provide preference control and thereby overcome various race conditions which could arise in Ada 83. * There is a new form of delay statement which allows waiting for an absolute rather than a relative time. This overcomes problems of poor timing which in essence are caused by a race condition with the clock. * There is a new form of the select statement which gives asynchronous transfer of control. This can be used to program mode changes. * The description of the rules regarding the abort statement is improved. * A task (like a protected type) may now have discriminants and a private part. * A minor improvement is that entries and representation clauses may now occur in any order in a task specification. In addition to the above changes there are further packages, pragmas and attributes plus requirements on implementations described in the Systems Programming and Real-Time Systems annexes. These relate to matters such as scheduling and priorities, task identification, shared variable access, accuracy of timing, interrupt handling and the immediacy of the abort statement. For further details on these topics the reader is referred to Part Three. == <span id="1">9.1 Protected Types</span> == In Ada 83, the rendezvous was used for both inter-task communication and for synchronizing access to shared data structures. However, the very generality of the rendezvous means that it has a relatively high overhead. Ada 95 overcomes this problem by introducing a low overhead, data-oriented synchronization mechanism based on the concept of protected objects. From the client perspective, operating on a protected object is similar to operating on a task object. The operations on a protected object allow two or more tasks to synchronize their manipulations of shared data structures. From the implementation perspective, a protected object is designed to be a very efficient conditional critical region (see 9.1.3). The protected operations are automatically synchronized to allow only one writer or multiple readers. The protected operations are defined using a syntax similar to a normal subprogram body, with the mutual exclusion of the critical region happening automatically on entry, and being released automatically on exit. We considered many different approaches to satisfying the needs for fast mutual exclusion, interrupt handling, asynchronous communication, and various other common real-time paradigms. We settled on the protected object construct because it seems to provide a very efficient building block, which is flexible enough to implement essentially any higher-level synchronization mechanism of interest. Some of the features that make protected objects attractive as a building block are: * Scalability. Protected objects enable the implementation of a synchronization mechanism that scales smoothly from a single processor to a multiprocessor. There is no built-in bias to a monoprocessor or to a multiprocessor. * Adaptability. Additional protected operations may be added to a protected type without the need to modify the existing operations. Approaches that use explicit signals and conditions rather than the conditional barrier approach generally need each operation to be aware of every state of interest, and explicitly signal all possible waiting tasks. * Modularity. All of the operations of a given critical region are identified in the specification of the protected type, and their implementations are encapsulated within the body of the protected type. The directly protected data components are encapsulated within the private part of the protected type, and all of the interesting states are identified explicitly via entry barrier conditions within the body of the protected type. * Efficiency. The size and initialization requirements of a protected object are known at compile time of the client, because all entries and data components are declared in the specification. This enables protected objects to be allocated statically or directly on the stack, rather than via dynamic allocation, and to be initialized in- line. No extra context switches are required to service waiting clients, since the task changing the state may directly execute the entry bodies whose barriers become true. Non-queued locking may be used to implement the mutual exclusion of a protected object because no blocking is permitted during the execution of a protected operation. * Expressiveness. The specification of a protected type makes explicit distinctions between read-only operations (functions), read-write operations (procedures), and possibly blocking operations (entries). This distinction is vital in analyzing a real-time program for correctness, including freedom from deadlock. * Compatibility. The entry call remains the primary mechanism for blocking a task until some condition is satisfied. An entry call on another task is blocked until the corresponding entry in the task is open. An entry call on a protected object is blocked until the corresponding entry barrier is true. An entry call on a task is completed when the rendezvous finishes and an entry call on a protected object is completed when the entry body finishes; possibly with intermediate blockings as part of a requeue in both cases. From the caller's perspective, an entry call involves a possible initial blocking, one or more intermediate blockings, and then a return. During the entry call, data may be transferred via the parameters. By using the entry call interface for both protected objects and tasks, the existing conditional and timed entry call mechanisms are applicable. * Interrupt Handling. A protected procedure is very well suited to act as an interrupt handler for a number of reasons; they both typically have a short bounded execution time, do not arbitrarily block, have a limited context and finally they both have to integrate with the priority model. The nonblocking critical region matches the needs of an interrupt handler, as well as the needs of non-interrupt-level code to synchronize with an interrupt handler. The entry barrier construct allows an interrupt handler to signal a normal task by changing the state of a component of the protected object and thereby making a barrier true. Of the many other approaches we considered for supporting data- oriented synchronization, none could match this set of desirable features. Like task types, protected types are limited types. Because protected objects are specifically designed for synchronizing access from concurrent tasks, a formal parameter must always denote the same protected object as the corresponding actual parameter and so pass by reference is required (a copy would not preserve the required atomicity). A protected type may have discriminants, to minimize the need for an explicit initialization operation, and to control composite components of the protected objects including setting the size of an entry family. A discriminant can also be used to set the priority and identify an interrupt. The other data components of a protected object must be declared in the specification of the type to ensure that the size is known to the compiler when the type is used by a caller. However these components are only accessible from protected operations defined in the body of the protected type and thus are declared in the private part of the protected type. The protected operations may be functions, procedures, or entries. All the entries must be declared in the protected type specification to ensure that space needed for entry queues is included when allocating the protected object. Entries which are not required to be visible to external clients can be declared in the private part. Additional functions and procedures may be declared in the private part or body of the protected unit, for modularizing the implementation of the operations declared in the specification. An example of a counting semaphore implemented as a protected type is given in II.9. This example illustrates the three kinds of protected operations: functions, procedures, and entries. Functions provide read- only access (which may be shared) to the components of the protected object. Procedures provide exclusive read-write access to the components. Entries have an entry barrier that determines when the operation may be performed. The entry body is performed with exclusive read-write access to the components, once the barrier becomes true due to the execution of some other protected operation. It is important to observe that the evaluation of barrier expressions is also performed with exclusive access to the protected object. The counting semaphore might be used as follows <syntaxhighlight lang="Ada"> Max_Users: constant := 10; -- limit number of simultaneous users of service User_Semaphore: Counting_Semaphore(Max_Users); procedure Use_Service(P: Param) is begin -- wait if too many simultaneous users User_Semaphore.Acquire; begin Perform_Service(P); exception when others => -- always release the semaphore for next user. User_Semaphore.Release; raise; end; -- release the semaphore for others User_Semaphore.Release; end Use_Service;</syntaxhighlight> This example illustrates that a semaphore can be implemented as a protected object. However, in essence this often constitutes abstraction inversion since it leaves the responsibility for releasing the semaphore in the hands of the user (unless we use a controlled type as illustrated in 7.4). It is precisely to avoid such possibilities that protected types are provided as an intrinsic syntactic form inherent in the language. Semaphores (like the goto statement) are very prone to misuse and should be avoided where possible. However, there are occasions when they are useful and this example shows an implementation. As mentioned, some of the protected operations declared in the specification may be declared after the reserved word private. This makes these operations callable only from within the protected unit. Task types may similarly have a private part, so that certain task entries may be hidden from a direct call from outside the task (they can be called by its sub-tasks or via a requeue statement). (Alternative structures were also considered and rejected. One was that the private part of a protected unit be visible to the enclosing package. However, this was considered confusing, and felt to be inconsistent with the visibility of the private part of a subpackage. We also considered splitting the protected type (and task) specification into two separate parts, with the private operations and data components declared in a second part included inside the private part of the enclosing package. However, this seemed like an unnecessary extra syntactic complexity, so we finally adopted the simpler suggestion from two Revision Requests (RR-0487, RR-0628) of using private within the specification to demarcate the private operations.) Each entry declared in the specification of a protected type must have an entry body. An entry body includes a barrier condition following the reserved word when; the barrier condition must be true before the remainder of the entry body is executed. The entry body for an entry family must specify a name for the entry family index, using an iterator notation (for I in discrete_subtype_definition). We considered a simpler syntax (I: discrete_subtype_definition) but opted for the iterator notation to avoid ambiguity with the formal parameter part. An entry barrier is not allowed to depend on parameters of the entry, but it may depend on the entry family index, or any other data visible to the entry body. This rule ensures that all callers of the same entry see the same barrier condition, allowing the barrier to be checked without examining individual callers. Without this rule, each caller of a given entry would have to be treated separately, since each might have a different effective barrier value. Rather than entry "queues" one would essentially have a single large "bag" of callers, all of which would have to be checked on each protected object state change. For flexibility, entry barriers may depend on data global to the protected object. This allows part of the data managed by the protected object to be outside it, if this is necessary due to some other program structure requirements. However, the barriers are only rechecked after completing a protected procedure or entry body, so asynchronous changes to global data have no immediate effect on the eligibility of a caller waiting on an entry queue. For efficiency, implementations may assume that the only meaningful changes to data referenced in an entry barrier of some protected object take place within a protected operation of that protected object. We considered disallowing references to globals in a barrier expression. However, that would also have disallowed the use of functions (which might reference globals) or the dereferencing of access values. Such a rule was felt to be too complex to implement, and too restrictive when dealing with data types implemented with access types, such as a linked list. The semantics for protected types are described in terms of mutual exclusion (except that protected functions may execute concurrently). In addition, as the final step of a protected action, the entry queues are serviced before allowing new calls from the outside to be executed. In this context, a protected "action" is the whole sequence of actions from locking to unlocking and thus comprises a series of one or more of: * a call on a protected subprogram from outside the protected unit, * the execution of an entry body, * the addition or removal of a call from an entry queue. Servicing the entry queues is required if any change has been made that might affect the value of a barrier expression. First, the barriers for the non-empty entry queues must be reevaluated. If at least one such barrier evaluates to true, some eligible caller must be selected, and the corresponding entry body must be executed. The barriers are then reevaluated once more, and this process continues until all non-empty entry queues have a false barrier. The barriers may be evaluated, and the entry bodies executed, by any convenient thread of control. It need not be the thread of the original caller. This flexibility allows for the most efficient implementation, minimizing unnecessary context switches. (For details on how the choice of caller is made see the Real- Time Systems annex.) While executing a protected operation of some protected object, a task cannot call a potentially blocking operation for any reason, though it may release the mutual exclusive access to the protected object by being requeued. Disallowing blocking while executing a protected operation allows a nonqueued locking mechanism to be used to implement the mutual exclusion. If blocking were allowed, then a queued locking mechanism would be required, since potential callers might attempt to get the lock while the current holder of the lock is blocked. Another advantage is that conditional calls are more meaningful. In the simplest monoprocessor environment, protected object mutual exclusion can be implemented by simply inhibiting all task preemption. If multiple priorities are supported, then rather than inhibiting all preemption, a ceiling priority may be established for the protected object (see the Ceiling Priorities section of the Real-Time Systems annex). Only tasks at this ceiling priority or below may use the protected object, meaning that tasks at priorities higher than the ceiling may be allowed to preempt the task performing the protected operation while still avoiding the need for a queued lock. In a multiprocessor environment, spin waiting may be used in conjunction with the ceiling priority mechanism to implement a non-queued protected object lock. By disallowing blocking within a protected operation and by also using the ceiling priority mechanism, unbounded priority inversion can be avoided. The generality that might be gained by allowing blocking would inevitably result in an increase in implementation complexity, run-time overhead, and unbounded priority inversion. To simplify composability, protected operations may call other non- blocking protected operations (protected procedures and functions). A direct call on a protected subprogram within the same protected type does not start a new protected action, but is rather considered to be part of the current action. It is considered an error if, through a chain of calls going outside the protected object, a call is made back to the same protected object. The effect is implementation-defined, but will generally result in a deadlock. We considered disallowing all subprogram calls from a protected operation to a subprogram defined outside the protected type, but this seemed unnecessarily constraining, and to severely limit composability. === <span id="1-1">9.1.1 Summary of Mechanism</span> === Protected types provide a low-level, lightweight, data-oriented synchronization mechanism whose key features are * A protected object has hidden components; these components are intended to be shared among multiple tasks. The protected operations of the protected object provide synchronized access to the components. * Protected types have three kinds of protected operations: protected functions, protected procedures, and entries. Protected functions and protected procedures are known as protected subprograms. * Protected procedures provide exclusive read-write access to the components. Protected functions, since they cannot change the components of the protected object, may be optimized to use a shared read-only lock. * Protected entries also provide exclusive read-write access to the components, but in addition, they specify a barrier, which is a Boolean expression that generally depends on the components of the protected object. The Run-Time System ensures that the barrier is true before allowing a protected entry call to proceed. * Each protected object has a conceptual lock associated with it. (This lock may sometimes be an actual one, or can instead be implemented using the ceiling priorities model, see the Real-Time Systems annex). At the start of a protected operation, the calling task seizes the lock. Evaluation of barriers, execution of protected operation bodies, and manipulation of entry queues (see below) are all done while the lock is held. On a multiprocessor, the intended implementation of locks uses busy waiting. (Other, more specialized algorithms, are allowed). * There is a queue associated with each protected entry. Tasks wait in the queue until the entry's barrier becomes True. If the barrier is already True when the entry call first seizes the lock, then it is executed immediately; the queue is not used. While waiting in the queue, a task does not hold the lock. * A requeue statement is allowed in an entry body (and an accept statement). The effect of this statement is to return the current caller back to the queue, or to place it on another, compatible, entry queue. * Ceiling priorities may be associated with protected objects as described in the Real-Time Systems annex. The ceiling rules prevent the priority-inversion phenomenon, and ensure freedom from deadlocks on single-processor systems. For further details see Part Three of this rationale. === <span id="1-2">9.1.2 Examples of Use</span> === Protected types combine high efficiency with generality and can be used as building blocks to support various common real-time paradigms. In this section we discuss three examples * An implementation of indivisible counters showing how protected subprograms are used. * An implementation of persistent signals showing how protected entries are used. * A generic bounded buffer showing how protected types can be used within a generic package. A non-generic form of the bounded buffer and an implementation of transient (broadcast) signals will be found in II.9. Examples of the use of the requeue mechanism are shown in 9.2. We observe that protected types allow Ada 95 to support these and other real-time paradigms with a smaller overall change to the language than the alternative approach where each problem is solved with its own distinct feature. In the following examples, we refer to the lock as an actual object with lock and release operations. This, of course, is not required, and is simply used for ease of presentation. The first very simple example shows a counter that is shared among multiple tasks <syntaxhighlight lang="Ada"> protected Counter is procedure Increment(New_Value: out Positive); private Data: Integer := 0; end Counter; protected body Counter is procedure Increment(New_Value: out Positive) is begin Data := Data + 1; New_Value := Data; end Increment; end Counter;</syntaxhighlight> The counter is initialized to zero. A task may increment it by calling the Increment procedure <syntaxhighlight lang="Ada"> Counter.Increment(New_Value => X);</syntaxhighlight> If N tasks do this, each exactly once, they will each get a unique value in the range 1 to N. Note that without the synchronization provided by the protected type, multiple simultaneous executions of Increment might cause unpredictable results. With the protected type, a task that calls Increment will first seize the lock, thus preventing such simultaneous executions. Since there are no entries in this example, there are no queues. The protected type consists, in essence, of a lock and the component Data. If we want to define many Counter objects, we would change the above example to declare a protected type instead of a single protected object as follows <syntaxhighlight lang="Ada"> protected type Counter_Type is ... -- same as before end Counter_Type; Counter_1, Counter_2: Counter_Type; -- declare two counters type Many is array (1 .. 1000) of Counter_Type; X: Many; -- declare many counters</syntaxhighlight> It is important to note that a lock is associated with each protected object and not with the type as a whole. Thus, each of the objects in the above example has its own lock, and the data in each is protected independently of the others. This simple example has a short, bounded-time algorithm; all it does is increment the value and assign it to the out parameter. This is typical of the intended use of protected types. Because the locks might be implemented as busy-waits (at least on multiprocessors), it is unwise to write an algorithm that might hold a lock for a long or unknown amount of time. A common approach where extensive processing is required would be to just record the new state, under the protection of the lock, and do the actual processing outside the protected body. The next example shows a persistent signal. In this example, tasks may wait for an event to occur. When the event occurs, some task whose job it is to notice the event will "signal" that the event has occurred. The signal causes exactly one waiting task to proceed. The signal is persistent in the sense that if there are no tasks waiting when the signal occurs, the signal persists until a task invokes a wait, which then consumes the signal and proceeds immediately. Multiple signals when no tasks are waiting are equivalent to just one signal. It is interesting to note that persistent signals are isomorphic to binary semaphores; the wait operation corresponds to P, and the signal operation corresponds to V. <syntaxhighlight lang="Ada"> protected Event is entry Wait; -- wait for the event to occur procedure Signal; -- signal that the event has occurred. private Occurred: Boolean := False; end Event; protected body Event is entry Wait when Occurred is begin Occurred := False; -- consume the signal end Wait; procedure Signal is begin Occurred := True; -- set Wait barrier True end Signal; end Event;</syntaxhighlight> A task waits for the event by calling <syntaxhighlight lang="Ada"> Event.Wait;</syntaxhighlight> and the signalling task notifies the happening of the event by <syntaxhighlight lang="Ada"> Event.Signal;</syntaxhighlight> whereupon the waiting task will proceed. There are two possibilities to be considered according to whether the call of Wait or the call of Signal occurs first. If a call of Wait occurs first, the task will seize the lock, check the barrier, and find it to be False. Therefore, the task will add itself to the entry queue, and release the lock. A subsequent Signal will seize the lock and set the Occurred flag to True. Before releasing the lock, the signalling task will check the Wait entry queue. There is a task in it, and the barrier is now True, so the body of Wait will now be executed, setting the flag to False, and the waiting task released. Before releasing the lock, the process of checking entry queues and barriers is repeated. This time, the Wait barrier is False, so nothing happens; the lock is released, and the signalling task goes on its way. If, on the other hand, a call of Signal occurs first, then the task will seize the lock, set the flag to True, find nothing in the entry queues, and release the lock. A subsequent Wait will seize the lock, find the barrier to be True already, and proceed immediately with its body. The barrier is now False, so the waiting task will simply release the lock and proceed. Important things to note are * Protected subprograms do not have barriers. Protected entries always have barriers. Signal is a protected procedure, because it never needs to block while waiting for the state of the protected type to change; that is, it needs no barrier. Wait is an entry, because it needs to block until the flag is set before proceeding. * The protected entry queues are not used for tasks waiting for access to the protected data. They are used for tasks waiting for an entry barrier to become true; that is, they are waiting for the state of the protected type to change in order to satisfy some user-specified condition. The lock associated with the protected object synchronizes access to the shared data. The same lock also protects the entry queues themselves; the queues may be considered as part of the shared data. * Barriers are associated with entry queues, not with individual tasks calling the entries. Therefore, the number of barriers to be evaluated can never be more than the number of entries of the protected object. (Note that the size of an entry family can depend on a discriminant, so the number of entries can vary from object to object of the type.) * Entry barriers are reevaluated only at well-defined points: in particular, when a call is first made and when a protected procedure or entry associated with that protected object has just finished, but before it has released the lock. * Protected functions do not change the state of the protected type, and so should not change barrier values. Therefore, entry barriers are not reevaluated when a protected function has just finished. * The lock stays locked during the actions that happen at the end of a protected procedure or entry (that is, checking the queues for non- empty status, evaluating barriers, removing a task from a queue, and executing the entry body). This means that tasks already on the queues get preference over tasks that are trying to seize the lock. * Barriers, like protected operation bodies, should contain only short, bounded-time expressions. In typical examples, the barrier simply tests a Boolean flag, or checks the number of elements in an entry queue. The programmer has complete control over worst-case waiting times; this worst-case analysis can be done by inspecting the algorithms in the protected bodies, the barriers, and the maximum number of tasks that can be expected to be waiting on each barrier. * The language does not specify which task executes a particular barrier or entry body. One can think of barriers and entry bodies as being executed by the Run-Time System, not by any particular task. Certain restrictions on what may appear in a barrier or an entry body imply that it does not matter which task does the work. (For example, Current_Task cannot be called, see Systems Programming annex.) This is done to ensure that no context switches are required; when one task finishes executing an operation, the task can immediately execute any others that have become ready, without having to switch to the context of the "correct" task. Our next example is a generic form of a bounded buffer. In this example a protected object provides conditional critical regions, which allow the abstraction to be used safely by multiple tasks. <syntaxhighlight lang="Ada"> generic type Item is private; Mbox_Size: in Natural; package Mailbox_Pkg is type Item_Count is range 0 .. Mbox_Size; type Item_Index is range 1 .. Mbox_Size; type Item_Array is array (Item_Index) of Item; protected type Mailbox is -- put a data element into the buffer entry Send(Elem: Item); -- retrieve a data element from the buffer entry Receive(Elem: out Item); private Count : Item_Count := 0; Out_Index: Item_Index := 1; In_Index : Item_Index := 1; Data : Item_Array; end Mailbox; end Mailbox_Pkg;</syntaxhighlight> This example illustrates a generic mailbox abstraction. The protected type has two entries, which insert and retrieve items to and from the mailbox buffer. Like a private type, the data components of the protected type are of no concern outside the body. They are declared in the specification so that a compiler can statically allocate all the space required for an instance of the protected type. The body of the mailbox package is as follows <syntaxhighlight lang="Ada"> package body Mailbox_Pkg is protected body Mailbox is entry Send(Elem: Item) when Count < Mbox_Size is -- block until there is room in the mailbox begin Data(In_Index) := Elem; In_Index := In_Index mod Mbox_Size + 1; Count := Count + 1; end Send; entry Receive(Elem: out Item) when Count > 0 is -- block until there is something in the mailbox begin Elem := Data(Out_Index); Out_Index := Out_Index mod Mbox_Size + 1; Count := Count - 1; end Receive; end Mailbox; end Mailbox_Pkg;</syntaxhighlight> As we saw in the non-generic example in II.9, Send waits until there is room for a new Item in the mailbox buffer. Receive waits until there is at least one Item in the buffer. The semantics of protected records guarantee that multiple tasks cannot modify the contents of the mailbox simultaneously. A minor point is that the type Item_Array has to be declared outside the protected type. This is because type declarations are not allowed inside a protected type which generally follows the same rules as records. Allowing types within types would have introduced additional complexity with little benefit. For elegance we have also declared the types Item_Count and Item_Index. === <span id="1-3">9.1.3 Efficiency of Protected Types</span> === Protected types provide an extremely efficient mechanism; the ability to use the thread of control of one task to execute a protected operation on behalf of another task reduces the overhead of context switching compared with other paradigms. Protected types are thus not only much more efficient than the use of an agent task and associated rendezvous, they are also more efficient than traditional monitors or semaphores in many circumstances. As an example consider the following very simple protected object which implements a single buffer between a producer and a consumer task. <syntaxhighlight lang="Ada"> protected Buffer is entry Put(X: in Item); entry Get(X: out Item); private Data: Item; Full: Boolean := False; end; protected body Buffer is entry Put(X: in Item) when not Full is begin Data := X; Full := True; end Put; entry Get(X: out Item) when Full is begin X := Data; Full := False; end Get; end Buffer;</syntaxhighlight> This object can contain just a single buffered value of the type Item in the variable Data; the boolean Full indicates whether or not the buffer contains a value. The barriers ensure that reading and writing of the variable is interleaved so that each value is only used once. The buffer is initially empty so that the first call that will be processed will be of Put. A producer and consumer task might be <syntaxhighlight lang="Ada"> task body Producer is begin loop ... -- generate a value Buffer.Put(New_Item); end loop; end Producer; task body Consumer is begin loop Buffer.Get(An_Item); ... -- use a value end loop; end Consumer;</syntaxhighlight> In order to focus the discussion we will assume that both tasks have the same priority and that a run until blocked scheduling algorithm is used on a single processor. We will also start by giving the processor to the task Consumer. The task Consumer will issue a call of Get, acquire the lock and then find that the barrier is false thereby causing it to be queued and to release the lock. The Consumer is thus blocked and so a context switch occurs and control passes to the task Producer. This sequence of actions can be symbolically described by <syntaxhighlight lang="Ada"> Get(An_Item); lock queue unlock switch context</syntaxhighlight> The task Producer issues a first call of Put, acquires the lock, successfully executes the body of Put thereby filling the buffer and setting Full to False. Before releasing the lock, it reevaluates the barriers and checks the queues to see whether a suspended operation can now be performed. It finds that it can and executes the body of the entry Get thereby emptying the buffer and causing the task Consumer to be marked as no longer blocked and thus eligible for processing. Note that the thread of control of the producer has effectively performed the call of Get on behalf of the consumer task; the overhead for doing this is essentially that of a subprogram call and a full context switch is not required. This completes the sequence of protected actions and the lock is released. However, the task Producer still has the processor and so it cycles around its loop and issues a second call of Put. It acquires the lock again, executes the body of Put thereby filling the buffer again. Before releasing the lock it checks the barriers but of course no task is queued and so nothing else can be done; it therefore releases the lock. The task Producer still has the processor and so it cycles around its loop and issues yet a third call of Put. It acquires the lock but this time it finds the barrier is false since the buffer is already full. It is therefore queued and releases the lock. The producer task is now blocked and so a context switch occurs and control at last passes to the consumer task. The full sequence of actions performed by the producer while it had the processor are <syntaxhighlight lang="Ada"> Put(New_Item); lock Data := New_Item; Full := True; scan: and then on behalf of Consumer An_Item := Data; Full := False; set Consumer ready unlock Put(New_Item); lock Data := New_Item: Full := True; scan: nothing to do unlock Put(New_Item); lock queue unlock switch context</syntaxhighlight> The consumer task now performs a similar cycle of actions before control passes back to the producer and the whole pattern then repeats. The net result is that three calls of Put or Get are performed between each full context switch and that each call of Put or Get involves just one lock operation. This should be contrasted with the sequence required by the corresponding program using primitive operations such as binary semaphores (mutexes). This could be represented by <syntaxhighlight lang="Ada"> package Buffer is procedure Put(X: in Item); procedure Get(X: out Item); private Data: Item; Full: Semaphore := busy; Empty: Semaphore := free; end; package body Buffer is procedure Put(X: in Item) is begin P(Empty); Data := X; V(Full); end Put; procedure Get(X: out Item) is begin P(Full); X := Data; V(Empty); end Get; end Buffer;</syntaxhighlight> In this case there are two lock operations for each call of Put and Get, one for each associated semaphore action. The behavior is now as follows (assuming once more that the consumer has the processor initially). The first call of Get by the consumer results in the consumer being suspended by P(Full) and a context switch to the producer occurs. The first call of Put by the producer is successful, the buffer is filled and the operation V(Full) clears the semaphore upon which the consumer is waiting. The second call of Put is however blocked by P(Empty) and so a context switch to the consumer occurs. The consumer is now free to proceed and empties the buffer and performs V(Empty) to clear the semaphore upon which the producer is waiting. The next call of Get by the consumer is blocked by P(Full) and so a context switch back to the producer occurs. The net result is that a context switch occurs for each call of Put or Get. This contrasts markedly with the behavior of the protected object where a context switch occurs for every three calls of Put or Get. In conclusion we see that the protected object is much more efficient than a semaphore approach. In this example it as a factor of three better regarding context switches and a factor of two better regarding locks. Observe that the saving in context switching overhead depends to some degree on the run-until-blocked scheduling and on the producer and consumer being of the same priority. However, the saving on lock and unlock overheads is largely independent of scheduling issues. The interested reader should also consult [Hilzer 92] which considers the more general bounded buffer and shows that monitors are even worse than semaphores with regard to potential context switches. === <span id="1-4">9.1.4 Relationship with Previous Work</span> === Protected types are related to two other synchronization primitives: the conditional critical region and the monitor. The protected type has been incorporated in a way that is compatible with Ada's existing task types, entries, procedures and functions. In 1973, Hoare proposed a synchronization primitive called a conditional critical region [Hoare 73] with the following syntax <syntaxhighlight lang="Ada"> region V when barrier do statements end;</syntaxhighlight> where the barrier is a Boolean expression, and V is a variable. The semantics of the construction may be described as follows [Brinch-Hansen 73]: <blockquote> When the sender enters this conditional critical region, the [barrier expression] is evaluated. If the expression is true the sender completes the execution of the critical region ... But if the expression is false, the sender leaves the critical region temporarily and enters an anonymous queue associated with the shared variable V.</blockquote> However, Brinch-Hansen pointed out a disadvantage with conditional critical regions [Brinch-Hansen 73]: <blockquote> Although [conditional critical regions] are simple and well- structured, they do not seem to be adequate for the design of large multiprogramming systems (such as operating systems). The main problem is that the use of critical regions scattered throughout a program makes it difficult to keep track of how a shared variable is used by concurrent processes. It has therefore been recently suggested that one should combine a shared variable and the possible operations on it in a single, syntactic construct called a monitor.</blockquote> This thus led to the monitor which has a collection of data and subprogram declarations. In Ada terms, the subprograms declared in the visible part of a monitor, and which are therefore visible outside the monitor, are guaranteed to have exclusive access to the data internal to the monitor. The monitor may also have some variables known as condition variables. These condition variables are like semaphores, in that they have Wait and Signal operations. A Wait operation waits for a matching Signal operation. Hoare introduces monitors with somewhat different syntax, but with equivalent semantics [Hoare 74]. The problem with monitors as discussed in [IBFW 86] is that the Signal and Wait operations suffer from the usual difficulties of using semaphores; they can easily be misused and the underlying conditions are not easy to prove correct. The Ada 83 rendezvous followed CSP [Hoare 78] by providing a dynamic approach to the problem and one which clarified the guarding conditions. However, as we have discussed, the rendezvous has a heavy implementation overhead through the introduction of an intermediary task and can also suffer from race conditions. Ada 95 protected objects are an amalgam of the best features of conditional critical regions and monitors: they collect all the data and operations together, like monitors, and yet they have barriers, like conditional critical regions. The barriers describe the required state that must exist before an operation can be performed in a clear manner which aids program proof and understanding. Protected objects are very similar to the shared objects of the Orca language developed by Bal, Kaashoek and Tanenbaum [Bal 92]. == <span id="2">9.2 The Requeue Statement</span> == Components such as complex servers or user-defined schedulers often need to determine the order and the timing of the service provided by entry or accept bodies based on the values of various controlling items. These items may be local to the server and dependent on its own state, be an attribute of the client or the controlled task, or be global to the system. In addition, these items may often change from the time the entry call is made to the time the selection decision is itself finally made. For fairly simple cases - that is when the items are known to the caller, do not change from the time of call, and have a relatively small discrete range - the entry family facility of Ada 83 might suffice (see [Wellings 84], [Burger 87], [Burns 87]). However, when those restrictions do not hold, a more powerful mechanism is often needed. Entry queue selection is sometimes called preference control. Many papers discussing preference control have appeared in the literature [Elrad 88, Wellings 84, Burns 89]. Preference control arises in applications like resource allocation servers, which typically grant satisfiable requests and queue up unsatisfiable requests for later servicing. Wellings, Keefe and Tomlinson [Wellings 84] were unable to find a good way to implement such servers in Ada 83. An intrinsic provision within a language of the full expressive power to describe the various forms of preference controls would require an elaborate semantic structure and a complex (and potentially large) run- time support system. Instead, we have chosen to provide a single and simple statement in Ada 95 which allows the programmer to construct the desired control algorithms based on the balance of needs of specific applications. This is the requeue statement and as we saw in Part One, it enables an entry call to be requeued on another or even the same entry. In order for the server to gain access to the caller's parameters there is no need to resume the caller and to require it to initiate another entry call based on the results of the first; it may simply be moved to another entry queue. An alternate approach that was considered required the caller to first query the state of the server, and then to initiate an entry call with appropriate parameters (presumably using a specific family member index) to reflect the server's state. This approach suffers from the potential of race conditions, since no atomicity is guaranteed between the two calls (another caller may be serviced and the state of the server may be changed), so the validity of the second request which is based on the first, may be lost. In the case of protected entry calls, exclusive access is maintained throughout the period of examining the parameters and doing the requeue; in the case of accept bodies, the server task controls its own state and since it can refuse to accept any intermediate calls, the atomicity is also maintained. The requeue statement may be specified as with abort. In Ada 83, after a rendezvous had started, there was no way for the caller to cancel the request (or for a time-out to take effect - a time-out request is present only until the acceptor starts the service). There was, of course, good reason for this behavior; after the service has commenced, the server is in a temporary state, and removing the caller asynchronously can invalidate its internal data structures. In addition, because of by-reference parameters, the acceptor must maintain its ability to access the caller's data areas (such as the stack). If the caller "disappears", this might result in dangling references and consequent disaster. However, in some cases, deferring the cancellation of a call is unacceptable, in particular when the time-out value is needed to control the amount of time until the service is completed (as opposed to just started). With the addition of asynchronous transfer of control to Ada 95, the same situation can arise if the caller is "interrupted" and must change its flow of control as soon as possible. Since there is not a single best approach for all applications, and since no easy work-around exists, the with abort is provided to allow the programmer to choose the appropriate mechanism for the application concerned. In general, when cancellation during a requeue is to be allowed, the server will "checkpoint" its data-structures before issuing requeue with abort, in such a way that if the caller is removed from the second queue, the server can continue to operate normally. When this is not possible, or when the cancellation during a requeue is not required, a simple requeue will suffice, and will hold the caller until the service is fully completed. The requeue statement is designed to handle two main situations * After an accept statement or entry body begins execution, it may be determined that the request cannot be satisfied immediately. Instead, there is a need to requeue the caller until the request can be handled. * Alternatively, part of the request may be handled immediately, but there may be additional steps in the process that need to be performed at a later point. In both cases, the accept statement or entry body needs to relinquish control so that other callers may be handled or other processing may be performed; the requeue enables the original request to be processed in two or more parts. The requeue statement allows a caller to be "requeued" on the queue of the same or some other entry. The caller need not be aware of the requeue and indeed the number of steps required to handle a given operation need not be visible outside the task or protected type. The net effect is that the server can be more flexible, while presenting a simple single interface to the client. As part of the requeue, the parameters are neither respecified nor reevaluated. Instead, the parameters are carried over to the new call directly. If a new parameter list were specifiable, then it might include references to data local to the accept statement or entry body itself. This would cause problems because the accept statement or entry body is completed as a consequence of the requeue and its local variables are thus deallocated. Subtype conformance is thus required between the new target entry (if it has any parameters) and the current entry. This allows the same representation to be used for the new set of parameters whether they are by-copy or by-reference and also eliminates the need to allocate new space to hold the parameters. Note that the only possibility other than passing on exactly the same parameters is that the requeued call requires no parameters at all. As a first example of requeue, the reader is invited to look once more at the example of the broadcast signal which we first met in II.9 and which we now repeat for convenience. As in the previous signal example in 9.1.2, tasks wait for an event to occur. However, this is a broadcast signal because when the event is signaled, all waiting tasks are released, not just one. After releasing them, the event reverts to its original state, so tasks can wait again, until another signal. Note also, that unlike the previous example, the event here is not persistent. If no tasks are waiting when the signal arrives, it is lost. <syntaxhighlight lang="Ada"> protected Event is entry Wait; entry Signal; private entry Reset; Occurred: Boolean := False; end Event; protected body Event is entry Wait when Occurred is begin null; -- note null body end Wait; entry Signal when True is -- barrier is always true begin if Wait'Count > 0 then Occurred := True; requeue Reset; end if; end Signal; entry Reset when Wait'count = 0 is begin Occurred := False; end Reset; end Event;</syntaxhighlight> The intended use is that tasks wait for the event by calling <syntaxhighlight lang="Ada"> Event.Wait;</syntaxhighlight> and another task notifies them that the event has occurred by calling <syntaxhighlight lang="Ada"> Event.Signal;</syntaxhighlight> and this causes all currently waiting tasks to continue, and the event to be reset, so that future calls to Event.Wait will wait. The example works as follows. If a task calls Event.Wait, it will first seize the protected object lock. It will check Occurred, find it to be False, add itself to the entry queue, and release the lock. Several tasks might add themselves to the queue in this manner. Later, the signalling task might call Event.Signal. After seizing the lock, the task will execute the entry body (since its barrier is True). If no tasks are currently waiting, the task exits without updating the flag. Otherwise, it sets the flag to indicate that the event has occurred, and requeues itself on the Reset entry. (Reset is declared in the private part, because it is not intended to be used directly by clients of the protected object.) Before releasing the lock, the signalling task will check the queues. The barrier for Wait is now True. A task is chosen from the Wait queue, and allowed to proceed. Since the entry body for Wait does nothing, the flag will not change. (See the Real-Time Systems annex for the detailed rules for choosing among the tasks waiting in entry queues.) This sequence of events will be repeated until the entry queue for Wait is empty. When the Wait queue is finally empty (that is Wait'Count equals 0), the barrier of Reset is True, and the Reset body is executed, thereby resetting the flag. The queues are now empty, so the protected object lock is released. Note that implementations can optimize null entry bodies by releasing waiting tasks in one operation, when the barrier is true. Because the steps described in the last two paragraphs are executed with the protected object locked, any other tasks that try to Wait or Signal on that object during that time will have to wait for the queues to be emptied, as explained above. Furthermore, there are no race conditions because the value of the barrier cannot be changed between the time it is evaluated and the time the corresponding entry body is executed. The check for now-true barriers happens whenever the state of the protected object might have changed and, of course, before releasing the lock; that is, they happen just after executing the body of a protected procedure or protected entry. In summary * A requeue statement is only allowed in an entry body and an accept statement. The target entry may be (possibly the same entry) in the same task or protected object or in a different task or protected object. All combinations are possible. * Any actual parameters to the original call are passed to the new entry; therefore, the new entry must have the same parameter profile, or else no parameters at all. In the broadcast example, the requeue statement prevents a race condition that might otherwise occur. For example, if the signalling task were required to call Signal and Reset in sequence, then the releasing of waiting tasks would no longer be atomic. A task that tried to Wait in between the two calls of the signalling task, might have been released as well. It might even be the same task that was already released once by that Signal. We noted in Part One that this example was for illustration only and could be programmed without using requeue. Here is a possible solution which uses the Count attribute in barriers for both Wait and Signal. <syntaxhighlight lang="Ada"> protected Event is entry Wait; entry Signal; end Event; protected body Event is entry Wait when Signal'Count > 0 is begin null; end Wait; entry Signal when Wait'Count = 0 is begin null; end Signal; end Event;</syntaxhighlight> When the Wait entry is called, the caller will be blocked until some caller is enqueued on the Signal entry queue. When the Signal entry is called, the caller is queued if there are any waiters, then all the tasks on the Wait entry queue are resumed. The signaler is then dequeued and the entry call is complete. If there are no waiters when Signal is called, it returns immediately. This is an interesting solution. It works because the event of joining a queue is a protected action and results in the evaluation of barriers (just as they are evaluated when a protected procedure or entry body finishes). Note also that there is no protected data (and hence no private part) and that both entry bodies are null); in essence the protected data is the Count attributes and these therefore behave properly. In contrast, the Count attributes of task entries are not reliable because the actions of adding and joining task entry queues are not performed in any protected manner. === <span id="2-1">9.2.1 Preference Control</span> === Many real-time applications require preference control, where the ability to satisfy a request depends on the parameters passed in by the calling task and often also on the internal state of the server. Examples are * The server must serve higher-priority requests first, where the priority of the request is passed as an entry parameter. * A particular entry call is used to request any of several resources, where some resources might be available, while others are in use. An entry parameter indicates which of the resources the task is requesting. * Several copies of a resource may be allocated at once, where the calling task passes in the number of required resources. A specific instance of this situation is a memory allocator, where the resource is a block of storage units. The calling task asks for a particular number of storage units, and must wait until a contiguous portion of memory of at least the right size is available. It might be that a request for 100 storage units can be satisfied, whereas a request for 1000 storage units cannot. * The server is controlling a device that might be ready to serve some requests but not others. We now consider an example of the last situation. We have a disk device with a head that may be moved to different tracks. When a calling task wants to write to the disk at a particular place, the call may proceed immediately if the disk head is already on the right track. Otherwise, the disk manager tells the disk device to move the head. When the disk has moved the head, it generates an interrupt. While waiting for the interrupt, the calling task is blocked. Preference control can be implemented in Ada 95 using the requeue statement. The entry call proceeds whether it can be immediately satisfied or not. Then the server checks to see whether the request can be immediately satisfied by looking at the parameters. If it can, the request is processed, and the entry returns. If not, the request is requeued to another entry, to wait until conditions change. The preference control in our example is simple. We can satisfy requests for the current disk track, and queue the others. Since the disk address is passed in as an entry parameter, some calls to the Write entry can proceed, while others cannot. <syntaxhighlight lang="Ada"> protected Disk_Manager is entry Write(Where: Disk_Address; Data: Disk_Buffer); -- write data to the disk at the specified address entry Read(Where: Disk_Address; Data: out Disk_Buffer); -- read data from the disk at the specified address procedure Disk_Interrupt; -- called when the disk has interrupted, indicating -- that the disk head has moved to the correct track private entry Pending_Write(Where: Disk_Address; Data: Disk_Buffer); entry Pending_Read(Where: Disk_Address; Data: out Disk_Buffer); Current_Disk_Track: Disk_Track_Address := ...; -- track where the disk head currently is. Operation_Pending: Boolean := False; -- is an incomplete Read or Write operation pending? Disk_Interrupted: Boolean := False; -- has the disk responded to the move command with -- an interrupt? end Disk_Manager;</syntaxhighlight> In order to write on the disk, a task calls Disk_Manager.Write, passing the disk address and data as parameters. The Read operation is similar but the full details are omitted. The body of the protected object is as follows <syntaxhighlight lang="Ada"> protected body Disk_Manager is procedure Disk_Interrupt is begin Disk_Interrupted := True; -- release pending operations end Disk_Interrupt; entry Pending_Write(Where: Disk_Address; Data: Disk_Buffer) when Disk_Interrupted is begin Current_Disk_Track := Where.Track; -- we know that the disk head is at the right track. ... -- write Data to the disk Operation_Pending := False; -- allow Reads and Writes to proceed end Pending_Write; entry Write(Where: Disk_Address; Data: Disk_Buffer) when not Operation_Pending is begin if Where.Track = Current_Disk_Track then ... -- write Data to the disk else ... -- tell the disk to move to the right track Disk_Interrupted := False; Operation_Pending := True; -- prevent further Reads and Writes requeue Pending_Write; -- wait for the interrupt end if; end Write; entry Pending_Read(Where: Disk_Address; Data: out Disk_Buffer) when Disk_Interrupted is begin ... -- similar to Pending_Write end Pending_Read; entry Read(Where: Disk_Address; Data: out Disk_Buffer) when not Operation_Pending is begin ... -- similar to Write end Read; end Disk_Manager;</syntaxhighlight> The Write operation checks whether the disk head is already on the right track. If so, it writes the data and returns. If not, it sends a command to the disk telling it to move the head to the right track, and then requeues the caller on Pending_Write. It sets a flag to prevent intervening Write and Read operations. When the disk has completed the move-head command, it interrupts, causing the Disk_Interrupt operation to be invoked. The Disk_Interrupt operation sets the flag that allows the Pending_Write operation to proceed. We do not specify here how Disk_Interrupt gets called when the interrupt occurs. It might be attached directly to the interrupt, or some other interrupt handler might call it or set a flag in some other protected object that causes Disk_Interrupt to be called. A real disk manager would be more complicated; it would probably allow multiple pending requests, sorted by track number, the actual reading and writing might be interrupt driven (in addition to the disk head movement), and so on. But this simple version nevertheless illustrates the key features of preference control. The following points should be noted * One might think that an obvious way to implement preference control would be to make the entry barrier depend on the parameters of the entry. However, that is not allowed in order to permit efficient implementations and to avoid complex semantics for the user. Because the barriers do not depend on the formal parameters, the value of the barrier is the same for all callers of the same entry. This means that there is only one barrier value per entry, not one per entry call, so evaluation of barriers can be efficient. If the barrier expression can be evaluated in a bounded amount of time, as is usually the case, the programmer can calculate total worst-case barrier evaluation times based on the worst-case barrier evaluation times of each of the entries. * It is important that the decisions of when to service a request happen inside a protected operation, because these decisions are based on the protected object's local data, which, of course must be protected. The Ada 95 requeue mechanism achieves such protection. * The example works properly in the presence of abort and asynchronous transfer of control. For example, if a writing task is aborted while it is waiting on the Pending_Write queue, the abort will be deferred until after Pending_Write has been executed. On the other hand, the programmer might wish to allow the task to be aborted earlier. In that case, the requeue statement would take the form requeue Pending_Write with abort; * and then the protected body would have to be written in such a way that callers can silently disappear from the Pending_Write queue without disruption. (The barriers would have to depend upon Pending_Write'Count.) * In Ada 83, an extra "agent" task was required to "hold" the call in examples such as this. In order to correctly handle abort and asynchronous transfer of control, and still handle multiple outstanding requests, the agent tasks had to be created dynamically, as necessary. Such agent tasks were too expensive for many applications, and their timing behavior was rather unpredictable. * Other methods in Ada 83 required exporting several entries that had to be called in a particular order. This violated information- hiding principles, and caused race conditions, because events could occur between the multiple calls. * The information-hiding objection could be answered by putting the task in a package, and putting the correct pattern of entry calls in a procedure exported from the package, thus enforcing the required protocol. But then, the resulting exported procedure could not be used in timed, conditional, and selective entry calls. * Other solutions to the race problems generally required the requesting task to poll the server, which was inefficient and nondeterministic, in addition to being error-prone. == <span id="3">9.3 Timing</span> == Ada 83 was unhelpful in the area of timing by notionally providing only one clock that could be used directly for delaying a task or timing an operation. Furthermore, the Ada 83 delay statement required a duration, rather than a wakeup time, making it difficult for a task to wake up at perfectly regular intervals as explained in II.10. In Ada 95, the delay statement is augmented by a delay until statement. The delay until statement takes the wakeup time rather than a duration as its argument. Furthermore, the Real-Time Systems annex defines the package Ada.Real_Time which contains an additional time type Real_Time.Time with an accompanying function Real_Time.Clock, which may be used in a delay until statement. The type Real_Time.Time is intended to represent a real-time clock with potentially finer granularity than the time-of-day clock associated with Calendar.Time. Furthermore, the value returned by Real_Time.Clock is guaranteed to be monotonically non-decreasing, whereas the time-of-day Calendar.Clock may jump forward or backward due to resetting of the time by a human operator (perhaps in response to a change of time-zone or daylight saving). The following example shows a task that awakens each night at midnight and performs some logging function. <syntaxhighlight lang="Ada"> task body At_Midnight is One_Day : constant Calendar.Day_Duration := 86_400.0; Now : Calendar.Time := Calendar.Clock; Midnight: Calendar.Time := Calendar.Time_Of( Year => Calendar.Year(Now), Month => Calendar.Month(Now), Day => Calendar.Day(Now), Seconds => 0.0); -- truncate current time to most recent midnight begin loop Midnight := Midnight + One_Day; delay until Midnight; Log_Data; end loop; end At_Midnight;</syntaxhighlight> Since the delay until expression specifies an absolute time rather than a time interval, there is no opportunity for preemption during the calculation of the interval, and therefore the delay will expire at precisely the time that is specified. Note furthermore that since the delay is written in terms of the time- of-day clock in the package Calendar, if the time-of-day clock is changed to daylight saving time (or perhaps the cruise liner moves over a time zone), the delay expiration time might be according to the new setting of the clock (although this is not guaranteed). As a further example we present a task that polls a device every 10 milliseconds. <syntaxhighlight lang="Ada"> task body Poll_Device is use Ada; Poll_Time: Real_Time.Time := time to start polling; Period: constant Real_Time.Time_Span := Real_Time.Milliseconds(10); begin loop delay until Poll_Time; ... -- Poll the device Poll_Time := Poll_Time + Period; end loop; end Poll_Device;</syntaxhighlight> In this case the Poll_Device task polls the device every 10 milliseconds starting at the initial value of Poll_Time. The period will not drift, as explained above for the At_Midnight example. We use Real_Time.Time instead of Calendar.Time in this example, because we do not wish to be sensitive to possible changes to the time-of-day clock. The existing (relative) delay statement only takes a value of the type Duration; the basis for relative delays is not necessarily that of the clock in the package Calendar and should be monotonic. The general idea is that relative delays should not be disturbed by a shift in the time base. A ten minute delay still means just that even if the clock moves forward. Finally note that in Ada 95 the package Calendar is a child of Ada. For compatibility it is also renamed as Standard.Calendar (all such existing library units in Ada 83 are similarly renamed for compatibility). == <span id="4">9.4 Asynchronous Transfer of Control</span> == Asynchronous transfer of control was identified as an important requirement for Ada 95 (Requirement R5.3-A(1)). In Ada 83, the only way to asynchronously change the execution path of a task was to abort it. However, in many applications, it is desirable that an external event be able to cause a task to begin execution at a new point, without the task as a whole being aborted and restarted. As an example of asynchronous transfer of control, consider an interactive program where the user may choose to terminate a given operation and begin a new one. This is normally signaled by typing a special key or hitting a special button associated with the controlling input device. The user does not want the entire context of the running program to be lost. Furthermore, for a long-running system, it is important that the resources associated with the interrupted processing be reclaimed. This implies that some mechanism for "cleaning up" be available as part of the asynchronous transfer process. Finally, if the abortable operation is updating some global data structure, it is essential to temporarily defer any asynchronous transfers until after the update is complete. As was briefly explained in II.10, Ada 95 has a form of select statement with an abortable part and a triggering alternative to support asynchronous transfer of control. We showed a simple example where a computation was abandoned if it could not be completed within a stated period of time. In essence the triggering statement and the abortable part execute in parallel and whichever finishes first causes the other to be abandoned. If the triggering statement completes before the abortable part, then the abortable part is abandoned and control passes to the sequence of statements following the triggering statement. On the other hand, if the abortable part completes before the triggering statement then the triggering alternative is abandoned. The important point is that we only need one thread of control. Waiting for a delay or waiting on an entry queue do not require a separate thread. Moreover, when a task entry is accepted it is the called task which executes the accept statement and even in the case of a protected entry it will often be another task which executes the entry body. So the abortable part can generally continue during the execution of the triggering statement. It is only when the entry call finally returns (or the delay expires) that the abortable part has to be abandoned. For full details of the mechanism see [RM95 9.7.4]. By supporting asynchronous transfer of control as a form of select statement, several useful properties are provided * The statements that are abortable are clearly bracketed in the abortable part. * The asynchronous transfer of control is directly tied to the acceptance of an entry call or the expiration of a delay. This allows the transfer to occur without requiring an additional task to explicitly signal the occurrence of the triggering event; this is in contrast to what is possible with abort. * Nesting of abortable regions (which are potentially "sensitive" to different events) and protecting code in these regions from interruption, is naturally achieved by the select construct and protected types. * The asynchronous transfer cannot be mistakenly redirected by a local handler, as might happen with a mechanism based on asynchronous exceptions. Here is an example of a database transaction using asynchronous transfer of control. The database operation may be cancelled by typing a special key on the input device. However, once the transaction has begun (is committed), the operation may not be cancelled. <syntaxhighlight lang="Ada"> with Ada.Finalization; use Ada; package Txn_Pkg is type Txn_Status is (Incomplete, Failed, Succeeded); type Transaction is new Finalization.Limited_Controlled with private; -- Transaction is a controlled type as discussed in 7.4 procedure Finalize(Txn: in out Transaction); procedure Set_Status(Txn: in out Transaction; Status: Txn_Status); private type Transaction is new Finalization.Limited_Controlled with record Status: Txn_Status := Incomplete; pragma Atomic (Status); ... -- More components end record; end Txn_Pkg; package body Txn_Pkg is procedure Finalize(Txn: in out Transaction) is begin -- Finalization runs with abort and ATC deferred if Txn.Status = Succeeded then Commit(Txn); else Rollback(Txn); end if; end Finalize; procedure Set_Status(Txn: in out Transaction); Status: Txn_Status) is begin Txn.Status := Status; end Set_Status; end Txn_Pkg;</syntaxhighlight> The package might be used as in the following <syntaxhighlight lang="Ada"> declare Database_Txn: Transaction; -- declare a transaction, will commit or abort -- during finalization begin select -- wait for a cancel key from the input device Input_Device.Wait_For_Cancel; -- the Status remains Incomplete, so that -- the transaction will not commit then abort -- do the transaction Read(Database_Txn, ...); Write(Database_Txn, ...); ... Set_Status(Database_Txn, Succeeded); -- set status to ensure the transaction is committed exception when others => Put_Line("Operation failed with unhandled exception"); -- set status to cause transaction to be aborted Set_Status(Database_Txn, Failed); end select; -- Finalize on Database_Txn will be called here and, -- based on the recorded status, will either commit or -- abort the transaction. end;</syntaxhighlight> This illustrates the use of controlled types and asynchronous transfer of control. At the end of the block, the Finalize operation is called and this will uniquely either rollback the transaction or commit to it. Note in particular the use of the pragma Atomic; this is described in the Systems Programming annex. Note also that the Finalization is always performed with abort and ATC deferred so that no unfortunate interactions can occur. The final example shows how asynchronous transfer of control can be used in a real-time application. Current_Coordinates is periodically updated with a new set of computed coordinates. A user task (not shown) can call Read as needed to get the most recently computed coordinates, which might then be used to control an external device. <syntaxhighlight lang="Ada"> protected Current_Coordinates is procedure Update(New_Val: Coordinates); -- used by the computing task only function Read return Coordinates; -- used by whoever needs the result private Current_Value: Coordinates; end Current_Coordinates; protected Controller is entry Wait_For_Overrun; -- called by the computing task procedure Set_Overrun; -- called by an executive or interrupt handler private Overrun_Occurred: Boolean := False; end Controller;</syntaxhighlight> The protected object Current_Coordinates provides mutually exclusive access to the most recently calculated coordinates. The protected object Controller provides an entry for detecting overruns, designed to be called in the triggering alternative of an asynchronous select statement as shown below. The following is the body of the Calculate task, which loops, progressively improving the estimate of the coordinates, until its time allotment expires, or the estimate stabilizes. <syntaxhighlight lang="Ada"> task body Calculate is Problem: Problem_Defn; begin Get_Problem(Problem); select Controller.Wait_For_Overrun; -- triggering alternative then abort declare Answer: Coordinates := Initial_Value; Temp : Coordinates; begin Current_Coordinates.Update(Answer); loop -- loop until estimate stabilizes Temp := Answer; Track_Computation.Improve_Estimate(Problem, Answer); Current_Coordinates.Update(Answer); exit when Distance(Answer, Temp) <= Epsilon; end loop; end; end select; end Calculate;</syntaxhighlight> The Calculate task sets the value of the Current_Coordinates initially, and then repeatedly calls Track_Computation.Improve_Estimate, which is presumably a time-consuming procedure that calculates a better estimate of the coordinates. Calculate stops looping when it decides that the estimate has stabilized. However, it may be that Improve_Estimate takes too long, or the system undergoes a mode change that requires the use of the current best estimate. There is presumably an executive or interrupt handler that notices such a situation and calls Controller.Set_Overrun. When that happens, the Calculate task does an asynchronous transfer of control thereby ending the computation loop. We now show a possible (partial) implementation of the Improve_Estimate subprogram. It depends on some work area that has a dynamic size, that can be allocated, lengthened, and deallocated. Improve_Estimate allocates the work area, and tries to compute the result. However, the computation of the result may fail, requiring a larger work area. Therefore, Improve_Estimate loops until it succeeds or the time expires or some resource is exhausted. <syntaxhighlight lang="Ada"> with Ada.Finalization; use Ada; package body Track_Computation is -- This package includes a procedure Improve_Estimate for -- progressively calculating a better estimate of the coordinates. -- buffer is used for a work area to compute new coordinates type Buffer_Size is range 0 .. Max; type Buffer is ... type Buffer_Ptr is access Buffer; type Work_Area is new Finalization.Limited_Controlled with record Buf: Buffer_Ptr; end record; -- these procedures allocate a work area of a given size, -- and reallocate a longer work area procedure Allocate_Work_Area( Area: in out Work_Area; Size: in Buffer_Size) is ... procedure Lengthen_Work_Area( Area : in out Work_Area; Amount: in Buffer_Size) is ... -- this procedure is called automatically on scope exit, -- and deallocates the buffer designated by Area.Buf procedure Finalize(Area: in out Work_Area) is ... procedure Improve_Estimate( Problem: in Problem_Defn; Answer : in out Coordinates) is -- calculate a better estimate, given the old estimate Initial_Size: Buffer_Size := Estimate_Size(Problem); -- compute expected work area size, based on problem definition Work_Buffer: Work_Area; begin Allocate_Work_Area(Work_Buffer, Initial_Size); loop begin ... -- compute better estimate Answer := ...; exit; -- computation succeeded exception when Work_Area_Too_Small => -- the Problem requires a larger work area Lengthen_Work_Area(Work_Buffer, Size_Increment); -- now loop around to try again end; end loop; -- Work_Buffer is automatically deallocated by -- finalization on exit from the scope end Improve_Estimate; end Track_Computation;</syntaxhighlight> Since it is important that the work area be deallocated when the asynchronous transfer of control occurs, Work_Area is derived from Finalization.Limited_Controlled so that a Finalize procedure can be defined. This provides automatic clean up on scope exit. Note that the Calculate task does not (and should not) need to know about the implementation details of Improve_Estimate. Therefore, it is not feasible to put the call on Finalize(Work_Buffer) in Calculate. Furthermore, Allocate_Work_Area might not use a normal Ada allocator. It might be allocating from some static data structure. In any case, it is important to reclaim the resources allocated to the work area when the processing is complete or aborted. Aborts and asynchronous transfers of control are deferred when a task is performing a protected subprogram or entry call, or during an initialization or finalization operation on an object of a controlled type. The programmer has complete control over the amount of code that should be placed in such abort-deferred regions. Typically, such regions should be kept short. == <span id="5">9.5 The Abort Statement</span> == In Ada 95, it is essential that use of the abort statement, and, more importantly, the asynchronous select statement with its abortable part, not result in corruption of global data structures. In Ada 83, abort was deferred for a calling task while it was engaged in a rendezvous. This allowed the rendezvous to complete normally so that the data structures managed by the accepting task were not left in an indeterminate state just because one of its callers was aborted. For Ada 95, we have generalized this deferral of abort to include the time during which calls on protected operations are being serviced, and the initialization, assignment and finalization of controlled types (see 7.4). (However, we recall that requeue with abort allows a server to override deferral if desired as explained in 9.2.) Without deferral of abort, any update of a global data structure becomes extremely unsafe, if not impossible. Ultimately all updates are forced into a two-phase approach, where updates are first performed into unused storage, and then the final commitment of a change involves a single atomic store, typically of a pointer of some sort. Such an approach can be extremely cumbersome, and very inefficient for large data structures. In most cases, it is much simpler and efficient to selectively defer asynchronous transfers or aborts, rather than to allow them at any moment. In addition to deferring abort, it is important to be able to reclaim resources allocated to constructs being aborted. The support for user- defined initialization and finalization of controlled types provides the primitives necessary to perform appropriate resource reclamation, even in the presence of abort and asynchronous transfers. Reclaiming local storage resources is of course important. However, releasing resources is even more critical for a program involved in communicating with an external subsystem, such as a remote database or other server. For a short-lived program, running on a conventional time- shared operating system, with no contact with external subsystems, it might be argued that there is no need to provide user-defined finalization that runs even when the task is aborted or is "directed" to execute an asynchronous transfer of control. However, for a long-running program, with limited memory, and which is possibly communicating with external subsystems, it is crucial that relatively local events like an asynchronous transfer not undermine global resource management. In general, the discussion in [RM95] is unified so that aborting a task and aborting a sequence of statements (as in ATC) are described together. == <span id="6">9.6 Tasking and Discriminants</span> == In Ada 95, we have generalized discriminants so that they are applicable to task types and protected types as well as to records. This allows tasks and protected objects to be parameterized when they are declared. An example of a protected type with a discriminant is the Counting_Semaphore in II.9. The discriminant indicates the number of items in the resource being guarded by the semaphore. Discriminants of tasks can be used to set the priority, storage size and size of entry families of individual tasks of a type. In the case of storage size this is done with the new pragma Storage_Size by analogy with the pragma Priority. (Note that an attribute definition clause could only be applied to all tasks of a type; the use of such an attribute definition clause for setting the storage size is now obsolescent.) Of more importance is the ability to indicate the data associated with a task; this obviates the need for an initial rendezvous with a task and can eliminate or at least reduce any bottleneck in the parallel activation of tasks. For example, in a numerical application we might have an array of tasks each of which works on some data. In each case the data will be shared with an adjacent task and so can be conveniently accessed through a protected object. The tasks do not therefore need to communicate with each other directly but just with the protected objects. We might write <syntaxhighlight lang="Ada"> subtype Data_Range is Integer range 0 .. 1000; subtype Task_Range is Data_Range range Data_Range'First+1 .. Data_Range'Last-1; protected type Data_Point is procedure Put(New_Value: in Data); procedure Get(Current_Value: out Data); private -- the protected data end; ... The_Data: array (Data_Range) of Data_Point; function Next_One return Task_Range; ... task type Computer(Index: Task_Range := Next_One); The_Tasks: array (Task_Range) of Computer;</syntaxhighlight> where we assume that the data at the end-points of the range is fixed (the boundary conditions) and so no task is associated with these. Successive calls of the function Next_One deliver the unique values throughout the task range. This guarantees that each task has a unique value of the discriminant Index although this might not correspond to its index position in the array since the components can be initialized in any order. However, they are not permitted to be initialized in parallel and so there is no need for the function Next_One to take any action to prevent parallel calls. Each task can then use its discriminant Index to access the data in the protected objects. An access discriminant is particularly useful for indicating the data associated with a task. We could write <syntaxhighlight lang="Ada"> type Task_Data is record ... -- data for task to work on end record; task type Worker(D: access Task_Data) is ... end;</syntaxhighlight> and then inside the body of Worker we can get hold of the data via the access discriminant D. The data is associated with a particular task in its declaration <syntaxhighlight lang="Ada"> Data_For_Joe: aliased Task_Data := ... Joe: Worker(Data_For_Joe'Access);</syntaxhighlight> where we note that the data has to be marked as aliased. An advantage of access discriminants is that they are constants and cannot be detached from the task; hence the task and its data are securely bound together. We recall from 3.7.1 that there are consequently no access checks on the use of an access discriminant. An alternative approach is to embed the task inside the data. We can then use the self-referential technique described in 4.6.3. <syntaxhighlight lang="Ada"> type Task_And_Data is limited record ... -- some data Jobber: Worker(Task_And_Data'Access); end record;</syntaxhighlight> We can use similar techniques with protected objects. The data logically protected by a protected object need not be directly inside the protected object. It could be indicated by an access discriminant. For example <syntaxhighlight lang="Ada"> type Resource is record Counter: Integer; ... end record; protected type Guardian(R: access Resource) is procedure Increment; ... end Guardian; protected body Guardian is procedure Increment is begin R.Counter := R.Counter + 1; end Increment; ... end Guardian;</syntaxhighlight> and then within the bodies of protected procedures such as Increment we can access the data of type Resource in a safe manner. We declare a particular protected object thus <syntaxhighlight lang="Ada"> My_Resource: aliased Resource := ... .. My_Object: Guardian(My_Resource'Access); ... My_Object.Increment;</syntaxhighlight> Clearly this approach can be used with any standard protected object such as the mailbox discussed in 9.1.2. === <span id="6-1">9.6.1 Interaction with OOP</span> === Tasks and protected objects may appear at first sight to be concerned with aspects of programming quite alien to the concepts associated with object oriented programming such as type extension and dispatching. For example, it is not possible to extend a protected type with additional protected operations (this was considered at conflict with other considerations such as efficiency). However, although indeed an orthogonal part of the language, tasks and protected objects work together with tagged types in a remarkable way. Thus we can create structures with both synchronization and extension properties where protected objects or tasks provide the synchronization aspects and tagged types provide extension aspects. For example, a task or protected object may be a component of a tagged object or conversely may contain a tagged object internally. A powerful construction is where a task or protected object has a class-wide access discriminant that references a tagged object. In this section we give some examples of the use of access discriminants in this way. The first example illustrates how a task type can provide a template for a variety of related activities with the details filled in with dispatching calls. (Remember from the discussion in 3.7.1 and 4.4.4 that type extension provides a flexible means of parameterizing a general activity such as the use of an iterator.) Suppose that we wish to perform a number of activities that have the general pattern of performing some job a certain number of times at intervals with perhaps some initial and final actions as well. We can also make provision for a general purpose exception handling mechanism. A suitable task type might be <syntaxhighlight lang="Ada"> task type T(Job: access Job_Descriptor'Class); task body T is begin Start(Job); for I in 1 .. Iterations(Job) loop delay Interval(Job); Do_It(Job, I); end loop; Finish(Job); exception when Event: others => Handle_Failure(Job, Event); end T;</syntaxhighlight> Note carefully that the access discriminant Job is class-wide so that dispatching can occur. The various subprograms Start, Iterations, Interval, Do_It, Finish and Handle_Failure are all dispatching operations of the type Job_Descriptor and might be declared as follows. <syntaxhighlight lang="Ada"> package Base_Job is type Job_Descriptor is abstract tagged null record; procedure Start(J: access Job_Descriptor); function Iterations(J: access Job_Descriptor) return Integer is abstract; function Interval(J: access Job_Descriptor) return Duration is abstract; procedure Do_It(J: access Job_Descriptor; I: Integer) is abstract; procedure Finish(J: access Job_Descriptor); procedure Handle_Failure(J: access Job_Descriptor; E: Exception_Occurrence); end Base_Job;</syntaxhighlight> We have made most of the operations abstract so that the user is forced to provide nonabstract versions but have chosen to make Start and Finish just null since that is an obvious default. A convenient default for Handle_Failure would also seem appropriate. Observe that the various operations dispatch on an access parameter. It would have been possible for the parameters to be just in parameters but then the actual parameters would have had to be Job.all in the various calls. (If we wanted write access to Job then the parameters would have to be in out or access parameters; see 6.1.2 for a discussion on the merits of one versus the other. Moreover, we might make the parameters of Iterations and Interval of mode in just to emphasize that they are read only operations.) A demonstration task to output a message ten times with one minute intervals might be produced by writing <syntaxhighlight lang="Ada"> with Base_Job; use Base_Job; package Demo_Stuff is type Demo is new Job_Descriptor with null record; function Iterations(D: access Demo) return Integer; function Interval(D: access Demo) return Duration; procedure Do_It(D: access Demo; I: Integer); end; package body Demo_Stuff is function Iterations(D: access Demo) return Integer is begin return 10; end Iterations; function Interval(D: access Demo) return Duration is begin return 60.0; end Interval; procedure Do_It(D: access Demo; I: Integer) is begin New_Line; Put("This is number "); Put(I); end Do_It; end Demo_Stuff; ... The_Demo: Demo; -- data for the demo The_Demo_Task: T(The_Demo'Access); -- create the task</syntaxhighlight> This somewhat pathetic demonstration task always does the same thing since there is actually no data in the type Demo. All the object The_Demo does is indicate through its tag the particular subprograms to be called by dispatching. Thus the type Demo is simply a tag. A more exciting demonstration might be created by giving the type some components indicating the number of iterations and the interval. The procedure Start might then check that the demonstration would not take too long (five minutes would be quite enough!) and, if necessary, by raising an exception cause the demonstration to be cancelled and a suitable message output. This might be written as <syntaxhighlight lang="Ada"> package Better_Demo_Stuff is type Better_Demo is new Job_Descriptor with record The_Iterations: Integer; The_Interval: Duration; end record; Silly_Demo: exception; ... end; package body Better_Demo_Stuff is function Iterations(D: access Better_Demo) return Integer is begin return D.The_Iterations; end Iterations; ... procedure Start(D: access Better_Demo) is begin if D.The_Iterations * D.The_Interval > 300.0 then Raise_Exception(Silly_Demo'Identity, "Sorry; too long"); end if; end Start; procedure Handle_Failure(D: access Better_Demo; E: Exception_Occurrence) is begin Put_Line("Demonstration not executed because: "); Put_Line(Exception_Message(E)); end Handle_Failure; end Better_Demo_Stuff;</syntaxhighlight> For illustrative purposes we have passed the message to be output using the exception message mechanism discussed in 11.2. Although our example has been merely a simple demonstration nevertheless the approach could be used to much effect in simulations and related applications. By using type extension, unnecessary repetition of common code is avoided. The next example illustrates how a class of types plus associated protocols originally developed for a non-tasking environment can be encapsulated as a protected type. Again the key is the use of a class- wide access discriminant. Suppose we have a queuing protocol defined by <syntaxhighlight lang="Ada"> type Queue is abstract tagged null record; function Is_Empty(Q: in Queue) return Boolean is abstract; function Is_Full(Q: in Queue) return Boolean is abstract; procedure Add_To_Queue(Q: access Queue; X: Queue_Data) is abstract; procedure Remove_From_Queue(Q: access Queue; X: out Queue_Data) is abstract;</syntaxhighlight> Observe that this describes a whole class of queue types. An existent Queue need only supply bodies for these four operations. Incidentally Is_Empty and Is_Full take in parameters since they do not modify the queue whereas Add_To_Queue and Remove_From_Queue take access parameters because they do modify the queue. This protocol is similar to the generic package in 4.4.1 except that we have assumed that we know the anticipated specific type when removing items from the queue. A general protection template is provided by <syntaxhighlight lang="Ada"> protected type PQ(Q: access Queue'Class) is entry Put(X: in Queue_Data); entry Get(X: out Queue_Data); end; protected body PQ is entry Put(X: in Queue_Data) when not Is_Full(Q.all) is begin Add_To_Queue(Q, X); end Put; entry Get(X: out Queue_Data) when not Is_Empty(Q.all) is begin Remove_From_Queue(Q, X); end Get; end PQ;</syntaxhighlight> Interference between operations on a queue is prevented by the natural mechanism of the protected type. Moreover, the functions Is_Empty and Is_Full (originally provided to enable the user of the non-tasking protocol to guard against misuse of the queue) can now be sensibly used as barriers to ensure that a user is automatically prevented from misuse of a queue. Note that the particular queue is identified by the access discriminant. The user can now define a particular implementation of a queue by type extension such as <syntaxhighlight lang="Ada"> type My_Queue is new Queue with private; function Is_Empty(Q: My_Queue) return Boolean; ...</syntaxhighlight> and then declare and use a protected queue as follows <syntaxhighlight lang="Ada"> Raw_Queue: aliased My_Queue; My_Protected_Queue: PQ(Raw_Queue'Access); ... My_Protected_Queue.Put(An_Item);</syntaxhighlight> The unprotected queue object provides the value of the access discriminant for the protected object. Operations upon the protected queue are performed as expected by normal entry calls. == <span id="7">9.7 Other Improvements</span> == An improvement to the syntax allows entries and representation clauses to be in an arbitrary order in a task specification; previously all entries had to precede all representation clauses. There are a number of other aspects of the control of tasks that are dealt with in the Systems Programming and the Real-Time Systems annexes. These cover topics such as the identification of tasks, task attributes, the handling of interrupts and the control of priorities. For a discussion on these topics the reader is referred to Part Three of this rationale. == <span id="8">9.8 Requirements Summary</span> == The requirement * R2.2-A(1) - Reduce Deterrents to Efficiency is very clearly addressed by the introduction of protected objects. The requirements * R5.1-A(1) - Elapsed Time Measurement * R5.1-B(1) - Precise Periodic Execution are met by the introduction of Real_Time.Time and the delay until statement (see 9.3). The requirement * R5.2-A(1) - Alternative Scheduling Algorithms is generally addressed by the Real-Time Systems annex and is thus discussed in Part Three. A related aspect is selection from entry queues. The rather general requirement * R5.2-A(2) - Common Real-Time Paradigms is met variously by the protected type, the requeue statement, and the asynchronous select in the core language and the facilities for priority control in the Real-Time Systems annex. The requirements * R5.3-A(1) - Asynchronous Transfer of Control * R5.1-C(1) - Detection of Missed Deadlines are met by the asynchronous select statement discussed in 9.4. The requirement for * R5.4-A(1) - Non-Blocking Communication can be met by the use of a protected record as a mailbox buffer. The study topic * S5.4-B(1) - Asynchronous Multicast can be met in various ways using protected objects as building blocks. The requirements * R6.3-A(1) - Interrupt Servicing * R6.3-A(2) - Interrupt Binding are of great concern to hard real-time programs. They are addressed in detail by the Systems Programming annex. The study topic * S7.2-A(1) - Managing Large Numbers of Tasks is addressed by the introduction of task discriminants; see 9.6. Finally, it should be noted that the two study topics * S7.3-A(1) - Statement Level Parallelism * S7.4-A(1) - Configuration of Parallel Programs which relate to vector processing are not directly addressed by any features in the language. However, the rules for the interaction between exceptions and optimization have been relaxed [RM95 11.6] so that implementers should be able to add appropriate pragmas to allow statement level parallelism. Mechanisms for controlling the configuration of parallel programs are clearly outside the scope of the language itself. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-8|Previous]] | [[Guide:9x_rationale/rat95-p2-10|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=9 Tasking}} jq5supn67t99yn8koec3dchaclzqmx4 Guide:9x rationale/rat95-p3 4200 344 1857 1829 2019-04-20T16:19:57Z WikiVisor 11 Text replacement - "[[Guide:9x_rationale/rat95-copyright|Copyright]] | " to "<div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | " wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-13|Previous]] | [[Guide:9x_rationale/rat95-p3-a|Next]]</div> ''The first two parts should have given the reader a good understanding of the Core of Ada 95. This third part describes the material in the Annexes. This includes the predefined environment which is mandatory, as well as the various specialized annexes themselves. It should be noted as a general principle that the annexes contain no new syntax. They are hence largely a description of various packages, attributes and pragmas.'' <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p2-13|Previous]] | [[Guide:9x_rationale/rat95-p3-a|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=Part Three. The Annexes}} jgxgkvf0rlrnthmb70i4ev3l6bm6eds Guide:9x rationale/rat95-p3-a 4200 345 1864 1858 2019-04-20T16:20:25Z WikiVisor 11 Text replacement - "[[Guide:9x_rationale/rat95-copyright|Copyright]] | " to "<div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | " wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p3|Previous]] | [[Guide:9x_rationale/rat95-p3-b|Next]]</div> One of the main objectives of Ada 95 is to supply a set of supplemental packages of general utility in order to promote portability and reusability. Several packages are essentially intrinsic to the language (such as Ada.Finalization) and are discussed in Part Two. This chapter explains the main design decisions behind the packages described in Annex A of [RM95]. It should be noted that input-output which appeared in chapter 14 of the Ada 83 reference manual [ANSI 83, ISO 87] now appears in Annex A. This move is designed to emphasize that input-output is just one of many facilities provided by the predefined environment and is not really an intrinsic part of the language. As mentioned in II.13, the predefined library is structured into three packages, Ada, Interfaces and System which can be thought of as child packages of Standard. The main reason for the restructuring is to avoid contamination of the top level name space and consequent risk of clashes with library units defined by the user. The package System concerns intrinsic facilities associated with the target machine and with storage management and is discussed in Chapter 13. The package Interfaces concerns communication with systems in other languages and also the interface to hardware numeric types. All other predefined packages including input-output are children of Ada. The major additions to the predefined environment compared with Ada 83 are as follows: * The packages Ada.Characters and Ada.Strings provide general facilities for the manipulation of characters and strings. * The package Ada.Numerics provides elementary functions and random number generation. * There are new packages for completely heterogeneous input-output streams. * The additional mode Append_File is provided for Ada.Sequential_IO and Ada.Text_IO. * Improvements to Text_IO include facilities for looking ahead at the next character, for getting the next character (from the keyboard) without buffering or blocking, and to flush an output buffer. In addition the procedure Get now accepts a wider variety of numeric formats. * The package Ada.Wide_Text_IO provides text input-output based on the types Wide_Character and Wide_String. Both Text_IO and Wide_Text_IO also have internal packages for modular and decimal input-output. * The concept of a current error file is introduced in Text_IO by analogy with the current output file. Additional subprograms are added to manipulate current input, output and error in a convenient manner. * The package Ada.Command_Line enables a program to access any arguments of the command which invoked it and to return an exit status. In order to avoid incompatibility problems, renamings are provided for packages existing in Ada 83 such as <syntaxhighlight lang="Ada"> with Ada.Text_IO; package Text_IO renames Ada.Text_IO;</syntaxhighlight> These renamings are considered obsolescent and thus liable to be removed at the next revision of the language. == <span id="1">A.1 Character Handling</span> == Ada 95 provides an empty parent package Ada.Characters with two children: a package of character categorization and conversion subprograms, Characters.Handling, and a child package of constants, Characters.Latin_1, corresponding to the values of type Character. The intent is to provide basic character handling facilities, similar in scope to the contents of the standard C library header [Plauger 92]. The following were the major issues concerning the design of this package: * Which kinds of classification functions to supply; * What to provide for Wide_Character handling; * Whether to have an analogue to the package Standard.ASCII, extended to account for characters in the "upper half" of the character set; * What to do about localization. We had considered declaring the character handling subprograms directly in the package Ada.Characters. However, with such an approach there was some concern that an application needing access only to the constants in Characters.Latin_1 would incur a code-space penalty if the subprograms in the parent package were bound into the application. Placing the subprograms in a child package addresses this concern. === <span id="1-1">A.1.1 Classification Functions</span> === A preliminary design of the character handling package was based heavily on C's . Although some of the classification functions are directly applicable, such as testing if a character is a digit, or testing if it is a letter, it was soon apparent that the C model was not completely appropriate for Ada 95. The main issue is that Ada 95, unlike C, has Latin-1 as its default standard character type. Thus the categorization functions such as ispunct(c) and isspace(c) would have no standard meaning in Latin-1. Moreover, relies on the C approach to locale, which is rather complicated and has not been adopted by Ada 95. The categorization functions in Characters.Handling are designed to reflect more the properties of Latin-1 than the heritage of . Most of the categorizations form a hierarchy: * Each character is either a control or graphic character * Each graphic character is either an alphanumeric or a special graphic * Each alphanumeric is either a letter or a decimal digit * Each letter is either an upper- or lower-case letter Supplementing these are further categories; for example a basic character (one without diacritical marks), a hexadecimal digit, and an ISO_646 character (whose position is in the range 0..127). === <span id="1-2">A.1.2 Wide_Character Handling</span> === There is a single classification function for Wide_Character, namely a test if a value is within the Character subset of the type. We had considered providing additional classification functions for Wide_Character, but this would be premature since there is no widespread agreement on how such functions might be defined. The Characters.Handling package provides a conversion from Wide_Character to Character, and from Wide_String to String, that leaves a Character value unchanged and that replaces a value outside the Character range with a (programmer-specifiable) value inside this range. === <span id="1-3">A.1.3 Package of Character Names</span> === The Ada 83 package Standard.ASCII declares a set of constants for the control characters (those whose positions are in the range 0 .. 31, and also the character at position 127), the lower-case letters, and some of the other graphic characters. The contents of this package are a rather uneven mixture, and different motivations led to the inclusion of different parts. The constants corresponding to the control characters are needed, since otherwise references to such characters would have to be in terms of Character'Val(number), which is not in the spirit of the language. It is accepted practice to use ASCII.Nul, ASCII.CR, and ASCII.LF in Ada programs. On the other hand, the inclusion of constants for the lower-case letters is principally a concession to the fact that, in the early 1980's, the input devices used in some environments did not support upper-case characters. To simulate a string literal such as "Abc" the programmer can write "A" & ASCII.LC_B & ASCII.LC_C. For Ada 95, the issues were what to do about the package Standard.ASCII, and what to do about names of the characters in the "upper half" (those whose positions are in the range 128 .. 255). Part of the problem surrounding Standard.ASCII is due to the fact that the name "ASCII" now no longer refers to a 7-bit character set, but rather to ISO 8859-1 (Latin-1). Thus perhaps the most consistent approach would be to add to Standard.ASCII the declarations of names for "upper half" characters, and to introduce renamings where relevant in order to be consistent with ISO nomenclature (for example, Reverse_Solidus as a renaming of Back_Slash). However, this would have the significant disadvantage of introducing a large number of declarations into Standard. Even though they would be in an inner package (and thus not pollute the user's namespace), there was concern that such a specialized package would be out of place if included in package Standard. These considerations led to the declaration of the child package Characters.Latin_1. This package includes names of the control characters from ISO 646 (the same names as in Standard.ASCII), the graphic characters from ISO 646 excepting the upper case letters and the decimal digits, the control characters from ISO 6429, and the graphic characters in the "upper half". The names of the graphics are based on Latin-1; hence Number_Sign for '#', as opposed to Sharp as in Standard.ASCII. Since Characters.Latin_1 is in the predefined environment, it must be supported by all implementations. Although there is some overlap between Characters.Latin_1 and Standard.ASCII, we expect that new Ada 95 programs will refer to the former, whereas existing Ada 83 code that is being moved intact to Ada 95 will continue to use the latter. In fact, the main reason to retain Standard.ASCII at all is for upward compatibility; removing it from the language would have been a major incompatibility and was not a realistic design alternative. Instead, it is specified as an obsolescent feature and its declaration appears in [RM95 J]. We recognize that names such as Ada.Characters.Latin_1.Nul are notationally rather heavy. However, we expect that users will typically provide renamings (either at the library level or as local declarations) such as <syntaxhighlight lang="Ada"> package Latin_1 renames Ada.Characters.Latin_1;</syntaxhighlight> and thus in practice the references will be of the more palatable form Latin_1.Nul. === <span id="1-4">A.1.4 Character Set Localization</span> === Although the language standard dictates Latin-1 as the contents of type Character, an implementation has permission to supply an alternative set specific to the locale or environment. For example, an eastern European implementation may define the type Character based on ISO 8859, Part 2 (Latin-2); a personal computer implementation may define the type Character as the native PC character set. Of course with such adaptations an Ada program might no longer be portable, but in some environments the ability to exploit the characteristics of the local environment is more important than the ability to move a program between different environments. In fact the explicit permission for a validated compiler to perform such localizations is not new in Ada 95 but applies also to Ada 83 based on a non-binding interpretation of ISO/IEC JTC1/SC22 WG9 Ada [ISO WG9 93]. An implication of such localization is that the semantics of the classification and conversion functions in the Characters.Handling package depends on the definition of Character. For example, the result of Is_Letter(Character'Val(16#F7#)) is false for Latin-1 (this character is the division sign) but is true for Latin/Cyrillic. == <span id="2">A.2 String Handling</span> == Many languages support string handling either directly via data types and operations or through standard supplemental library functions. Ada 83 provided the framework for a solution, through discriminated record types and access types, but the absence of a standard set of string handling services has proved a barrier to portability. To solve this problem, Ada 95 includes a set of packages for string handling that need to be supplied by all implementations. === <span id="2-1">A.2.1 Categories of Strings</span> === We can divide string data structures into three categories based on their flexibility and associated storage management: * A fixed-length string has a length whose value is established at object creation and is invariant during the object's lifetime. There is no need to use the heap for the storage of a fixed-length string. * A bounded-length string, also known in the literature as a varying- length string, can change in length during its lifetime, but the maximum length is established no later than when the object is created. Thus a bounded-length string has both a current length which can change, and a maximum length which does not change. * Since the maximum length is known on a per-object basis, a natural implementation is to reserve this maximum amount of storage when the object is created, rather than using the heap. * An unbounded-length string, also known in the literature as a dynamic string, can change in length during its lifetime with no a priori maximum length other than that implied by the range of the index subtype. Unbounded-length strings need to be managed dynamically, either in the general heap or in some region reserved for strings, because of the wide range of possible sizes for any given object. In practice the storage allocation performed by the compiler may vary from the "natural" method mentioned. For example, if the length of a fixed-length string, or the maximum length of a bounded-length string, exceeds some threshold value then the compiler may choose to place the object on the heap, with automatic reclamation when the object becomes inaccessible. This may be done because of target machine addressing constraints or (for bounded-length strings with a prohibitively large maximum size) as a means to economize on storage usage. Ada 95 supplies packages for each of these categories, for both the predefined types String and Wide_String. For fixed-length strings the type is the specific type String or Wide_String. For the other two categories, a private type is supplied (see below) since it is important for purposes of data abstraction to avoid exposing the representation. Each of the three packages supplies a set of string-handling subprograms. The bounded- and unbounded-length string packages also supply conversion and selection functions; these are needed because the type is private. === <span id="2-2">A.2.2 Operations on Strings</span> === Operations on strings fall into several categories. This section summarizes the various operations that are provided, and notes the semantic issues that arise based on whether the strings are fixed-, bounded-, or unbounded-length. <dl> <dt>Constructors</dt> <dd><p>Literals are available for fixed-length strings; for bounded- and unbounded-length strings we need conversion functions (String to/from Bounded_String and also to/from Unbounded_String).</p> <p>The conversion function from String to Bounded_String illustrates a point that comes up in other contexts when constructing a bounded string: suppose the length of the result exceeds the maximum length of the bounded string? We let the user control the behavior through a parameter to the constructor function. The default effect is to raise an exception (Strings.Length_Error), but the user can also establish truncation of extra characters either on the right or left.</p> <p>Concatenation is available automatically for fixed-length strings, and explicit overloadings are provided for bounded and unbounded strings. Note that since the operator form for concatenation of bounded length strings does not offer a possibility for the user to control the behavior if the result length exceeds the bounded string type's maximum length, we provide also a set of Append functions taking an explicit parameter dictating truncation versus raising an exception. The operator form will raise an exception if the result length exceeds the type's maximum length.</p> <p>For bounded and unbounded strings, there is the question of how many overloaded versions to supply for the concatenation functions. For convenience we allow concatenation of a Bounded_String with either a Character, a String, or another Bounded_String, returning a Bounded_String result, and analogously for Unbounded_String. We decided against allowing the concatenation of two fixed-length strings return a Bounded_String (or an Unbounded_String), since such an overloading would render ambiguous a statement such as</p> <syntaxhighlight lang="Ada"> B := S1 & S2 & S3;</syntaxhighlight> <p>where S1, S2 and S3 are of type String and B is of type Bounded_String.</p> <p>If it is necessary to convert between a bounded and an unbounded string, this can be done by producing a String as an intermediate result.</p> <p>Replication operations are also provided to construct string values. For each of the three string categories a "*" operator is supplied with left operand of subtype Natural and right operand either a Character, a String, or (for bounded and unbounded strings) a value of the corresponding string type. The result is of the string type. For example:</p> <syntaxhighlight lang="Ada"> declare Alpha, Beta : Unbounded_String; begin Alpha := 3 * 'A'; -- To_String(Alpha) = "AAA" Alpha := 2 * Alpha; -- To_String(Alpha) = "AAAAAA" Beta := 2 * "Abc"; -- To_String(Beta) = "AbcAbc" end;</syntaxhighlight></dd> <dt>Copying</dt> <dd><p>The issue in copying is what to do when the source and target lengths differ; this is only a concern in the fixed-length case. For bounded strings the ":=" operation always works: the source and target have identical maximum lengths, so assignment simply copies the source to the target. For unbounded strings the ":=" operation does the necessary storage management through Adjust and Finalize operations to allocate needed space for the new value of the target and to reclaim the space previously occupied by the object.</p> <p>Our model, based on COBOL, is that a fixed-length string comprises significant contents together with padding. The pad characters may appear either on the right or left (or both); this is useful for report output fields. Parameters to the Move procedure allow the programmer to control the effect. When a shorter string is copied to a longer string, pad characters are supplied as filler, and the Justify parameter guides where the source characters are placed. When a longer string is copied to a shorter string, the programmer establishes whether the extra characters are to be dropped from the left or the right, or if an exception should be raised when a non-pad character is dropped.</p></dd> <dt>Selection</dt> <dd><p>Component selection is not an issue for fixed-length strings, since indexing and slicing are directly available. For both bounded and unbounded strings, we supply subprograms to select and replace a single element, and to select and replace a slice.</p></dd> <dt>Ordering relations</dt> <dd><p>For fixed-length strings the predefined ordering and equality operators are appropriate, but for both the bounded and unbounded string types we provide explicit overloadings. Note that if the implementation chooses to represent bounded strings with a maximum-length array and an index for the current length (see A.2.5 for further discussion), then predefined assignment has the desired effect but predefined equality does not, since it would check the "junk" characters in the string beyond the logical length.</p> <p>The ordering operators return a result based on the values of corresponding characters; Thus for example the string "ZZZ" is less than the string "aa". Anything more sophisticated would have been out of scope and in any event is dependent on local cultural conventions.</p></dd> <dt>Searching and pattern matching</dt> <dd><p>Each of the string handling packages provides subprograms to scan a string for a pattern (Index, Count) or for characters inside or outside specified sets (Index_Non_Blank, Index, and Find_Token). The profiles for each of these subprograms is the same in the three packages, except for the type of the source string (String, Bounded_String, or Unbounded_String).</p> <p>A design issue was how to arrange that pattern matches be case insensitive, or in general to reflect user-defined character equivalences. Our approach is to supply to each pattern matching function a parameter that specifies a character equivalence. By default the equivalence mapping is the identity relation, but the programmer can override this via an explicit parameter of type Strings.Maps.Character_Mapping.</p> <p>Although Index_Non_Blank is redundant, it is included since searching for blanks is such a common operation.</p> <p>Find_Token is at a somewhat higher level than the other subprograms. We have supplied this procedure since it is extremely useful for simple lexical analysis such as parsing a line of interactively supplied input text.</p></dd> <dt>String transformation</dt> <dd><p>As with the searching and pattern matching subprograms, we supply the same functionality for string transformations in each of the three string handling packages.</p> <p>A common need is to translate a string via a character translation table. The Translate function satisfies this goal. The procedural form of Translate is included for efficiency, to avoid the extra copying that may be required for function returns.</p> <p>The other string transformation subprograms are Replace_Slice, Insert, Overwrite, Delete, and Trim. These are not necessarily length preserving.</p> <p>We had considered including a subprogram to replace all occurrences of a pattern with a given string but ultimately decided in the interest of simplicity to leave this out. It can be written in terms of the supplied operations if needed (see the example in A.2.8).</p></dd></dl> === <span id="2-3">A.2.3 General Design Decisions</span> === Independent of the functionality provided, several fundamental design questions arose: whether to make the packages generic (with respect to character and string type) or specific to the types in Standard; how to organize the packages (hierarchically or as siblings); and whether to define the string-returning operations as functions, procedures, or both. <dl> <dt>Generic vs non-generic form of packages</dt> <dd><p>String handling needs to be provided for the predefined String and Wide_String types, and it is also useful for strings of elements from user-supplied character types. For these reasons it seems desirable to have a generic version of the string handling packages, with language- defined instantiations for Character and String and also for Wide_Character and Wide_String. In fact, an earlier version of the packages adopted this approach, but we subsequently decided to provide non-generic forms instead.</p> <p>There are several reasons for this decision. First, although the specifications for the packages for handling Character and Wide_Character strings might be the same, the implementations would be different. Second, the generic form would be rather complicated, a pedagogical issue for users and a practical issue for implementations.</p></dd> <dt>Structure of packages</dt> <dd><p>In order to minimize the number of language-defined names for immediate children of the root package Ada, the string handling packages form a hierarchy. The ancestor unit, Ada.Strings, declares the types and exceptions common to the other packages. The package Strings.Maps declares the types and related entities for the various data representations needed by the other packages. Strings.Fixed, Strings.Bounded, and Strings.Unbounded provide the entities for fixed- length, bounded-length, and unbounded-length strings, respectively. The package Strings.Maps.Constants declares Character_Set constants corresponding to the character classification functions in the package Characters, as well as Character_Mapping constants that can be used in pattern matching and string transformations. There are analogous packages Strings.Wide_Maps, Strings.Wide_Fixed, Strings.Wide_Bounded, Strings.Wide_Unbounded, and Strings.Wide_Maps.Constants, for Wide_String handling.</p></dd> <dt>Procedures vs functions</dt> <dd><p>The subprograms that deliver string results can be defined either as functions or as procedures. The functional notation is perhaps more pleasant stylistically but typically involves extra copying. The procedural form, with an in out parameter that is updated "in place", is generally more efficient but can lead to a heavy-looking style.</p> <p>Our solution is to provide both forms for all three string-handling packages. Although this increases the size of the packages, the benefits are an increase in flexibility for the programmer, and a regularity in the structure of the packages that should make them easier to use.</p></dd></dl> === <span id="2-4">A.2.4 Strings.Maps</span> === The package Strings.Maps defines the types for representing sets of characters and character-to-character mappings, for the types Character and String. A corresponding package, Strings.Wide_Maps, provides the same functionality for the types Wide_Character and Wide_String. The type Character_Set represents sets of Character values that are to be passed to the string handling subprograms. We considered several alternative declarations for Character_Set: * A visible constrained array-of-Booleans type; * A visible unconstrained array-of-Booleans type; * A private type; and * A private type with unknown discriminants. A visible constrained array type is the traditional representation of a set of values from a discrete type; in the case of Character it would be: <syntaxhighlight lang="Ada"> type Character_Set is array (Character) of Boolean; pragma Pack(Character_Set);</syntaxhighlight> However, this has several disadvantages. First, it would differ from the choice of representations for a set of Wide_Character values, in the package Strings.Wide_Maps; in the latter package a constrained array type is not a realistic decision, since an overhead of 2**16 (64K) bits for each set would be excessive. Second, even 256 bits may be more than is desirable for small sets, and a more compact representation might be useful. An unconstrained array of Booleans addresses the second issue: <syntaxhighlight lang="Ada"> type Character_Set is array (Character range <>) of Boolean; pragma Pack(Character_Set);</syntaxhighlight> In this version, an object CS of type Character_Set represents the set comprising each character C in CS'Range such that CS(C) is true; any character outside CS'Range is implicitly regarded as not being in the set, and of course any character C in CS'Range such that CS(C) is false is regarded as not being in the set. Thus, for example, the empty set is represented by a null Character_Set array (as well as by many other Character_Set values). The unconstrained array approach was used in earlier versions of the string handling packages, since it is more efficient in storage than the constrained array approach. However, we ultimately decided against this approach, for several reasons. * Similar to the constrained array-of-Booleans approach, it is not always appropriate for Wide_Character sets. In particular, even if a set is small and has a compact representation, taking the complement of the set can yield a value requiring 64K bits. * The effect of ":=" is unintuitive. Two Character_Set objects could represent the same set, yet since they might have different lengths, assigning one to another could raise Constraint_Error. * The need to provide an explicit initialization for each Character_Set variable (since the type is unconstrained) is inconvenient. The private type approach is much more in the spirit of Ada and allows the implementation, rather than requiring the language, to make the choice of representations for Character_Set. Note that a simple private type (i.e., one without unknown discriminants) is not allowed to have an unconstrained type as its full declaration. Thus if we want to allow some flexibility (rather than just imposing a private type interface on what is certain to be a constrained array type declaration as the full type declaration) we should allow the possibility of having the full declaration be an access type whose designated type is an unconstrained array of Booleans. To do this, we need to compromise the goal of having a pure package (since access types are not permitted in a pure package); instead, we simply make the package preelaborable. A private type with an unknown discriminant part might seem like a more direct way to allow the unconstrained-array-of-Booleans as the full declaration, but it suffers from a major portability flaw. If Set_1 and Set_2 are objects of type Character_Set, and Character_Set is a private type with an unknown discriminant part, then the assignment Set_1 := Set_2; may or may not raise Constraint_Error, depending on what the implementation chooses for the full type declaration. As a result of these considerations, we have declared Character_Set as a private type, without an unknown discriminant part, and have specified the package as just preelaborable rather than pure in order to allow the implementation to use an access type in the full declaration of Character_Set. A consequence of declaring Character_Set as private is that constructor functions are needed for composing Character_Set values. We have provided several such functions, each named To_Set. Since it is often convenient to have a set containing a single character, or exactly those characters appearing in some array, we have overloaded To_Set to take either a parameter of type Character or of type Character_Sequence (the latter is in fact just a subtype with the effect of renaming String). It is also useful to compose a set out of one or more character ranges, and hence we have supplied the appropriate additional overloadings of To_Set. In the other direction, it is useful to get a "concrete" representation of a set as either a set of ranges or a character sequence, and hence we have provided the corresponding functions. Although introducing the name Character_Sequence is not strictly necessary (the name String would be equivalent), the style of having a subtype as effectively a renaming of an existing (sub)type makes the intent explicit. Other languages that supply string handling functions represent character sets directly as character sequences as opposed to boolean arrays; for example, the functions in the C standard header . This was considered for the Ada 95 packages but rejected in the interest of efficiency. Another type declared by Strings.Maps is Character_Mapping, which represents a mapping from one Character value to another. For the same reasons underlying the choice of a private type for Character_Set, we have also declared Character_Mapping as private. A typical choice for a full type declaration would be: <syntaxhighlight lang="Ada"> type Character_Mapping is array (Character) of Character;</syntaxhighlight> with the obvious interpretation; if CM is a Character_Mapping and C is a character, then CM(C) is the character to which C maps under the mapping CM. Character mappings are used in two contexts: * To define an equivalence function applicable during pattern matches (e.g., allowing the programmer to do searches where the distinction between upper and lower case letters does not matter); and * To define a translation table used in string transformation subprograms. As an example of the use of the Character_Mapping type, the constant Lower_Case_Map (declared in Strings.Maps.Constants) maps each letter to the corresponding lower case letter and maps each other character to itself. The following finds the first occurrence of the pattern string "gerbil" in a source string S, independent of case: <syntaxhighlight lang="Ada"> Index(Source => S, Pattern => "gerbil", Going => Forward, Mapping => Strings.Maps.Constants.Lower_Case_Map)</syntaxhighlight> A character C matches a pattern character P with respect to the Character_Mapping value Map if Map(C)=P. Thus the user needs to ensure that a pattern string comprises only characters occurring in the range of the mapping. (Passing as a pattern the string "GERBIL" would always fail for the mapping Lower_Case_Map.) An earlier version of the string packages had a more symmetric definition for matching; namely C matched P if Map(C) = Map(P). However, this yielded some counterintuitive effects and has thus been changed. There is another possible representation for mappings, namely an access value denoting a function whose domain and range are the character type in question. This would be useful where the domain and range are very large sets, and in fact is used in the string handling packages for Wide_Character and Wide_String. To avoid unnecessary differences between the String and Wide_String packages, we have supplied the analogous access-to-subprogram type in Strings.Maps: <syntaxhighlight lang="Ada"> type Character_Mapping_Function is access function (From : in Character) return Character;</syntaxhighlight> Each subprogram that takes a Character_Mapping parameter is overloaded with a version that takes a Character_Mapping_Function. In an earlier version of the string handling packages, the access-to-subprogram type was provided for Wide_String handling but not for String handling, since we were striving to make the latter pure. However, since the package has had to compromise purity for other reasons as described above, there was no longer a compelling reason to leave out the character mapping function type. === <span id="2-5">A.2.5 Bounded-Length Strings</span> === The major decisions for bounded-length strings were (1) whether the type should be private or not, and (2) whether to realize the maximum length as a discriminant or, instead, as a generic formal parameter. There are two main reasons to declare a type as private as opposed to non-private: * To hide irrelevant representational decisions, thus allowing implementation flexibility, * To ensure that the programmer does not violate data consistency or otherwise abuse the intent of the type. Both of these apply to Bounded_String; hence it is appropriate for the type to be declared as private. There are two principal ways to represent a varying- (but bounded-) length string, assuming that access types are to be avoided. One is to supply the maximum length as a discriminant constraint, thus allowing different objects of the same type to have different maximum lengths. The other approach is to supply the maximum length at the instantiation of a generic package declaring a bounded string type, implying that objects with different maximum lengths must be of different types. We thus have the following basic approaches: <syntaxhighlight lang="Ada"> package Discriminated_Bounded_Length is type Bounded_String(Max_Length : Positive) is private; function Length(Item : Bounded_String) return Natural; ... private type Bounded_String(Max_Length : Positive) is record Length : Natural; Data : String(1 .. Max_Length); end record; end Discriminated_Bounded_Length;</syntaxhighlight> and also the alternative: <syntaxhighlight lang="Ada"> generic Max : Positive: package Generic_Bounded_Length is Max_Length : constant Positive := Max; subtype Length_Range is Natural range 0 .. Max_Length; type Bounded_String is private; function Length(Item : Bounded_String) return Length_Range; ... private type Bounded_String_Internals(Length : Length_Range := 0) is record Data : String(1 .. Length); end record; type Bounded_String is record Data : Bounded_String_Internals; end record; end Generic_Bounded_Length;</syntaxhighlight> Each of these approaches has advantages and disadvantages (the reason for the seeming redundancy in the private part of the generic package will be discussed below). If there is an operation that needs to deal with Bounded_String values with different maximum lengths, then the discriminated type approach is simpler. On the other hand, predefined assignment and equality for discriminated Bounded_String do not have the desired behavior. Assignment makes sense when the maximum lengths of source and target are different, as long as the source's current length is no greater than the target's maximum length, yet predefined ":=" would raise Constraint_Error on the discriminant mismatch. User-defined Adjust and Finalize operations do not solve this problem. It would be possible to avoid the difficulty by declaring the type as limited private, but this would result in a very clumsy programming style. A variation is to declare a discriminated type with a default value for the Max_Length discriminant. An object declared unconstrained can thus be assigned a value with a different maximum length (and a different length). This approach, however, introduces other problems. First, if the object is allocated rather than declared, then its discriminant is in fact constrained (by its default initial value). Second, declaring an appropriate subtype for the discriminant - that is, establishing an appropriate bound for Max_Length - is difficult. If it is too small then the user might not be able to create needed objects. If it is too large, then there will either be a lot of wasted space or else the implementation may use dynamic storage allocation implicitly. The solution is to let the user establish the maximum length as a parameter at generic instantiation. Such an approach avoids these complications, but has two main drawbacks. First, the programmer will need to perform as many instantiations as there are different maximum lengths to be supported. Second, operations involving varying-length strings of different maximum lengths cannot be defined as part of the same generic package. However, the programmer can get around the first difficulty by providing a small number of instantiations with sufficient maximum size (for example, max lengths of 20 and 80). Either explicit overloadings or generics with formal package instantiations serve to address the second issue. For these reasons we have adopted the generic approach, rather than the discriminant approach, to specifying the maximum length for a varying-length string. Note that Bounded_String in the generic package is declared without discriminants. Max_Length is established at the generic instantiation, and the Length field is invisible to the user and is set implicitly as part of the effect of the various operations. An alternative would be to declare the type as follows: <syntaxhighlight lang="Ada"> type Bounded_String(Length : Length_Range := 0) is private;</syntaxhighlight> However, this would allow the user to create constrained instances, which defeats the intent of the package. In order to prevent such abuses it is best to leave the Length component hidden from the user [Eachus 92]. A final point of rationale for the Bounded_String generic: the reason for declaring Max_Length, which is simply a constant reflecting the value supplied at the generic instantiation, is to allow the user to refer to the maximum length without keeping track manually of which values were supplied at which instantiations. === <span id="2-6">A.2.6 Unbounded-Length Strings</span> === Unbounded-length strings need to be implemented via dynamic storage management. In Ada 83, in the absence of automatic garbage collection it was the programmer's responsibility to reclaim storage through unchecked deallocation. Ada 95's facilities for automatically invoked Adjust and Finalize plug this loophole, since the unbounded string type implementor can arrange that storage be reclaimed implicitly, with no need for the user to perform unchecked deallocation. The main design issue for unbounded strings was whether to expose the type as derived from Finalization.Controlled. That is, the type could be declared either as <syntaxhighlight lang="Ada"> type Unbounded_String is private;</syntaxhighlight> or <syntaxhighlight lang="Ada"> type Unbounded_String is new Finalization.Controlled with private;</syntaxhighlight> An advantage of the latter approach is that users can further derive from Unbounded_String for richer kinds of data structures, and override the default Finalize and Adjust. However, we have chosen the simpler approach, just making Unbounded_String private. If a more complicated data structure is desired, this can be obtained by including an Unbounded_String as a component. Besides providing the private type Unbounded_String, the package Strings.Unbounded declares a visible general access type String_Access whose designated type is String. The need for such a type arises often in practice, and so it is appropriate to have it declared in a language- defined package. The following is a sample implementation of the private part of the package: <syntaxhighlight lang="Ada"> private use Finalization; Null_String : aliased String := ""; type Unbounded_String is new Controlled with record Reference : String_Access := Null_String'Access; end record; -- No need for Initialize procedure procedure Finalize (Object : in out Unbounded_String); procedure Adjust (Object : in out Unbounded_String); Null_Unbounded_String : constant Unbounded_String := (Controlled with Reference => Null_String'Access); end Ada.Strings.Unbounded;</syntaxhighlight> The following skeletal package body illustrates how several of the subprograms might be implemented. <syntaxhighlight lang="Ada"> with Unchecked_Deallocation; package body Strings.Unbounded is procedure Free is new Unchecked_Deallocation(String, String_Access); function To_Unbounded_String(Source : String) return Unbounded_String is Result_Ref : constant String_Access := new String(1 .. Source'Length); begin Result_Ref.all := Source; return (Finalization.Controlled with Reference => Result_Ref); end To_Unbounded_String; function To_String(Source : Unbounded_String) return String is begin return Item.Reference.all; -- Note: Item.Reference is never null end To_String; -- In the following subprograms, the Reference component of each -- Unbounded_String formal parameter is non-null, because of the -- default initialization implied by the type's declaration function Length(Source : Unbounded_String) return Natural is begin return Source.Reference.all'Length; end Length; function "=" (Left, Right : Unbounded_String) return Boolean is begin return Left.Reference.all = Right.Reference.all; end "="; procedure Finalize(Object : in out Unbounded_String) is begin if Object.Reference /= Null_String'Access then Free(Object.Reference); end if; end Finalize; procedure Adjust(Object : in out Unbounded_String); begin -- Copy Object if it is not Null_Unbounded_String if Object.Reference /= Null_String'Access then Object.Reference := new String'(Object.Reference.all); end if; end Adjust; function "&" (Left, Right : in Unbounded_String) return Unbounded_String is Left_Length : constant Natural := Left.Reference.all'Length; Right_Length : constant Natural := Right.Reference.all'Length; Result_Length : constant Natural := Left_Length + Right_Length; Result_Ref : String_Access; begin if Result_Length = 0 then return Null_Unbounded_String; else Result_Ref := new String(1 .. Result_Length); Result_Ref.all(1..Left_Length) := Left.Reference.all; Result_Ref.all(Left_Length+1..Result_Length) := Right.Reference.all; return (Finalization.Controlled with Reference => Result_Ref); end if; end "&"; ... end Ada.Strings.Unbounded;</syntaxhighlight> === <span id="2-7">A.2.7 Wide String Handling</span> === Since the same functionality is needed for Wide_String as for String, there are child packages of Ada.Strings with analogous contents to those discussed above, but for Wide_Character and Wide_String. The only difference is that some of the type and subprogram names have been adapted to reflect their application to Wide_Character. As a consequence of providing equivalent functionality for the two cases, we have made it easier for a programmer to modify an application that deals with, say, String data, so that it can work with Wide_String data. === <span id="2-8">A.2.8 Examples</span> === The function below, which replaces all occurrences of a pattern in a source string, is intended as an illustration of the various string handling operations rather than as a recommended style for solving the problem. A more efficient approach would be to defer creating the result string until after the pattern matches have been performed, thereby avoiding the overhead of allocating and deallocating the intermediate string data at each iteration. <syntaxhighlight lang="Ada"> with Ada.Strings.Maps, Ada.Strings.Unbounded, Ada.Strings.Fixed; use Ada.Strings; function Replace_All (Source : in String; Pattern : in String; By : in String; Going : in Direction := Forward; Mapping : in Maps.Character_Mapping := Maps.Identity) return String is use type Unbounded.Unbounded_String; Pattern_Length : constant Natural := Pattern'Length; Start : Natural := Source'First; Result : Unbounded.Unbounded_String; Index : Natural; begin loop Index := Fixed.Index(Source(Start .. Source'Last), Pattern, Going, Mapping); if Index/=0 then Result := Result & Source(Start .. Index-1) & By; Start := Index + Pattern'Length; else Result := Result & Source(Start .. Source'Last); return Unbounded.To_String(Result); end if; end loop; end Replace_All;</syntaxhighlight> The following program fragments show how the string handling subprograms may be used to get the effect of several COBOL INSPECT statement forms. <syntaxhighlight lang="Ada"> COBOL: INSPECT ALPHA TALLYING NUM FOR ALL "Z" BEFORE "A". Ada 95: Alpha : String( ... ); A_Index, Num: Natural; ... A_Index := Index(Alpha, 'A'); Num := Count(Alpha(Alpha'First .. A_Index-1), "Z"); COBOL: INSPECT ALPHA REPLACING ALL "A" BY "G", "B" BY "H" BEFORE INITIAL "X". Ada 95: Alpha : String( ... ); X_Index : Natural; My_Map : Character_Mapping := To_Mapping(From => "AB", To=>"GH"); ... X_Index := Index(Alpha, 'X'); Translate(Source => Alpha(Alpha'First .. X_Index -1), Mapping => My_Map);</syntaxhighlight> == <span id="3">A.3 Numerics Packages and Attributes</span> == Ada 95 includes in the predefined environment several child packages of Ada.Numerics, and the language also provides a comprehensive set of representation-oriented, model-oriented, and primitive-function attributes for real types. The package Ada.Numerics itself defines the named numbers Pi and e, as well as an exception (Argument_Error) shared by several of its children. The constants Pi and e are defined for the convenience of mathematical applications. The WG9 Numerics Rapporteur Group did not define these constants in the secondary numeric standards for Ada 83 [ISO 94a], primarily because it could not decide whether to define a minimal set (as has now been done in Ada 95) or a much larger set of mathematical and physical constants. Ada 95 implementations are required to provide Pi and e to at least 50 decimal places; this exceeds by a comfortable margin the highest precision available on present-day computers. The Argument_Error exception is raised when a function in a child of Numerics is given an actual parameter whose value is outside the domain of the corresponding mathematical function. The child packages of Ada.Numerics are Generic_Elementary_Functions and its non-generic equivalents, Float_Random and Discrete_Random (see A.3.2); Generic_Complex_Types and its non-generic equivalents (see G.1.1); Generic_Complex_Elementary_Functions and its non-generic equivalents (see G.1.2). === <span id="3-1">A.3.1 Elementary Functions</span> === The elementary functions are critical to a wide variety of scientific and engineering applications written in Ada. They have been widely provided in the past as vendor extensions, but the lack of a standardized interface, variations in the use or avoidance of generics, differences in the set of functions provided, and absence of guaranteed accuracy have hindered the portability and the analysis of programs. These impediments are removed by including the elementary functions in the predefined language environment. The elementary functions are provided in Ada 95 by a generic package, Numerics.Generic_Elementary_Functions, which is a very slight variation of the generic package, Generic_Elementary_Functions, defined in [ISO 94a] for Ada 83. In addition, Ada 95 provides non-generic equivalent packages for each of the predefined floating point types, so as to facilitate the writing of scientific applications by programmers whose experience in other languages leads them to select the precision they desire by choosing an appropriate predefined floating point type. The non-generic equivalent packages have names as follows <syntaxhighlight lang="Ada"> Numerics.Elementary_Functions -- for Float Numerics.Long_Elementary_Functions -- for Long_Float</syntaxhighlight> and so on. These nongeneric equivalents behave just like instances of the generic packages except that they may not be used as actual package parameters as in the example in 12.6. A vendor may, in fact, provide the non-generic equivalent packages by instantiating the generic, but more likely they will be obtained by hand- tailoring and optimizing the text of the generic package for each of the predefined floating point types, resulting in better performance. The Argument_Error exception is raised, for example, when the Sqrt function in Numerics.Generic_Elementary_Functions is given a negative actual parameter. In [ISO 94a] and related draft secondary standards for Ada 83, Argument_Error was declared in each generic package as a renaming of an exception of the same name defined in a (non-generic) package called Elementary_Functions_Exceptions; in Ada 95, the children of Numerics do not declare Argument_Error, even as a renaming. In Ada 83, simple applications that declare problem-dependent floating point types might look like this: <syntaxhighlight lang="Ada"> with Generic_Elementary_Functions; procedure Application is type My_Type is digits ...; package My_Elementary_Functions is new Generic_Elementary_Functions(My_Type); use My_Elementary_Functions; X : My_Type; begin ... Sqrt(X) ... exception when Argument_Error => ... end Application;</syntaxhighlight> In Ada 95, they will look almost the same, the essential difference being the addition of context clauses for Ada.Numerics: <syntaxhighlight lang="Ada"> with Ada.Numerics; use Ada.Numerics; with Ada.Numerics.Generic_Elementary_Functions; procedure Application is type My_Type is digits ...; package My_Elementary_Functions is new Generic_Elementary_Functions(My_Type); use My_Elementary_Functions; X : My_Type; begin ... Sqrt(X) ... exception when Argument_Error => ... end Application;</syntaxhighlight> The benefit of the Ada 95 approach can be appreciated when one contemplates what happens when a second problem-dependent type and a second instantiation of Numerics.Generic_Elementary_Functions are added to the application. There are no surprises in Ada 95, where one would write the following: <syntaxhighlight lang="Ada"> with Ada.Numerics; use Ada.Numerics; with Ada.Numerics.Generic_Elementary_Functions; procedure Application is type My_Type_1 is digits ...; type My_Type_2 is digits ...; package My_Elementary_Functions_1 is new Generic_Elementary_Functions(My_Type_1); package My_Elementary_Functions_2 is new Generic_Elementary_Functions(My_Type_2); use My_Elementary_Functions_1, My_Elementary_Functions_2; X : My_Type_1; Y : My_Type_2; begin ... Sqrt(X) ... ... Sqrt(Y) ... exception when Argument_Error => ... end Application;</syntaxhighlight> If one were to extend the Ada 83 example with a second problem-dependent type and a second instantiation, one would be surprised to discover that direct visibility of Argument_Error is lost (because both instances declare that name, and the declarations are not overloadable [RM95 8.4(11)]). To regain direct visibility, one would have to add to the application a renaming declaration for Argument_Error. The functions provided in Numerics.Generic_Elementary_Functions are the standard square root function (Sqrt), the exponential function (Exp), the logarithm function (Log), the forward trigonometric functions (Sin, Cos, Tan, and Arctan), the inverse trigonometric functions (Arcsin, Arccos, Arctan, and Arccot), the forward hyperbolic functions (Sinh, Cosh, Tanh, and Coth), and the inverse hyperbolic functions (Arcsinh, Arccosh, Arctanh, and Arccoth). In addition, an overloading of the exponentiation operator is provided for a pair of floating point operands. Two overloadings of the Log function are provided. Without a Base parameter, this function computes the natural (or Napierian) logarithm, i.e. the logarithm to the base e, which is the inverse of the exponential function. By specifying the Base parameter, which is the second parameter, one can compute logarithms to an arbitrary base. For example, <syntaxhighlight lang="Ada"> Log(U) -- natural logarithm of U Log(U, 10.0) -- common (base 10) logarithm of U Log(U, 2.0) -- log of U to the base 2</syntaxhighlight> Two overloadings of each of the trigonometric functions are also provided. Without a Cycle parameter, the functions all imply a natural cycle of 2*pi, which means that angles are measured in radians. By specifying the Cycle parameter, one can measure angles in other units. For example, <syntaxhighlight lang="Ada"> Sin(U) -- sine of U (U measured in radians) Cos(U, 360.0) -- cosine of U (U measured in degrees) Arctan(U, Cycle => 6400.0) -- angle (in mils) whose tangent is U Arccot(U, Cycle => 400.0) -- angle (in grads) whose cotangent is U</syntaxhighlight> Cycle is the second parameter of all the trigonometric functions except Arctan and Arccot, for which it is the third. The first two parameters of Arctan are named Y and X, respectively; for Arccot, they are named X and Y. The first parameter of each of the remaining trigonometric functions is named X. A ratio whose arctangent or arccotangent is to be found is specified by giving its numerator and denominator separately, except that the denominator can be omitted, in which case it defaults to 1.0. The separate specification of numerator and denominator, which of course is motivated by the Fortran ATAN2 function, allows infinite ratios (i.e., those having a denominator of zero) to be expressed; these, of course, have a perfectly well-defined and finite arctangent or arccotangent, which lies on one of the axes. Thus, <syntaxhighlight lang="Ada"> Arctan(U, V) -- angle (in radians) whose tangent is U/V Arccot(U, V) -- angle (in radians) whose cotangent is U/V Arctan(U) -- angle (in radians) whose tangent is U Arctan(U, V, 360.0) -- angle (in degrees) whose tangent is U/V) Arctan(1.0, 0.0, 360.0) -- 90.0 (degrees)</syntaxhighlight> The result of Arctan or Arccot is always in the quadrant (or on the axis) containing the point (X, Y), even when the defaultable formal parameter takes its default value; that of Arcsin is always in the quadrant (or on the axis) containing the point (1.0, X), while that of Arccos is always in the quadrant (or on the axis) containing the point (X, 1.0). Given that the constant Pi is defined in Numerics, one might wonder why the two overloadings of each trigonometric function have not been combined into a single version, with a Cycle parameter having a default value of 2.0*Numerics.Pi. The reason is that computing the functions with natural cycle by using the value of Numerics.Pi cannot provide the accuracy required of implementations conforming to the Numerics Annex, as discussed below. Since Numerics.Pi is necessarily a finite approximation of an irrational (nay, transcendental) value, such an implementation would actually compute the functions for a slightly different cycle, with the result that cumulative "phase shift" errors many cycles from the origin would be intolerable. Even relatively near the origin, the relative error near zeros of the functions would be excessive. An implementation that conforms to the accuracy requirements of the Numerics Annex will use rather different strategies to compute the functions relative to the implicit, natural cycle of 2*pi as opposed to an explicit cycle given exactly by the user. (In particular, an implementation of the former that simply invokes the latter with a cycle of 2.0*Numerics.Pi will not conform to the Numerics Annex.) Similar considerations form the basis for providing the natural logarithm function as a separate overloading, with an implicit base, rather than relying on the version with a base parameter and a default value of Numerics.e for that parameter. In an early draft of Ada 95, the overloading of the exponentiation operator for a pair of floating point operands had parameter names of X and Y, following the style adopted for the other subprograms in Numerics.Generic_Elementary_Functions. It was subsequently deemed important for new overloadings of existing arithmetic operators to follow the precedent of using Left and Right for the names of their parameters, as in Ada 83. The exponentiation operator is noteworthy in another respect. Instead of delivering 1.0 as one might expect by analogy with 0.0**0, the expression 0.0**0.0 is defined to raise Numerics.Argument_Error. This is because 0.0**0.0 is mathematically undefined, and indeed x**y can approach any value as x and y approach zero, depending on precisely how x and y approach zero. If X and Y could both be zero when an application evaluates X**Y, it seems best to require the application to decide in advance what it means and what the result should be. An application can do that by defining its own exponentiation operator, which would * invoke the one obtained by instantiating the elementary functions package, and * handle an Argument_Error exception raised by the latter, delivering from the handler the appropriate application-dependent value. The local exponentiation operator can be inlined, if the extra level of subprogram linkage would be of concern. The Ada 95 version uses Float_Type'Base as a type mark in declarations; this was not available in Ada 83. Thus the formal parameter types and result types of the functions are of the unconstrained (base) subtype of the generic formal type Float_Type, eliminating the possibility of range violations at the interface. The same feature can be used for local variables in implementations of Numerics.Generic_Elementary_Functions (if it is programmed in Ada) to avoid spurious exceptions caused by range violations on assignments to local variables having the precision of Float_Type. Thus, in contrast to [ISO 94a] there is no need to allow implementations to impose the restriction that the generic actual subtype must be an unconstrained subtype; implementations must allow any floating point subtype as the generic actual subtype, and they must be immune to the potential effects of any range constraint of that subtype. Implementations in hardware sometimes do not meet the desired accuracy requirements [Tang 91] because the representation of pi contained on the hardware chip has insufficient precision. To allow users to choose between fast (but sometimes inaccurate) versions of the elementary functions implemented in hardware and slightly slower versions fully conforming to realistic accuracy requirements, we introduced the concept of a pair of modes, "strict" and "relaxed". No accuracy requirements apply in the relaxed mode, or if the Numerics Annex is not supported. (These modes govern all numeric accuracy issues, not just those connected with the elementary functions.) The accuracy requirements of the strict mode are not trivial to meet, but neither are they particularly burdensome; their feasibility has been demonstrated in a public-domain implementation using table-driven techniques. However, it should be noted that most vendors of serious mathematical libraries, including the hardware vendors, are now committing themselves to implementations that are fully accurate throughout the domain, since practical software techniques for achieving that accuracy are becoming more widely known. The accuracy requirements in Ada 95 are not as stringent as those which vendors are now striving to achieve. Certain results (for example, the exponential of zero) are prescribed to be exact, even in the relaxed mode, because of the frequent occurrence of the corresponding degenerate cases in calculations and because they are inexpensively provided. Also, although the accuracy is implementation-defined in relaxed mode, nothing gives an implementation license to raise a spurious exception when an intermediate result overflows but the final result does not. Thus, implementations of the forward hyperbolic functions need to be somewhat more sophisticated than is suggested by the usual textbook formulae that compute them in terms of exponentials. An implementation that accommodates signed zeros, such as one on IEEE hardware (where Float_Type'Signed_Zeros is true), is required to exploit them in several important contexts, in particular the signs of the zero results from the "odd" functions Sin, Tan, and their inverses and hyperbolic analogs, at the origin, and the sign of the half-cycle result from Arctan and Arccot; this follows a recommendation [Kahan 87] that provides important benefits for complex elementary functions built upon the real elementary functions, and for applications in conformal mapping. Exploitation of signed zeros at the many other places where the elementary functions can return zero results is left implementation- defined, since no obvious guidelines exist for these cases. === <span id="3-2">A.3.2 Random Number Generation</span> === The capability of generating random numbers is required for many applications. It is especially common in simulations, even when other aspects of floating point computation are not heavily stressed. Indeed, some applications of random numbers have no need at all for floating point computation. For these reasons, Ada 95 provides in the predefined language environment a package, Numerics.Float_Random, that defines types and operations for generating random floating point numbers uniformly distributed over the range 0.0 .. 1.0 and a generic package, Numerics.Discrete_Random, that defines types and operations for generating uniformly distributed random values of a discrete subtype specified by the user. As a simple example, various values of a simulated uniform risk could be generated by writing <syntaxhighlight lang="Ada"> use Ada.Numerics.Float_Random; Risk: Float range 0.0 .. 1.0; G: Generator; ... loop Risk := Random(G); -- a new value for risk ... end loop; ...</syntaxhighlight> It has been the custom in other languages (for example, Fortran 90) to provide only a generator of uniformly distributed random floating point numbers and to standardize the range to 0.0 .. 1.0. Usually it is also stated that the value 1.0 is never generated, although values as close to 1.0 as the hardware permits may be generated. Sometimes the value 0.0 is excluded from the range instead, or in addition. The user who requires random floating point numbers uniformly distributed in some other range or having some other distribution, or who requires uniformly distributed random integers, is required to figure out and implement a conversion of what the language provides to the type and range desired. Although some conversion techniques are robust with respect to whether 0.0 or 1.0 can occur, others might fail to stay within the desired range, or might even raise an exception, should these extreme values be generated; with a user-designed conversion, there is also a risk of introducing bias into the distribution. The random number facility designed for Ada 95 initially followed the same custom. However, concerns about the potential difficulties of user- designed post-generation conversion, coupled with the assertion that the majority of applications for random numbers actually need random integers, led to the inclusion of a capability for generating uniformly distributed random integers directly. The provision of that capability also allows for potentially more efficient implementations of integer generators, because it gives designs that can stay in the integer domain the freedom to do so. Thus a random integer in the range 1 to 49 inclusive can be generated by <syntaxhighlight lang="Ada"> subtype Lotto is Integer range 1 .. 49; package Lottery is new Ada.Numerics.Discrete_Random(Lotto); use Lottery; G: Generator; Number: Lotto; ... loop Number := Random(G); -- next number for lottery ticket ... end loop; ...</syntaxhighlight> The use of generics to parameterize the integer range desired seemed obvious and appropriate, because most applications for random integers need a sequence of values in some fixed, problem-dependent subtype. As an alternative or a potential addition, we considered specifying the range dynamically on each call for a random number; this would have been convenient for those applications that require a random integer from a different range on each call. Reasoning that such applications are rare, we left their special needs to be addressed by using the floating point generator, coupled with post-generation conversion to the dynamically varying integer range. Help for the occasional user who faces the need to perform such a conversion is provided by a note in the reference manual, which describes a robust conversion technique [RM95 A.5.2(50..52)]. Note that the parameter of Discrete_Random can be of any discrete subtype and so one can easily obtain random Boolean values, random characters, random days of the week and so on. Once the potential conversion problems had been solved by the combination of providing a generic discrete generator and documenting a robust conversion technique for the small number of applications that cannot use the generic generator, some of the pressure on the floating point generator was relieved. In particular, it was no longer necessary to specify that it must avoid generating 0.0 or 1.0. The floating point generator is allowed to yield any value in its range, which can be described as the range 0.0 .. 1.0 without further qualification. Of course, some implementations may be incapable of generating 0.0 or 1.0, but the user does not need to know that and would be better off not knowing it (portability could be compromised by exploiting knowledge that a particular implementation of the random number generator cannot deliver one or both bounds of the range). A note in the reference manual [RM95 A.5.2(52..54)] discusses ways of transforming the result of the floating point generator, using the Log function, into exponentially distributed random floating point numbers, illustrating a technique that avoids the Argument_Error exception that Log would raise when the value of its parameter is zero. <dl> <dt>Generators</dt> <dd><p>With the obvious exception of the result subtype, the two predefined packages declare the same types and operations, thereby simplifying their description and use. In the remainder of this section, we therefore discuss the contents of the packages without (in most cases) naming one or the other.</p> <p>Applications vary widely in their requirements for random number generation. Global floating point and discrete random number generators would suffice for most applications, but more demanding applications require multiple generators (either one in each of several tasks or several in one task), with each generator giving rise to a different sequence of random numbers. For this reason, we provide in both packages a type called Generator, each of whose objects is associated with a distinct sequence of random numbers.</p> <p>Operations on generators, such as obtaining the "next" random number from the associated sequence, are provided by subprograms that take an object of type Generator as a parameter. Applications requiring multiple generators can declare the required number of objects of type Generator in the tasks where they are needed. The mechanism is simple enough, however, not to be burdensome for applications requiring only a single global generator, which can be declared in the main program or in a library package.</p> <p>(We entertained the idea of also having an implicit generator, which would be used when the Generator parameter is omitted from an operation on generators. This idea was abandoned, however, when agreement could not be reached on the question of whether the implicit generator should be local to each task or global to the tasks in a partition, and, in the latter case, whether serialization should be automatically provided for concurrent operations on the default generator performed in different tasks. To do so would be likely to impose an unnecessary overhead on applications that do no tasking and require only a single generator. The mechanisms provided in the random number packages and elsewhere in the language, particularly protected types and the generic package Ada.Task_Attributes, are sufficient to allow the developer of an advanced application, or the designer of a secondary library, to provide these capabilities, if desired.)</p></dd> <dt>State Information</dt> <dd><p>A generator obviously has state information associated with it, which reflects the current position in the associated sequence of random numbers and provides the basis for the computation of the next random number in the sequence. To allow the implementation wide latitude in choosing appropriate algorithms for generating random numbers, and to enforce the abstraction of a generator, the Generator type is a private type; furthermore, to enforce the distinctness of different generators, the type is limited. The full type is implementation defined.</p> <p>For convenience of use, we chose to make Random a function. Since its parameter must therefore be of mode in, the Generator type in practice has to be realized either as an access type or (if its storage is to be reclaimed through finalization on exit from the generator's scope) as a controlled type containing an access type.</p> <p>Applications that use random numbers vary also in their requirements for repeatability as opposed to uniqueness of the sequence of random numbers. Repeatability is desired during development and testing but often not desired in operational mode when a unique sequence of random numbers is required in each run. To meet both of these needs, we have specified that each generator always starts in the same, fixed (but implementation-defined) state, providing repeatable sequences by default, and we have provided several operations on generators that can be used to alter the state of a generator.</p> <p>Calling the Reset procedure on a generator without specifying any other parameter sets the state to a time-dependent value in an implementation-dependent way.</p> <p>The Reset procedure can also be used to ensure that task-local generators yield different, but repeatable, sequences. Note that by default, the fixed initial state of generators will result in all such generators yielding the same sequence. This is probably not what is desired. We considered specifying that each generator should have a unique initial state, but there is no realistic way to provide for the desired repeatability across different runs, given that the nondeterministic nature of task interactions could result in the "same" tasks (in some logical sense) being created in a different order in different runs.</p> <p>Assuming that each task has a generator, different-but-repeatable sequences in different tasks are achieved by invoking the Reset procedure with an integer Initiator parameter on each generator prior to generating random numbers. The programmer typically must provide integer values uniquely associated with each task's logical function, independent of the order in which the tasks are created. The specified semantics of Reset are such that each distinct integer initiator value will initiate a sequence that will not overlap any other sequence in a practical sense, if the period of a generator is long enough to permit that. At the very least, consecutive integers should result in very different states, so that the resulting sequences will not simply be offset in time by one element or a small number of elements.</p></dd> <dt>Saving the State</dt> <dd><p>Most applications will have no need for capabilities beyond those already described. A small number of applications may have the need to save the current state of a generator and restore it at a later time, perhaps in a different run. This can be done by calling the Save procedure and another overloading of the procedure Reset. The state is saved in a variable of the private type State.</p> <p>As was said earlier, the realization of the internal state of a generator is implementation defined, so as to foster the widest possible innovation in the design of generators and generation algorithms. The state is thus private and might be represented by a single integer or floating point value, or it might be represented by an array of integer or floating point values together with a few auxiliary values, such as indices into the array.</p> <p>Internal generator states can be exported to a variable of the type State, saved in a file, and restored in a later run, all without knowing the representation of the type.</p> <p>We also provide an Image function, which reversibly converts a value of type State to one of type String in an implementation-defined way, perhaps as a concatenation of one or more integer images separated by appropriate delimiters. The maximum length of the string obtained from the Image function is given by the named number Max_Image_Width; images of states can be manipulated conveniently in strings of this maximum length obtained by the use of Ada.Strings.Bounded. Using Save and Image, one can examine (a representation of) the current internal state for debugging purposes; one might use these subprograms in an interactive debugger, with no advanced planning, to make a pencilled note of the current state with the intention of typing it back in later. This does not require knowledge of the mapping between states and strings.</p> <p>The inverse operation, Value, converts the string representation of an internal state back into a value of type State, which can then be imported into a generator by calling the Reset procedure. This pair of subprograms supports, without knowledge of the mapping between states and strings, the restoration of a state saved in the form of a string. Of couse if one does know the implementation's mapping of strings to states, then one can use Value and Reset to create arbitrary internal states for experimentation purposes. If passed a string that cannot be interpreted as the image of a state, Value raises Constraint_Error. This is the only time that the possibly expensive operation of state validation is required; it is not required every time Random is called, nor even when resetting a generator from a state.</p> <p>We considered an alternative design, perhaps closer to the norm for random number generators, in which Random is a procedure that acts directly on the state, the latter being held in storage provided by the user. There would be no need for the Save and Reset (from-saved-state) procedures in this design, since the generator and state types would effectively be one and the same. The only real problem with this design is that it necessitates making Random a procedure, which would interfere with the programmer's ability to compose clear and meaningful expressions.</p> <p>Of course, most simple applications will have no need to concern themselves with the State type: no need to declare variables of type State, and no need to call Save or Reset with a state parameter.</p></dd> <dt>Statistical Considerations</dt> <dd><p>The result subtype of the Random function in Float_Random is a subtype of Float with a range of 0.0 .. 1.0. The subtype is called Uniformly_Distributed to emphasize that a large set of random numbers obtained from this function will exhibit an (approximately) uniform distribution. It is the only distribution provided because it is the most frequently required distribution and because other distributions can be built on top of a uniform distribution using well-known techniques. In the case of Discrete_Random, it does not really make sense to consider other than uniform distributions.</p> <p>No provision is made for obtaining floating point random numbers with a precision other than that of Float. One reason is that applications typically do not have a need either for extremely precise random floating point numbers (those with a very fine granularity) or for random floating point numbers with several different precisions. Assuming that they are to be used as real numbers, and not converted to integers, the precision of a set of random floating point numbers generally does not matter unless an immense quantity of them are to be consumed. High precision random floating point numbers would be needed if they were to be converted to integers in some very wide range, but the provision of Discrete_Random makes that unnecessary. A second reason for providing random floating point numbers only with the precision of Float, and especially for not providing them with a precision of the user's choice, is that algorithms for random number generation are often tied to the use of particular hardware representations, which essentially dictates the precision obtained.</p> <p>Nothing is said about the number of distinct values between 0.0 and 1.0 that must be (capable of being) delivered by the Random function in Float_Random. Indeed, in the spirit of not requiring guaranteed numerical performance unless the Numerics Annex is implemented, the specification of Float_Random says nothing about the quality of the result obtained from Random, except that a large number of such results must appear to be approximately uniformly distributed. On the other hand, the Numerics Annex specifies the minimum period of the generation algorithm, a wide range of statistical tests that must be satisfied by that algorithm, and the resolution of the time-dependent Reset function. In implementations in which Float corresponds to the hardware's double- precision type, the floating point random number algorithm can be based on the use of single-precision hardware, and can coerce the single- precision results to double precision at the final step, provided that the statistical tests are satisfied, which is perfectly feasible.</p> <p>Details of the statistical tests, which are adapted from [Knuth 81] and other sources, are provided in an annotation in the [AARM]. The tests applicable to the floating point random number generator facility all exploit the floating point nature of the random numbers directly; they do not convert the numbers to integers. Different tests are applicable to the discrete random number generator.</p> <p>In the rare case that random floating point numbers of higher precision (finer granularity) than that of Float are needed, the user should obtain them by suitably combining two or more successive results from Random. For example, two successive values might be used to provide the high-order and the low-order parts of a higher-precision result.</p> <p>Guaranteeing that all the values in a wide integer range will eventually be generated is, in general, rather difficult and so is not required for the discrete generator. Nevertheless, some guarantee of this nature is desirable for more modest ranges. We thus require that if the range of the subtype has 2**15 or fewer values then each value of the range will be delivered in a finite number of calls. This coverage requirement is in the specification of Discrete_Random in the Predefined Language Environment Annex; because it so directly affects the usability of the discrete random number generator facility, it was not thought appropriate to relegate the coverage requirement to the (optional) Numerics Annex. It is practical to verify by testing that the coverage requirement is satisfied for ranges up to this size, but it is not practical to verify the same for significantly wider ranges; for that matter, only a very long-running application could detect that a wide integer range is not being completely covered by the random numbers that are generated. Satisfying the coverage requirement is easily achieved by an underlying floating point algorithm, even one implemented in single precision, that converts its intermediate floating point result to the integer result subtype by appropriate use of scaling and type conversion.</p> <p>The modest requirement discussed above does not completely eliminate all the difficulty in implementing Discrete_Random. Even the straightforward scaling and conversion technique faces mundane problems when the size of the integer range exceeds Integer'Last. Note that the size of the range of the predefined subtype Integer exceeds Integer'Last by about a factor of two, so that an instantiation of Discrete_Random for that predefined subtype will have to confront certain mundane problems, even if it does not purport to cover that range completely. These implementation burdens could have been eliminated by imposing restrictions on the (size of the ranges of the) subtypes with which Discrete_Random could be instantiated, but such restrictions are inimical to the spirit of Ada.</p> <p>Of course, implementations of Discrete_Random need not be based on an underlying floating point algorithm, and indeed, as has already been said, part of the justification for providing this package separately from Float_Random has to do with the efficiency gains that can be realized when the former is implemented in terms of an underlying integer algorithm, with no use of floating point at all. Nevertheless, it may be convenient and sufficiently efficient for the discrete generator facility to be implemented in terms of a floating point algorithm. There are implementations of the venerable multiplicative linear congruential generator with multiplier 7**5 and modulus 2**31-1 of [Lewis 69] and both the add-with-carry and subtract-with-borrow Fibonacci generators of [Marsaglia 91] that remain entirely within the floating point domain, and which therefore pay no premium for conversion from integer to floating point. These algorithms have been verified to pass the statistical requirements of the Numerics Annex. (Other algorithms that might be expected to pass, but that have not been explicitly tested, include the combination generators of [Wichmann 82] and [L'Ecuyer 88] and the x**2 mod N generators of [Blum 86]; each of the algorithms mentioned here has much to recommend it.)</p></dd></dl> === <span id="3-3">A.3.3 Attributes of Real Types</span> === Most of the attributes of floating and fixed point types are defined in the Predefined Language Environment Annex. These attributes are discussed elsewhere in this Rationale (see 6.2). == <span id="4">A.4 Input-Output</span> == Enhancements to input-output include a facility for heterogeneous streams, additional flexibility for Text_IO, and further file manipulation capabilities. === <span id="4-1">A.4.1 Stream Input and Output</span> === The packages Sequential_IO and Direct_IO have not proved to be sufficiently flexible for some applications because they only process homogeneous files. Even so this is fairly liberal in the case of Sequential_IO which now has the form <syntaxhighlight lang="Ada"> generic type Element_Type(<>) is private; package Ada.Sequential_IO is ...</syntaxhighlight> since the actual parameter can be any indefinite type and hence can be a class-wide type. This does not apply to Direct_IO which can only take a definite type as a parameter because of the need to index individual elements. In order to provide greater flexibility, totally heterogeneous streams can be processed using the new package Streams [RM95 13.13] and several child packages [RM95 A.12]. The general idea is that there is a stream associated with any file declared using the package Ada.Streams.Stream_IO. Such a file may be processed sequentially using the stream mechanism and also in a positional manner similar to Direct_IO. We will consider the stream process first and return to positional use later. The package Streams.Stream_IO enables a file to be created, opened and closed in the usual manner. Moreover, there is also a function Stream which takes a stream file and returns (an access to) the stream associated with the file. In outline the first part of the package is <syntaxhighlight lang="Ada"> package Ada.Streams.Stream_IO is type Stream_Access is access all Root_Stream_Type'Class; type File_Type is limited private; -- Create, Open, ... function Stream(File: in File_Type) return Stream_Access; ... end Ada.Streams.Stream_IO;</syntaxhighlight> Observe that all streams are derived from the abstract type Streams.Root_Stream_Type and access to a stream is typically through an access parameter designating an object of the type Streams.Root_Stream_Type'Class. We will return to the package Streams and the abstract type Root_Stream_Type in a moment. Sequential processing of streams is performed using attributes T'Read, T'Write, T'Input and T'Output. These attributes are predefined for all nonlimited types. The user can replace them by providing an attribute definition clause and can also define such attributes explicitly for limited types. This gives the user fine control over the processing when necessary. The attributes T'Read and T'Write will be considered first; T'Input and T'Output (which are especially relevant to indefinite subtypes) will be considered later. The attributes Read and Write take parameters denoting the stream and the element of type T thus <syntaxhighlight lang="Ada"> procedure T'Write(Stream : access Streams.Root_Stream_Type'Class; Item : in T); procedure T'Read(Stream : access Streams.Root_Stream_Type'Class; Item : out T);</syntaxhighlight> As a simple example, suppose we wish to write a mixture of integers, month names and dates where type Date might be <syntaxhighlight lang="Ada"> type Date is record Day : Integer; Month : Month_Name; Year : Integer; end record;</syntaxhighlight> We first create a file using the normal techniques and then obtain an access to the associated stream. We can then invoke the Write attribute procedure on the values to be written to the stream. We have <syntaxhighlight lang="Ada"> use Streams.Stream_IO; Mixed_File : File_Type; S : Stream_Access; ... Create(Mixed_File); S := Stream(Mixed_File); ... Date'Write(S, Some_Date); Integer'Write(S, Some_Integer); Month_Name'Write(S, This_Month); ...</syntaxhighlight> Note that Streams.Stream_IO is not a generic package and so does not have to be instantiated; all such heterogeneous files are of the same type. Note also that they are binary files. A file written in this way can be read back in a similar manner, but of course if we attempt to read things with the inappropriate subprogram then we will get a funny value or Data_Error. In the case of a simple record such as Date the predefined Write attribute simply calls the attributes for the components in order. So conceptually we have <syntaxhighlight lang="Ada"> procedure Date'Write(Stream : access Streams.Root_Stream_Type'Class; Item : in Date) is begin Integer'Write(Stream, Item.Day); Month_Name'Write(Stream, Item.Month); Integer'Write(Stream, Item.Year); end;</syntaxhighlight> We can supply our own version of Write. Suppose for some reason that we wished to output the month name in a date as the corresponding integer; we could write <syntaxhighlight lang="Ada"> procedure Date_Write(Stream : access Streams.Root_Stream_Type'Class; Item : in Date) is begin Integer'Write(Stream, Item.Day); Integer'Write(Stream, Month_Name'Pos(Item.Month) + 1); Integer'Write(Stream, Item.Year); end Date_Write; for Date'Write use Date_Write;</syntaxhighlight> and then the statement <syntaxhighlight lang="Ada"> Date'Write(S, Some_Date);</syntaxhighlight> will use the new format for the output of dates. Similar facilities apply to input and indeed if we wish to read the dates back in we would need to declare the complementary version of Date'Read to read the month as an integer and convert to the appropriate value of Month_Name. Note that we have only changed the output of months in dates, if we wish to change the format of all months then rather than redefining Date'Write we could simply redefine Month_Name'Write and this would naturally have the indirect effect of also changing the output of dates. Note carefully that the predefined attributes T'Read and T'Write can only be overridden by an attribute definition clause in the same package specification or declarative part where T is declared (just like any representation item). As a consequence these predefined attributes cannot be changed for the predefined types. But they can be changed for types derived from them. The situation is slightly more complex in the case of arrays, and also records with discriminants, since we have to take account of the "dope" information represented by the bounds and discriminants. (In the case of a discriminant with defaults, the discriminant is treated as an ordinary component.) This is done using the additional attributes Input and Output. The general idea is that Input and Output process dope information (if any) and then call Read and Write to process the rest of the value. Their profiles are <syntaxhighlight lang="Ada"> procedure T'Output(Stream : access Streams.Root_Stream_Type'Class; Item : in T); function T'Input(Stream: access Streams.Root_Stream_Type'Class) return T;</syntaxhighlight> Note that Input is a function since T may be indefinite and we may not know the constraints for a particular call. Thus in the case of an array the procedure Output outputs the bounds of the value and then calls Write to output the value itself. In the case of a record type with discriminants, if it has defaults (is definite) then Output simply calls Write which treats the discriminants as just other components. If there are no defaults then Output first outputs the discriminants and then calls Write to process the remainder of the record. As an example consider the case of a definite subtype of a type whose first subtype is indefinite such as <syntaxhighlight lang="Ada"> subtype String_6 is String(1 .. 6); S: String_6 := "String"; ... String_6'Output(S); -- outputs bounds String_6'Write(S); -- does not output bounds</syntaxhighlight> Note that the attributes Output and Write belong to the types and so it is immaterial whether we write String_6'Write or String'Write. The above description of T'Input and T'Output applies to the default attributes. They could be redefined to do anything and not necessarily call T'Read and T'Write. Note moreover that Input and Output also exist for definite subtypes; their defaults just call Read and Write. There are also attributes T'Class'Output and T'Class'Input for dealing with class-wide types. For output, the external representation of the tag (see [RM95 3.9]) is output and then the procedure Output for the specific type is called (by dispatching) in order to output the specific value (which in turn will call Write). Similarly on input, the tag is first read and then, according to its value, the corresponding function Input is called by dispatching. For completeness, T'Class'Read (T'Class'Write) is defined to dispatch to the subprogram denoted by the Read (respectively, Write) attribute of the specific type identified by the tag. The general principle is, of course, that whatever is written can then be read back in again by the appropriate reverse operation. We now return to a consideration of the underlying structure. All streams are derived from the abstract type Streams.Root_Stream_Type which has two abstract operations, Read and Write thus <syntaxhighlight lang="Ada"> procedure Read(Stream : in out Root_Stream_Type; Item : out Stream_Element_Array; Last : out Stream_Element_Offset) is abstract; procedure Write(Stream : in out Root_Stream_Type; Item : in Stream_Element_Array) is abstract;</syntaxhighlight> These work in terms of stream elements rather than individual typed values. Note the difference between stream elements and storage elements (the latter being used for the control of storage pools which was discussed in 13.4). Storage elements concern internal storage whereas stream elements concern external information and are thus appropriate across a distributed system. The predefined Read and Write attributes use the operations Read and Write of the associated stream, and the user could define new values for the attributes in the same way. Note, however, that the parameter Stream of the root type is of the type Root_Stream_Type whereas that of the attribute is an access type denoting the corresponding class. So any such user-defined attribute will have to do an appropriate dereference thus <syntaxhighlight lang="Ada"> procedure My_Write(Stream : access Streams.Root_Stream_Type'Class; Item : T) is begin ... -- convert value into stream elements Streams.Write(Stream.all, ...); -- dispatches end My_Write;</syntaxhighlight> We conclude by remarking that Stream_IO can also be used for indexed access. This is possible because the file is structured as a sequence of stream elements. Indexing then works in terms of stream elements much as Direct_IO works in terms of the typed elements. Thus the index can be read and reset. The procedures Read and Write process from the current value of the index and there is also an alternative Read that starts at a specified value of the index. The procedures Read and Write (which take a file as parameter) correspond precisely to the dispatching operations of the associated stream. === <span id="4-2">A.4.2 Text_IO</span> === The main changes to Ada.Text_IO are the addition of internal generic packages Modular_IO (similar to Integer_IO) and Decimal_IO (similar to Fixed_IO). There is also a completely distinct package Ada.Wide_Text_IO which provides identical facilities to Ada.Text_IO except that it works in terms of the types Wide_Character and Wide_String rather than Character and String. Text_IO and Wide_Text_IO declare distinct file types. Both Text_IO and Wide_Text_IO have a child package Editing defined in the Information Systems Annex. This provides specialized facilities for the output of decimal values controlled by picture formats; for details see F.1. Similarly both packages have a child Complex_IO defined in the Numerics Annex; see G.1.3. Small but important changes to Text_IO are the addition of subprograms Look_Ahead, Get_Immediate and Flush. The procedure Look_Ahead enables the next character to be determined without removing it and thereby enables the user to write procedures with similar behavior to predefined Get on numeric and enumeration types. The procedure Get_Immediate removes a single character from the file and bypasses any buffering that might otherwise be used; it is designed for interactive use. A call of Flush causes the remainder of any partly processed output buffer to be output. A minor point is that the procedures Get for real types accept a literal in more liberal formats than in Ada 83. Leading and trailing zeros before or after the point are no longer required and indeed the point itself can be omitted. Thus the following are all acceptable forms for input for real types: <syntaxhighlight lang="Ada"> 0.567 123 0,567 123 123</syntaxhighlight> whereas in Ada 83 only the first two were acceptable. This is in some respects an incompatibility since a form such as .567 would cause Data_Error to be raised in Ada 83. However, the main advantage is interoperability with other languages; data produced by Fortran programs can then be processed directly. Furthermore, the allowed formats are in accordance with ISO 6093:1985 which defines language independent formats for the textual representation of floating point numbers. There are also nongeneric equivalents to Integer_IO and Float_IO for each of the predefined types Integer, Long_Integer, Float, Long_Float and so on. These have names such as Ada.Integer_Text_IO, Ada.Long_Integer_Text_IO, and Ada.Float_Text_IO. Observe that they are not child packages of Ada.Text_IO but direct children of Ada, thus allowing the names to be kept reasonably short. A major reason for introducing these nongeneric equivalents was to facilitate teaching Ada to new users. Experience with teaching Ada 83 has shown that fundamental input-output was unnecessarily complicated by the reliance on generics, which gave the language an air of difficulty. So rather than writing <syntaxhighlight lang="Ada"> with Ada.Text_IO; procedure Example is package Int_IO is new Ada.Text_IO.Integer_IO(Integer); use Int_IO; N: Integer; begin ... Put(N); ... end Example;</syntaxhighlight> one can now perform simple output without needing to instantiate a generic <syntaxhighlight lang="Ada"> with Ada.Integer_Text_IO; use Ada.Integer_Text_IO; procedure Example is N: Integer; begin ... Put(N); ... end Example;</syntaxhighlight> Another advantage of the nongeneric equivalents is that the user does not have to worry about an appropriate name for the instantiated version (and indeed fret over whether it might also be called Integer_IO without confusion with the generic version, or some other name such as we chose above). Having standard names also promotes portability since many vendors had provided such nongeneric equivalents but with different names. Note carefully that these packages are said to be nongeneric equivalents rather than preinstantiated versions. This is so that implementations can use special efficient techniques not possible in the generic versions. A minor consequence is that the nongeneric equivalents cannot be used as actual package parameters corresponding to the generic package. Thus we cannot use Ada.Integer_Text_IO as an actual parameter to <syntaxhighlight lang="Ada"> generic with package P is new Ada.Text_IO.Integer_IO; package Q is ...</syntaxhighlight> Similar nongeneric equivalents apply to the generic packages for elementary functions, complex types and complex elementary functions, see A.3.1 and G.1. Finally, it is possible to treat a Text_IO file as a stream and hence to use the stream facilities of the previous section with text files. This is done by calling the function Stream in the child package Text_IO.Text_Streams. This function takes a Text_IO file as parameter and returns an access to the corresponding stream. It is then possible to intermix binary and text input-output and to use the current file mechanism with streams. === <span id="4-3">A.4.3 File Manipulation</span> === The Ada 83 package Sequential_IO did not make provision for appending data to the end of an existing file. As a consequence implementations provided a variety of solutions using pragmas and the form parameter and so on. In Ada 95 we have overcome this lack of portability by adding a further literal Append_File to the type File_Mode for Sequential_IO and Text_IO. It also exists for Stream_IO but not for Direct_IO. The concept of a current error file for Text_IO is introduced, plus subprograms Standard_Error, Current_Error and Set_Error by analogy with the similar subprograms for current input and current output. The function Standard_Error returns the standard error file for the system. On some systems standard error and standard output might be the same. Error files are a convenience for the user; the ability to switch error files in a similar manner to the default output file enables the user to keep the real output distinct from error messages in a portable manner. A problem with the Ada 83 subprograms for manipulating the current files is that it is not possible to store the current value for later use because the file type is limited private. As mentioned in 7.3, it is possible to temporarily "hang on" to the current value by the use of renaming thus <syntaxhighlight lang="Ada"> Old_File: File_Type renames Current_Output; ... -- set and use a different file Set_Output(Old_File);</syntaxhighlight> and thus permits some other file to be used and then the preexisting environment to be restored afterwards. This works because the result of a function call is treated like an object and can then be renamed. However, this technique does not permit a file value to be stored in an arbitrary way. In order to overcome this difficulty, further overloadings of the various functions are introduced which manipulate an access value which can then be stored. Thus <syntaxhighlight lang="Ada"> type File_Access is access constant File_Type; function Current_Input return File_Access; function Current_Output return File_Access; function Current_Error return File_Access;</syntaxhighlight> and similarly for Standard_Input and so on. Additional procedures for setting the values are not required. We can then write <syntaxhighlight lang="Ada"> procedure P(...) is New_File : File_Type; Old_File_Ref : constant File_Access := Current_Output; begin Open(New_File, ...); Set_Output(New_File); -- use the new file Set_Output(Old_File_Ref.all); Close(New_File); end P;</syntaxhighlight> More sophisticated file manipulation is also possible. We could for example have an array or linked list of input files and then concatenate them for output. As another example, a utility program for pre- processing text files could handle nested "include"s by maintaining a stack of File_Access values. Making the access type an access to constant prevents passing the reference to subprograms with in out parameters and thus prevents problems such as might arise from calling Close on Current_Input. == <span id="5">A.5 Command Line</span> == The package Ada.Command_Line provides an Ada program with a simple means of accessing any arguments of the command which invoked it. The package also enables the program to set a return status. Clearly the interpretation and implementation of these facilities depends very much on the underlying operating system. The function Command_Name returns (as a string) the command that invoked the Ada program and the function Argument_Count returns the number of arguments associated with the command. The function Argument takes an integer and returns the corresponding individual command argument also as a string. The exit status can be set by a call of Set_Exit_Status which takes an integer parameter. An alternative scheme based on using the parameters and results of the Ada main subprogram as the command arguments and exit status was rejected for a number of reasons. The main reason was that the start and end of the main subprogram are not the start and end of the execution of the Ada program as a whole; elaboration of library packages occurs before and might want access to command arguments and similarly, library tasks can outlive the main subprogram and might want to set the exit status. == <span id="6">A.6 Requirements Summary</span> == The study topic * S10.4-A(1) - Varying-length String Package is met by the bounded and unbounded-length string packages, and the study topic * S10.4-A(2) - String Manipulation Functions is met in part by the string handling packages. The requirement * R11.1-A(1) - Standard Mathematics Packages is met by the generic elementary functions and random number packages. The somewhat general requirement * R4.6-B(1) - Additional Input/Output Functions calls for additional capability. In particular it suggests that there should be a standard way to append data to an existing file and the ability to have heterogeneous files. These specific requirements (and others) have been met as we have seen. Moreover the requirement * R4.6-A(1) - Interactive TEXT_IO is specifically addressed by the introduction of the subprograms Get_Immediate, Look_Ahead and Flush; see A.4.2. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p3|Previous]] | [[Guide:9x_rationale/rat95-p3-b|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=Annex A. Predefined Language Environment}} 2xmcrhhepicm37zk92nnhx9uipk3mio Guide:9x rationale/rat95-p3-b 4200 346 2197 2196 2019-04-20T18:46:09Z WikiVisor 11 wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p3-a|Previous]] | [[Guide:9x_rationale/rat95-p3-c|Next]]</div> It is very important for Ada 95 programs to be able to interface effectively with systems written in other languages. For example, the success of Ada 95 depends in part on its ability to cleanly and portably support interfaces to such systems as X Windows, POSIX, and commercial windows-based personal computer environments. (The portability in question is the ability to take a given Ada program or binding that interfaces with an external system, and move it to an environment with the same external system but a different Ada implementation.) To achieve this goal we have supplied three pragmas for interfacing with non-Ada software, and child packages Interfaces.C, Interfaces.COBOL, and Interfaces.Fortran which declare types, subprograms and other entities useful for interfacing with the three languages. The root package Interfaces contains declarations for hardware-specific numeric types, described in 3.3. == <span id="1">B.1 Interfacing Pragmas</span> == Experience with pragma Interface in Ada 83 has uncovered a number of issues that may interfere with developing portable Ada code that is to be linked with foreign language modules. We have therefore removed pragma Interface (though the implementation may choose still to support it for upward compatibility) and have added the three pragmas Import (effectively replacing Interface), Export and Convention which provide the following capabilities: * Calling Ada subprograms from other languages. Ada 83 only supported calls in one direction, from Ada to external code modules. * Communicating with external systems via access to subprogram types. * Specifying external names (and link names) where appropriate. Most Ada 83 implementations supported such an ability and it is beneficial to users that it be standardized [Fowler 89]. * Communicating with external systems via objects and other entities. Ada 83 only supported interfacing via subprogram calls. The following example illustrates how Ada 95 procedures can call and be called from a program written in the C language. <syntaxhighlight lang="Ada"> type XT_Callback is access procedure (Widget_Id : in out XT_Intrinsics.Widget; Closure : in X_Lib.X_Address; Call_Data : in X_Lib.X_Address); pragma Convention(C, XT_Callback); procedure XT_Add_Callback (The_Widget : in out XT_Intrinsics.Widget; Callback_Name : in String; Callback : in XT_Callback; Client_Data : in XT_Intrinsics.XT_Pointer); pragma Import(C, XT_Add_Callback, External_Name => "XtAddCallBack"); procedure My_Callback(Widget_Id : in out XT_Intrinsics.Widget; Closure : in X_Lib.X_Address; Call_Data : in X_Lib.X_Address) is separate; pragma Convention(C, My_Callback); My_Widget : XT_Intrinsics.Widget; ... XT_Add_Callback(My_Widget, "Mousedown" & ASCII.Nul, My_Callback'Access, XT_Intrinsics.Null_Data);</syntaxhighlight> The pragma Convention applies to the type XT_Callback, and indicates that values of this type designate subprograms callable from programs written in C. The machine code generated for calls through the access values of the type XT_Callback will follow the conventions of the C compiler. The pragma Import indicates that the procedure XT_Add_Callback is written with the calling conventions of a C compiler. The third parameter of the pragma specifies the external name (in this case the C name) of the subprogram. The pragma Convention also applies to My_Callback. This informs the compiler that the procedure is written in Ada but is intended to be called from a C program, which may affect how it will reference its parameters. My_Callback'Access will yield a value compatible with XT_Callback, because the same calling convention is specified for both. Note that it is unnecessary to apply the pragma Export to My_Callback since, although called from the C program, it is called indirectly through the access to subprogram value and the Ada identifier itself is not required externally. The pragmas Import and Export may omit the external name if it is the same as the Ada identifier. A fourth parameter may be used to specify the link name if necessary. The pragmas Import and Export may also be applied to objects. In particular a deferred constant can be completed by a pragma Import; this specifies that the object is defined externally to the Ada program. Similarly a pragma Export can be used to indicate that an object is used externally. A programmer would typically use pragma Export in situations where the main subprogram is written in the external language. This raises some semantic issues, because correct execution of the exported Ada subprogram might depend on having certain Ada library units elaborated before the subprogram is invoked. For example, the subprogram might reference library package data objects that are initialized by the package body; or the subprogram might execute a construct (such as an allocator) that requires the Ada run-time system to have been elaborated. To handle such situations, Ada 95 advises the implementation [RM95 B.1(39)] to supply subprograms with link names "adainit" and "adafinal". The adainit subprogram contains elaboration code for the Ada library units, and adafinal contains any needed finalization code (such as finalization of the environment task). Thus a main subprogram written in the external language should call adainit before the first call to an Ada subprogram, and adafinal after the last. == <span id="2">B.2 C Interface Package</span> == The C interface package, Interfaces.C, supports importing C functions into Ada, and exporting Ada subprograms to C. Since many bindings and other external systems are written in C, one of the more important objectives of Ada 95 is to ease the job of having Ada code work with such software. Part of the issue in arranging an interface to a foreign language, of particular importance with C, is to allow an Ada subprogram to be called from code written in the foreign language. This is handled in Ada 95 through a combination of pragma Convention and access to subprogram types, as illustrated above. Further child packages Interfaces.C.Strings and Interfaces.C.Pointers provide specialized functionality for dealing with C strings and pointers. === <span id="2-1">B.2.1 Scalar Types</span> === C's predefined integer, floating point, and character types are modelled directly in Interfaces.C. The Ada implementation is responsible for defining the Ada types such that they have the same representation as the corresponding C types in the supported C implementation. Since C parameters are passed copy-in, interfacing to a C function taking a scalar parameter is straightforward. The program declares an Ada subprogram with an in parameter of the corresponding type. A C function may have a t* parameter, where t is a scalar type, and where the caller is supposed to pass a reference to a scalar. If such a function is imported, then the corresponding Ada subprogram would declare either an access T parameter, or an in out T parameter. === <span id="2-2">B.2.2 Strings</span> === C's string representation and manipulation come in several varieties, and we have tried to define the interface package so as to support the most typical applications. The Interfaces.C package provides an implementation-defined character type, char, designed to model the C run- time character type. This may or may not be the same as Ada's type Character; thus the package provides mappings between the types char and Character. Unlike COBOL, the mappings between the C and Ada character types do not need to be dynamically modifiable; hence they are captured by functions. In the common case where the character set is the same in C and Ada, the implementation should define the conversion functions through unchecked conversions expanded inline, with thus no run-time overhead. One important application of the C interface package is for the programmer to compose a C string and pass it to a C function. We provide several ways to accomplish this goal. One approach is for the programmer to declare an object that will hold the C array, and then pass this array to the C function. This is realized via the type char_array: <syntaxhighlight lang="Ada"> type char_array is array (size_t range <>) of char;</syntaxhighlight> The programmer can declare an Ada String and convert it to a char_array (or simply declare a char_array directly), and pass the char_array as actual parameter to the C function that is expecting a char *. The implication of pragma Import on the subprogram is that the char_array will be passed by reference, with no "descriptor" for the bounds; the compiler needs to implement this in such a way that what is passed is a pointer to the first element. The package Interfaces.C , which provides the above conversions, is Pure; this extends its applicability in distributed applications that need to interface with C code. An alternative approach for passing strings to C functions is for the programmer to obtain a C char pointer from an Ada String (or from a char_array) by invoking an allocation function. The child package Interfaces.C.Strings provides a private type chars_ptr that corresponds to C's char *, and two allocation functions. To avoid storage leakage, we also provide a Free procedure that releases the storage that was claimed by one of these allocate functions. If one of these allocate functions is invoked from an Ada program, then it is the responsibility of the Ada program (rather than the called C function) to reclaim that storage. It is typical for a C function that deals with strings to adopt the convention that the string is delimited by a nul character. The C interface package supports this convention. A constant nul of type char is declared, and the function Value(chars_ptr) in Interfaces.C.Strings returns a char_array up to and including the first nul in the array that the chars_ptr points to. Some C functions that deal with strings do not assume nul termination; instead, the programmer passes an explicit length along with the pointer to the first element. This style is also supported by Interfaces.C, since objects of type char_array need not be terminated by nul. === <span id="2-3">B.2.3 Pointers and Arrays</span> === The generic package Interfaces.C.Pointers allows the Ada programmer to perform C-style operations on pointers. It includes an access type Pointer, Value functions that dereference a Pointer and deliver the designated array, several pointer arithmetic operations, and "copy" procedures that copy the contents of a source pointer into the array designated by a destination pointer. As in C, it treats an object Ptr of type Pointer as a pointer to the first element of an array, so that for example, adding 1 to Ptr yields a pointer to the second element of the array. This generic package allows two styles of usage: one in which the array is terminated by a special terminator element; and another in which the programmer needs to keep track of the length. This package may be used to interface with a C function that takes a "*" parameter. The Pointer type emerging from an instantiation corresponds to the "*" parameter to the C function. === <span id="2-4">B.2.4 Structs</span> === If the C function expects a "struct *", the Ada programmer should declare a corresponding simple record type and apply pragma Convention to this type. The Ada compiler will pass a reference to the record as the argument to the C function. Of course, it is not realistic to expect that any Ada record could be passed as a C struct; [RM95, B.1] allows restrictions so that only a "C-eligible" record type T need be supported for pragma Convention(C, T). For example, records with discriminants or dynamically-sized components need not be supported. Nevertheless, the set of types for which pragma Convention needs to be supported is sufficiently broad to cover the kinds of interfaces that arise in practice. In the (rare) situation where the C function takes a struct by value (for example a struct with a small number of small components), the programmer can declare a C function that takes a struct * and which then passes the value of its argument to the actual C function that is needed. === <span id="2-5">B.2.5 Example</span> === The following example shows a typical use of the C interface facilities. <syntaxhighlight lang="Ada"> -- Calling the C Library Function strcpy with Interfaces.C; procedure Test is package C renames Interfaces.C; use type C.char_array; -- Call strcpy: -- C definition of strcpy: -- char *strcpy(char *s1, const char *s2); -- This function copies the string pointed to by s2 -- (including the terminating null character) into the -- array pointed to by s1. If copying takes place -- between objects that overlap, the behavior is undefined. -- The strcpy function returns the value of s1. -- Note: since the C function's return value is of no interest, -- the Ada interface is a procedure procedure Strcpy(Target : out C.char_array; Source : in C.char_array); pragma Import(C, Strcpy, "strcpy"); Chars1: C.char_array(1 .. 20); Chars2: C.char_array(1 .. 20); begin Chars2(1 .. 6) := "qwert" & C.Nul; Strcpy(Chars1, Chars2); -- Now Chars1(1 .. 6) = "qwert" & C.Nul end Test;</syntaxhighlight> == <span id="3">B.3 COBOL Interface Package</span> == The package Interfaces.COBOL allows an Ada program to pass data as parameters to COBOL programs, allows an Ada program to make use of "external" data created by COBOL programs and stored in files or databases, and allows an Ada program to convert an Ada decimal type value to or from a COBOL representation. In order to support the calling of and passing parameters to an existing COBOL program, the interface package supplies types that can be used in an Ada program as parameters to subprograms whose bodies will be in COBOL. These types map to COBOL's alphanumeric and numeric data categories. Several types are provided for support of alphanumeric data. Since COBOL's run-time character set is not necessarily the same as Ada's, Interfaces.COBOL declares an implementation-defined character type COBOL_Character and mappings between Character and COBOL_Character. These mappings are visible variables (rather than, say, functions or constant arrays), since in the situation where COBOL_Character is EBCDIC, the flexibility of dynamically modifying the mappings is needed. Corresponding to COBOL's alphanumeric data is the array type Alphanumeric. Numeric data may have either a "display" or "computational" representation in COBOL. On the Ada side, the data is of a decimal fixed point type. Passing an Ada decimal data item to a COBOL program requires conversion from the Ada decimal type to some type that reflects the representation expected on the COBOL side. ;Computational Representation :Floating point representation is modelled by Ada floating point types, Floating and Long_Floating. Conversion between these types and Ada decimal types is obtained directly, since the type name serves as a conversion function. :Binary representation is modelled by an Ada integer type, Binary, and possibly other types such as Long_Binary. Conversion between, say, Binary and a decimal type is through functions from an instantiation of the generic package Decimal_Conversions. An integer conversion using say Binary as the target and an object of a decimal type as the source does not work, since there would be no way to take into account the scale implicitly associated with the decimal type. :Packed decimal representation is modelled by the Ada array type Packed_Decimal. Conversion between packed decimal and a decimal type is through functions from an instantiation of the generic package Decimal_Conversions. ;Display Representation :Display representation for numeric data is modelled by the array type Numeric. Conversion between display representation and a decimal type is through functions from an instantiation of the generic package Decimal_Conversions. A parameter to the conversion function indicates the desired interpretation of the data (e.g., signed leading separate, etc.) The pragma Convention(COBOL, T) may be applied to a record type T to direct the compiler to choose a COBOL-compatible representation for objects of the type. The package Interfaces.COBOL allows the Ada programmer to deal with data from files or databases created by a COBOL program. For data that is alphanumeric, or in display or packed decimal format, the approach is the same as for passing parameters: instantiate Decimal_Conversions to obtain the needed conversion functions. For binary data, the external representation is treated as a Byte array, and an instantiation of Decimal_Conversions produces a package that declares the needed conversion functions. A parameter to the conversion function indicates the desired interpretation of the data (e.g., high- versus low-order byte first). We had considered defining the binary conversion functions in terms of a Storage_Array rather than a Byte_Array for the "raw data". However, Storage_Array reflects the properties of the machine that is running the Ada program, whereas the external file may have been produced in a different environment. Thus it is simpler to use a model in terms of COBOL-character-sized units. The following examples show typical uses of the COBOL interface. <syntaxhighlight lang="Ada"> with Interfaces.COBOL; procedure Test_Call is -- Calling a foreign COBOL program -- Assume that a COBOL program PROG has the following declaration -- in its LINKAGE section: -- 01 Parameter-Area -- 05 NAME PIC X(20). -- 05 SSN PIC X(9) -- 05 SALARY PIC 99999V99 USAGE COMP. -- The effect of PROG is to update SALARY based on some algorithm package COBOL renames Interfaces.COBOL; type Salary_Type is delta 0.01 digits 7; type COBOL_Record is record Name : COBOL.Numeric(1 .. 20); SSN : COBOL.Numeric(1 .. 9); Salary : COBOL.Binary; -- Assume Binary = 32 bits end record; pragma Convention(COBOL, COBOL_Record); procedure Prog(Item : in out COBOL_Record); pragma Import(COBOL, Prog, "PROG"); package Salary_Conversions is new COBOL.Decimal_Conversions(Salary_Type); Some_Salary : Salary_Type := 12_345.67; Some_Record : COBOL_Record := (Name => "Johnson, John ", SSN => "111223333", Salary => Salary_Conversions.To_Binary(Some_Salary)); begin Prog(Some_Record); ... end Test_Call; with Interfaces.COBOL; with COBOL_Sequential_IO; -- Assumed to be supplied by implementation procedure Test_External_Formats is -- Using data created by a COBOL program -- Assume that a COBOL program has created a sequential file with -- the following record structure, and that we need to -- process the records in an Ada program -- 01 EMPLOYEE-RECORD -- 05 NAME PIC X(20). -- 05 SSN PIC X(9) -- 05 SALARY PIC 99999V99 USAGE COMP. -- 05 ADJUST PIC S999V999 SIGN LEADING SEPARATE -- The COMP data is binary (32 bits), high-order byte first package COBOL renames Interfaces.COBOL; type Salary_Type is delta 0.01 digits 7 range 0.0 .. 99_999.99; type Adjustments_Type is delta 0.001 digits 6; type COBOL_Employee_Record_Type is -- External representation record Name : COBOL.Alphanumeric(1 .. 20); SSN : COBOL.Alphanumeric(1 .. 9); Salary : COBOL.Byte_Array(1 .. 4); Adjust : COBOL.Numeric(1 .. 7); -- Sign and 6 digits end record; pragma Convention(COBOL, COBOL_Employee_Record_Type); package COBOL_Employee_IO is new COBOL_Sequential_IO(COBOL_Employee_Record_Type); use COBOL_Employee_IO; COBOL_File : File_Type; type Ada_Employee_Record_Type is -- Internal representation record Name : String(1 .. 20); SSN : String(1 .. 9); Salary : Salary_Type; Adjust : Adjustments_Type; end record; COBOL_Record : COBOL_Employee_Record_Type; Ada_Record : Ada_Employee_Record_Type; package Salary_Conversions is new COBOL.Decimal_Conversions(Salary_Type); use Salary_Conversions; package Adjustments_Conversions is new COBOL.Decimal_Conversions(Adjustments_Type); use Adjustments_Conversions; begin Open(COBOL_File, Name => "Some_File"); loop Read(COBOL_File, COBOL_Record); Ada_Record.Name := To_Ada(COBOL_Record.Name); Ada_Record.SSN := To_Ada(COBOL_Record.SSN); begin Ada_Record.Salary := To_Decimal(COBOL_Record.Salary, High_Order_First); exception when Conversion_Error => ... -- Report "Invalid Salary Data" end; begin Ada_Record.Adjust := To_Decimal(COBOL_Record.Adjust, Leading_Separate); exception when Conversion_Error => ... -- Report "Invalid Adjustment Data" end; ... -- Process Ada_Record end loop; exception when End_Error => ... end Test_External_Formats;</syntaxhighlight> == <span id="4">B.4 Fortran Interface Package</span> == Much mathematical software exists and continues to be written in Fortran and so there is a strong need for Ada programs to be able to interface to Fortran routines. Ada programs should be able to call Fortran subprograms, or Fortran library routines, passing parameters mapped the way Fortran would map them. Similarly, with increasing frequency, there will also be reasons for Fortran programs to call Ada subprograms as if they were written in Fortran (that is, with parameters passed in the normal way for Fortran). The Numerics Annex recommends that the facilities for interfacing to Fortran described in the annex on Interface to Other Languages be implemented if Fortran is widely supported in the target environment. Some high-performance mathematical software is also written in C, so a similar recommendation is made with regard to the facilities for interfacing to C. We discuss only the Fortran interfacing facilities here. Interfacing to Fortran is provided by the child package Interfaces.Fortran and the convention identifier Fortran in the interfacing pragmas. The package Interfaces.Fortran defines types having the same names as the Fortran intrinsic types (except where they would conflict with the names of Ada types predefined in Standard, in which case they are given different names) and whose representations match the default representations of those types in the target Fortran implementation. Multiple Fortran interface packages may be provided if several different implementations of Fortran are to be accommodated in the target environment; each would have an identifier denoting the corresponding implementation of Fortran. The same identifier would be used to denote that implementation in the interfacing pragmas. Additional types may be added to a Fortran interface package as appropriate. For example, the package for an implementation of Fortran 77 might add declarations for Integer_Star_2, Integer_Star_4, Logical_Star_1, Logical_Star_4, and so on, while one for an implementation of Fortran 90 might add declarations for Integer_Kind_0, Integer_Kind_1, Real_Kind_0, Real_Kind_1, and so forth. Use of the types defined in a Fortran interface package suffices when the application only requires scalar objects to be passed between Ada and Fortran subprograms. The Convention pragma can be used to indicate that a multidimensional array is to be mapped in Fortran's column-major order, or that a record object declared in a library subprogram or package is to be mapped the way Fortran would map a common block (the Import or Export pragma would also be specified for the object), or that a record type is to be mapped the way Fortran 90 would map a corresponding type (called a "derived type" in Fortran 90). Compatibility with Fortran 90's pointer types is provided by applying the Convention pragma to appropriate access types. == <span id="5">B.5 Requirements Summary</span> == The requirement * R4.1-B(2) - Pragma Interface is met by the introduction of the pragmas Convention, Import and Export for the better control of interfaces to programs in other languages. The study topic * S10.1-A(2) - Specification of Decimal Representation is met in part by the generic package Interfaces.COBOL.Decimal_Conversions. The study topic * S10.2-A(1) - Alternate Character Set Support is satisfied in part by the facilities provided in Interfaces.COBOL.Decimal_Conversions. The study topic * S10.3-A(1) - Interfacing with Data Base Systems is satisfied in part by the types and conversions in the package Interfaces.COBOL. The study topic * S11.2-A(1) - Array Representation is met by the pragma Convention with a Fortran convention identifier, and more generally by the package Interfaces.Fortran. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p3-a|Previous]] | [[Guide:9x_rationale/rat95-p3-c|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=Annex B. Interface to Other Languages}} s2dr81xr4vvfd2fqm5ynlbbiclecyvi Guide:9x rationale/rat95-p3-c 4200 347 1867 1830 2019-04-20T16:20:35Z WikiVisor 11 Text replacement - "[[Guide:9x_rationale/rat95-copyright|Copyright]] | " to "<div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | " wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p3-b|Previous]] | [[Guide:9x_rationale/rat95-p3-d|Next]]</div> The Systems Programming Annex specifies additional capabilities for low- level programming. These capabilities are also required in many real- time, embedded, distributed, and information systems. The purpose of the Annex is to provide facilities for applications that are required to interface and interact with the outside world (i.e. outside the domain of an Ada program). Examples may be other languages, an operating system, the underlying hardware, devices and I/O channels. Since these kinds of interfaces lie outside the Ada semantic model, it is necessary to resort to low-level, environment specific programming paradigms. Such sections of the application are often implementation dependent and portability concerns are less critical. However, rigid isolation of these components helps in improving the portability of the rest of the application. The application domains of such systems include: real-time embedded computers, I/O drivers, operating systems and run-time systems, multilingual/multicomponent systems, performance-sensitive hardware dependent applications, resource managers, user-defined schedulers, and so on. Accordingly, this annex covers the following facilities needed by such applications: * Access to the underlying hardware (machine instructions, hardware devices, etc.); * Access to the underlying operating or runtime system; * Low-level, direct interrupt handling; * Unchecked access to parts of the run-time model of the implementation; * Specifying the representation and allocation of program data structures; * Access to shared variables in a multitasking program; * Access to the identity of tasks and the allocation of data on a per- task basis. Note that implementation of this annex is a prerequisite for the implementation of the Real-Time Systems annex. == <span id="1">C.1 Access to Machine Operations</span> == In systems programming and embedded applications, we need to write software that interfaces directly to hardware devices. This might be impossible if the Ada language implementation did not permit access to the full instruction set of the underlying machine. A need to access specific machine instructions arises sometimes from other considerations as well. Examples include instructions that perform compound operations atomically on shared memory, such as test-and-set and compare-and-swap, and instructions that provide high-level operations, such as translate- and-test and vector arithmetic. It can be argued that Ada 83 already provides adequate access to machine operations, via the package Machine_Code. However, in practice, the support for this feature was optional, and some implementations support it only in a form that is inadequate for the needs of systems programming and real-time applications. The mechanisms specified in this Annex for access to machine code are already allowed in Ada 83. The main difference is that now it is intended that the entire instruction set of a given machine should be accessible to an Ada program either via the Machine_Code package or via intrinsic subprograms (or indeed both). In addition, implementation- defined attributes ought to allow machine code to refer to the addresses or offsets of entities declared within the Ada program. This Annex leaves most of the interface to machine code implementation defined. It is not appropriate for a language standard to specify exactly how access to machine operations must be provided, since machine instructions are inherently dependent on the machine. We considered providing access to machine instructions only through interface to assembly language. This would not entirely satisfy the requirements, however, since it does not permit insertion of machine instructions in-line. Because the compiler cannot always perform register allocation across external subprogram calls, such calls generally require the saving and restoring of all registers. Thus, the overhead of assembly language subprogram calls is too high where the effect of a single instruction (e.g. test-and-set or direct I/O) is desired. For this, an in-line form of access is required. This requirement is satisfied by machine-code inserts or intrinsic subprograms. To be useful, a mechanism for access to machine code must permit the flow of data and control between machine operations and the rest of the Ada program. There is not much value in being able to generate a machine code instruction if there is no way to apply it to operands in the Ada program. For example, an implementation that only permits the insertion of machine code as numeric literal data would not satisfy this requirement, since there would be no way for machine code operations to read or write the values of variables of the Ada program, or to invoke Ada procedures. However, this can be entirely satisfied by a primitive form of machine-code insertion, which allows an instruction sequence to be specified as a sequence of data values, so long as symbolic references to Ada entities are allowed in such a data sequence. For convenience, it is desirable that certain instructions that are used frequently in systems programming, such as test-and-set and primitive I/O operations, be accessible as intrinsic subprograms, see [RM95 6.3.1]. However, it is not clear that it is practical for an implementation to provide access to all machine instructions in this form. Thus, it might be desirable to provide machine code inserts for generality, and intrinsic operations for convenient access to the more frequently needed operations. ==== The Pragma Export ==== The implementation advice concerning the pragma Export [RM95 B.1] addresses unintended interactions between compiler/linker optimizations and machine code inserts in Ada 83. A machine code insert might store an address, and later use it as a pointer or subprogram entry point - as with an interrupt handler. In general, the compiler cannot detect how the variable or subprogram address is used. When machine code is used in this way, it is the programmer's responsibility to inform the compiler about these usages, and it is the language's responsibility to specify a way for the programmer to convey this information. Without this information, the compiler or linker might perform optimizations so that the data object or subprogram code are deleted, or loads and stores referencing the object are suppressed. In Ada 95, machine code subprograms are like external subprograms written in another language, in that they may be opaque to optimization. That is, in general, the compiler cannot determine which data objects a machine code subprogram might read or update, or to where it might transfer control. The Export pragma tells the compiler not to perform optimizations on an exported object. By requiring the user to specify as exported anything that might be modified by an external call, the compiler is provided with information that allows better optimization in the general case. Export can also be used to ensure that the specified entity is allocated at an addressable location. For example, this might mean that a constant must actually be stored in memory, rather than only inserted in-line where used. ==== Interface to Assembly Language ==== An Ada implementation conforming to this Annex should also support interface to the traditional "systems programming language" for that target machine. This might be necessary to interface with existing code provided by the hardware vendor, such as an operating system, device drivers, or built-in-test software. We considered the possibility of requiring support for an assembler, but this has obvious problems. It is hard to state this requirement in a way that would not create enforcement problems. For example, what if there are several assemblers available for a given target, and new assemblers are developed from time to time? Which ones must an implementor support? Likewise, how hard does an implementor need to look before concluding there are no assemblers for a given target? However, we believe that stating the requirement simply as "should support interface to assembler" together with market forces will provide the appropriate direction for implementors in this area, even though compliance can not be fully defined. ==== Documentation Requirements ==== The intent of the documentation requirements is to ensure that the implementation provides enough information for the user to write machine code subprograms that interact with the rest of the Ada program. To do so effectively, the machine code subprograms ought to be able to read constants and read and update variables (including protected objects), to call subprograms, and to transfer control to labels. ==== Validation ==== The specifications for machine code are not likely to be enforceable by standard validation tests, but it should be possible to check for the existence of the required documentation and interfaces by examination of vendor supplied documentation, and to carry out spot checks with particular machine instructions. == <span id="2">C.2 Required Representation Support</span> == The recommended levels of support defined in [RM95 13] are made into firm requirements if this annex is implemented because systems programming applications need to control data representations, and need to be able to count on a certain minimum level of support. == <span id="3">C.3 Interrupt Support</span> == The ability to write handlers for interrupts is essential in systems programming and in real-time embedded applications. The model of interrupts and interrupt handling specified in Ada 95 is intended to capture the common elements of most hardware interrupt schemes, as well as the software interrupt models used by some application interfaces to operating systems, notably POSIX [1003.1 90]. The specification allows an implementation to handle an interrupt efficiently by arranging for the interrupt handler to be invoked directly by the hardware. This has been a major consideration in the design of the interrupt handling mechanisms. The reason for distinguishing treatments from handlers is that executing a handler is only one of the possible treatments. In particular, executing a handler constitutes delivery of the interrupt. The default treatment for an interrupt might be to keep the interrupt pending, or to discard it without delivery. These treatments cannot be modelled as a default handler. The notion of blocking an interrupt is an abstraction for various mechanisms that may be used to prevent delivery of an interrupt. These include operations that "mask" off a set of interrupts, raise the hardware priority of the processor, or "disable" the processor interrupt mechanism. On many hardware architectures it is not practical to allow a direct- execution interrupt handler to become blocked. Trying to support blocking of interrupt handlers results in extra overhead, and can also lead to deadlock or stack overflow. Therefore, interrupt handlers are not allowed to block. To enable programmers to avoid unintentional blocking in handlers, the language specifies which operations are potentially blocking, see [RM95 9.5.1]. We introduced the concept of reserved interrupts to reflect the need of the Ada run-time system to install handlers for certain interrupts, including interrupts used to implement time delays or various constraint checks. The possibility of simply making these interrupts invisible to the application was considered. This is not possible without restricting the implementation of the Interrupt_ID type. For example, if this type is an integer type and certain values within this range are reserved (as is the case with POSIX signals, for example), there is no way to prevent the application from attempting to attach a handler to one of the reserved interrupts; however, any such attempt will raise Program_Error. Besides, other (implementation-defined) uses for an interrupt-id type are anticipated for which the full range of values might be needed; if the standard interrupt-id type did not include all values, the implementation would have to declare an almost identical type for such purposes. We also need to reserve certain interrupts for task interrupt entries. There are many ways in which implementations can support interrupt entries. The higher-level mechanisms involve some degree of interaction with the Ada run-time system. It could be disastrous if the run-time system is relying on one of these high-level delivery mechanisms to be in place, and the user installs a low-level handler. For this reason, the concept of reserved interrupt is used here also, to prevent attachment of another handler to an interrupt while an interrupt entry is still attached to it. On some processor architectures, the priority of an interrupt is determined by the device sending the interrupt, independent of the identity of the interrupt. For this reason, we need to allow an interrupt to be generated at different priorities at different times. This can be modelled by hypothesizing several hardware tasks, at different priorities, which may all call the interrupt handler. A consequence of direct hardware invocation of interrupt handlers is that one cannot speak meaningfully of the "currently executing task" within an interrupt handler (see [RM95 C.7.1]). The alternative, of requiring the implementation to create the illusion of an Ada task as context for the execution of the handler would add execution time overhead to interrupt handling. Since interrupts may occur very frequently, and require fast response, any such unnecessary overhead is intolerable. For these and other reasons, care has been taken not to specify that interrupt handlers behave exactly as if they are called by a hardware "task". The language must not preclude the writing of efficient interrupt handlers, just because the hardware does not provide a reasonable way to preserve the illusion of the handler being called by a task. The Annex leaves as implementation-defined the semantics of interrupts when more than one interrupt subsystem exists on a multi-processor target. This kind of configuration may dictate that different interrupts are delivered only to particular processors, and will require that additional rules be placed on the way handlers are attached. In essence, such a system cannot be treated completely as a homogeneous multi- processor. The means for identifying interrupt sources, and the specification of the circumstances when interrupts are blocked are therefore left open by the Annex. It is expected that these additional rules will be defined as a logical extension of the existing ones. From within the program the form of an interrupt handler is a protected procedure. Typically we write <syntaxhighlight lang="Ada"> protected Alarm is procedure Response; pragma Attach_Handler(Response, Alarm_Int); end Alarm; protected body Alarm is procedure Response is begin ... -- the interrupt handling code end Response; end Alarm;</syntaxhighlight> where Alarm_Int identifies the physical interrupt as discussed in C.3.2. Protected procedures have appropriate semantics for fast interrupt handlers; they are directly invoked by the hardware and share data with tasks and other interrupt handlers. Thus, once the interrupt handler begins to execute it cannot block; on the other hand while any shared data is being accessed by other threads of control, an interrupt must be blocked. For upward compatibility, the Ada 83 interrupt entry mechanism is retained although classified as obsolescent. It has been extended slightly, as a result of the integration with the protected procedure interrupt-handling model. In addition, this Annex does not preclude implementations from defining other forms of interrupt handlers such as protected procedures with parameters. The recommendation is that such extensions will follow the model defined by this Annex. ==== Exceptions and Interrupt Handlers ==== Propagating an exception from an interrupt handler is specified to have no effect. (If interrupt handlers were truly viewed as being "called" by imaginary tasks, the propagation of an exception back to the "caller" of an interrupt handler certainly should not affect any user-defined task.) The real question seems to be whether the implementation is required to hide the effect of an interrupt from the user, or whether it can be allowed to cause a system crash. If the implementation uses the underlying interrupt mechanism directly, i.e. by putting the address of a handler procedure into an interrupt vector location, the execution context of the handler will be just the stack frame that is generated by the hardware interrupt mechanism. If an exception is raised and not handled within the interrupt handler, the exception propagation mechanism will try to unroll the stack, beyond the handler. There needs to be some indication on the stack that it should stop at the interrupt frame, and not try to propagate beyond. Lacking this, either the exception might just be propagated back to the interrupted task (if the hardware interrupt frame structure looks enough like a normal call), or the difference in frame structures will cause a failure. The failure might be detected in the run-time system, might cause the run-time system to crash, or might result in transfer of control to an incorrect handler, thereby causing the application to run amok. The desired behavior is for the exception mechanism to recognize the handler frame as a special case, and to simply do an interrupt return. Unless the hardware happens to provide enough information in the handler frame to allow recognition, it seems an extra layer of software will be needed, i.e. a software wrapper for the user interrupt handler. (This wrapper might be provided by the compiler, or by the run-time system.) Thus, the requirement that propagating an exception from a handler be "safe" is likely to impose some extra run-time overhead on interrupt handlers but is justified by the additional safety it provides. It is not expected that exceptions will be raised intentionally in interrupt handlers, but when an unexpected error (a bug) causes an exception to be raised, it is much better to contain the effect of this error than to allow the propagation to affect arbitrary code (including the RTS itself). ==== Implementation Requirements ==== It is not safe to write interrupt handlers without some means of reserving sufficient stack space for them to execute. Implementations will differ in whether such handlers borrow stack space from the task they interrupt, or whether they execute on a separate stack. In either case, with dynamic attachment of interrupt handlers, the application needs to inform the implementation of its maximum interrupt stack depth requirement. This could be done via a pragma or a link-time command. ==== Documentation Requirements ==== Where hardware permits an interrupt to be handled but not to be blocked (while in the handler), it might not be possible for an implementation to support the protected object locking semantics for such an interrupt. The documentation must describe any variations from the model. For example, in many implementations, it may not be possible for an interrupted task to resume execution until the interrupt handler returns. The intention here is to allow the implementation to choose whether to run the handler on a separate stack or not. The basic issue is whether the hardware (or underlying operating system) interrupt mechanism switches stacks, or whether the handler begins execution on the stack of the interrupted task. Adding software to the handler to do stack switching (in both directions) can add significantly to the run-time overhead, and this may be unacceptable for high frequency interrupts. Situations in which this would make a difference are rather unusual. Since the handler can interrupt, the task that it interrupts must have a lower active priority at that time. Therefore, the only situations where the interrupted task would need to resume execution before the handler returns are: * If there is more than one processor, and the interrupted task could migrate to another available processor; * If the handler or some higher priority task causes the priority of the interrupted task to be raised (via a call to Set_Priority); or * If priorities are not supported. The semantic model, when the interrupt handler uses the stack of the interrupted task, is that the handler has taken a non-preemptable processing resource (the upper part of the stack) which the interrupted task needs in order to resume execution. Note that this stack space was not in use by the interrupted task at the time it was preempted, since the stack did not yet extend that far, but it is needed by the interrupted task before it can resume execution. === <span id="3-1">C.3.1 Protected Procedure Handlers</span> === A handler can be statically attached to an interrupt by the use of the pragma Attach_Handler as in the example above. Alternatively the connection can be made dynamic by using the pragma Interrupt_Handler together with the procedure Attach_Handler. The example might then become <syntaxhighlight lang="Ada"> protected Alarm is procedure Response; pragma Interrupt_Handler(Response); end Alarm; protected body Alarm is procedure Response is begin ... -- the interrupt handling code end Response; end Alarm; ... Attach_Handler(Alarm.Response, Alarm_Int);</syntaxhighlight> Note therefore that the name Attach_Handler is used for both the pragma and for the procedure. The procedure form is needed to satisfy the requirement for dynamic attachment. The pragma form is provided to permit attachment earlier, during initialization of objects, or possibly at program load time. Another advantage of the pragma form is that it permits association of a handler attachment with a lexical scope, ensuring that it is detached on scope exit. Note that while the protected type is required to be a library level declaration, the protected object itself may be declared in a deeper level. Under certain conditions, implementations can preelaborate protected objects, see [RM95 10.2.1] and [RM95 C.4]. For such implementations, the Attach_Handler pragma provides a way to establish interrupt handlers truly statically, at program load time. The Attach_Handler and Interrupt_Handler pragmas specify a protected procedure as one that is or may be used as an interrupt handler and (in the latter case) be attached dynamically. This has three purposes: * It informs the compiler that it might need to generate code for a protected procedure that can be invoked directly by the hardware interrupt mechanism, and to generate appropriate calls to procedures contained in such an object if they are called from software. * It allows the implementation to allocate enough space for the corresponding protected object to store the interrupt-id to which the handler is attached. (This might be needed on some implementations in order to mask that interrupt when operations on the protected object are called from software.) * It serves as important documentation about the protected object. In general, the hardware mechanism might require different code generation than for procedures called from software. For example, a different return instruction might be used. Also, the hardware mechanism may implicitly block and unblock interrupts, whereas a software call may require this to be done explicitly. For a procedure that can be called from hardware or software, the compiler generally must choose between: * Compiling the procedure in the form for hardware invocation and adding some sort of glue-code when it is called via software; * Compiling the procedure in the form for software invocation, and call it indirectly, from an extra layer of interrupt handler, when a hardware interrupt occurs. Because code generation is involved, the pragma is associated with the protected type declaration, rather than with a particular protected object. The restrictions on protected procedures should be sufficient to eliminate the need for an implementation to place any further restrictions on the form or content of an interrupt handler. Ordinarily, there should be no need for implementation-defined restrictions on protected procedure interrupt handlers, such as those imposed by Ada 83 on tasks with fast interrupt handler entries. However, such restrictions are permitted, in case they turn out to be needed by implementations. This Annex requires only that an implementation support parameterless procedures as handlers. In fact, some hardware interrupts do provide information about the cause of the interrupt and the state of the processor at the time of the interrupt. Such information is also provided by operating systems that support software interrupts. The specifics of such interrupt parameters are necessarily dependent on the execution environment, and so are not suitable for standardization. Where appropriate, implementation-defined child packages of Ada.Interrupts should provide services for such interrupt handlers, analogous to those defined for parameterless protected procedures in the package Ada.Interrupts itself. Note that only procedures of library-level protected objects are allowed as dynamic handlers. This is because the execution context of such procedures persists for the full lifetime of the partition. If local procedures were allowed to be handlers, some extra prologue code would need to be added to the procedure, to set up the correct execution environment. To avoid problems with dangling references, the attachment would need to be broken on scope exit. This does not seem practical for the handlers that might be attached and detached via a procedure interface. On the other hand, it could be practical for handlers that are attached via a pragma. Some implementations may choose to allow local procedures to be used as handlers with the Attach_Handler pragma. For some environments, it may be appropriate to also allow ordinary subprograms to serve as interrupt handlers; an implementation may support this, but the mechanism is not specified. Protected procedures are the preferred mechanism because of the better semantic fit in the general case. However, there are some situations where the fit might not be so good. In particular, if the handler does not access shared data in a manner that requires the interrupt to be blocked, or if the hardware does not support blocking of the interrupt, the protected object model may not be appropriate. Also, if the handler procedure needs to be written in another language, it may not be practical to use a protected procedure. ==== Issues Related to Ceiling Priorities ==== With priority-ceiling locking, it is important to specify the active priority of the task that "calls" the handler, since it determines the ability of the interrupt to preempt whatever is executing at the time. It is also relevant to the user, since the user must specify the ceiling priority of the handler object to be at least this high, or else the program will be erroneous (might crash). Normally, a task has its active priority raised when it calls a protected operation with a higher ceiling than the task's own active priority. The intent is that execution of protected procedures as interrupt handlers be consistent with this model. The ability of the interrupt handler "call" from the hardware to preempt an executing task is determined by the hardware interrupt priority. In this respect, the effect is similar to a call from a task whose active priority is at the level of the hardware interrupt priority. Once the handler begins to execute, its active priority is set to the ceiling priority of the protected object. For example, if a protected procedure of an object whose ceiling priority is 5 is attached as a handler to an interrupt of priority 3, and the interrupt occurs when a task of priority 4 runs, the interrupt will remain pending until there is no task executing with active priority higher than or equal to 3. At that point, the interrupt will be serviced. Once the handler starts executing, it will raise its active priority to 5. It is impractical to specify that the hardware must perform a run-time check before calling an interrupt handler, in order to verify that the ceiling priority of the protected object is not lower than that of the hardware interrupt. This means that checks must either be done at compile-time, at the time the handler is attached, or by the handler itself. The potential for compile-time checking is limited, since dynamic attachment of handlers is allowed and the priority can itself be dynamic; all that can be done is to verify that the handler ceiling is specified via the Interrupt_Priority pragma thus <syntaxhighlight lang="Ada"> protected Alarm is pragma Interrupt_Priority(N); procedure Response; pragma Interrupt_Handler(Response); end Alarm;</syntaxhighlight> Doing the check when the handler is attached is also limited on some systems. For example, with some architectures, different occurrences of the same interrupt may be delivered at different hardware priorities. In this case, the maximum priority at which an interrupt might be delivered is determined by the peripheral hardware rather than the processor architecture. An implementation that chooses to provide attach-time ceiling checks for such an architecture could either assume the worst (i.e. that all interrupts can be delivered at the maximum priority) or make the maximum priority at which each interrupt can be delivered a configuration parameter. A last-resort method of checking for ceiling violations is for the handler to start by comparing its own ceiling against the active priority of the task it interrupted. Presumably, if a ceiling violation were detected, the interrupt could be ignored or the entire program could be aborted. Providing the run-time check means inserting a layer of "wrapper" code around the user-provided handler, to perform the check. Executing this code will add to the execution time of the handler, for every execution. This could be significant if the interrupt occurs with high frequency. Because of the difficulty of guaranteeing against ceiling violations by handlers on all architectures, and the potential loss of efficiency, an implementation is not required to detect situations where the hardware interrupt mechanism violates a protected object ceiling. Incorrect ceiling specification for an interrupt handler is "erroneous" programming, rather than a bounded error, since it might be impractical to prevent this from crashing the Ada RTS without actually performing the ceiling check. For example, the handler might interrupt a protected action while an entry queue is being modified. The epilogue code of the handler could then try to use the entry queue. It is hard to predict how bad this could be, or whether this is the worst thing that could happen. At best, the effect might be limited to loss of entry calls and corresponding indefinite blocking of the calling tasks. Since the priorities of the interrupt sources are usually known a priori and are an important design parameter, it seems that they are not likely to vary a lot and create problems after the initial debugging of the system. Simple coding conventions can also help in preventing such cases. ==== Non-Suspending Locks ==== With interrupt handlers, it is important to implement protected object locking without suspension. Two basic techniques can be applied. One of these provides mutual exclusion between tasks executing on a single processor. The other provides mutual exclusion between tasks executing on different processors, with shared memory. The minimal requirement for locking in shared memory is to use some form of spin-wait on a word representing the protected object lock. Other, more elaborate schemes are allowed (such as priority-based algorithms, or algorithms that minimize bus contention). Within a single processor, a non-suspending implementation of protected object locking can be provided by limiting preemption. The basic prerequisite is that while a protected object is locked, other tasks that might lock that protected object are not allowed to preempt. This imposes a constraint on the dispatching policy, which can be modelled abstractly in terms of locking sets. The locking set of a protected object is the set of tasks and protected operations that might execute protected operations on that object, directly or indirectly. More precisely, the locking set of a protected object R includes: * Tasks that call protected operations of R directly. * Protected procedures and entries whose bodies call a protected operation of R. * The locking set of Q, if Q is a protected object with a procedure or entry whose body contains a call to an operation (including a requeue) in the locking set of R. While a protected object is held locked by a task or interrupt handler, the implementation must prevent the other tasks and interrupt handlers in the locking set from executing on the same processor. This can be enforced conservatively, by preventing a larger set of tasks and interrupt handlers from executing. At one extreme, it may be enforced by blocking all interrupts, and disabling the dispatching of any other task. The priority-ceiling locking scheme described in [RM95 D.3] approximates the locking set a little less conservatively, by locking out all tasks and interrupt handlers with lower or equal priority to the one that is holding the protected object lock. The above technique (for a single processor) can be combined with the spin-wait approach on a multiprocessor. The spinning task raises its priority to the ceiling or mask interrupts before it tries to grab the lock, so that it will not be preempted after grabbing the lock (while still being in the "wrong" priority). ==== Metrics ==== The interrupt handler overhead metric is provided so that a programmer can determine whether a given implementation can be used for a particular application. There is clearly imprecision in the definition of such a metric. The measurements involved require the use of a hardware test instrument, such as a logic analyzer; the inclusion of instructions to trigger such a device might alter the execution times slightly. The validity of the test depends on the choice of reference code sequence and handler procedure. It also relies on the fact that a compiler will not attempt in-line optimization of normal procedure calls to a protected procedure that is attached as an interrupt handler. However, there is no requirement for the measurement to be absolutely precise. The user can always obtain more precise information by carrying out specific testing. The purpose of the metric here is to allow the user to determine whether the implementation is close enough to the requirements of the application to be worth considering. For this purpose, the accuracy of a metric could be off by a factor of two and still be useful. === <span id="3-2">C.3.2 The Package Interrupts</span> === The operations defined in the package Ada.Interrupts are intended to be a minimum set needed to associate handlers with interrupts. The type Interrupt_ID is implementation defined to allow the most natural choice of the type for the underlying computer architecture. It is not required to be private, so that if the architecture permits it to be an integer, a non-portable application may take advantage of this information to construct arrays and loops indexed by Interrupt_ID. It is, however, required to be a discrete type so that values of the type Interrupt_ID can be used as discriminants of task and protected types. This capability is considered necessary to allow a single protected or task type to be used as handler for several interrupts thus <syntaxhighlight lang="Ada"> Device_Priority: constant array (1 .. 5) of Interrupt_Priority := ( ... ); protected type Device_Interface(Int_ID: Interrupt_ID) is procedure Handler; pragma Attach_Handler(Handler, Int_ID); ... pragma Interrupt_Priority(Device_Priority(Int_ID)); end Device_Interface; ... Device_1_Driver: Device_Interface(1); ... Device_5_Driver: Device_Interface(5); ...</syntaxhighlight> Some interrupts may originate from more than one device, so an interrupt handler may need to perform additional tests to decide which device the interrupt came from. For example, there might be several timers that all generate the same interrupt (and one of these timers might be used by the Ada run-time system to implement delays). In such a case, the implementation may define multiple logical interrupt-id's for each such physical interrupt. The atomic operation Exchange_Handler is provided to attach a handler to an interrupt and return the previous handler of that interrupt. In principle, this functionality might also be obtained by the user through a protected procedure that locks out interrupts and then calls Current_Handler and Attach_Handler. However, support for priority- ceiling locking of protected objects is not required. Moreover, an exchange-handler operation is already provided in atomic form by some operating systems (e.g. POSIX). In these cases, attempting to achieve the same effect via the use of a protected procedure would be inefficient, if feasible at all. The value returned by Current_Handler and Exchange_Handler in the case that the default interrupt treatment is in force is left implementation- defined. It is guaranteed however that using this value for Attach_Handler and Exchange_Handler will restore the default treatment. The possibility of simply requiring the value to be null in this case was considered but was believed to be an over-specification and to introduce an additional overhead for checking this special value on each operation. Operations for blocking and unblocking interrupts are intentionally not provided. One reason is that the priority model provides a way to lock out interrupts, using either the ceiling-priority of a protected object or the Set_Priority operation (see [RM95 D.5]). Providing any other mechanism here would raise problems of interactions and conflicts with the priority model. Another reason is that the capabilities for blocking interrupts differ enough from one machine to another that any more specific control over interrupts would not be applicable to all machines. In Ada 83, interrupt entries are attached to interrupts using values of the type System.Address. In Ada 95, protected procedures are attached as handlers using values of Interrupt_ID. Changing the rules for interrupt entries was not considered feasible as it would introduce upward-incompatibilities, and would require support of the Interrupts package by all implementations. To resolve the problem of two different ways to map interrupts to Ada types, the Reference function is provided. This function is intended to provide a portable way to convert a value of the type Interrupt_ID to a value of type System.Address that can be used in a representation clause to attach an interrupt entry to an interrupt source. ; The Interrupts.Names Package : The names of interrupts are segregated into the child package Interrupts.Names, because these names will be implementation-defined. In this way, a use clause for package Interrupts will not hide any user- defined names. === <span id="3-3">C.3.3 Task Entries as Handlers</span> === Attaching task entries to interrupts is specified as an obsolescent feature (see [RM95 J.7.1]). This is because support of this feature in Ada 83 was never required and important semantic details were not given. Requiring every implementation to support attaching both protected procedures and task entries to interrupts was considered to be an unnecessarily heavy burden. Also, with entries the implementation must choose between supporting the full semantics of rendezvous for interrupts (with more implementation overhead than protected procedures) versus imposing restrictions on the form of handler tasks (which will be implementation-dependent and subtle). The possibility of imposing standard restrictions, such as those on protected types, was considered. It was rejected on the grounds that it would not be upward compatible with existing implementations of interrupt entries (which are diverse in this respect). Therefore, if only one form of handler is to be supported, it should be protected procedures. As compared to Ada 83, the specifications for interrupt entries are changed slightly. First, the implementation is explicitly permitted to impose restrictions on the form of the interrupt handler task, and on calls to the interrupt entry from software tasks. This affirms the existing practice of language implementations which support high- performance direct-execution interrupt entries. Second, the dynamic attachment of different handlers to the same interrupt, sequentially, is explicitly allowed. That is, when an interrupt handler task terminates and is finalized, the attachment of the interrupt entry to the interrupt is broken. The interrupt again becomes eligible for attachment. This is consistent with the dynamic attachment model for protected procedures as interrupt handlers, and is also consistent with a liberal reading of the Ada 83 standard. Finally, in anticipation of Ada 95 applications that use protected procedures as handlers together with existing Ada 83 code that uses interrupt entries, interrupts that are attached to entries, are specified as reserved, and so effectively removed from the set of interrupts available for attachment to protected procedures. This separation can therefore eliminate accidental conflicts in the use of values of the Interrupt_ID type. == <span id="4">C.4 Preelaboration Requirements</span> == The primary systems programming and real-time systems requirement addressed by preelaboration is the fast starting (and possibly restarting) of programs. Preelaboration also provides a way to possibly reduce the run-time memory requirement of programs, by removing some of the elaboration code. This section is in the Systems Programming Annex (rather than the Real-Time Annex) because the functionality is not limited to real-time applications. It is also required to support distribution. ==== Rejected Approaches ==== There is a spectrum of techniques that can be used to reduce or eliminate elaboration code. One possible technique is to run the entire program up to a certain point, then take a snap-shot of the memory image, which is copied out and transformed into a file that can be reloaded. Program start-up would then consist of loading this check-point file and resuming execution. This "core-dump" approach is suitable for some applications and it does not require special support from the language. However, it is not really what has been known as preelaboration, nor does it address all the associated requirements. The core-dump approach to accelerating program start-up suffers from several defects. It is error-prone and awkward to use or maintain. It requires the entire active writable memory of the application to be dumped. This can take a large amount of storage, and a proportionately long load time. It is also troublesome to apply this technique to constant tables that are to be mapped to read-only memory; if the compiler generates elaboration code to initialize such tables, writable memory must be provided in the development target during the elaboration, and replaced by read-only memory after the core-dump has been produced; the core-dump must then be edited to separate out the portions that need to be programmed into read-only memory from those that are loaded in the normal way. This technique presumes the existence of an external reload device, which might not be available on smaller real-time embedded systems. Finally, effective use of this method requires very precise control over elaboration order to ensure that the desired packages, and only those packages, are elaborated prior to the core-dump. Since this order often includes implementation packages, it is not clear that the user can fully control this order. ==== The Chosen Approach ==== Preelaboration is controlled by the two pragmas Pure and Preelaborate as mentioned in 10.3. Many predefined packages are Pure such as <syntaxhighlight lang="Ada"> package Ada.Characters is pragma Pure(Characters); end Ada.Characters;</syntaxhighlight> The introduction of pure packages together with shared passive and remote call interface packages (see [RM95 E.2]) for distribution, created the need to talk about packages whose elaboration happens "before any other elaboration". To accommodate this, the concept of a preelaborable construct is introduced in [RM95 10.2.1]. (Preelaborability is naturally the property of an entity which allows it to be preelaborated.) Pure packages are always preelaborated, as well as packages to which the pragma Preelaborate specifically applies such as <syntaxhighlight lang="Ada"> package Ada.Characters.Handling is pragma Preelaborate(Handling); ...</syntaxhighlight> The difference between pure packages and any other preelaborated package is that the latter may have "state". In the core, being preelaborated does not necessarily mean "no code is generated for preelaboration", it only means that these library units are preelaborated before any other unit. The Systems Programming Annex defines additional implementation and documentation requirements to ensure that the elaboration of preelaborated packages does not execute any code at all. ==== Issues Related to Preelaboration ==== Given this approach, some trade-offs had to be made between the generality of constructs to which this requirement applies, the degree of reduction in run-time elaboration code, the complexity of the compiler, and the degree to which the concerns of the run-time system can be separated from those of the compiler. Bodies of subprograms that are declared in preelaborated packages are guaranteed to be elaborated before they can be called. Therefore, implementations are required to suppress the elaboration checks for such subprograms. This eliminates a source of a distributed overhead that has been an issue in Ada 83. Tasks, as well as allocators for other than access-to-constant types, are not included among the things specified as preelaborable, because the initialization of run-time system data structures for tasks and the dynamic allocation of storage for general access types would ordinarily require code to be executed at run time. While it might be technically possible to preelaborate tasks and general allocators under sufficiently restrictive conditions, this is considered too difficult to be required of every implementation and would make the compiler very dependent on details of the run-time system. The latter is generally considered to be undesirable by real-time systems developers, who often express the need to customize the Ada run-time environment. It is also considered undesirable by compiler vendors, since it aggravates their configuration management and maintenance problem. (Partial preelaboration of tasks might be more practical for the simple tasking model, described in [RM95 D.7].) Entryless protected objects are preelaborable and are essential for shared passive packages. They are therefore allowed in preelaborated packages. The initialization of run time data structures might require run-time system calls in some implementations. In particular, where protected object locking is implemented using primitives of an operating system, it might be necessary to perform a system call to create and initialize a lock for the protected object. On such systems, the system call for lock initialization could be postponed until the first operation that is performed on the protected object, but this means some overhead on every protected object operation (perhaps a load, compare, and conditional jump, or an indirect call from a dispatching table). It seems that this kind of distributed overhead on operations that are intended to be very efficient is too high a price to pay for requiring preelaboration of protected objects. These implementations can conform to the requirements in this Annex by doing all initializations "behind- the-scene" before the program actually starts. On most other systems, it is expected that protected objects will be allocated and initialized statically and thus be elaborated when the program starts. Thus, the difference between these two cases is not semantic, and can be left to metrics and documentation requirements. == <span id="5">C.5 Shared Variable Control</span> == Objects in shared memory may be used to communicate data between Ada tasks, between an Ada program and concurrent non-Ada software processes, or between an Ada program and hardware devices. Ada 83 provided a limited facility for supporting variables shared between otherwise unsynchronized tasks. The pragma Shared indicated that a particular elementary object is being concurrently manipulated by two or more tasks, and that all loads and stores should be indivisible. The pragma Shared was quite weak. The semantics were only defined in terms of tasks, and not very clearly. This made it inadequate for communication with non-Ada software or hardware devices. Moreover, it could be applied only to a limited set of objects. For example, it could not be applied to a component of an array. One of the most common requirements for shared data access is for buffers, which are typically implemented as arrays. For these reasons, the pragma Shared was removed from the language and replaced by the pragmas Atomic and Volatile. This Annex thus generalizes the capability to allow data sharing between non-Ada programs and hardware devices, and the sharing of composite objects. In fact, two levels of sharability are introduced: * atomic This indicates that all loads and stores of the object should be indivisible, and that no local copies of the object may be retained. It need only be supported for types where the underlying hardware memory access allows indivisible load and store operations. This imposes requirements on both the size and the alignment of the object. * volatile This indicates that the object can be updated asynchronously. However, there is no need for indivisible load and store. So we can write <syntaxhighlight lang="Ada"> type Data is new Long_Float; pragma Atomic(Data); -- applying to a type ... I: Integer; pragma Volatile(I); -- applying to a single object</syntaxhighlight> Atomic types and objects are implicitly volatile as well. This is because it would make little sense to have an operation applied to an atomic object while allowing the object itself not to be flushed to memory immediately afterwards. Since the atomicity of an object might affect its layout, it is illegal to explicitly specify other aspects of the object layout in a conflicting manner. These pragmas may be applied to a constant, but only if the constant is imported. In Ada, the constant designation does not necessarily mean that the object's value cannot change, but rather that it is read-only. Therefore, it seems useful to allow an object to be read-only, while its value changes from the "outside". The rules about volatile objects ensure that the Ada code will read a fresh value each time. The run-time semantics of atomic/volatile objects are defined in terms of external effects since this is the only way one can talk formally about objects being flushed to or refreshed from memory (as is required to support such objects). When using such pragmas, one would not want to have the effect of the pragma more general than is minimally needed (this avoids the unnecessary overhead of atomic or load/store operations). That is why separate forms of the pragmas exist for arrays. Writing <syntaxhighlight lang="Ada"> Buffer: array (1 .. Max) of Integer; pragma Atomic_Components(Buffer);</syntaxhighlight> indicates that the atomicity applies individually to each component of the array but not to the array Buffer as a whole. These pragmas must provide all the necessary information for the compiler to generate the appropriate code each time atomic or volatile objects are accessed. This is why the indication is usually on the type declaration rather than on the object declaration itself. For a stand- alone object there is no problem for the designation to be per-object, but for an array object whose components are atomic or volatile complications would arise. Specifying array components as atomic or volatile is likely to have implications on the layout of the array objects (e.g. components have to be on word boundaries). In addition, if the type of a formal parameter does not have volatile components and the actual parameter does, one would have to pass the parameter by copy, which is generally undesirable. Anonymous array types (as in the example above) do not present this problem since they cannot be passed as parameters directly; explicit conversion is always required, and it is not unreasonable to presume that a copy is involved in an explicit conversion. The rules for parameter passing distinguish among several cases according to the type; some must be passed by copy, some must be passed by reference and in some cases either is permitted. The last possibility presents a problem for atomic and volatile parameters. To solve this, the rules in this section make them by reference if the parameter (or a component) is atomic or volatile. Moreover, if the actual is atomic or volatile and the formal is not then the parameter is always passed by copy; this may require a local copy of the actual to be made at the site of the call. The following example shows the use of these pragmas on the components of a record for doing memory-mapped I/O <syntaxhighlight lang="Ada"> type IO_Rec_Type is record Start_Address: System.Address; pragma Volatile(Start_Address); Length: Integer; pragma Volatile(Length); Operation: Operation_Type; pragma Atomic(Operation); Reset: Boolean; pragma Atomic(Reset); end record; -- A store into the Operation field triggers an I/O operation. -- Reading the Reset field terminates the current operation. IO_Rec: IO_Rec_Type; for IO_Rec'Address use ... ;</syntaxhighlight> By using the pragmas to indicate the sharability of data, the semantics of reading and writing components can be controlled. By declaring Operation and Reset to be atomic, the user ensures that reads and writes of these fields are not removed by optimization, and are performed indivisibly. By declaring Start_Address and Length to be volatile, the user forces any store to happen immediately, without the use of local copies. ==== Other Alternatives ==== Another concept considered was a subtype modifier which would appear in a subtype indication, an object declaration, or parameter specification. However, for simplicity, pragmas were chosen instead. Other possibilities included an "independent" indication. This would mark the object as being used to communicate between synchronized tasks. Furthermore, the object should be allocated in storage so that loads and stores to it may be performed independently of neighboring objects. Since in Ada 83, all objects were implicitly assumed as independent, such a change would have created upward-compatibility problems. For this reason, and for the sake of simplicity, this feature was rejected. == <span id="6">C.6 Task Identification and Attributes</span> == In order to permit the user to define task scheduling algorithms and to write server tasks that accept requests in an order different from entry service order, it is necessary to introduce a type which identifies a general task (not just of a particular task type) plus some basic operations. This Task_ID type is used also by other language-defined packages to operate on task objects such as Dynamic_Priorities and Asynchronous_Task_Control. In addition, a common need is to be able to associate user-defined properties with all tasks on a per-task basis; this is done through task attributes. === <span id="6-1">C.6.1 The Package Task_Identification</span> === The Task_ID type allows the user to refer to task objects using a copyable type. This is often necessary when one wants to build tables of tasks with associated information. Using access-to-task types is not always suitable since there is no way to define an access-to-any-task type. Task types differ mostly in the entry declarations. The common use of task-id's does not require this entry information, since no rendezvous is performed using objects of Task_ID. Instead, the more generic information about the object as being a task is all that is needed. Several constructs are provided to create objects of the Task_ID type. These are the Current_Task function to query the task-id of the currently executing task; the Caller attribute for the task-id of entry callers; and the Identity attribute for the task-id of any task object. It is believed that together these mechanisms provide the necessary functionality for obtaining task-id values in various circumstances. In addition, the package provides various rudimentary operations on the Task_ID type. Thus using the example from 9.6, the user might write <syntaxhighlight lang="Ada"> Joes_ID: Task_ID := Joe'Identity; ... Set_Priority(Urgent, Joes_ID); -- see D.5 ... Abort_Task(Joes_ID); -- same as abort Joe;</syntaxhighlight> Another use might be for remembering a caller in one rendezvous and then recognizing the caller again in a later rendezvous, thus <syntaxhighlight lang="Ada"> task body Some_Service is Last_Caller: Task_ID; begin ... accept Hello do Last_Caller := Hello'Caller; ... end Hello; ... accept Goodbye do if Last_Caller /= Goodbye'Caller then raise Go_Away; -- propagate exception to caller end if; ... exception when Go_Away => null; end Goodbye; ... end Some_Service;</syntaxhighlight> Since objects of Task_ID no longer have the corresponding type and scope information, the possibility for dangling references exist (since Task_ID objects are nonlimited, the value of such an object might contain a task-id of a task that no longer exists). This is particularly so since a server is likely to be at a library level, while the managed tasks might be at a deeper level with a shorter life-time. Operating on such values (here and in other language-defined packages) is defined to be erroneous. Originally, the possibility of requiring scope checking on these values was considered. Such a requirement would impose certain execution overhead on operations and space overhead on the objects of such a type. Since this capability is mainly designed for low-level programming, such an overhead was considered unacceptable. (Note, however, that nothing prevents an implementation from implementing a Task_ID as a record object containing a generation number and thereby providing a higher degree of integrity.) The Task_ID type is defined as private to promote portability and to allow for flexibility of implementation (such as with a high degree of integrity). The possibility of having a visible (implementation-defined) type was considered. The main reason for this was to allow values of the type to be used as indices in user-defined arrays or as discriminants. To make this usable, the type would have to be discrete. However a discrete type would not allow for schemes that use generation numbers (some sort of a record structure would then be required as mentioned above). A visible type would also reduce portability. So, in the end, a private type approach was chosen. As always, implementations can provide a child package to add hashing functions on Task_ID values, if indexing seems to be an important capability. ==== Other Alternatives ==== In an earlier version of Ada 9X, the Task_ID type was defined as the root type of the task class. Since that class was limited, a language-defined access type was also defined to accommodate the need for a copyable type. This definition relied on the existence of untagged class types which were later removed from the language. The approach provided a nice encapsulation of the natural properties of such a type. The general rules of derivations and scope checking could then be fitted directly into the needs of the Task_ID type. Since the underlying model no longer exists, the simpler and more direct approach of a private type with specialized semantics and operation, was adopted. Another possibility that was considered was to define a special, language-defined, access-to-task type which, unlike other access types, would be required to hold enough information to ensure safe access to dereferenced task objects. This type could then be used as the task-id. Values of such a type would necessarily be larger. This was rejected on the grounds that supporting this special access type in the compiler would be more burdensome to implementations. ==== Obtaining the Task Identity ==== The Current_Task function is needed in order to obtain the identity of the currently executing task when the name of this task is not known from the context alone; for example when the identity of the environment task is needed or in general service routines that are used by many different tasks. There are two situations in which it is not meaningful to speak of the "currently executing task". One is within an interrupt handler, which may be invoked directly by the hardware. The other is within an entry body, which may be executed by one task on behalf of a call from another task (the Caller attribute may be used in the latter case, instead). For efficiency, the implementation is not required to preserve the illusion of there being an interrupt handler task, or of each execution of an entry body being done by the task that makes the call. Instead, calling Current_Task in these situations is defined to be a bounded error. The values that may be returned if the error is not detected are based on the assumption that the implementation ordinarily keeps track of the currently executing task, but might not take the time to update this information when an interrupt handler is invoked or a task executes an entry body on behalf of a call from another task. In this model, the value returned by Current_Task would identify the last value of "current task" recorded by the implementation. In the case of an interrupt handler, this might be the task that the interrupt handler preempted, or an implementation task that executes when the processor would otherwise be idle. If Current_Task could return a value that identifies an implementation task, it might be unsafe to allow a user to abort it or change its priority. However, the likelihood of this occurring is too small to justify checking, especially in an implementation that is sufficiently concerned with efficiency not to have caught the error in the first place. The documentation requirements provide a way for the user to find out whether this possibility exists. Conversion from an object of any task type to a Task_ID is provided by the Identity attribute. This conversion is always safe. Support for conversion in the opposite direction is intentionally omitted. Such a conversion is rarely useful since Task_ID is normally used when the specific type of the task object is not known, and would be extremely error-prone; (a value of one task type could then be used as another type with all the dangerous consequences of different entries and masters). Caller and Identity are defined as attributes and not as functions. For Caller, an attribute allows for an easier compile-time detection of an incorrect placement of the construct. For Identity, a function would require a formal parameter of a universal task type which does not exist. The Caller attribute is allowed to apply to enclosing accept bodies (not necessarily the innermost one) since it seems quite useful without introducing additional run-time overhead. ==== Documentation Requirements ==== In some implementations, the result of calling Current_Task from an interrupt handler might be meaningful. Non-portable applications may be able to make use of this information. === <span id="6-2">C.6.2 The Package Task_Attributes</span> === The ability to have data for which there is a copy for each task in the system is useful for providing various general services. This was provided for example in RTL/2 [Barnes 76] as SVC data. For Ada 95, several alternatives were considered for the association of user-defined information with each task in a program. The approach which was finally selected is to have a language-defined generic package whose formal type is the type of an attribute object. This mechanism allows for multiple attributes to be associated with a task using the associated Task_ID. These attributes may be dynamically defined, but they cannot be "destroyed". A new attribute is created through instantiation of the generic package. Thus if we wished to associate some integer token with every task in a program we could write <syntaxhighlight lang="Ada"> package Token is new Ada.Task_Attributes(Attribute => Integer, Initial_Value => 0);</syntaxhighlight> and then give the task Joe its particular token by <syntaxhighlight lang="Ada"> Token.Set_Value(99, Joes_ID);</syntaxhighlight> Note that the various operations refer to the current task by default, so that <syntaxhighlight lang="Ada"> Token.Set_Value(101);</syntaxhighlight> sets the token of the task currently executing the statement. After being defined, an object of that attribute exists for each current and newly created task and will be initialized with a user- provided value. Internally the hidden object will typically be derived from the type Finalization.Controlled so that finalization of the attribute objects can be performed. When a task terminates, all of its attribute objects are finalized. Note that the attribute objects themselves are allocated in the RTS space, and are not directly accessible by the user program. This avoids problems with dangling references. Since the object is not in user space, it cannot live longer than the task that has it as an attribute. Similarly, this object cannot be deallocated or finalized while the run-time system data structures still point to it. Obviously, other unrelated user objects might still contain references to attribute objects after they have gone (as part of task termination). This can only happen when one dereferences the access value returned by the Reference function since the other operations return (or store) a copy of the attribute. Such dereference (after the corresponding task has terminated) is therefore defined as erroneous. Note that one does not have to wait until a master is left for this situation to arise; referencing an attribute of a terminated task is equally problematic. In general, the Reference function is intended to be used "locally" by the task owning the attribute. When the actual attribute object is large, it is sometimes useful to avoid the frequent copying of its value; instead a pointer to the object is obtained and the data is read or written in the user code. When the Reference function is used for tasks other then the calling task, the safe practice should be to ensure, by other means, that the corresponding task is not yet terminated. The generic package Task_Attributes can be instantiated locally in a scope deeper than the library level. The effect of such an instantiation is to define a new attribute (for all tasks) for the lifetime of that scope. When the scope is left, the corresponding attribute no longer exists and cannot be referenced anymore. An implementation may therefore deallocate all such attribute objects when that scope is left. For the implementation of this feature, several options exist. The simplest approach is of a single pointer in the task control block (TCB) to a table containing pointers to the actual attributes, which in turn are allocated from a heap. This table can be preallocated with some initial size. When new attributes are added and the table space is exhausted, a larger one can be allocated with the contents of the old one being copied to the new one. The index of this table can serve as the attribute-id. Each instantiated attribute will have its own data structure (one per partition, not per task), which will contain some type information (for finalization) and the initial value. The attribute-id in the TCB can then point to this attribute type information. Instead of having this level of indirection, the pointer in the TCB can point to a linked list of attributes which then can be dynamically extended or shrunk. Several optimizations on this general scheme are possible. One can preallocate the initial table in the TCB itself, or store in it a fixed number of single-word attributes (presumably, a common case). Since implementations are allowed to place restrictions on the maximum number of attributes and their sizes, static allocation of attribute space is possible, when the application demands more deterministic behavior at run time. Finally, attributes that have not been set yet, or have been reinitialized, do not have to occupy space at all. A flag indicating this state is sufficient for the Value routine to retrieve the initial value from the attribute type area instead of requiring per-task replication of the same value. ==== Other Approaches ==== A number of other approaches were considered. One was the idea of a per- task data area. Library-level packages could have been characterized by a pragma as Per_Task, meaning that a fresh copy of the data area of such a package would be available for each newly created task. Several problems existed with this approach. These problems related to both the implementation and the usability aspects. A task could only access its own data, not the data of any other task. There were also serious problems concerning which packages actually constituted the per- task area. Another approach considered was a singe attribute per task. Operations to set and retrieve the attribute value of any task were included in addition to finalization rules for when the task terminates. This approach was quite attractive. It was simple to understand and could be implemented with minimal overhead. Larger data structures could be defined by the user and anchored at the single pointer attribute. Operations on these attributes were defined as atomic to avoid race conditions. But the biggest disadvantage of this approach, which eventually led to its rejection, was that such a mechanism does not compose very well and is thus difficult to use in the general case. == <span id="7">C.7 Requirements Summary</span> == The requirements * R6.3-A(1) - Interrupt Servicing * R6.3-A(2) - Interrupt Binding are met by the pragmas Interrupt_Handler and Attach_Handler plus the package Ada.Interrupts. The requirement * R7.1-A(1) - Control of Shared Memory is met by the pragmas Atomic and Volatile discussed in C.5. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p3-b|Previous]] | [[Guide:9x_rationale/rat95-p3-d|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=Annex C. Systems Programming}} b6v449p8ysk2w0hoq7pr4yvxy6j73z2 Guide:9x rationale/rat95-p3-d 4200 348 1871 1822 2019-04-20T16:20:40Z WikiVisor 11 Text replacement - "[[Guide:9x_rationale/rat95-copyright|Copyright]] | " to "<div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | " wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p3-c|Previous]] | [[Guide:9x_rationale/rat95-p3-e|Next]]</div> The purpose of this Annex is to supplement the core language with features specific to real-time systems. Since Ada is a general-purpose language with a large and diverse audience, not all the capabilities that are required to build applications can be sensibly put in the core language without prohibitively increasing its size and hurting other application domains. As is the case with Ada 95 in general, this Annex tries to provide a single solution to each recognized problem, even though we acknowledge that several alternatives exist in the market-place. The mechanisms that we have provided can serve as building blocks when more sophisticated solutions are needed. The models that we specify allow for extensions, and accommodate a certain degree of variability. The primary goal was to allow the user to rely on a portable, yet usable, set of capabilities. These capabilities will always be present in an implementation that supports this Annex. Therefore, the default behavior is well-specified, and the user must explicitly request implementation-provided additions. In addition, optionality within this Annex was kept to a minimum. This annex addresses the following topics * Priorities of tasks in general and especially the ability to change priorities (they were fixed in Ada 83) either explicitly or as a result of interaction with other tasks and protected objects; * Scheduling issues including the entry queue discipline; * Specific measurements on the effect of the abort statement including the formalization of the concept of an abort-deferred region; * Restrictions on the use of certain aspects of the tasking model that should permit the use of specialized runtime systems; * Resolution of a number of timing issues in Ada 83, including the introduction of a distinct monotonic clock; * The addition of explicit synchronous and asynchronous task control protocols. Note that several features in this Annex are invoked by using configuration pragmas (see [RM95 10.1.5]). This means that the corresponding semantics are defined on a per-partition basis; thus priority scheduling, the queuing policy and time are only specified in the scope of the one active partition containing the unit where the pragma applies. Ada 95 does not address issues concerning multipartition execution beyond the minimum that is in the Distributed Systems Annex. Interactions among partitions are left to implementations or to the providers of partition communication software. == <span id="1">D.1 Task Priorities</span> == In real-time applications, it is necessary to schedule the use of processing resources to meet timing constraints. One approach is to use priority scheduling; this has a well developed theory, and is adequate for a wide range of real-time applications; see [Sha 90a] and [Klein 93]. Ada 83 specified preemptive task scheduling based on static priorities, but left certain aspects implementation dependent. This scheduling model, however, has raised issues in practice. On the one hand, it is viewed as not sufficiently specified for portable real-time system designs. On the other hand, it is viewed as too restrictive to permit the implementation of important real-time programming paradigms. It is important that a language not limit the application to a particular scheduling model. There are many appropriate scheduling techniques, and more are continually being developed. No one scheduling model is accepted as adequate for all real-time applications. It is also important to permit Ada to take advantage of the concurrent programming support of commercial real-time operating systems or executives. This is especially so with the growing acceptance of the "open systems" approach to software architecture, and the development of standards for application program interfaces to operating system services, such as POSIX [1003.1 90]. Ada should not impose any requirements on the language implementation that conflict with the scheduling model of an underlying operating system. For these reasons, the Ada 83 priority scheduling model has been removed from the core of the language. However, this leaves a gap. Some users have found the Ada 83 scheduling model useful and it is clearly essential to continue to support those users. This argues for the inclusion of a priority scheduling model in this Annex, and for it to be compatible with Ada 83. A second reason for specifying a standard scheduling model in this Annex is economy. Even though a single scheduling model cannot satisfy the requirements of all Ada users, it seems that a large number can be satisfied with priority scheduling, provided that the obvious adjustments to Ada 83 are made. This model thus provides a useful base for vendors and users alike. The priority model specified in this Annex thus subsumes the Ada 83 model and provides several important improvements: support for dynamic priorities; solutions to the problem of priority inversion; and a unified model of the interactions of task priorities with protected objects and interrupts. The specification of the priority model is spread over several clauses in [RM95 D.1-5]. Besides readability, the main reason for this organization is to permit the designation of options within the Annex. In particular, while the overall task dispatching model is essential, the standard policies for Task Dispatching, Priority Ceiling Locking, and Entry Queuing may optionally be replaced by other implementation defined alternatives. === <span id="1-1">D.1.1 Priority Subtypes</span> === The range of possible task priorities is extended so that it can overlap with interrupt priorities as on some hardware architectures. We now have <syntaxhighlight lang="Ada"> subtype Any_Priority is Integer range implementation-defined; subtype Priority is Any_Priority range Any_Priority'First .. implementation-defined; subtype Interrupt_Priority is Any_Priority range Priority'Last+1 .. Any_Priority'Last;</syntaxhighlight> The subtype Any_Priority is introduced (rather than simply allowing Priority to include interrupt priorities) because existing Ada 83 programs may assume that Priority'Last is below interrupt priority. Moreover, since giving a task a priority that blocks interrupts is sufficiently dangerous that it should be very visible in the source code, the subtype Interrupt_Priority is introduced. The ranges of Priority and Interrupt_Priority do not overlap. A minimum number of levels of priority is specified, in the interest of promoting portability of applications and to ensure that an implementation of this Annex actually supports priority scheduling in a useful form. Research in Rate Monotonic scheduling [Lehoczky 86] has shown that approximately 32 levels of priority is the minimum needed to ensure adequate schedulability in systems with 32 or more tasks. Moreover, it is desirable that where hardware provides support for priority scheduling, it should be possible to use such support. Certain hardware architectures are reported to support only 32 levels of priority, including interrupt priority levels. Therefore the combined number of priority levels is not required to be higher than 32. In order to permit the use of efficient bit-vector operations on 32-bit machines, where one bit may need to be reserved, the actual requirement is reduced to 31 of which one must be an interrupt priority. As in Ada 83, priority subtypes need not be static, so an implementation that is layered over an operating system can query the underlying operating system at elaboration-time to find out how many priority levels are supported. === <span id="1-2">D.1.2 Base and Active Priorities</span> === The distinction between base and active priority is introduced in order to explain the effect of priority inheritance. The base priority of a task is the priority the task would have in the absence of priority inheritance of any sort. Priority inheritance is already present in Ada 83, during rendezvous. It is extended here, to bound priority inversion (see D.3.1 for the definition of priority inversion) during protected operations. In the default scheduling policy, priority inheritance is limited to a few simple forms, in order to permit more efficient implementations. These forms do not cause the active priority of a task to change asynchronously. Inheritance happens only as a direct result of the execution of the affected task, when the task is being resumed, or before the task has ever executed. If inheritance is via protected operations, the priority is raised at the start of the operation and lowered at the end. If inheritance is via rendezvous, the priority is raised at the beginning of rendezvous (either by the accepting task itself, or by the caller before the acceptor is resumed) and then lowered at the end of the rendezvous (by the acceptor). The case of activation is slightly different, since if the active priority of the task is raised, it is raised by the creator. However, this change is synchronous for the affected task, since the task has not yet started to execute; the lowering of the priority is done at the end of activation by the action of the activated task. Priority inheritance via queued entry calls, via abortion, and via a task master waiting for dependents to terminate is intentionally not specified, mainly because the effects are asynchronous with respect to the affected task, which would make implementation significantly more difficult. An additional reason for not specifying inheritance through task masters waiting for dependents is that it would be a one-to-many relation, which would also introduce extra implementation difficulty. Other reasons for not doing inheritance via abortion are stated in D.6. === <span id="1-3">D.1.3 Base Priority Specification</span> === The initial specification of the base priority of a task is by means of the pragma Priority. This is compatible with Ada 83. The pragma Interrupt_Priority is provided for specifying a base priority that may be at an interrupt level. The pragma is different in order to make it very visible in the source code wherever a base priority is being assigned that might have the side-effect of blocking interrupts. The Interrupt_Priority pragma is also allowed to specify priorities below interrupt level, so that it is possible to write reusable code modules containing priority specifications, where the actual priority is a parameter. The rule that the priority expression is evaluated for each task object, at the time of task initialization satisfies the requirement for having task objects of the same type but with different priorities. The expression specifying the priority is evaluated separately for each task. This means that it is possible, for example, to define an array of tasks of different priorities, by specifying the priority as a discriminant of the task, or by a call to a function that steps through the desired sequence of priority values thus <syntaxhighlight lang="Ada"> task type T is pragma Priority(Next_One); -- call function Next_One ...</syntaxhighlight> and similarly for protected objects. A default base priority is specified, so that the behavior of applications is more predictable across implementations that conform to this Annex. This does not prevent implementations from supporting priority inheritance or other implementation-defined scheduling policies, which relied for legality under Ada 83 on the task priority being unspecified. This is because an implementation need not support this Annex at all but if it does then it may still conform and provide user- selectable task scheduling policies that define additional forms of priority inheritance. Such inheritance may raise the active priority of a task above its base priority, according to any policy the implementation chooses. The main reason for choosing the default priority of a task to be the base priority of the task that activates it (the base priority of its creator) is that the creator must wait for the new task to complete activation. For the same reason, AI-00288 specifies that during this time the task being activated should inherit the priority of the creator. The default base priority of the environment task (System.Default_Priority) is chosen to be the midpoint of the priority range so that an application has equal freedom to specify tasks with priorities higher and lower than that of the default. It does not seem to always be the case that "normal" tasks (i.e. those that do not have a particular priority requirement), necessarily have the lowest priority in all circumstances. == <span id="2">D.2 Priority Scheduling</span> == The purpose of this section is to define the operational semantics of task priority, and to define a specific default scheduling policy. The definitions introduced here are also used for priority ceiling locking [RM95 D.3] and entry queuing policies [RM95 D.4]. === <span id="2-1">D.2.1 The Task Dispatching Model</span> === Ada 95 provides a framework for a family of possible task dispatching policies, including the default policy which is specified in [RM95 D.2.2] as well as other policies which may be defined by an implementation. The phrase task dispatching is used here to denote the action of choosing a task to execute on a processor at a particular instant, given that one already knows the set of tasks that are eligible for execution on that processor at that instant, and their priorities. This is distinguished from the more general concept of task scheduling, which includes determination of the other factors, i.e. which tasks are eligible to execute (in the logical sense), which tasks are allowed to be executed on each processor, and what is the active priority of each task. The term "processing resource", which was introduced in Ada 83, is developed further. Informally, a processing resource is anything that may be needed for the execution of a task, and whose lack can prevent a task from execution even though the task is eligible for execution according to the rules of the language. Besides processors, the only specific processing resources that are specified by the Annex are the logical "locks" of protected objects - i.e. the rights to read or update specific protected objects. An important feature of the protected type model (explained more fully in D.3) is that protected objects can be implemented in a way that never requires an executing task to block itself in order to execute a protected subprogram call. As explained in D.3, it is a consequence of the priority-ceiling rules that, if there is only one processor, the highest priority task that is eligible for execution will never attempt to lock a protected object that is held by another task. Thus, based on single-processor systems alone, there would be no need to treat protected objects as processing resources. However, on a multiprocessor system, regardless of how protected types are implemented, a task may be forced to wait for access to a protected object. Thus, access to a protected object must be viewed as a processing resource. Even on a single- processor system, if the implementation chooses not to use priority- ceiling locking, a task may need to wait for access to a protected object. This might be the case, for example, if tasks are implemented using the services of an underlying operating system which does not support economical priority changes. (Note that this potential waiting is not formally considered to be "blocking" by the rules of the language.) In some systems there may be other processing resources. A likely example is access to a page of virtual memory. This might require a task to wait for a page of real memory to be allocated, and the desired page of virtual memory to be read into it. I/O operations may require access to an I/O device that is in use by another task (or operating system process). The use of conceptual ready queues in the specification of the task dispatching model is derived from POSIX 1003.4 (Realtime Extension) [1003.4 93] and 1003.4a (Threads Extension) [1003.4a 93] standards. A separate queue for each processor is specified in the model, in order to allow models of multiprocessor scheduling in which certain tasks may be restricted to execute only on certain processors. If the implementation allows all tasks to run on any processor, then the conceptual ready queues of all processors will be identical. Since this is only a conceptual model, the implementation is free to implement the queues as a single physical queue in shared memory. The model thus accommodates a full range of task-to-processor assignment policies, including the extremes of a single task dispatching queue and a separate queue per processor. To allow for multiprocessor implementations, it is implementation defined whether a task may hold the processor while waiting for access to a protected object. This allows the implementation to directly use a "spin-lock" mechanism, or to use a (higher-level) suspending lock mechanism such as might be provided by an underlying multiprocessor operating system. Though it is not specified here, it is desirable for delay queues to be ordered by priority within sets of tasks with the same wake-up time. This can reduce priority inversion when several tasks wake up at once. Ideally, run-time system processing for wake-ups of lower priority tasks should also be postponed, while a high-priority task is executing. This behavior is allowed by the model, but it is not required, since the implementation cost may be high. Though we hope that the default scheduling policy defined in [RM95 D.2.2] will be adequate for most real-time applications, it is inevitable that there will be a demand for implementation-defined variations. We will consider how several such policies can be accommodated within the framework. Consider the Earliest-Deadline-First (EDF) scheduling technique. The EDF scheduling algorithm is known to be optimal for systems of independent tasks on a single processor. The EDF priority of a task is the number of ready tasks with later (absolute) deadlines. In general, this value may need to be adjusted for every change in the set of tasks that are eligible for execution. Since there is no mechanism by which a user-defined scheduler can be notified to make such changes, the Dynamic_Priorities package (see D.5) is insufficient for a user to implement EDF scheduling. However, an implementation is free to provide EDF scheduling via an implementation-defined mechanism. The implementation could dynamically adjust base priorities to reflect EDF task ordering, in which case the semantics could be defined in terms of the run-time system calling Set_Priority to affect the changes. Alternatively, an implementation could model EDF scheduling by means of "priority inheritance", where tasks inherit priority dynamically from some implementation-defined abstraction. For this to work well, the base priorities of all tasks would need to be set to Any_Priority'First, since the active priority would need to be lowered dynamically, as well as raised. Another anticipated application requirement is for time slicing. Implementation-defined time-slicing schemes may conform to this specification by modifying the active or base priority of a task, in a fashion similar to that outlined for EDF scheduling. === <span id="2-2">D.2.2 The Standard Task Dispatching Policy</span> === The standard dispatching policy can be explicitly requested by writing <syntaxhighlight lang="Ada"> pragma Task_Dispatching_Policy(FIFO_Within_Priorities);</syntaxhighlight> for the partition. An implementation may provide alternatives but none are required. If no such pragma appears then the policy is implementation defined. As mentioned above, the purpose of specifying a standard task dispatching policy is to achieve more predictable task scheduling and more portability of applications that use priority scheduling, as compared to the Ada 83 task scheduling model. This leads to a dilemma. On one hand, the ideal is to completely specify which task will be chosen to execute. On the other hand, such specification will prevent (efficient) implementation on certain machines. In particular, there are inherent differences between multiprocessor and single-processor machines, and there may be constraints on task dispatching policies imposed by underlying operating systems. It seems there is no one task dispatching policy that will be acceptable to all users and implementable for all execution environments. Nevertheless, if there is a dispatching policy that will satisfy the needs of a large segment of real-time applications and is implementable on most execution platforms, there are benefits to making it always available. While implementations are allowed to provide additional dispatching policies, there is no requirement that more than one such policy will be supported in the same active partition. This is based on the assumption that usually it does not make a lot of sense to talk about two independent dispatching policies in the same partition. Interactions must be defined and by doing so the two policies become essentially one. However, the support of two such unrelated policies is not precluded whenever it makes sense for the application and/or the underlying system. In addition, the dispatching policy is unspecified (as opposed to implementation-defined) if the user does not specify the pragma Task_Dispatching_Policy. This is because presumably, if the pragma is not provided, the user is not concerned about the dispatching specifics, and in addition, in many cases the actual policy (in the absence of the pragma) can simply be the policy of the underlying OS. This might not be specified, not documented precisely enough, or may even vary from one execution of the program to the next (as would be the case if the policy is controlled from outside the program). The standard task dispatching policy specified in this Annex can be implemented on both single-processor and multiprocessor machines. It can be implemented by an Ada RTS that runs on a bare machine, and it is also likely to be implementable over some operating systems. In particular, the standard dispatching policy is intended to be compatible with the SCHED_FIFO policy of the Realtime Extension of the POSIX operating system interface standard. A special feature of the delay statement, whether it appears as a simple statement or in a select statement, is that it always causes the executing task to go to the tail of its ready queue of its active priority. This is true even for delay statements with a zero or negative duration. It means that if there is another task of equal priority competing for the same processor, the task executing the delay will yield to this task. Imposing this rule makes the delay behavior uniform. It is also desired for predictable execution behavior, especially in situations where the delay duration or time is a value computed at run time, and which may have positive, zero, or negative values. As mentioned in UI-0044, causing a task to yield its processor to equal- priority tasks is a side-effect of delay statements in many existing Ada 83 implementations. Some current Ada users rely on this feature to achieve a form of voluntary round-robin scheduling of equal-priority tasks, under application control. Supporting this feature is expected to increase the execution time overhead of zero and negative delays, but the overhead does not seem to be greater than that which would be experienced if the shortest possible nontrivial delay (i.e. one that requires the task to be blocked) were executed. === <span id="3">D.3 Priority Ceiling Locking</span> === Priority-ceiling locking of protected objects serves the following purposes, in order of decreasing importance * Priority inversion can be bounded. * A very efficient implementation of locking is permitted. * Protected subprograms can be called safely from within direct- execution hardware interrupt handlers. * On a single processor, deadlock is prevented. Priority ceiling locking is specified by writing <syntaxhighlight lang="Ada"> pragma Locking_Policy(Ceiling_Locking);</syntaxhighlight> in a unit of the partition. Other policies are permitted but not required. As with task dispatching, if no pragma appears for the locking policy, then the policy is implementation defined. Note that if FIFO_Within_Priorities is requested as the task dispatching policy then Ceiling_Locking must also be specified. === <span id="3-1">D.3.1 Bounding Priority Inversion</span> === By specifying that the task executing a protected operation inherits the priority of the protected object, we permit the duration of priority inversion (due to enforcement of mutual exclusion between operations on a protected object) to be bounded. A priority inversion is a deviation from the ideal model of preemptive priority scheduling; that is, a situation where a higher (base) priority task is waiting for a processing resource that is being used by a lower (base) priority task. Priority inversion is undesirable in a priority-based scheduling system, since it represents a failure to honor the intent of the user, as expressed by the task priorities. Bounding priority inversion is important in schedulability analysis. In particular, if priority inversion can be bounded, Rate Monotonic Analysis can be used to predict whether a set of Ada tasks will be able to meet their deadlines [Sha 90a]. The technique has been successfully applied to several hard real-time systems written in Ada. The ceiling locking scheme specified in this Annex is similar to the "priority ceiling emulation" in [Sha 90b], and to the "stack resource protocol" described in [Baker 91]. On a single processor, these schemes have the property that, once a task starts to run, it cannot suffer priority inversion until it blocks itself. Thus, the only points at which a task can suffer priority inversion are where the task has been unblocked (e.g. delay or rendezvous) and is waiting to resume execution. At these points, it may need to wait for one task with lower base priority (but a higher inherited priority) to complete the execution of a protected operation. Among the locking policies that bound priority inversion, the policy specified here is the simplest to implement, and has been shown to be more or less indistinguishable from other policies in effectiveness. Support for this policy is also included in the mutex locking model of the proposed POSIX Threads Extension standard [1003.4a 93]. With priority inheritance through protected object ceilings, the duration of priority inversion encountered by a task T that has been unblocked will not be longer than the longest execution time of any one protected operation, over all the protected objects with ceilings higher than or equal to the base priority of T. In estimating this bound, the worst case execution time of each operation must be used, including the entry-servicing code. For a protected object with entries, this time bound must include the case where the maximum number of queued entry calls are served. (This number is bounded by the number of tasks that share access to the protected object.) Checking of priority ceiling violations by the implementation can be helpful to the programmer, even if the implementation is not relying on the accuracy of this information for locking, since it amounts to verifying important assumptions that are made in schedulability analysis. === <span id="3-2">D.3.2 Efficient Implementation Techniques</span> === Note that the Annex does not require that protected objects be implemented in any specific way. However, it is intended that the model be implementable via an efficient non-suspending mutual exclusion mechanism, based on priorities. Such mechanisms are well understood for static priority systems where the only priority inheritance is through locks, but the inclusion of dynamic base priorities and other forms of priority inheritance complicates the picture. We will argue the adequacy of the specifications in this Annex to permit an efficient non-suspending mutual exclusion mechanism based on priorities, under certain assumptions. In this discussion it is assumed that priority inheritance occurs only via the mechanisms specified in this Annex, and the only processing resources that can be required by a task are a processor and protected object locks. Here, a lock is an abstraction for having mutually exclusive access to a protected object. The operations on locks are seize a lock, and release a lock. Locks are not transferable; once seized, a lock is not allowed to be seized by another task until it is released by the last task that seized it. It is assumed that protected objects can be implemented using locks. It is also assumed here that when the base priority of a task is lowered, it yields its processor to any task with active priority equal to the new base priority, in particular to one that is holding a protected object lock with that priority as its ceiling, if such a task exists. The cases of a single processor and a multiprocessor will be considered separately. Suppose there is only one processor. Assume that the implementation of the seize operation is not able to block the task. We will argue that mutual exclusion is still enforced, by the scheduling policy. In particular, suppose a task, T1, is holding a lock on a protected object, R1. Suppose T2 is another task, and T2 attempts to seize R1 while T1 is holding it. We will show that this leads to a contradiction. Let C(R) denote the ceiling of a protected object R, Bp(T) denote the base priority of a task T, and Ap(T) denote the active priority of a task T. If Ap(T2) > C(R1), T2 would not be allowed to attempt to lock R1. (This rule is enforced by a run-time check.) Therefore, Ap(T2) <= C(R1). T1 must run in order to seize R1, but it cannot be running when T2 attempts to seize R1. So long as T1 is holding R1, it cannot be blocked. (This rule can be enforced statically, or by a run-time check.) Thus T1 must be preempted after it seizes R1 but before T2 attempts to seize R1. When T1 is preempted, it goes to the head of the ready queue for its active priority, where it stays until it runs again. Note that the active priority of T1 cannot be changed until it runs again, according to the reasoning in D.1.2: changes to base priority are deferred while T1 is holding the lock of R1, and T1 cannot inherit higher priority since it is not blocked (and not running) and must already have started activation. For T2 to attempt to seize R1 while T1 is on the ready queue, T2 must have higher active priority than T1, or have been inserted at the head of T1's queue after T1 was preempted. The latter case can be eliminated: for T2 to be inserted at the head of T1's ready queue, T2 must be preempted after T1; to be preempted after T1, T2 must be running after T1 is preempted; to be running after T1 is preempted, T2 must be at the head of the highest priority non-empty queue; this queue must have higher priority than Ap(T1), since T1 is at the head of its own queue. Thus, in either case, T2 must be executing with higher active priority than Ap(T1), some time after T1 is preempted and while T1 is still on the same priority queue. That is Ap(T1) < Ap(T2). Since T1 is holding R1, it follows that C(R1) <= Ap(T1) < Ap(T2) at the first point where T2 runs after T1 is preempted, and while T1 is still on the same ready queue. Before T2 attempts to seize R1, the active priority of T2 must drop to a value no greater than C(R1). (This is enforced by a run-time check.) The active priority of T2 cannot drop below Ap(T1), or T1 would preempt. This leaves the possibility that the active priority of T2 drops to exactly Ap(T1). But in this case, the implementation must cause T2 to yield to T1, as part of the operation that changes the base priority of T2 (see [RM95 D.5]). Thus, T2 cannot execute and so cannot attempt to lock R1. In conclusion, for a single processor, the scheduling policy guarantees that there is no way a task can execute to attempt to seize a lock that is held by another task, and thus, no explicit locking mechanism is required. On a multiprocessor, it is clear that priorities alone will not be sufficient to enforce mutual exclusion. Some form of interprocessor locking is required. Suppose this is accomplished by means of a busy- wait loop, using an atomic read-modify-write operation such as test-and- set. That is, a processor attempting to seize a protected object lock "spins" until it is able to set some variable in shared memory, which indicates that the protected object is locked. Thus, there is no danger of loss of mutual exclusion. The new problem is deadlock. A necessary (but not sufficient) condition for deadlock is a cycle of "wait-for" relationships between pairs of tasks. In this case, there are two kinds of wait-for relationships. The obvious kind is where task T is spinning for a lock R held by task T'. The less obvious kind is where T is waiting for a processor that is being held by the spinning task T'. The priority locking scheme does not prevent a direct deadlock situation of the obvious kind, in which task T1 is spinning waiting for a lock held by task T2, and task T2 is spinning (on another processor) waiting for a lock held by task T1. Fortunately, the user can prevent this kind of a deadlock, by not using nested protected operation calls, or by imposing a fixed ordering on nested protected operation calls. A more serious problem, if it could occur, would be a deadlock involving a task waiting for a processor that is busy spinning for a lock. For example, suppose task T1 seizes R1, T1 is preempted by T2, and then T2 starts spinning in an attempt to seize R1. This would result in a deadlock if T2 is spinning on the only processor where T1 can execute at this time. This kind of deadlock would be serious, since it would be hidden inside the implementation, where the user could not prevent it. Fortunately, this kind of deadlock is prevented by the priority ceiling locking scheme. For tasks executing on the same processor, this is obvious. Since T1 inherits the ceiling priority of R1, an exception will be raised if T2 tries to lock R1 while its active priority is high enough to preempt T1. The priority ceiling scheme also prevents such deadlocks in situations involving tasks executing on different processors. For example, suppose task T1 (executing on processor M1) locks R1 and task T2 (executing on M2) locks R2. Suppose task T3 preempts T1 and attempts to lock R2, while T4 preempts T2 and tries to lock R1. For this to happen, either T3 or T4 must fail the priority ceiling check. We will show this for the general case. Suppose there is a cycle of wait-for relationships. If T is waiting for T', we have either: # T is spinning for a lock L held by T', so Ap(T) = C(L) <= Ap(T'). (Note that we may have C(L) < Ap(T') if T' performs a nested protected operation with higher ceiling, while it is still holding the lock L.) # T is waiting for a processor held by T', which is spinning for some lock L', so Ap(T) < Ap(T') = C(L). In order for the cycle to happen, both relationships have to hold for at least one pair of tasks, but then we have a contradiction. === <span id="3-3">D.3.3 Deadlock Prevention</span> === It is a consequence of the priority ceiling locking scheme that an application cannot create a deadlock using protected subprograms on a single processor. This follows directly from the fact that a task executing a protected object operation cannot be preempted by any other task that requires access to that protected object. Note that this is distinct from the problem of deadlock discussed above, which is within a particular multiprocessor implementation of ceiling locking. In the case of a multiprocessor, the priority ceiling locking does not prevent an application from constructing a deadlock with protected subprograms, but it still can be used to prevent deadlocks that might be caused by the implementation. === <span id="3-4">D.3.4 Implementing Over an OS</span> === Priority ceiling locking may be very costly (possibly even impossible) where Ada tasks are implemented using the services of certain operating systems or executives. In particular, locking a protected object requires setting the active priority of a task to the protected object ceiling, or making the task entirely non-preemptable in some way, or using specialized operating system primitives. If there is no way to do this at all over a particular OS or executive, [RM95 1.1.3(6)] may be used to relieve the implementation from supporting priority ceiling locking. A more difficult case would be where there is a way to change a task's priority, but this operation is very costly. This might be true, for example, where Ada is implemented over a version of POSIX threads which does not support the priority ceiling emulation option for mutexes. We considered whether an implementation of this Annex should be allowed to support priority ceiling locking but to only use it on those protected objects for which it is requested explicitly. The rationale is that the cost of priority changes may be too high to tolerate in general, but the user may determine that it is worthwhile in some specific cases. The extra implementation overhead of supporting two kinds of locks would be offset by the gain in efficiency for those cases (perhaps the majority) where ceiling locking is not used. Presumably, an implementation could still use priority ceiling locking with a default priority ceiling when no ceiling is specified, but could also use some other locking protocol in this case. If this proposal had been accepted, then there would have been a problem with the check for ceiling violations. To reap the maximum benefit in efficiency from not raising the active priority of a task when it locks a protected object, no check for ceiling violations should be required either. This would result in portability problems going from implementations that use a mixture of priority-ceiling and non-priority- ceiling locking (A) to implementations that use priority-ceiling locking for all protected objects (B). For example, suppose PR1 has no specified ceiling, PR2 has a ceiling specified that is somewhere below Priority'Last, and all callers of PR1 and PR2 happen to have active priorities below Priority'Last. Suppose some operation of PR1 calls some operation of PR2. With implementation (A), this call to PR2 would always be safe, since the active priority of a task is not raised by calling PR1. With implementation (B), the call to PR2 from inside PR1 would be made at the default ceiling priority of PR1, which is Priority'Last. This would violate the ceiling of PR2, causing Program_Error to be raised. While this approach could have worked, it did not seem that there was enough user benefit to justify the loss of portability. If the implementation did not support priority-ceiling locking, because the cost of priority changes is prohibitive, but the application designer judged that avoiding priority inversion justifies the overhead of the priority changes, the application might have to adjust the active priority explicitly, by setting the base priority. This would mean calling Set_Priority before and after calls to the protected operations where priority inversion is of concern. Naturally, techniques like this are prone to race conditions, especially in the presence of interrupts. Also, it is not clear that the overhead of Set_Priority would be any smaller than the direct OS support for priority ceilings. This Annex provides a prioritized model of mutual-exclusion which is integrated with interrupt disabling when shared data is used between the interrupt handler and normal tasks. There may be situations where this model will be too elaborate and costly. Examples of this may be certain operating systems, or implementations over bare machines which traditionally have disabled preemption and/or interruption for this purpose. This implementation model is allowed by the Annex and is consistent with the other priority rules. In particular, the tasks' priorities still maintain the granularity and the range of the type. However, for protected object ceilings, implementations are allowed to round all priority values in the Priority range to Priority'Last, and those in the Interrupt_Priority range to Interrupt_Priority'Last. The net effect of such rounding is that on each call of a protected object with ceiling in the lower range, preemption (or dispatching) is disabled. When a protected object in the interrupt range is involved, all interrupts are disabled. This reduces the number of protected object ceilings to only two values which makes the approach quite similar to the disable preemption/interruption employed by existing kernels. The rest of the priority rules are not affected by this approach. === <span id="3-5">D.3.5 Implementation and Documentation Requirements</span> === The implementation will require protection of certain processing resources, not visible to the application, from concurrent access. For example, a storage allocation operation generally requires exclusive access to the data structure that is used to keep track of blocks of free storage. Likewise, run-time system operations involved in rendezvous generally require exclusive access to an entry queue. It would be natural to implement such critical sections in the run-time system using protected objects. If this is done, it is important that an application task with high active priority does not unwittingly violate the priority ceiling of one of these run-time system structures. In order to reduce the likelihood of such problems, the implementation requirement is for the ceilings of such resources to be at least Priority'Last. This is intended to make such unwitting ceiling violations impossible unless the application uses interrupt priorities. An application that does use interrupt priorities is responsible for ensuring that tasks avoid operations with low ceilings while they are operating at interrupt priority. The rules against performing potentially blocking operations in protected bodies are expected to help in this respect, by ruling out most of the operations (other than storage allocation) that are likely to require locking run-time system data structures. In addition, the implementation is allowed to limit the RTS operations that are allowed from an interrupt handler. An application that uses interrupt priority levels will need to know of any implementation uses of resources with lower ceilings, in order to avoid ceiling violations. The implementation is required to provide this information. == <span id="4">D.4 Entry Queuing Policies</span> == The Ada 83 rule that entry calls be served in FIFO order may result in priority inversion, which can cause a loss of schedulable processor utilization. The same issue has been raised regarding the choice between open alternatives of a selective accept statement, which is unspecified by Ada 83. However, for upward compatibility reasons any existing Ada applications that rely on FIFO entry queuing order should continue to work with Ada 95. For this reason, the default entry queuing policy, specified in [RM95 9.5.3] and [RM95 9.7.1] is still FIFO. (This contrasts with the other two policies where, if no pragma is supplied, the policies are implementation defined.) In addition, the user can override the default FIFO policy with the pragma Queueing_Policy thus <syntaxhighlight lang="Ada"> pragma Queuing_Policy(Priority_Queuing);</syntaxhighlight> which stipulates the alternative policy which all implementations supporting this Annex must provide. An approach that we rejected was for a user to be able to specify different entry service policies for each entry or task. Based on analysis of existing Ada run-time system technology, it appeared that requiring the Ada implementation to support per-entry or per-task selection would impose significant distributed execution-time overhead and would significantly complicate the Ada run-time system. Moreover, the need for mixed policies for entry service has not been demonstrated. The solution adopted here is that a user can rely on applications that select priority queuing on a partition-wide basis being portable to any implementation that complies with this Annex. It is left to the implementor to decide whether to support finer-grained (i.e. per-task or per-entry) selection of queuing policy, based on customer demand. It is possible that the choice of entry queuing policy may cause different code to be generated. Thus, the entry queuing policy must be specified no later than the point where each affected entry is declared. Since certain compilation units (including packages that are intended to be reusable) may depend for correctness on a particular policy, it is important for the compiler or linker to be able to detect inconsistencies in such dependences. This can be guaranteed so long as the choice of policy is fixed at the time the entry is declared, and achieved through the general mechanism of compatible configuration pragmas (see [RM95 10.1.5]). === <span id="4-1">D.4.1 FIFO Queuing</span> === FIFO queuing is provided for upward compatibility with Ada 83. If the correctness of a particular unit relies on FIFO entry queuing, it may specify this policy explicitly by <syntaxhighlight lang="Ada"> pragma Queueing_Policy(FIFO_Queuing);</syntaxhighlight> This is important when other units that are included in the same partition specify Priority_Queuing. If FIFO_Queuing was just the default, all units in the partition would have inherited, in this case, the Priority_Queuing policy, as opposed to being illegal (due to conflicts) which is the desired behavior. Implementations may support both policies in the same partition, but then the interactions between the policies are implementation-defined. Nothing is specified about the rules for choosing between open alternatives of a selective accept statement, since there is no consensus among existing Ada compilers or Ada users as to how this choice should be resolved in a FIFO queuing environment. Leaving the rule unspecified provides upward compatibility. === <span id="4-2">D.4.2 Priority Queuing</span> === Substantial consensus seems to have evolved that priority scheduling requires priority-ordered entry service. Priority-ordered entry service eliminates a source of unnecessary priority inversion and more consistently expedites the execution of higher priority tasks. Therefore, the Priority_Queuing policy is specified as a user-selectable option that must be supported by all real-time implementations. Priority inheritance through queued entry calls was intentionally omitted from the Priority_Queuing policy. Several models for priority inheritance through queued calls have been proposed in the literature. However, there is no hard analytical data to support choosing one of these priority inheritance models over another. The basic need for providing access to shared data without unbounded priority inversion is already supported by the inheritance feature of priority-based protected objects. The implementation overhead of more complex forms of priority inheritance is sufficiently high that requiring it is not sensible, if only one standard entry queuing and priority inheritance policy is specified. The decision to require priority-order selection among open alternatives of selective accept statements, and among open entries of a protected object is based on the desire to avoid unnecessary priority inversion. It is understood that there will be some additional implementation overhead, but this overhead is believed to be justified by the potential gain in schedulability. Priority ties can occur. If there are several open accept alternatives of a selective accept statement, or several open entries of a protected object, there may be several highest priority calls. For predictable behavior, a tie-breaking rule is needed. Textual order of the select alternatives or entry declarations is specified, on the grounds that this provides the greatest degree of predictability and direct control to the programmer. In addition, it is believed to be easy to implement. The choice of tie-breaker rules does limit implementation choices. Even though the semantic model for entries is based on there being a separate queue for each entry, the implementation may choose not to provide separate physical queues. For example, when a task reaches a selective accept statement or is exiting a protected object the implementation might do one of the following: * Do a full scan of all tasks in the system, in priority order, to see whether any of them is trying to call one of the currently open entries. (This might already be very inefficient, due to the rules about the effects of priority changes on queued calls.) * Search a single priority-ordered queue, which is associated with the accepting task or the protected object, to find the first caller that is calling one of the currently open entries. With data structures that combine calls to different entries, it would be harder to select the call that corresponds to the lexically-first accept alternative or entry body declaration. The most natural tie- breaker between equal priority calls would be some form of FIFO. On the other hand, if the implementation does maintain a separate queue for each entry, then it may be easier to break ties based on textual order. The present rule takes the point of view that pinning down the choice of tie- breaker rule is important enough to the application that the implementation choice can be so limited. ==== Reordering of Entry Queues ==== The decision to specify what effect task priority changes have on queued entry calls is based on the goal of implementation uniformity. The rules distinguish between "synchronous" entry calls and those associated with asynchronous select statements. Entry calls associated with asynchronous select statements are not reordered when the priority of the task that queued the entry call changes. This decision is largely based on consideration of implementation efficiency and the fact that the task is not waiting for these entry calls. Otherwise, every time the priority of a task changed, its asynchronous calls would be deleted and reinserted in their various entry queues. This would conceivably happen even for temporary changes in active priority associated with starting and completing a protected action in the abortable part. The priority of an entry call must be determined before the task has locked the protected object, because it is a consequence of the priority ceiling locking mechanism that, at the time the protected object lock is seized, the active priority of the task making the entry call will always be equal to the ceiling of the protected object. If the priority of the call were taken at this time, it would be the same for all callers to the entry, which would defeat the purpose of priority queuing. The desired semantics can be implemented by recording the calling priority as an implicit parameter associated with the queued call, before the protected object is locked. In an earlier version, asynchronous entry calls were reordered as well, but only upon base priority changes. However, this introduced certain problems. In particular, the task that caused the priority to change would probably have to do the reordering itself, which would imply getting the locks on the various protected objects with asynchronous calls. This would not be possible if the ceiling of the protected object were below the active priority of the task causing the priority change. By contrast, a task waiting on a synchronous entry call can do its own queue reordering, presuming its new priority is not above the ceiling. If it is, it is considered a bounded error, and Program_Error might be raised in the waiting task. This is consistent with the behavior which would have occurred if the priority had been raised above the ceiling just before the task originated the entry call, so it was deemed appropriate. We also considered the idea of requiring that the priority of a task not change while it is on an entry queue. This would eliminate the question of queue reordering, but it has several complicated consequences. Most serious of these seems to be that a task could not lock a protected object while it is on an entry queue and executing the abortable part of an asynchronous select statement. Other limitations would also need to be imposed, including extension of the deferral of base priority changes to cover the case where a task is on an entry queue. This would in turn increase the overhead of entry calls. More serious is that this limitation would interfere with the use of an entry queue to control user-defined scheduling. It seems plausible to create the equivalent of a ready queue using a protected entry queue, and then use dynamic priority changes coupled with other operations on the protected object to implement a scheduling policy. If dynamic priority changes were not permitted, a hypothetical scheduler would have significantly less flexibility in controlling the order of service of the various tasks on the entry queue. In contrast to asynchronous calls, a synchronous entry call is reordered upon a priority change in the waiting task. This was deemed important for consistency of the priority model, for example when dynamic priority changes are used to implement mode changes or a user-defined scheduling policy. Moreover, since dynamic priority changes are not expected to be frequent and there are other factors that are already likely to make the Set_Priority operation complicated, the extra complexity of checking whether the task is waiting on a (synchronous) entry call does not seem too high. We considered whether, when a task's priority changes, the new position of its queued call should be based on the new base priority or the new active priority. Since a waiting task could not be inheriting priority from a protected object, the active priority will be the same as the base unless the task is in a rendezvous or activating. (This assumes there are no extra implementation-defined sources of priority inheritance.) In these latter cases, it seems the call should continue to inherit the priority from the activator or entry caller. Therefore, the new priority of the call is specified as the new active priority of the caller after the new base priority is set. Another semantic detail is whether adjustment of priority causes loss of FIFO position within a priority queue, in the case that the new active priority is the same as the old active priority. For conceptual consistency, Set_Priority is specified as having the same round-robin effect on queued entry calls as it does on the task's position in the ready queue(s). === <span id="4-3">D.4.3 Other Queuing Policies</span> === The possibility of specifying other standard entry queuing policies, including some with priority inheritance, was also considered. The decision not to specify such alternative policies in the Annex was based on a general design goal of avoiding multiple solutions for a single problem. This would be contrary to the intent of the Annex to encourage uniformity among implementations and portability among applications. Moreover, supporting each alternative policy would involve significant implementation cost. Therefore, requiring every implementation of the Real-Time Systems Annex to support several alternative policies would not be sensible. The intent is that there be one policy that all Annex implementations are required to support; this is the Priority_Queuing. For applications that require upward compatibility with Ada 83, FIFO_Queuing is also specifiable. The basic model defined in this Annex allows experimentation with new policies, and the introduction of new solutions based on market demands. Therefore, implementations are permitted to define alternatives, but portable applications should rely only on the Priority_Queuing and FIFO_Queuing policies. == <span id="5">D.5 Dynamic Priorities</span> == The ability to vary the priorities of tasks at run-time has been so widely demanded that most Ada implementations provide some form of dynamic priority facility. The package Ada.Dynamic_Priorities provides such a capability in a portable manner. The interactions of priority changes with other aspects of Ada task semantics are also defined. The following subprograms are provided <syntaxhighlight lang="Ada"> procedure Set_Priority(Priority: Any_Priority; T: Task_ID := Current_Task); function Get_Priority(T: Task_ID := Current_Task) return Any_Priority;</syntaxhighlight> where the priority is the base priority rather than the active priority. Versions of Get_Priority and Set_Priority with no explicit task parameter (and so applying implicitly to the calling task) are unnecessary since this capability is provided by the Current_Task as a default parameter. Calling such operations might be slightly faster, but they would clutter the interface, and since these operations are not trivial anyway, the benefit did not seem to be worthwhile. (Compilers recognizing this special case can still optimize it by calling a separate entry point in the RTS.) Calling Get_Priority for a terminated task raises Tasking_Error. This allows the implementation to reclaim the storage devoted to the task control block upon task termination. Querying the priority of a completed or abnormal task is allowed and has a well-defined meaning since such tasks may still be executing and may still use the CPU, so providing user access to their priorities makes sense. A function for querying the active priority of a task was intentionally omitted. This is partly because the active priority can be volatile, making the result unreliable. In particular, querying the active priority inside a protected body will not return useful information, since the task will always be executing at the priority ceiling of the protected object. Another reason is that it is likely to be difficult to implement such a function on some systems. Moreover, requiring this value to be available would rule out at least one efficient technique for priority inheritance, in which inheritance relationships are represented only by links from donor to inheritor, and the implementation does not need to explicitly compute the active priority of a task or to store it. When the base priority of a running task is set, the task is required to go to the tail of the ready queue for its active priority. There are several reasons for this. First, this is what is specified in the SCHED_FIFO policy of [1003.4 93], after which the default task dispatching policy is modelled. Second, this is needed to prevent priority changes from violating the ceiling rules if priority inheritance is used to enforce mutual exclusion. For example, suppose task T1 is executing a protected operation of PR1, and task T2 preempts. Suppose T2 then lowers its own base priority to the ceiling of PR1. T2 is required to go to the tail of the ready queue at this point. This ensures that there is no danger of T2 trying to perform a protected operation on PR1. (Allowing T1 to preempt under these circumstances might also be desirable from the point of view of expediting the release of PR1.) ==== Deferral of the Effect of Priority Changes ==== The effect of Set_Priority on a task is deferred while the task is executing a protected operation, for several reasons. One reason is to prevent Set_Priority from forcing a task that is executing in a protected object to give up the processor to a task of the same active priority. Another reason is to permit more efficient implementation of priority inheritance and priority changes. In particular, when entering a protected operation body, or starting a rendezvous, it is permissible to push the old active priority on a stack, from which it is popped when the protected operation is left, or the rendezvous ends. Note that there need be no additional execution time overhead for implementing this deferral, over that already imposed by deferring abortion, in the case that no priority change is attempted during the time the protected operation is executed. For simplicity of implementation, priority changes are allowed to be deferred until the next abort completion point. This will be primarily useful in the context of target environments that have limited support for preemptive interthread or interprocessor signalling. Taken from a user's point of view, deferring a change to the base priority of a task during protected operations should make no difference if the change is in the downward direction, since this would not affect the active priority of the task anyway. If the change is in the upward direction, the difference could be noticeable, but no requirement for immediate upward change of base priority during protected operations has been demonstrated. There may be a requirement for a temporary change to the active priority, but this is possible by calling an operation of a protected object with high enough ceiling. Deferring the effect of changing the base priority also eliminates some semantic questions. One of these is whether the base priority of a task should be allowed to be raised higher than the ceiling priority of a protected object in which the task is currently executing. Allowing this would constitute a retroactive violation of the rule that a task cannot call a protected operation of a protected object while its active priority is higher than the protected object ceiling (the active priority is of course never less than the base priority). ==== Dynamic Priorities and Ceilings ==== When ceiling priorities and dynamic changes to priorities are supported in the same environment, some interactions with other language features are unavoidable. The source of these problems is mainly the inherent conflict between the need to arbitrarily and asynchronously change the task base priorities, and the ceiling model where a more disciplined usage of priorities is required. The problems get more serious if the effect of such misuse affects not just the program behavior, but also the correctness of the implementation. At least two interesting cases exist: <ol> <li>As part of the Set_Priority operation, a protected entry queue may have to be reordered. This happens when the affected task is waiting on a protected entry call (see [RM95 D.4]). If the task calling Set_Priority has an active priority higher than the ceiling of the relevant protected object, it will not be able to accomplish this reordering due to a ceiling violation. To circumvent this problem, it can awaken the waiting task which can then itself reorder the queue and continue waiting.</li> <li>A call queued on a protected entry queue may sometimes need to be cancelled. This happens when the task is aborted, its currently executing abortable_part is aborted (and it has some nested calls), or when the abortable_part completes normally and the triggering call needs to be removed from its queue. If the task's base priority was raised after the call was initially queued and remains too high when the call needs to be removed, it might fail to remove the call due to ceiling violations (since such removal involves locking the protected object). This situation is considered a bounded error, and can result in the task's priority being temporarily lowered to accomplish the cancellation of its call.</li></ol> We considered other alternatives as solutions to the above problems. For the first case, we looked into the possibility of temporarily lowering the priority of the task calling Set_Priority. This has the obvious problems of potentially introducing priority inversions, complicating implementations, and presenting a non-intuitive model to the user. We also looked at allowing the reordering to be deferred. This is also undesirable: the deferral may be too long and there may be several priority changes during this time. Resuming the affected task in order to accomplish the reordering was chosen as the suggested implementation model, since a similar mechanism is already required to support abort of a low-priority task by a high-priority task. We also looked at the possibility of limiting the effect of the Set_Priority call such that it will raise the priority only to the minimum of the ceilings of protected objects either held by or being queued on by the task. Again, it was not clear that these semantics are desired, and it would certainly add a substantial cost to the implementation. The second situation introduces a problem that if not addressed might make the implementation of finalization (as part of abortion) impossible. Here, a call is already queued and it must be removed; just raising an exception is not acceptable since this will not solve the problem. We considered various solutions, but ultimately declared the situation a bounded error, and allowed the task when it needs to cancel its call to have its priority temporarily lowered. The temporary priority inversion was not felt to be serious since this is considered an error situation anyway. ==== Example of Changing Priorities of a Set of Tasks ==== <syntaxhighlight lang="Ada"> type Task_Number is range 1 .. 4; type Mode_Type is range 0 .. 2; Task_Priority: array (Task_Number, Mode_Type) of Priority := ... ; protected Mode_Control is procedure Set(Mode: Mode_Type); pragma Priority(System.Priority'Last); end Mode_Control; protected High_Priority_Mode_Control is procedure Set(Mode: Mode_Type); pragma Interrupt_Priority; end High_Priority_Mode_Control; use Dynamic_Priorities; protected body Mode_Control is procedure Set(Mode: Mode_Type) is begin High_Priority_Mode_Control.Set(Mode); Set_Priority(Task_Priority(1, Mode),T1); Set_Priority(Task_Priority(2, Mode),T2); end Set; end Mode_Control; protected body High_Priority_Mode_Control is procedure Set(Mode: Mode_Type) is begin Set_Priority(Task_Priority(3, Mode),T3); Set_Priority(Task_Priority(4, Mode),T4); end Set; end High_Priority_Mode_Control;</syntaxhighlight> The table Task_Priority specifies the priorities that the tasks T1 through T4 should have, for every mode. Here, in order to avoid blocking every task for a long time, the priority changes are done in stages, at two different active priorities, via two protected objects. The task doing the priority change starts with a call to the lower-priority protected object. This calls the next higher level. The priority adjustments of lower priority tasks can be preempted by the execution of the higher priority tasks. ==== Metrics ==== The purpose of the metric for Set_Priority is to specify the cost of this operation, compared to other operations, for a case where it should be about as low as can be expected. This metric may be critical for some applications, which need to perform priority changes under time constraints, but the inherent complexity of Set_Priority is likely to make it time-consuming. Of course, complicating factors such as entry queue reordering may make the execution time of Set_Priority worse than would be indicated by this metric. The possibility of including more metrics, such as for a situation involving entry-queue reordering, was considered. This idea was rejected on the grounds that it would only be of interest for applications that change the priority of tasks with queued entry calls. Special cases could not be covered uniformly to this level of detail without greatly increasing the number of metrics. Finally, this metric would cover a large part of the RTS code itself, and not just the priority change operation proper, thus it will be influenced by many factors diminishing the value of the specific metric to the user. == <span id="6">D.6 Preemptive Abort</span> == A requirement has been expressed for "immediate" task abortion. There appear to be several motivations for wanting immediate abortion: # To stop the task from doing what it is currently doing before it can "contaminate" the application further, possibly with dangerous consequences. A task can contaminate the application by changing the system state or wasting processing resources. # To be certain that the task has stopped executing, so that the aborter can proceed without fear of interference from the aborted task (e.g. I/O, rendezvous, writing on shared variables). # To be certain that the aborted task does not continue executing indefinitely, as it might if it were (due to error) in an infinite loop without any abort completion points (see [RM95 9.8]). There are several possible meanings of "immediate" in this context: * Before the abort statement completes. This is easy to define and implement, but it may take a long or indeterminate time to complete, and so might require blocking the task that executes the abort. It satisfies requirement (2) only. * Before the affected task(s) are allowed to execute further. This is easy on a single processor, but may be too costly or impossible on a multiprocessor. It satisfies all three requirements. * As soon as the implementation can do it, and certainly within a bounded time. On a single processor, this would have the same meaning as above, but would allow some delay on a multiprocessor. It satisfies requirements (2) and (3). Whether it satisfies (1) depends on the implementation. The third meaning of "immediate" seems like the best compromise. This is the basis for the specifications in this section. With respect to what actually has to happen as part of the immediate activity, [RM95 9.8] defines what is included in the completion of an aborted construct. Specifically, [RM95 9.8] requires part of the effect of the abort statement to occur before that statement returns (e.g. marking the affected tasks and their dependents as abnormal). The requirements in the Annex go further and address the completion and finalization of the aborted constructs. The key requirement here is that the abortion be preemptive, in the sense that abortion should preempt the execution of the aborted task, and if abortion requires the attention of another processor, the abortion request should preempt any activity of the other processor that is not higher in priority than the aborted tasks. Note that the requirement for bounding the delay in achieving the effect of abortion can be satisfied on a multiprocessor, even if it is not possible for one processor to interrupt another. One technique is to use a periodic timer-generated interrupt on each processor, which causes the processor to check whether the currently executing task has become abnormal. An alternative was considered to allow the task calling the abort statement to be blocked until all the aborted tasks have completed their finalization, and for those tasks to inherit the blocked task's priority while it is blocked. This would be a change from Ada 83, where it is only necessary to wait for the aborted tasks to become "abnormal", and Ada 83 did not have user-defined finalization. Certainly, one of the reasons for aborting a task may be to release resources that it is holding. The actual release of such resources may be done during task finalization. However, waiting for finalization is not always possible, since a task may abort itself (perhaps indirectly, by aborting some other task on which it indirectly depends). In this case, it is not possible for the task calling for the abortion to wait for all the aborted tasks (including itself) to complete their finalization. Another problem is where the abort statement is inside an accept statement, and the task being aborted is the caller in the rendezvous. In this case, forcing the aborter to wait for the aborted task to complete finalization would result in a deadlock. The problem with self-abortion could be resolved by releasing the aborter to perform finalization, but the problem with rendezvous does not seem to be so easily resolved. The ability to wait for a collection of tasks to complete finalization is partially satisfied by two other mechanisms. One of these is the rule that requires blocking of a completed task master until its dependent tasks are terminated. If the tasks being aborted are not dependent, another partial solution is to use the delay statement and the Terminated attribute to poll the aborted tasks until they have all terminated. However, none of these mechanisms fully accomplishes the objective. Not allowing abortion to cause blocking has several benefits. In real-time applications, there are situations where the task executing the abort statement does not wish to wait for the aborted task to complete; in this case it could also be said that requiring the task to block is not "immediate" abortion. If the task executing the abort statement were to be blocked, unbounded priority inversion would be possible unless the tasks being aborted inherit the priority of the blocked task. This form of inheritance is undesirable for reasons explained in the next paragraph. A final benefit is that in this way, the treatment of abortion of a task via the abort statement is more similar to the abortion of a sequence of statements via a change to a barrier caused by a protected operation, since executing the body of a protected operation can never involve blocking of the calling task. Irrespective of the decision not to block the task executing the abort statement, there are other reasons for not requiring that aborted tasks executing finalization code inherit the priority of the task executing the abort. First, this would introduce a new form of one-to-many inheritance, with the associated additional implementation complexity. Second, if the aborted task is a low-priority task, and the aborter has high priority, it might not be appropriate to suspend the aborter while the aborted task finalizes. Third, if the active priority of the aborted task could be raised by abortion, it would be necessary to take into account all abort statements, as well as task dependency hierarchies, in determining protected object ceiling priorities; otherwise, the active priority of a task might violate the ceiling of a protected object during finalization code. Note finally, that if the user does want to make the finalization of the aborted task happen faster, the only solution is to raise the aborted task's base priority either before or after issuing the abort. Doing it afterwards enables the priority to be set higher than that of the aborting task; if the aborted task is already terminated no harm is done <syntaxhighlight lang="Ada"> Abort_Task(Joes_ID); -- take that Set_Priority(Priority'Last, Joes_ID); -- die quickly you dog</syntaxhighlight> While this approach is not that elegant, it is expected to satisfy such a need. ==== Documentation Requirements ==== It is clear that interprocessor communication delays may cause abortion to take longer on some multiprocessor systems. The predictability of such delays is bound to depend on the implementation, and the duration may depend on what other activities are going on in the system at the time. It is important that the designer of an application that uses abortion be able to determine whether this is going to be a problem for a particular application. ==== Metrics ==== The execution time of an abort statement is intended only to be a sample of the execution time, in a non-pathological case. Of course the actual execution time will vary, depending on factors such as the number of tasks being aborted, their current states, and their dependence relationships. Providing an upper bound would therefore require specification of more conditions. The intent of the upper bound on the additional delay for a multiprocessor is primarily to require the implementor to verify that such an upper bound exists. The specific value is less important than the existence of such a value. There must be some upper bound on the delay if abortion is to be useful in a real-time system. An upper bound may not be able to be measured directly, but it should be possible to (over-) estimate a bound by adding the upper bound of the communication delay to the upper bound of the local processing time. The intent of the metrics for asynchronous transfer of control is to tell whether this capability is implemented efficiently enough to be useful in time-critical applications. Potentially, there is a great gap in performance between an implementation of asynchronous transfer of control that is based on creating a separate thread of control for the abortable part, versus an implementation that uses the context of the same task. The intent is that such a gap can be discovered by the metrics. == <span id="7">D.7 Tasking Restrictions</span> == This section establishes that the Ada standard permits the development of highly optimized implementations for restricted tasking models. It also defines a specific set of restrictions, that both serves as an example of what an implementation can do, and may encourage convergent development and usage. Builders of hard real-time systems have observed that the full Ada tasking model is more general than they require, and imposes more overhead than they can afford. The existence of very lightweight executives for other tasking models suggests that significant performance improvements are possible for Ada tasking implementations, if some usage restrictions are observed. Any Ada implementor can define a restricted tasking model and provide a run-time system that is optimized for this model. (In fact many implementations do so currently, but in a non-portable way.) However, Ada 83 has been misinterpreted to give the (incorrect) impression that this is a form of "subsetting", and therefore is not allowed by the language standard. It is not subsetting, as long as the implementor also provides support for the full tasking model, perhaps with different compilation and linking options. Thus, it appears desirable for the Real-Time Annex to endorse this form of optimization. A restricted tasking model should permit simple and useful multitasking applications to be expressed, but simplify the implementation problem enough so that the size and execution time overhead of the run-time system need be no greater than with traditional real-time executives. Therefore, the intent behind the model defined here is to satisfy the needs of many of the real-time embedded applications that have rejected the full Ada tasking model for being too heavyweight. These applications include some that consist of a fixed set of cyclic tasks, with periodic and aperiodic timing constraints. This has traditionally been a stronghold of the cyclic executive and rate-monotonic scheduling models. The intended scope of restricted tasking applications also includes some more complex applications, which are event-driven. These applications have traditionally used real-time executives that can dynamically create and schedule extremely lightweight tasks. This kind of system is organized into groups of simple tasks. A task group is created in response to an event, executes for a while, and goes away. There may be precedence relations and delays among tasks within a group, but an individual task never blocks to wait for another task. Each task within a group is very simple: it may be preempted, but otherwise it runs to completion without blocking. The events that can trigger the invocation of task groups include interrupts and actions performed by other tasks. This is a well established model of software architecture, and has been used for more than a decade in guidance and control systems, including radar and sonar tracking systems, process control, railroad signalling and so on. This is also the task model of classical scheduling theories (see [Coffman 73]). === <span id="7-1">D.7.1 The Chosen Approach To Restrictions</span> === This Annex specifies a set of restrictions which should be such that the potential performance improvement justifies producing one or more special versions of the RTS according to the combinations of restrictions asserted in a particular program. The Restrictions pragma (see [RM95 13.12]), which is a configuration pragma, takes two forms. One such as <syntaxhighlight lang="Ada"> pragma Restrictions(No_Task_Hierarchy);</syntaxhighlight> indicates a simple yes/no restriction, whereas <syntaxhighlight lang="Ada"> pragma Restrictions(Max_Select_Alternatives => 5);</syntaxhighlight> indicates some numerical restriction on the feature concerned. ==== Compliance ==== Compliance with this pragma means that all the parameters must be recognized by the implementation, and the associated limitations must be enforced. It is clearly important for the implementation to reject violations of the restrictions. Without such checking, much of the value of the pragma is lost. Checking itself can be of value as well. Where the implementation is for a development host, if the host is used in preliminary testing of an application that is eventually intended for an embedded target, enforcement of the pragma by the development host will help to identify code that will cause problems arising when the time comes to move the application to the final target. Some of these limitations are to be checked at compile-time (such as for task hierarchies and the presence of finalization). For those that can only be checked at run-time, implementations are allowed to omit the checking code. Programs that violate the corresponding restrictions are considered erroneous. If a run-time check fails, Storage_Error should be raised. This exception is chosen because failure of these checks often indicates shortage of the storage allocated for a task - either the run- time stack storage or storage allocated within the task control block. The permission to omit the run-time checks is given due to the recognition that a check for a given violation may be as complex and costly as the support for the restricted construct. One does not want the checks to be difficult to implement or for the checks to add any overhead to a model that is intended to allow a simple implementation. The resource utilization checks need to be done at run time, and may incur some run-time overhead, but they may be very important during the testing of a system. The decision on whether to omit the checks is therefore left to the implementation based on the particular situation. ==== The Specific Restrictions ==== The basic criteria for deciding upon the restrictions were: * The restriction allows a faster or smaller run-time system. * The advantage is distributed. If it is a speed improvement, it applies to operations other than those ruled out by the restriction. If it is a size reduction, it is not simply due to deletion of unused run-time system components, such as might be done automatically by a linker. * Taking advantage of the restriction does not require a major change in compilation strategy for programs that follow the restriction from those that do not. * A sample of real-time embedded systems developers felt that the restricted feature is not essential for a significant portion of their applications. In addition, some restrictions have been included because a significant number of users and vendors felt that they were appropriate. Some of the specific restrictions and the benefits they bring are as follows * Max_Tasks (maximum number of task creations over the lifetime of the partition) plus Max_Task_Entries (maximum number of entries per task). These enable fixed RTS and task storage size. The amount of storage required by the run-time system for its own data structures and task workspace should be determinable statically, no later than load time. * Max_Task_Entries plus Max_Asynchronous_Select_Nesting (maximum nesting of asynchronous selects). These enable a fixed Task Control Block (TCB) size. If each task can be represented in the RTS by a fixed-size task control block, the complexity of the RTS is reduced. A list of free TCBs may be allocated at load time, speeding up task creation. * No_Task_Hierarchy; all tasks are library tasks. This means no overhead due to code executed to keep track of potential task masters, or to check for unterminated dependent tasks. Likewise, there should be no storage overhead for data structures to keep track of task master nesting. Abortion and task termination should not be complicated by the need to support hierarchies. * No_Task_Hierarchy plus No_Nested_Finalization (all controlled objects at library level). These permit the storage for non- library-level collections to be allocated on the stack, and the stack space can be recovered without finalization when the stack frame is popped. * No_Dynamic_Priorities. There are several known scheduling algorithms that do not use the capability to dynamically change the task's base priority. If it is known that the base priority of a task is static, then it is possible to have much simpler and more efficient queue management and dispatching algorithms in the run- time system. * No_Asynchronous_Control. Even though the semantics of this package are defined in terms of priorities, it is not clear that an implementation approach based on this semantic model is feasible on all possible targets. In general, the ability to asynchronously suspend the execution of another task is considered dangerous from the user's point of view, and may have distributed ramifications on the rest of the run-time system. Since in some applications, this feature will not be used (and may even be disallowed) it makes sense to allow for the corresponding restriction. * Max_Protected_Entries. There are several very efficient algorithms for servicing protected entry queues when the maximum number of entries is statically known and relatively small. The main issue here is the requirement for evaluating barriers whenever the state of the protected objects changes. The language rules in [RM95 9.5.2, 9.5.3] make it possible to evaluate the barrier less often than it would otherwise be needed (provided that the compiler can determine that no "interesting" change has occurred since the last check). It was suggested that the implementation can use a bit- vector (usually of one word length) to represent the true/false state of the barriers, and then check this bit-vector (using only a small number of machine instructions) in appropriate places instead of reevaluating all the barrier expressions. For this approach to work, the number of possible entries should be known a priori. Since the implementation of such a technique often involves the compiler, it might be necessary for this information to be known before any unit is compiled. * No_Abort_Statements plus No_Asynchronous_Control. These enable a number of further simplifications to the model. * Max_Task_Entries = 0. Forbidding task entries could reduce the size of the run-time system code. It could also reduce the amount of rendezvous-related information that must be stored in task control blocks. Processing this information during task creation and termination is a source of distributed overhead. The implementation of abortion might also benefit by not having to take into account the special case of tasks engaged in a rendezvous as callers, though the rules requiring deferral during protected operations and finalization operations cast this into doubt. Protected objects provide a lighter-weight mechanism that is more suitable than rendezvous for data and control synchronization in small real-time embedded systems. * No_Terminate_Alternatives. The terminate alternative may add distributed overhead but is less valuable in Ada 95 since a protected object will typically be used rather than a server task. * No_Implicit_Heap_Allocation. We considered adding a restriction forbidding the compiler from using the heap implicitly (i.e. not as a direct result of using an allocator). Such a restriction can improve the deterministic behavior of the memory in the system, by making all memory usage visible and user-invoked. However, this was difficult to mandate as a requirement on the compiler and so we have adopted a slightly different approach. The compiler is allowed to reject (and document) such user constructs that require implicit heap allocation. This way, it can ensure that no such heap requests will be present at run-time, and so the heap usage will be avoided. Certain other restrictions were considered, but were not included. Specifying a mechanism for configuring the run-time system size limits was also considered. It was left implementation-defined, because the practical mechanism is outside the scope of the language. For example, one method is for the implementor to provide source code of a few run- time system packages, which contain configuration constants. The user could edit these, recompile them, and link them in with the rest of the run-time system and the user's application. Another method is to provide a configuration tool that edits the run-time system object code, inserting constants for the required limits at the required points. This same function might be performed by a linker or a loader. ==== Max_Storage_At_Blocking ==== This restriction deserves special mention. If a task is not permitted to be blocked while it is holding more than a fixed amount of stack storage, a much larger number of tasks can be supported, since only one dynamic stack storage area is required for each priority level (essentially, only the TCB of a blocked task needs to be saved). Traditional real time systems are designed to make this possible. Practical ramifications of this requirement include: * Tasks should not have large local data objects or access collections. * Tasks should not have entries whose parameters require a large amount of storage. * Operations that may cause a task to be blocked should not be performed within deeply nested procedure calls or within a block statement that has large local data requirements. One implementation model is to have a fixed pool of stack spaces that are shared by all tasks, or all the tasks at a priority level. On each processor, not more than one stack space will be needed for each priority level. The stack space for a given level must be configured (by the user) to be large enough to meet the largest stack requirement of any task that executes at that priority level. A task releases its stack area when it blocks, and is allocated a stack area when it wakes up again. Depending on how ready queues are structured, allocation of a stack area might be done at the point where the task wakes up, or as a special case in the dispatcher when it gets ready to do a context switch to a stack-less task. A slight variation of this approach would be to always allocate a small and fixed-size part of the stack to the task, and to allocate the larger part only when the task is ready. In any case, the implementation can go to a linked list of stack spaces, remove one, and link it to the fixed-size part of the stack. This could be kept simple, maybe to the point of just setting the saved stack pointer value and a link to the fixed part of the stack. For example, on a machine with register windows, the implementation could keep one register window stored in the TCB. When allocating a stack area, it would write the new stack pointer (base) into this saved register window. Then, when the task is resumed, the implementation would load registers from the TCB and the task would be running with the new stack. The intention is that all requirements for non-volatile storage associated with a task be met by the task control block (or by a fixed- size extension of it). For example, this includes storage for the implementation of select statements, entry parameters, local variables, and local access collections. This means that any large non-volatile data used by a task must be declared in library-level packages or passed to the task by means of access values. The size of the task control block and the fixed part of each task's run-time stack is intended to be determinable no later than link time, so that a fixed-size pool of identical task control blocks can be pre-allocated at system initialization time. == <span id="8">D.8 Monotonic Time</span> == The package Ada.Real_Time is similar to the package Calendar. It has a type Time, a function Clock, relational operations on time, and arithmetic operations for combining times and durations. In order to explain why such a "duplicate" of Calendar is needed, we first review why some real-time applications need facilities beyond those in package Calendar. The inclusion of a standard calendar package and clock function in Ada seems useful. Certainly, the existence of a standard interface to time- keeping services that hides unimportant details of specific execution environments can be an aid to writing portable applications. However, a sample of existing practice in real-time Ada applications reveals that they frequently choose not to use the package Calendar. Perhaps the main reason is simply that Calendar is typically "political" time and so is not guaranteed to be monotonic since it may be adjusted by the effects of time zones and daylight saving changes. Another issue is the diversity of time-keeping requirements among real-time applications. It does not seem feasible to meet all these with a single solution. Both the requirements and the hardware (or operating system) support available differ widely from one real-time application to another. At one extreme, a simple real-time controller might be able to use a single 16-bit counter-timer circuit, with very fine granularity but a rather narrow range. At the other extreme, a complex electronic navigation system may require an atomic clock that is precisely synchronized with a global time reference, and may have precision and range requirements that demand 64-bit time representation. Given this diversity, it is natural to wonder whether Ada 95 should attempt to provide any standard time services at all other than the package Calendar which has to be retained for compatibility. To the extent that there are common requirements for such services within certain application domains, they should perhaps be the subject of a language-independent standard; but no such standard exists. The exisiting delay statement and the delay alternative require the language to provide a clock for two reasons: * Coordination of Clock and delay. If the application uses delay statements to control timing, the application's view of the time should be consistent with that of the implementation. * Timer resource sharing. The implementation needs access to a timer for the implementation of the delay statements. If there is only one such timer (as is the case on some execution platforms), the implementation and application must share it. Real-time applications clearly need the capability to block task execution until a specified time, and to impose a time limit on how long a task can stay blocked waiting for other operations. We considered an approach of providing general mechanisms for an application to wait for an event, and to abort blocking operations in response to events. This would have allowed the application to provide its own timer services. The delay statement could then just be a special case of waiting for a time-out event signalled by the user-defined timer, rather than the implementation's default timer. This solution was dropped since the added complexity seemed out of proportion to the benefits. The inclusion of the Real_Time package in this Annex is based on the realization that there was no choice but to provide a real-time clock which applications could use. Specifically, an application that requires time-outs on select statements must use the standard delay statement implementation. If the application needs to know what time it is, based on a time reference that is consistent with the delay, it must use a clock provided by the implementation. The following general requirements can be identified for a clock that is used in conjunction with the delay statement, to schedule task execution and specify time-outs: * Monotonically non-decreasing time value, incremented at a steady rate, with bounded discontinuities. * Fine granularity. * The ability to be used as the time reference in all forms of delay statement. * Efficient implementability using clock facilities that are typical of most existing hardware, and real-time operating systems. * Exact arithmetic on time and duration values, and precise conversion of rational-number durations to time intervals. * A defined relationship to other time-related features of the language, including the Calendar package, System.Tick, and the Standard.Duration type. The package Ada.Real_Time is intended to provide facilities that satisfy these requirements. Some real-time applications have other requirements, such as * Unique time-stamps. With fast processors and multiprocessor architectures, it is possible that for some implementations the clock may be read several times in one tick. Enforcing uniqueness in such an environment would amount to slowing down the clock reading operation. * Synchronization with external time references. In some situations (such as where the external time reference is non-monotonic, or synchronization cannot be performed frequently enough to avoid large adjustments), synchronization may be incompatible with the requirements for monotonicity and bounded discontinuity of the clock. These were considered but appeared to conflict with satisfying one or more of the other requirements and so were dropped. === <span id="8-1">D.8.1 An Ideal Clock</span> === International Atomic Time (TAI), regulated by the Bureau International de l'Heure (BIH) and supported by the various national time references, is currently accepted as the most precise physical time reference. It is monotonic and does not have leap-seconds or seasonal changes. All the other time standards can be defined as a function of TAI. That is, any other standard of political or physical time can be defined as a function C = TAI + D(TAI), where D(TAI) is a piecewise constant function, depending on the current value of TAI. In an ideal world, and an ideal implementation of the language for real-time applications, there would be a clock function that returns the current TAI clock value. Language- defined functions could be provided to convert this time to an arbitrary time zone. In practice, most Ada execution environments will not have access to an atomic clock. Even if such a clock is available, there may be a need to use other (less accurate) clocks, including the local time as perceived by a human operator or an operating system, or counter-timer circuits that are capable of generating interrupts. === <span id="8-2">D.8.2 Time Sources</span> === A language implementation is limited by the actual time-keeping resources provided by the hardware, which are possibly filtered through an operating system interface. In practice, several different kinds of time references are likely to be available to an Ada implementor. These have significantly different characteristics: * Counter-timer circuit * Calendar clock circuit * Externally synchronized clock A counter-timer circuit is a programmable hardware device which can be viewed as a register counting clock ticks. Such a timer is typically driven by a crystal oscillator, and can be read and reset to a specified value. A typical tick duration might be one microsecond. A counter-timer can typically be used to generate an interrupt when a specified number of ticks have elapsed. It might then restart automatically at a specified value (a periodic timer) or wait to be reset (a one-shot timer). Counter-timer circuits are comparatively inexpensive, and are easily added to a microprocessor-based design. Thus, in a specific hardware configuration of an embedded application, there may be several counter- timer circuits. However, these are not likely to be known and available to the implementation. The standard configuration of most processors typically has only a small number of counter-timer circuits (possibly one) that can be relied upon to always be available for use by the application and the language implementation. In small embedded real-time applications, these counter-timer circuits may be the only time reference available. The strengths of counter-timer circuits include: * Small clock-tick, typically one microsecond or smaller; * Monotonicity, subject to periodic wrap-around to zero; * Very regular ticks; * Ability to generate interrupts; * Very regular periodic interrupts, in periodic mode. Some limitations of counter-timer circuits include: jitter up to one clock-tick, variation in interval from one timer to another and with temperature, and a limited range before wrap-around. A calendar-clock circuit is a programmable hardware device that is very similar to a counter-timer-circuit. The main differences are: * The visible update rate (granularity) of the clock may be coarser (e.g. once per second). However, the underlying oscillator rate, and hence the accuracy, is likely to be just as high as the counter- timer. * The range of times representable by the clock is large, perhaps 100 years. * The clock may be programmable to automatically take into account leap years and seasonal political time changes, such as daylight savings time. * Time values, instead of being a simple count of ticks, may be represented in terms of second, minute, hour, day, month, and year. Various forms of externally synchronized time references may be available in a specific application. In a system requiring very precise global positioning there might be a local atomic clock, periodically synchronized with the TAI via a communications link. In a network, there might be a broadcast periodic "heartbeat", or a message-based averaging algorithm for keeping the local clocks of various network nodes synchronized within some tolerance. Generally, the frequency of external synchronization is limited, and if it relies on communications with external systems there may be times when the local system is cut off from its source of external synchronization. Typically, local clock or timer circuits are used to keep time between external synchronization points, so that a finer granularity of time is available locally. In general, synchronization conflicts with regularity and fine granularity. That is, if the granularity of the clock is fine enough, synchronization will cause discernible irregularities in the rate of progress of the clock. Clock synchronization may require the local clock to jump forward or backward. Of these two, backward jumps are especially troublesome, since they can induce apparent ordering inversion if the clock happens to be used to determine the times of events immediately before and after a jump. However, an error in the measurement of an interval due to a forward jump can also be serious. A good synchronization method can reduce the impact of clock adjustments by several techniques. Backward jumps may be avoided by arranging to skip some ticks of the local time reference until the desired adjustment is reached. Discontinuities due to forward jumps and skipped ticks may be smoothed by splitting a large adjustment into several smaller adjustments, separated by intervals. Better, the size of adjustments may be kept small by frequent synchronization. Still, these techniques are limited. In less than ideal circumstances, one must anticipate that a synchronized clock may be available but not be able to deliver as fine a granularity, or as regular a rate of progress, as unsynchronized time references that may be available locally. Where Ada is implemented over an operating system, and so does not have direct access to time-keeping hardware circuits, it may be necessary to rely on the time-keeping services of the operating system. The operating system ultimately must rely on hardware devices similar to those described above, and it may or may not attempt to synchronize with other clocks; therefore, operating system time sources are subject to the same diversity of characteristics discussed above. In addition, they are subject to other limitations, including: * Inability to access the full accuracy of the hardware, due to timer- programming decisions made by the OS implementor. * Loss of accuracy as viewed by the user, due to system-call overhead. * Delay between expiration of a wake-up time and notification being delivered to a waiting process, due to system overhead. * Discontinuities, due to setting of the clock by a human operator or an unrelated application program. * Disparate views, due to "environment variables" specifying different time zones for different processes within a system. While these factors may affect the suitability of a particular operating system for a real-time application, they must be accepted as inherent limitations from the point of view of the Ada language. One is forced to assume that the time services provided by the OS have sufficient accuracy and low enough overhead to meet the needs of Ada applications on that system. For the purposes of this discussion, whatever time sources are provided by an operating system are presumed to have characteristics similar to one of the three basic types of clocks mentioned above. ==== A Single-Clock Model ==== In a real-time application, there may be requirements that cannot be satisfied by any single time source that is available. As explained above, the actual time-keeping resources available in a specific environment may have significant limitations, and the choice of time references may require that one thing be sacrificed for another. For example, fine granularity may mean sacrificing range or synchronization, greater range may mean sacrificing granularity, and synchronization may mean sacrificing the regularity or fine granularity, all at the cost of higher overhead. It follows that if all of these properties are important for a given application, a combination of different time references must be used. In some cases, it may be possible to provide a virtual interface that creates the illusion of a single time reference, using multiple time references in the implementation. For example, this is the case when a local timer is used to interpolate between points of synchronization with a remote clock. However, preserving this illusion is not always possible, or practical. In the extreme, there may be a fundamental conflict, as between steady tick rate and synchronization with an external reference. An implementation of a single-clock interface may be useless if it ends up exhibiting the same time anomalies such as sudden jumps, insufficient granularity, or insufficient accuracy. In this case, the promise of portability becomes a dangerous illusion. The Ada 83 Calendar package attempts to provide a single-clock interface. In order to ensure that it can be implemented in most execution environments, very little is specified about Calendar.Clock and, as mentioned, the predominant practice among existing implementations is to treat Calendar.Clock as political time. The values are likely not to be monotonic, and the resolution may be rather coarse. In effect, Calendar.Clock cannot be relied upon for measurement of "physical time" in real-time applications. ==== A Two-Clock Model ==== For the Real-Time Annex, we considered adding requirements to Calendar.Clock so that it would satisfy real-time requirements. For example, it could be required to be monotonic and have at least one millisecond precision. This idea was rejected. One reason is that the requirement for monotonicity might conflict with existing practice and other (non-real-time) requirements for a standard clock that returns local political time. A second reason is that requiring fine precision for Calendar.Clock might prevent an implementation from using hardware calendar-clock circuits. Thus Calendar.Clock is essentially as in Ada 83. In contrast, Real_Time.Clock is used for computations of physical parameters based on time, and scheduling of task execution to satisfy real-time constraints. The implementation must ensure that the value of the clock progresses monotonically, and that irregularities are strictly bounded. After the system starts, the clock is not allowed to be reset by an operator, the underlying operating system, or the run-time environment. Of course, there is no requirement for an implementation to have multiple clocks internally. The implementation may simply provide two package interfaces to a single underlying (monotonic) clock. The capability of supporting clock adjustments and seasonal time changes for Calendar.Clock is not mandated by the language, so the values of the two clocks could be the same. Moreover, where the application requires Calendar.Clock to do things that are incompatible with the specification of Real_Time.Clock, such as seasonal time changes and clock adjustments, the effect may be accomplished by computing a transformation of the value of Real_Time.Clock. It is in fact recommended that both Calendar.Clock and Real_Time.Clock be transformations of the same underlying timebase. The suggestion was made that a way might be provided for the application to modify the rate of the clock, so that the application could do clock synchronization, and do it in a way that would not compromise monotonicity. However, such a requirement would be applicable to only a small subset of applications, and the cost of providing the capability would be unwelcome for applications not needing it. In fact, for most existing general purpose processors, such a facility is not provided in the hardware, and providing it in software would introduce significant overhead in the clock driver. Alternatively, this capability, as well as the capability to do other low-level clock functions, is better provided by expecting the implementation to export the interface to its low-level clock driver in these systems, allowing it to be replaced by applications with special clock requirements. === <span id="8-3">D.8.3 Clock Accuracy Requirements</span> === The average clock tick given by the constant Real_Time.Tick is specified as not being larger than one millisecond. This number is conservative in the direction of not imposing extreme requirements on implementors, and seems adequate for the task scheduling needs of many real-time applications. Finer clock resolution is recommended. === <span id="8-4">D.8.4 Relationship to Delays</span> === The requirement that Real_Time.Clock be consistent with the effect of delay statements may be problematic for some implementations, but the conceptual consistency is seen as outweighing the implementation difficulty. One problem is that the range of times measurable directly by the available counter-timer circuit may be very narrow. In this case, the clock may need to be implemented in two parts. The low-order part may be decremented by every tick of the hardware timer, and the high- order part may be incremented by an interrupt handler that is driven by underflow of the timer. Another possible problem is that a separate timer circuit may be used for delays. It is desirable to utilize one timer to implement the real-time clock, using the simple treatment of timer underflow explained above, and to program another timer to generate an interrupt at the next point a delay is due to expire. However, in this case, since the delay timer is used only to express offsets from the clock, any difference between the two timers may not be noticeable. === <span id="8-5">D.8.5 Representation of Duration, Time_Span, and Real_Time.Time</span> === The Time_Span type is introduced to allow more precise representation of durations. A new type is introduced because the need for upward compatibility rules out changes to the range requirement for Standard.Duration. ==== Requirements and Representation ==== Lack of sufficient precision is one of the issues with the Calendar package and delay statements in Ada 83. The Duration type is required to be able to represent a full day, in the positive or negative direction. The hardware arithmetic on many machines today is limited to 32 bits. If Duration values are represented with 32 bits, then Duration'Small cannot be smaller than 2.0**(-14) seconds. This is coarser than the resolution of timer circuits. If the resolution of the timer is not exactly equal to an integer multiple (or divisor) of Duration'Small, additional precision can be lost in conversion. For example, suppose the clock is implemented using a timer with microsecond resolution, and the difference of two clock values is 100 microseconds. If Duration'Small is 2.0**(- 14), the nearest Duration value to 100 microseconds is 2*Duration'Small, or about 122 microseconds. Conversion to Duration in this example has introduced an error of 22 percent! The required minimum range and precision of Time_Span represent a compromise, given the assumption that the value should be representable in 32 bits. Originally, we required that Time_Span_Unit be equivalent to at most one microsecond and the range, equivalent to at least -2.0 .. 2.0 seconds. These requirements would still allow for a nanosecond representation in 32 bits (for example, the real-time extensions to POSIX specify nanosecond precision for timers). On the other hand, it would allow a range of up to an hour (with one microsecond precision). However, reviewers have commented that a portable range of -2.0 .. 2.0 is too small to be useful. We have changed the requirements so that a minimum resolution of twenty microseconds, and a minimum range of +/- one hour are mandated. This compromise still allows for "spare" bits in each direction, so that implementations, using 32 bits, can still have some flexibility in responding to stricter application needs without violating the range or precision requirements. Of course, this freedom sacrifices portability for users who require a greater range or finer precision than these minimum specifications. It is expected that in many implementations, the representation of Time_Span will use 64 bits (just as for the type Time). Since this type is private, such an implementation approach will not require 64-bit arithmetic in general. Since these requirements are based on a 32-bit machine architecture, for machines with a smaller word size, we have provided an escape clause in the form of an implementation permission. For example, some machines have only 24-bit words with no easy way to manipulate double-words. If we want to maintain the model of one word for Time_Span and two for Time, we must relax the range/accuracy requirements. On the other hand, a 16- bit machine such as the 1750A, which has built-in double-word operations, can easily use one double-word for Time_Span and two double-words for Time, and thus meet the requirements. The possibility was also considered of having Time_Span as a visible integer type, which could be a count of ticks. This is appealing, since clocks count time in ticks, and arithmetic on real numbers tends to introduce unnecessary loss of accuracy. Under the Ada 83 rules, the multiplication and division operations on fixed point types require much greater precision than for integer types of the same size. Moreover, real-time systems often involve computations in which time is viewed as cyclic. Such computations are naturally expressed in terms of the integer division and rem operations, rather than fixed point operations. This idea was discarded because there was a potential for confusion arising from different units for logically similar types. For example, the assignment statements in <syntaxhighlight lang="Ada"> T: Time_Span; ... T := T + 3 -- add 3 ticks to T ... T := T + 3.0; -- add three seconds duration to T</syntaxhighlight> would have a vastly different meaning and yet both be allowed because both relevant overloadings of the "+" operator would exist. The concept of a Time_Unit is introduced to ensure that the choice of representations for Time and Time_Span do not cause loss of information in time arithmetic. That is, the value obtained by subtracting two Time values should be exactly representable as a Time_Span, and adding a Time_Span value to a Time value should yield an exact Time value. This is the origin of the requirement that Time_Span_Unit be equal to Time_Unit. ==== Fixed point Issues ==== An alternative considered was to replace both Time and Time_Span by a single (64-bit) fixed point type. This would have simplified the interface and allowed a full range of user needs to be met. However, we concluded that supporting fixed point arithmetic on 64 bits would have been an unreasonable requirement to impose on all real-time implementations. Moreover, users who do not require extreme range or precision would have suffered from the overhead of arithmetic operations on objects of such a type. Finally, the requirements for accuracy and determinism on these types would have disturbed the general model of fixed point types in the core too much. Some of the needed changes would have been in direct conflict to the changes needed to support decimal types. Also, they would have been upward incompatible and too much of an implementation burden. Below, we provide more details about this alternative and related issues. === <span id="8-6">D.8.6 Arithmetic and Relational Operators</span> === In Ada 83 [RM83 9.6(5)], nothing is specified about the semantics of arithmetic and relational operators on times and durations except that the operations "have the conventional meaning". One of the objectives of this Annex is to give a more precise specification. Several approaches were considered. One of these is to specify a representation for Time, and then define the effects of the operations in terms of the representation. Possibilities considered included: a two-part record, analogous to the POSIX "timespec" type (a two-part record, consisting of a signed integer count of seconds and an unsigned integer count of nanoseconds); a very long integer type; and a very long fixed point type. This approach was rejected on the grounds that it would not allow the natural implementation for a wide enough variety of machines and operating systems. On the assumption that Time must be a private type, the possibility of providing an axiomatic specification of time arithmetic was considered. This approach was rejected on the grounds that it is inconsistent with the style of the rest of the Ada language definition. The present approach draws on analogy to the definition of arithmetic on integer types. In addition, for the conversion functions, rounding is specified (away from zero) to ensure deterministic results. Another possibility considered was of specifying that the time values are unsigned integers. As such, there is no overflow or underflow, and arithmetic is modular. One unfortunate aspect of using modular arithmetic for time is that the relational operations must be used with great care. For example, on a 12-hour clock it is not possible to say whether eleven o'clock is earlier or later than one o'clock, without further information. Because of this potential for confusion, the idea of arithmetic on time values being modular was dropped. This means that the Time type cannot be practically represented in 32 bits. If Time is going to take 64 bits, there is no problem representing a large range. A 32-bit signed count of seconds can represent a range of about 136 years. The requirement for a range of 50 years has been chosen because it is well within this range, and appears more than adequate to handle the continuous running time of most real-time systems. The operations Nanoseconds, Microseconds, and Milliseconds construct values of the type Time_Span. We considered having constants for one nanosecond, one microsecond, etc. However, the possibility that such real time values might not be representable accurately as Time_Span values, when using the constants to convert multiples of these values, leads to the danger of introducing cumulative errors. For example, if one wants to have a value of Time_Span equal to five milliseconds, calling Milliseconds(5) will return a more accurate result than doing 5*One_Millisecond, where One_Millisecond is a constant of Time_Span representing one millisecond. Using Milliseconds, one can convert up to almost 25 days worth of milliseconds (assuming a 32-bit implementation of Integer). This range seems large enough for this purpose, so a function that takes seconds as a parameter is not provided. === <span id="8-7">D.8.7 Other Issues</span> === In order to allow direct mapping of Real_Time.Time onto the most natural time reference that is available for a particular implementation, it is not required that there be any fixed correspondence between time values and specific real-time intervals. For example, Real_Time.Time could be a simple count of ticks since the clock was started. Given a fixed size representation of time values, this gives the widest possible range of values in the direction of interest, which is forward from the time of system start-up. It is also easy to implement, since there is no requirement for synchronization to obtain the initial clock value. In a model with this degree of implementation freedom, it is difficult to specify meaningful counterparts of Calendar.Split and Calendar.Time_Of. In this context, Split and Time_Of are likely to be used as a communication means to the outside world (since both Time and Time_Span are private). Examples include constructing a (local) time value from information read from a network, and logging event times in a readable format. Two possible approaches were considered. One approach was to provide functions for conversion between Real_Time.Time and Calendar.Time. The Split and Time_Of operations on Calendar.Time could then be used. The other approach was to define Time_Of and Split as operations that would convert a Time value into a seconds value and Duration part, or construct a Time value from these values. The seconds value would then be interpreted as an extended duration since clock start-up. Both of these approaches could be implemented, within some degree of tolerance for error, if the implementation reads both Real_Time.Clock and Calendar.Clock at the time of system start-up to establish a common reference point. The second approach, with a slight variation, was chosen for two reasons. First, it does not seem appropriate to require applications to include the package Calendar, just for this I/O purpose, if it is not needed otherwise (as is often the case). Second, as was discussed above, the package Calendar allows for certain implementation-defined behavior; it is not clear that the operations of this package will always be capable of serving as a transparent filter, one that provides the appropriate range and accuracy needed by the Real_Time.Time type representation. Accordingly, an integer type, Seconds_Count, is introduced. It represents the elapsed time from the epoch (the origin point) in seconds. (Since the epoch of the time is not specified by this Annex, the meaning of the Seconds parameter has to be interpreted based on implementation and application conventions.) A seconds representation was chosen based on range considerations. Even a 32 bit representation is enough to hold 50 years. Seconds_Count is a signed integer since the Annex does not specify that Time_First equals the epoch. In fact, it is legal to have the epoch defined somewhere in the future, and have Time values as negative offsets from that point. Hence, Seconds_Count should be able to hold both positive and negative values. For the fraction part, we had originally chosen the type Duration (as opposed to Time_Span). This was done in light of the fact that the primary purpose of the Split and Time_Of operation is communication with the outside world. A visible and printable type is much more convenient in this case. However, some reviewers commented that by doing so we introduce the possibility of an error "at the source", and that Time_Span should be used instead of Duration as the parameter for these operations. Since there exist other conversion routines that return a Duration value, and since the suggestion seemed to provide more flexibility, it was accepted. ==== Metrics ==== The intent of the upper bounds on clock ticks and clock jumps is to quantify the maximum fine-grain clock variation that can be expected. The upper bound on clock drift rate is intended to provide an estimate of the long-term accuracy of the clock. The upper bound on the execution time of a call to the Clock function is intended to expose implementations where reading the clock is extremely time-consuming. This might be the case, for example, where the clock function involves an operating system call, which involves context switches in and out from the operating system kernel. The reason for the metric on time arithmetic is to expose extremely inefficient time representations. For example, this is likely to expose the difference between an implementation based on a record containing years, months, days, etc. and an implementation based on a 64-bit count of clock ticks. Not all of these metrics are intended to be testable by pure Ada benchmark programs, such as the PIWG performance tests. That measurement technique is inherently limited, especially by the accuracy and precision of the software clock. Instead, it is intended that an external timing instrument, such as a logic analyzer, plus some knowledge of the implementation, may be needed to obtain the values of some metrics. In particular, this applies to measurements of the accuracy of the clock itself. Benchmark programs that rely on the internal clock for a time reference are inherently incapable of measuring the behavior of the clock itself. Moreover, for fine measurements such programs must settle for average execution times, since they must perform many iterations before they can accumulate enough execution time that is measurable on the internal clock. Thus, benchmarks are intrinsically incapable of deriving worst-case bounds for short execution times. == <span id="9">D.9 Delay Accuracy</span> == Real-time applications require that a task of sufficiently high priority be able to delay itself for a period of time with the assurance that it will resume execution immediately when the delay expires - i.e. that the duration of the interval between the start of the delay and the time the task resumes execution must be equal to the requested duration, within a predictable tolerance. [RM95 9.6] only requires that execution of the task that executes the delay be blocked for at least the duration specified. It is not in general possible to require an upper bound on the duration of the execution of any statement, due to possible interleaved operations of other tasks on the same processor. However, it is both possible and necessary to have an upper bound on the duration of the interval between the start of a delay and the time the expiration of the delay is detected. It is also possible to guarantee that if the task whose delay has expired has higher priority than all the other tasks it will resume execution as soon as the expiration of the delay is detected. This section of the Annex tightens the core requirements on the implementation of delays, and requires documentation of implementation characteristics. These tighter semantics also apply to uses of delay statements within select statements. These tighter semantics will permit better prediction of application timing behavior. ==== Coordination with Real_Time.Clock ==== An important reason for a language to provide a standard clock is to present a view of time that is coordinated with the implementation of the delay statement. Without such coordination, the utility of both delays and the clock is significantly diminished. The measurement of delays relative to a time reference that may be reset or adjusted (i.e. the time-of-day/calendar clock) is unacceptable, due to possible anomalies. In general, it may be necessary to adjust the calendar clock, for such things as leap-seconds or time zones. Maintaining a relationship between the actual delay duration and the time, relative to such a non-continuous clock, would make delays useless for most hard real-time applications, and would impose extra complexity on the delay implementation. The specific requirements in this section for coordination with Real_Time.Clock are minimal, since a delay statement is only required to delay a task for "at least" a specified time. However, taken together, the metrics on delay accuracy and clock accuracy permit a user to determine more precisely how well coordinated delays are with Real_Time.Clock. We also considered specifying a relationship between the clock resolution and the delay resolution. It is not reasonable to require that the delay resolution be at least as fine as that of the clock itself. The internal resolution can have very fine granularity if it is implemented via a hardware timer, much finer than the overhead of setting up a delay or reading the clock. If a periodic timer-generated interrupt is used to check for delay expirations, the interval between interrupts must be kept long enough to get useful work done; this limits delay granularity. If delay expirations are implemented via a programmed- interval timer, delay accuracy is limited by the overhead of receiving an interrupt and reprogramming the timer. It is possible to achieve finer granularity (without blocking) via execution of a timed sequence of "idle" instructions. This may provide delay resolution below the level of granularity achievable by a timer, provided the task is able to execute without preemption. Otherwise, if the task is preempted, it may delay longer than desired. To remain accurate in the face of preemption, the task could loop, reading the clock and comparing the clock value against the desired wake-up time; in this case, the precision is limited by the time it takes to execute an iteration of this loop. Of course, such busy-waiting techniques would not be sensible where delays are used within select statements, if the task is waiting for a rendezvous with a task that must execute on the same processor. It is not reasonable to require that the clock resolution be at least as fine as the delay resolution, either, since this could rule out the high-resolution delay implementation techniques described above. ==== Uniform Behavior Near Zero ==== A problem with timed entry calls was pointed out by the Third International Workshop on Real-Time Ada Issues [Baker 89]. Suppose the requested delay duration is a variable, and consider the effect of the timed entry call as the requested duration approaches zero from above. For large positive requests, an attempt will be made to perform a rendezvous. For small enough positive requests, an implementation is permitted to not make any attempt to rendezvous, on the presumption that simply determining whether a rendezvous is possible will take longer than the requested delay. The effect is that for small positive requests there will certainly be no rendezvous, and the total execution time of the timed entry call will be short. Then, as the requested delay approaches zero, the semantics change abruptly, back to what they would be for large positive requests (this is because of the conditional entry call semantics as specified in [RM95 9.7.2, 9.7.3]). The implementation must check whether a rendezvous is possible. This may take a long time. There is again a possibility of rendezvous, and the execution time of the timed call will be longer than it is for requests with small positive delays. An implementation that conforms to this Annex should avoid this anomalous behavior for small positive values, by always attempting to make a rendezvous (even if the requested duration is very short). Similar issues come up with timed entry calls using the absolute form of the delay statement, and for delay alternatives in selective accept and asynchronous select statements. However, for asynchronous select statements, the required behavior is modelled after the case where an entry call replaces the delay statement. In this situation, if the entry call can proceed immediately, the abortable part never starts. Similarly, when the delay amount is zero, the alternative is chosen, and the abortable part does not start. ==== An Alternative Proposal ==== The Third International Workshop on Real-Time Ada Issues proposed a more detailed accuracy model for delays [Baker 89]. One possibility that we considered was to incorporate this approach into the implementation requirements. This proposal has not been adopted, because it is expressed in terms of events in the implementation that are not directly visible to the user, and it was believed to be too complex. ==== Documentation Requirements ==== The implementation is required to document the thresholds that it uses to determine whether a delay statement will result in the blocking of the task. ==== Metrics ==== The specifications given here are intended to allow enough flexibility that they can be applied to a variety of different implementation techniques. The upper bound on the execution time of a relative delay statement with zero duration, and the execution time of an absolute delay whose wake-up time has already arrived, are intended to give the user an approximate idea of the minimum execution time overhead of the statement, excluding blocking. The upper bounds on the lateness of delay statements are intended to give the user an idea of the accuracy with which delays are implemented. As with other upper bounds, its mere existence is actually more important than the precise value of the bound. It is understood that these metrics will not expose the full implementation behavior. For example, if busy-wait delays are used for short durations, the granularity there may be much finer than further up the scale. The present metric ignores this issue. Likewise, if the hardware timer has limited range, a timer-task might be used for delays outside this range. Thus, there might be another shift in granularity farther out. The metrics chosen here do not require the implementor to expose such details. However, the implementor is free to provide more detailed information, by expressing the bound as a function of the requested delay. == <span id="10">D.10 Synchronous Task Control</span> == During the 9X revision, the term suspension was replaced with blocking since it was considered to better describe the actual state (i.e. waiting for something to happen - being blocked as opposed to just being suspended). We recognize that traditionally suspend and resume were the common terms used when discussing these primitives. In this and the following section, we use the term blocked when referring to the "official" Ada state, and the term suspended when referring to the generic capability. An important goal for Ada 95 was to allow protected objects for a simple suspend/resume mechanism that in turn could be used to build higher-level synchronization primitives. Here, by suspend, we mean the ability to block only the calling task itself, not another (for the latter, see the next section). Even for such a simple mechanism, some guarantees have to be made. This is commonly known as the two-stage suspend problem. (Strictly speaking, this name refers more to the solution, rather to the problem itself.) The problem that needs to be solved can be briefly described as follows. A task may want to block itself, after it has checked some data structure, and found that a particular system state is not present yet. The data structure is used by other tasks as well. One of these tasks will eventually set the data structure to the appropriate state and will resume the blocked task. Therefore, this data structure must be protected from concurrent access, i.e. a lock is needed. This in turn leads to the requirement that a task will be able to atomically release the lock and block itself. If it first releases the lock, the state might change just before it is about to be blocked (for example, the desired state may now be present, but there will be no way to detect it). On the other hand, if the task is blocked while still holding the lock, another task will not be able to access the shared data structure, and to record the new state - a deadlock. If the state that is being waited upon can be easily expressed using a protected entry barrier expression, then such functionality already exists in the language. However, this is not always the case. When user-defined schedulers or servers are being implemented, it is often much more natural to separate the blocked state (and the corresponding operations) from the actual reason the task is waiting (it might be waiting for multiple events). There are several approaches to solve this problem. They all depend on the kinds of primitives the underlying system provides. # Allow the calling task to suspend while it still holds the lock. When the task is suspended, it loses the lock, and has to reacquire it when it wakes up. # Register a pending suspension request while still holding the lock. After the task releases the lock (presumably soon after registering the request), it will be suspended. # Atomically clear a bit in the user space marking the suspension intention, and then suspend waiting for the bit to be set. A task wishing to resume the suspended task does so by atomically setting the bit. If the protocol of manipulating this bit is well- coordinated, such a technique can work safely and efficiently. It is beyond the scope of this discussion to analyze the trade-offs of the approaches described above. For Ada 95, we have chosen the third approach mainly for its simplicity and the fact that it does not require any changes to the semantics of protected types and does not have complex interactions with other existing semantics. Here, the two-stage suspend means that first the task announces its intention to suspend itself, and then it actually does so. Between these two operations, the task is logically suspended as viewed by other tasks in the system, and so they may reliably resume it even before the actual suspension is done. For example, it would be wrong for the suspending task to clear the bit again without first checking its state to ensure that no other task has resumed it in the meantime. Failing to do so will effectively result in losing the resume operation. Originally, we proposed to express the needed functionality as visible operations of a language-defined protected type. The abstraction presented by a simple protected type with Set_True and Set_False operations and a Suspend_Until_True entry, in addition to one boolean flag, seemed appropriate. Having this type known to the implementation would ensure that optimization was straightforward. We rejected this idea for two reasons: a procedural interface enables the implementation to choose the most efficient technique by isolating this feature from the general support of the protected types. Second, by not having a visible protected entry for the Suspend_Until_True operation, the user is not able to use it in a select statement. While this may be considered as a loss of functionality, it has not been demonstrated that such functionality (timed, conditional, and asynchronous waits) is needed with such a low-level primitive. Not having to support the various kinds of select statements allows a much simpler, and hence, more efficient implementation. The chosen solution is thus to make the suspension object of a private type with the operations described above (that is, Set_True, Set_False, and Suspend_Until_True). In addition, we provide a function Current_State to query the state of the object. This function should be used with care since the state may change asynchronously, and in particular, immediately after the function returns. We considered providing additional operations, to atomically change the state of the object and to return its previous state. We did not provide these operations since they really do not belong to this abstraction and we could not find a practical use for them; they were unreliable and they required an extra locking mechanism inside the implementation. This locking would be required when Set_False and Set_True (both with a return parameter) were called at the same time. A suspension object can be viewed as a private binary semaphore in that it can be assumed to belong to one task only. This assumption is not enforced by the language, but a check is provided that only one task may wait on such an object at any point in time, Program_Error being raised if it fails. This rule makes it unnecessary to maintain a queue - a major saving in run-time cost. A suspension object (or a pointer to it) can be passed to other components, thus indirectly maintaining the identity of the task that needs to be resumed when a certain state becomes true. A typical example of the use of suspension objects is as follows <syntaxhighlight lang="Ada"> -- Assume that the protected object state -- contains just a simple (protected) indication of the state; -- the rest is elsewhere. use Ada.Synchronous_Task_Control; type Token is access all Suspension_Object; protected State is procedure Check(T : in Token; Result : out Boolean); procedure Set(D : in Some_Data_Structure); private Data : Some_State_Structure; Waiting_Task : Token; end State; protected body State is procedure Check(T : in Token; Result : out Boolean) is begin if Data = Desired_State then Result := True; else -- Mark intention to suspend Set_False(T.all); Waiting_Task := T; Result := False; end if; end Check; procedure Set(D : in Some_Data_Structure) is begin Data := D; if Data = Desired_State then if Waiting_Task /= null then -- Resume waiting task Set_True(Waiting_Task.all); end if; end if; end Set; end State; -- Task wishing to suspend task body T1 is SO : aliased Suspension_Object; In_Desired_State : Boolean; begin State.Check(SO'Unchecked_Access, In_Desired_State); if In_Desired_State then process-data else Suspend_Until_True(SO); -- suspend end if; ... end T1; -- Another task detects that the waiting task needs -- to be resumed task body T2 is Data : Some_Data_Structure; begin State.Set(Data); end T2;</syntaxhighlight> When Check is called by T1, the state is checked. If it is possible to continue, T1 does so and processes the data. Otherwise, T1 suspends itself until the object becomes true. When T2 updates a new state, it checks to see if the updated state is a desired one. If it is, and a task is waiting, it is resumed (Set_True). The new state is saved, so when T1 checks again, it will not have to be suspended. The important thing to remember is that it makes no difference whether the Set_True is called before or after the Suspend_Until_True. Since the semantics of suspension objects are defined to be persistent in the sense that there is a bit to keep the state, the suspending task will always notice the resume request. == <span id="12">D.11 Asynchronous Task Control</span> == An important facility for some real-time aplications is a very low-level, simple, and efficient capability to suspend the execution of another task (and resume it later). The core part of Ada 95 intentionally omitted this capability because of the well-known problems with integrating such a feature into a multi- tasking environment. The asynchronous transfer of control is the feature that comes closest to this requirement, but it is not the full answer; it requires cooperation of the "to-be-suspended" task, and does not allow the continuation of the affected task from exactly the same point where it was interrupted. There are very good reasons for these limitations in the general case. Suspending a task asynchronously at an arbitrary point is likely to leave the system state in an inconsistent state. This state would then become visible to the remaining tasks in the system. In addition, the interaction of such suspension with the other blocking primitives of the language is quite problematic (particularly, when priority scheduling is in effect). In practice, two choices exist. One is to define the complete semantic model of such a feature and how it interacts with the rest of the language. Such a model would then require additions to the core and was believed to be very complex to understand and implement, especially for those users that do not need this capability. The other option is to leave all these interactions as implementation-defined. This is obviously undesirable since many of the benefits of standardizing such a capability would be lost. In addition, using such features is likely to move the program into the "erroneous zone", since the semantic model of tasking would not apply. Finally, and probably due to the above, experience with such primitives has proven in the past to be quite error- prone. However, for a certain class of applications, such a capability is considered essential. These applications can be characterized as small, time-critical, and often safety-critical. They usually do not use the full power of the language, especially its tasking model. For certification reasons, as much as possible of the code needs to be visible in the actual program as opposed to be "hidden" inside the run- time system support supplied by the vendor. So even though this capability by itself may be considered unsafe, using it on top of a very simple run-time system, and applying strict guidelines, can make a system easier to certify. A final argument in favor of adding such a capability is that within certain application domains, this paradigm is well- understood, has been heavily used in the past, and is known to be implementable efficiently. Note that the issue of feature interaction with the rest of the tasking primitives is less of a concern here, since most of these primitives are not likely to be used by such an application. Existing capabilities in the language and annexes allow a task to block itself until a specified state becomes true. This is not the same as a capability to asynchronously suspend another task. Because of this difference, the problems mentioned above, and issues concerning the best way to define such a feature in Ada, the straightforward approach of just defining a Suspend_Other primitive was rejected. Such an approach would necessitate introducing another task state ("suspended"), in addition to the existing states, and defining all the necessary interactions. Instead, the approach taken by this Annex is based on the observation that a "suspend-other" capability is quite similar to the capability to lower a task's priority to a value that is so low as to effectively prevent the task from being dispatched. (In fact, using dynamic priorities is a known workaround to this problem, but it does not scale well to multiprocessors.) The package Asynchronous_Task_Control introduces a conceptual idle task for each processor in the system, in addition to a priority level which is so low as to be below any other task in the system including the idle task. This level is also conceptual; it need not actually exist as a separate level in the ready queue. The Hold procedure is defined in terms of sources of priority inheritance. The general model of priority inheritance as defined in [RM95 D.3] states that the task's own base priority is always a source of priority inheritance. However, when the task is being held, its own base priority is no longer such a source, and instead the value of the special priority level becomes such a source. For reasons similar to those discussed in D.10, we do not want to stop the task's execution while it is inside a protected action. With this approach, a held task will still inherit the ceiling priority of the protected object in which it is executing, and will therefore continue to run until it leaves the protected action. When the task does not inherit any other priority, its active priority becomes lower than the conceptual task; therefore it does not run. The Continue operation simply changes the inheritance sources back to the default. The benefit of this approach is that nothing else has to be said with respect to interactions with other tasking constructs. All the rules are ramifications of the above definitions and the general priority rules. (For a more detailed analysis of the various cases, see the notes in [RM95 D.11].) In this way, no additional mechanism is needed in the run- time system, and the feature can be implemented efficiently while still presenting a consistent and safe interface to the user. For implementation flexibility, nothing in this section really requires the use of dynamic priorities inside the implementation; priorities are used just to describe the semantic model. A straightforward implementation approach that uses traditional states is therefore possible. == <span id="12">D.12 Other Optimization and Determinism Rules</span> == This section of the Annex describes various requirements for improving the response and determinism in a real-time system. The maximum duration that interrupts are blocked by the implementation (in supporting the language features) must be bounded and documented. Clearly, this value is very important to the application for schedulability analysis. In addition, a real-time application often needs to interact with an external device at a certain frequency. If the implementation-induced interrupt blocking time is too long, such a device interface is not feasible. Another requirement addresses the problem of the storage associated with terminated tasks. In a real-time system, tasks are often allocated using a library-level access type, and their storage is sometimes released only upon exit from the access type's scope. In this case, this will mean not until the partition as a whole terminates, which is clearly too late. Ada 83 did not require Unchecked_Deallocation of tasks to actually release the task's storage, and this is the motivation for the new requirement. When a protected object does not have entries, it acts similarly to a simple lock (mutex) abstraction with no need for any overhead associated with checking barriers and servicing queues. It is expected that such protected objects will be used heavily by concurrent applications to achieve simple mutual exclusion. It is therefore important that implementations will recognize such cases, and avoid any unnecessary run- time costs. In general, performance can be neither legislated nor validated; the purpose of the requirement is to direct the attention of implementors to this important case. The corresponding metrics are provided for the purpose of exposing the degree to which such an optimization is carried out in a given implementation. == <span id="13">D.13 Requirements Summary</span> == The requirements * R5.1-A(1) - Elapsed Time Measurement * R5.1-B(1) - Precise Periodic Execution are met by the introduction of Real_Time.Time and the precise requirements on the delay statement. The requirement * R5.2-A(1) - Alternative Scheduling Algorithms is generally addressed by the various pragmas such as Task_Dispatching_Policy, Locking_Policy and Queueing_Policy plus the facilities for priority control. The packages for synchronous and asynchronous task control provide facilities for special techniques. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p3-c|Previous]] | [[Guide:9x_rationale/rat95-p3-e|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=Annex D. Real-Time Systems}} 5i0zucngtfamvpmlmgo46lv62yfuvsx Guide:9x rationale/rat95-p3-e 4200 349 1874 1777 2019-04-20T16:20:44Z WikiVisor 11 Text replacement - "[[Guide:9x_rationale/rat95-copyright|Copyright]] | " to "<div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | " wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p3-d|Previous]] | [[Guide:9x_rationale/rat95-p3-f|Next]] The Ada 95 model for programming distributed systems specifies a partition as the unit of distribution. A partition comprises an aggregation of library units that executes in a distributed target execution environment. Typically, each partition corresponds to a single execution site, and all its constituent units occupy the same logical address space. The principal interface between partitions is one or more package specifications. The semantic model specifies rules for partition composition, elaboration, execution, and interpartition communication. Support for the configuration of partitions to the target execution environment and its associated communication connectivity is not explicitly specified in the model. The rationale for this model derives from the Ada 9X Requirements for Distributed Processing (see R8.1-A(1) and R8.2-A(1)); namely, that the language shall facilitate the distribution and dynamic reconfiguration of Ada applications across a homogeneous distributed architecture. These requirements are satisfied by a blend of implementor- and user-provided (or third-party) capabilities. In addition, the following properties are considered essential to specifying a model for distributed program execution: * The differences between developing a distributed versus a nondistributed system should be minimal. In particular, the same paradigms, rules for type safety, and interface consistency for a nondistributed system should apply to a distributed system. Furthermore, it must be possible to partition an Ada library for varying distributed configurations without recompilation. * The implementation should be straightforward. In particular, the run-time system of each partition should be autonomous. In this way, robust type-safe distributed systems can be implemented using off-the-shelf Ada compilers that support the model, rather than depending upon custom adaptations of a compiler to a specific distributed environment. * The partitioning should be separated from the details of the communications network architecture supporting the distributed system. Similarly, inter-partition communication should avoid specifying protocols more appropriately provided by an application or by standard layers of the network communications software. * The model should facilitate programming fault-tolerant applications to the extent that an active partition failure should not cause the distributed program to fail. In particular, it should be possible to replace the services provided by a failed partition with those of a replacement partition. * The model should be compatible with other standards that support open distributed applications. The requirements and properties are satisfied in the Annex by specifying a simple, consistent, and systematic approach towards composing distributed systems based upon the partition concept. Partitions are specified before runtime, usually during or after the linking step. Programming the cooperation among partitions is achieved by library units defined to allow access to data and subprograms in different partitions. These library units are identified at compile-time by categorization pragmas. In this way, strong typing and unit consistency is maintained across a distributed system. Finally, separation of implementor and user responsibility is allowed by specifying a common interface to a partition communication subsystem (PCS) that performs message passing among partitions. The PCS is internally responsible for all routing decisions, low-level message protocols, etc. By separating the responsibilities, an implementation need not be aware of the specific network connectivity supporting the distributed system, while the communication subsystem need not be aware of the types of data being exchanged. == <span id="1">E.1 The Partition Model</span> == An Ada 83 program corresponds to an Ada 95 active partition (see below); an Ada 95 program is defined in [RM95 10.2] as a set of one or more partitions. The description in the Core is kept purposefully non- specific to allow many different approaches to partitioning a distributed program, either statically or dynamically. In the Annex, certain minimal capabilities are specified to enhance portability of distributed systems across implementations that conform to these specifications. This Annex develops the partitioning concept for distributed systems in terms of active and passive partitions. The library units comprising an active partition reside and execute upon the same processing node. In contrast, library units comprising a passive partition reside at a storage node that is accessible to the processing nodes of different active partitions that reference them. Library units comprising a passive partition are restricted to ensure that no remote access (such as for data) is possible and that no thread of control is needed (since no processing capabilities are available and no tasking runtime system exists in such a partition). Thus, a passive partition provides a straightforward abstraction for representing an address space that is shared among different processing nodes (execution sites). It is implementation-defined (and must therefore be documented) whether or not more than one partition may be associated with one processing or storage node. The characteristics of these nodes are target dependent and are outside the scope of the Annex. Similar to an Ada 83 program, each active partition is associated with an environment task that elaborates the library units comprising the partition. This environment task calls the main subprogram, if present, for execution and then awaits the termination of all tasks that depend upon the library units of the partition. Therefore, there is no substantive difference between an active partition and an Ada 83 program. A partition is identified as either active or passive by the post- compilation (link-time) aggregation of library units. Post-compilation tools provide the necessary functionality for composing partitions, linking the library units of a partition, and for resolving the identities of other partitions. A passive partition may include only shared passive and pure library units. By naming a shared passive library unit (which resides in a passive partition) in a context clause, the referencing unit gains access to data and code that may be shared with other partitions. Different active partitions (executing on separate nodes) may thus share protected data or call subprograms declared in such shared passive library units. An active partition can obtain mutually exclusive access to data in a shared partition package if the data is encapsulated in a protected object or is specified as atomic. An active partition may call subprograms in other active partitions. Calls to subprograms in a different active partition are allowed only if the called subprogram is declared in a library unit with a Remote_Call_Interface pragma. Each active partition calling the subprogram must name the corresponding remote call interface (RCI) library unit in its context clause. So we might have <syntaxhighlight lang="Ada"> package A is -- in one active partition pragma Remote_Call_Interface(A); procedure P( ... ); ... end A; -------------- with A; package B is -- in another active partition ... A.P( ... ); -- a remote call ... end B;</syntaxhighlight> When an active partition calls such a subprogram, the call is termed a remote procedure call (RPC). Stubs are inserted in the calling code and in the called code to perform the remote communication; these are termed the calling stub and receiving stub respectively. In addition, an asynchronous procedure call capability is provided to allow the caller and the remote subprogram to execute independently once the call has been sent to the remote partition. The categorization of library units establishes potential interfaces through which the partitions of a distributed system may cooperate. In a distributed system where no remote subprogram calls or shared library units are required, e.g., all inter-partition data is exchanged through other communication facilities, library unit categorization is unnecessary. In such a case the multipartition program is similar to the multiprogramming approach allowed by Ada 83 (using a set of quite distinct programs). The library unit categorization and link-time identification of partitions provides a flexible and straightforward approach for partitioning the library units of an Ada program library. Library units may be aggregated to form partitions exploiting the target execution environment for the distributed system, with the single stipulation that any given shared passive or RCI library unit may be assigned to only one partition. Different distributed configurations of the same target execution environment may then be supported by a single version of an Ada library. (A change to the configuration does not require recompilation of library units.) Library units are elaborated and executed within the context of the environment task associated with the active partition, and until they communicate with another partition, their execution proceeds independently (since all the library units in a passive partition must be preelaborated, the environment task in such a partition is purely conceptual). The runtime system of each active partition is independent of all other runtime systems in a multi-partition program. This is achieved by first disallowing tasks and protected types with entries in the visible parts of the interface library units, and second, by declaring the library units Calendar and Real_Time, as well as the subtype Priority, as local to each active partition. In consequence, tasks (and hence entry queues) are not visible across partitions. This allows each active partition to manage its own tasking subsystem independently, avoiding such complexities as remote rendezvous, distributed time management, and distributed activation and termination management. (Protected objects without entries are allowed in passive partitions, since access to their data requires only a simple mutual-exclusion, a capability assumed to be present for a passive partition.) Mechanisms to specify the allocation of partitions to the target execution environment are not included in the Annex; similarly, the dynamic creation and replication of partitions is not explicitly specified. These capabilities are deemed beyond the scope of the requirements. However, because partition replication is essential towards programming fault-tolerant applications, remote calls may be directed to different partitions using one of the two forms of dynamic binding, by dereferencing an access-to-subprogram object or access-to- class-wide tagged object. Thus, implementations that support the replication of partitions can allow a failed partition to be replaced transparently to other partitions. In summary, this approach allows for flexible, link-time partitioning, with type-safety ensured at compile-time. The model separates categorization and partitioning from configuration and communication thus promoting compiler/linker independence from the target execution environment. The objective is to maintain the properties of a single Ada program for distributed execution with minimal additional semantic and implementation complexity. Fundamental to this objective is the ability to dynamically call remote subprograms. == <span id="2">E.2 Categorization of Library Units</span> == Several library unit categorization pragmas exist. They are <syntaxhighlight lang="Ada"> pragma Shared_Passive( ... ); pragma Remote_Types( ... ); pragma Remote_Call_Interface( ... );</syntaxhighlight> where in each case the optional parameter simply names the library unit. These pragmas identify library units used to access the types, data, and subprograms of other partitions. In other words, the library units that are associated with categorization pragmas provide the visible interface to the partitions to which they are assigned. These pragmas place specific restrictions upon the declarations that may appear in the visible part of the associated library units and the other library units that they may name in their context clauses. In addition, such library units are preelaborated. The pragma Pure, which is defined in the core since it also relates to preelaboration, is also important for distribution and has the most severe restrictions. The various categories form a hierarchy, in the order given above with Pure at the top. Each can only "with" units in its own or higher categories (although the bodies of the last two are not restricted). Thus a package marked as Shared_Passive can only with packages marked as Shared_Passive or Pure. Restricting the kinds of declarations that may be present in such library units simplifies the semantic model and reduces the need for additional checking when the library unit is named in the context clause of another library unit. For example, by disallowing task declarations (and protected types with entries), we avoid the interaction among the run-time systems of different partitions that is required to support entry calls across partitions. Pure library units [RM95 10.2.1] may be named in the context clauses of other interface library units. For example, a pure library unit may contain type declarations that are used in the formal parameter specifications of subprograms in RCI library units. To achieve remote dispatching, a library unit specified with pragma Pure must declare the corresponding dispatching operations. Such a library unit is replicated in all referencing partitions. The properties of a pure library unit allow it to be replicated consistently in any partition that references it, since it has no variable state that may alter its behavior. When no categorization pragma is associated with a library unit, such a unit is considered normal; it may be included in multiple active partitions with no restrictions on its visible part. Unlike a pure library unit, replication of such a unit in different partitions does not necessarily maintain a consistent state. The state of the unit in each partition is independent. === <span id="2-1">E.2.1 Shared Passive Library Units</span> === The rules for a shared passive library unit ensure that calling any of its subprograms from another partition cannot result in an implicit remote call, either directly or indirectly. Moreover, the restrictions eliminate the need for a run-time system (e.g., to support scheduling or real-time clocks) to be associated with a passive partition. Thus a passive partition corresponds to a logical address space that is common to all partitions that reference its constituent library units. As mentioned earlier, a shared passive unit must be preelaborable and can only depend on pure and other shared passive units. There are also restrictions on access type declarations which ensure that it is not possible to create an access value referring back to an active partition. === <span id="2-2">E.2.2 Remote Types Library Units</span> === Originally, this Annex provided only the Shared_Passive and Remote_Call_Interface pragmas (in addition to the core pragma Pure). However, this omitted an important functionality. Often one needs to be able to pass access values among partitions. Usually, such access values have no meaning outside their original partition (since their designated object is still in that partition). Hence we generally disallow access types for remote subprograms' formal parameters. However, there are cases in which the access type has a user-defined meaning (such as a handle to a system-wide resource) that can be "understood" in other partitions as well. Since the implementation is not aware of such a meaning, the user must supply specific Read and Write attributes to allow the meaningful transfer of the information embodied in such access values. In addition, such a library unit often needs to be able to maintain specific (per-partition) state, to support such conversions. This is the main reason for introducing the Remote_Types categorization pragma. The restrictions enforced by this pragma are quite similar to those enforced by pragma Pure; a separate copy of a remote types package is placed in every partition that references it. Since a remote types library unit may be withed by a remote call interface, the types declared in the former may be used as formals of remote subprograms. === <span id="2-3">E.2.3 Remote Call Interface Library Units</span> === For RCI library units the restrictions ensure that no remote accesses need be supported, other than remote procedure calls. These calls may be * direct, through static binding, * indirect, through a remote access to subprogram type, * dispatching, through a remote access to class wide type. Furthermore, the types of all formal parameters may be converted to and from a message stream type using the Write and Read attributes respectively [RM95 13.13.2]. This message stream type is the primary interface to the partition communication subsystem. Child library units of an RCI library unit must be assigned to the same partition as the RCI library unit. As a consequence, visible child library units of an RCI library unit have the same restrictions as RCI library units. That is, the private part and the body of a child library unit have visibility to the private part of the parent. Thus a child library unit, unless included in the same partition as its parent, may make an unsupported remote access to its parent's private part. By constraining a child to the same partition, its visible part must be as restricted as the root RCI library unit. The support for remote call interface library units is optional in the Annex, since RPC is not always the appropriate communication paradigm for a particular application. The other capabilities introduced by this Annex might still be useful in such a case. ==== Pragma All_Calls_Remote ==== For some applications, it is necessary that the partition communication subsystem get control on each remote procedure call. There are several motivations for such a requirement, including support for debugging (for example, isolating problems to either the PCS or to the generated code) and the need in some circumstances to have the PCS perform application- specific processing (e.g. supporting broadcasts) on each remote call. For such techniques to be feasible, users need to be assured that remote calls are never "optimized away". This can be assured by inserting <syntaxhighlight lang="Ada"> pragma All_Calls_Remote;</syntaxhighlight> in the unit concerned. Note that opportunities for such optimizations arise often, for example when the calling library unit and the called RCI library unit are assigned to the same active partition. In such cases, the linker can transform the remote call to a local call, thereby bypassing the stubs and the PCS. (In fact, such an optimization is extremely important in general, to allow the design of library units independent of their eventual location.) Similar optimization is possible (although probably not as straightforward) when multiple active partitions are configured on the same processing node. When a call on a subprogram declared in the visible part of an RCI library unit (usually a remote call) is generated from either the body of that library unit or from one of its children, it is always guaranteed to be local (regardless of the specific configuration). This is because the Annex rules ensure that all corresponding units end up in the same partition. For this reason, the All_Calls_Remote pragma does not apply to such calls, and they remain local. Doing otherwise would constitute a change of the program semantics (forcing a local call to be remote), would introduce implementation difficulties in treating otherwise normal procedure calls as special, and would introduce semantic difficulties in ensuring that such a local-turned-remote call did not violate the privacy rules that guarantee that remote references are not possible. == <span id="3">E.3 Consistency of a Distributed System</span> == Consistency is based on the concept of a version of a compilation unit. The exact meaning of version is necessarily implementation-defined, and might correspond to a compilation time stamp, or a closure over the source text revision stamps of all of the semantic dependences of the unit. == <span id="4">E.4 Remote Subprogram Calls</span> == RCI library units allow communication among partitions of a distributed system based upon extending the well-known remote procedure call (RPC) paradigm. This is consistent with the ISO RPC Committee Draft that presents a proposed RPC Interaction Model (see subsequent section) and Communication Model for cooperating applications in a distributed system. Calls to remote partitions may be bound either statically or dynamically. The task executing a synchronous remote call suspends until the call is completed. Remote calls are executed with at-most-once semantics (i.e., the called subprogram is executed at most once; if a successful response is returned, the called subprogram is executed exactly once). If an exception is raised in executing the body of a remote subprogram, the exception is propagated to the calling partition. Unless the pragma Asynchronous (see below) is associated with a procedure (for a direct call) or an access type (for an indirect call), the semantics of a call to a remote subprogram are nearly identical to the semantics of the same subprogram called locally. This allows users to develop a distributed program where a subprogram call and the called subprogram may be in the same or different partitions. The location of the subprogram body, determined when the program is partitioned, only affects performance. The exception System.RPC.Communication_Error may be raised by the PCS (the package System.RPC is the interface to the PCS). This exception allows the caller to provide a handler in response to the failure of a remote call as opposed to the result of executing the body of the remote subprogram; for example, if the partition containing the remote subprogram has become inaccessible or has terminated. This exception may be raised for both synchronous and asynchronous remote calls. For asynchronous calls, the exception is raised no later than when control would be returned normally to the caller; any failure after that point is invisible to the caller. === <span id="4-1">E.4.1 Pragma Asynchronous</span> === An asynchronous form of interaction among partitions is provided by associating the pragma Asynchronous with a procedure accessible through an RCI library unit. Thus using the previous example we might write <syntaxhighlight lang="Ada"> package A is pragma Remote_Call_Interface(A); procedure P( ... ); pragma Asynchronous(P); ... end A;</syntaxhighlight> When this pragma is present, a procedure call may return without awaiting the completion of the remote subprogram (the task in the calling partition is not suspended waiting the completion of the procedure). This extends the utility of the remote procedure call paradigm to exploit the underlying asynchronism that may be available through the PCS. As a consequence, synchronous and asynchronous interactions among partitions are maintained at a consistent level of abstraction; an agent task is not required to await the completion of a remote call when asynchronism is desired. Asynchronous procedure calls are necessarily restricted to procedures with all parameters of mode in (and of course a function cannot be asynchronous). Unhandled exceptions raised while executing an asynchronous remote procedure are not propagated to the calling partition but simply lost. When the call and called procedure are in the same partition, the normal synchronous call semantics apply. The use of asynchronous procedure calls, when combined with the capability to dynamically bind calls using remote access values, allows the programming of efficient communication paradigms. For example, an asynchronous procedure call may pass a remote access value designating a procedure (in the sending partition) to be called upon completion. In this way, the results of the asynchronous call may be returned in some application-specific way. == <span id="5">E.5 Post-Compilation Partitioning</span> == Aggregating library units into partitions of a distributed system is done after the units have been compiled. This post-compilation approach entails rules for constructing active and passive partitions. These rules ensure that a distributed system is semantically consistent with a nondistributed system comprising the same library units. Moreover, the required implementation is within the capability of current post- compilation tools. Therefore, in order to allow the use of existing tools and to avoid constraining future tools, the Annex omits specifying a particular method for constructing partitions. Each RCI library unit may only be assigned to a single active partition. Similarly, each shared passive library unit may only be assigned to a single passive partition. Following the assignment of a library unit to a partition, a value for the attribute Partition_ID is available that identifies the partition after it is elaborated. (This attribute corresponds to values of the type Partition_ID declared in System.RPC; see E.7. This library unit provides the interface to the PCS; however, it is not required that this unit be visible to the partition using the attribute and hence the attribute returns universal_integer.) In order to construct a partition, all RCI and shared passive library units must be explicitly assigned to a partition. Consequently, when a partition is elaborated, the Partition_ID attribute for each RCI or shared passive library unit referenced by this partition has a known value. The construction is completed by including in a partition all the other units that are needed for execution. An exception is that a shared passive library unit is included in one partition only. Similarly, the body of an RCI library unit is in one partition only; however the specification of an RCI library unit is included in each referencing partition (with the code for the body replaced by the calling stubs). A library unit that is neither an RCI nor shared passive library unit may be included in more than one partition. Unlike a nondistributed system, a normal library unit does not have a consistent state across all partitions. For example, the package Calendar does not synchronize the value returned by the Clock function among all partitions that include the package. A type declaration within the visible part of a library unit elaborated in multiple partitions yields matching types. For pure, RCI, and shared passive library units, this follows either from the rule requiring library unit preelaboration (RCI and shared passive) or the restrictions on their declarations. For normal library units, since non- tagged types are not visible across partitions, this matching is of little significance. However, a special check is performed when passing a parameter of a class-wide type to make sure that the tag identifies a specific type declared in a pure or shared passive library unit, or the visible part of a remote types or RCI library unit. Type extensions declared elsewhere (in the body of a remote types or RCI library unit, or anywhere in a normal library unit) might have a different structure in different partitions, because of dependence on partition-specific information. This check prevents passing parameters of such a type extension, to avoid erroneous execution due to a mismatch in representation between the sending and the receiving partition. An attempt to pass such a parameter to a remote subprogram will raise Program_Error at run-time. For example, consider the following declarations: <syntaxhighlight lang="Ada"> package Pure_Pkg is pragma Pure; type Root_Type is tagged ... ... end Pure_Pkg; with Pure_Pkg; package RCI_Pkg is pragma Remote_Call_Interface; -- Class-wide operation procedure Cw_OP(Cw : in Pure_Pkg.Root_Type'Class); end RCI_Pkg; with Pure_Pkg; package Normal_Pkg is ... type Specific_Type is new Pure_Pkg.Root_Type with record Vector : Vector_Type(1 .. Dynamic_Value); end record; end Normal_Pkg; with RCI_Pkg; package body Normal_Pkg is Value : Specific_Type; begin -- The following call will result in Program_Error -- when the subprogram body is executed remotely. RCI_Pkg.Cw_OP(Cw => Value); end Normal_Pkg;</syntaxhighlight> In the above example, if Normal_Pkg is included in a partition that is not assigned RCI_Pkg, then a call to Cw_OP will result in a remote call. When this call is executed in the remote partition, Program_Error is raised. The following library units are a simple example of a distributed system that illustrate the post-compilation partitioning approach. In this particular example, the system uses mailboxes to exchange data among its partitions. Each partition determines the mailbox of its cooperating partitions by calling a subprogram specified in an RCI library unit. The mailboxes for each partition are represented as protected types. Objects of the protected types are allocated in a shared passive library unit. RCI library units (instantiations of Gen_Mbx_Pkg) are included in active partitions, and they with the shared passive package Ptr_Mbx_Pkg. When an allocator for Ptr_Safe_Mbox is executed (on behalf of a library unit in another partition), the protected object is allocated in the passive partition, making it accessible to other partitions. Consequently, no remote access is required to use mailbox data. However, to access a mailbox of another partition, a remote subprogram call is required initially. <syntaxhighlight lang="Ada"> package Mbx_Pkg is pragma Pure; type Msg_Type is ... type Msg_Array is array (Positive range <>) of Msg_Type; type Key_Type is new Integer; protected type Safe_Mbx(Lock : Key_Type; Size : Positive) is procedure Post(Note : in Msg_Type); -- Post a note in the mailbox procedure Read(Lock : in Key_Type; Note : out Msg_Type); -- Read a note from the mailbox if caller has key private Key : Key_Type := Lock; Mbx : Msg_Array(1 .. Size); end Safe_Mbx; end Mbx_Pkg; with Mbx_Pkg; package Ptr_Mbx_Pkg is pragma Shared_Passive; type Ptr_Safe_Mbx is access Mbx_Pkg.Safe_Mbx; -- All mailboxes are allocated in a passive partition and -- therefore remote access is not required. end Ptr_Mbx_Pkg; with Mbx_Pkg; with Ptr_Mbx_Pkg; generic Mbx_Size : Positive; Ptn_Lock : Mbx_Pkg.Key_Type; package Gen_Mbx_Pkg is -- This package creates a mailbox and makes the -- access value designating it available through -- a remote subprogram call. pragma Remote_Call_Interface; function Use_Mbx return Ptr_Mbx_Pkg.Ptr_Safe_Mbx; end Gen_Mbx_Pkg; with Mbx_Pkg; package body Gen_Mbx_Pkg is New_Mbx : Ptr_Mbx_Pkg.Ptr_Safe_Mbx := new Mbx_Pkg.Safe_Mbx(Ptn_Lock, Mbx_Size); -- A mailbox is created in the passive partition. -- The key to read from the mailbox is the elaborating -- partition's identity. function Use_Mbx return Ptr_Mbx_Pkg.Ptr_Safe_Mbx is -- The access value designating the created mailbox is -- made available to the calling unit. begin return New_Mbx; end Use_Mbx; end Gen_Mbx_Pkg; with Ptr_Mbx_Pkg, Gen_Mbx_Pkg; package RCI_1 is -- This package is the interface to a set of library units that -- is conveniently identified by the library unit Closure_1. pragma Remote_Call_Interface; package Use_Mbx_Pkg is new Gen_Mbx_Pkg(1_000, RCI_1'Partition_ID); function Use_Mbx return Ptr_Mbx_Pkg.Ptr_Safe_Mbx renames Use_Mbx_Pkg.Use_Mbx; -- All partitions include this remote subprogram in -- their interface. ... end RCI_1; with Ptr_Mbx_Pkg, Gen_Mbx_Pkg; package RCI_2 is -- This package is the interface to a set of library units that -- is conveniently identified by the library unit Closure_2. pragma Remote_Call_Interface; ... end RCI_2; with Ptr_Mbx_Pkg, Gen_Mbx_Pkg; package RCI_3 is -- This package is the interface to a set of library units that -- is conveniently identified by the library unit Closure_3. pragma Remote_Call_Interface; ... end RCI_3; with Closure_1; -- Names library units that execute locally. with RCI_2, RCI_3; -- Names RCI packages for interfacing to other -- partitions executing at different sites. package body RCI_1 is My_Mbx : Ptr_Mbx_Pkg.Ptr_Safe_Mbx := Use_Mbx_Pkg.Use_Mbx; Mbx_2, Mbx_3 : Ptr_Mbx_Pkg.Ptr_Safe_Mbx; ... -- Obtain access values to other partition mailboxes. -- For example Mbx_2 := RCI_2.Use_Mbx; Mbx_3 := RCI_3.Use_Mbx; ... My_Mbx.Read(RCI_1'Partition_ID, Next_Note); Mbx_2.Post(Next_Note); Mbx_3.Post(Next_Note); -- Read note in local mailbox and pass to other mailboxes. ... end RCI_1; with Closure_2; -- Names library units that execute locally. with RCI_1, RCI_3; -- Names RCI packages for interfacing to other -- partitions executing at different sites. package body RCI_2 is ... -- Obtain access values to other partition mailboxes. -- For example Mbx_1 := RCI_1.Use_Mbx; Mbx_3 := RCI_3.Use_Mbx; ... end RCI_2; with Closure_3; -- Names library units that execute locally. with RCI_1, RCI_2; -- Names RCI packages for interfacing to other -- partitions executing at different sites. package body RCI_3 is ... -- Obtain access values to other partition mailboxes. -- For example Mbx_1 := RCI_1.Use_Mbx; Mbx_2 := RCI_2.Use_Mbx; ... end RCI_3;</syntaxhighlight> The following post-compilation partitioning support is implementation defined; the syntax is for illustration only. Several possible combinations for partitioning are presented. In each combination, the first partition specified is a passive partition where the mailboxes are allocated. This partition is accessible to other partitions by simply calling the protected operations of the mailbox. The minimally distributed partitioning comprises two partitions; one passive partition and one active partition. All RCI library units in the application are assigned to a single active partition. There would be no remote calls executed as a result of this partitioning. <syntaxhighlight lang="Ada"> Partition(Ptn => 0, Assign => (Ptr_Mbx_Pkg)) -- passive Partition(Ptn => 1, Assign => (RCI_1, RCI_2, RCI_3)) -- active</syntaxhighlight> A more distributed version comprises three partitions. The RCI library units in the application are assigned to two active partitions. <syntaxhighlight lang="Ada"> Partition(Ptn => 0, Assign => (Ptr_Mbx_Pkg)) -- passive Partition(Ptn => 1, Assign => (RCI_1)) -- active Partition(Ptn => 2, Assign => (RCI_2, RCI_3)) -- active</syntaxhighlight> A fully distributed version comprises four partitions. The RCI library units in the application are assigned to three active partitions. <syntaxhighlight lang="Ada"> Partition(Ptn => 0, Assign => (Ptr_Mbx_Pkg)) -- passive Partition(Ptn => 1, Assign => (RCI_1)) -- active Partition(Ptn => 2, Assign => (RCI_2)) -- active Partition(Ptn => 3, Assign => (RCI_3)) -- active</syntaxhighlight> Note that there is no need to mention the pure unit Mbx_Pkg because it can be replicated as necessary. Moreover, generic units do not have to be mentioned since it is only their instances that really exist. === <span id="5-1">E.5.1 Dynamically Bound Remote Subprogram Calls</span> === In Ada 95, the core language supports dynamically bound subprogram calls. For example, a program may dereference an access-to-subprogram object and call the designated subprogram, or it may dispatch by dereferencing an access-to-class-wide type controlling operand. These two forms of dynamic binding are also allowed in distributed systems to support the programming of fault-tolerant applications and changes in communication topology. For example, through dynamically bound calls, a distributed program may reference subprograms in replicated partitions to safeguard against the failure of active partitions. In the event of a failure in a called active partition, the caller can simply redirect the call to a subprogram backup partition. An advantage of these two forms of dynamic binding is that they relax the requirement for library units in the the calling partition to semantically depend on the library units containing the actual remote subprograms. Partitions need only name an RCI or Remote-Types library unit that includes the declaration of an appropriate general access type; objects of such types may contain remote access values. A remote access value designating a subprogram allows naming a subprogram indirectly. The remote access value is restricted to designating subprograms declared in RCI library units. This ensures that the appropriate stubs for the designated subprograms exist in a receiving (server) partition. In order to pass remote access values designating subprograms among partitions, subprograms declared in RCI library units may specify formal parameters of access-to-subprogram types. The remote access-to-class-wide type provides an alternative dynamic binding capability that facilitates encapsulating both data and operations. The remotely callable subprograms are specified as the primitive operations of a tagged limited type declared in a pure library unit. In an RCI or Remote-Types library unit, a general access type designating the class-wide type is declared; this declaration allows the corresponding primitive operations to be remote dispatching operations when overridden. Similar to the binding using access-to-subprogram types, library units in the calling partition need only include the RCI or Remote-Types library unit (that declares the access-to-class-wide type) in their context clause in order to dispatch to subprograms in library units included in other active partitions. By restricting dereferencing of such remote access values to occur as part of a dispatching operation, there is no need to deal with remote addresses elsewhere. The existing model for dispatching operations corresponds quite closely to the dispatching model proposed for the linker-provided RPC-receiver procedure suggested in [RM95 E.4]. These dynamic binding capabilities are enhanced further when combined with a name server partition. Typically, the name server partition provides a central repository of remote access values. When a remote access value is made available to a client partition, the value can be dereferenced to execute a remote subprogram call. This avoids a link- time dependence on the requested service and achieves the dynamic binding typical of a client/server paradigm. The following library units illustrate the use of access-to-class-wide types to implement a simple distributed system. The system comprises multiple client partitions, which are instantiations of Client_Ptn, a mailbox server partition named Mbx_Server_Ptn, and two partitions to access local and wide-area network mailboxes named Lan_Mbx_Ptn and Wan_Mbx_Ptn respectively. A client partition may communicate with other partitions in the distributed system through a mailbox that it is assigned by the mailbox server. It may post a message to its mailbox for delivery to another partition (based on the address in the message), or wait for a message to be delivered to its mailbox. A client may be connected either to the LAN or the WAN, but this is transparent to the application. <syntaxhighlight lang="Ada"> package Mbx_Pkg is pragma Pure; type Mail_Type is ... type Mbx_Type is abstract tagged limited private; procedure Post(Mail : in Mail_Type; Mbx : access Mbx_Type) is abstract; procedure Wait(Mail : out Mail_Type; Mbx : access Mbx_Type) is abstract; private type Mbx_Type is abstract tagged limited null record; end Mbx_Pkg; with Mbx_Pkg; use Mbx_Pkg; package Mbx_Server_Ptn is pragma Remote_Call_Interface; type Ptr_Mbx_Type is access all Mbx_Type'Class; function Rmt_Mbx return Ptr_Mbx_Type; end Mbx_Server_Ptn; with Mbx_Server_Ptn; package Lan_Mbx_Ptn is pragma Remote_Call_Interface; function New_Mbx return Mbx_Server_Ptn.Ptr_Mbx_Type; end Lan_Mbx_Ptn; with Mbx_Server_Ptn; package Wan_Mbx_Ptn is pragma Remote_Call_Interface; function New_Mbx return Mbx_Server_Ptn.Ptr_Mbx_Type; end Wan_Mbx_Ptn; with Mbx_Pkg; package body Lan_Mbx_Ptn is type Lan_Mbx_Type is new Mbx_Pkg.Mbx_Type with ...; procedure Post(Mail : in Mail_Type; Mbx : access Lan_Mbx_Type); procedure Wait(Mail : out Mail_Type; Mbx : access Lan_Mbx_Type); ... function New_Mbx return Ptr_Mbx_Type is begin return new Lan_Mbx_Type; end New_Mbx; end Lan_Mbx_Ptn; with Mbx_Pkg; package body Wan_Mbx_Ptn is ... with Lan_Mbx_Ptn, Wan_Mbx_Ptn; package body Mbx_Server_Ptn is function Rmt_Mbx return Ptr_Mbx_Type is begin if ... then return Lan_Mbx_Ptn.New_Mbx; elsif ... then return Wan_Mbx_Ptn.New_Mbx; else return null; end if; end Rmt_Mbx; end Mbx_Server_Ptn; -- The client partitions do not need to with the specific -- LAN/WAN mailbox interface packages. with Mbx_Pkg, Mbx_Server_Ptn, ... use Mbx_Pkg, Mbx_Server_Ptn, ... procedure Use_Mbx is Some_Mail : Mail_Type; This_Mbx : Ptr_Mbx_Type := Rmt_Mbx; -- Get a mailbox pointer for this partition begin ... Post(Some_Mail, This_Mbx); -- Dereferencing controlling operand This_Mbx -- causes remote call as part of Post's dispatching ... Wait(Some_Mail, This_Mbx); ... end Use_Mbx; generic ... package Client_Ptn is pragma Remote_Call_Interface; end Client_Ptn; with Use_Mbx; package body Client_Ptn is begin ... end Client_Ptn; package Client_Ptn_1 is new Client_Ptn ... ... package Client_Ptn_N is new Client_Ptn ... -- Post-compilation partitioning Partition(Ptn => 0, Assign => (Mbx_Server_Ptn)) Partition(Ptn => 1, Assign => (Lan_Mbx_Ptn)) Partition(Ptn => 2, Assign => (Wan_Mbx_Ptn)) Partition(Ptn => 3, Assign => (Client_Ptn_1)) ... Partition(Ptn => N+2, Assign => (Client_Ptn_N))</syntaxhighlight> In this next example, there is one controlling partition, and some number of worker partitions, in a pipeline configuration. The controller sends a job out to a worker partition, and the worker chooses either to perform the job, or if too busy, to pass it on to another worker partition. The results are returned back through the same chain of workers through which the original job was passed. Here is a diagram for the flow of messages: <syntaxhighlight lang="Ada"> Job Job Job Job Controller ----> W1 ---> W2 ---> W3 ---> W4 ... <--- <--- <--- <--- Result Result Result Result</syntaxhighlight> The elaboration of each worker entails registering that worker with the controller and determining which other worker (if any) the job will be handed to when it is too busy to handle the job itself. When it receives a job from some other worker, it also receives a "return" address to which it should return results. The workers are defined as instances of a generic RCI library unit. The first solution uses (remote) access-to-subprogram types to provide the dynamic binding between partitions. Two access-to-subprogram types are declared in the RCI library unit (Controller) that designate the procedures to perform the work and return the results. In addition, this library unit declares two procedures; one to register and dispense workers for the pipeline and one to receive the final results. An instantiation of a generic RCI library unit (Worker) declares the actual subprograms for each worker. The locations of these procedures are made available as remote access values; elaboration of Worker registers the Receive_Work procedure with the Controller. <syntaxhighlight lang="Ada"> package Controller is pragma Remote_Call_Interface; type Job_Type is ...; -- Representation of job to be done type Result_Type is ...; -- Representation of results type Return_Address is access procedure (Rslt : Result_Type); -- Return address for sending back results type Worker_Ptr is access procedure(Job : Job_Type; Ret : Return_Address); -- Pointer to next worker in chain procedure Register_Worker(Ptr : Worker_Ptr; Next : out Worker_Ptr); -- This procedure is called during elaboration -- to register a worker. Upon return, Next contains -- a pointer to the next worker in the chain. procedure Give_Results(Rslt : Result_Type); -- This is the controller procedure which ultimately -- receives the result from a worker. end Controller; with Controller; use Controller; generic -- Instantiated once for each worker package Worker is pragma Remote_Call_Interface; procedure Do_Job(Job : Job_Type; Ret : Return_Address); -- This procedure receives work from the controller or -- some other worker in the chain procedure Pass_Back_Results(Rslt : Result_Type); -- This procedure passes results back to the worker in the -- chain from which the most recent job was received. end Worker; package body Worker is Next_Worker : Worker_Ptr; -- Pointer to next worker in chain, if any Previous_Worker : Return_Address; -- Pointer to worker/controller who sent a job most recently procedure Do_Job(Job : Job_Type; Ret : Return_Address) is -- This procedure receives work from the controller or -- some other worker in the chain begin Previous_Worker := Ret; -- Record return address for returning results if This_Worker_Too_Busy and then Next_Worker /= null then -- Forward job to next worker, if any, if -- this worker is too busy Next_Worker(Job, Pass_Back_Results'Access); -- Include this worker's pass-back-results procedure -- as the return address else declare Rslt : Result_Type; -- The results to be produced begin Do The Work(Job, Rslt); Previous_Worker(Rslt); end; end if; end Do_Job; procedure Pass_Back_Results(Rslt : Result_Type) is -- This procedure passes results back to the worker in the -- chain from which the most recent job was received. begin -- Just pass the results on... Previous_Worker(Rslt); end Pass_Back_Results; begin -- Register this worker with the controller -- and obtain pointer to next worker in chain, if any Controller.Register_Worker(Do_Job'Access, Next_Worker); end Worker; -- Create multiple worker packages package W1_RCI is new Worker; ... package W9_RCI is new Worker; -- Post-Compilation Partitioning -- Create multiple worker partitions Partition(Ptn => 1, Assign => (W1_RCI)) ... Partition(Ptn => 9, Assign => (W9_RCI)) -- create controller partition Partition(Ptn => 0, Assign => (Controller))</syntaxhighlight> The second solution uses (remote) access-to-class-wide types to provide the dynamic binding between partitions. A root tagged type is declared in a pure package Common. Two derivatives are created, one to represent the controller (Controller_Type), and one to represent a worker (Real_Worker). One object of Controller_Type is created, which will be designated by the return address sent to the first worker with a job. An object for each worker of the Real_Worker type is created, via a generic instantiation of the One_Worker generic. All of the data associated with a single worker is encapsulated in the Real_Worker type. The dispatching operations Do_Job and Pass_Back_Results use the pointer to the Real_Worker (the formal parameter W) to gain access to this worker- specific data. The access type Worker_Ptr is used to designate a worker or a controller, and can be passed between partitions because it is a remote access type. Normal access types cannot be passed between partitions, since they generally contain partition-relative addresses. <syntaxhighlight lang="Ada"> package Common is -- This pure package defines the root tagged type -- used to represent a worker (and a controller) pragma Pure; type Job_Type is ...; -- Representation of Job to be done type Result_Type is ...; -- Representation of results type Worker_Type is abstract tagged limited private; -- Representation of a worker, or the controller procedure Do_Job(W : access Worker_Type; Job : Job_Type; Ret : access Worker_Type'Class) is abstract; -- Dispatching operation to do a job -- Ret may point to the controller procedure Pass_Back_Results(W : access Worker_Type; Rslt : Result_Type) is abstract; -- Dispatching operation to pass back results private ... end Common; with Common; use Common; package Controller is pragma Remote_Call_Interface; type Worker_Ptr is access all Common.Worker_Type'Class; -- Remote access to a worker procedure Register_Worker(Ptr : Worker_Ptr; Next : out Worker_Ptr); -- This procedure is called during elaboration -- to register a worker. Upon return, Next contains -- a pointer to the next worker in the chain. end Controller; package body Controller is First_Worker : Worker_Ptr := null; -- Current first worker in chain type Controller_Type is new Common.Worker_Type; -- A controller is a special kind of worker, -- it can receive results, but is never given a job The_Controller : Controller_Type; -- The tagged object representing the controller Controller_Is_Not_A_Worker : exception; procedure Do_Job(W : access Controller_Type; Job : Job_Type; Ret : access Worker_Type'Class) is -- Dispatching operation to do a job begin raise Controller_Is_Not_A_Worker; -- Controller never works (lazy pig) end Do_Job; procedure Pass_Back_Results(W : access Controller_Type; Rslt : Result_Type) is -- Dispatching operation to receive final results begin Do Something With Result(Rslt); end Pass_Back_Results; procedure Register_Worker(Ptr : Worker_Ptr; Next : out Worker_Ptr) is -- This procedure is called during elaboration -- to register a worker. It receives back -- a pointer to the next worker in the chain. begin -- Link this worker into front of chain gang Next := First_Worker; First_Worker := Ptr; end Register_Worker; begin -- Once all workers have registered, Controller initiates -- the pipeline by dispatching on Do_Job with First_Worker -- as the controlling operand; Controller then awaits the -- results to be returned (this mechanism is not specified). end Controller; with Common; use Common; with Controller; use Controller; package Worker_Pkg is -- This package defines the Real_Worker type -- whose dispatching operations do all the -- "real" work of the system. -- Note: This package has no global data; -- All data is encapsulated in the Real_Worker type. type Real_Worker is new Common.Worker_Type with record Next : Worker_Ptr; -- Pointer to next worker in chain, if any Previous : Worker_Ptr; -- Pointer to worker/controller who sent -- us a job most recently ... -- other data associated with a worker end record; procedure Do_Job(W : access Real_Worker; Job : Job_Type; Ret : access Worker_Type'Class); -- Dispatching operation to do a job procedure Pass_Back_Results(W : access Real_Worker; Rslt : Result_Type); -- Dispatching operation to pass back results end Worker_Pkg; package body Worker_Pkg is procedure Do_Job(W : access Real_Worker; Job : Job_Type; Ret : access Worker_Type'Class) is -- Dispatching operation to do a job. -- This procedure receives work from the controller or -- some other worker in the chain. begin W.Previous := Worker_Ptr(Ret); -- Record return address for returning results if W.This_Worker_Too_Busy and then W.Next /= null then -- Forward job to next worker, if any, if -- this worker is too busy Common.Do_Job(W.Next, Job, W); -- now dispatch to appropriate Do_Job, -- include a pointer to this worker -- as the return address. else declare Rslt : Result_Type; -- The results to be produced begin Do The Work(Job, Rslt); Common.Pass_Back_Results(W.Previous, Rslt); -- dispatch to pass back results -- to another worker or to the controller end; end if; end Do_Job; procedure Pass_Back_Results(W : access Real_Worker; Rslt : Result_Type) is -- Dispatching operation to pass back results -- This procedure passes results back to the worker in the -- chain from which the most recent job was received. begin -- Pass the results to previous worker Common.Pass_Back_Results(W.Previous, Rslt); end Pass_Back_Results; end Worker_Pkg; generic -- Instantiated once for each worker package One_Worker is pragma Remote_Call_Interface; end One_Worker; with Worker_Pkg; with Controller; package body One_Worker is The_Worker : Worker_Pkg.Real_Worker; -- The actual worker begin -- Register this worker "object" Controller.Register_Worker(The_Worker'Access, The_Worker.Next); end One_Worker; -- Create multiple worker packages package W1_RCI is new One_Worker; ... package W9_RCI is new One_Worker; -- Post-Compilation Partitioning -- Create multiple worker partitions Partition(Ptn => 1, Assign => (W1_RCI)) ... Partition(Ptn => 9, Assign => (W9_RCI)) -- create controller partition Partition(Ptn => 0, Assign => (Controller))</syntaxhighlight> == <span id="6">E.6 Configuring a Distributed System</span> == In the previous examples, post-partitioning has been illustrated in terms of the library units that comprise a partition. The configuration of partitions to nodes has been omitted since this is beyond the scope of the Annex. For example, whether partitions may share the same node is implementation defined. The capability for a passive partition to share a node with multiple active partitions would allow a distributed system to be configured into a standard, multiprogramming system, but this may not be practical for all environments. The mapping of partitions to the target environment must be consistent with the call and data references to RCI and shared passive library units, respectively. This requires only that the target environment support the necessary communication connectivity among the nodes; it does not guarantee that active partitions are elaborated in a particular order required by the calls and references. To allow partitions to elaborate independently, a remote subprogram call is held until the receiving partition has completed its elaboration. If cyclic elaboration dependencies result in a deadlock as a result of remote subprogram calls, the exception Program_Error may be raised in one or all partitions upon detection of the deadlock. The predefined exception Communication_Error (declared in package System.RPC) is provided to allow calling partitions to implement a means for continuing execution whenever a receiving partition becomes inaccessible. For example, when the receiving partition fails to elaborate, this exception is raised in all partitions that have outstanding remote calls to this partition. To maintain interface consistency within a distributed system, the same version of an RCI or a shared passive library unit specification must be used in all elaborations of partitions that reference the same library unit. The consistency check cannot happen before the configuration step. (The detection of unit inconsistency, achievable when linking a single Ada program, cannot be guaranteed at that time for the case of a distributed system.) It is implementation defined how this check is accomplished; Program_Error may be raised but in any event the partions concerned become inaccessible to one another (and thus later probably resulting in Communication_Error); see [RM95 E.3]. In addition to the partition termination rules, an implementation could provide the capability for one partition to explicitly terminate (abort) another partition; the value of the attribute Partition_ID may be used to identify the partition to be aborted. If a partition is aborted while executing a subprogram called by another partition, Communication_Error will be raised in the calling partition since the receiving partition is no longer accessible. == <span id="7">E.7 Partition Communication Subsystem</span> == The partition communication subsystem (PCS) is notionally compatible with the proposed Communications Model specified by the in-progress recommendations of the ISO RPC Committee Draft. The Annex requires that, as a minimum capability, the PCS must implement the standard package RPC to service remote subprogram calls. Standardizing the interface between the generated stubs for remote subprogram calls and the message-passing layer of the target communications software (the RPC package) facilitates a balanced approach for separating the implementation responsibilities of supporting distributed systems across different target environments. The remote procedure call (RPC) paradigm was selected as the specified communication facility rather than message passing or remote entry call because of the following advantages of RPC: * The RPC paradigm is widely implemented for interprocess communication between processes in different computers across a network. Several standards have been initiated by organizations such as ISO and OSF. Furthermore, emerging distributed operating system kernels promote support for RPC. Such considerations require that a language for programming distributed systems provide RPC as a linguistic abstraction. Finally, the need for RPC support is identified in U.S. Government initiatives towards developing open systems. * A tenet of the revision is to maintain the type safety properties of the existing standard. Type-safe interfaces among partitions are a consequence of using the RPC paradigm. RPC is a compatible extension of the standard which, unless included in the Annex, would be difficult to support (by user-defined facilities) since detailed information on the compiler implementation is required. * The RPC paradigm allows programs to be written with minimal regard for whether the program is targeted for distributed or nondistributed execution. Except in the instance of asynchronous procedure calls, the execution site implies no change in semantics from that of a local subprogram call. This is necessary for partitioning library units into various distributed configurations in a seamless or transparent manner. Furthermore, the use of RPC maintains concurrency/parallelism as orthogonal to distribution. This orthogonality reduces the complexity of the run-time system and allows remote references to be controlled through straightforward restrictions. * The asynchronous form of RPC relaxes the normal synchronous semantics of RPC. This facilitates programming efficient application-specific communication paradigms where at-most-once semantics are not required. Ada 95 includes important enhancements that allow dynamic subprogram calls using access-to-subprogram types and tagged types. To restrict these enhancements to nondistributed programs is likely to promote criticism similar to the absence of dynamic calls in Ada 83. In addition, the capability to support remote dispatching is an important discriminator between Ada 95 and other competing languages. Package System.RPC This package specifies the standard interface necessary to implement stubs at both the calling and receiving partitions for a remote subprogram call. The interface specifies both the actual operations and the semantic conditions under which they are to be used by the stubs. It is also adaptable to different target environments. Additional non- standard interfaces may be specified by the PCS. For example, a simple message passing capability may be specified for exchanging objects of some message type using child library units. (Note that the normal user does have to use this package but only the implementer of the communication system.) The package specifies the primitive operations for Root_Stream_Type to marshall and unmarshall message data by using the attributes Read and Write within the stubs. This allows an implementation to define the format of messages to be compatible with whatever message-passing capability between partitions is available from the target communication software. The routing of parameters to a remote subprogram is supported by the Partition_ID type that identifies the partition, plus implementation- specific identifiers passed in the stream itself to identify the particular RCI library unit and remote subprogram. A value of type Partition_ID identifies the partition to which a library unit is assigned by the post-compilation partitioning. The procedures RPC and APC support the generation of stubs for the synchronous and asynchronous forms of remote subprogram call. Each procedure specifies the partition that is the target of the call and the appropriate message data to be delivered. For the synchronous form, the result data to be received upon the completion the call is specified. As a consequence, the task originating the remote subprogram call is suspended to await the receipt of this data. In contrast, the asynchronous form does not suspend the originating task to await the receipt of the result data. To facilitate the routing of remote calls in the receiving partition, the procedure Establish_RPC_Receiver is specified to establish the interface for receiving a message and for dispatching to the appropriate subprogram. The interface is standardized through the parameters specified for an access-to-subprogram type that designates an implementation-provided RPC-receiver procedure. In this way, post- compilation support can link the necessary units and data to the RPC- receiver procedure. Once the RPC-receiver procedure has been elaborated, it may be called by the PCS. A single exception Communication_Error is specified to report error conditions detected by the PCS. Detailed information on the precise condition may be provided through the exception occurrence. These conditions are necessarily implementation-defined, and therefore, inappropriate for inclusion in the specification as distinct exception names. === <span id="7-1">E.7.1 The Interaction Between the Stubs and the PCS</span> === The execution environment of the PCS is defined as an Ada environment. This is done in order to provide Ada semantics to serving partitions. In the calling and receiving partitions, the canonical implementation relies upon the Ada concurrency model to service stubs. For example, in the calling partition, cancellation of a synchronous remote call, when the calling task has been aborted, requires that the PCS interrupt the Do_RPC operation to execute the cancellation. In the receiving partition, the stub for a remote subprogram is assumed to be called by the RPC-receiver procedure executing in a task created by the PCS. == <span id="8">E.8 Requirements Summary</span> == The facilities of the Distributed Systems annex relate to the requirements in 8.1 (Distribution of Ada Applications) and 8.2 (Dynamic Reconfiguration of Distributed Systems). More specifically, the requirement * R8.1-A(1) - Facilitating Software Distribution is met by the concept of partitions and the categorization of library units and the requirement * R8.2-A(1) - Dynamic Reconfiguration is addressed by the use of remote access to subprogram and access to class wide types for dynamic calls across partitions. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p3-d|Previous]] | [[Guide:9x_rationale/rat95-p3-f|Next]] [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=Annex E. Distributed Systems}} kuuqxhs3yxwfe083p7e1bqxp7t11kc6 Guide:9x rationale/rat95-p3-f 4200 350 1861 1819 2019-04-20T16:20:07Z WikiVisor 11 Text replacement - "[[Guide:9x_rationale/rat95-copyright|Copyright]] | " to "<div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | " wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p3-e|Previous]] | [[Guide:9x_rationale/rat95-p3-g|Next]]</div> One of the major goals of Ada 95 is to provide the necessary language facilities for the development of large-scale information systems that previously have been produced in COBOL and 4GLs. To a large extent, core language enhancements such as child units and object-oriented programming, and the new support for distribution, serve to meet this goal. However, there are also specific requirements at the computational level and for report-oriented output that must be addressed in order to ensure applicability to financial and related Information Systems applications. The major needs are * Exact, decimal arithmetic for quantities up to at least 18 digits of precision; * The ability to produce human-readable formats for such values, with control over the form and placement of currency symbol, sign, digits separator, and radix mark; * The ability to interface with data produced by, or programs written in, other languages (in particular C and COBOL). This chapter describes the facilities and gives the reasons for the major decisions taken in Ada 95 to satisfy these requirements. == <span id="1">F.1 Decimal Computation</span> == A numeric model highly appropriate for information systems, especially for financial applications, is that supplied by the COBOL language. In COBOL the programmer defines numeric items via a "picture" in terms of a specified number of decimal digits and the placement of the decimal point. The arithmetic verbs provide exact arithmetic, with control over truncation versus rounding on a per-computation basis. For example: <syntaxhighlight lang="Ada"> 05 FRACTION PIC S9V99 VALUE .25. 05 ALPHA PIC S9999V9 VALUE 103. 05 BETA PIC S9999V9.</syntaxhighlight> FRACTION has values in the range -9.99 through 9.99, and each of ALPHA and BETA is in the range -9999.9 through 9999.9. <syntaxhighlight lang="Ada"> MULTIPLY ALPHA BY FRACTION GIVING BETA ROUNDED. * Now BETA = 25.8, the rounded value of 25.75 ADD ALPHA TO BETA. * Now BETA = 128.8 DIVIDE BETA BY 10. * Now BETA = 12.8, since truncation is the default</syntaxhighlight> It is also possible to express the above calculation more succinctly in COBOL: <syntaxhighlight lang="Ada"> COMPUTE BETA = (ALPHA * FRACTION + ALPHA) / 10.</syntaxhighlight> However, the effect of rounding versus truncation is now implementation dependent, so the result may be either 12.8 or 12.9. === <span id="1-1">F.1.1 Decimal Arithmetic through Discriminated Type</span> === In addressing the exact computational requirements, we examined several alternatives. One was to rely on a private discriminated type, with discriminants reflecting scale and precision. (The terminology here is the same as in SQL [ISO 92]: precision is the total number of decimal digits; scale is the number of digits after the decimal point.) For example <syntaxhighlight lang="Ada"> package Computation is subtype Scale_Range is Integer range implementation-defined .. implementation-defined; subtype Precision_Range is Positive range 1 .. implementation-defined; type Decimal(Precision : Precision_Range; Scale : Scale_Range) is private; ... -- Subprograms for arithmetic end Computation;</syntaxhighlight> Such an approach would have the benefit of separability from the core features, but its numerous drawbacks led to its rejection: * Literals are unavailable for private types, hence the programmer would need to perform explicit conversions either from String or from a specific real type. Such a style would be both inefficient and aesthetically displeasing. In an early version of the Ada 9X mapping there was a capability to obtain numeric literals for private types, but this was removed as a simplification. * Non-trivial optimizations are needed to avoid time and space overhead. In COBOL precision and scale are known at compile time, so the compiler can generate efficient code. The discriminated type approach lets the programmer defer specifying the precision and scale until run time, but the generality comes at a price. * A problem often cited with the COBOL model is the lack of typing. For example, if by mistake a COBOL programmer adds a unitless fraction to a salary, this error will not be detected by the compiler. To obtain compile-time protection from such an error in Ada, the programmer would need to derive from type Decimal, for example to declare the types Fraction and Salary. However, derivation provides more operations than make sense and hence other kinds of errors could still arise (for example, multiplying a Salary by a Salary to obtain a Salary). At the same time it yields less than what is needed; for example, it would be useful to be able to divide two Salary values and obtain a Fraction, but this would not be provided automatically. Although both of these problems could be solved by the programmer providing some additional explicit declarations, programmers might be tempted to forego the type derivations (and the resulting safety) and to simply declare all their data of type Decimal. * Specifying just precision and scale allows more values than might be sensible. For example, if we want a fraction value to be in the range 0.00 .. 1.00, we need to specify Decimal(Precision=>3, Scale=>2), but this allows all values in the range -9.99 .. 9.99. Another major problem with the discriminated type approach is the error- prone effects of having arithmetic operators take parameters of type Decimal and deliver a result of type Decimal. Division in particular is troublesome; languages that attempt to address the issue lead inevitably to anomalies. For example, the well-known curiosity in PL/I is that the operation 10+1/3 overflows, since the language rules attempt to maximize the precision of the quotient. Moreover, the rules for precision and scale of an arithmetic result would clash with the need for discriminant identity on assignment. For example, consider the simple fragment: <syntaxhighlight lang="Ada"> declare Salary : Decimal(Precision => 9, Scale => 2); -- Values in -99_999_99.99 .. 99_999_999.99 Fraction : Decimal(Precision => 2, Scale => 2); -- Values in -0.99 .. 0.99 begin ... Salary := Salary * Fraction; ... end;</syntaxhighlight> The intuitive rule for "*" would be to define the precision of the result as the sum of the precisions of the operands, and similarly for the scale. Thus Salary*Fraction would have precision 11 and scale 4, sufficient to hold any product. But then the rules for discriminant matching would cause Constraint_Error to be raised by the assignment to Salary. A possible solution would be to introduce special rules for discriminant matching in such cases, but this adds complexity. An alternative would be to omit the operator forms for the arithmetic subprograms and instead to provide a procedural interface with an out parameter, thereby making the result precision and scale known at the point of call. For example: <syntaxhighlight lang="Ada"> procedure Multiply (Left, Right : in Decimal; Result : out Decimal; Rounding : in Boolean := False);</syntaxhighlight> Although such an approach has been successfully applied in the Ada 83 Decimal Arithmetic and Representation components [Brosgol 92], the other drawbacks led us to seek alternative solutions for Ada 95. === <span id="1-2">F.1.2 Decimal Arithmetic and Ada 83 Numeric Types</span> === The Ada 83 numeric types give us a choice among integer, floating point, and fixed point. In some sense integer arithmetic provides the most appropriate computational model, since it matches the requirements for exact results. For example, one might consider using an integer type Pennies to represent monetary values. However, this would be impractical for several reasons: the absence of real literals is a hardship, keeping track of implicit scaling is awkward, and many compilers do not support the 64-bit integer arithmetic that would be needed for 18 digits of accuracy. Floating point is unacceptable because of the inherent inexactness of representing decimal quantities. Consider the following program fragment, where X is a floating point variable: <syntaxhighlight lang="Ada"> X := 0.0; for I in 1 .. 10 loop X := X + 0.10; end loop;</syntaxhighlight> After execution of the loop using typical floating point hardware, X will not equal 1.00. Moreover, 64-bit floating point does not have enough mantissa bits to represent 18 decimal digits. At first glance, fixed point seems no better. The apparent motivations behind the fixed point facility in Ada were to deal with scaled data coming in from sensors in real-time applications, and to provide a substitute for floating point in target environments lacking floating point hardware. Indeed, the inherent bias toward powers of 2 for the attribute Small in the Ada 83 fixed point model seems at odds with the needs of decimal computation. However, fixed point provides a closer fit than might be expected [Dewar 90b]. The Ada 83 unification of floating point and fixed point under the category of "approximate" computation is more artificial than real, since the model-number inaccuracy that is appropriate in the floating point case because of differences in target hardware is not applicable at all to fixed point. The fixed point arithmetic operations "+", "-", "*", "/" are exact, and through a Small representation clause the programmer can specify decimal scaling. Thus consider a COBOL declaration <syntaxhighlight lang="Ada"> 05 SALARY PICTURE S9(6)V9(2) USAGE COMPUTATIONAL.</syntaxhighlight> which defines SALARY as a signed binary data item comprising 8 decimal digits, of which 2 are after the assumed decimal point. This can be simulated in Ada: <syntaxhighlight lang="Ada"> type Dollars is delta 0.01 range -999_999.99 .. 999_999.99; for Dollars'Small use 0.01; Salary : Dollars;</syntaxhighlight> The programmer-specified Small not only provides the required decimal scaling, it also prevents the implementation from supplying extra fractional digits. This is important in financial applications: if the programmer requests 2 fractional digits, it would be incorrect for a compiler to provide 3. The fixed point approach immediately avoids several of the problems with discriminated types: we get numeric literals, compile-time known scales and precisions, strong typing, and the ability to specify logical ranges. Moreover, the rules for the arithmetic operators are fitting. The "+" and "-" operators require identical operand types and deliver a result of the same type, which is an intuitively correct restriction. Adding or subtracting quantities with different scales is not a frequent situation; when it arises, it is reasonable to require an explicit conversion to indicate the rescaling. Automatic availability of mixed- type "*" and "/" also makes sense. There are, however, several problems with adopting the Ada 83 fixed point model unchanged for decimal arithmetic. * The Ada fixed point model leads to occasional surprises, even in the presence of a Small representation clause. For example, one or both endpoints supplied in the definition of a fixed point type may be absent from the implemented range for the type. * The Ada 83 fixed point rules require conversions of real literals (and named numbers of type universal_real) that appear as factors in multiplication or division. Without the programmer providing an explicit declaration of an applicable "*" operator, it would be illegal to write: <syntaxhighlight lang="Ada"> Worker_Salary := 1.05 * Worker_Salary;</syntaxhighlight> :Instead, something like the following circumlocution is required: <syntaxhighlight lang="Ada"> Worker_Salary := Dollars(Some_Type(1.05) * Worker_Salary);</syntaxhighlight> :The need for the programmer to supply either these explicit conversions or an explicit overloading of "*", is somewhat embarrassing. In COBOL the equivalent functionality can be obtained directly: <syntaxhighlight lang="Ada"> MULTIPLY WORKER-SALARY BY 1.05.</syntaxhighlight> * The previous example illustrates another serious problem: Ada fixed point does not give a well-defined result for the conversion of values. That is, the language does not guarantee whether the result of a fixed point conversion is to be rounded or truncated. In fact, different evaluations of the same expression in the same program could yield different results, an unwelcome nondeterminism. * Facilities such as edited output, and a division operation delivering both a quotient and remainder, are not defined for fixed point types. === <span id="1-3">F.1.3 Decimal Arithmetic through Decimal Types</span> === Since fixed point comes reasonably close to satisfying the requirements for decimal arithmetic, our decision was to use that facility as the basis for a solution. Ada 95 thus introduces a new class of fixed point types, the decimal types, distinguished syntactically by the presence of a positive integer digits value following the delta in a fixed point definition. The delta .. digits .. syntax, suggested by David Emery [Emery 91], has the advantage of identifying the type immediately as a special kind of fixed point type (the delta) without requiring new reserved words. The delta value must be a power of 10. For example: <syntaxhighlight lang="Ada"> type Francs is delta 0.01 digits 9;</syntaxhighlight> This declaration is similar in effect to the Ada 83 fragment: <syntaxhighlight lang="Ada"> type Francs is delta 0.01 range -(10.0**9 - 1.0) .. 10.0**9 - 1.0; for Francs'Small use 0.01;</syntaxhighlight> The digits value in a decimal fixed point type definition thus implies a range constraint. For a decimal type with delta D and digits N (both of which must be static), the implied range is - (10.0**N - 1.0)*D .. (10.0**N - 1.0)*D. Moreover, a range constraint may be further supplied at the definition of a decimal type or subtype, and at the declaration of objects. For example: <syntaxhighlight lang="Ada"> type Salary is delta 0.01 digits 8 range 0.00 .. 100_000.00; subtype Price is Francs range 0.00 .. 1000.00; Worker_Salary : Salary range 0.00 .. 50_000.00;</syntaxhighlight> The ordinary fixed point operations, such as the arithmetic operators and fixed point attributes, are available for decimal types. There are, however, several important differences: * For a decimal subtype S, the conversion S(expr) where expr is of some numeric type is defined to truncate (towards 0) rather than having an unspecified effect. * To obtain a rounded result for an expression expr having a real type, the function attribute S'Round(expr) can be used. This attribute is not available for ordinary fixed point types. * Other attributes apply only to decimal subtypes: for example, S'Digits and S'Scale. The former reflects the value of digits supplied for the declaration of S. The latter is the number of digits after the decimal point in values of S and is related to S'Delta by the equation <syntaxhighlight lang="Ada"> 10.0**(-S'Scale) = S'Delta</syntaxhighlight> :A stylistic issue noted above, namely the inability in Ada 83 to write simple statements such as: <syntaxhighlight lang="Ada"> Worker_Salary := 1.05 * Worker_Salary;</syntaxhighlight> has been solved in Ada 95 for fixed point types in general. The revised rules permit a universal_fixed value to be implicitly converted to a specific target type if the context uniquely establishes the target type. Thus there is no need to convert to Salary the product on the right side of the assignment. Another new rule allows a universal_real value to be used as an operand to a fixed point "*" and "/"; thus there is no need to convert the literal 1.05 to a specific type. Although these enhancements are motivated by considerations with decimal types, it makes no sense either from an implementation or user viewpoint to apply the new rules only to decimal types, and thus they have been generalized for ordinary fixed point types as well. : Given that decimal types come equipped with their own operations, it is natural to introduce a category of generic formal type that can only be matched by decimal subtypes. The syntax for such a generic formal type is what one would expect: <syntaxhighlight lang="Ada"> type T is delta <> digits <>;</syntaxhighlight> :The actual subtype supplied for a formal decimal type must be a decimal subtype. This makes sense, since an ordinary fixed point subtype does not have all the necessary operations. On the other hand, there is a design issue whether to permit an actual decimal subtype to match a formal fixed point type (one given by delta <>). Such permission would seem to be useful, since it would allow existing Ada 83 fixed point generics to be matched by Ada 95 decimal subtypes. However, it would introduce some implementation difficulties, especially for those compilers that attempt to share the code of the template across multiple instances. The fact that some operations (in particular numeric conversion) behave differently for decimal and ordinary fixed point would also cause complications if decimal subtypes were permitted to match formal fixed point types. Thus the decimal fixed point types are defined to form a class disjoint from ordinary fixed point types with respect to generic matching. :Formal decimal types are exploited to provide edited output (see below) as well as division delivering both a quotient and a remainder. :One of the requirements for information systems applications is the ability to perform edited output of decimal quantities. We considered introducing decimal subtype attributes for this effect; for example S'Image(X, Picture) would return a String based on the value of X and the formatting conventions of Picture. However, this approach would have introduced implementation complexity out of proportion to the notational benefit for users. The type of Picture is defined in an external package, making such an attribute rather atypical, and support would affect the compiler and not simply require a supplemental package. Instead, picture-based output is obtained via generics, as described below. === <span id="1-4">F.1.4 Internal Representation for Decimal Objects</span> === Ada and COBOL have a somewhat different philosophy about internal data representation. Through the USAGE clause the COBOL programmer furnishes information about how numeric items will be represented, either explicitly (such as BINARY, DISPLAY, PACKED-DECIMAL) or by default (DISPLAY). COBOL's default representation opts for data portability versus computational efficiency. Ada's approach to data representation, for types in general and not just decimal, is to let the compiler decide based on efficiency, and to let the programmer override this choice explicitly when necessary. For decimal types this is achieved through the Machine_Radix attribute and the corresponding attribute definition clause. An object of a decimal type, as with fixed point in general, may be viewed as the product of an integer mantissa (represented explicitly at run time) and the type's delta (managed at compile time). The type's Machine_Radix determines the representation of the mantissa: a value of 2 implies binary, while a value of 10 implies decimal. The compiler will choose an implementation-defined machine radix by default, which the programmer can override with an explicit attribute definition clause. Consider the following example, where the implementation's default for all decimal types is binary machine radix: <syntaxhighlight lang="Ada"> type Money_2 is delta 0.01 digits 18; type Money_10 is delta 0.01 digits 18; for Money_10'Machine_Radix use 10;</syntaxhighlight> An object of type Money_2 is represented in binary; on typical machines it will occupy 64 bits (including a sign). An object of type Money_10 is represented in decimal; it will take 18 digits (and a sign). The exact representation is unspecified, and in fact different machines have different formats for packed decimal concerning how the sign is encoded. If a decimal type's machine radix is 10, then the compiler may also generate packed-decimal instructions for arithmetic computation. Whether it chooses to do so, rather than converting to/from binary and using binary arithmetic, depends on which is more efficient. The only difference in behavior between decimal and binary machine radix, aside from performance, is that some intermediate results might overflow in one case but not the other. For example, if Money_10 values are represented in 19 digits (an odd number is typical for packed decimal, since the sign can be stored in the same byte as a digit), and Money_2 values occupy 64 bits, then a computation such as (100.0 * Money)/100.0 will overflow if Money has type Money_10, but not if Money has type Money_2, where Money is 10.0**18 - 1.0. Implementations using packed decimal are encouraged to exploit subtype digits constraints for space economization. For example: <syntaxhighlight lang="Ada"> Pay : Money_10 digits 9;</syntaxhighlight> The compiler can and should represent Pay in 9 digits rather than 18 as would be needed in general for Money_10. Ada does not provide the equivalent of DISPLAY usage for decimal data, since computation on character strings would be inefficient. If the programmer wishes to store decimal data in an external file in a portable fashion, the recommended approach is to convert via the To_Display function in Interfaces.COBOL.Decimal_Conversions; see B.3. === <span id="1-5">F.1.5 Compliance</span> === The decimal type facility is part of the core language; thus the syntax for decimal types and for formal generic decimal types must be supported by all implementations. However, since a compiler needs to implement ordinary fixed point only for values of Small that are powers of 2, it may reject the declaration of a decimal type and also the declaration of a generic unit with a formal decimal type parameter. To be compliant with the Information Systems Annex a compiler must implement decimal types and must also allow digits values up to at least 18. We had considered requiring support for decimal types (but without the 18 digit capacity) for all implementations. However, this was judged a heavy implementation burden for a facility whose usage is fairly specialized. == <span id="2">F.2 Edited Output</span> == A facility essential for financial and other Information Systems applications and long established in COBOL is the ability for the programmer to dictate the appearance of numeric data as character strings, for example for reports or for display to human readers. Known as edited output, such a facility allows control over the placement and form of various elements: * The sign; * The radix mark, which separates the integer part of the number from the fraction; * The digits separator, which separates groups of digits to improve readability; * The currency symbol; * The treatment of leading zeros, for example whether they should appear explicitly as '0' characters, as blank space, or as a string of occurrences of a "check protection" character. COBOL's approach is to associate a "picture string" with the target data item for the edited output string. When a numeric value is moved to that target item, the associated picture determines the form of the output string. For example: <syntaxhighlight lang="Ada"> 05 OUTPUT-FIELD PIC S$,ZZ9.99. 05 DATA-1 PIC S9999V99 VALUE -1234.56. ... MOVE DATA-1 TO OUTPUT-FIELD.</syntaxhighlight> The contents of OUTPUT-FIELD after the move are "-$bb1,234.56" where 'b' denotes the blank character. === <span id="2-1">F.2.1 General Approach</span> === Textual I/O for decimal types is obtained in the same fashion as for other numeric types, by generic instantiation. The generic package Decimal_IO in Text_IO supplies Get and Put procedures for a decimal type with analogous effects to Get and Put in Text_IO.Fixed_IO for an ordinary fixed point type. Supplementing these facilities is a child package Text_IO.Editing in the Information Systems Annex, which provides several facilities: * A private type Picture and associated operations. A Picture object encodes the formatting information supplied in a "picture string" concerning the placement of so-called "editing characters" in an output string; * Constants for the default localization elements. These elements comprise the currency string, and the characters for fill of leading zeros, for digits separation, and for the radix mark; * A generic package Decimal_Output allowing COBOL-style edited output for decimal types. The Decimal_Output package supplies an Image function and several Put procedures, each taking an Item parameter (of the decimal type), a Pic parameter (of type Picture), and parameters for the localization effects. The default values for the localization parameters can be supplied as generic parameters; if not, then the default values declared in the enclosing package Text_IO.Editing are used. An alternative that we considered for the picture parameter was to have it directly as a String, but this would make optimizations difficult. Hence package Editing supplies a private type Picture, conversion functions between String and Picture, and a function Valid that checks a string for well-formedness. Since picture strings are dynamically computable, the approach provides substantial flexibility. For example, an interactive program such as a spreadsheet could obtain the picture string at run time from the user. On the other hand, if the programmer only needs static picture strings, the compiler can exploit this and produce optimized inline expansions of calls of the edited output subprograms. An example of a typical usage style is as follows: <syntaxhighlight lang="Ada"> with Text_IO.Editing; procedure Example is use Text_IO.Editing; type Salary is delta 0.01 digits 9; package Salary_Output is new Decimal_Output(Salary); S : Salary; S_Pic : constant Picture := To_Picture("$*_***_**9.99"); begin S := 12345.67 Salary_Output.Put(S, S_Pic); -- Produces "$***12,345.67" end Example;</syntaxhighlight> We recognize that someone coming to Ada from COBOL may find the style somewhat unusual. In COBOL, performing edited output involves simply defining a picture and doing a MOVE, whereas in Ada 95 it is necessary to instantiate a generic, convert a string to a private type, and invoke a subprogram. However, this is principally a training and transition issue, which experience has shown to be solvable via an appropriate pedagogical style. Moreover, generics and private types are features of Ada that all programmers will need to understand and employ. Since these features apply naturally to the problem of edited output, there is little point in trying to disguise this. === <span id="2-2">F.2.2 Relationship to COBOL Edited Output</span> === There are several reasons for basing the Ada 95 edited output facility directly on COBOL. First, the programmer population toward whom Ada 95's information systems support is targeted comprises largely COBOL users. Second, although enhanced edited output mechanisms have appeared in modern spreadsheet utilities, their proprietary nature makes commercial products an unappealing candidate as a source of specific features. Still there was the issue of whether to adopt COBOL's "picture" approach as closely as possible, or to use it more loosely as the basis for a more comprehensive but possibly incompatible facility. We have taken the former approach for several reasons: * To redesign the edited output facility from starting principles would have required a detailed review of the entire history behind the current COBOL standard's approach, an effort that would have been outside the scope of the Ada 9X project. * Basing the Ada 95 edited output rules directly on COBOL obviously reduces the learning curve for COBOL programmers. As a result the rules for picture string formation and interpretation for edited output are identical to those in ISO standard COBOL, except for the following: * In Ada the picture characters for currency symbol, digits separator, and radix mark are not overridable. '$' and '#' are the currency symbols, '_' is the digits separator and '.' is the radix mark. No other characters can be used for these purposes in the picture string. * On the other hand, Ada provides more flexibility than COBOL in the run-time localization of currency symbol, digits separator, radix mark, and "fill character" (also known as the "check protection character"). The programmer can arrange localization by passing explicit parameters to the edited output subprograms, or by instantiating the generic Decimal_Output package with values to be used as defaults for the localization elements. * The currency symbol can be localized to a multi-character string; each of the other localization elements can be localized to any single character. The first (or only) occurrence of '$' in a picture string represents as many positions in the edited output result as there are characters in the current currency string. Subsequent occurrences of the symbol represent just one position in the edited output string. * Ada allows a multi-character currency substring of the picture string to stand for a substring with the same length in the edited output string, if '#' is the currency symbol. This "length invariant" property can be useful in programs that need to deal with different currencies. * Ada also allows the use of parentheses for negative quantities in the edited output string. The angle bracket characters '<' and '>' in the picture string denote positions where '(' and ')' can appear in the edited output. (The parentheses characters themselves have other meaning in picture strings, surrounding a count indicating repetition of the preceding picture character as in COBOL. The angle brackets were chosen since they look enough like parentheses to remind the user of their effect.) * Ada allows the currency symbol to the right of the number as well as to the left. There are several reasons why we have not adopted the COBOL-style permission to provide a single-character replacement in the picture string for the '$' as currency symbol, or to interchange the roles of '.' and ',' in picture strings: * It would have introduced considerable complexity into Ada, as well as confusion between run-time and compile-time character interpretation, since picture strings are dynamically computable in Ada, in contrast with COBOL. * Ada's rules for real literals provide a standard and natural interpretation of '_' as digits separator and '.' for radix mark; it is not essential to allow these to be localized in picture strings, since Ada does not allow them to be localized in real literals. * The COBOL restriction for the currency symbol in a picture string to be replaced by a single character currency symbol is a compromise solution. In any event a mechanism is needed to localize the edited output to be a multi-character currency string. Allowing a single- character localization for the picture character, and a multiple- character localization for the currency string, would be an unwelcome complication. The enhancement of the picture string form to allow parentheses for negative quantities is not in the current COBOL standard, but it is a real need in many financial applications. Thus the additional rules were judged to be worth the cost. The approach to currency symbol localization is consistent with the directions that the ISO COBOL standardization group (WG4) is taking [Sales 92]. Thus we are attempting to preserve compatibility not just with the existing COBOL standard but also with the version currently under development. In COBOL, the BLANK WHEN 0 clause for a numeric edited item interacts with edited output. For example, if OUTPUT-ITEM is defined as follows: <syntaxhighlight lang="Ada"> 05 OUTPUT-ITEM PIC -9999.99 BLANK WHEN 0. ... MOVE 0 to OUTPUT-ITEM.</syntaxhighlight> then OUTPUT-ITEM will contain a string of 8 blanks. In the absence of the BLANK WHEN 0 clause, OUTPUT-ITEM would contain "b0000.00". The effect of the BLANK WHEN 0 clause is considered in Ada to be part of the Picture value; thus the function To_Picture takes not just a picture string but also a Boolean value reflecting whether a 0 value is to be treated as all blanks. The edited output rules in the Ada standard are given by a combination of BNF (for "well-formed picture strings") and expansion rules that define the edited output of a non-terminal in terms of the edited output for the right sides of the rules. We had considered defining the rules instead by a direct reference to the COBOL standard, but that would have had two undesirable consequences. First, it would have required the reader to be familiar with a rather complicated section of a document (the COBOL standard) that would not necessarily be easily accessible. Second, the reference would become obsolete when the COBOL standard is revised. === <span id="2-3">F.2.3 Example</span> === The following example illustrates edited output with localization: <syntaxhighlight lang="Ada"> with Text_IO.Editing; procedure Example is use Text_IO.Editing; type Money is delta 0.01 digits 8; package Money_Output is new Decimal_Output(Money); package Money_Output_FF is new Decimal_Output( Money, Default_Currency => "FF", Default_Fill => '*', Default_Separator => '.', Default_Radix_Mark => ','); Amount : Money range 0.0 .. Money'Last; Amount_Pic : constant Picture := To_Picture("$$$$_$$9.99"); begin Amount := 1234.56; Money_Output.Put(Item => Amount, Pic => Amount_Pic ); -- Outputs the string "bb$1,234.56" -- where 'b' designates the space character Money_Output_FF.Put(Item => Amount, Pic => Amount_Pic ); -- Outputs the string "bbFF1.234,56" Money_Output.Put(Item => Amount, Pic => Amount_Pic, Currency => "CHF", Fill => '*', Separator => ',', Radix_Mark => '.' ); -- Outputs the string "bbCHF1,234.56" Money_Output.Put(Item => Amount, Pic => To_Picture("####_##9.99") Currency => "CHF", Fill => '*', Separator => ',', Radix_Mark => '.' ); -- Outputs the string "CHF1,234.56" end Example;</syntaxhighlight> == <span id="3">F.3 Requirements Summary</span> == The facilities of the Information Systems Annex relate to the requirements in 10.1 (Handling Currency Quantities for Information Systems), 10.2 (Compatibility with Other Character Sets), 10.3 (Interfacing with Data Base Systems), and 10.4 (Common Functions). The requirement * R10.1-A(1) - Decimal-Based Types is satisfied by the Ada 95 decimal fixed point type facility. The study topic * S10.1-A(2) - Specification of Decimal Representation is met in part by the Machine_Radix attribute definition clause. The study topic * S10.2-A(1) - Alternate Character Set Support is satisfied in part by the permission of an implementation to localize the declaration of type Character. The study topic * S10.3-A(1) - Interfacing with Data Base Systems is satisfied in part by the provision of decimal types and also the package Interfaces.COBOL (see B.3). The study topic * S10.4-A(2) - String Manipulation Functions is met in part by the edited output facilities. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p3-e|Previous]] | [[Guide:9x_rationale/rat95-p3-g|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=Annex F. Information Systems}} ohqyiyshhkrayjho3zfo2tdlcpez5zw Guide:9x rationale/rat95-p3-g 4200 351 1859 1842 2019-04-20T16:20:04Z WikiVisor 11 Text replacement - "|Next]]" to "|Next]]</div>" wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p3-f|Previous]] | [[Guide:9x_rationale/rat95-p3-h|Next]]</div> The Numerics Annex addresses the particular needs of the numerically intensive computing community. Like the other specialized needs annexes, support of this annex is optional. The annex covers the following topics * Various generic packages are provided for the manipulation of complex numbers including the computation of elementary functions and input-output. * The annex specifies two modes of operation, a strict mode in which certain accuracy requirements must be met and the relaxed mode in which they need not be met. The accuracy requirements for the strict mode cover both arithmetic and the noncomplex elementary functions and random number generation of the core language. * The models of floating point and fixed point arithmetic applicable to the strict mode are described; these differ from those of Ada 83. * Various model attributes are defined which are applicable to the strict mode for floating point types; again these differ from Ada 83. Note that since the elementary functions and random number generation are in the core language, they and their accuracy requirements are discussed elsewhere (see A.3). The majority of attributes (including the so-called "primitive function" attributes) are also defined in the core language. Implementations conforming to the numerics annex should also support the package Interfaces.Fortran, which is discussed in B.4. == <span id="1">G.1 Complex Arithmetic</span> == Several application areas depend on the use of complex arithmetic. Complex fast Fourier transforms are used, for example, in conjunction with radar and similar sensors; conformal mapping uses complex arithmetic in fluid-flow problems such as the analysis of velocity fields around airfoils; and electrical circuit analysis is classically modelled in terms of complex exponentials. The Ada 95 facilities for complex arithmetic consist of the generic packages <syntaxhighlight lang="Ada"> Numerics.Generic_Complex_Types Numerics.Generic_Complex_Elementary_Functions Text_IO.Complex_IO</syntaxhighlight> which are children of Ada. === <span id="1-1">G.1.1 Complex Types and Arithmetic Operations</span> === When first designed, Numerics.Generic_Complex_Types was patterned after the version of the generic package, Generic_Complex_Types, that was then being developed in the SIGAda Numerics Working Group for proposal as an ISO standard for Ada 83. At that time, roughly mid-1992, the latter defined a complex type as well as types for vectors and matrices of complex components, together with a large set of scalar, vector, and matrix operations on those types. A decision was made to abbreviate the Ada 95 package by omitting the vector and matrix types and operations. One reason was that such types and operations were largely self-evident, so that little real help would be provided by defining them in the language. Another reason was that a future version of Ada might add enhancements for array manipulation and so it would be inappropriate to lock in such operations prematurely. The initial design for Numerics.Generic_Complex_Types also inherited a rather pedestrian approach to defining the complex type from the same proposed standard. The Ada 9X Distinguished Reviewers recommended a different approach that enabled the writing of expressions whose appearance closely matches that of the standard mathematical notation for complex arithmetic. The idea was to define not just a complex type, but also a pure imaginary type Imaginary and a constant i of that type; operations could then easily be defined to allow one to write expressions such as <syntaxhighlight lang="Ada"> 3.0 + 5.0*i -- of type Complex</syntaxhighlight> which has the feel of a complex literal. Another advantage of this approach is that by providing mixed mode operations between complex and imaginary as well as between complex and real, it is possible to avoid unnecessary arithmetic operations on degenerate components. Moreover, avoiding such unnecessary operations is crucial in environments featuring IEEE arithmetic [IEC 89], where signed infinities can arise and can be used in meaningful ways. (Ada 95 does not support infinite values, but in an implementation in which the Machine_Overflows attribute is False, an overflow or a division by zero yields an implementation-defined result, which could well be an infinite value. Thus a future Ada binding to IEEE arithmetic could capitalize on exactly that opportunity by providing semantics of arithmetic with infinities as in [IEC 89].) To see how avoiding unnecessary operations provides more than just a gain in efficiency, consider the multiplication of a complex value x + iy by a pure imaginary value iv. The result of the multiplication should, of course, be -vy + ivx. Without a pure imaginary type, we have to represent the pure imaginary value as the complex value 0.0 + iv and perform a full complex multiplication, yielding (0.0x-vy) + i(vx+0.0y). This, of course, reduces to the same value as before, unless x or y is an infinity. However, if x is infinity, y is finite, and v is nonzero (say, positive), the result should be -vy + i*infinity, but instead we get NaN + i*infinity, since multiplication of zero and infinity yields a NaN ("Not-a-Number") in IEEE arithmetic, and NaNs propagate through addition. See [Kahan 91]. A similar situation can be demonstrated for the multiplication of a complex value and a pure real value, but in that case we expect to have such a mixed-mode operation, and if we use it the generation of the NaN is avoided. Another subtle problem occurs when the imaginary value iv is added to the complex value x + iy. The result, of course, should be x + i(y+v). Without an imaginary type, we have to represent the imaginary value as the complex value 0.0 + iv and perform a full complex addition, yielding (x+0.0) + i(y+v). The problem here [Kahan 91] is that if x is a negative zero, the real component of the result of the full complex addition will have the wrong sign; it will be a positive zero instead of the expected negative zero. This phenomenon, also a consequence of the rules of IEEE arithmetic, can and does occur in existing Ada 83 implementations, since it does not require an extension permitting infinities. In both cases, the pure imaginary type gives the programmer the same opportunity to avoid problems in mixed complex/imaginary arithmetic as in mixed complex/real arithmetic. With the inclusion of a pure imaginary type and mixed complex/imaginary operations, the generic complex types package in Ada 95 could have diverged from the proposed standard under development in the SIGAda NumWG. This was averted, however, when the working group changed its proposed standard to agree with the Ada 95 version. It also removed the vector and matrix types and operations from its generic complex types package and put them in a separate package. And so, Numerics.Generic_Complex_Types is just a slight variation of the generic package proposed for standardization for Ada 83. (The differences have to do with the use of Real'Base, rather than just Real, as the subtype mark for the components of the complex type and for the parameter and result subtypes of some of the operations, Real being the name of the generic formal parameter. This capability is lacking in Ada 83.) The type Complex defined by Numerics.Generic_Complex_Types is a visible record type thus <syntaxhighlight lang="Ada"> type Complex is record Re, Im: Real'Base; end record;</syntaxhighlight> corresponding to the cartesian representation of a complex value. We have made the type visible to allow one to write complex "literals" using aggregate notation as in some other languages (and to ensure efficiency). The cartesian representation was chosen over a polar representation to avoid canonicalization problems and because it is normal practice. An explicit choice of representation is required in any case to give meaning to the accuracy requirements. Operations are provided, however, to compute the modulus (length) and argument (angle) of a complex value and to construct a complex value from a given modulus and argument, so that it is easy to convert between the built-in cartesian representation and a polar representation, if needed. It is perhaps unusual that the components of the complex type are of the unconstrained subtype of the generic formal parameter, Real'Base, rather than just Real, but this is intended to increase the chances of being able to deliver the result computed by a complex arithmetic operation even when their operands belong to some restricted domain. This provides behavior analogous to that of the elementary functions (see A.3.1), which also yield results in the unconstrained subtype of the relevant generic formal parameter. It is also similar to the behavior of the predefined arithmetic operations, which yield results of an unconstrained subtype, even when their operands are of a constrained subtype. A consequence is that we cannot create complex types with constrained components, but that does not seem so severe in view of the fact that applications of complex arithmetic typically have a naturally circular domain, rather than a rectangular domain. The type Imaginary, on the other hand, is private, its full type being derived from Real'Base thus <syntaxhighlight lang="Ada"> type Imaginary is new Real'Base;</syntaxhighlight> Making it private prevents the implicit conversion of a real literal to the type Imaginary, which would be available if Imaginary were visibly derived from Real'Base. This avoids various ambiguous expressions and enables overload resolution to work properly. It has the additional advantage of suppressing the implicit declaration of multiplying operators for the Imaginary type, which would incorrectly yield a result of the type Imaginary, when it should be Real'Base. Operations with the correct result type such as <syntaxhighlight lang="Ada"> function "*" (Left, Right: Imaginary) return Real'Base;</syntaxhighlight> are, of course, explicitly declared. The same benefits could have been achieved by defining Imaginary as a visible record type with a single component, but the method chosen prevents the writing of expressions containing pure imaginary values as aggregates, whose meaning would not be intuitively obvious. The imaginary constant i (and its equivalent, j, provided for the engineering community), has the value 1.0, and so unoptimized expressions like 5.0*i will have the proper numerical value. However, it is expected that compilers will optimize this and effectively convert the real literal 5.0 to the imaginary type. Similarly, an expression such as 3.0 + 5.0*i can be optimized to perform no arithmetic at all since it is functionally equivalent to the aggregate (3.0, 5.0) of the type Complex. Note that there are also constructor and selector functions such as Compose_From_Cartesian. The following expressions are thus equivalent <syntaxhighlight lang="Ada"> X + i*Y -- using operators (X, Y) -- using an aggregate Compose_From_Cartesian(X, Y) -- using the constructor</syntaxhighlight> The constructor function has the merit that it can be used as a generic actual parameter, if it should be necessary. Nongeneric equivalents of Numerics.Generic_Complex_Types are provided corresponding to instantiations with the predefined types Float, Long_Float and so on with names such as <syntaxhighlight lang="Ada"> Numerics.Complex_Types -- for Float Numerics.Long_Complex_Types -- for Long_Float</syntaxhighlight> This means that applications can effectively treat single-precision complex, double-precision complex, etc., as predefined types with the same convenience that is provided for the predefined floating point types (or, more importantly, so that independent libraries assuming the existence and availability of such types without the use of generics can be constructed and freely used in applications). The nongeneric forms also have the advantage that Fortran programmers migrating to Ada do not have to learn generics in order to use complex arithemtic. Accuracy requirements are generally specified for the complex arithmetic operations only in the strict mode. Nevertheless, certain special cases are prescribed to give the exact result even in the relaxed mode, ensuring high quality at negligible implementation cost. Examples are where one operand is pure real or pure imaginary. (These prescribed results are likely to be achieved even without special attention by the implementation.) Accuracy requirements are not given for exponentiation of a complex operand by an integer, owing to the variety of implementations that are allowed (ranging from repeated complex multiplication to well-known operations on the polar representation). Note finally that spurious overflows (those occurring during the computation of an intermediate result, when the final result, or its components, would not overflow) are not allowed. Thus, implementations of complex multiplication and division need to be somewhat more sophisticated than the textbook formulae for those operations. === <span id="1-2">G.1.2 Complex Elementary Functions</span> === The package Numerics.Generic_Complex_Elementary_Functions differs from the corresponding proposed standard for Ada 83 by taking advantage of the formal package parameter facility of Ada 95. Thus it imports the one parameter which is an instance of Numerics.Generic_Complex_Types instead of the complex type and a long list of operations exported by such an instance. In the Ada 83 version, the complex type has to be imported as a private type, and implementations of the complex elementary functions there have no choice but to use the imported selector functions, Re and Im, to extract the real and imaginary components of a complex value, and the imported constructor function, Compose_From_Cartesian, to assemble such components into a complex value. Implementations of the Ada 95 version see that type as the record type that it is, allowing more efficient composition and decomposition of complex values; they also have available the complete set of operations, not just the partial (albeit long enough) list of operations imported in the Ada 83 version. Nonngeneric equivalents of Numerics.Generic_Complex_Elementary_Functions are also provided for each of the predefined floating point types. The overloading of the Exp function for a pure imaginary parameter is provided to give the user an alternative way to construct the complex value having a given modulus and argument. Thus, we can write either <syntaxhighlight lang="Ada"> Compose_From_Polar(R, Theta)</syntaxhighlight> or <syntaxhighlight lang="Ada"> R * Exp(i * Theta).</syntaxhighlight> The treatment of accuracy requirements and prescribed results for the complex elementary functions is analogous to that discussed above for the complex arithmetic operations. However, since the avoidance of spurious overflows is difficult and expensive to achieve in several of the functions, it is explicitly permitted, allowing those functions to be implemented in the obvious way. No accuracy requirement is imposed on complex exponentiation (the operator "**") by a pure real, pure imaginary, or complex exponent, because the obvious implementation in terms of complex exponentials and logarithms yields poor accuracy in some parts of the domain, and better algorithms are not available. === <span id="1-3">G.1.3 Complex I/O</span> === Complex I/O is performed using the procedures in the generic child package, Text_IO.Complex_IO. As with Numerics.Generic_Complex_Elementary_Functions, the user instantiates this generic package with an instance of Numerics.Generic_Complex_Types. (Note that nongeneric equivalents do not exist.) A fundamental design decision underlying Text_IO.Complex_IO is that complex values are represented on the external medium in parenthesized aggregate notation, as in Fortran list-directed I/O. This is the format produced on output, and it is the format expected on input, except that the comma, the parentheses, or both may be omitted when the real and imaginary components are separated by appropriate white space. (This allows the reading of existing Fortran files containing complex data written by a variety of techniques.) An implementation of Text_IO.Complex_IO can easily be built around an instance of Text_IO.Float_IO for Real'Base; the optional parentheses on input requires the use of the procedure Text_IO.Look_Ahead; see A.4.2. Text_IO.Complex_IO defines similar Get and Put procedures to Text_IO.Float_IO with analogous semantics. The only somewhat arbitrary decision that we made concerns the mechanism for filling the target string in the case of output to a string. The question is where to put any extra blanks that are needed to fill the string. A rule like the one for Text_IO.Float_IO.Put to a string might read: <syntaxhighlight lang="Ada"> Outputs the value of the parameter Item to the given string, following the same rule as for output to a file, using a value for Fore such that the sequence of characters output exactly fills, or comes closest to filling, the string; in the latter case, the string is filled by inserting one extra blank immediately after the comma.</syntaxhighlight> Such a rule essentially allocates the available space equally to the real and imaginary components. But that is not desirable when the value of the Exp parameter is zero and the two components of the Item parameter have disparate magnitudes, so that the integer part of one requires more characters than the integer part of the other. To accommodate this case, we have chosen a rule, simple to implement, that left justifies the left parenthesis, real component, and comma and right justifies the imaginary component and right parenthesis. All the extra spaces are placed between the comma and the imaginary component; they are available to accommodate either component, should it be unusually long. If strings produced by this rule are eventually displayed in the output, the real and imaginary components will not line up in columns as well as with the previously cited rule, but it can be argued that output to a string is intended for further computation, rather than for display. Early implementation experience indicated that it might also have been profitable to consider yet another rule for output to a string, namely, that all the components be right justified, with all the padding placed at the beginning of the string. This rule would be extremely easy to implement if Text_IO.Float_IO.Put to a string (which right justifies its output in the target string), had an additional out parameter which gave the index of the first non-blank character that it put into the output string. == <span id="2">G.2 Floating Point Machine Numbers</span> == Many of the attributes of floating point types are defined with reference to a particular mathematical representation of rational numbers called the canonical form, which is defined, together with those attributes, in the Predefined Language Environment. The definitions clarify certain aspects of the floating point machine numbers. Several new representation-oriented attributes of floating point machine numbers are also defined, together with a group of functional attributes called the "primitive function" attributes. === <span id="2-1">G.2.1 Clarification of Existing Attributes</span> === The machine numbers of a floating point type are somewhat informally defined as the values of the type that are capable of being represented to full accuracy in all unconstrained variables of the type. The intent is to exclude from the set of machine numbers any extra-precise numbers that might be held in extended registers in which they are generated as a consequence of performing arithmetic operations. In other words, it is the stored values that matter and not values generated as intermediate results. The representation-oriented attributes S'Machine_Mantissa, S'Machine_Emin, and S'Machine_Emax of a floating point subtype S are defined in terms of bounds on the components of the canonical form. The attribute S'Machine_Radix is the radix of the hardware representation of the type and is used as the radix of the mantissa in the canonical form. These definitions clarify that S'Machine_Emin is the minimum canonical-form exponent such that all numbers expressible in the canonical form, with that exponent, are indeed machine numbers. In other words, S'Machine_Emin is determined by the normalized floating point numbers only; the presence of IEEE denormalized numbers in the implementation does not affect (reduce) the value of S'Machine_Emin. A consequence of this definition of S'Machine_Emin is that the primitive function attribute S'Exponent(X) can yield a result whose value is less than that of S'Machine_Emin if X is denormalized. The definitions also clarify that S'Machine_Emax is the canonical-form exponent of the machine number of largest magnitude whose negation is also a machine number; it is not the canonical-form exponent of the most negative number on radix-complement machines. Alternative definitions for S'Machine_Emin and S'Machine_Emax were considered, namely, that they yield the minimum and maximum canonical- form exponents for which some combination of sign, exponent, and mantissa yields a machine number. This would have allowed denormalized numbers to be accommodated without relaxing the normalization requirement (see the next section) in the definition of the canonical form, and the result of S'Exponent(X) would have necessarily remained within the range S'Machine_Emin .. S'Machine_Emax, which is appealing. Nevertheless, it was judged to be too much of a departure from current practice and therefore too likely to cause compatibility problems. === <span id="2-2">G.2.2 Attributes Concerned With Denormalized Numbers and Signed Zeros</span> === Many implementations of Ada do provide IEEE denormalized numbers and "gradual underflow", as defined in [IEC 89], even though the full capabilities of IEEE arithmetic are not provided and must await an Ada binding to IEEE arithmetic. (Denormalized numbers come for free with IEEE hardware chips and have always been consistent with the Ada model of floating point arithmetic; it would require extra code generation to suppress them.) Since denormalized numbers are capable of being stored in variables of an unconstrained floating point type, they are machine numbers. What characterizes the denormalized numbers is that they can be represented in the canonical form with an exponent of S'Machine_Emin, provided that the normalization requirement on the mantissa is relaxed. If every nonzero number expressible in this weakened canonical form is a machine number of the subtype S, then the new representation-oriented attribute, S'Denorm, is defined to have the value True. Many implementations also provide IEEE signed zeros, which similarly come for free. The new representation-oriented attribute, S'Signed_Zeros, is True if signed zeros are provided by the implementation and used by the predefined floating point operations as specified in [IEC 89]. The idea behind a signed zero is that a zero resulting from a computation that underflows can retain the sign of the underflowing quantity, as if the zero represented an infinitesimal quantity instead; the sign of a zero quantity, interpreted as if it were infinitesimal, can then affect the outcome of certain arithmetic operations. Moreover, various higher-level operations, such as the elementary functions, are defined to yield zeros with specified signs for particular parameter values when the Signed_Zeros attribute of the target type is True. And indeed, some such operations, for example, Arctan and Arccot produce different (nonzero) results in certain cases, depending on the sign of a zero parameter, when Signed_Zeros is True. In some cases, no conventions exist yet for the sign of a zero result. We do not specify the sign in such cases, but instead require the implementation to document the sign it produces. Also, we have not carried over into the facilities for complex arithmetic and the complex elementary functions the specifications for the signs of zero results (or their components) developed by the SIGAda NumWG, largely because of their excessive complexity. Instead we merely suggest that implementations should attempt to provide sensible and consistent behavior in this regard (for example, by preserving the sign of a zero parameter component in a result component that behaves like an odd function). === <span id="2-3">G.2.3 The Primitive Function Attributes</span> === A group of attributes of floating point types called the "primitive function" attributes is provided, in support of Requirement R11.1-A(1), to facilitate certain operations needed by the numerical specialists who develop mathematical software libraries such as the elementary functions. These attributes are modelled on the various functions in the standard package Generic_Primitive_Functions for Ada 83 [ISO 94b], but made available in the language as attributes of a floating point subtype rather than as functions in a generic package. These attributes support * error-free scaling by a power of the hardware radix, * decomposition of a floating point quantity into its components (mantissa and exponent), and construction of a floating point quantity from such components, * calculation of exact remainders, and various directed rounding operations. All of these attributes yield the mathematically specified results, which are either machine numbers or have the accuracy of the parameters. For a general rationale for the design of the primitive functions, see [Dritz 91b]. (Some of the attributes have different names from the corresponding functions in [ISO 94b], since some of the names in the latter had already been used for other new, but unrelated, attributes.) The casting of the primitive functions as attributes, rather than as functions in a generic package, befits their primitive nature and allows them to be used as components of static expressions, when their parameters are static. The Exponent and Fraction attributes decompose a floating point number into its exponent and (signed) fraction parts. (These attributes, along with Scaling and Leading_Part, are useful in the argument reduction step of certain kinds of function approximation algorithms in high-quality mathematical software; Scaling and Compose are similarly useful in the final result assembly steps of such algorithms.) T'Exponent(X) is defined in such a way that it gives an indication of the gross magnitude of X, even when X is denormalized. In particular, if X is repetitively scaled down by a power of the hardware radix, T'Exponent(X) will decrease by one and will continue to do so (on machines with denormalized numbers) even after X becomes denormalized. T'Fraction(X) will not change as X is scaled in this way, even when X becomes denormalized. To achieve this behavior, an implementation of Exponent must do more than just pick up the hardware exponent field and unbias it, and an implementation of Fraction must do more than just pick up the hardware fraction field; both attributes must be sensitive to denormalized numbers. (Indeed, the presence or absence of the leading fraction digit is dependent on whether a number is denormalized or not, on IEEE hardware. Probably the most efficient solution to the problem is for the implementation of Exponent to scale the operand up by an appropriate fixed amount k sufficient to normalize it when the operand is in the denormalized range, as evidenced by its having the minimum exponent or by other means; extract and unbias the exponent field; and then subtract k to obtain the result. The implementation of Fraction can simply extract the fraction field after a similar scaling up when the operand is in the denormalized range, and then attach the appropriate fixed exponent; what the scaling accomplishes is the left shifting of the fraction field and the removal of its leading digit.) The Copy_Sign attribute transfers the sign of one value to another. It is provided for those applications that require a sign to be propagated, even (on machines with signed zeros) when it originates on a zero; such a need cannot be met by the predefined comparison operators and various sign-changing operations (like abs and negation), because comparison ignores the sign of zero and therefore cannot be used to determine the sign of a zero. By the same token, the implementation of Copy_Sign must likewise use some other technique, such as direct transfer of the sign bit or some other examination of the Sign operand to determine its sign. An application can use the Copy_Sign attribute to determine the sign of a zero value, when required, by transferring that sign to a nonzero value and then comparing the latter to zero. The Remainder attribute computes the remainder upon dividing its first floating point parameter by its second. It considers both parameters to be exact, and it delivers the exact remainder, even when the first parameter is many orders of magnitude larger than the second; for this reason, its implementation can be tricky. This attribute is useful in implementing the argument reduction step of algorithms for computing periodic functions (when the period is given exactly). The function T'Remainder(X, Y) is defined so that the magnitude of the result is less than or equal to half the magnitude of Y; it may be negative, even when both parameters are positive. Note that the Remainder attribute cannot be considered to be a natural extension of the predefined rem operator for floating point operands (and, indeed, that is one reason why the functionality was not made available by overloading rem). To see this, observe that <syntaxhighlight lang="Ada"> Float'Remainder(14.0, 5.0) -- yields -1.0</syntaxhighlight> whereas <syntaxhighlight lang="Ada"> 14 rem 5 -- yields 4</syntaxhighlight> and so are quite different. The rationale for defining Remainder this way is twofold: it exhibits the behavior preferred by numerical analysts (i.e., it yields a reduced argument of generally smaller magnitude), and it agrees with the IEEE rem operator. Indeed, the latter is implemented in hardware on some machines; when available, it should certainly be used instead of the painful alternative documented in [Dritz 91b]. The functionality of the Successor and Predecessor functions of [ISO 94b] is provided by extending the existing attributes Succ and Pred to floating point types. Note that T'Succ(0.0) returns the smallest positive number, which is a denormalized number if T'Denorm is True and a normalized number if T'Denorm is False; this is equivalent to the "fmin" derived constant of LIA-1 (Language Independent Arithmetic) [ISO 93]. (Most of the other constants and operations of LIA-1 are provided either as primitive functions or other attributes in Ada 95; those that are absent can be reliably defined in terms of existing attributes.) == <span id="3">G.3 Assignments to Variables of Unconstrained Numeric Types</span> == Ada 83 did not make a distinction between unconstrained and constrained numeric subtypes. Any subtype T was considered constrained by the values given by T'First and T'Last; if no range constraint was declared for T, then T'First = T'Base'First and T'Last = T'Base'Last. It was technically not possible for a variable of an unconstrained subtype to be assigned a value outside the range T'Base'First .. T'Base'Last. This prevented the optimization of leaving a value in an extended register beyond an assignment, fulfilling subsequent references to the target variable from the register. To guarantee that the new value of the target variable after an assignment is not outside the range T'Base'First .. T'Base'Last, it is necessary in Ada 83 either to store the register into the variable's assigned storage location (if such a store operation could signal violation of the range check by generating an overflow condition) or to compare the value in the register to the values of T'Base'First and T'Base'Last; if the range check succeeds, the value in the register can be used subsequently. Ada 95 does not perform a range check on the value assigned to a variable of an unconstrained numeric subtype; consequently, such a target variable can acquire a value outside its base range (T'Base'First .. T'Base'Last). This allows the value to be retained in the register in which it was generated and never stored (if all subsequent references to the target variable can be fulfilled from the register) nor checked by comparison for inclusion in the base range. A consequence of this change, which generally allows more efficient object code to be generated, is that an Ada 83 program that raised Constraint_Error for a range violation on assignment to a variable of an unconstrained numeric subtype may raise the exception later (at a different place) or not at all. The first possibility arises because it may be necessary to store the extended register in the storage format for any of several reasons at a place far removed from the original assignment. The opportunity to raise the exception at such remote places is provided by a new rule that allows Constraint_Error to be raised at the place where a variable is referenced (fetched), if its value is outside its base range. == <span id="4">G.4 Accuracy and Other Performance Issues</span> == The Numerics Annex specifies the accuracy to be delivered by the elementary functions, the complex arithmetic operations, and the complex elementary functions, and the performance to be expected from the random number generator. It also specifies the accuracy expected of the predefined floating point and fixed point arithmetic operators. If the Numerics Annex is not implemented, the predefined arithmetic operations and the various numerical packages do not have to yield any particular language-defined accuracy or performance, except where specified outside the Numerics Annex. Even though the accuracy and performance requirements of the Numerics Annex are realistic, strict conformance may, in certain implementations, come only at a price. One or more native floating point instructions may produce slightly anomalous behavior that cannot conform to the model without some kind of sacrifice; for example, the purported maximum precision may have to be reduced, or some operations may have to be simulated in software. Similarly, achieving the specified accuracy in the elementary functions (say) may mean abandoning less accurate but much faster versions available on a hardware chip. Thus, to allow the user to trade accuracy for other considerations, the Numerics Annex specifies a pair of modes, strict mode and relaxed mode, that may be selected by the user. The accuracy and other performance requirements apply only when the strict mode is selected; the relaxed mode exempts implementations from these requirements, exactly as if the Numerics Annex had not been implemented. A program that is intended for wide distribution, and whose numerical performance is to be guaranteed and portable across implementations, must be compiled and linked in the strict mode. Its portability will clearly extend, in that case, only to implementations that support the Numerics Annex. The language does not specify how the modes should be implemented. It is clear, however, that the choice of mode can affect code generation, the values of the model-oriented attributes, and the version of the numerical libraries that is used. In implementations that meet the requirements without any undue sacrifices, or that have nothing substantial to gain from their relaxation, the two modes may, in fact, be identical. === <span id="4-1">G.4.1 Floating Point Arithmetic and Attributes</span> === The strict-mode accuracy requirements for predefined floating point arithmetic operations are based on the same kind of model that was used in Ada 83, but with several changes. The Ada 83 model of floating point arithmetic was a two-level adaptation of the "Brown Model" [Brown 81] and defined both model numbers and safe numbers. The Ada 95 model is closer to a one-level, classical Brown Model that defines only model numbers, although it innovates slightly in the treatment of the overflow threshold. The existence of both model numbers and safe numbers in Ada 83 caused confusion which hopefully will not apply to Ada 95. Note however, that the model numbers in Ada 95 are conceptually closer to the safe numbers rather than the model numbers of Ada 83 in terms of their role in the accuracy requirements. Other problems with the Ada 83 model centered around inherent compromises in the way the Brown Model was adapted to Ada 83. These compromises are eliminated in Ada 95, and other improvements are made, by * freeing the model numbers to have a mantissa length that depends only on the implementation's satisfaction of the accuracy requirements, rather than a quantized mantissa length; * defining the model numbers to have the hardware radix, rather than a fixed radix of two; * defining the model numbers to form an infinite set, and basing overflow considerations on the concept of a type's "safe range" rather than on the largest model number; * separating range and precision considerations, rather than tying them together intimately via the infamous "4B Rule" [RM83 3.5.7]; and * freeing the minimum exponent of the model numbers from a connection to the overflow threshold, allowing it to reflect underflow considerations only. We will now consider these in detail. ==== Mantissa Length ==== The Ada 83 safe numbers have mantissa lengths that are a function of the Digits attribute of the underlying predefined type, giving them a quantized length chosen from the list (5, 8, 11, 15, 18, 21, 25, ...). Thus, on binary hardware having T'Machine_Mantissa equal to 24, which is a common mantissa length for the single-precision floating point hardware type, the last three bits of the machine representation exceed the precision of the safe numbers. As a consequence, even when the machine arithmetic is fully accurate (at the machine-number level), one cannot deduce that Ada arithmetic operations deliver full machine-number accuracy. By freeing the mantissa length from quantization, tighter accuracy claims will be provable on many machines. As an additional consequence of this change, in Ada 95 the two types declared as follows <syntaxhighlight lang="Ada"> type T1 is digits D; type T2 is digits T1'Digits range T1'First .. T1'Last;</syntaxhighlight> can be represented identically. This matches one's intuition, since the declaration of T2 requests neither more precision nor more range than that of T1. In Ada 83, the chosen representations almost always differ, with T2'Base'Digits being greater than T1'Base'Digits, for reasons having nothing to do with hardware considerations. (Note that this artificial example is not intended to illustrate how one should declare two different types with the same representation.) ==== Radix ==== Using the hardware radix rather than a binary radix has two effects: * It permits practical implementations on decimal hardware (which, though not currently of commercial significance for mainstream computers, is permitted by the radix-independent IEEE floating point arithmetic standard [IEEE 87]; is appealing for embedded computers in consumer electronics; and is used in at least one such application, a Hewlett-Packard calculator); * On hexadecimal hardware, it allows more machine numbers to be classed as model numbers (and therefore to be proven to possess special properties, such as being exactly representable, contributing no error in certain arithmetic operations, and so on). As an example of the latter effect, note that T'Last will become a model number on most hexadecimal machines. Also, on hexadecimal hardware, a 64-bit double-precision type having 14 hexadecimal (or 56 binary) digits in the hardware mantissa, as on many IBM machines, has safe numbers with a mantissa length of 51 binary bits in Ada 83, and thus no machine number of this type with more than 51 bits of significance is a safe number. In Ada 95, such a type would have a mantissa length of 14 hexadecimal digits, with the consequence that every machine number with 53 bits of significance is now a model number, as are some with even more. Note that the type under discussion does not have Ada 83 safe numbers with 55 bits in the mantissa, even though that is the next possible quantized length and one which is less than that of the machine mantissa. This is because some machine numbers with 54 or 55 bits of significance do not yield exact results when divided by two and cannot therefore be safe numbers. This is a consequence of their hexadecimal normalization, and it gives rise to the phenomenon known as "wobbling precision": the hexadecimal exponent remains unchanged by the division, while the mantissa is shifted right, losing a bit at the low-order end. ==== Safe Range ==== Extending the model numbers to an infinite set is intended to fill a gap in Ada 83 wherein the results of arithmetic operations are not formally defined when they are outside the range of the safe numbers but an exception is not raised. Some of the reasons why this can happen are as follows: * the quantization of mantissa lengths may force the bounds of the range of safe numbers to lie inside the actual hardware overflow threshold; * arithmetic anomalies of one operation may require the attributes of model and safe numbers to be conservative, with the result that other operations exceed the minimum guaranteed performance; * the provision and use of extended registers in some machines moves the overflow threshold of the registers used to hold arithmetic results well away from that of the storage representation; * the positive and negative actual overflow thresholds may be different, as on radix-complement machines. The change means, of course, that one can no longer say that the model numbers of a type are a subset of the machine numbers of the type. As a consequence we have introduced the concept of the "safe range" of a type in Ada 95. This is the subrange of the type's base range that is guaranteed to be free of overflow; in Ada 83 terms, this subrange was the range of the type's safe numbers. Thus, in Ada 95 the the model numbers of a type within the type's safe range are indeed a subset of the machine numbers of the type. By continuing the model numbers beyond the safe range of a type, we can say that an operation whose result interval (defined, as usual, in terms of model numbers) transcends the safe range of the result type either raises Constraint_Error, signalling overflow, or delivers a value from that result interval (provided the Machine_Overflows attribute is True for the type). In Ada 83, the result when an exception was not raised was completely implementation defined in this case. Of course, it continues to be implementation defined when the Machine_Overflows attribute is False for the type. Incidentally, the safe range of a type has bounds characterized by two independent attributes, Safe_First and Safe_Last. In Ada 83, the range of safe numbers of a type was necessarily symmetric, with its upper bound being given by the value of the Safe_Large attribute. This was necessary, because Safe_Large was itself defined in terms of Safe_Emax, which gave the maximum exponent of the safe numbers. Because the model numbers no longer have a finite range, we no longer talk about the maximum exponent of the model numbers, and in fact there is no longer such an atttribute. Allowing the safe range to be asymmetric accommodates radix-complement machines better than Ada 83; in fact, it removes another impediment to the identical representation of the types T1 and T2 in the example given earlier. ==== The 4B Rule ==== Separating range and precision considerations is equivalent to dropping the "4B Rule" as it applies to the predefined types. There is however a "4D Rule" which affects the implementation's implicit selection of an underlying representation for a user-declared floating point type lacking a range specification, providing in that case a guaranteed range tied to the requested precision. The change in the application of the 4B Rule allows all hardware representations to be accommodated as predefined types with attributes that accurately characterize their properties. Such types are available for implicit selection by the implementation when their properties are compatible with the precision and range requested by the user; but they remain unavailable for implicit selection, in the absence of an explicit range specification, exactly as in Ada 83. The 4D Rule says that the representation chosen for a floating point type declared with a decimal precision of d, but lacking a range specification, must provide a safe range of at least -10.04d .. 10.04d. If the type declaration includes a range specification, the safe range need only cover the specified range. The 4B Rule was introduced in Ada 83 in order to define the model numbers of a type entirely as a function of a single parameter (the requested decimal precision). By its nature, the rule potentially precludes the implementation of Ada in some (hypothetical) environments; in other (actual) environments, it artificially penalizes some hardware types so strongly that they have only marginal utility as predefined types available for implicit selection and may end up being ignored by the vendor. Such matters are best left to the judgment of the marketplace and not dictated by the language. The particular minimum range required in Ada 83 (as a function of precision) is furthermore about twice that deemed minimally necessary for numeric applications [Brown 81]. Among implementations of Ada 83, the only predefined types whose characteristics are affected by the relaxation of the 4B Rule are DEC VAX D-format and IBM Extended Precision, both of which have a narrow exponent range in relation to their precision. In the case of VAX D-format, even though the hardware type provides the equivalent of 16 decimal digits of precision, its narrow exponent range requires that the Digits attribute for this type be severely penalized and reported as 9 in Ada 83; the Mantissa attribute is similarly penalized and reported as 31, and the other model attributes follow suit. In Ada 95, in contrast, the Digits attribute of this predefined type would have a truthful value of 16, the Model_Mantissa attribute (corresponding to Ada 83's Mantissa attribute, but interpreted relative to the hardware radix rather than a fixed radix of two) would have a value of 56, and the other model-oriented attributes would accurately reflect the type's actual properties. A user-declared floating point type requesting more than 9 digits of precision does not select D-format as the underlying representation in Ada 83, but instead selects H-format; in Ada 95, it still cannot select D-format if it lacks a range specification (because of the effect of the new 4D Rule), but it can select D-format if it includes an explicit range specification with sufficiently small bounds. The IBM Extended Precision hardware type has an actual decimal precision of 32, but the 4B Rule requires the value of its Digits attribute to be severely penalized and reported as 18 in Ada 83, only three more than that of the double-precision type. Supporting this type allows an Ada 83 implementation to increase System.Max_Digits from 15 to 18, a marginal gain and perhaps the reason why it is rarely supported. In Ada 95, on the other hand, such an implementation can support Extended Precision with a Digits attribute having a truthful value of 32, though System.Max_Digits must still be 18. Although a floating point type declaration lacking a range specification cannot request more than 18 digits on this machine, those including an explicit range specification with sufficiently small bounds can do so and can thereby select Extended Precision. Note that the named number System.Max_Base_Digits has been added to Ada 95; it gives the maximum decimal precision that can be requested in a type declaration that includes a range specification. In IBM systems having the Extended Precision type, the value of this named number can be 32. ==== Minimum Exponent ==== Freeing the minimum exponent of the model numbers to reflect only underflow considerations removes another compromise made necessary in Ada 83 by defining the model numbers of a type in terms of a single parameter. The minimum exponent of the model or safe numbers of a type in Ada 83 is required to be the negation of the maximum exponent (thereby tying it implicitly both to the overflow threshold and, through the 4B Rule, to the precision of the model numbers). One consequence of this is that Ada 83's range of safe numbers may need to be reduced simply to avoid having the smallest positive safe number lie inside the implementation's actual underflow threshold. Such a reduction gives yet another way of obtaining values outside the range of safe numbers without raising an exception. Another consequnce is that the smallest positive safe number may, on the other hand, have a value unnecessarily greater than the actual underflow threshold. This change therefore allows more of the machine numbers to be model numbers, allowing sharper accuracy claims to be proved. ==== Machine and Model Numbers ==== Consideration was given to eliminating the model numbers and retaining only the machine numbers. While this would further simplify the semantics of floating point arithmetic, it would not eliminate the interval orientation of the accuracy requirements if variations in rounding mode from one implementation to another and the use of extended registers are both to be tolerated. It would simply substitute the machine numbers and intervals for the model numbers and intervals in those requirements, but their qualitative form would remain the same. However, rephrasing the accuracy requirements in terms of machine numbers and intervals cannot be realistically considered, since many platforms on which Ada has been implemented and might be implemented in the future could not conform to such stringent requirements. If an implementation has clean arithmetic, its model numbers in the safe range will in fact coincide with its machine numbers, and an analysis of a program's behavior in terms of the model numbers will not only have the same qualitative form as it would have if the accuracy requirements were expressed in terms of machine numbers, but it will have the same quantitative implications as well. On the other hand, if an implementation lacks guard digits or has genuine anomalies, its model numbers in the safe range will be a subset of its machine numbers having less precision, a narrower exponent range, or both, and accuracy requirements expressed in the same qualitative form, albeit in terms of the machine numbers, would be unsatisfiable. The values of the model-oriented attributes of a subtype S of a floating point type T are defined in terms of the model numbers and safe range of the type T, when the Numerics Annex is implemented; this is true even in the relaxed mode. (Some of these attributes have partially implementation-defined values if the Numerics Annex is not implemented.) Although these attributes generally have counterparts in Ada 83, their names are new in Ada 95. The reason is that their values may be different in Ada 95. Clearly, S'Model_Mantissa and S'Model_Emin will have very different values on a nonbinary machine, since they are interpreted relative to the hardware radix, rather than a radix of two. (On a hexadecimal machine, each will have roughly a quarter of the value of the corresponding attribute in Ada 83.) S'Model_Small and S'Model_Epsilon will only change slightly, if at all, because various effects will tend to cancel each other out. In any case, the new names convert what would be upward inconsistencies into upward incompatibilities. We have recommended that implementations continue to provide the old attributes, as implementation-defined attributes, during a transition period, with compiler warning messages when they are used. An Ada 83 program using the Safe_Small or Base'Epsilon attributes should be able to substitute the Model_Small and Model_Epsilon attributes for an equivalent (and logically consistent) effect, but substitutions for the other attributes may require more careful case by case analysis. It is instructive to consider how the fundamental model-oriented attributes and the Digits attribute of a predefined floating point type P are determined in Ada 95, when the Numerics Annex is implemented. The algorithm is as follows. * Initially set P'Model_Emin to P'Machine_Emin and P'Model_Mantissa to P'Machine_Mantissa. This tentatively defines an infinite set of model numbers. * If the accuracy requirements, defined in terms of the model numbers, are satisfied by every predefined arithmetic operation that is required to satisfy them, when overflow does not occur, then these are the final values of those attributes. Otherwise, if the machine lacks guard digits or exhibits precision anomalies independent of the exponent, reduce P'Model_Mantissa by one until the accuracy requirements are satisfied (when overflow does not occur); if underflow occurs prematurely, increase P'Model_Emin by one until the accuracy requirements are satisfied near the underflow threshold. The final set of model numbers has now been determined. * Let P'Safe_First be the smallest model number that is greater than P'First and similarly let P'Safe_Last be the largest model number that is less than P'Last. These tentatively define the safe range. * If overflow is avoided throughout the safe range by every predefined arithmetic operation, then this is the final safe range. Otherwise, i.e. if overflow occurs prematurely, increase P'Safe_First and/or decrease P'Safe_Last by one model number until overflow is correctly avoided in the resulting safe range. The final safe range has now been determined. * Finally, let P'Digits be the maximum value of d for which <syntaxhighlight lang="Ada"> Ceiling(d*log(10.0)/log(P'Machine_Radix) + 1) <= P'Model_Mantissa.</syntaxhighlight> This is relevant in the context of the selection of a representation for a user-declared floating point type, which must provide at least as many decimal digits of precision as are requested. If this condition is satisfied, the type's arithmetic operations will satisfy the accuracy requirements. P'Model_Epsilon and P'Model_Small are defined in terms of other attributes by familiar formulae. The algorithm for Ada 83, which is not given here, is much more complex and subtle, with more couplings among the attributes. === <span id="4-2">G.4.2 Fixed Point Arithmetic and Attributes</span> === The revision of the model of fixed point arithmetic focuses on two of the problems concerning fixed point types that have been identified in Ada 83: * The model used to define the accuracy requirements for operations of fixed point types is much more complicated than it needs to be, and many of its freedoms have never been exploited. The accuracy achieved by operations of fixed point types in a given implementation is ultimately determined, in Ada 83, by the safe numbers of the type, just as for floating point types, and indeed the safe numbers can, and in some implementations do, have more precision than the model numbers. However, the model in Ada 83 allows the values of a real type (either fixed or float) to have arbitrarily greater precision than the safe numbers, and so to lie between safe numbers on the real number axis. Implementations of fixed point typically do not exploit this freedom. Thus, the opportunity to perturb an operand value within its operand interval, although allowed, does not arise in the case of fixed point, since the operands are safe numbers to begin with. In a similar way, the opportunity to select any result within the result interval is not exploited by current implementations, which we believe always produce a safe number; furthermore, in many cases (for some operations) the result interval contains just a single safe number anyway, given that the operands are safe numbers, and it ought to be more readily apparent that the result is exact in these cases. * Support for fixed point types is patchy, due to the difficulty of dealing accurately with multiplications and divisions having "incompatible smalls" as well as fixed point multiplications, divisions, and conversions yielding a result of an integer or floating point type. Algorithms have been published in [Hilfinger 90], but these are somewhat complicated and do not quite cover all cases, leading to implementations that do not support representation clauses for Small and that, therefore, only support binary smalls. The solution adopted in Ada 95 is to remove some of the freedoms of the interval-based accuracy requirements that have never been exploited and to relax the accuracy requirements so as to encourage wider support for fixed point. Applications that use binary scaling and/or carefully matched ("compatible") scale factors in multiplications and divisions, which is typical of sensor-based and other embedded applications, will see no loss of accuracy or efficiency. A host of specialized requirements for information systems applications is addressed by the division of fixed point types into ordinary and decimal fixed point types. The facilities for the latter are to be found in the Information Systems Annex, see Chapter F. The default small in Ada 95 is an implementation-defined power of two less than or equal to the delta, whereas in Ada 83 it was defined to be the largest power of two less than or equal to the delta. The purpose of this change is merely to allow implementations that previously used extra bits in the representation of a fixed point type for increased precision rather than for increased range, giving the safe numbers more precision than the model numbers, to continue to do so. An implementation that does so must, however, accept the minor incompatibility represented by the fact that the type's default small will differ from its value in Ada 83. Implementations that used extra bits for extra range have no reason to change their default choice of small, even though Ada 95 allows them to do so. Note that the simplification of the accuracy requirements that apply in the strict mode, by expressing them directly in terms of integer multiples of the result type's small rather than in terms of model or safe intervals, removes the need for many of the attributes of fixed point types. However, it is recommended that implementations continue to provide these attributes as implementation-defined attributes during a transition period, with their Ada 83 values, and that implementations produce warning messages upon detecting their use. The accuracy requirements for the adding operators and comparisons now simply say that the result is exact. This was always the case in Ada 83, assuming operands were always safe numbers, and yet it was not clear from the model-interval form of the accuracy requirements that comparison of fixed point quantities was, in practice, deterministic. Other accuracy requirements are now expressed in terms of small sets of allowable results, called "perfect result sets" or "close result sets" depending on the amount of accuracy that it is practical to require. These sets comprise consecutive integer multiples of the result type's small (or of a "virtual" small of 1.0 in the case of multiplication or division giving an integer result type). In some cases, the sets contain a single such multiple or a pair of consecutive multiples; this translates into a requirement that the result be exact, if possible, but never off by more than one rounding error or truncation error. This occurs with fixed point multiplications and divisions in which the operand and result smalls are "compatible" meaning that the product or quotient of the operand smalls (depending on whether the operation is a multiplication or a division) is either an integer multiple of the result small, or vice versa. These compatible cases cover much of the careful matching of types typically exhibited by sensor-based and other embedded applications, which are intended to produce exact results for multiplications and at- most-one-rounding-error results for divisions, with no extra code for scaling; they can produce the same results in Ada 95, and with the same efficient implementation. Our definition of "compatible" is more general than required just to cover those cases of careful matching of operand and result types, permitting some multiplications that require scaling of the result by at worst a single integer division, with an error no worse than one rounding error. In cases where the smalls are incompatible, the accuracy requirements are relaxed, in support of Requirement R2.2-A(1); in fact, they are left implementation defined. Implementations need not go so far as to use the Hilfinger algorithms [Hilfinger 90], though they may of course do so. An Ada 95 implementation could, for instance, perform all necessary scaling on the result of a multiplication or division by a single integer multiplication or division (or shifting). That is, the efficiency for the cases of incompatible smalls need not be less than that for the cases of compatible smalls. This relaxation of the requirements is intended to encourage support for a wider range of smalls. Indeed, we considered making support for all smalls mandatory in the strict mode on the grounds that the weaker requirements removed all barriers to practical support for arbitrary smalls, but we rejected it because it would make many existing implementations (which could in all other respects satisfy the requirements of strict mode) instantly nonconforming. Ada 95 allows an operand of fixed point multiplication or division to be a real literal, named number, or attribute. Since the value v of that operand can always be factored as an integer multiple of a compatible small, the operation must be performed with no more than one rounding error and will cost no more than one integer multiplication or division for scaling. That v can always be factored in this way follows from the fact that it, and the smalls of the other operand and the result, are necessarily all rational quantities. The accuracy requirements for fixed point multiplication, division, and conversion to a floating point target are left implementation defined (except when the operands' smalls are powers of the target's machine radix) because the implementation techniques described in [Hilfinger 90] rely on the availability of several extra bits in typical floating point representations beyond those belonging to the Ada 83 safe numbers; with the revision of the floating point model, in particular the elimination of the quantization of the mantissa lengths of model numbers, those bits are now likely gone. Except when the operands' smalls are powers of the target's machine radix, requiring model-number accuracy for these operations would demand implementation techniques that are more exacting, expensive, and complicated than those in [Hilfinger 90], or it would result in penalizing the mantissa length of the model numbers of a floating point type just to recover those bits for this one relatively unimportant operation. An implementation may use the techniques in [Hilfinger 90] for fixed point multiplication, division, and conversion to a floating point target; the accuracy achieved will be exactly as in Ada 83, but will simply not be categorizable as model-number accuracy, unless the operands' smalls are powers of the target's hardware radix. Furthermore, in the latter case, even simpler algorithms are available. === <span id="4-3">G.4.3 Accuracy of the Numerics Packages</span> === The Numerics Annex specifies the accuracy or other performance requirements that the mandatory elementary function and random number packages must satisfy in the strict mode. These are discussed in A.3 with the packages themselves. == <span id="5">G.5 Requirements Summary</span> == The facilities of the Numerics Annex and the floating point attributes of the Predefined Language Environment Annex relate to the requirements in 11.1 (Floating Point). The requirement * R11.1-A(1) - Standard Mathematics Packages is met in part by the Complex types and related packages of the Numerics Annex and in part by the elementary functions and random numbers packages of the Predefined Language Environment Annex. The study topic * S11.1-B(1) - Floating Point Facilities is met by the numeric model presented in the Numerics Annex and by the floating point attributes provided in the Predefined Language Environment Annex. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p3-f|Previous]] | [[Guide:9x_rationale/rat95-p3-h|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=Annex G. Numerics}} 2vpdt4vty2xdtbm14sz0n5qfqil94fi Guide:9x rationale/rat95-p3-h 4200 352 1873 1860 2019-04-20T16:20:44Z WikiVisor 11 Text replacement - "|Next]]" to "|Next]]</div>" wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p3-g|Previous]] | [[Guide:9x_rationale/rat95-p4|Next]]</div> For critical software, the key issue is assurance of the application, that is, gaining sufficient confidence in the application in order to authorize its use. The Ada 95 language contributes to this process by providing a language definition which minimizes potential insecurities and which thus facilitates independent program validation and verification. However, the size and richness of the language also raise some issues that need to be addressed if it is to be fully exploited for safety and security applications. * As a high-level language, Ada 95 tries to leave implementation- oriented matters unspecified, but validation and verification of a system requires knowledge of these details. * Although software development takes place in Ada 95, validation logically needs to be performed at the object code level; understanding the correspondence between source and object is therefore essential for the most critical applications. * If the expressive power of the full language is not needed, there must be some way to ensure that a tailored version of the run-time system is used, without support for the unwanted features, thereby simplifying the process of validation and verification. The Safety and Security Annex is designed to address these concerns. It should be noted that the prospective users of this annex form a small, specialized community who historically have been served by special contracts between large user organizations and specific vendors. However, such an approach can only satisfy the requirements of enterprises with significant resources. Since the Annex is part of the Ada 95 standard, "off-the-shelf" products should be able to satisfy the same requirements at substantially reduced costs. This will allow Ada 95 to be used with assurance by different application areas, including those outside the military sector such as medical electronics or electronic funds transfer. Over the period that the Ada 95 standard can be expected to be operative, the number of applications in such areas could rise quite steeply. ==== Relationship to Current Approaches ==== The UK Ministry of Defence standard for the procurement of safety- critical software [MoD 91] is based upon the use of mathematical specifications and formal proofs or rigorous arguments for showing compliance and has been effectively used in some environments. However, the complete application of this standard is often not feasible and hence other methods must be used, even within the defense context. Whatever approach is taken, the final form of the program is vital, since it is an analysis of the program itself which must provide the basis of most of the assurance procedures. This implies that the programming language used for the application is likely to have a key role. The Annex aids but does not require the application of mathematical specification techniques. A mature standard in the safety-critical area which takes a different view to formal methods is the international avionics standard [DO-178B]. Here the emphasis is on design, analysis and test. Although there is little stated about programming languages, it is clear that any analysis will either depend upon the programming language or upon a corresponding analysis of the object code generated by the compiler. Quite rightly, the standard requires isolation from the correctness of the compiler for the most critical software, implying that one must either reason from the object code or else show that the object and source code are equivalent. The Annex provides facilities to aid in the analysis of the object code, including access to data values during testing, in order to ease validation. In the context of safety, the requirements surrounding the application of computers to nuclear shut-down systems has been well documented [Archinoff 90]. In the same application area, the need to show that compiler errors can be detected is given in [Pavey 93]. In the security area, the general requirements are well documented in [DoD 85, ITSEC 91]. Although the latter document does imply some requirements on the programming language in use, they are at a level that is not really relevant to this Annex. ==== Dealing with Language Insecurities ==== To reason about a program requires that the structures used within the program be well-defined and properly implemented. However, almost all existing programming languages standardized by ISO are not defined in a mathematically precise form. Hence substantial care must be taken to ensure that the features of the language used are well-defined and that the program accords with the intention of the programmer. Since programmers are fallible, languages which require checks for some forms of error are an advantage, especially if the design can allow the software to request the system to return to a safe state. Ada 83 is the only widely used language suitable for critical applications which requires such checking (and Ada 95 of course continues in this tradition). Many critical applications do not exploit this checking but demonstrate (perhaps by mathematical proof) that the checks could not fail. Undertaking this form of static checking is very expensive in staff time, and hence is not practical for less critical applications. A brief summary of the securities and insecurities of standard languages is shown in Figure H-1. <syntaxhighlight lang="Ada">+--------------+--------------------------------+------------------------+ | Standard | Security Features | Insecurities | | Language | | | +--------------+--------------------------------+------------------------+ | Ada 83 |Runtime checks required |Access to unset scalars | | |Pointer initialization | | | |Type-secure across packages | | | |Can recover from check failures | | +--------------+--------------------------------+------------------------+ | Modula-2 |Type-secure across modules |Unset pointers (and | |(not yet an |Limited recovery from failures | scalars) | | ISO standard)| | | +--------------+--------------------------------+------------------------+ | Pascal |Strongly typed |Runtime checks optional | | | |Unset pointers (and | | | | scalars) | +--------------+--------------------------------+------------------------+ | C |(Additional tools: |150 undefined "features"| | | make and lint) |Runtime checking often | | | | not done | +--------------+--------------------------------+------------------------+ | Fortran 77 |Type checking |Default declarations | | |No pointers |No checking across | | | | routines | +--------------+--------------------------------+------------------------+ Figure H-1: Securities and Insecurities in Standard Languages</syntaxhighlight> A comparison of programming languages for safety and security applications showed that a subset of Ada 83 was a good choice [Cullyer 91]. The subsequent maturity of Ada compilers, the better understanding of the language, and the provision of Ada-specific tools, makes the language the first choice for many applications. In contrast, the C language is deprecated in the IEC draft standard on safety software [IEC/SC65A 91] since it is very difficult to demonstrate that C code is restricted to the subset which is well-defined. Ada 95 fills a number of the insecurities noted in Ada 83 [Wichmann 89], and hence it provides the smallest area of uncertainty to the developer. The C++ language is not listed in Figure H-1, since it is not yet standardized by ISO. There are substantial problems in the validation of C++ code, some of which arise due to the lack of an agreed standard. Moreover, since almost all C programs can be compiled by a C++ compiler, the inherent problems of the validation of C code are transferred to C++. In addition, compiler vendors are at a disadvantage compared to Ada in not having an internationally agreed and comprehensive validation suite for the language. The insecurities may be avoided by suitably chosen subsets of Ada, such as that provided by SPARK [Carre' 88]. The same subset could be used for Ada 83 and Ada 95, and may be exploited by the compiler through the pragma Restrictions described below. Note that the use of such subsets is not in conflict with Ada's traditional "no subsets, no supersets" policy, since for compiler validation purposes there must be a complete implementation of the language, and not simply a subset. The point is that any particular program will not use the full language, and if there are a set of features whose exclusion can result in software for which validation and verification is facilitated, then the implementation can enforce such exclusions in one mode of operation and can link in reduced versions of the run-time system. Until now, language standards have not addressed the problem of the validation of the object code generated by a compiler. This is troublesome unless information is provided linking the source code to the object code. Such checking will be required for many years to come while there is a possibility of errors being introduced by a compiler. The alternative of having "trusted compilers" does not yet seem viable for the major languages. The user can indicate exclusion of particular features in a partition by means of pragma Restrictions. For instance, the user can indicate that tasking is not needed, thus allowing the run-time system to be very much smaller and simpler. Similarly, the user can ensure that other language features are avoided. Through this facility, the language used on a particular system can be reduced to a quite small subset of Ada 95. This can facilitate the analysis of the source code, since not only can language features be avoided for which verification and validation are impractical, but one can be assured that these restrictions are enforced by the compiler. One might argue in favor of a smaller language than Ada 95 for safety- critical systems, rather than a mechanism for indicating features to be excluded. However, past experience has shown that there is no consensus on a suitable subset is difficult since specific applications do require most features of Ada for convenient and maintainable coding. After agreeing to the Ada 95 standard, WG9 discussed the problems in the validation and verification of Ada programs. Such activities could be substantially cheaper if tools could effectively analyze Ada source code to verify safety or security requirements. In practice, this is likely to require that the code conforms to some conventions, suh as being within a subset. These issues are to be investigated by the WG9 Verification Rapporteur Group (VRG). == <span id="1">H.1 Understanding Program Execution</span> == A key issue for the language in critical applications is that of understandable execution. Ada 95 addresses this issue in several ways: * Eliminating certain cases of Ada 83 erroneous execution, and replacing them by bounded errors; * Adding an attribute to check for scalar data validity; * Adding a pragma to cause otherwise uninitialized scalars to be set to values outside their nominal subtypes; * Requiring documentation of implementation decisions. === <span id="1-1">H.1.1 The Valid Attribute</span> === Although this feature is in the core language [RM95 13.9.2], it is discussed here since it is relevant to the safety and security applications. The Valid attribute allows the user to check whether the bit-pattern for a scalar object is valid with respect to the object's nominal subtype. A reason for including such a facility is that the other language-defined operations that could conceivably undertake the same function might not have the intended effect. The following example illustrates the issue. <syntaxhighlight lang="Ada"> declare I : Integer range 1 .. 10; -- Uninitialized A : array (1 .. 10) of Float; begin ... A(I) := 1.0; ... end;</syntaxhighlight> In Ada 83, users are sometimes surprised to learn that a compiler is permitted to remove the index check for A(I). The reason that such an optimization is allowed is that a reference to an uninitialized scalar object in Ada 83 yields an erroneous execution, and therefore unspecified effects. Thus the compiler may apply the following logic: * If the value of I happens to be within 1 .. 10, then the check is unnecessary. * On the other hand, if the value is not within 1 .. 10, then since execution is erroneous any effect is allowed including using the out of range value as an index. Perhaps even more surprising, the programmer cannot count on the following style to ensure that a check is carried out: <syntaxhighlight lang="Ada"> declare I : Integer range 1 .. 10; -- Uninitialized A : array (1 .. 10) of Float; begin ... if I in 1 .. 10 then A(I) := 1.0; else raise Bad_Index; end if; end;</syntaxhighlight> In this example the compiler may optimize the test <syntaxhighlight lang="Ada"> I in 1 .. 10</syntaxhighlight> to true, using the same logic that led to the suppression of the index check in A(I), namely that if the program's execution is not erroneous then the value of I will be within its declared subtype and hence the membership test can be omitted, and if the program's execution is erroneous then the effect is unspecified and thus again the test can be omitted. Ironically, if the programmer had declared the variable I without a range constraint, then it is likely that the check would be performed (unless data flow analysis can show otherwise). The fact that including a range constraint with a scalar declaration might reduce the security of the code (by failing to raise a run-time exception) is against the Ada design philosophy. This problem is addressed in several ways in Ada 95. First, a reference to an uninitialized scalar variable is no longer erroneous but rather a bounded error: the permitted effects are to yield a valid value (i.e., one within the variable's nominal subtype), to yield an invalid value (one within the variable's type but outside its nominal subtype), or to raise the exception Program_Error. This rule prevents the compiler from "reasoning from erroneousness". In the first example, unless the compiler has by default set the initial value of I to be within the range 1 .. 10 (which is not recommended, since it would mask errors), it will need either to raise Program_Error (because of the reference to an uninitialized object) or to generate a range check. The second example will not have the problem of the in membership test being optimized away, but there is still the possibility that the reference to the uninitialized value of I will raise Program_Error, which is presumably not what the programmer intended. Moreover, to allow membership tests to be implemented simply and efficiently, the membership test only performs a range check and thus might not work as desired for enumeration types with "holes" in the representation. These remaining issues have motivated the introduction of a simple, intuitive facility for checking that the value of a scalar object is within the object's nominal subtype. That is the purpose of the Valid attribute, which applies to any scalar object. As illustration, an alternative version of the second example, using Valid rather than the membership test, is as follows <syntaxhighlight lang="Ada"> declare I : Integer range 1 .. 10; -- Uninitialized A : array (1 .. 10) of Float; begin ... if I'Valid then A(I) := 1.0; else raise Bad_Index; end if; end;</syntaxhighlight> The purpose of the Valid attribute is to check the contents of a scalar object without formally reading its value. Using this attribute on an uninitialized object is not an error of any sort, and is guaranteed to either return True or False (it will never raise Program_Error), based on the actual contents of the object, rather than on what the optimizer might have assumed about the contents of the object based on some declaration. Although the use of the Valid attribute for checking the validity of uninitialized data is somewhat contrived, other examples are more realistic, such as checking data from: * An unchecked conversion; * Calling procedure Read from Sequential_IO or Direct_IO; * An object for which pragma Import has been specified; * An object that has been assigned a value where checks have been suppressed. The Valid attribute could potentially be applied to a wider range of types than that of scalars. Unfortunately, this extension is not easy to define with the rigor that should be expected. For instance, what action should an implementation perform to attempt to determine if a bit-pattern of an access type is a valid value? If the attribute did have a larger scope but with unspecified semantics, then its use on critical systems would require an implementation-defined specification, checked by analysis of the object code produce by the compiler. This complexity did not seem justified. If the attribute is to be used on a record read from a file that was written by a COBOL program, it is important that the Ada program can check that the value is meaningful rather than execute code based upon the premise that the value is legal. In the context of safety-critical applications, such alien data is likely to be provided by some external device. Such data could well be a composite value, in which case the attribute must be applied to the scalar components. Checking on non- scalar components or for potential gaps between components cannot be undertaken with Valid. It is not necessarily logically sound to apply Valid to a composite type, due to the presence of components which are undefined, as in the following example <syntaxhighlight lang="Ada"> type Stack_Data is array (1 .. 100) of Character range 'A' .. 'Z'; type Stack is record Index : Integer range 0 .. 100; Data : Stack_Data; end record;</syntaxhighlight> Only those elements of the array up to the position of Index need to be checked for validity, but there is no way for a general definition to capture such semantics. In formulating the design of the Valid attribute, we considered several alternatives. One was to have it as a scalar subtype attribute function, applied to the object of that subtype whose validity was to be checked; for example, <syntaxhighlight lang="Ada"> declare subtype S is Integer range 1 .. 10; I : S; begin ... if S'Valid(I) then ... else ... end if; ... end;</syntaxhighlight> However, this would present semantic difficulties since calling a function causes evaluation of the actual parameters; the main idea behind the Valid attribute, however, is that it should not read the value of the object, since this might raise an exception. Another approach we considered was to have the attribute as a function associated with a "target" scalar subtype (either as an attribute or through generic instantiation) applied to a value of any (other) "source" scalar subtype. The idea is to check a source bit pattern (say an Integer value) to see if it is a valid value for the target subtype. As an example, if Enum is an enumeration type with "holes" (that is, it has a representation clause with non-contiguous integer values), and V is an Integer value, then Enum'Valid(V) would return True if V has one of the identified values, and False otherwise. The idea is to check validity before the source bits are copied to the target object. One problem with such an approach, however, is that it raises some semantic and implementation questions with respect to the expected sizes of both the source value and the target subtype; this issue does not arise with the notation X'Valid since the object X is not itself evaluated. Another problem is that it is rather unwieldy in the common case where validity needs to be checked for data that is being read from an external device into a record, and where the record fields have scalar subtypes. In such a case it is simplest and most efficient to read the data into the record first, and then to check validity. This works conveniently using the Valid attribute applied to a scalar object <syntaxhighlight lang="Ada"> declare type Rec is record A : Character range 'A' .. 'Z'; B : Integer range 1 .. 10; end record; R : Rec; begin Read(R); if not R.A'Valid then ... end if; if not R.B'Valid then ... end if; ... end;</syntaxhighlight> With the alternative style, it would be necessary to have a record type with fields corresponding to the full types (Character and Integer), to read the data into an object of this record type, check validity of the fields, and then copy it into R so that constraint checks can be enforced on subsequent assignments to these fields. As a result of analysis of these design alternatives, we decided on the approach where validity is realized through an attribute that is applicable to a scalar object, rather than an attribute function associated with a target scalar subtype. === <span id="1-2">H.1.2 Abnormal Values</span> === A value can be abnormal instead of having an invalid representation [RM95 13.9.1]. From the point of view of safety and security, such abnormal values are a potential disaster, since they can give rise to erroneous execution - the opposite of predictable execution which the Annex strives to provide. In general, it is not possible for a scalar value to be abnormal, and in any case, the user can take precautions against scalar values with an invalid representation by suitable use of the Valid attribute. It might be possible for an implementation to obtain an abnormal floating point value if a signalling NaN was produced in which no trap-handler was provided, since access to the value would produce unpredictable results. (A signalling NaN is a bit pattern used in place of a floating point number in systems that support IEC 559; see [IEC 89]. Access to such a bit pattern will cause an interrupt, if the processor state is set correctly. If the interrupt is not then handled, disaster could ensue. In fact, signalling NaNs could be used to detect unset floating point values with very little overhead on some machines, although existing Ada systems do not appear to do this.) Abnormal values can arise from an abort statement interrupting an assignment operation, or interactions with the environment external to the Ada program. Typically, the data type would be composite with a complex internal structure which can be placed in a state that the Ada system cannot subsequently handle. Task objects and types with discriminants are potential candidates for types which can have abnormal values. Vendors providing support for this Annex should be able to indicate if and how such value can arise (unless they require the use of the Restrictions pragma to effectively exclude such values). Abnormal values can also arise if a language defined check would fail but the check has been suppressed. Suppressing checks can obviously lead to problems, since any storage could be overwritten making it generally impossible for the Ada run-time system to retain control. === <span id="1-3">H.1.3 The Pragma Normalize_Scalars</span> === The use of an undefined scalar is a very common programming error which must be detected in critical systems (see [Wichmann 92] for a discussion of some of the subtleties of this issue in connection with an earlier draft of the Ada 9X mapping). As observed above, the Ada 95 rule treating this as a bounded error rather than an erroneous execution will inhibit certain compiler optimizations that would make this kind of error difficult to detect. However, it does not prevent the compiler from giving an in-range "default" initial value to otherwise uninitialized scalars, which would also make it difficult to find errors. In the light of these considerations, Ada 95 supplies the configuration pragma Normalize_Scalars, which serves to ensure that elaboration of the declaration of an otherwise uninitialized scalar, sets the object to an invalid value if such a value exists. If no such invalid value exists for a scalar object, then the implementation needs to identify this (for example on the program listing) so that the programmer is alerted to ensure that the object is assigned before it is referenced. In such cases, the program will have a predictable (but not necessarily portable) value and the implementation needs to document the in-range value taken. The name Normalize_Scalars reflects the intent of the pragma. A "normal" value for a scalar object is either valid (if within the object's nominal subtype) or invalid (if outside). Since scalar initializations induced by the pragma might or might not be invalid, "normalize" is an appropriate description. In general, an invalid value will be outside the object's nominal subtype, but there are also cases where it is possible for the implementation to produce an invalid value even when the nominal subtype has the same range as the type. For example, suppose that an implementation of the type Boolean reserves 8 bits for objects that are not in packed arrays or in records with representation clauses, with 16#00# corresponding to False and 16#01# to True. In the presence of pragma Normalize_Scalars, an otherwise uninitialized Boolean variable will be set to an invalid value, which is neither 0 nor 1. Some interactions with other pragmas need to be understood by prospective users. First, if a scalar object is the argument to pragma Import, then its (probable lack of) initialization is not affected by pragma Normalize_Scalars. This is reasonable, since an imported data item is under the control of foreign language code that is not subject to Ada semantics. Note that if an Ada scalar variable corresponds to a memory-mapped I/O location, then any implicit initialization could have an unwanted effect. This can be avoided by importing the scalar variable. Another interaction is with pragma Restrictions. If a system is being developed in which exception handling is absent, then the use of pragma Normalize_Scalars is inappropriate, and even dangerous. With the pragma Restrictions(No_Exceptions) in effect, there is no object code generated to perform constraint checks. Clearly, referencing an out-of-range scalar would then result in an unpredictable effect. === <span id="1-4">H.1.4 Documentation of Implementation Decisions</span> === One aspect of predictability is to understand the behavior of a program in situations identified by the language rules as either bounded errors or unspecified effects. Thus the implementation needs to document these behaviors, either as part of a listing or tool-processable output, or (if a general rule) as independent documentation. Some specific requirements are now discussed. ==== Parameter Passing Mechanism ==== Some parameters can be passed by reference or by copy. A different mechanism could even be chosen for two calls of the same subprogram. Incorrect programs can be affected by the choice and hence safety and security applications need to check that either this error has not been made or that the effect will be acceptable. The simplest solution is for the compiler to indicate the choice made. If the choice is a simple static one (say, always by reference, except for entry parameters which are always by copy), then this could be stated once in the compiler documentation, otherwise the object code listing (or appropriate tool) should indicate the choice. In fact, some compilers have a complex algorithm which varies from call to call, especially for slices. The complexity of this algorithm is not relevant to the issue, merely that the choices made should be clear. ==== Storage Management ==== Many safety critical applications are in the form of an infinite loop. It is important that this loop should not permanently consume storage. Therefore it must be possible, by reviewing the object code, to ensure that this does not happen. In the security context, it is important that storage used to contain classified information does not leak via the storage allocation system. It is possible that this requirement can be met by proposals for a user-defined allocation and de-allocation of storage - in which case the run-time system may be less critical. There is a parameter to the Restrictions pragma to avoid storage leaks. Of course, even if there is no net consumption of storage within a program, and if the storage is not allocated and de-allocated via a stack, it will be necessary to show that storage fragmentation does not undermine the system. For this reason, the algorithm used by the run- time system is important and must be fully documented. For time-critical applications, additional constraints could be required on the run-time routines, such as having a tight upper bound in execution time. This requirement is not specified here, since it will be application specific and many systems avoid the use of the heap and hence are unlikely to have a problem. ==== Evaluation of Numeric Expressions ==== Problems can arise if the evaluation of numeric expressions involves extended range or extra precision. Counter-intuitive results can be produced with floating point expressions when combined with equality tests, which is quite common on IEEE systems. Hence the vendor should document the approach taken, independent of any annotation of the object code, so that any potential confusion can be avoided. This implies that for any specific expression, the range and precision with which it is computed should be clear from the documentation (see [RM95 H.2(2)]). The evaluation of the exponentiate operator is not defined exactly in [RM95 4.5.6(11..12)]. Apart from the association of the multiplications (which only makes a marginal difference to the result), performing the division (for negative exponents) at the end or initially make a significant difference to the occurrence of overflow. Adherence of an Ada implementation to the Language Independent Arithmetic standard [ISO 93] would be appropriate in the context of this annex, since that standard requires that the numeric operations used are precisely defined. == <span id="2">H.2 Reviewable Object Code</span> == The relevant features supplied by the Annex are the pragmas Reviewable and Inspection_Point. === <span id="2-1">H.2.1 The Pragma Reviewable</span> === Due to the well-known fact that all compilers have bugs, it is the conventional wisdom of the safety critical community to avoid assuming that the generated object code is automatically correct. For instance, the approach taken in the avionics standard DO-178B is one of Design, Review and Test [DO-178B]. As far as practical, the review and test activities are undertaken at the object code level. Indeed, if the reliability requirements of Class 1 flight critical software (the most critical) are to be attained, every attempt must be made to detect errors induced by a compiler. This is expensive, but unavoidable given current technology. The pragma Reviewable applies to a partition so that the compiler can generate code to match special documentation thus permitting independent review of the object code. The following specific requirements apply. ==== Elaboration Order for Library Units ==== Since the elaboration order may have a visible effect, it is essential that the chosen ordering be indicated by the implementation in forms convenient both for human readers (such as in a program listing) and for processing by automated tools. An example of such a tool is a static analyzer that determines the absence of accesses to undefined variables. ==== Object Code ==== It cannot be assumed that the vendor will provide every tool needed for validation and verification. In any case, complete reliance upon such tools may not be acceptable. Hence it should be possible to extract the object code in a form that can be easily machine processed. An example of a tool is one which provides maximal times for instruction sequences so that time-critical software can be shown to meet deadlines. The wording in the Annex on the requirement of producing output suitable for tools uses the word "should" rather than the conventional (and stronger) "shall". This is because it may not be possible to check compliance with the requirement objectively. Since there are no standard data interchange formats for such information, there is no means of giving a precise description of what is "suitable". ==== Object Lifetime Analysis ==== The implementation needs to allow the user to determine which objects are assigned to which registers, and the lifetimes of those assignments. An important aspect of code generation is the assignment of registers. The most general register assignment algorithm is known to be NP complete and hence it is quite unreasonable for compiler documentation to detail such an algorithm (especially since it may be proprietary). However, the result of the algorithm for the specific safety/security application is to be provided. The area allocated to any object is to be specified so that an object can be accessed, either via the register or via main memory for the entire lifetime of the object. Compilers typically produce code to address internal information as well as the information directly related to objects declared by the program. This issue is not specified in the Annex, since it is unclear how it can be specified in a testable form. ==== Initialization Analysis ==== For each reference to a scalar object, the implementation needs to identify whether the object is either "known to be initialized" or "possibly uninitialized". Note that pragma Normalize_Scalars does not affect this analysis. Since the access to unset scalars can lead to severe errors, and compilers already perform some of the analysis required, the purpose of this requirement is to provide the information to aid validation and verification. In the case of "possibly uninitialized", the information would depend upon the strength of the analysis performed by the compiler, and hence different compilers (or even the same compiler under different options) could not be expected to give identical information. ==== Machine Instructions Used ==== For the most critical applications, it is necessary to check that the machine instructions required by an application are correctly handled by the processor hardware. Microcode faults in processor chips are not uncommon and therefore such checking may be needed [Wichmann 93]. A list of the used instructions aids the checking since unused instructions need not be checked. It would be helpful to identify instructions only used in the run-time system, but this is not essential. For checking timing constraints, a user needs to consider only the instructions listed. ==== Relationship between Source and Object Code ==== Code sequences derived entirely from one Ada statement (or declaration) must be indicated as such. In those cases in which a code sequence is derived from a single Ada statement, this statement should be identified. Due to some optimizations, it could be that this identification is difficult. In such cases, some optimizations could be disabled when the pragma Reviewable is in force, rather than enhancing the compiler to meet the requirements with full optimization. In this area, a tool could be much more useful for independent validation and verification rather than an annotated listing. Some compilers provide information based upon line numbers rather than Ada statements. For the purposes of this annex, it can be assumed that there is only one statement per line. For a single statement, several code sequences could be involved, especially if instruction scheduling merges the code from more than one statement. Addressing instructions derived from more than one statement would not have to be identified as such. If an Ada statement results in no object code, then a positive indication of removal is required, rather than a mere absence of object code from a statement. The user may need to compute the storage requirements for a program so that the absence of the Storage_Error exception can be checked. For subprograms containing only statically sized objects, an implementation should indicate the size of the stack frame required. ==== Exception Analysis ==== The implementation must indicate where compiler-generated run-time checks occur in the object code, and must also provide a method of determining which exceptions can be raised by any statement. The handling of the predefined exceptions is problematic. Exception sites need not be in the same compilation unit as the handlers that service them. Some method is needed to indicate, explicitly in the object code, the actual locations at which exceptions are raised and handled. Some mechanism should be available, either through source or object code analysis, that permits the analysis of the program to determine which handler is used for each site that can raise an exception and to identify sites for which no handler is supplied. It would probably be most useful if this was in the form of a tool, rather than tables which required detailed analysis of each case. An example of a tool to undertake exception analysis is given by [Schaefer 93]. Since exceptions raised by predefined operations are not explicitly indicated in the source, and since the implementation is allowed some freedom in choosing actual execution order, this facility is best supported at the object code level. Even if a vendor does not choose to perform such an analysis, the information necessary to perform it should be made available to the user. For a detailed analysis of the issues involved, see Chapter 2 of the report on Formal Studies of Ada 9X [DoD 92]. ==== Analysis of Run-Time System Components ==== Clearly, the fact that a compiler generates a call to an out-of-line routine does not obviate the need for reviewing the object code of the called routine. Hence the same requirements for reviewing the object code must apply to the run-time system components. === <span id="2-2">H.2.2 The Pragma Inspection_Point</span> === A point in the program text can be marked as an inspection point through a pragma of the same name, optionally identifying a set of objects whose values are to be available. At the corresponding point(s) in the object code, the vendor is required to provide a means of determining the values of the specified objects, or, if none was specified, then a means of determining the values of all live objects. This implies that the object code can be analyzed with special tools so that properties of the code and object values can be verified, independently of the source code. In theory, full mathematical verification could be undertaken, although this implies that the specification of the application is available in a suitable form. This proposal arose out of the discussion from the special meeting held in April 1993 [Brosgol 93] attended by experts associated with producing safety critical systems. The idea is to break down a program into code sections separated by inspection points to facilitate validation of the code. This idea is new, although the concept of "break-points" in assembly language debugging is clearly similar. Note that a single occurrence of pragma Inspection_Point in the source text may correspond to several inspection points in the object code; for example, if the pragma appears in an inlined subprogram, a generic unit, or a loop that has been "unrolled" by the optimizer. There are, not surprisingly, some interactions between the pragma and optimizations. Since a user will in general examine the values of inspectable objects when execution is suspended at an inspection point, it is essential that compilers not perform "dead code elimination" on prior assignments to such objects. On the other hand, disabling all optimization is too extreme and in fact is unnecessary. Thus the compiler is allowed to store inspectable objects in registers; the implementation needs to provide sufficient information to make this mapping known to the user. The compiler is also allowed to move expressions (including those which could raise predefined exceptions) over inspection points. The main design decision in connection with inspection points was whether to provide a single pragma, or to separate it into two: one that identifies the inspectable objects, and the other that identifies the points in program execution where currently live inspectable objects could be inspected. An advantage of the two-pragma approach is separation of concerns, and the ability to specify that, say, a variable declared in a package body is inspectable outside the package without needing to have all live objects inspectable. (Note that, with the single pragma approach the name of a variable declared in a package body is inaccessible outside the package and hence cannot be used as an argument to pragma Inspection_Point. Thus in the single-pragma approach, if the user needs to be able to inspect such a variable, pragma Inspection_Point with no arguments needs to be provided, which makes all objects inspectable and thus may inhibit some optimizations.) In the end, the choice of a single-pragma approach was based on anticipated usage of the functionality provided, and in particular on the desire to avoid tedious source code changes and recompilations during software development. That is, the exact set of objects that need to be inspected might not be apparent at the outset. With the two-pragma approach, a decision to identify an additional variable will require a source code modification and may induce significant recompilation costs depending on where the variable is declared. With the single-pragma approach, the default is to have all variables inspectable and hence this is not a problem. In some respects the issue is similar to the decision taken in Ada that when a package is withed, by default all entities declared in the package's visible part are available in the withing unit. An alternative approach would have the latter specify exactly those entities that are needed. Although seemingly producing a narrower and more specific interface, this would in practice yield long lists of needed entities that no one would read, and programmers would end up using a notation that made all visible entities available. In the case of inspection points, the anticipated typical usage is to have all objects inspectable; in those contexts where the programmer knows that only a limited set is of interest, a specific list can be provided as argument to pragma Inspection_Point. Pragma Inspection_Point with a specific list of names provides some of the capabilities of an assertion facility without the need of an additional language feature. For example, if one writes <syntaxhighlight lang="Ada"> pragma Inspection_Point(Alpha, Beta);</syntaxhighlight> then, when the program is executed under the control of an appropriate monitor / debugger, it may be suspended at the corresponding point in the object code. Information is available at that point to examine Alpha and Beta. Therefore an assertion, say that Alpha < Beta, can be checked at that point. Note that no change to the generated code is required, which would be an issue if the assert capability were to be provided via an alternative mechanism. Variables such as Alpha and Beta must be in scope. Also, if such Inspection_Point pragmas are added at several points in a program, it may be possible to formally verify that the object code between the pragmas performs the operations in the source code. == <span id="3">H.3 Safety and Security Restrictions</span> == A key technique that those developing critical software adopt is that of restricting the language constructs used. For instance, if tasking is not used, then the validation process is much simpler, since certain kinds of programming errors specific to tasking (such as deadlock, race conditions, and so on) cannot arise, and, moreover, the run-time system does not need to include any tasking support. Although the term "subset" often has negative connotations, since in the past uncontrolled subsets for other languages have led to major portability problems, in the context of safety and security applications the use of subsets is essential. The issue is then how to satisfy these requirements without sacrificing the obvious significant advantages that Ada has enjoyed as a single-language standard. Interestingly, the current revision to the COBOL standard is going to a single-language model, in contrast to the language modules approach of the past, partly because of the success that Ada 83 has had with program portability. The approach adopted is for the user to indicate excluded features as arguments to pragma Restrictions. The default behavior is for a compilation unit (or more generally a partition) to be rejected if it uses a feature identified in the pragma. Hence an Ada 95 compiler may enforce usage subsets in the manner required by [MoD 91], thus avoiding the potential risk of manual checking for adherence to restrictions. Moreover, an implementation is permitted to "bundle" restrictions, since otherwise compiler vendors would need to support 2N versions of the run- time system, where N is the number of possible arguments to the pragma. Thus the pragma should not be seen as a way for precisely defining a subset, but as a framework which a vendor can exploit. As an example, consider the safety critical system produced by Alsys and described in [Brygier 93]. Here, an Ada 83 subset is defined which has a zero-byte run-time system, called CSMART. This subset is vendor-specific since it is oriented around the structure of the Alsys run-time system. An Ada 95 version of this system could be developed which is based on language- defined parameters to the Restrictions pragma. The set of restrictions identified in the Safety and Security Annex is a representative set, but a compiler implementation may extend it. For example, in the SPARK system [Carre' 88] the requirement is to use only those language features to which formal proof tools can be applied. Hence features such as generics are excluded, even though the implementation issues are straightforward. Other analysis tools [Rex 88] impose similar restrictions on the source language. A vendor intending to support Ada 95 in those environments may thus add further restrictions to those defined in the Annex. Although the default behavior in the presence of pragma Restrictions is to reject a compilation unit (or partition) if a restricted feature is used, the implementation may have a "full language" mode of operation where the use of a restricted feature elicits a warning message versus a fatal error. This could be useful in some environments, and it helps address the compiler validation concerns that might otherwise surround an implementation of a subset. Possible scenarios showing uses of the Restrictions pragma are given in the following two examples. ==== Application to a Safety System ==== Vendor A produces a compiler and an implementation of the Safety and Security Annex, targeted to safety applications which use a standard similar to [DO-178B]. To simplify the production of the compiler and ensure the documentation aspects of reviewable object code are met, they require the use of the arguments No_Protected_Types, No_Allocators, No_Dispatch, No_Delay, No_Exceptions and Max_Tasks = 0 when the pragma Reviewable is applied to a partition. The user of this system has chosen this compiler because of the option above, knowing that the object code produced has a very simple structure, and that therefore the source code and object code are easily related. The user understands that since checking code does not appear in the object code, it is essential for this application to ensure that the code is indeed exception-free. To this end, a program analysis tool is being used. The pragma Normalize_Scalars is not used. To ensure that some language features are not used which would cause problems for the program analysis tool, additional parameters are specified by the user to the Restrictions pragma as follows: No_Floating_Point, No_Fixed_Point, No_Access_Subprograms. In other words, the design requirements of not using these features are enforced by the compiler by means of the pragma. In fact, the program analysis tool cannot handle Unchecked_Conversion. However, this restriction cannot be imposed by use of the Restrictions pragma since the application does require its use. In consequence, the use of Unchecked_Conversion is confined to one package which is not analyzed by the tool. This package uses the attribute Valid to ensure that the raw data will not subsequently cause an unbounded error. ==== Application to a Security System ==== Vendor B produces a compiler specifically for the security community who produce systems complying with the Orange Book and ITSEC [DoD 85, ITSEC 91]. Here, the full language is supported by the vendor when pragma Reviewable is enforced, since some applications require almost all of the language. The user chooses this compiler since the Annex is supported with the full language. Tested packages which have formed part of other systems are being imported into their applications, and therefore the imposition of the restrictions is not usually feasible. Again, the user has tools to analyze the Ada source code to validate both the security kernel and the main application code for adherence to the security policy. Since the kernel and the application code are all in one partition, it is only possible to use the pragma Restrictions for those features not used in any part of the system. For instance, Unchecked_Conversion is used in the kernel but should not appear in the application code, and hence this rule cannot be enforced by the Restrictions pragma. On the other hand, the declaration of access-to- subprogram types is not required at all, and hence this restriction is checked by the pragma. Since the full language is supported by the vendor, the documentation provided to adhere to the pragma Reviewable is quite complex. To aid the review of the object code, the vendor provides a special tool, based upon the debugger, to ease the process of independent validation and verification. In particular, the tool can be used to locate the object code arising from a specific statement or declaration. This facility depends on the removal of optimizations that would be applied in the absence of pragma Reviewable. The user decides to employ the pragma Normalize_Scalars to reduce the risk of a covert channel and also to aid the detection of programming errors. (In principle, program components could communicate information via unset scalar values, thus establishing a secret or covert communication channel.) Hence, in this example, the pragma Restrictions has a modest effect upon the compiler and its method of use. ==== Other Applications ==== The Restrictions pragma could clearly be used in other contexts apart from safety and security. For instance, in the context of teaching Ada, it might be convenient to ensure students are using just those features which would be allowed when developing high integrity software. Since the pragma is a configuration pragma, it should be simple to set up an Ada compilation system so that the student does not need to use pragma Restrictions explicitly. Some high performance applications could also use the pragma to ensure an appropriately tailored run-time system is used. == <span id="4">H.4 Validation against the Annex</span> == The majority of the Ada 95 standard consists of specific features for which the conventional validation process works well. Corresponding to each feature, a number of Ada test programs can be written for which the outcome can be stated and checked, usually within the test program itself. In contrast, the essence of the Safety and Security Annex is not language features but high assurance for the application program. Thus it is clear that validation of implementations to this Annex is different from both the other Annexes and also from Ada 83. The problem of devising objective tests needs to be considered carefully in the context of the high assurance required, not just adherence to the standard. == <span id="5">H.5 Issues outside the Scope of the Standard</span> == The Safety and Security community have concerns which cannot be addressed by the Ada 95 standard itself. These issues are recorded here for completeness and to demonstrate that the standard was not the correct place to have them resolved. The general requirement is for a "high assurance" compiler and run- time system. However, it is not possible to characterize this by means of requirements which are consistent with a language standard. The philosophy adopted by the Annex is to require information so that a user can judge whether a specific compiler meets the (subjective) requirements of an application. Some of the issues which arise here are as follows: ; Version control for compilers and run-time; : Each version of the compiler and/or run-time system must be distinguished by a version number. It is convenient if it is easy to trace back from the binary to the corresponding source code. ; Validation of compiler in non-standard modes; : The compiler may well be used in a mode of operation which does not support the full language. In such a case, documentation is required (specified in the Annex). However, it is often convenient to provide information on the processing of the validation suite in this mode (not required by the Annex). There is a significant change from Ada 83 here, since a mode of operation in which some language features are not supported can be provided by means of the Restrictions pragma. ; Security of compiler against Orange book or ITSEC; : If a compiler is being used in a security context, it would be necessary to know that it conformed to the relevant requirements [DoD 85, ITSEC 91]. ; Compiler support; : Critical projects are likely to require support from the vendor over an extended period. ; Evaluation; : The Ada Compiler Evaluation Service provides additional tests to measure aspects such as processing speed which cannot be specified in the standard. Special tools are also available to stress test compilers in order to give further confidence in their quality; see [Austin 91] and [Elsom 91]. ; Certification of a specific system; : It would be convenient if a specific Ada run-time system could be formally certified. This would give additional confidence in a system, and would allow a vendor to provide an identical platform for several market areas. However, it is unclear how such a service would operate. In short, the requirements for critical systems go beyond those aspects which are covered by a conventional standard, and hence those which can be satisfied by the ordinary validation process. == <span id="6">H.6 Requirements Summary</span> == The facilities of the Safety and Security Annex relate generally to the requirements in 9.1 (Predictability of Execution), 9.2 (Certifiability), and 9.3 (Enforcement of Safety-Critical Programming Practices). More specifically, the study topic * S9.1-A(1) - Determining Implementation Choices is met by the Normalize_Scalars pragma and by the requirements for documentation of implementation decisions. The requirement * R9.1-A(2) - Ensuring Canonical Application of Operations is met by the pragma Inspection_Point and by the provision of Off as an argument to the pragma Optimize. The requirement * R9.2-A(1) - Generating Easily Checked Code is met by the Reviewable and Inspection_Point pragmas. The requirement * R9.3-A(1) - Allow Additional Compile-Time Restrictions is met by the pragma Restrictions. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p3-g|Previous]] | [[Guide:9x_rationale/rat95-p4|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=Annex H. Safety and Security}} f02fwnk320y4qm6uw7tse4dgc34db5o Guide:9x rationale/rat95-p4 4200 353 1884 1814 2019-04-20T16:21:26Z WikiVisor 11 Text replacement - "[[Guide:9x_rationale/rat95-copyright|Copyright]] | " to "<div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | " wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p3-h|Previous]] | [[Guide:9x_rationale/rat95-p4-x|Next]]</div> ''This fourth part comprises three appendices which summarize various aspects of the relationship between Ada 83 and Ada 95. Appendix X covers the incompatabilities of which there are few of real significance. Appendix Y gives the main changes betwen the Committee Draft, the Draft International Standard and the final International Standard; it shows that these changes are few and hence that the final language has had the benefit of considerable stability throughout the review periods. Appendix Z is a brief summary of the mapping between the original Requirements and the sections of this rationale where they are addressed; it concludes that Ada 95 meets the Requirements.'' <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p3-h|Previous]] | [[Guide:9x_rationale/rat95-p4-x|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=Part Four. The Appendices }} na8f324ej65dnf7mp9vwwfpoh8x2u4r Guide:9x rationale/rat95-p4-x 4200 354 1856 1827 2019-04-20T16:19:56Z WikiVisor 11 Text replacement - "|Next]]" to "|Next]]</div>" wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p4|Previous]] | [[Guide:9x_rationale/rat95-p4-y|Next]]</div> A major design goal of Ada 95 was to avoid or at least minimize the need for modifying the existing base of Ada 83 software to make it compatible with Ada 95. This involves not only pursuing upward compatibility but also preserving implementation-dependent behavior that can currently be relied upon. In common with the experience of revising other language standards, it is infeasible to guarantee 100% compatibility. Other languages have been more or less successful in meeting this goal. For example, COBOL 83 has been very successful in achieving upward compatibility with COBOL 74. Nevertheless some minor incompatibilities were introduced which affect existing programs. For example, IS_ALPHABETIC, accepts upper and lower case in the new COBOL standard. The transition from C to ANSI C and from there to C++ has also caused incompatibilities, for example C++ requires all procedure definitions in old-style C to be modified. In the design of Ada 95, a very conservative approach has been adopted. The few incompatibilities that exist can be dealt with in a simple mechanical way. For example, the introduction of a small number of reserved words requires their replacement in any program using them as identifiers. Extensive surveys of existing code show few programs to be affected. Most of the other incompatibilities involve obscure or pathological programming styles which are expected to appear very infrequently in existing code. The great majority of programs will not be significantly affected by these changes - the most likely incompatibilities being automatically detected at compilation time. Moreover, tools are being developed to aid in the reliable detection of any problems and thereby smooth the process of transition. Only three incompatibilities are considered likely to occur in normal programs. They are as follows: * New reserved words - In Ada 95, six new reserved words have been added to the language. * Type Character has 256 positions - In Ada 95, the type Character has 256 positions. In Ada 83, it had 128 positions. * Unconstrained generic parameters - In Ada 95, different syntax must be used in a generic formal parameter to allow unconstrained actual parameters. The following further two incompatibilities might occur in normal programs but are less likely: * Library package bodies illegal if not required - In Ada 95, it is illegal to provide a body for a library package that does not require one. * Numeric_Error renames Constraint_Error - In Ada 95, the declaration for Numeric_Error has been changed to a renaming of Constraint_Error. These incompatibilities usually cause a legal Ada 83 program to be an illegal Ada 95 program and hence are detected at compile time. They are described in more detail in the ensuing sections. In each case we give an example of the incompatibility, an indication of how it can be avoided in existing Ada 83 programs and the possibility of its automatic detection and removal. The remaining incompatibilities which are considered very unlikely to occur in normal programs are briefly considered in X.6. The reader should note that we say that an incompatibility is consistent if the worst that can happen is that a legal Ada 83 program becomes illegal in Ada 95 and thus fails to compile. An incompatibility is said to be inconsistent if the program can remain legal but have a different meaning. == <span id="1">X.1 Reserved Words</span> == Six new reserved words are introduced in Ada 95: abstract, aliased, protected, requeue, tagged, and until. Two alternatives to new reserved words were considered: a new concept of unreserved keywords or the use of combinations of existing reserved words. Neither of these options was considered preferable to the transitory inconvenience caused by the introduction of the new reserved words. An Ada 83 program that uses any of these words as identifiers is an illegal Ada 95 program. For example, the following fragment of Ada 83 will fail to compile in Ada 95 because it uses two of the new reserved words <syntaxhighlight lang="Ada"> Protected: Boolean := False; procedure Requeue(The_Activity: Activity; On_Queue: Queue);</syntaxhighlight> Avoidance is clearly straightforward - avoid use of these six words as identifiers. Detection of the incompatibility is also straightforward. Automatic correction is problematic - to ensure that a name change is valid requires significant analysis especially if the identifier is the name of a library unit, or occurs in a package specification for which use clauses occur. == <span id="2">X.2 Type Character</span> == In Ada 95, the type Character has 256 positions. In Ada 83, it had 128 positions. Although suitable for English-speaking nations, a character type based on ASCII is inappropriate for most of Europe. ISO has defined a number of 256 character standards such as Latin-1 and Latin-2. This change to the language thus accommodates non-English speaking nations. An Ada 83 program could be an illegal Ada 95 program if it has a case statement or an array indexed by Character, but it could be a legal Ada 95 program with different semantics if it relies on the position number or value of Character'Last. For example <syntaxhighlight lang="Ada"> type Char_Kind is (Numeric, Alphabetic, Other); Kind_Array: array (Character) of Char_Kind := -- (1) ('0' .. '9' => Numeric, 'A' .. 'Z' | 'a' .. 'z' => Alphabetic, others => Other); case Char is -- (2) when Character'Val(0) .. Character'Val(63) => ... when Character'Val(64) .. Character'Val(127) => ... end case; I: Integer := Character'Pos(Character'Last); -- (3)</syntaxhighlight> Declaration (1) is legal in Ada 95 but probably does not achieve the desired effect. Statement (2) is illegal in Ada 95 and will be detected at compilation. Statement (3) illustrates a situation where the program will still execute but have a different effect in Ada 95 (it is inconsistent). As it is likely that allowing for 256 characters is outside the scope of the original requirement for the program concerned, avoidance is not really the issue - a review of the requirements is necessary. The inconsistency illustrated by the third example can be avoided by not depending on the position or value of Character'Last. Avoiding the other incompatibilities avoids the real issue of how the extra 128 characters are to be handled. Unless uniform behavior is acceptable for these extra characters, use of an others choice, whilst ensuring a legal (but bad style) Ada 95 program might cause unacceptable behavior. Detection of the consistent incompatibilities is straightforward; detection that an inconsistency may arise is possible. Manual correction is necessary to determine whether the required semantics of the program are those defined by Ada 95. Finally, it should be noted that the ISO Working Group with responsibility for maintaining the Ada standard, has decreed that this change can be introduced into Ada 83 compilers, so this will increasingly become an Ada 83 portability issue as more implementations support 256 characters. == <span id="3">X.3 Library Package Bodies</span> == In Ada 95, library unit packages are allowed to have a body only if required by language rules. This avoids a nasty and not so rare error. In Ada 83, a body need only be provided for a package that really needed one, such as where the specification contains subprogram or task declarations. If a body was provided for a library package that did not need a body (for performing initializations for example), then if the package specification was subsequently changed, the body became obsolete. However, since it was optional, subsequent builds incorporating the package would not incorporate the body, unless it was manually recompiled. This obviously affects packages, for example, that only declare types, constants and/or exceptions, a very common occurrence. As a trivial example in Ada 83 consider <syntaxhighlight lang="Ada"> package Optional_Body is Global_Variable: Integer; end Optional_Body; ----------------------------------------- with Integer_Function; package body Optional_Body is begin Global_Variable := Integer_Function; end Optional_Body;</syntaxhighlight> The solution adopted in Ada 95 is to allow a body for a library unit package only when one is required by some language rule; the above example is therefore illegal in Ada 95. However, the pragma Elaborate_Body can be used to cause a body to be required. Given the non-uniform functionality of program libraries and sublibraries, it is probably wise not to try to automatically detect, let alone correct, this incompatibility. == <span id="4">X.4 Indefinite Generic Parameters</span> == Ada 95 provides new syntax for a generic formal private type to indicate that the actual subtype is allowed to be indefinite. The old syntax is retained, but the meaning is changed to require definite actual parameters. In Ada 83, no indication was given in a generic formal type declaration as to whether the actual needed to be definite, for example because the body declared an uninitialized variable for the type. It was thus possible for a legal instantiation to become illegal if the body was changed. An Ada 83 program, where an indefinite type is used as a generic actual parameter is an illegal Ada 95 program. For example the following legal Ada 83 program is illegal in Ada 95 <syntaxhighlight lang="Ada"> generic type Element_Type is private; package Stack is ... ------------------------------------------------------ with Stack; package String_Stack is new Stack(Element_Type => String);</syntaxhighlight> There is no way to avoid this incompatibility but an Ada 83 program can be annotated with an appropriate comment, thus <syntaxhighlight lang="Ada"> generic type Element_Type is private; -- !! (<>) in Ada 95 package Stack ...</syntaxhighlight> Detection of the incompatibility is straightforward. Manual correction is necessary to determine whether restricting the actual to being definite is acceptable. It is interesting to note that some predefined library units in Ada 83 used this feature and so are changed. Examples are Unchecked_Conversion and Unchecked_Deallocation and also Sequential_IO. Finally, it should be noted that the ISO Working Group has recommended that Ada 83 compilers be allowed to accept the new syntax in order to simplify transition. == <span id="5">X.5 Numeric Error</span> == In Ada 95, the exception Numeric_Error is declared in the package Standard as a renaming of Constraint_Error. The checks that could cause Numeric_Error to be raised in Ada 83 have all been reworded to cause Constraint_Error to be raised instead. Indeed, this change has been sanctioned by the Ada Rapporteur Group and encouraged in existing Ada 83 implementations. However, the alternative of completely removing Numeric_Error was rejected because it would naturally have caused an incompatibility in programs using the construction <syntaxhighlight lang="Ada"> when Numeric_Error | Constraint_Error => Some_Action;</syntaxhighlight> which is the currently recommended way of avoiding the confusion between Numeric_Error and Constraint_Error in Ada 83. This construction is still allowed in Ada 95 because of an additional rule that permits an exception to be mentioned more than once in the same handler. Programs which do have distinct separate handlers for Numeric_Error and Constraint_Error such as <syntaxhighlight lang="Ada"> exception when Constraint_Error => Action_1; when Numeric_Error => Action_2; end;</syntaxhighlight> are illegal in Ada 95. Moreover, an inconsistency will arise if a frame has an explicit handler for Numeric_Error or Constraint_Error but not both as in the following <syntaxhighlight lang="Ada"> exception when Constraint_Error => Action_1; when others => Action_2; end;</syntaxhighlight> since Numeric_Error will be caught by the first handler in Ada 95 but by the second in Ada 83. Detection of the incompatibility is straightforward but manual correction will be necessary in cases where Numeric_Error is treated differently. == <span id="6">X.6 Other Incompatibilities</span> == It is considered that other incompatibilities will be unlikely to occur in normal programs - the Ada 83 semantics being known only to the most erudite of Ada programmers - and so only a brief description seems appropriate in this document. In the following summary, they are grouped according to whether they result in a legal Ada 95 program but with different semantics; whether they would be detectable by an Ada 95 compiler and so on. === <span id="6-1">X.6.1 Unlikely Inconsistencies</span> === These incompatibilities might cause a change in the runtime behavior, but they are not thought likely to occur in normal programs. * Derived type inherits all operations of parent - In Ada 95 a derived type inherits all its parent's primitive operations previously declared in the same declarative part. In Ada 83, it did not. * Floating point types may have less precision - the chosen representation for a floating point type may have less precision in Ada 95 for hardware with a non-binary radix. * Fixed point types may have less precision - the chosen representation for a fixed point type may have less precision in Ada 95. This is related to the next item. * Default Small for fixed point types - In Ada 83, the default value of Small was defined to be the largest power of two not exceeding S'Delta. In Ada 95, it is allowed to be a smaller power of two. * Rounding from real to integer is deterministic - Rounding is defined in Ada 95 as away from zero if the real number is midway between two integers. * Evaluation order of defaulted generic actual parameters - The order of evaluation of defaulted generic actuals is arbitrary in Ada 95. * Static expressions evaluated exactly - Static expressions are always evaluated exactly in Ada 95. In Ada 83 this was only required in a static context. === <span id="6-2">X.6.2 Unlikely Incompatibilities</span> === These incompatibilities cause a legal Ada 83 program to be an illegal Ada 95 program and hence are detectable at compile time. They are considered to be unlikely in normal programs. * Bad pragmas illegal - In Ada 95, a pragma with an error in its arguments makes the compilation illegal. In Ada 83, it was ignored. * S'Base not defined for composite subtypes - In Ada 95, S'Base is not defined for a composite subtype S. * Wide_Character shares all character literals - As a result of adding types Wide_Character and Wide_String to package Standard, Ada 95 character literals are always overloaded and Ada 95 string literals are always overloaded. * Definition of freezing tightened - In Ada 95, range constraints on a type after its declaration and in occurrences in pragmas freeze the representation (are treated as forcing occurrences). In Ada 83 they were not treated as forcing occurrences. * Static matching of subtypes - In Ada 95, matching of subtypes is now performed statically instead of at runtime (as in Ada 83) in array conversions and generic instantiations. * Illegal to use value of deferred constant - In Ada 95 it is illegal to use the value of a deferred constant before it is set. In Ada 83 it was erroneous. * Explicit constraints in uninitialized allocators designating access types - in Ada 95 such constraints are illegal; in Ada 83 they were ignord. * Exceptions in static expressions illegal - in Ada 95, it is illegal to raise an exception in a static expression; in Ada 83 it made the expression non-static. * Preference for universal numeric operators - In Ada 95, the overload resolution rules have been changed to simplify them. As a consequence certain pathological Ada 83 programs become illegal. * Assume worst when checking generic bodies - Ada 83 generic contract model violations have been overcome in Ada 95 by assuming the worst case in a generic body. * New identifiers added to package System - New identifiers in package System may introduce illegalities into a unit having a use clause for System. * Append_Mode added to File_Mode enumeration - In Ada 95, subtype File_Mode in packages Sequential_IO and Text_IO has an extra literal, Append_Mode. * New identifiers added to package Text_IO - New identifiers in package Ada.Text_IO may introduce illegalities into a unit having a use clause for Text_IO. * New identifiers added to package Standard - New identifiers in package Standard may clash with existing use-visible identifiers. * Functions returning local variables containing tasks - In Ada 95 it is illegal or raises Program_Error if a function with a result type with a task subcomponent returns a local variable. In Ada 83 it was erroneous to return a variable containing a local task. * Illegal to change representation of types containing tasks - In Ada 95, it is illegal to give a representation item for a derived type containing a task. * Character literals always visible - In Ada 95, character literals are visible everywhere. In Ada 83 they followed the usual rules of visibility. === <span id="6-3">X.6.3 Implementation Dependent Incompatibilities</span> === These incompatibilities only arise with some implementations. They occur either as a result of tightening up Ada semantics or where an Ada 83 implementation has used an identifier now predefined in Ada 95. In the latter case, an inconsistency could occur if the Ada 83 use of the identifier is compatible with the Ada 95 use, though this is unlikely. * Real attributes replaced - The Ada 83 attributes for a real subtype S (such as S'Mantissa) have been replaced by Ada 95 attributes defined in the Numerics Annex. * Certain pragmas removed - Some pragmas (including Interface and Shared) have been removed from the language and Priority has been moved to the Real-Time Systems annex. * New pragmas defined - The names of new pragmas may clash with implementation-defined pragmas. * New attributes defined - The names of new attributes may clash with implementation-defined attributes. * New library units defined - The names of new (language-defined) library units may clash with user-defined or implementation-defined library units. === <span id="6-4">X.6.4 Error Incompatibilities</span> === These incompatibilities only occur in programs containing runtime errors, either detectable (an exception is raised) or undetectable (the execution is erroneous). * Exceeding 'First or 'Last of an unconstrained floating point type - In Ada 95, the 'First and 'Last of a floating point type declared without a range constraint are treated as minimum bounds and may be exceeded without causing Constraint_Error. * Dependent compatibility checks performed on object declaration - In Ada 95, dependent compatibility checks are performed on object declaration. In Ada 83, they were performed on subtype declaration. * Implicit array subtype conversion - Ada 95 allows sliding in more situations than did Ada 83, so Constraint_Error might not be raised as in Ada 83. * Lower bound of catenation changed for constrained array types - In Ada 95, the lower bound of the result of catenation for a constrained array type is defined to be 'First of the index subtype. In Ada 83, the lower bound of the result was 'First of the left operand. * Raising Time_Error deferred - In Ada 95, raising Time_Error can be deferred until Split or Year is called, or might not be raised at all. In Ada 83, it is raised on "+" or "-". * Data format for Get - In Ada 95, Get for real types accepts a wider range of formats which would raise Data_Error in Ada 83. Leading and trailing zeros and the radix point are not required. == <span id="7">X.7 Conclusion</span> == This appendix has outlined the incompatibilities between Ada 83 and Ada 95. As we have seen, the small number that are likely to occur in practice are easily overcome. The remainder are unlikely to be encountered in normal programs but have been mentioned for completeness. For further details the reader should consult the comprehensive discussion in [Taylor 95] upon which this discussion has been based. In conclusion, it is clear that there are unlikely to be significant transition issues for the vast majority of Ada 83 programs. Ada 95 has been carefully designed to minimize incompatibilities while meeting the overall goals of the requirements. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p4|Previous]] | [[Guide:9x_rationale/rat95-p4-y|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=Appendix X. Upward Compatibility}} dgkgij2ybxt6tppnihohvwx7ng1yxjy Guide:9x rationale/rat95-p4-y 4200 355 1855 1845 2019-04-20T16:19:56Z WikiVisor 11 Text replacement - "[[Guide:9x_rationale/rat95-copyright|Copyright]] | " to "<div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | " wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p4-x|Previous]] | [[Guide:9x_rationale/rat95-p4-z|Next]]</div> The final International Standard for Ada 95 incorporates a number of changes to the Committee Draft [CD 93] of September 1993 (version 4.0 of RM9X) and the Draft International Standard [DIS 94] of June 1994 (version 5.0). These were made in response to formal comments made by the ISO members as part of the ballots on these drafts and to informal comments made by individual reviewers. Although many of the changes are of an editorial nature several are of significance to the normal user. The more important changes are outlined in this appendix for the convenience of readers familiar with the drafts. Unless otherwise mentioned changes are with respect to the CD; if a change has occurred since the DIS then this is explicitly mentioned. A reference to that section of the rationale containing further discussion of the topic is given where appropriate. The organization of the standard has been rearranged into a more logical order. The most significant to users familiar with Ada 83 is that chapter 14 on input-output has been moved into the annex on the predefined environment where it logically belongs. The annexes have themselves been reordered so that the mandatory annexes on the predefined environment and interfacing to other languages come first, followed by the six specialized needs annexes, the obsolescent features and then finally the non-normative annexes summarizing attributes and so on. == <span id="1">Y.1 Core Language</span> == ==== Trailing underlines ==== Trailing underlines are not allowed in identifiers whereas they were in the Committee Draft. Reversion to the Ada 83 rule was deemed appropriate because allowing just trailing underlines did not achieve the flexibility desired for wide compatibility with other languages such as C. Permitting leading underlines and multiple embedded underlines would have given greater compatibility but was considered unacceptable given the strength of concern for readability of program text. (2.1) ==== Modular types ==== Modular types are no longer described in terms of principal values and secondary values; they just have a value. A consequence is that conversion to and from integer types always preserves the numerical value or raises Constraint_Error. Wraparound on conversion no longer occurs. (3.3.2) ==== Extension aggregates ==== The ancestor part can now be a subtype name as an alternative to an expression. This enables an extension aggregate to be written even when the ancestor is abstract such as in the case of controlled types. (3.6.1, 7.4) ==== Controlled types ==== The package Ada.Finalization is restructured. The types Controlled and Limited_Controlled are no longer derived from types in the package System.Implementation (which no longer exists) but are simply abstract private types. The previous problem with writing aggregates for types derived from abstract types is now overcome by the new form of extension aggregate mentioned above. The procedure Split is now called Adjust. The procedures Adjust and Finalize are no longer abstract but have null bodies like Initialize. (7.4) ==== Task storage size ==== The new pragma Storage_Size permits setting the storage size for individual tasks of a task type. This pragma is placed in the task specification and could thus depend on the value of a task discriminant. It replaces the use of an attribute definition clause for setting Storage_Size which gave the same attribute value to all tasks of the type. (9.6) ==== Children of generic units ==== It is no longer necessary for a child of a generic unit to be instantiated as a child of an instantiation of its parent. This requirement of the CD and DIS caused problems for many applications and a child can now be instantiated anywhere provided the generic child is visible. (10.1.3) ==== Exception occurrences ==== The package Ada.Exceptions is significantly restructured. The generic child Ada.Exceptions.Messages has been deleted. The ability to attach a user message to the raising of an exception can now be done more flexibly using the procedure Raise_Occurrence and the new attribute Identity. A major advantage is that exceptions so raised do not all have the same name Exception_With_Message. The type Exception_Occurrence is now limited so that occurrences cannot be directly assigned. Exceptions can now be saved by a procedure and function Save_Occurrence. This approach overcomes implementation problems associated with the size of saved information. (11.2) ==== Access in generic bodies ==== The Access attribute can now be applied to objects in generic bodies when the access type is external. The associated accessibility check is dynamic and raises Program_Error if it fails. This gives greater flexibility in the use of generics. Note that the Access attribute still cannot be applied to subprograms in generic bodies when the access type is external. (12.3) ==== Alignment and Size attributes ==== The rules regarding these attributes have been somewhat changed. They can now only be applied to first subtypes (and objects) and not to all subtypes. Furthermore the Address must be a multiple of the Alignment. (13.1) == <span id="2">Y.2 Predefined Environment</span> == ==== Package Characters ==== This has been slightly restructured. The classification and conversion functions are now in a child package Characters.Handling and the package Characters is itself empty (other than the pragma Pure). The reason for this change is so that the child Characters.Latin_1 can be used without introducing any unnecessary executable code from its parent. A related change is that the package Standard.ASCII is now obsolescent; programmers are expected to use Characters.Latin_1 instead. (A.1) ==== Import and Export ==== The pragmas Import and Export now have a fourth parameter. The third parameter now gives the name of the entity in the other language and the fourth parameter gives the link name. (B.1) ==== Text_IO ==== A number of improvements have been made to Text_IO. The concept of an error output stream has been added in line with facilities in many operating systems. Subprograms enable the error stream to be manipulated in a manner similar to the default output stream. The functions Current_Input, Current_Output and Current_Error are overloaded with versions returning an access value. This enables the current stream to be preserved for later use in a more flexible manner. The procedure Get_Immediate provides immediate non-buffered and non- blocking input; this is useful for interactive applications. The procedure Look_Ahead returns the next character without removing it; this enables the user to write procedures which behave in a similar manner to the predefined procedures Get for integer and real types. The procedure Get for real types will now accept a literal in more liberal formats; leading and trailing digits around the radix point are not required and indeed the point itself may be omitted. This enables data produced by programs written in languages such as Fortran to be processed directly. The procedure Flush is added; this outputs the contents of the current buffer. Nongeneric packages equivalent to instantiations of Integer_IO and Float_IO with the predefined types have been added since the DIS. These will be found of considerable benefit for teaching Ada since simple input-output of numbers can now be performed without the introduction of genericity. (A.4) ==== Command line ==== The package Ada.Command_Line enables a program to access the commands and parameters of the command line interpreter if any. It also enables a program to set its result status. (A.5) ==== Random number generator ==== The package Ada.Numerics.Random_Numbers has been considerably restructured and renamed as Ada.Numerics.Float_Random. The additional generic package Ada.Numerics.Discrete_Random produces streams of random discrete values. (A.3) == <span id="3">Y.3 Specialized Needs Annexes</span> == ; Edited output : The package Ada.Text_IO.Pictures is now called Ada.Text_IO.Editing. The description has been recast to avoid dependence on the COBOL standard. (F.2) <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p4-x|Previous]] | [[Guide:9x_rationale/rat95-p4-z|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=Appendix Y. Revisions To Drafts}} ils477pdnf77m9wb33q2kg39fazdk07 Guide:9x rationale/rat95-p4-z 4200 356 1835 1818 2019-04-20T16:19:20Z WikiVisor 11 Text replacement - "[[Guide:9x_rationale/rat95-copyright|Copyright]] | " to "<div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | " wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p4-y|Previous]] | [[Guide:9x_rationale/rat95-references|Next]]</div> This appendix lists the various requirements and study topics discussed in the Requirements document [DoD 90] and generally indicates how they have been met (by refererence to other parts of this rationale) or else notes why they proved to be inappropriate. == <span id="1">Z.1 Analysis</span> == The requirements are listed here in exactly the order of the requirements document; against each requirement is a list of the one or more Requirement Summary sections of this rationale containing an indication of how the requirement has been met. Note that a detailed analysis of how the requirements themselves relate back to the original Revision Requests is contained in the Requirements Rationale [DoD 91]. ==== General ==== <pre>R2.1-A(1) - Incorporate Approved Commentaries 1.5 R2.1-A(2) - Review Other Presentation Suggestions 1.5 R2.1-B(1) - Maintain Format of Existing Standard 1.5 R2.1-C(1) - Machine-Readable Version of the Standard 1.5 R2.2-A(1) - Reduce Deterrents to Efficiency 3.11, 8.5, 9.8 R2.2-B(1) - Understandability 1.5, 3.11, 8.5 R2.2-C(1) - Minimize Special-Case Restrictions6.4, 8.5, 11.5 S2.3-A(1) - Improve Early Detection of Errors 1.5, 3.11 R2.3-A(2) - Limit Consequences of Erroneous Executions 1.5 R2.4-A(1) - Minimize Implementation Dependencies 3.11</pre></li> ==== International Users ==== <pre>R3.1-A(1) - Base Character Set 3.11 R3.1-A(2) - Extended Graphic Literals 3.11 R3.1-A(3) - Extended Character Set Support 3.11 R3.1-A(4) - Extended Comment Syntax 2.4 S3.1-A(5) - Extended Identifier Syntax 2.4</pre></li> ==== Programming Paradigms ==== <pre>S4.1-A(1) - Subprograms as Objects 3.11, 4.8 R4.1-B(1) - Passing Subprograms as Parameters 3.11 R4.1-B(2) - Pragma INTERFACE 3.11, B.5 R4.2-A(1) - Allocation and Reclamation of Storage 13.7 S4.2-A(2) - Preservation of Abstraction 7.5 S4.3-A(1) - Reducing the Need for Recompilation 4.8, 10.6 S4.3-B(1) - Programming by Specialization/Extension4.8, 10.6 S4.3-C(1) - Enhanced Library Support 10.6 S4.4-A(1) - Generic Formal Parameters 12.8 R4.4-B(1) - Dependence of Instantiations on Bodies 12.8 S4.4-B(2) - Tighten the "Contract Model" 12.8 R4.4-C(1) - Generic Code Sharing 12.8 R4.5-A(1) - Accessing an Exception Name 11.5 R4.6-A(1) - Interactive TEXT_IO A.6 R4.6-B(1) - Additional Input/Output Functions A.6</pre></li> ==== Real-Time ==== <pre>R5.1-A(1) - Elapsed Time Measurement 9.8, D.13 R5.1-B(1) - Precise Periodic Execution 9.8, D.13 R5.1-C(1) - Detection of Missed Deadlines 9.8 R5.2-A(1) - Alternative Scheduling Algorithms 9.8, D.13 R5.2-A(2) - Common Real-time Paradigms 9.8 R5.3-A(1) - Asynchronous Transfer of Control 9.8 R5.4-A(1) - Non-Blocking Communication 9.8 S5.4-B(1) - Asynchronous Multicast 9.8</pre></li> ==== System Programming ==== <pre>R6.1-A(1) - Unsigned Integer Operations 3.11 R6.2-A(1) - Data Interoperability 13.7 R6.3-A(1) - Interrupt Servicing 9.8, C.7 R6.3-A(2) - Interrupt Binding 9.8, C.7 R6.4-A(1) - Access Values Designating Global Objects 3.11 S6.4-B(1) - Low-Level Pointer Operations 3.11, 13.7</pre></li> ==== Parallel Processing ==== <pre>R7.1-A(1) - Control of Shared Memory C.7 S7.2-A(1) - Managing Large Numbers of Tasks 9.8 S7.3-A(1) - Statement Level Parallelism 9.8 S7.4-A(1) - Configuration of Parallel Programs 9.8</pre> No specific standard constructs for vector (SIMD) machines have been introduced; however the rules regarding exceptions have been changed so that vendors are able to provide optimizations through pragmas as discussed in 9.8. ==== Distributed Processing ==== <pre>R8.1-A(1) - Facilitating Software Distribution 10.6, E.8 R8.2-A(1) - Dynamic Reconfiguration 10.6, E.8</pre></li> ==== Safety-Critical and Trusted ==== <pre>S9.1-A(1) - Determining Implementation Choices H.6 R9.1-A(2) - Ensuring Canonical Application of Operations H.6 R9.2-A(1) - Generating Easily Checked Code H.6 R9.3-A(1) - Allow Additional Compile-Time Restrictions H.6</pre></li> ==== Information Systems ==== <pre>R10.1-A(1) - Decimal-Based Types 3.11, F.3 S10.1-A(2) - Specification of Decimal Representation F.3 S10.2-A(1) - Alternate Character Set Support F.3 S10.3-A(1) - Interfacing with Data Base Systems B.5, F.3 S10.4-A(1) - Varying-Length String Package A.6 S10.4-A(2) - String Manipulation Functions A.6, F.3</pre></li> ==== Scientific and Mathematical ==== <pre>R11.1-A(1) - Standard Mathematics Packages A.6, G.5 S11.1-B(1) - Floating Point Facilities G.5 S11.2-A(1) - Array Representation B.5</pre></li></ul> == <span id="2">Z.2 Conclusion</span> == The above analysis shows that all the formal Requirements have been thoroughly met and it is only the Study Topics for parallel processing where compromises have been made. We can therefore conclude that Ada 95 clearly meets the spirit of the Requirements as expressed in [DoD 90]. <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p4-y|Previous]] | [[Guide:9x_rationale/rat95-references|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=Appendix Z. Requirements}} k4ukr26jzzvr07kz5er4e1b2jrigt0e Guide:9x rationale/rat95-preface 4200 357 1895 1894 2019-04-20T16:41:26Z WikiVisor 11 wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-foreword|Previous]] | [[Guide:9x_rationale/rat95-p1|Next]]</div> Modern society is becoming very dependent upon software. Our transport systems, financial systems, medical systems and defense systems all depend to a very large degree upon software. As a consequence the safety of many human lives and much property now depends upon the reliable functioning of software. Moreover, the fall in the cost of hardware has now made possible the development of large software systems. Ada is a programming language of special value in the development of large programs which must work reliably. This applies to most defense applications (from which background Ada evolved) and extends to many application domains. Indeed over half the Ada programs now being developed are for non-defense applications. This document describes the rationale for Ada 95, the revised International Standard. Ada 95 increases the flexibility of Ada thus making it applicable to wider domains but retains the inherent reliability for which Ada has become noted. Important aspects of Ada 95 include * Object Oriented Programming. Ada 95 includes full OOP facilities giving the flexibility of programming by extension which enables programs to be extended and maintained at lower cost. * Hierarchical Libraries. The library mechanism now takes a hierarchical form which is valuable for the control and decomposition of large programs. * Protected Objects. The tasking features of Ada are enhanced to incorporate a very efficient mechanism for multitask synchronized access to shared data. This is of special value for hard realtime systems. These enhancements to Ada make Ada 95 an outstanding language. It adds the flexibility of languages such as C++ to the reliable Software Engineering framework provided and proven by Ada 83 over the past ten years. Ada 95 is a natural evolution of Ada 83. The enhancements have been made without disturbing the existing investment in Ada 83 programs and programmers. Upward compatibility has been a prime goal and has been achieved within the constraints imposed by other requirements. This document is in several parts. The first part is an Introduction to Ada 95; it presents a general discussion of the scope and objectives of Ada 95 and its major technical features. The second part contains a more detailed chapter by chapter account of the Core language. The third part covers the various Annexes which address the predefined environment and the needs of specialized application areas. Finally there are three appendices; Appendix X addresses the issue of upward compatibility with Ada 83 and shows that for normal programs the goal of compatibility has been achieved; Appendix Y summarizes the few changes since the two public drafts of the standard; Appendix Z summarizes the requirements and concludes that they have been met. This document will be of special value to program managers, team leaders and all software professionals with concern for the organized development of software. Ada 95 deserves the attention of all members of the computing profession. It is a coherent and reliable foundation vehicle for developing the major applications of the next decade. ''The Ada 9X Design Team,<br /> January 1995'' <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-foreword|Previous]] | [[Guide:9x_rationale/rat95-p1|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=Preface}} 8vsf6bqw81e5i6znvj1895qgpyqx25s Guide:9x rationale/rat95-references 4200 358 1838 1837 2019-04-20T16:19:21Z WikiVisor 11 Text replacement - "|Next]]" to "|Next]]</div>" wikitext text/x-wiki <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p4-z|Previous]] | [[Guide:9x_rationale/rat95-index|Next]]</div> <pre>[1003.1 90] The Institute of Electrical and Electronics Engineers. Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) [C Language]. The Institute of Electrical and Electronics Engineers, 1990 [1003.4 93] The Institute of Electrical and Electronics Engineers. Portable Operating System Interface (POSIX) - Part 1: Amendment 1: Realtime Extensions [C Language]. POSIX P1003.4/D14. March, 1993. [1003.4a 93] The Institute of Electrical and Electronics Engineers. Portable Operating System Interface (POSIX) - Part 1: Amendment 2: Threads Extensions [C Language]. POSIX P1003.4a/D7. April, 1993. [1003.5 92] The Institute of Electrical and Electronics Engineers. POSIX Ada Language Interfaces, Part 1 Binding for System Application Program Interface (API). The Institute of Electrical and Electronics Engineers, 1992. [AARM] Annotated Ada 95 Reference Manual, Version 6.0. Intermetrics Inc, 1995. [Abadi 91] M. Abadi, L. Cardelli, B. Pierce, and G. Plotkin. "Dynamic Typing in a Statically Typed Language". Transactions on Programming Languages and Systems 13(2), April 1991. [ANSI 83] Reference Manual for the Ada Programming Language. ANSI/MIL-Std-1815a edition, 1983. [Archinoff 90] G. H. Archinoff, R. J. Hohendorf, A. Wassyng, B. Quigley and M. R. Borsch. "Verification of the Shutdown System Software at the Darlington Nuclear Generating Station". In International Conference on Control & Instrumentation in Nuclear Installations. May, 1990. Glasgow. [Atkinson 88] C. Atkinson, T. Moreton, and A. Natali (editors). Ada for Distributed Systems. The Ada Companion Series, Cambridge University Press, 1988. [Austin 91] S. M. Austin, D. R. Wilkins, and B. A. Wichmann. "An Ada Test Generator". In Tri-Ada 1991 Proceedings, ACM SIGAda, 1991 [Baker 89] T. Baker. "Time Issues Working Group". In Proceedings of the First International Workshop on Real-Time Ada Issues, pages 119-135. Software Engineering Institute and United States Office of Naval Research, Association for Computing Machinery, New York, NY, June, 1989. Appeared in ACM SIGAda Ada Letters, Vol. X, No..4. [Baker 91] T. Baker. "Stack-Based Scheduling of Realtime Processes". The Real-Time Systems Journal 3(1): 67-100, March, 1991. [Bal 92] H. E. Bal, M. F. Kaashoek, and A. S. Tanenbaum. "Orca: A Language for Parallel Programming of Distributed Systems". IEEE Transactions on Software Engineering, 18(3): 190-205, March 1992. [Bardin 89] B. M. Bardin and C. J. Thompson. "Composable Ada Software Components and the Re-Export Paradigm". ACM SIGAda Ada Letters VIII(1), 1989. [Barnes 76] J. G. P. Barnes. RTL/2 Design and Philosophy. Heyden, 1976 [Barnes 82] J. G. P. Barnes. Programming in Ada. Addison-Wesley, London, 1982. [Barnes 95] J. G. P. Barnes. Accessibility Rules OK! Ada Letters XV(1), 1995. [Birtwistle 73] G. M. Birtwistle, O-J. Dahl, B. Myhrhaug, and K. Nygaard. SIMULA Begin. Auerbach, Philadelphia, PA, 1973. [Blum 86] L. Blum, M. Blum and M. Shub. "A Simple Unpredictable Pseudo-Random Number Generator". SIAM Journal of Computing 15(2):364-383, 1986. [Booch 86] G. E. Booch. "Object-Oriented Development". IEEE Transactions on Software Engineering SE-12(2), February 1986 [Booch 87] G. E. Booch. Software Components with Ada. Benjamin/Cummings, Menlo Park, CA, 1987. [Brinch-Hansen 73] P. Brinch-Hansen. Concurrent Programming Concepts. Computing Surveys 5(4): 224-245, 1973. [Brosgol 89] B. Brosgol. "Is Ada Object-Oriented?" ALSYS News. Fall, 1989 [Brosgol 92] B. M. Brosgol, D. E. Emery and R. I. Eachus. "Decimal Arithmetic in Ada". In Proceedings of the Ada-Europe International Conference, Amsterdam, June 1-5, 1992. [Brosgol 93] B. M. Brosgol. Minutes of Special Meeting - Security & Safety Annex. Unnumbered Ada 9X Project Document, 1993. [Brown 81] W. S. Brown. "A simple but realistic model of floating- point computation". Transactions on Mathematical Software 7(4): 445-480, December, 1981. [Brygier 93] J. Brygier and M. Richard-Foy. "Ada Run Time System Certification for Avionics Applications". In Proceedings of the Ada-Europe International Conference. June, 1993. Paris, France. [Budd 91] T. Budd. An Introduction to Object-Oriented Programming. Addison-Wesley, 1991. [Burger 87] T. M. Burger and K. W. Nielsen. "An Assessment of the Overhead Associated With Tasking Facilities and Tasking Paradigms in Ada". ACM SIGAda Ada Letters VII(1): 49-58, 1987 [Burns 87] A. Burns, A. M. Lister, and A. Wellings. A Review of Ada Tasking. Lecture Notes in Computer Science, Springer- Verlag, Berlin, 1987. [Burns 89] A. Burns and A. Wellings. Real-Time Systems and their Programming Languages. International Computer Science Series, Addison-Wesley, Reading, MA, 1989. [Cardelli 85] L. Cardelli and P. Wegner. "On Understanding Types, Data Abstraction, and Polymorphism". ACM Computing Surveys 17(4): 471-522, December 1985. [Carre' 88] B. A. Carre' and T. J. Jennings. SPARK - The SPADE Ada Kernel. Technical Report, University of Southampton, March, 1988. [CD 93] Ada 9X Reference Manual, Version 4.0 (Committee Draft). Intermetrics Inc, 1993. [Coffman 73] Coffman and Denning. Operating Systems Theory. Prentice- Hall, Englewood Cliffs, New Jersey, 1973. [Cohen 90] S. Cohen. Ada Support for Software Reuse. Technical Report SEI-90-SR-16, Software Engineering Institute, October 1990. [Cullyer 91] W. J. Cullyer, S. J. Goodenough and B. A. Wichmann. "The Choice of Computer Languages in Safety-Critical Systems". Software Engineering Journal 6(2): 51-58, March, 1991. [Dahl 72] O-J. Dahl, E. W. Dijkstra, and C. A. R. Hoare. Structured Programming. Academic Press, London, 1972, p111. [Dewar 90a] R. B. K. Dewar. Shared Variables and Ada 9X Issues. Special Report SEI-90-SR-1, Software Engineering Institute, January 1990. [Dewar 90b] R. B. K. Dewar. The Fixed-Point Facility in Ada. Technical Report Special Report SEI-90-SR-2, Software Engineering Institute, Pittsburgh, PA, February, 1990. [Dijkstra 72] E. W. Dijkstra. "Notes on Structured Programming". In O- J. Dahl, E. W. Dijkstra, and C. A. R. Hoare. Structured Programming. Academic Press, London, 1972. [DIS 94] Ada 9X Reference Manual, Version 5.0 (Draft International Standard). Intermetrics Inc, 1994. [DO-178B] Issued in the USA by the Requirements and Technical Concepts for Aviation (document RTCA SC167/D0-178B) and in Europe by the European Organization for Civil Aviation Electronics (EUROCAE document ED-12B). [DoD 78] Defense Advanced Research Projects Agency. Department of Defense Requirements for High Order Computer Programming Languages - STEELMAN. USDoD, Arlington, Virginia, 1978. [DoD 85] Trusted Computer Systems Evaluation Criteria. DOD 5200.28- STD edition, Department of Defense, 1985. [DoD 92] Formal Studies of Ada 9X, Formal Definition Report Ada 9X Project Report edition, Department of Defense, 1992. [DoD 88] Ada Board's Recommended Ada 9X Strategy. Office of the Under Secretary of Defense for Acquisition, Washington, D.C., 1988. [DoD 89a] Ada 9X Project Plan. Office of the Under Secretary of Defense for Acquisition, Washington, D.C., 1989. [DoD 89b] Common Ada Programming Support Environment (APSE) Interface Set (CAIS) (Revision A) edition. MIL-STD-1838A. United States Department of Defense, 1989. [DoD 90] Ada 9X Requirements. Office of the Under Secretary of Defense for Acquisition, Washington, D.C., 1990. [DoD 91] Ada 9X Requirements Rationale. Office of the Under Secretary of Defense for Acquisition, Washington, D.C., 1991 [DoD 92] Formal Studies of Ada 9X, Formal Definition Report. Ada 9X Project Report edition, Department of Defense, 1992. [Dritz 91a] K. W. Dritz. "Rationale for the Proposed Standard for a Generic Package of Elementary Functions for Ada". ACM SIGAda Ada Letters XI(7): 47-65, Fall, 1991. [Dritz 91b] K. W. Dritz. "Rationale for the Proposed Standard for a Generic Package of Primitive Functions for Ada". ACM SIGAda Ada Letters XI(7): 82-90, Fall, 1991. [Eachus 92] Personal communication from Robert Eachus, 1992. [Ellis 90] M. A. Ellis and B. Stroustrup. The Annotated C++ Reference Manual. Addison-Wesley, Reading, MA, 1990. [Elrad 88] T. Elrad. "Comprehensive Scheduling Controls for Ada Tasking". In Proceedings of the Second International Workshop on Real-Time Ada Issues, pages 12-19. Ada UK and United States Air Force Office of Scientific Research, Association for Computing Machinery, New York, NY, June 1988. Appeared in ACM SIGAda Ada Letters, VIII(7). [Elsom 91] K. C. Elsom. Grow: an APSE Stress Tensor. DRA Maritime Division, Portsmouth, 1991. [Emery 91] Personal communication from David Emery, 1991. [Fowler 89] K. J. Fowler. A Study of Implementation-Dependent Pragmas and Attributes in Ada. Technical Report Ada 9X Project Report, Software Engineering Institute, November 1989. [Goldberg 83] A. Goldberg and D. Robson. Smalltalk-80: The Language and its Implementation. Addison-Wesley, Reading, MA, 1983. [Guimaraes 91] N. Guimaraes. "Building Generic User Interface Tools: An Experience with Multiple Inheritance". In Proceedings of the Conference on Object-Oriented Programming Systems, Languages, and Applications, 1991. [Guttag 77] J. Guttag. "Abstract Data Types and the Development of Data Structures". Communications of the ACM 20(6): 396- 404, June 1977. [Hilfinger 90] P. N. Hilfinger. Implementing Ada Fixed-point Types Having Arbitrary Scales. Technical Report Report No. UCB/CSD 90/#582, University of California, Berkeley, CA, June, 1990. [Hilzer 92] R. C. Hilzer. "Synchronization of the Producer/Consumer Problem using Semaphores, Monitors, and the Ada Rendezvous". ACM Operating Systems Review, 26(3), July 1992 [Hoare 73] C. A. R. Hoare. "Towards a Theory of Parallel Programming". In C.A.R. Hoare and R.H. Perrott (editor), Operating Systems Techniques. Academic Press, New York, 1973 [Hoare 74] C. A. R. Hoare. "Monitors - An Operating Systems Structuring Concept". Communications of the ACM 17(10), pp 549-557, October 1974. [Hoare 78] C. A. R. Hoare. "Communicating Sequential Processes". Communications of the ACM 21(8): 666-677, August 1978. [IBFW 86] J. D. Ichbiah, J. G. P. Barnes, R. J. Firth, and M. Woodger. Rationale for the Design of the Ada Programming Language. Reprinted by Cambridge University Press, 1991. [IEC 89] Binary Floating-Point Arithmetic for Microprocessor Systems. IEC 559:1989 edition, IEC, 1989. [IEC/SC65A 91] Software for Computers in the Application of Industrial Safety-Related Systems (Draft). IEC/SC65A/(Secretariat 122), 1991. [IEEE 87] Standard for Radix-Independent Floating-Point Arithmetic. ANSI/IEEE Std. 854-1987 edition, 1987. [IEEE 92] POSIX Ada Language Interfaces - Part 1: Binding for System Application Program Interface. Std 1003.5, IEEE, New York, 1992 [Ingalls 86] D. H. H. Ingalls. "A Simple Technique for Handling Multiple Polymorphism". In ACM OOPSLA'86 Conference Proceedings, 1986. [ISO 87] International Standards Organization. Reference Manual for the Ada Programming Language. ISO/8652-1987, 1987. [ISO 90] International Standards Organization. Memorandum of Understanding between the Ada 9X Project Office and ISO- IEC/JTC 1/SC 22/WG 9 Ada. ISO-IEC/JTC 1/SC 22 N844, 1990. [ISO 91] International Standards Organization. Generic Package of Elementary Functions for Ada. ISO/JTC 1 DIS 11430. [ISO 92] Database Language SQL. Document ISO/IEC 9075:1992 edition, International Organization for Standardization (ISO), 1992. [ISO 93] Information Technology-Language Independent Arithmetic- Part 1: Integer and Floating Point Arithmetic. DIS 10967- 1:1993 edition, ISO/IEC, 1993. [ISO 94a] International Standards Organization. Generic Package of Elementary Functions for Ada. ISO-IEC/JTC 1 11430:1994. [ISO 94b] International Standards Organization. Generic Package of Primitive Functions for Ada. ISO-IEC/JTC 1 11729:1994. [ISO 95] International Standards Organization. Reference Manual for the Ada Programming Language. ISO/8652-1995, 1995. [ISO WG9 93] AI 00866/03, The Latin-1 character set is used in source code and literals. ISO/IEC JTC1/SC22 WG9 Ada, June, 1993. [ITSEC 91] Information Technology Security Evaluation Criteria. Version 1.2 edition, Provisional Harmonised Criteria, 1991. UK contact point: CESG Room 2/0805, Fiddlers Green Lane, Cheltenham, Glos, GL52 5AJ. [Kahan 87] W. Kahan. "Branch Cuts for Complex Elementary Functions, or Much Ado About Nothing's Sign Bit". In The State of the Art in Numerical Analysis. Clarendon Press, 1987, Chapter 7 [Kahan 91] W. Kahan and J. W. Thomas. Augmenting a Programming Language with Complex Arithmetic. Technical Report UCB/CSD 91/667, Univ. of Calif. at Berkeley, December, 1991. [Klein 93] M. H. Klein, T. Ralya, B. Pollak, R. Obenza, and M. G. Harbour. A Practitioner's Handbook for Real-Time Analysis: Guide to Rate Monotonic Analysis for Real-Time Systems. Klewer Academic Publishers, 1993. [Knuth 81] D. E. Knuth. The Art of Computer Programming. Volume 2: Seminumerical Algorithms. Addison-Wesley, 1981. [LaLonde 89] W. R. LaLonde. "Designing Families of Data Types using Exemplars". ACM Transactions on Programming Languages and Systems 11(2), April 1989. [L'Ecuyer 88] P. L'Ecuyer. "Efficient and Portable Combined Random Number Generators". Communications of the ACM 31(6):742- 749, 774; 1988. [Lehoczky 86] J. P. Lehoczky and L. Sha. "Performance of Real-Time Bus Scheduling Algorithms". ACM Performance Evaluation Review, Special Issue 14(1): 44-53, May, 1986. [Lewis 69] P. A. Lewis, A. S. Goodman, and J. M. Miller. " Pseudo- Random Number Generator for the System/360" IBM System Journal 8(2):136-146, 1969. [Liskov 77] B. Liskov, A. Snyder, R. Atkinson, and C. Schaffert. "Abstraction Mechanisms in CLU". Communications of the ACM 20(8): 564-576, August 1977. [Marsaglia 91] G. Marsaglia and A. Zaman. "A New Class of Random Number Generators". Annals of Applied Probability 1(3):462-480,1991 [Meyer 88] B. Meyer. Object-Oriented Software Construction. Prentice Hall, Englewood Cliffs, NJ, 1988. [MoD 91] The Procurement of Safety Critical Software in Defence Equipment (Part 1: Requirements; Part 2: Guidance). Interim Defence Standard 00-55 edition, Ministry of Defence, 1991. [Nelson 91] G. Nelson (ed). Systems Programming with Modula-3. Prentice Hall, Englewood Cliffs, NJ, 1991. [Pavey 93] D. J. Pavey and L. A. Winsborrow. "Demonstrating Equivalence of Source Code and PROM Contents". Computer Journal 36(7): 654-667, 1993. [Plauger 92] P. J. Plauger. The Standard C Library. Prentice Hall, Englewood Cliffs NJ, 1992. [Rex 88] MALPAS User Guide Release 4.1, RTP/4009/UG, Issue 3 edition, Rex, Thompson and Partners Ltd., 1988. [RM83] See [ANSI 83]. [RM95] See [ISO 95]. [Sales 92] R. Sales. Currency Sign Enhancements. Technical Report X3J4/WR-684, ANSI X3J4, 1992. COBOL Full Revision Working Paper. [Schaeffer 93] C. F. Schaeffer and G. N. Bundy. "Static Analysis of Exception Handling in Ada". Software Practice & Experience 23(10):1157-1174, 1993. [Schaffert 86] C. Schaffert, T. Cooper, B. Bullis, M. Kilian, and C. Wilpolt. An "Introduction to Trellis/Owl". In ACM OOPSLA'86 Proceedings. Portland, OR, 1986. [Seidewitz 91] E. Seidewitz. "Object-Oriented Programming Through Type Extension in Ada 9X". ACM SIGAda Ada Letters XI(2), March/April 1991. [Sha 90a] L. Sha, and J. B. Goodenough. "Real-Time Scheduling Theory and Ada". IEEE Computer 23(4): 53-62, April, 1990. [Sha 90b] L. Sha, R. Rajkumar, and J. P. Lehoczky. "Priority Inheritance Protocols - An Approach to Real-Time Synchronization". IEEE Transactions on Computers C-39(9), September, 1990. [Stroustrup 91] B. Stroustrup. The C++ Programming Language, 2nd Ed. Addison-Wesley, Reading, MA, 1991. [Taft 93] S. Tucker Taft. "Ada 9X: From Abstraction-Oriented to Object-Oriented". In ACM OOPSLA'93 Conference Proceedings,1993 [Tang 91] P. T. P. Tang. "A Portable Generic Elementary Function Package in Ada and an Accurate Test Suite". ACM SIGAda Ada Letters XI(7): 180-216, Fall, 1991. [Taylor 95] W. J. Taylor. Ada 95 Compatibility Guide, Version 6.0. Transition Technology, January 1995. [Wellings 84] A. J. Wellings, D. Keeffe, and G. M. Tomlinson. "A Problem with Ada and Resource Allocation". ACM SIGAda Ada Letters III(4): 112-123, 1984. [Wichmann 82] B. A. Wichmann and I. D. Hill. "An Efficient and Portable Pseudo-Random Number Generator". Applied Statistics 31:188-190, 1982. [Wichmann 89] B. A. Wichmann. Insecurities in the Ada programming language. Technical Report DITC 137/89, NPL, January, 1989 [Wichmann 92] B. A. Wichmann. Undefined scalars in Ada 9X. March, 1992. [Wichmann 93] B. A. Wichmann. "Microprocessor design faults". Microprocessors and Microsystems 17(7):399-401, 1993. [Wirth 77] N. Wirth. "Modula: A Language for Modular Multiprogramming". Software Practice & Experience, January 1977, pp 3-35. [Wirth 88] N. Wirth. "Type Extensions". ACM Transactions on Programming Languages and Systems 10(2): 204-214, April 1988.</pre> <div class="navigator">[[Guide:9x_rationale/rat95-copyright|Copyright]] | [[Guide:9x_rationale/rat95-contents|Contents]] | [[Guide:9x_rationale/rat95-index|Index]] | [[Guide:9x_rationale/rat95-p4-z|Previous]] | [[Guide:9x_rationale/rat95-index|Next]]</div> [[Guide:9x_rationale/rat95-author|Laurent Guerby]] {{9x_rationale|Displaytitle=References}} mqoqkb0x2dr0uwn2kohegzvh5oxz5lr Template:9x rationale 10 359 3415 1890 2019-04-24T16:56:38Z WikiVisor 11 wikitext text/x-wiki {{#if: {{{Displaytitle|}}}|{{DISPLAYTITLE: {{{Displaytitle|}}} <span class="hide">- Ada 95 Rationale</span> }} }} [[Category:9x rationale]] <span class="guide" style="display: inline;">Ada 95 Rationale</span> jaobahxc0n06k0sgqe20karwxow54dz