CVS difference for arm/source/11.mss

Differences between 1.16 and version 1.17
Log of other versions for file arm/source/11.mss

--- arm/source/11.mss	2000/08/03 05:37:40	1.16
+++ arm/source/11.mss	2000/08/11 00:09:15	1.17
@@ -1,10 +1,10 @@
 @Part(11, Root="ada.mss")
 
-@Comment{$Date: 2000/08/03 05:37:40 $}
+@Comment{$Date: 2000/08/11 00:09:15 $}
 @LabeledSection{Exceptions}
 
 @Comment{$Source: e:\\cvsroot/ARM/Source/11.mss,v $}
-@Comment{$Revision: 1.16 $}
+@Comment{$Revision: 1.17 $}
 
 @begin{Intro}
 @redundant[This section defines the facilities for dealing with errors or other
@@ -18,7 +18,7 @@
   Text=<An @i(exception) represents a kind of exceptional situation;
   an occurrence of such a situation (at run time)
   is called an @i(exception occurrence).
-  @redundant[  @PDefn2{Term=[raise], Sec=(an exception)}
+  @redundant[@PDefn2{Term=[raise], Sec=(an exception)}
   To @i{raise} an exception is to abandon normal program execution so
   as to draw attention to the fact that the corresponding situation has
   arisen.
@@ -33,7 +33,7 @@
 @begin{Ramification}
 For example, an exception End_Error might
 represent error situations in which an attempt is made to read beyond
-end-of-file.  During the execution of a partition, there might be
+end-of-file. During the execution of a partition, there might be
 numerous occurrences of this exception.
 @end{Ramification}
 @begin{Honest}
@@ -80,7 +80,7 @@
 
 @begin{StaticSem}
 Each single @nt{exception_declaration} declares a name for a different
-exception.  If a generic unit includes an @nt{exception_declaration},
+exception. If a generic unit includes an @nt{exception_declaration},
 the @nt{exception_declaration}s implicitly generated by
 different instantiations of the generic unit refer to distinct
 exceptions (but all have the same @nt{defining_identifier}).
@@ -147,7 +147,7 @@
 @end{RunTime}
 
 @begin{Examples}
-@i{Examples of user-defined exception declarations:}
+@leading@keepnext@i{Examples of user-defined exception declarations:}
 @begin{Example}
 Singular : @key[exception];
 Error    : @key[exception];
@@ -159,15 +159,15 @@
 The exception Numeric_Error is now defined in the Obsolescent
 features Annex, as a rename of Constraint_Error.
 All checks that raise Numeric_Error in Ada 83
-instead raise Constraint_Error in Ada 9X.
+instead raise Constraint_Error in Ada 95.
 To increase upward compatibility,
 we also changed the rules to allow the same exception to be named
 more than once by a given handler.
 Thus,
 @lquotes@;@key[when] Constraint_Error | Numeric_Error =>@rquotes@; will remain
-legal in Ada 9X,
+legal in Ada 95,
 even though Constraint_Error and Numeric_Error now denote the same
-exception.  However, it will not be legal to have
+exception. However, it will not be legal to have
 separate handlers for Constraint_Error and Numeric_Error.
 This change is inconsistent in the rare case that an
 existing program explicitly raises Numeric_Error at a point where
@@ -223,7 +223,7 @@
 exception.
 @begin{Ramification}
   Two @nt<choice>s of the same @nt<exception_handler> may cover
-  the same exception.  For example, given two renaming declarations in
+  the same exception. For example, given two renaming declarations in
   separate packages for the same exception, one may nevertheless
   write, for example,
   @lquotes@;@key[when] Ada.Text_IO.Data_Error | My_Seq_IO.Data_Error =>@rquotes@;.
@@ -267,7 +267,7 @@
 @end{RunTime}
 
 @begin{Examples}
-@i{Example of an exception handler:}
+@leading@keepnext@i{Example of an exception handler:}
 @begin{Example}
 @key[begin]
    Open(File, In_File, "input.txt");   @RI[-- see @RefSecNum{File Management}]
@@ -285,7 +285,7 @@
 allow a @nt{choice_parameter_specification}.
 
 Different @nt<choice>s of the same @nt<exception_handler> may
-cover the same exception.  This allows for
+cover the same exception. This allows for
 @lquotes@;when Numeric_Error | Constraint_Error =>@rquotes@; even though
 Numeric_Error is a rename of Constraint_Error.
 This also allows one to @lquotes@;with@rquotes@; two different I/O packages,
@@ -301,7 +301,7 @@
 This obviates the need to explain
 (in Sections 5, 6, 7, and 9)
 what portions of the program are handled by the handlers.
-Note that there are more such cases in Ada 9X.
+Note that there are more such cases in Ada 95.
 
 The syntax rule for @nt{choice_parameter_specification} is new.
 @end{DiffWord83}
@@ -347,7 +347,7 @@
 @end{RunTime}
 
 @begin{Examples}
-@i{Examples of raise statements:}
+@leading@keepnext@i{Examples of raise statements:}
 @begin{Example}
 @key[raise] Ada.IO_Exceptions.Name_Error;   @RI[-- see @RefSecNum{Exceptions In Input-Output}]
 
@@ -421,7 +421,7 @@
 @lquotes@;evaluation@rquotes@;, as well as other executions.)
 The evaluation of a function call dynamically encloses the execution
 of the @nt{sequence_of_statement}s of the @nt{function_body}
-(during that execution).  Note that, due to recursion, several
+(during that execution). Note that, due to recursion, several
 simultaneous executions of the same construct can be occurring at once
 during the execution of a particular task.
 
@@ -435,7 +435,7 @@
 enclosed by the execution of the @nt{if_statement} (or anything else).
 @end{Ramification}
 
-@Defn2{Term=[raise], Sec=(an exception occurrence)}
+@Leading@Defn2{Term=[raise], Sec=(an exception occurrence)}
 When an exception occurrence is raised by the execution of a given
 construct, the rest of the execution of that construct is @i{abandoned};
 that is, any portions of the execution that have not yet taken place
@@ -522,7 +522,7 @@
 @LabeledSubClause{The Package Exceptions}
 
 @begin{StaticSem}
-The following language-defined library package exists:
+@leading@keepnext@;The following language-defined library package exists:
 @begin{Example}
 @ChildUnit{Parent=[Ada],Child=[Exceptions]}
 @key[package] Ada.Exceptions @key[is]
@@ -564,7 +564,7 @@
 Null_Occurrence does not represent any exception occurrence,
 and is the default initial value of type Exception_Occurrence.
 
-For @PrefixType{a prefix E that denotes an exception},
+@Leading@Keepnext@;For @PrefixType{a prefix E that denotes an exception},
 the following attribute is defined:
 @begin{Description}
 @Attribute{Prefix=<E>, AttrName=<Identity>,
@@ -589,24 +589,30 @@
 Reraise_Occurrence reraises the specified exception occurrence.
 @ImplDef{The information returned by Exception_Message.}
 @begin{Ramification}
-Given an exception E, the @nt{raise_statement}:
+@Leading@Keepnext@;Given an exception E, the @nt{raise_statement}:
 @begin{Example}
 @key[raise] E;
 @end{Example}
 
-is equivalent to this call to Raise_Exception:
+@begin{Wide}
+@Leading@keepnext@;is equivalent to this call to Raise_Exception:
+@end{Wide}
 @begin{Example}
 Raise_Exception(E'Identity, Message => @RI{implementation-defined-string});
 @end{Example}
 
-The following handler:
+@begin{Wide}
+@Leading@keepnext@;The following handler:
+@end{Wide}
 @begin{Example}
 @key[when] @key[others] =>
     Cleanup;
     @key[raise];
 @end{Example}
 
-is equivalent to this one:
+@begin{Wide}
+@Leading@keepnext@;is equivalent to this one:
+@end{Wide}
 @begin{Example}
 @key[when] X : @key[others] =>
     Cleanup;
@@ -758,8 +764,8 @@
 
 Note that exceptions behave as if declared at library level;
 there is no @lquotes@;natural scope@rquotes@; for an exception; an exception always
-exists.  Hence, there is no harm in saving an exception occurrence in
-a data structure, and reraising it later.  The reraise has to occur
+exists. Hence, there is no harm in saving an exception occurrence in
+a data structure, and reraising it later. The reraise has to occur
 as part of the same program execution, so saving an exception
 occurrence in a file, reading it back in from a different
 program execution, and then reraising it is not required to work.
@@ -767,9 +773,9 @@
 Note that it is possible to use RPC to propagate exceptions across
 partitions.
 
-Here's one way to implement Exception_Occurrence in the private part
-of the package.  Using this method, an implementation need store only
-the actual number of characters in exception messages.  If the user
+@Leading@;Here's one way to implement Exception_Occurrence in the private part
+of the package. Using this method, an implementation need store only
+the actual number of characters in exception messages. If the user
 always uses small messages, then exception occurrences can be small.
 If the user never uses messages, then exception occurrences can be
 smaller still:
@@ -781,29 +787,29 @@
     @key[end] @key[record];
 @end{Example}
 
-At the point where an exception is raised, an Exception_Occurrence
+@Leading@;At the point where an exception is raised, an Exception_Occurrence
 can be allocated on the stack with exactly the right amount of space
-for the message @em none for an empty message.  This is just like
+for the message @em none for an empty message. This is just like
 declaring a constrained object of the type:
 @begin{Example}
 Temp : Exception_Occurrence(10); --@RI{ for a 10-character message}
 @end{Example}
 
 After finding the appropriate handler, the stack can be cut back,
-and the Temp copied to the right place.  This is similar to returning
-an unknown-sized object from a function.  It is not necessary to
+and the Temp copied to the right place. This is similar to returning
+an unknown-sized object from a function. It is not necessary to
 allocate the maximum possible size for every Exception_Occurrence.
 If, however, the user declares an Exception_Occurrence object,
-the discriminant will be permanently set to 200.  The Save_Occurrence
-procedure would then truncate the Exception_Message.  Thus, nothing is
-lost until the user tries to save the occurrence.  If the user is
+the discriminant will be permanently set to 200. The Save_Occurrence
+procedure would then truncate the Exception_Message. Thus, nothing is
+lost until the user tries to save the occurrence. If the user is
 willing to pay the cost of heap allocation, the Save_Occurrence
 function can be used instead.
 
 Note that any arbitrary-sized implementation-defined Exception_Information can
-be handled in a similar way.  For example, if the
+be handled in a similar way. For example, if the
 Exception_Occurrence includes a stack traceback, a discriminant can
-control the number of stack frames stored.  The traceback would be
+control the number of stack frames stored. The traceback would be
 truncated or entirely deleted by the Save_Occurrence procedure @em as
 the implementation sees fit.
 
@@ -821,13 +827,13 @@
 Using the above method, heap space is never allocated unless the user
 calls the Save_Occurrence function.
 
-An alternative implementation would be to store the message strings
-on the heap when the exception is raised.  (It could be the global
+@Leading@;An alternative implementation would be to store the message strings
+on the heap when the exception is raised. (It could be the global
 heap, or it could be a special heap just for this purpose @em it
 doesn't matter.)  This representation would be used only for choice
-parameters.  For normal user-defined exception occurrences, the
+parameters. For normal user-defined exception occurrences, the
 Save_Occurrence procedure would copy the message string into the
-occurrence itself, truncating as necessary.  Thus, in this
+occurrence itself, truncating as necessary. Thus, in this
 implementation, Exception_Occurrence would be implemented as a
 variant record:
 @begin{Example}
@@ -845,7 +851,7 @@
 @end{Example}
 
 Exception_Occurrences created by the run-time system during exception
-raising would be As_Choice_Param.  User-declared ones would be Normal @em the
+raising would be As_Choice_Param. User-declared ones would be Normal @em the
 user cannot see the discriminant, and so cannot set it to As_Choice_Param.
 The strings in the heap would be freed upon completion of the
 handler.
@@ -853,7 +859,7 @@
 This alternative implementation corresponds to a heap-based
 implementation of functions returning unknown-sized results.
 
-One possible implementation of Reraise_Occurrence is as follows:
+@Leading@;One possible implementation of Reraise_Occurrence is as follows:
 @begin{Example}
 @key[procedure] Reraise_Occurrence(X : @key[in] Exception_Occurrence) @key[is]
 @key[begin]
@@ -886,9 +892,8 @@
 @LabeledSubClause{Example of Exception Handling}
 
 @begin{Examples}
-Exception handling may be used to separate the detection of an error
+@Leading@;Exception handling may be used to separate the detection of an error
 from the response to that error:
-
 @begin{Example}
 @key[with] Ada.Exceptions;
 @key[use] Ada;
@@ -997,7 +1002,7 @@
 
 @begin{Syntax}
 @begin{SyntaxText}
-The form of a @nt{pragma} Suppress is as follows:
+@Leading@Keepnext@;The form of a @nt{pragma} Suppress is as follows:
 @end{SyntaxText}
 
 @PragmaSyn`@key{pragma} @prag(Suppress)(@Syn2{identifier} [, [On =>] @Syn2{name}]);'
@@ -1045,7 +1050,7 @@
 for example, if the erroneousness is detected.
 @end{Ramification}
 
-The following are the language-defined checks:
+@Leading@Keepnext@;The following are the language-defined checks:
 @begin{Itemize}
 @Defn2{Term=[Constraint_Error],Sec=(raised by failure of run-time check)}
 @Redundant[The following checks correspond to situations in which the
@@ -1061,7 +1066,7 @@
 @RootDefn{Discriminant_Check}
 Discriminant_Check @\@Redundant[Check that the discriminants of a
 composite value
-have the values imposed by a discriminant constraint.  Also, when
+have the values imposed by a discriminant constraint. Also, when
 accessing a record component, check that it exists for the current
 discriminant values.]
 
@@ -1073,10 +1078,10 @@
 @RootDefn{Index_Check}
 Index_Check @\@Redundant[Check that the bounds of an array value are
 equal to the
-corresponding bounds of an index constraint.  Also, when accessing a
+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
+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.]
 
@@ -1099,7 +1104,7 @@
 the @nt<constraint> (if present) is compatible with the
 subtype denoted by the @nt{subtype_mark}.
 Also, for an @nt<aggregate>, check that an index or
-discriminant value belongs to the corresponding subtype.  Also, check
+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.]
 
@@ -1136,7 +1141,7 @@
 @Defn2{Term=[Storage_Error],Sec=(raised by failure of run-time check)}
 Storage_Check @\@Redundant[Check that evaluation of an @nt{allocator}
 does not require
-more space than is available for a storage pool.  Check
+more space than is available for a storage pool. Check
 that the space available for a task or subprogram has
 not been exceeded.]
 @begin{Reason}
@@ -1223,7 +1228,7 @@
 @end{Notes}
 
 @begin{Examples}
-@i{Examples of suppressing checks:}
+@Leading@Keepnext@i{Examples of suppressing checks:}
 @begin{Example}
 @key[pragma] Suppress(Range_Check);
 @key[pragma] Suppress(Index_Check, On => Table);
@@ -1302,7 +1307,7 @@
 the canonical semantics.
 @end{Ramification}
 @begin{Discussion}
-The following parts of the canonical semantics are of particular
+@Leading@;The following parts of the canonical semantics are of particular
 interest to the reader of this clause:
 @begin{Itemize}
 Behavior in the presence of abnormal objects
@@ -1340,7 +1345,7 @@
 @end{RunTime}
 
 @begin{ImplPerm}
-The following additional permissions are granted to the
+@Leading@;The following additional permissions are granted to the
 implementation:
 @begin{Itemize}
 @Defn{extra permission to avoid raising exceptions}
@@ -1348,7 +1353,7 @@
 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 @i{undefined result}.  The exception need be raised
+an @i{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.
@@ -1366,7 +1371,7 @@
   We express the permission in terms of removing
   the raise, rather than the operation or the check,
   as it minimizes the disturbance to the canonical
-  semantics (thereby simplifying reasoning).  By allowing
+  semantics (thereby simplifying reasoning). By allowing
   the implementation to omit the raise, it thereby does
   not need to "look" at what happens in the exception handler
   to decide whether the optimization is allowed.
@@ -1378,7 +1383,7 @@
 This follows from the canonical semantics.
 @end{Discussion}
 @begin{ImplNote}
-  This permission is intended to allow normal "dead code removal"
+  @Leading@;This permission is intended to allow normal "dead code removal"
   optimizations, even if some of the removed code might have failed
   some language-defined check.
   However, one may not eliminate the raise of an exception
@@ -1397,7 +1402,7 @@
   that it is comparing it with an in-range Integer value, and hence
   always yields False.
 
-  As another example where a raise may not be eliminated:
+  @Leading@;As another example where a raise may not be eliminated:
 @begin{Example}
   @key[subtype] Str10 @key[is] String(1..10);
   @key[type] P10 @key[is] @key[access] Str10;
@@ -1453,7 +1458,7 @@
 @end{Reason}
 @begin{Ramification}
   If a check fails, no result dependent on the check may be
-  incorporated in an external interaction.  In other words,
+  incorporated in an external interaction. In other words,
   there is no permission to output meaningless results due
   to postponing a check.
 @end{Ramification}
@@ -1524,9 +1529,8 @@
 @end{Notes}
 
 @begin{DiffWord83}
-RM83-11.6 was unclear.
-It has been completely rewritten here;
-we hope this version is clearer.
+@Leading@;RM83-11.6 was unclear.
+It has been completely rewritten here; we hope this version is clearer.
 Here's what happened to each paragraph of RM83-11.6:
 @begin{Itemize}
 Paragraphs 1 and 2 contain no semantics;

Questions? Ask the ACAA Technical Agent