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 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!mx05.eternal-september.org!feeder.eternal-september.org!nuzba.szn.dk!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Is this expected behavior or not Date: Fri, 12 Apr 2013 19:22:36 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <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> <8bj2k30k7i19.w7ehsldwbf7x.dlg@40tude.net> <1o34nhpfuy6yl$.2orlukd1elr7.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1365812559 7908 69.95.181.76 (13 Apr 2013 00:22:39 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sat, 13 Apr 2013 00:22:39 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:14979 Date: 2013-04-12T19:22:36-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:lhy7cs9p0v0t.jmyir4bofwok.dlg@40tude.net... > On Thu, 11 Apr 2013 18:02:49 -0500, Randy Brukardt wrote: ... >> It is never a good idea to mix types in a program: String shouldn't be >> mixed >> with Wide_String, Float with Complex, or Integer with Float. In the rare >> case when you need to do so, you should write an explicit conversion. > > Ergo, performance is not your concern when it is about the Principle. But > you tried to justify that very principle with performance in first place. > > So, we are the to the square one. Of course. You argue in circles, which makes me go over the same things over and over. I'm wasting my time bothering. > Why is it never a good idea to use > Ada.Strings.Unbounded.Append [a mixed type operation]? That's the package that convinced me that mixed operations are never a good idea. The intent of the mixed operations was to provide string literals, but the effect was that they are available inconsistently and you're at a real risk of ambiguity. Moreover, there are cases where you have to convert things to String just to do an operation on a value of an Unbounded_String. It's just a bad design. Of course, if you have to use the bad design, then using the operations provided in that bad design is unavoidable. >> There's nothing wrong with storing all strings in unbounded UTF-8, for >> instance, but storing them in a variety of formats will just cause you a >> huge amount of translation overhead. It's not worth it. > > This is what you proposed. I did to avoid translations through support of > mixed type operations. They do exactly that. But you're not eliminating anything. The only way to implement such mixed operations is via converting one or the other operands to the most general type. Certainly that's required to automatically create such operations, and that would have to be the case in order to avoid forcing programmers to create thousands of operations for large hierarchies like strings. In any case, multi-methods don't work given the existing Ada resolution rules. You want to fix that with preference rules, but those are a non-starter. That's because preference rules give rise to Ripple and Beaujolias effects, which are not and will not be tolerated in Ada. (These are cases where adding or removing an otherwise unused with or use clause can change the meaning of a program.) Unless you can clearly prove that you have rules that are completely free of such effects (which are significant maintenance hazards), the ARG will not consider them. (Integrated packages failed in Ada 2012 mainly because we couldn't eliminate such effects.) >>>> For instance, I tend to write out the entire name of the conversion >>>> between string and unbounded string: >>>> >>>> Ada.Text_IO.Put_Line (Ada.Strings.Unbounded.To_String (My_Object)); >>> >>> Hideous. What kind of information this mess should convey to the reader? >>> 2/3 of it is noise. My_Object is a string, why Put_Line does not handle >>> it? >> >> It's a "string", not a String. > > And *semantically* the difference is? Ada is strongly typed; there is currently no such thing as an operation that will work on any string type. The origin of this pointless discussion was possible ways to fix that, but you are so focused on useless, pie-in-the-sky capabilities that we can't sanely explore what we CAN do. (Which is what I wanted to do initially.) Randy.