CVS difference for ai05s/ai05-0227-1.txt

--- ai05s/ai05-0227-1.txt	2011/01/27 06:06:17	1.3
+++ ai05s/ai05-0227-1.txt	2011/01/28 02:29:50	1.4
@@ -1,4 +1,4 @@
-!standard  1.1.4(14.2/2)                             11-01-22    AI05-0227-1/02
+!standard  1.1.4(14.2/2)                             11-01-27    AI05-0227-1/03
 !class binding interpretation 10-10-21
 !status work item 10-10-21
 !status received 10-07-03
@@ -19,14 +19,14 @@
 AARM 2.3(5.c/2) implies that Ada 2005 may be incompatible with Ada 95 in obscure
 cases. That's because some of the sequences which are neither identifiers nor
 reserved words in Ada 2005 were legal identifiers in Ada 95. Moreover, the
-expected change in identifier equivalence also could introduce incompatibilies
+expected change in identifier equivalence also could introduce incompatibilities
 or in very unusual cases, inconsistencies. Neither of these were discussed nor
 documented for Ada 2005.
 
 However, this AARM note is wrong, because 1.1.4(14.2/2) says that "convert to
 upper case" means "locale-independent full case folding". Full case folding does
 not consider the character at 16#DF# (the German character that looks like a
-beta) to be the same as "ss". Thus, these incompatibilies don't arise. However,
+beta) to be the same as "ss". Thus, these incompatibilities don't arise. However,
 "full case folding" is a mapping to *lower case*!! Thus the definition in
 1.1.4(14.2/2) is madness. Moreover, taken literally, it requires 'Image to
 produce *lower case* versions of enumeration literals, which would be completely
@@ -79,7 +79,7 @@
 Replace the notes 2.3(6.a/2-6.i/2) by: (Turkish characters surrounded by <> here, <I> - dotted capital I,
 <i> - dotless lower-case I).
 
-For instance, in most languages, the simple case folded equivalent of LATIN CAPTIAL LETTER I (a
+For instance, in most languages, the simple case folded equivalent of LATIN CAPITAL LETTER I (a
 upper case letter without a dot above) is LATIN SMALL LETTER I (an lower case letter with a dot
 above). In Turkish, though, LATIN CAPITAL LETTER I and LATIN CAPITAL LETTER WITH DOT ABOVE are two
 distinct letters, so the case folded equivalent of LATIN CAPTIAL LETTER I is LATIN SMALL LETTER DOTLESS I,
@@ -97,7 +97,7 @@
 
    d<I>yarbakir
 
-which is different any of:
+which is different from any of:
 
    <the four values in 6.f>
 
@@ -110,7 +110,7 @@
 
 Replace 3.5.1(5):
 
-The defining_identifiers in upper case Redunant[and the defining_character_literals]
+The defining_identifiers in upper case Redundant[and the defining_character_literals]
 listed in an enumeration_type_definition shall be distinct.
 
 AARM Reason: To ease implementation of the attribute Wide_Wide_Value, we require
@@ -125,7 +125,7 @@
 Unicode says that case-insensitive identifier equivalence should be done by
 converting both strings using "locale-independent case folding", and comparing
 the results. But this is *not* a conversion to some case: it is solely intended
-for comparisions.
+for comparisons.
 
 Unicode also provides a variety of mappings to convert strings from mixed case
 into all upper case or all lower case versions. The "full" versions are
@@ -133,7 +133,7 @@
 leave the string lengths the same.
 
 The important take-away here is that there is not a single operation that can
-both be used for case conversion and case insensitive comparisions. These are
+both be used for case conversion and case insensitive comparisons. These are
 two different operations.
 
 An important property of "full case folding" (and "simple case folding as well)
@@ -171,7 +171,7 @@
 Both "full case folding" and "full upper case mapping" can cause strings to
 change lengths. This adds implementation complexity.
 
-"Locale-idependent full case folding" maps the 16#DF# character (German sharp s,
+"Locale-independent full case folding" maps the 16#DF# character (German sharp s,
 represented here by <S>) character maps to "ss". This leads directly to the various
 incompatibilities noted in the question. In particular all of the following
 identifiers would be equivalent in Ada 2012 if this was adopted:
@@ -180,11 +180,11 @@
 
 This is clearly incompatible with Ada 95 (where the last two are different than
 the first three). Moreover, this incompatibility could in fact lead to a
-beaujolias-like inconsistency if there are nested identifiers that used to be
+beaujolais-like inconsistency if there are nested identifiers that used to be
 considered different and now are considered the same.
 
 We might be prepared to live with an incompatibility, but an inconsistency here
-is unconsionable. So we cannot use "locale-independent full case folding".
+is unconscionable. So we cannot use "locale-independent full case folding".
 
 If we use "locale-independent simple case folding" instead, it then makes no
 sense to use the more complex "full upper case mapping" for '[Wide_Wide_]Image.
@@ -201,7 +201,7 @@
 
 Even using "simple case folding" and "simple upper case mapping"s, it is still
 possible for two different identifiers to have the same upper case mapping (the
-dotless i is likely to be such an example). In order to keep the implementation of
+dotless lowercase i is such an example). In order to keep the implementation of
 '[Wide_Wide_]Value manageable, we have also adopted a rule that all of the literals
 of an enumeration type have distinct upper case mappings. This allows
 '[Wide_Wide_]Value to compare the upper case mappings of its parameter, rather than
@@ -223,7 +223,7 @@
 notion that this is what we were doing.
 
 However, this has the same problem as using "locale-independent full case folding".
-The Sharp-S mapping is such that identifiers are incompatable with Ada 95.
+The Sharp-S mapping is such that identifiers are incompatible with Ada 95.
 Thus this solution has to be rejected.
 
 The next obvious thing to do is to define "convert to upper case" in
@@ -245,14 +245,12 @@
 meaning that switching to a newer version of Unicode (presumably when 10646 is
 updated) almost certainly would introduce incompatibilities.
 
-We could solve this by abandoning Unicode altogether. Since we've pretty much
-booted the Unicode recommendations at this point, it doesn't matter much if we
-simply ignore them altogether. We could do that by defining our own case mapping
-algorithm. (Robert Dewar has a suggestion of how we could do that in the
-!appendix.) However, if we were to do that, it would have to be because we
-wanted to avoid incompatibilities in the future. Thus simply depending on
+We could solve this by abandoning Unicode altogether. We could do that by defining
+our own case mapping algorithm. (Robert Dewar has a suggestion of how we could do
+that in the !appendix.) However, if we were to do that, it would have to be because
+we wanted to avoid incompatibilities in the future. Thus simply depending on
 character names/classifications is not enough, as a future character set standard
-will surely change some of those.
+will surely change some of those. Thus we rejected this option.
 
 
 !ACATS Test