From mboxrd@z Thu Jan 1 00:00:00 1970 Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Blady Newsgroups: comp.lang.ada Subject: Re: Renaming primitives. Date: Fri, 12 Jan 2024 11:29:40 +0100 Organization: A noiseless patient Spider Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 12 Jan 2024 10:29:41 -0000 (UTC) Injection-Info: dont-email.me; posting-host="dc21db9e1065c4542d0bf5ec17bc6141"; logging-data="3607643"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+jM7o0roL4W/gnCNeKqAdv" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:1J3q/akuiO4rrnJTNRCOIC+hM1k= In-Reply-To: Content-Language: fr, en-US Xref: news.eternal-september.org comp.lang.ada:65989 List-Id: Le 12/01/2024 à 04:59, Randy Brukardt a écrit : > "Blady" wrote in message > news:unoep3$2uqo6$2@dont-email.me... >> Le 11/01/2024 à 03:18, Randy Brukardt a écrit : >>> "Blady" wrote in message >>> news:unls1j$2f0up$3@dont-email.me... >>>> Is a procedure renaming equivalent to a simple call? >>> >>> General point: "Equivalent" is never true in programming language design. >>> If >>> construct A is equivalent in every way to construct B, then they have to >>> be >>> the same construct. >>> >>> For instance, in your example below, the two subprogram declarations have >>> different identifiers which have different visibility (two declarations >>> cannot be at exactly the same place), so there is at least one way that >>> they're not equivalent. >>> >>> So, if you want to talk about "equivalence", you need to qualify that by >>> what properties you are interested in. >> >> Well, I hadn't find a better word :-( > > You have to say something like "equivalent in run-time behavior"; > "equivalent" by itself is always False. Thanks, I like it. >>> ... >>>> What is happening if My_Generic_Handler change? >>> >>> Nothing. The names in a renaming are evaluated when the renaming is >>> declared. If there are parts that could change, the compiler has to save >>> the >>> values at the point of the renaming. That's true for all forms of >>> renaming >>> (some names, like package names, can't change meaning so the example >>> isn't >>> possible, of course). >> >> Yet, the code: >> My_Log_3 ("Hei"); >> My_Generic_Handler := My_Full_Handler'Access; >> My_Log_3 ("Hei"); >> gives: >> Hei >> Full Hei >> >> I thought that was correct, wasn't it? > > Shouldn't be correct. The "name" is evaluated during a renaming, and the > renamed entity does not change afterwards. So whatever subprogram My_Log_3 > designates for the first call should be the same for the second call. > >> GNAT issue ? > > Appears to be (of course, without seeing the full code I can't say > definitively; people here often post snippets that aren't quite the same as > the actual code they tried to run. I wouldn't expect that with you, but we > all make mistakes. :-). I quote you :-) and attached the full source code. You might follow or comment on the created issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113350