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-06 17:05:15 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!npeer.de.kpn-eurorings.net!newsfeed.stueberl.de!proxad.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: Tue, 7 Oct 3 03:57:32 +0400 Organization: Cuivre, Argent, Or Message-ID: References: <3F7E352F.1@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 1065484927 47111 80.67.180.195 (7 Oct 2003 00:02:07 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Tue, 7 Oct 2003 00:02:07 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: X-Mailer: BML [MS/DOS Beauty Mail v1.36H] 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:350 Date: 2003-10-07T03:57:32+04:00 Robert I. Eachus wrote: > > ... Establishing the idea of a Universal String might not be a bad > > idea..... Although in reality once if we just really standardize on "+" doing > > a conversion and being in the standard I think the extra syntax overhead is > > pretty minimal. > >All I can say is this is language parochialism at its worst. Not Ada >parochialism, but ASCII parochialism. It does not seem a proper attribution. In the issues like that, when you insist on totally equal status, you are actually promoting not diversity, but entropy. (It seems also that you have mostly remote view on other "parishes", and not enough information about real-life problems with national encodings in those other "parishes".) > In Ada, ASCII and Latin-1 have no > particular magic status. If you want to have a character type Cyrillic > and a Cyrillic_String, Greek and Greek_String, or for that matter > Japanese_Character and Japanese_String go right ahead. I can't get how it is related to the issue of relation between Strings and Unbounded_Strings, and to the implicit conversions between them. Those implicit conversions should not change actual memory contents in any way, and they are completely unrelated to any encodings. 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. > If you look in the Ada Reference Manual at sections 3.5.2 Character > Types and 3.6.3 String Types, you would know all this. I looked there, and I reread what said Cohen's book about all that stuff - character sets, maps, and translation - and found nothing relevant to the issue of implicit conversion between Strings and Unbounded_Strings. > Now do you understand why you need for the conversions from String to > Unbounded_String to be explicit? No, I haven't even a slightest idea. > There could be mappings involved, How they can be involved? From all I can see, there are no implicit mappings (that is, implicit calls of Translate subroutine) in Ada 95 standard. > and you definitely don't want two implicit conversions, because the >intermediate type could be just about anything. That could be bad indeed if the mappings were involved, but they don't. I think that at this stage I should show my sketch proposition (which I sent to Ada-Comment about a year ago). Here it is: --------------------------------------------------------------------------- Generalizing the Strings/Unbounded_Strings issue, I would propose a new notion of "enveloped" private type. That is, a private type Y may be declared as an envelope (new keyword) of some base type X: type Y is private envelope of X; Enveloping type (Y above) is required to have 2 private primitive operations: function Strip (Source : Y) return X; and function Upgrade (Source : X) return Y; which must be exact inverse of each other: Strip( Upgrade(V) ) = V and Upgrade( Strip(W) ) = W and their implementation is severely restricted so that compiler can verify and guarantee these identities. Then, a variable of enveloped type may be immediately initialized with a value of enveloping type and vice versa, in all cases of initialization, which include: 1) declaration with initialization V : X := R; -- where R is either a variable or constant of type Y -- or a function returning result of type Y W : Y := S; -- where S is either a variable or constant of type X -- or a function returning result of type X 2) argument for "in" parameter of a subroutine call function F(A : in X; B : in Y) ... procedure P(A: in X; B : in Y) ... V : X; W : Y; ... ... := F(W, V); P(W, V); 3) argument for "out" parameter of a procedure call procedure P1(U : out X) ... procedure P2(U : in out X) ... W : Y; ... P1(W); P2(W); In all these cases a compiler provides implicit conversions between types X and Y using private operations Strip and Upgrade of Y. Further, there may be several different envelopes for the same base type: type Y is private envelope of X; type Z is private envelope of X; and one of those envelopes may be immediately used for an initialization of a variable or parameter of another envelope type (as in the previous case above). For example: procedure P(W : out Y) ... T : Z; ... P(T); The compiler provides implicit conversions between types Y and Z using compositions Z.Upgrade(Y.Strip(...)) and Y.Upgrade(Z.Strip(...)) . I believe that the notion of enveloped type may be considered (to some extent) as opposite to the notion of subtype. --------------------------------------------------------------------------- As I said recently, I can't work out this proposition to a precise and complete form - I'm not a language laywer. But I don't see why it may be fundamentally wrong, and still nobody said me that. Some today's comments for that 1-year-old text: 1) subroutine names "Strip" and "Upgrade" should be seen as "denonations", and To_X, To_Y (To_String and To_Unbounded_String in the case of Strings) may be actually used instead. 2) although this proposition is about implicit conversions, the latter are essentially identities, and what is most important, they are applicable for explicitly related types only. Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia