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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,UTF8 X-Google-Thread: 103376,e1bb9627c57b7d5b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-08 16:19:00 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!cyclone.bc.net!sjc70.webusenet.com!news.webusenet.com!elnk-nf2-pas!newsfeed.earthlink.net!wn14feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc54.POSTED!not-for-mail Message-ID: <3F849B4A.2090008@comcast.net> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: U : Unbounded_String := "bla bla bla"; (was: Is the Writing...) References: <3F7E352F.1@comcast.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit NNTP-Posting-Host: 24.34.139.183 X-Complaints-To: abuse@comcast.net X-Trace: rwcrnsc54 1065655139 24.34.139.183 (Wed, 08 Oct 2003 23:18:59 GMT) NNTP-Posting-Date: Wed, 08 Oct 2003 23:18:59 GMT Organization: Comcast Online Date: Wed, 08 Oct 2003 23:18:59 GMT Xref: archiver1.google.com comp.lang.ada:504 Date: 2003-10-08T23:18:59+00:00 List-Id: Alexandre E. Kopilovitch wrote: > BTW, when you mentioned Cyrillic_String you made me smiling grimly. Do you > know that there are 3 alive Cyrillic encodings? Do you know that, for example, > in Windows, the final effect of your Cyrillic encoding depends not only upon > encoding, but upon Regional Settings also? And there are plenty of more subtle > issues, which may easily hurt you when you deal with a Cyrillic encoding. So, > don't fancy that your Cyrillic_String will be of much help, especially if you > want to develop a robust product for actual field use. You are just thinking Russian, there are even more Cyrillic character bindings for other Cyrillic languages. When it comes to multiple representations for one language Japanese is by far the worst! But if you don't see it, try this. In Ada, I can DEFINE a Cyrillic_String type and bind it to one of the variants, and add other string types for other variants, then provide for conversions between them. The fact that almost all conversions are explicit makes all this possible. Let me add three types and show you the problem: type Unbounded_Cyrillic is new Ada.Strings.Unbounded.Unbounded_String; -- to make sure you don't get confused. Yeah, I know, in real life -- you should make the derivation private, and provide Cyrillic_String -- versions of some of the operations in Ada.Strings.Unbounded. Take --- all that as given. type Georgian_String is (...); type Unbounded_Georgian is new Ada.Strings.Unbounded.Unbounded_String; -- same as above. In Ada as it is now, I can say: Some_String: Unbounded_Cyrillic := To_Unbounded("Македонии"); Other_String: Unbounded_Georgian := To_Unbounded("Македонии"); In each case, there is an implicit conversion from the string_literal "Македонии" to the proper string type, then that type is converted to the proper unbounded type. But if you add additional implicit conversions into the mix, it all falls apart: Some_String: Unbounded_Cyrillic := "Македонии"; I hope you don't expect the compiler to guess which set of implicit conversions to apply! I am certainly not going to try to list all the possibilities, but for example, there is: "Македонии" to String to Unbounded_String to Cyrillic_String. And yes, in this case, the first conversion would raise Constraint_Error. But I could choose some other example where all the characters were in both (Latin1) String and Cyrillic_String. But I don't have to: "Македонии" to Georgian_String to Unbounded_Georgian to Unbounded_String to Cyrillic_String. Once you introduce new implicit conversions, the compiler is going to have to assume that they may occur anywhere. If the overloading rules result in only one possible match, great. But you will find that right now Ada has about as many implicit conversions as it can without creating lots of ambiguous situations. And yes, there are situations in Ada currently where you have to qualify expressions to avoid ambiguity. The most userul balance point is where everything can be done, and you don't have to qualify expressions too often. Oh, since I am trying to be fair here, there is one additional implicit conversion that I would love to figure out how to add to the language. (Well, I know how to add it, I just don't think I'll ever get enough interest to make it happen.) That would be to add some pragmas that allowed character, string, or numeric literals to private types. The conversion directly from a character literal to Unbounded_Cyrillic wouldn't break anything. It also wouldn't help if you had a Cyrillic_String variable to put in an Unbounded_Cyrillic object. -- Robert I. Eachus "Quality is the Buddha. Quality is scientific reality. Quality is the goal of Art. It remains to work these concepts into a practical, down-to-earth context, and for this there is nothing more practical or down-to-earth than what I have been talking about all along...the repair of an old motorcycle." -- from Zen and the Art of Motorcycle Maintenance by Robert Pirsig