Version 1.1 of ais/ai-00049.txt
!standard A.1 (35) 96-06-05 AI95-00049/02
!class confirmation 95-06-25
!status WG9 approved 95-06-14
!status ARG approved 10-0-1 (by letter ballot) 96-06-05
!status ARG approved (subject to letter ballot) 8-1-1 95-11-01
!status received 95-06-25
!subject Reserved_128, etc.
!summary 96-04-30
The names of the control characters in type Character are as defined in
the RM.
!question 96-04-30
Several of the control characters in type Character have (italicized)
names starting with "Reserved", namely:
Reserved_128
Reserved_129
Reserved_132
Reserved_153
It is not clear that these names reflect the latest version of ISO 6429.
Furthermore, it seems a pity to have Character'Width = 12, when all the
other character names are much shorter.
!response 96-04-30
It seems hopeless to keep up with a moving target. For portability, it
is important that all Ada implementations use the same names.
Therefore, we should stick with what we have.
The fact that Character'Width = 12 seems a minor annoyance compared to
the portability concern.
!appendix
!section A.1(35)
!subject Reserved_128, etc.
!reference RM95-A.1(35)
!keywords character, ISO 8859-1
!from Keith Thompson 95-05-05
!reference as: 95-5135.a Keith Thompson 95-5-5>>
!discussion
Several of the control characters in type Character have (italicized)
names starting with "Reserved", namely:
Reserved_128
Reserved_129
Reserved_132
Reserved_153
If I understand correctly, these strings (mapped to upper case)
are required to be the results returned by Character'Image; e.g.,
Character'Image(Character'Val(128)) = "RESERVED_128".
I've seen a document that gives shorter names for these characters:
128 => PAD
129 => HOP
132 => IND
153 => SGCI
(Sorry, I don't know where I saw these.)
If these shorter names are valid, are implementations
allowed/encouraged/required to use them instead of the longer names?
It seems a pity to have Character'Width = 12 -- though inconsistency
between implementations is probably worse.
Note that the set of "Reserved" character names changed between
draft 5.0 and the final version 6.0:
5.0 6.0
--- ---
Reserved_130 --> BPH
Reserved_131 --> NBH
IND --> Reserved_132
Reserved_152 --> SOS
Reserved_154 --> SCI
If the names of the ISO 8859-1 characters are a moving target, how can
Ada 95 best follow that target over the next Y+5 years (Y as in Ada 200Y)?
My suggestion: Find out the "real" names of these characters and issue
a ruling requiring these names to be used instead of Reserved_128, etc.
-- *before* validated Ada 95 compilers start hitting the streets.
****************************************************************
!section A.1(35)
!subject Draft of AI95-00049/00 -- Reserved_128, etc.
!reference RM95-A.1(35)
!reference 95-5195.a Robert A Duff 95-6-29
!keywords character, ISO 8859-1
!from Keith Thompson 95-07-07
!reference as: 95-5211.a Keith Thompson 95-7-7>>
!discussion
Bob Duff wrote:
> The names of the control characters in type Character are defined in the
> RM, even if the ISO character set standard 8859-1 changes.
[...]
> It seems hopeless to keep up with a moving target. For portability, it
> is important that all Ada implementations use the same names.
> Therefore, we should stick with what we have.
>
> The fact that Character'Width = 12 seems a minor annoyance compared to
> the portability concern.
This is probably correct, but I'll make one last attempt to state the
case for changing it.
I don't know the status of the ISO 8859-1 standard. If it's at or near
completion, and the character names in question (for positions 128, 129,
132, and 153) were added to that standard recently, and are likely or
certain to remain stable indefinitely, then I think it's (just barely!)
not too late to make the Ada standard consistent with the ISO 8859-1
standard. In this case, retaining the names Reserved_128, etc., could
generate more confusion. Portability can be addressed by adding a test
to the ACVC that requires the updated names.
If this change is to be made, it should be done Real Soon Now, or there
*will* be portability problems.
This is certainly a less radical change to the Ada-95 standard than
allowing 8-bit characters or raising Constraint_Error instead of
Numeric_Error was for the Ada-83 standard.
Of course, if ISO 8859-1 really is a moving target, my entire argument
falls apart. Can someone out there find out what its status is?
****************************************************************
!section A.1(35)
!subject Draft of AI95-00049/00 -- Reserved_128, etc.
!reference RM95-A.1(35)
!reference 95-5195.a Robert A Duff 95-6-29
!keywords character, ISO 8859-1
!from Keith Thompson 95-07-07
!reference as: 95-5211.a Keith Thompson 95-7-7>>
!discussion
Bob Duff wrote:
> The names of the control characters in type Character are defined in the
> RM, even if the ISO character set standard 8859-1 changes.
[...]
> It seems hopeless to keep up with a moving target. For portability, it
> is important that all Ada implementations use the same names.
> Therefore, we should stick with what we have.
>
> The fact that Character'Width = 12 seems a minor annoyance compared to
> the portability concern.
This is probably correct, but I'll make one last attempt to state the
case for changing it.
I don't know the status of the ISO 8859-1 standard. If it's at or near
completion, and the character names in question (for positions 128, 129,
132, and 153) were added to that standard recently, and are likely or
certain to remain stable indefinitely, then I think it's (just barely!)
not too late to make the Ada standard consistent with the ISO 8859-1
standard. In this case, retaining the names Reserved_128, etc., could
generate more confusion. Portability can be addressed by adding a test
to the ACVC that requires the updated names.
If this change is to be made, it should be done Real Soon Now, or there
*will* be portability problems.
This is certainly a less radical change to the Ada-95 standard than
allowing 8-bit characters or raising Constraint_Error instead of
Numeric_Error was for the Ada-83 standard.
Of course, if ISO 8859-1 really is a moving target, my entire argument
falls apart. Can someone out there find out what its status is?
****************************************************************
!section A.1(35)
!subject Reserved_128, etc.
!reference RM95-A.1(35)
!reference 95-5135.a Keith Thompson 95-5-5
!reference AI95-00049
!reference RM95-1.2
!from Keith Thompson 95-11-03
!reference 95-5381.a Keith Thompson 95-11-3>>
!discussion
Several months ago, I wrote:
> I've seen a document that gives shorter names for these characters:
>
> 128 => PAD
> 129 => HOP
> 132 => IND
> 153 => SGCI
>
> (Sorry, I don't know where I saw these.)
The document in question is RFC 1345, "Character Mnemonics & Character
Sets", which is not actually a standard.
According to some recent e-mail from Erik Naggum (erik@naggum.no):
> PAD, HOP, IND, and SGCI are dead. the codes may be assigned to something
> else. the codes were reserved because it was envisioned that ISO 10646
> would need them. now it doesn't. no published standard includes them.
The relevant standard for control characters is apparently ISO 6429,
not ISO 8859-1, which only deals with graphic characters. (Both are
listed under Normative References in 1.2).
****************************************************************
!section A.1(35)
!subject Reserved_128, etc.
!reference AI95-00049
!from Norman Cohen
!reference 96-5574.b Norman H. Cohen 96-5-24>>
!discussion
The !repsonse states, "It seems hopeless to keep up with a moving
target." Maybe, but it's not hopeless to keep chasing it, and since
we're an ISO body and ISO is the entity moving the target, we ought to
try.
For the sake of upward compatibility, no currently defined names should
ever be removed from Ada.Latin_1. However, as new names are recognized
by ISO, they should be added to the package as aliases (following the
examples of Hyphen and Minus_Sign, IS1 and US, Pilcrow_Sign and
Paragraph_Sign, etc.).
I believe that the ARG should approve this AI, but with a recommendation
to WG9 to establish a liason to the appropriate ISO body to keep
informed about changes to the names of 8859-1 characters, with the
intent of tracking these changes in the definition of Ada.Latin_1.
(By the way, the RM reference in the AI should be to A.3.3, not A.1.)
****************************************************************
Questions? Ask the ACAA Technical Agent