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,a41c4a2c795dbe34 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,UTF8 Path: g2news1.google.com!news3.google.com!feeder.news-service.com!94.75.214.39.MISMATCH!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Will "renames" increase program size? Date: Thu, 16 Jun 2011 10:59:31 +0200 Organization: cbb software GmbH Message-ID: References: <46294109-f07d-49c0-8e81-65a369a05ced@z15g2000prn.googlegroups.com> <1ayjsy885qg2b$.13bmeo97hbau1$.dlg@40tude.net> <316ac8ed-1ded-43d0-98d1-36bb2c0221ad@f2g2000yqh.googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: g2news1.google.com comp.lang.ada:19868 Date: 2011-06-16T10:59:31+02:00 List-Id: On Wed, 15 Jun 2011 23:59:35 -0700 (PDT), AdaMagica wrote: > On 15 Jun., 15:15, "Dmitry A. Kazakov" > wrote: >> On Wed, 15 Jun 2011 13:24:52 +0200, Yannick Duchêne (Hibou57) wrote: >>> Le Wed, 15 Jun 2011 07:37:22 +0200, Randy Brukardt   >>> a écrit: >>>> Some examples where there probably would be some overhead: >> >>>>              Obj : Natural renames My_Array (Some_Variable).all; >>>>              Obj2 : Float renames Some_Function (A, B); >> >>> Yes, because this is more an aliasing (in the symbolic sense) than a   >>> proper renaming. >> >> Yes, Ada's renaming is not renaming. Consider this: >> >>    Line : String renames Get_Line; >> >> It calls Get_Line once and keeps the result object. In fact it is an >> equivalent to: >> >>     : constant String := Get_Line; >>    Line : properly renames ; >> >> Consider also the effect of renaming on the visibility rules: >> >>    package P1 is >>       End_Error : exception renames Ada.Text_IO.End_Error; >>    end P1; >>    package P2 is >>       End_Error : exception renames Ada.Text_IO.End_Error; >>    end P2; >>    use P1, P2; >> >>    exception >>       when End_Error => -- End_Error is hidden! >> >> Ada's "renames" does not rename here, it copies, creates objects. There are >> three End_Error here, all of them are equal, but not same: >> >> exception >>    when Ada.Text_IO.End_Error => >>       ... >>    when P1.End_Error => -- Error! P1.End_Error has the same value >>       ... >>    when P2.End_Error => >>       ... >> >> A proper renaming would create identical (x≡y) entities, Ada's renaming >> sometimes creates only equal ones (x=y). >> >> -- >> Regards, >> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de > > That's not correct. A renaming does not copy nor somehow create new > entities, it only creates new names for the same thing. Since > visibility is via names, you arrive at unresolvability issues. No. First, sometimes it certainly copies, e.g. when the function's result is renamed, the result (temporary object) is copied. The compiler might optimize the temporary object away, or even mandated to do so for limited results, but *semantically* it is a copy. Compare it with array indexing, which is a properly renamed result, as a lazy expression or using aliasing. The wisdom of allowing renaming function results is questionable, but if allowed it should be lazy. Laziness could also solve this disgrace of Ada's renaming: with Ada.Text_IO; use Ada.Text_IO; procedure Shame is type T is array (Integer range <>) of Integer; A : T := (0 => 0, 1 => 1); subtype S is T (1..2); B : S renames A; begin Put_Line (Integer'Image (B (0))); -- Surprise, 0 is a legal index of S! end Shame; Regarding the visibility rules, the design bug is that the new name of a thing shall not hide any other names of it in any context. In the example above P1.End_Error should not have hidden P2.End_Error. (I don't know why this has not been fixed long time ago, because it would be a really minor language change, which would not break any existing code). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de