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,ASCII-7-bit X-Google-Thread: 103376,e1bb9627c57b7d5b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-11 22:03:10 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.mathworks.com!wn13feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc52.ops.asp.att.net.POSTED!not-for-mail Message-ID: <3F88E067.30209@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: <3F86F5FE.4050104@comcast.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.34.139.183 X-Complaints-To: abuse@comcast.net X-Trace: rwcrnsc52.ops.asp.att.net 1065934989 24.34.139.183 (Sun, 12 Oct 2003 05:03:09 GMT) NNTP-Posting-Date: Sun, 12 Oct 2003 05:03:09 GMT Organization: Comcast Online Date: Sun, 12 Oct 2003 05:03:09 GMT Xref: archiver1.google.com comp.lang.ada:708 Date: 2003-10-12T05:03:09+00:00 List-Id: Alexandre E. Kopilovitch wrote: > I consulted my home linguist on this matter, and she confirmed that there are > exactly 3 alphabets in Japanese: Hiragana, Katakana and a set of hierogliphs. > Then she went in the usage details, but unfortunately she knows nothing about > computer encodings. Anyway, she explicitly rejected the possibility of > context-dependent recognition of Japanese characters in writing or in print. No, the problem is not that the meanings of the characters are context dependent, although in several cases there are over a hundred Kanji that match a single Katakana or Hirigana syllable. (Katakana and Hirigana are phonetic, and there are many more Kanji than phonetically different syllables.) But that is not the problem. In a single text you may see the same word spelled in all three alphabets, or in a mixture of say Hirigana and Kanji. The alphabet chosen to write the word adds or confirms contextual information. The Hirigana alphabet was originally designed for use by women, and is therefore often used to add a feminine implication to a word. The same goes for Katakana and foreign words or things. So you can spell "trousers" in three different alphabets to mean men's pants, womens slacks, and blue jeans. And of course, using the "wrong" spelling in some contexts can be an intentional nasty insult. That is the Minesweeper problem. >>Agreed, but you miss the problem. Right now you can implicitly convert >>between string literals and ANY string type. > > > Do you mean that, for example, an initialization > > S : String := "literal"; > > includes implicit conversion? That is, a string literal itself belongs to some > type other than String? That is correct. > > And I didn't catch what you mean by "ANY string type" - surely that "ANY" > can't include Unbounded_String type, as in In Ada a character type is any enumeration type where one or more of the enumeration values is a character literal. A string type is a one dimensional array of characters. (The index type need not be Integer, or even an integer type.) > > U_S : Unbounded_String := "literal"; -- illegal (but I want it to be legal) > String literals are a universal type that can be implicitly converted to any string type. As I said it would be possible to make this case legal by making Unbounded_String (and presumably similar types) string types. But that would work against what you really want, since now, if you also allow Foo: String := "foo"; O_S : Unbounded_String := Foo; --implicit conversion U_S : Unbounded_String := "literal"; -- Can't work now. ^ ambiguous could be: function ""(L: string_literal) return Unbounded_String; or function ""(L: string_literal) return String; followed by function ""(L: String) return Unbounded_String; But as I said, if you overload unary "+" with the conversion from String to Unbounded_String (and probably vice-versa), then everything works. You write U_S : Unbounded_String := +"literal"; and it all works, you get one implicit conversion (to String) and one explicit conversion (from String to Unbounded_String). How many years of those little plus signs do I need to match all the verbiage we have exchanged on this subject? Now if you want to recommend that in Ada 200X, package Ada.Strings.Unbounded include: function "+" (Source : in String) return Unbounded_String renames To_Unbounded_String; function "+" (Source : in Unbounded_String) return String renames To_String; I will certainly support that. I don't really know why they were left out of Ada.Strings.Unbounded while function To_Unbounded_String (Length : in Natural) return Unbounded_String; function "*" (Left : in Natural; Right : in String) return Unbounded_String; function "*" (Left : in Natural; Right : in Unbounded_String) return Unbounded_String; Although that does mean you can write our canonical example as: U_S : Unbounded_String := 1 * "literal"; > I think I understand this problem of ambiguity. For example, in > > S : String := ... > U_S : Unbounded_String := ... > ... > U_S := Translate(S, ,,,); > > is going to be ambiguous if we have Translate both from String to String and > from Unbounded_String to Unbounded_String -- there appears the diagram: > > conversion > S --------------> Temp_1 > | | > | | > Translate | | Translate > | | > v conversion v > Temp_2 -------------> U_S > > with two possible paths - via Temp_1:Unbounded_String or via Temp_2:String . > But what I want to stress is that this diagram is always commutative, that is, > all possible paths from the source to the destination will always lead to the > same result. The crucial point is that this may be rigorously proven, so we > can safely pick either path. Would be nice if it were true, but remember you can, if you feel like it overide one of the Translate functions with a different meaning. -- 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