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.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC 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!seismo!mcvax!enea!sommar From: sommar@enea.UUCP (Erland Sommarskog) Newsgroups: comp.lang.ada Subject: Re: characters with codes >= 128 Message-ID: <2281@enea.UUCP> Date: Tue, 15-Sep-87 16:55:58 EDT Article-I.D.: enea.2281 Posted: Tue Sep 15 16:55:58 1987 Date-Received: Fri, 18-Sep-87 04:20:01 EDT References: <8709141533.AA25180@ucbvax.Berkeley.EDU> Reply-To: sommar@enea.UUCP(Erland Sommarskog) Followup-To: comp.lang.ada Organization: ENEA DATA Svenska AB, Sweden List-Id: 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