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,a41c4a2c795dbe34 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!feeder.erje.net!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!jacob-sparre.dk!ada-dk.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Will "renames" increase program size? Date: Sat, 18 Jun 2011 17:44:38 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <46294109-f07d-49c0-8e81-65a369a05ced@z15g2000prn.googlegroups.com> <1ayjsy885qg2b$.13bmeo97hbau1$.dlg@40tude.net> <316ac8ed-1ded-43d0-98d1-36bb2c0221ad@f2g2000yqh.googlegroups.com> <2e8222df-9b82-497f-9dc4-5cb0d5653550@f31g2000pri.googlegroups.com> <1t5j5p8gurul3$.k4cq2qnsbbjb.dlg@40tude.net> <12lr1j2mmzidu.18gjo4p3e73kk$.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1308437081 11021 69.95.181.76 (18 Jun 2011 22:44:41 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sat, 18 Jun 2011 22:44:41 +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.6090 Xref: g2news1.google.com comp.lang.ada:19958 Date: 2011-06-18T17:44:38-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:c8ynrt1qxx83.1vaqckntoa8r5$.dlg@40tude.net... > On Fri, 17 Jun 2011 19:02:49 -0500, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" wrote in message >> news:12lr1j2mmzidu.18gjo4p3e73kk$.dlg@40tude.net... >>> On Thu, 16 Jun 2011 18:39:35 -0500, Randy Brukardt wrote: >>> >>>>>Semantically returning result of a function is always copying because >>>>>the >>>>>object being returned changes the scope. >>>> >>>> "Changing scope" doesn't require a copy in either RM or some sort of >>>> outside >>>> logical universe. The only thing that the "scope" of an object controls >>>> is >>>> when it is finalized, and that has nothing to do with the contents >>>> (from a >>>> logical perspective) of the object. >>> >>> I fail to see how finalization could have nothing to do with the >>> contents. >>> Finalized objects have no contents, they do not even exist. >> >> Sorry, you need the read the RM again. Finalization is a process that >> happens on objects that exist, and it has no effect on whether they exist >> or >> not. Typically, they cease to exist later (how much later depends on >> where >> they are declared). > > Semantically finalized [typed] object does not exist. Object /= memory > allocated for it. It does in RM terms. If you want to invent notions other than those in the RM, that's fine, but please label them as such. (Then I know I can ignore them.) The most important thing for the definition of a programming language is to have a logically complete and consistent definition. It does not matter (at least in the abstract) if that definition is the same as you might expect. The English meaning of "exist" is much broader than the Ada technical meaning, and I couldn't even hazard a guess what meaning might make sense for a programming language. ... >> Last I recall, we were talking about renames, which never copy anything. > > Some renames copy, some do not. Consider this example: > > type T is new Ada.Finalization.Controlled ...; > function Foo return T; > > X : T renames Foo; > > Does this copy? The renames never copies. We're not talking about what the function call might do, that is something completely separate (and irrelevant as to what the renames does). A function call might or might not copy its result, and the context it calls in does not matter (at least in most implementations). > It seems that according to you, you cannot tell without > looking into the body of Foo: > > function Foo return T is -- This copies > Result : T; > begin > return T; > end Foo; > > function Foo return T is -- This does not copy > begin > return Result : T; > end Foo; No, the semantics of both of these return statements is identical. The truth is that you can *never* tell, and you should never write your code so it cares. > Implementation-dependent semantics is not that good idea. So you would prefer that Ada is Java, with only one possible set of representations for numbers. Because whether or not a compiler supports a 24-bit integer is implementation-defined, and that is not a good idea... > In my view any function always copies no matter what. Even when no Adjust > is called because it happened that the object created for rename shared > the > memory with the function result. Even if it was inlined and optimized away > completely, semantically, it is still a copy. Have any view you like, but it has nothing to do with the definition of Ada. > That Ada's designer possibly thought otherwise, constitutes, in my > opinion, > a language design bug (e.g. bogus limited-valued functions). > >> Don't recall any discussion whatsoever about parameter passing. But if >> parameter passing does in fact do a copy, then there is a semantic effect >> (on aliasing at the very least). > > No, because an attempt to exploit this effect is an error. Semantics does > not apply to erroneous programs, which is after all, why they are > erroneous. Sorry, but "aliasing" is not an error, and does not (usually) make a program erroreous). Oh, that's right, you are ignoring the RM definitions of everything, so you clearly have this wrong, too. :-) >> It's pretty hard to do anything in a language definition without there >> being >> a semantic effect. Even when you think there isn't one, clever people >> like >> Adam and Steve Baird will show you one in some convoluted case. (Steve >> was >> just bending my ear about 'Unchecked_Access causing overhead when used to >> return an object of a local tagged type.) > > One might need to generate some code in order to ensure *absence* of any > semantic effect. > > P.S. It seems that you use the word "semantic" as an equivalent to "code" > (a meaning to the machine). I used it as a meaning to the programmer. Not at all; I don't know where or why you would think that. In any case, it doesn't matter; I'm leaving soon for the upcoming meetings, and I have to get ready to go, so this discussion is going to stop here. And it's obvious that I'm completely wasting my time with you -- you're smart and clever enough to be a valuable resource vis-a-vis design and correction of the language -- but if you won't even try to use the terminology correctly, you're never going to provide any value because I'll never be able to tell if you are talking about a real problem or one that exists only in your head. Randy.