From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!ucla-cs!zen!ucbvax!DCA-EMS.ARPA!jmoody
From: jmoody@DCA-EMS.ARPA (Jim Moody, DCA C342)
Newsgroups: comp.lang.ada
Subject: re: characters with codes >= 128
Message-ID: <8709141533.AA25180@ucbvax.Berkeley.EDU>
Date: Mon, 14-Sep-87 10:28:47 EDT
Article-I.D.: ucbvax.8709141533.AA25180
Posted: Mon Sep 14 10:28:47 1987
Date-Received: Tue, 15-Sep-87 05:43:26 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
List-Id: <comp.lang.ada>

Erland Sommarskog (sommar@enea.uucp) gets to the heart of the
disagreement when he writes:
    And, guys, can't we agree on that it would have been much easier
    if the language definition in one way or another had given place
    for a wider character concept than 128 ASCII codes?
No it wouldn't.  Or at least, easier for whom?
Text_IO, remember, is standard.  That means that all vendors must support
it.  And must support it to all output devices (not just bright terminals).
That means printers with hammers which are limited to the ASCII 95 graphic
characters.  The only reasonable way of requiring vendors to support
something more than the 95 characters plus ASCII.HT would be to make
Text_IO generic.  This brings its own problems:  there is currently no
provision for a generic formal parameter to be restricted to character
type and indeed no requirement that a compiler recognise character types
as a separate semantic category.  I do not know that LRM 3.5.2 is
referenced elsewhere in the LRM.  This means that doing what Sommarskog
wants imposes costs on a vendor/implementor which are not limited to
the Text_IO package but spread into the middle part of the compiler.
If we have a cost of such magnitude, we are entitled to ask what benefit
to the user community as a whole does it produce.  I think that it was a
reasonable decision to limit the standard to the 95 ASCII printables plus
ASCII.HT which means that if someone wants to use other characters, he/she
has to shoulder the cost his/herself rather than have the entire user
community pay.  I emphasis that this is a cost/benefit decision which 
could change in the future.  One of these days, Ada standardisation will
be reopened.  If at that point, it is clear that a substantial segment of
the user community is using or wants to use a bigger character set, the
benefits of centralising the cost of supporting them may outweigh.  I
doubt that it does now.  That is, the cost to Sommarskog of implementing
the subset of text_io which he needs plus the cost to the other users
of implementing the subsets of text_io that they need for the character
sets they want to use is less than the cost (for 137 compilers at last 
count) of requiring vendors to support bigger character sets.  Maybe I'm
wrong.  Maybe there are a thousand applications out there which need
bigger character sets (I think that's the order of magnitude needed for
it to be cheaper on the whole for vendors to support).  If there are, 
then ISO/ANSII/AJPO probably need to be told.

Usual disclaimer:  the opinions expressed are my own and should not be
construed as the opinions of the US Government.

Sorry to go on at such length.

Jim Moody