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=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,73cb216d191f0fef X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.20.105 with SMTP id m9mr3630065wie.5.1366081073811; Mon, 15 Apr 2013 19:57:53 -0700 (PDT) MIME-Version: 1.0 Path: hg5ni6237wib.1!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!border2.nntp.ams2.giganews.com!border1.nntp.ams2.giganews.com!border3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!news.teledata-fn.de!news.albasani.net!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: Wed, 10 Apr 2013 17:07:57 -0500 Organization: Jacob Sparre Andersen Research & Innovation 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> <8bj2k30k7i19.w7ehsldwbf7x.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1365631681 7527 69.95.181.76 (10 Apr 2013 22:08:01 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 10 Apr 2013 22:08:01 +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 Date: 2013-04-10T17:07:57-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:8bj2k30k7i19.w7ehsldwbf7x.dlg@40tude.net... > On Tue, 9 Apr 2013 18:24:29 -0500, Randy Brukardt wrote: ... >>> Why there should be many? >> >> If you've got operations like "+" or "*", you'll have a lot of functions >> returning objects of the type. That's a bad idea for the reasons I >> mentioned. > > You have + and * of GUI objects? That is weird. Anyway if you have > arithmetic upon a hierarchy how the compiler is supposed to deduce > implementations for derived types? Tagged types and extension is used for more than just GUIs. The compiler shouldn't have trouble with inheriting implementations -- we don't do or want multi-methods, after all. Ada only supports that for null extensions; it's easy to extend that so long as an information-preserving conversion is possible. (That would have to be declared by an aspect, I think.) ... >>>>> Yes, the language permits compilers implemented poorly, and? >>>> >>>> This has nothing to do with compilers. It has to do with *poorly >>>> designed >>>> programs*. It's certainly true that a program that depends on by-copy >>>> or >>>> by-reference passing is wrong; the compiler should be free to choose. >>>> But >>>> this is an undetectable error. And bringing Adjust into it makes it >>>> much >>>> worse, because it's easy to write code that doesn't work if Adjust is >>>> called (you probably can get infinite recursion that way). >>> >>> Are you saying the copy constructors (Adjust) are broken in Ada? They >>> are >>> to me too. Fix them. >> >> Not at all (at least for this topic). The act of calling a routine (*any >> routine*) usually has detectable side-effects. That's certainly true for >> Adjust. (It might be bad practice to depend on those side-effects, but >> language standards cannot legislate program morality.) > > You don't make language design dependent and promoting bad practices. If you are starting with a blank page, you're right. If you are building on 30+ years of practice, even "bad practice" has to be taken into account. This is one of the reasons that the language you're suggesting really has to be different than Ada. Ada has too many existing nasties that have to be preserved in order to make the overhaul you're suggesting. We'd be afraid to do it even if it appears to be neutral, just because it would be too risky to make the change. I'd like to make objects [and exceptions] overloadable (it would fix a large percentage of the problems with use clauses and visibility, and unify objects, enumeration literals, and functions - which you should be able to switch between without breaking anything). But the idea is deemed too risky; there is a very low possibility of silent changes in meaning of programs (usually, an illegal program would become legal -- not a problem, or a legal program would become illegal -- a problem, but not showstopping, especially as it would be rare). So the idea is unlikely to go anywhere. And that is a *much* simpler change than what you're suggesting. ... ... >> That isn't very likely to >> happen. The only way to define these conversions would be through a >> Wide_Wide_String intermediate - the net effect is that the conversions >> will >> be quite expensive and you would never, ever want to use such >> implementations. > > This is exactly the overhead of doing this using the infamous unary plus > operation. I don't understand the point you are trying to make. You don't > want to override for custom types, you don't want automatic conversion as > too expensive. There is no third way. You want to apply explicit > conversions at all call points? This is exactly the solution you declared > inefficient. It not only inefficient, it is extremely error prone and a > major overhead for those unfortunate who have to use the package defined > in > such manner. The compiler rejects a program. What you do? Erratically > place > unary pluses before all arguments? But that is invisible. Actually some > hundred of them are already visible. For each of them the compiler spits > some garbage error messages on you. But the right one you need is not > visible. Were was it declared? Was it declared anywhere? Have fun! You're confusing expensive *implicit* operations with expensive explicit ones. I don't care that an explicit type conversion is expensive -- you wrote it, you meant it, and you can see the consequences -- it's right there in the source code. You're right that you could use unary plus for this purpose -- a lot of people do -- but it's also considered an ugly hack. I would never use it to cover up expensive conversions -- I *want* those hard to write, so I only write them where absolutely necessary. And the use of "+" fills your program with ambiguity. OTOH, writing explicit conversions (or function calls with real names) does not have this problem. 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)); I've used the "+" trick here, but almost exclusively for literals (which should have been part of the type from the beginning). Randy.