Re: characters with codes >= 128

[sommar@enea.UUCP (Erland Sommarskog)]

jmoody@DCA-EMS.ARPA (Jim Moody, DCA C342) writes:
>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?

As you have guessed, I'm not giving in that easy. 

>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.  

That is not an argument. If that is true, we should immediately get away
with the lowercase letters. There are printers who don't know them and
leaves spaces where thext should have been. And, yes, Text_io allows you
send any ASCII character. (Or since when did Put(ASCII.ETX) become illegal?)

More on the spot, what the output device does with bits sent to it is
beyond the scope of the language definition. Or else all vendors will
be in big trouble. How can they assure that ASCII.L_BRACKET always
turn up as a left bracket? Sent to a Swedish terminal you are likely to
get a capital A with dots over.

>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
>
> ...Long discussion on character generic and cost/benefit

The very easy solution is to remove the restriction of character/
string literals to consist of only printable characters. A very cheap
modification, even in 137 compilers. Also the language must explicitly 
allow character codes up to 255, which several compilers already seem
to do. (Any one who knows of one that doesn't?) These two changes are
the minimum, although the language definition would be cleaner with
some packages defining names for all characters. (You need more than
one, since there exists, or will exist, more than one ISO standard
in parallel.)

I could stop here, but let me continue to a definitely more costsome
solution. Ed Colbert talked about the virtue of data abstraction
when advocating the idea of writng a new Text_io. But the character
type is as concrete it can be. Character comparisons based the
codes used for communication is ridiculous when you think of it. It
happens to give the correct result for English, but that is the one.
(With Ada it doesn't really matter, since it seems to disallow other
languages. :-) What I like to see is language-dependent comparison
operators. Languages being selected somewhere, in the OS, a pragma
or set dynamically.
  This last idea is of course not unique for Ada, but general for
all programming langauges.
-- 

Erland Sommarskog       
ENEA Data, Stockholm    
sommar@enea.UUCP