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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,6afcf1840abb7c5e X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,UTF8 Path: g2news2.google.com!news3.google.com!news.glorb.com!newsfeed0.kamp.net!newsfeed.kamp.net!newsfeed.arcor.de!news.arcor.de!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Send me a sample prgm in ADA for linked list using access type From: Georg Bauhaus In-Reply-To: References: <1147426476.864349.95890@y43g2000cwc.googlegroups.com> <1147427871.772981.122150@i40g2000cwc.googlegroups.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Organization: # Message-ID: <1147560551.9085.101.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Date: Sun, 14 May 2006 00:49:11 +0200 NNTP-Posting-Date: 14 May 2006 00:48:20 MEST NNTP-Posting-Host: a4bdb15e.newsread2.arcor-online.net X-Trace: DXC=G2LWB]5l7j;CDTkn::RD0?Q5U85hF6f;4jW\KbG]kaM8VA=iV<7g:25konHFVAIa>8=0F65HQV8i6iQ:TIkElR<6 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:4237 Date: 2006-05-14T00:48:20+02:00 List-Id: On Sat, 2006-05-13 at 09:50 -0500, Larry Kilgallen wrote: > I would suggest sticking to ASCII (values 32-127) for maximum clarity. I agree that 7 bit character sets guarantee low probability of misrepresentation on today's machines. On the other hand, I spend many hours finding serious, unnerving, and costly character handling bugs in "standard" software packages. Most of these bugs demonstrate that many programmers somehow believe that 7bit is anywhere near sufficient. (Maybe for themselves?) This is why I'd like to question your advice in two ways. Fostering 7 bit ASCII habits (32-127) in usenet will invite two shortcomings of programs, or, pardon me, their programmers, because you learn that you can get away with it in usenet: (a) meeting the requirements of real world software, on the technical side (b) software professionalism, on the human side (a) Few computer users find a seven-segment LED display agreeable, so to speak. These have no 1:1 relation to ASCII but you get the picture. Usually, 7 bit Text is a serious hindrance, even when English is the language. For example, shops, insurance companies, etc. cannot spell Spanish, French, Canadian, Polish, Danish ... names, titles, addresses etc. S=C3=B8rensen is not the same person as Sorensen. [**] (And these all use Latin scripts.) Searching will not work properly. [*] (b) lack of true character support is really strange. Many times programmers have taken pride in algorithms that arrange bits in a well defined and efficient manner. But when these bits represent characters, not so. A fair amount of irrationality is added to what is considered arguments. "It's slow!" "It wastes memory!" "It's too much work!" "Who needs it?" "Learn how to read!" Is any of this backed up with convincing data, measurements, business requirements, etc.? At the same time, users are annoyed when they cannot write currency symbols like =C2=A3, or =E2=82=AC. (Zip codes are rejected if the style is = British. Phone numbers can not be entered using alphabetic characters. Passwords cannot contain accented characters. Same symptoms?) Programmers spend hours trying to find ways of rendering or combining pieces of data encoded differently, or at least find the most likely applicable encoding. Is this where we should be spending our time? So, No! It is time to consider that VAX, Alpha, Motorola 68030, x86, PowerPC, SPARC, etc. have 32 bit words in registers. We can see that placing 8bit quantities in x86's AL (8 bits wide) will *not* in general make our programs run faster. One should think that people who write sophisticated sorting algorithms, or operating systems' process schedulers for N CPUs are capable of providing functions for plain text rendering. All the more when the algorithms have already been published, and when libraries are freely available, with or without support, for free or not. It is time to consider the capabilities of the computers of today^H^H^H^H^H yesterday. These can be programmed to handle much more than 127 - 32 + 1 character positions. There are standards and collections, there is supported software. ISO/IEC 10646:2003, Unicode >=3D 3.1, TRON, Mule, whichever. Sant=C3=A9 ! [*] This is still real, see for example the Oxford Advanced Learner's Compass, which is the electronic edition of OALD, an otherwise very good program: When I want to find "master" and start typing "mas" into the search box, the Find As You Type lookup gets stuck because seemingly it runs into "ma=C3=AEtre", and stops there. (That's ma^itre, if your news reader can't display Western international plain text.) [**] A famous example is the mix-up of surnames Tuttle and Buttle in the film "Brazil". A bug in a typewriter causes terror. ;-)