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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable 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 12:51:09 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!easynet-quince!easynet.net!mephistopheles.news.clara.net!news.clara.net!usenet-fr.net!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail From: "Alexandre E. Kopilovitch" Newsgroups: comp.lang.ada Subject: Re: U : Unbounded_String := "bla bla bla"; (was: Is the Writing...) Date: Sat, 11 Oct 2003 23:43:57 +0400 (MSD) Organization: Cuivre, Argent, Or Message-ID: References: <3F86F5FE.4050104@comcast.net> NNTP-Posting-Host: lovelace.ada-france.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: melchior.cuivre.fr.eu.org 1065901751 55634 80.67.180.195 (11 Oct 2003 19:49:11 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Sat, 11 Oct 2003 19:49:11 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: In-Reply-To: <3F86F5FE.4050104@comcast.net>; from "Robert I. Eachus" at Fri, 10 Oct 2003 18:10:38 GMT X-Mailer: Mail/@ [v2.44 MSDOS] X-Virus-Scanned: by amavisd-new-20030616-p5 (Debian) at ada-france.org X-BeenThere: comp.lang.ada@ada-france.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Gateway to the comp.lang.ada Usenet newsgroup List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Xref: archiver1.google.com comp.lang.ada:685 Date: 2003-10-11T23:43:57+04:00 Robert I. Eachus wrote: > Have you played the Minesweeper game that comes with Windows in expert > mode? Well, I almost never played computer games... there was single exception about a decade ago, I played SimCity for half an hour. But I developed several computer games for living, so I am not completely out of contact with that world -;) . Right now I glanced on this Minesweeper game, trying to catch what you meant. > Working with Japanese text is like that when you have to deal > with encodings. They have three alphabets, and almost all words can be > written using more than one. But the RIGHT one to use often depends on > context. 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. So, I still don't understand those specific problems your mentioned: do you mean that not only encodings for these 3 alphabets overlap, but also that no special "switching" characters are used? It seems highly unlikely to me - I hardly can believe that Japanese really use some non-trivial context-dependent encoding scheme instead of simple switching of alphabets (by special characters) or using non-overlapped encodings for these alphabets. And excuse me, but I will not believe in that until a native Japanese programmer confirm that... and explain the reasons, however briefly. (Those problems with Japanese encodings that I met in emails were of entirely another kind, they had no in common with context-dependent encodings.) > > Oh, it seems that I see (at last!) what you mean: you assume that conversions > > between encodings should be implicit! But this is far from desirable in real > > applications! > > > > I understand perfectly that there should not be two competing kinds of implicit > > conversions (one between encodings and another between String and Unbounded_String). > > So we have to choose between them. > > > You assumed that implicit conversions between encodings are more natural and > more desirable than implicit conversions between String and Unbounded_String. > > 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? And I didn't catch what you mean by "ANY string type" - surely that "ANY" can't include Unbounded_String type, as in U_S : Unbounded_String := "literal"; -- illegal (but I want it to be legal) > You want to add implicit > conversions between String and Unbounded_String, and presumably between > Wide_String and Wide_Unbounded_String, and so on. Yes. But I'm ready to accept some restrictions... and the minimum which I want is implicit conversions from string literals to Unbounded_String and Bounded_String. Additionally, it will be very good to permit implicit conversions from non-literal strings to other string types (I mean String to Unbounded_String and vice versa etc.) in initializations. Regarding full-scale implicit conversions (in assignments and expressions), I'm not sure... perhaps associated problems overweight the gains there indeed, and in fact the gains in those cases are more doubtful. > Now when you go to do explicit conversions between string types, the > presence of two potential implicit conversions makes some simple seeming > conversions hard or impossible to write unambiguously. If you want to > go and overload the (existing) explicit conversions on unary "+" > everything works just fine. The cases that would be ambiguous with two > implicit conversions around are disambiguated by the presence and > location of the "+" operators. 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. I understand that value of statements about rigorous proofs is generally doubtful as it pertains to real programming, and in particular, to compilers. But fortunately in Ada we have a professional team specializing in this area - I mean SPARK people, and I hope that they may provide sufficient support for this method of disambiguation, if needed. > And as I said, I think adding implicit conversion of string literals to > and from Unbounded_String would work. But that isn't the case you want. Actually this is exactly the minimum which I want, as I just explained above. > And of course, adding both that and implict conversions from String to > Unbounded_String would be a disaster. I'm ready to admit that in general case, which includes assignments and expressions. In fact, requirement of explicit conversions in assignments and expressions not only brings some inconvenience, but also acts as a kind of warning which sometimes may be useful, so there is much less desire for implicit conversions in those cases. Probably there is only one common case where those implicit conversions (in expression) are definitely desired: S1 : String := ... S2 : String := ... U_S : Unbounded_String := ... ... Text_IO.Put(S1 & U_S & S2); > The rules in ARM 4.6, Type Conversions and 8.6 The Context of Overload > Resolution are pretty complex just to make the language SEEM simple to > use. ;-) I believe that (I can't say that I *understand* that, though -;) . Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia