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.198.210 with SMTP id je18mr105301wic.1.1366082144344; Mon, 15 Apr 2013 20:15:44 -0700 (PDT) MIME-Version: 1.0 Path: p18ni69727wiv.0!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!border4.nntp.ams.giganews.com!border2.nntp.ams.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!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: Tue, 9 Apr 2013 18:24:29 -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> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1365549872 31128 69.95.181.76 (9 Apr 2013 23:24:32 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 9 Apr 2013 23:24:32 +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-09T18:24:29-05:00 List-Id: "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. And you should never mix types. Since you seem to think that mixing types is a good thing, you need to find a language where that's possible. Ada is never going to be that language. ... > You will need explicit conversions wherever you use Get_Text: > > X : UTF8_String := Box.Get_Text; > > or > > Open (Box.Get_Text); You wouldn't have to in either of these cases (presuming that Open has a specific type). But of course you could get a type mismatch that way (it would be better when the tag is passed up, as accessibility is). But in general it's a good thing to specify your types, and you do that with explicit conversions. ... >> 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. > Anyway, if you know how to create such function, you make it class-wide. > If > you don't know, nobody knows. It must be overridden and the compiler tells > you so. There is simply no problem with that. Of course there is a problem with that -- if it takes more than a couple of hours to create those functions, you cannot write an extension in a working day (and anything else is too long). I agree that there's probably going to have to be one constructor function, but that's about all that can be tolerated. And, similarly, abstract routines can be tolerated only in very small doses -- no giant interfaces being inherited. .... >>> 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.) It cannot be the case that moving a program to a different compiler breaks a *correct* program simply because the new compiler now calls (or does not call) Adjust. We call this "performance incompability"; we can't change the language in such a way that the performance of existing programs is going to change a lot -- doing so has a serious potential for breakage (for instance, it might cause or expose a race condition). >>>>>> 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, I believe that one of the ACATS tests does exactly that. Sure seems like the Ada model includes that! 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. >>>>>> 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. (These are "immutably limited".) So the issue does not come up. Next question?? >>>>> 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. 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. (Certainly not for any commonly used operations, and the others ought to be class-wide anyway, stuff like Find_Token) You're going to write all-new implementations for each representation, there won't be anything worth inheriting. Randy.