# CVS difference for arm/source/01.mss

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

```--- arm/source/01.mss	2000/06/03 02:02:33	1.17
+++ arm/source/01.mss	2000/08/03 05:37:35	1.18
@@ -32,10 +32,10 @@
@end{WithoutParanum}

@LabeledSectionNoBreak{General}
-@Comment{\$Date: 2000/06/03 02:02:33 \$}
+@Comment{\$Date: 2000/08/03 05:37:35 \$}

@Comment{\$Source: e:\\cvsroot/ARM/Source/01.mss,v \$}
-@Comment{\$Revision: 1.17 \$}
+@Comment{\$Revision: 1.18 \$}

@begin{Intro}
Ada is a programming language designed to support the construction of
@@ -45,7 +45,7 @@
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
+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.
@@ -57,7 +57,7 @@
Errors can be signaled as exceptions and handled explicitly.
The language also
covers  systems  programming;   this  requires  precise  control  over  the
a predefined environment of standard packages is provided, including
facilities for, among others, input-output, string manipulation,
numeric elementary functions, and random number generation.
@@ -74,13 +74,15 @@

The AARM stresses detailed correctness and uniformity over
-We're not trying to make the language ``appear'' simple here;
+We're not trying to make the language @lquotes@;appear@rquotes@; simple here;
on the contrary, we're trying to expose hidden complexities,
so we can more easily detect language bugs.
The RM95, on the other hand, is intended to be a more

The annotations in the AARM are as follows:
@begin{Itemize}
Text that is logically redundant is shown
@Redundant[in square brackets, like this].
@@ -199,10 +201,10 @@
and also in @i{italics, like this}.
Syntactic categories defined in BNF are also indexed.

-A definition marked ``[distributed]'' is the main definition for a
+A definition marked @lquotes@;[distributed]@rquotes@; is the main definition for a
term whose complete definition is given in pieces distributed
throughout the document.
-The pieces are marked ``[partial]''
+The pieces are marked @lquotes@;[partial]@rquotes@;
or with a phrase explaining what cases the partial definition applies
to.
@end{Discussion}
@@ -221,7 +223,9 @@
@LabeledSubClause{Extent}

@begin{Intro}
This International Standard specifies:
@begin(Itemize)
The form of a program written in Ada;

@@ -244,7 +248,9 @@
is not required to detect.
@end(Itemize)

This International Standard does not specify:
@begin(Itemize)
The means whereby a program written in Ada is transformed into
object code executable by a processor;
@@ -272,8 +278,10 @@
fourteen annexes,
and an index.

@Defn{core language}
The @i{core} of the Ada language consists of:
@begin{Itemize}
Sections 1 through 13

@@ -284,12 +292,14 @@
@RefSec{Obsolescent Features}
@end{Itemize}

@Defn{Specialized Needs Annexes}
@Defn2{Term=[Annex],Sec=(Specialized Needs)}
@Defn{application areas}
The following @i{Specialized Needs Annexes}
define features that are needed by certain
application areas:
@begin{Itemize}
@RefSec{Systems Programming}

@@ -304,26 +314,30 @@
@RefSec{Safety and Security}
@end{Itemize}

@Defn{normative}
@Defn2{Term=[Annex],Sec=(normative)}
The core language and the Specialized Needs Annexes are normative,
except that the material in each of the items listed below
is informative:
@begin(Itemize)
Text under a NOTES or Examples heading.

-    Each clause or subclause whose title starts with the word ``Example''
-    or ``Examples''.
+    Each clause or subclause whose title starts with the word @lquotes@;Example@rquotes@;
+    or @lquotes@;Examples@rquotes@;.
@end(Itemize)

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

@Defn{informative}
@IndexSee{Term=[non-normative],See=(informative)}
@Defn2{Term=[Annex],Sec=(informative)}
The following Annexes are informative:
@begin{Itemize}
@RefSec{Language-Defined Attributes}

@@ -362,11 +376,11 @@
implementations @i{not} be allowed to validate a portion of one of the
Specialized Needs Annexes,
although implementations can, of course, provide unvalidated support for such
-portions.  We have designed the Specialized Needs Annexes assuming that
-this recommendation is followed.  Thus, our decisions about what to
+portions. We have designed the Specialized Needs Annexes assuming that
+this recommendation is followed. Thus, our decisions about what to
include and what not to include in those annexes are
based on the assumption that each annex is validated in an
-``all-or-nothing'' manner.
+@lquotes@;all-or-nothing@rquotes@; manner.

An implementation may, of course,
support extensions that are different from
@@ -431,7 +445,7 @@
@begin{Discussion}
These rules are observed at compile time.
-(We say ``observed'' rather than ``checked,''
+(We say @lquotes@;observed@rquotes@; rather than @lquotes@;checked,@rquotes@;
because these rules are not individually checked.
They are really just part of the @LegalityName@;s in Section 8
that require exactly one interpretation of each constituent
@@ -445,9 +459,9 @@
and it is sometimes difficult to decide which it should be.
We generally make a given rule a @ResolutionName only if it has to be.
For example,
-``The @nt{name}, if any, in a @nt{raise_statement} shall be the @nt{name}
-of an exception.''
-is under ``@LegalityTitle.''
+@lquotes@;The @nt{name}, if any, in a @nt{raise_statement} shall be the @nt{name}
+of an exception.@rquotes@;
+is under @lquotes@;@LegalityTitle.@rquotes@;
@end{Discussion}
@end{Resolution}

@@ -463,7 +477,7 @@
These rules are not used in overload resolution.

Note that run-time errors are always attached to exceptions;
-for example, it is not ``illegal'' to divide by zero,
+for example, it is not @lquotes@;illegal@rquotes@; to divide by zero,
it just raises an exception.
@end{Discussion}
@end{Legality}
@@ -475,10 +489,10 @@
@begin{Discussion}
The most important compile-time effects represent the effects
on the symbol table associated with declarations (implicit or
-explicit).  In addition, we use this heading as a bit of a grab
+explicit). In addition, we use this heading as a bit of a grab
bag for equivalences, package specifications, etc.
For example, this is where we put statements like so-and-so is
-equivalent to such-and-such.  (We ought to try to really mean it when we say
+equivalent to such-and-such. (We ought to try to really mean it when we say
such things!)
Similarly, statements about magically-generated implicit declarations
go here.
@@ -500,10 +514,10 @@
@begin{Discussion}
It is not specified exactly when these rules are checked, so
long as they are checked for any given partition before that partition starts
-running.  An implementation may choose to check some such rules at compile
+running. An implementation may choose to check some such rules at compile
time, and reject @nt{compilation_unit}s accordingly.
Alternatively, an implementation may check such rules when the partition is
-created (usually known as ``link time''),
+created (usually known as @lquotes@;link time@rquotes@;),
or when the partition is mapped to a particular piece of hardware (but before
the partition starts running).
@end{Discussion}
@@ -534,7 +548,7 @@
Situations that result in bounded (run-time) errors
(see @RefSecNum{Classification of Errors}).
@begin{Discussion}
-The ``bounds'' of each such error are described here @em
+The @lquotes@;bounds@rquotes@; of each such error are described here @em
that is, we characterize the set of all possible behaviors that can
result from a bounded error occurring at run time.
@end{Discussion}
@@ -553,13 +567,13 @@
@begin{Discussion}
...as opposed to rules imposed on the programmer.
An example might be,
-``The smallest representable duration, Duration'Small,
-shall not be greater than twenty milliseconds.''
+@lquotes@;The smallest representable duration, Duration'Small,
+shall not be greater than twenty milliseconds.@rquotes@;

It's really just an issue of how the rule is worded.
-We could write the same rule as ``The smallest representable duration is
-an implementation-defined value less than or equal to 20 milliseconds''
-and then it would be under ``@StaticSemTitle.''
+We could write the same rule as @lquotes@;The smallest representable duration is
+an implementation-defined value less than or equal to 20 milliseconds@rquotes@;
+and then it would be under @lquotes@;@StaticSemTitle.@rquotes@;
@end{Discussion}
@end{ImplReq}

@@ -568,9 +582,9 @@
Documentation requirements for conforming implementations.
@begin{Discussion}
These requirements are beyond those that are implicitly specified by
-the phrase ``implementation defined''.  The
+the phrase @lquotes@;implementation defined@rquotes@;. The
latter require documentation as well, but we don't repeat these cases
description of the documentation requirement is longer and does not
correspond directly to one, narrow normative sentence.
@end{Discussion}
@@ -586,14 +600,14 @@
@Defn{implementation permissions}
Additional permissions given to the implementer.
@begin{Discussion}
-For example, ``The implementation is allowed to impose further
-restrictions on the record aggregates allowed in code statements.''
+For example, @lquotes@;The implementation is allowed to impose further
+restrictions on the record aggregates allowed in code statements.@rquotes@;
When there are restrictions on the permission,
those restrictions are given here also.
-For example, ``An implementation is allowed to restrict the kinds of
+For example, @lquotes@;An implementation is allowed to restrict the kinds of
subprograms that are allowed to be main subprograms.
-However, it shall support at least parameterless procedures.''
-@em we don't split this up between here and ``@ImplReqTitle.''
+However, it shall support at least parameterless procedures.@rquotes@;
+@em we don't split this up between here and @lquotes@;@ImplReqTitle.@rquotes@;
@end{Discussion}
@end{ImplPerm}

@@ -601,7 +615,7 @@
Optional advice given to the implementer.
-The word ``should'' is used to indicate that the advice is
+The word @lquotes@;should@rquotes@; 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.
@@ -618,9 +632,9 @@
It would be wrong for the ACVC to enforce any of this advice.

For example,
-``Whenever possible, the implementation should choose a value no
+@lquotes@;Whenever possible, the implementation should choose a value no
greater than fifty microseconds for the smallest representable duration,
-Duration'Small.''
+Duration'Small.@rquotes@;

We use this heading, for example, when the rule is so low level or
implementation-oriented as to be untestable.
@@ -644,7 +658,7 @@
@ @* @Comment{Two blank lines: why? Because it was in the original.}
@*
-and Ada 95.  Language changes are any change that changes the set of
+and Ada 95. Language changes are any change that changes the set of
text strings that are legal Ada programs, or changes the meaning of
any legal program.
Wording changes, such as changes in terminology, are not language
@@ -657,8 +671,7 @@
@begin{Inconsistent83}
-9X.
-Upward inconsistencies are situations in which a legal Ada 83 program
+95. Upward inconsistencies are situations in which a legal Ada 83 program
is a legal Ada 95 program with different semantics.
This type of upward incompatibility is the worst type for users,
so we only tolerate it in rare situations.
@@ -666,7 +679,7 @@
(Note that the semantics of a program is not the same thing as the
behavior of the program.
-the ``semantics'' of a given feature describes a @i{set} of behaviors
+the @lquotes@;semantics@rquotes@; of a given feature describes a @i{set} of behaviors
that can be exhibited by that feature.
The set can contain more than one allowed behavior.
Thus, when we ask whether the semantics changes,
@@ -679,8 +692,8 @@
@begin{Incompatible83}
-and Ada 95, except for the ones listed under ``@Inconsistent83Title''
-above.  These are the situations in which a legal Ada 83 program is
+and Ada 95, except for the ones listed under @lquotes@;@Inconsistent83Title@rquotes@;
+above. These are the situations in which a legal Ada 83 program is
We do not generally consider a change that turns erroneous execution
into an exception, or into an illegality, to be upwardly incompatible.
@@ -711,7 +724,7 @@
This heading lists some of the non-semantic changes between RM83 and
the RM95.
It is incomplete; we have not attempted to list all wording
-changes, but only the ``interesting'' ones.
+changes, but only the @lquotes@;interesting@rquotes@; ones.

This is not part of the definition of the language,
and does not appear in the RM95.
@@ -721,21 +734,23 @@

@begin{ImplReq}

@Defn2{Term=[conformance],Sec=(of an implementation with the Standard)}
A conforming implementation shall:
@begin{Discussion}
@Defn{implementation}
The @i{implementation} is the software and hardware that implements
the language.
This includes compiler, linker, operating system, hardware, etc.

-We first define what it means to ``conform'' in general @em
+We first define what it means to @lquotes@;conform@rquotes@; in general @em
basically, the implementation has to properly implement the normative
rules given throughout the standard.
Then we define what it means to conform to a Specialized Needs
Annex @em the implementation must support the core features plus the
features of that Annex.
-Finally, we define what it means to ``conform to the Standard'' @em
+Finally, we define what it means to @lquotes@;conform to the Standard@rquotes@; @em
this requires support for the core language,
and allows partial (but not conflicting) support for
the Specialized Needs Annexes.
@@ -756,10 +771,10 @@
errors whose detection is required by this
International Standard;
@begin{Discussion}
-       Note that we no longer use the term ``rejection'' of programs
+       Note that we no longer use the term @lquotes@;rejection@rquotes@; of programs
or program units.
We require that programs or program units with errors or that
-       exceed some capacity limit be ``identified.''  The way in which
+       exceed some capacity limit be @lquotes@;identified.@rquotes@;  The way in which
errors or capacity problems are reported is not specified.

An implementation is allowed to use standard error-recovery
@@ -796,7 +811,7 @@
@Defn2{Term=[italics],Sec=(implementation-defined)}
Wherever in the standard the text of a language-defined library
unit contains an italicized phrase starting with
-       ``@i{implementation-defined}'', the implementation's version
+       @lquotes@;@i{implementation-defined}@rquotes@;, the implementation's version
will replace that phrase with some implementation-defined text
that is syntactically legal at that place, and follows any other
applicable rules.
@@ -815,7 +830,7 @@
@ImplDef{Variations from the standard that are impractical to avoid
given the implementation's execution environment.}
@begin{Reason}
-     The ``impossible or impractical'' wording comes from AI-325.
+     The @lquotes@;impossible or impractical@rquotes@; wording comes from AI-325.
It takes some judgement and common sense to interpret this.
Restricting compilation units to less than 4 lines is probably
unreasonable, whereas restricting them to less than 4 billion lines
@@ -828,6 +843,7 @@
by this International Standard.
@end(Itemize)

@Defn2{Term=[external effect], Sec=(of the execution of an Ada program)}
@Defn2{Term=[effect], Sec=(external)}
The @i(external effect) of the execution of an Ada program is
@@ -835,6 +851,7 @@
with its external environment.
@Defn{external interaction}
The following are defined as @i(external interactions):
@begin(Itemize)
Any interaction with an external file
(see @RefSecNum(External Files and File Objects));
@@ -856,7 +873,7 @@
or an exported subprogram
(see @RefSecNum(Interface to Other Languages)) to an external caller;
@begin{Discussion}
-    By ``result returned'' we mean to include function results
+    By @lquotes@;result returned@rquotes@; we mean to include function results
and values returned in [@key(in)] @key(out) parameters.
@end{Discussion}

@@ -880,7 +897,7 @@
order and timing are consistent with the definitions and requirements of this
International Standard for the semantics of the given program.
@begin{Ramification}
-  There is no need to produce any of the ``internal effects''
+  There is no need to produce any of the @lquotes@;internal effects@rquotes@;
defined for the semantics of the program @em all of these
can be optimized away @em so long as an appropriate sequence
of external interactions is produced.
@@ -890,38 +907,38 @@
various liberties associated with optimizations in
the presence of language-defined checks,
that could change the external effects that
-  might be produced.  These alternative external effects
+  might be produced. These alternative external effects
are still consistent with the standard, since
@RefSecNum(Exceptions and Optimization) is part of the standard.

-  Note also that we only require ``@i(an appropriate) sequence
-  of external interactions'' rather than ``@i(the same) sequence...''
+  Note also that we only require @lquotes@;@i(an appropriate) sequence
+  of external interactions@rquotes@; rather than @lquotes@;@i(the same) sequence...@rquotes@;
An optimizer may cause a different sequence of external interactions
to be produced than would be produced without the optimizer, so
long as the new sequence still satisfies the requirements
-  of the standard.  For example, optimization might affect
+  of the standard. For example, optimization might affect
the relative rate of progress of two concurrent tasks, thereby
altering the order in which two external interactions occur.

-  Note that RM83 explicitly mentions the case of an ``exact effect''
+  Note that RM83 explicitly mentions the case of an @lquotes@;exact effect@rquotes@;
of a program, but since so few programs have their effects defined
that exactly,
-  we don't even mention this ``special'' case.  In particular,
+  we don't even mention this @lquotes@;special@rquotes@; case. In particular,
almost any program that uses floating point or tasking has to have
some level
-  of inexactness in the specification of its effects.  And if one
+  of inexactness in the specification of its effects. And if one
includes aspects of the timing of the external interactions
in the external effect of the program (as is appropriate for a real-time
-  language), no ``exact effect'' can be specified.
+  language), no @lquotes@;exact effect@rquotes@; can be specified.
For example, if two external interactions initiated by a single task
-  are separated by a ``@key(delay) 1.0;'' then the language rules
+  are separated by a @lquotes@;@key(delay) 1.0;@rquotes@; then the language rules
imply that the two external interactions have to be separated in time
by at least one second, as defined by the clock associated with
-  the @nt<delay_relative_statement>.  This in turn implies that
+  the @nt<delay_relative_statement>. This in turn implies that
the time at which an external interaction occurs is part of
the characterization of the external interaction, at least in
some cases, again making the specification of the required
-  ``exact effect'' impractical.
+  @lquotes@;exact effect@rquotes@; impractical.
@end{Discussion}

An implementation that conforms to this Standard shall support each
@@ -1012,18 +1029,18 @@
The implementation-defined characteristics are summarized in
@RefSecNum{Implementation-Defined Characteristics}.
@begin{Discussion}
-  We used to use the term ``implementation dependent''
-  However, that sounded too much like ``implementation defined''.
-  Furthermore, the term ``unspecified'' is used in the ANSI C and
+  We used to use the term @lquotes@;implementation dependent@rquotes@;
+  However, that sounded too much like @lquotes@;implementation defined@rquotes@;.
+  Furthermore, the term @lquotes@;unspecified@rquotes@; is used in the ANSI C and
POSIX standards for this purpose, so that is another advantage.
-  We also use ``not specified'' and ``not specified by the language''
-  as synonyms for ``unspecified.''
+  We also use @lquotes@;not specified@rquotes@; and @lquotes@;not specified by the language@rquotes@;
+  as synonyms for @lquotes@;unspecified.@rquotes@;
The documentation requirement is the only difference between
implementation defined and unspecified.

-  Note that the ``set of possible effects'' can be ``all imaginable
-  effects'', as is the case with erroneous execution.
+  Note that the @lquotes@;set of possible effects@rquotes@; can be @lquotes@;all imaginable
+  effects@rquotes@;, as is the case with erroneous execution.
@end{Discussion}

The implementation may choose to document implementation-defined behavior
@@ -1072,7 +1089,7 @@
it should normally do so by adding children to the library unit.
@begin(ImplNote)
If an implementation has support code
-(``run-time system code'')
+(@lquotes@;run-time system code@rquotes@;)
that is needed for the execution of user-defined code,
it can put that support code in child packages of System.
Otherwise, it has to use some trick to avoid polluting the user's
@@ -1108,13 +1125,15 @@
rules defining both the effects of each construct and the composition
rules for constructs.

@keepnext@;@Defn2{Term=[syntax], Sec=(notation)}
@Defn2{Term=[grammar], Sec=(notation)}
@Defn2{Term=[context free grammar], Sec=(notation)}
@Defn2{Term=[BNF (Backus-Naur Form)], Sec=(notation)}
@Defn2{Term=[Backus-Naur Form (BNF)], Sec=(notation)}
The context-free syntax of the language is described using a simple variant
-of Backus-Naur Form.  In particular:
+of Backus-Naur Form. In particular:
@begin(Itemize)
@keepnext@;Lower case words in a sans-serif font,
some containing embedded underlines, are used to
@@ -1128,16 +1147,16 @@
@key(array)
@end(Display)

-@keepnext@;Square brackets enclose optional items.  Thus the two following
+@keepnext@;Square brackets enclose optional items. Thus the two following
rules are equivalent.
@begin(Display)
@nt<return_statement> ::= @key(return) [@nt<expression>];
@nt<return_statement> ::= @key(return); | @key(return) @nt<expression>;
@end(Display)

-@keepnext@;Curly brackets enclose a repeated item.  The item may appear zero
+@keepnext@;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 left-recursive rule. Thus the two following rules are
equivalent.
@begin(Display)
@nt<term> ::= @nt<factor> {@nt<multiplying_operator> @nt<factor>}
@@ -1155,8 +1174,8 @@
@Defn2{Term=[italics],Sec=(syntax rules)}
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 @i(subtype_)@nt<name> and
+part. The italicized part is intended to convey some semantic
+information. For example @i(subtype_)@nt<name> and
@i(task_)@nt<name> are both equivalent to @nt<name> alone.
@end(Itemize)
@begin(Discussion)
@@ -1169,22 +1188,22 @@
(see @RefSecNum{The Context of Overload Resolution}).

-We often use ``if'' to mean ``if and only if'' in definitions.
-For example, if we define ``photogenic'' by saying,
-``A type is photogenic if it has the following properties...,''
+We often use @lquotes@;if@rquotes@; to mean @lquotes@;if and only if@rquotes@; in definitions.
+For example, if we define @lquotes@;photogenic@rquotes@; by saying,
+@lquotes@;A type is photogenic if it has the following properties...,@rquotes@;
we mean that a type is photogenic if @i{and only if}
it has those properties.
It is usually clear from the context,
-and adding the ``and only if'' seems too cumbersome.
+and adding the @lquotes@;and only if@rquotes@; seems too cumbersome.

-When we say, for example, ``a @nt{declarative_item} of a
-@nt{declarative_part}'', we are talking about a @nt{declarative_item}
-immediately within that @nt{declarative_part}.  When we say ``a
-@nt{declarative_item} in, or within, a @nt{declarative_part}'', we are
+When we say, for example, @lquotes@;a @nt{declarative_item} of a
+@nt{declarative_part}@rquotes@;, we are talking about a @nt{declarative_item}
+immediately within that @nt{declarative_part}. When we say @lquotes@;a
+@nt{declarative_item} in, or within, a @nt{declarative_part}@rquotes@;, we are
talking about a @nt{declarative_item} anywhere in the
@nt{declarative_part}, possibly deeply nested within other
-@nt{declarative_part}s.  (This notation doesn't work very well for
-@nt{name}s, since the name ``of'' something also has another meaning.)
+@nt{declarative_part}s. (This notation doesn't work very well for
+@nt{name}s, since the name @lquotes@;of@rquotes@; something also has another meaning.)

When we refer to the name of a language-defined
entity (for example, Duration),
@@ -1198,21 +1217,21 @@

@Defn{syntactic category}
A @i{syntactic category} is
-a nonterminal in the grammar defined in BNF under ``@SyntaxTitle.''
+a nonterminal in the grammar defined in BNF under @lquotes@;@SyntaxTitle.@rquotes@;
Names of syntactic categories are set in a different font,
@nt{like_this}.

@ToGlossaryAlso{Term=<Construct>,
Text=<A @i(construct) is a piece of text
(explicit or implicit) that is an instance of a syntactic category
-  defined under ``@SyntaxTitle.''>}
+  defined under @lquotes@;@SyntaxTitle.@rquotes@;>}
@begin{Ramification}
For example, an @nt{expression} is a construct.
A declaration is a construct,
-whereas the thing declared by a declaration is an ``entity.''
+whereas the thing declared by a declaration is an @lquotes@;entity.@rquotes@;
@end{Ramification}
@begin{Discussion}
-``Explicit'' and ``implicit'' don't mean exactly what you might think
+@lquotes@;Explicit@rquotes@; and @lquotes@;implicit@rquotes@; don't mean exactly what you might think
they mean:  The text of an instance of a generic is
considered explicit, even though it does not appear explicitly (in
the non-technical sense) in the program text,
@@ -1251,15 +1270,15 @@
@RefSec(Exceptions and Optimization).

There is no requirement that the implementation always choose
-the same order in a given kind of situation.  In fact, the
+the same order in a given kind of situation. In fact, the
implementation is allowed to choose a different order for two
different executions of the same construct.
However, we expect most implementations will behave in a relatively
predictable manner in most situations.
@end{Ramification}
@begin{Reason}
-The ``sequential order'' wording is intended to allow the programmer
-to rely on ``benign'' side effects.
+The @lquotes@;sequential order@rquotes@; wording is intended to allow the programmer
+to rely on @lquotes@;benign@rquotes@; side effects.
For example, if F is a function that returns a unique integer by
incrementing some global and returning the result,
a call such as P(F, F) is OK if the programmer cares only
@@ -1272,7 +1291,7 @@

@begin{Notes}
The syntax rules describing structured constructs are presented in a
-form that corresponds to the recommended paragraphing.  For example, an
+form that corresponds to the recommended paragraphing. For example, an
@nt{if_statement} is defined as:
@begin(Example)
@nt<if_statement> ::=
@@ -1293,8 +1312,10 @@
@LabeledSubClause{Classification of Errors}

@begin{ImplReq}
The language definition classifies errors into several different
categories:
@begin(Itemize)
@Keepnext@;Errors that are required to be detected prior to run time by every
@@ -1303,7 +1324,7 @@
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
+     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, @i(per se), that the program is free from other
forms of error.
@@ -1331,7 +1352,7 @@
@NoPrefix@Defn{run-time error}
@Defn2{Term=[error], Sec=(run-time)}
The corresponding error situations are associated with the names of
-     the predefined exceptions.  Every Ada compiler is required to
+     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.
@Redundant[If such an error situation is certain to arise in every
@@ -1355,9 +1376,9 @@

@NoPrefix@Defn{erroneous execution}
In addition to bounded errors, the language rules define certain
-     kinds of errors as leading to @i{erroneous execution}.  Like bounded
+     kinds of errors as leading to @i{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
+     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.
@begin{Ramification}
@@ -1370,8 +1391,8 @@
since partitions are not required to live in separate address spaces.
(But implementations are encouraged to limit it as much as possible.)

-       Suppose a program contains a pair of things that will be executed ``in
-       an arbitrary order.''
+       Suppose a program contains a pair of things that will be executed @lquotes@;in
+       an arbitrary order.@rquotes@;
It is possible that one order will result in something sensible, whereas
the other order will result in erroneous execution.
If the implementation happens to choose the first order,
@@ -1380,7 +1401,7 @@

Saying that something is erroneous is semantically
equivalent to saying that the behavior is unspecified.
-       However, ``erroneous'' has a slightly more disapproving
+       However, @lquotes@;erroneous@rquotes@; has a slightly more disapproving
flavor.
@end{Ramification}

@@ -1392,11 +1413,11 @@
@Defn{nonstandard mode}An implementation may provide
@i(nonstandard modes) of operation.
Typically these modes would be selected by a @nt<pragma> or by a command line
-switch when the compiler is invoked.  When operating in
+switch when the compiler is invoked. When operating in
a nonstandard mode, the implementation may reject @nt<compilation_unit>s
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,
+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.
@@ -1407,9 +1428,9 @@
mode, all legal @nt<compilation_unit>s shall be accepted.]
@begin{Discussion}
These permissions are designed to authorize explicitly the
-  support for alternative modes.  Of course, nothing we say can
+  support for alternative modes. Of course, nothing we say can
prevent them anyway, but this (redundant) paragraph is designed
-  to indicate that such alternative modes are in some sense ``approved''
+  to indicate that such alternative modes are in some sense @lquotes@;approved@rquotes@;
and even encouraged where they serve the specialized needs of
a given user community, so long as the standard mode, designed
to foster maximum portability, is always available.
@@ -1441,18 +1462,18 @@
Constraint_Error, even if the value came from an uninitialized
variable.
This means that optimizers can no longer
-``assume'' that all variables are initialized within their subtype's
+@lquotes@;assume@rquotes@; that all variables are initialized within their subtype's
range.
Violating a check that is suppressed remains erroneous.

-The ``incorrect order dependences'' category of errors is removed.
+The @lquotes@;incorrect order dependences@rquotes@; category of errors is removed.
All such situations are simply considered potential non-portabilities.
This category was removed due to the difficulty of defining
-what it means for two executions to have a ``different effect.''
+what it means for two executions to have a @lquotes@;different effect.@rquotes@;
For example, if a function with a side-effect is called twice in a single
expression, it is not in principle possible for the compiler to
decide whether the correctness of the resulting program depends on the order
-of execution of the two function calls.  A compile time warning
+of execution of the two function calls. A compile time warning
might be appropriate, but raising of Program_Error at
run time would not be.
@end{DiffWord83}
@@ -1463,8 +1484,8 @@
@Defn{references}
@Defn{bibliography}
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
+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.
@@ -1537,7 +1558,7 @@
Terms are defined throughout this International Standard,
indicated by @i(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
+refer implicitly to similar terms defined elsewhere. Terms not defined in
this International Standard are to be interpreted according to
the @i(Webster's Third New International Dictionary of the
English Language).
@@ -1565,7 +1586,9 @@