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 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.198.210 with SMTP id je18mr90478wic.1.1366081050949; Mon, 15 Apr 2013 19:57:30 -0700 (PDT) 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!weretis.net!feeder4.news.weretis.net!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!gegeweb.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Is this expected behavior or not Date: Wed, 10 Apr 2013 10:20:46 +0200 Organization: cbb software GmbH Message-ID: <8bj2k30k7i19.w7ehsldwbf7x.dlg@40tude.net> 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> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2013-04-10T10:20:46+02:00 List-Id: On Tue, 9 Apr 2013 18:24:29 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:igo6blwn0oas$.wifvpq91hm9m.dlg@40tude.net... >> On Fri, 5 Apr 2013 20:20:58 -0500, Randy Brukardt wrote: > ... >> You conflate type checking with representation checking. There is no need >> to check how a string is represented. > > That's because they're intimately linked. You can't do an operation without > knowing how the type is represented. That does not explain why representation needs to be checked. Especially for the types like Boolean and Integer. >>> Well, I have. As I previously explained, the abstract routines and functions >>> in the Claw Builder root types make it so time-consuming to create an >>> extension (the last one I did took around 20 hours to write, and even >>> then I never finished it) that it's impractical to do so. >>> >>> If you have only one such routine, >> >> 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? >>>> 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. >>>>>>> It strikes me that the model of stripping tags means that type conversion >>>>>>> of an object to a class-wide type would effectively change the tag (if the >>>>>>> routine was inherited or called by a conversion of an operand). >>>>>> >>>>>> Yes, re-dispatch is a broken thing. Don't do it, because it is ambiguous >>>>>> in general case when objects do not have an identity. By-copy scalar >>>>>> types are such things. There is nothing which could distinguish Integer 13 >>>>>> from Long_Integer 13 except the context. Once you dispatched that >>>>>> information is lost. There is no way back. >>> >>> Here you are saying that you can't redispatch because you insist on a >>> model that doesn't allow it. >> >> No model exist which would allow re-dispatch on scalar value. Like no >> model exist where 2+2=5. > > Gee, you can easily redefine "+" in Ada so that 2 + 2 = 5 -- indeed, Then don't expect arithmetic to work. There is a price for each wrong decision. > I have an tagged universal numeric type implementation, and it certainly > allows redispatch. It's not much of a leap to think of it as a scalar type. It is a huge leap, it is from semantically right to wrong. Scalar objects do not have identity, which is a fundamental properly of. Pretty much is based on lack of identity, these properties allow vital program analysis, transformations, e.g. optimization etc. The major flaw of OOPL is an attempt to hand identity on all types. This is simply impossible to do. This is why all of them, including Ada, have types which are more types then others. >>>>>>> That would >>>>>>> mean that the behavior of such a conversion would be very different >>>>>>> for an untagged type and for a tagged type. >>>>>> >>>>>> Not different. It is just so that tagged types per design have type >>>>>> identity. Other types simply don't have it. >>>>> >>>>> Objects of limited types are always assumed to have an identity; >>>> >>>> No. E.g. task and protected types lack type identity. Only tagged types >>>> have type identity. >>>> >>>> Note that type identity /= object identity (e.g. machine address where >>>> the object resides). >>> >>> I don't think that they ought to be separated. If you have object identity, >>> and every object has a nominal type, it does not make sense to lose that >>> information. >> >> Nothing is lost. You forgot that the parameter was passed by copy, as >> required by the type, which was by-copy. It is another object in there. >> Its identity is obviously not the identity of the origin. How could it be >> otherwise? > > You can't pass types with object identity by-copy. And untagged by-copy types will have none, per design. >>>>>> You want to derive each string type straight from Root_String. >>>>> >>>>> Yes, or from related ones. There is no significant value to doing anything >>>>> else - as you point out, if you can inherit the operations, the >>>>> representations have to be compatible. So there is nothing useful you >>>>> can do with multiple levels. >>>> >>>> Encoding! >>> >>> You have to reimplement *every* operation for a new representation (in >>> your model as well as in existing Ada). >> >> Most bodies will be inherited per composition with conversion. > > I forget that you seem to think that compilers will magically be able to > implement this stuff as if you wrote it by hand. Not at all. The conversion will be provided by the programmer. If he did not define one, he will be required to override things manually. > 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! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de