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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: border1.nntp.dca3.giganews.com!border2.nntp.dca3.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!newsfeed.news.ucla.edu!usenet.stanford.edu!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Is this expected behavior or not Date: Fri, 5 Apr 2013 18:29:54 +0200 Organization: cbb software GmbH Message-ID: References: <1u72u7h5j4jg3$.wlxmaltyzqik.dlg@40tude.net> <1gnmajx2fdjju.1bo28xwmzt1nr.dlg@40tude.net> <3gv2jwc95otm.pl2aahsh9ox8.dlg@40tude.net> <1gkxiwepaxvtt$.u3ly33rbwthf.dlg@40tude.net> <1fmcdkj58brky.bjedt0pr39cd$.dlg@40tude.net> <1bj564vat3q1j$.1s4d00rlzx4ux$.dlg@40tude.net> <4hzv51v872q2$.1imijbwd7heqm$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: rHWOzyHApalsT5sEUcbvVQ.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 X-Original-Bytes: 4889 Xref: number.nntp.dca.giganews.com comp.lang.ada:180936 Date: 2013-04-05T18:29:54+02:00 List-Id: On Fri, 5 Apr 2013 17:16:59 +0200, Stefan.Lucks@uni-weimar.de wrote: > On Fri, 5 Apr 2013, Dmitry A. Kazakov wrote: > >> On Fri, 5 Apr 2013 14:45:55 +0200, Stefan.Lucks@uni-weimar.de wrote: >> >>> But what reasons would you have to actually mix >>> narrow, Wide_ and Wide_Wide_ Strings? >> >> What is at least one reason to distinguish them? > > I agree with you that there is no reason to distinguish between them. The > entire distinction narrow, Wide_ and Wide_Wide_ Strings (and Characters) > is a historical artifact, no more, no less. > > But if there is no reason to disting between them -- there is no reason to > mix them either! Sorry, but it cannot be both. > Right now, the best you can do if you really have to use different of > these String types is the following: > 1. convert everything into a single type (probably Wide_Wide_String), > 2. do your work. > 3. and convert back (if you really have to). This is how the compiler could implement the interface inherited from the root string type, e.g. from Wide_Wide_String. But that is an implementation detail. The problem is in resolution of mixed operations *inevitably* emerging from putting strings under the same roof. Wether you inherit an implementation from Wide_Wide_String and compose it with a conversion forth and/or back to String or else override it with a tailored implementation is not the core problem. The problem is that Ada does not support multi-methods needed for this. That literals generate uncontrollable ambiguities. These problems are to address. >> Once answered, please name a reason to distinguish UTF-16, UTF-8, UCS-2 etc >> strings in assignment, comparison, concatenation. > > I agree, there is none. Which is precicely why one should not need any > mixed-representation operations. How so? Apart from comparisons and concatenation. Consider Ada.Text_IO.Create. It has name a string and content. You tell us that it is not necessary to be able to open an UTF-8 file which name is UTF-16? Blame Microsoft. >> The difference between Randy and me, is that he wants to scrap all >> operations Ada 83 strings had. Since this would be clearly incompatible >> with existing programs, he wants to add them as completely new types, as if >> we had not enough string types in the language already. > > I think, I agree with Randy here. The old bunch of strings are a mess, There is nothing wrong with them except for being not in the same class. [Literals could be done better] > that has historically evolved and is far beyond repair. Trying to repair > it by adding support for mixed operations gives birth to a gazillion of > new cockroaches. They tried once, see Unbounded_String. They tried twice, see bounded strings. This is an inherently flawed approach. Furthermore what Randy proposes will actually be worse than pitiful Unbounded_String. For them you could at least do this: type Relative_File_Path is new Unbounded_String; type Absolute_File_Path is new Unbounded_String; You could not do that for tagged strings. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de