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: 103376,9fb8e2af320d5b3e X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Bus error Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <0367891DA5DA7E408D42A860FA002F44B0CC48@sma2901.cr.eurocopter.corp> <1l4yqvxoid4n1.1u8eo4oo8ml4m$.dlg@40tude.net> <4685280c$0$14869$9b4e6d93@newsspool4.arcor-online.net> Date: Sat, 30 Jun 2007 10:44:12 +0200 Message-ID: NNTP-Posting-Date: 30 Jun 2007 10:43:31 CEST NNTP-Posting-Host: 57b781de.newsspool2.arcor-online.net X-Trace: DXC=3L_YQJ\N>0c;iVb[J9ZZP`A9EHlD;3Ycb4Fo<]lROoRa8kF057mHiiWoJ613BN@a X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:16349 Date: 2007-06-30T10:43:31+02:00 List-Id: On Fri, 29 Jun 2007 21:37:43 -0400, Robert A Duff wrote: > "Dmitry A. Kazakov" writes: > >>...It creates new objects, > > Heh? Renaming does not create new objects. > A function call creates a new object, but that's a > different story. And it's a good thing -- that function-result > object might need to be finalized, which means it has to be > an object (not just a value). The language misguiding the programmer here. He should declare an initialized constant when a function result is "renamed," it is not renaming, At least it is not just renaming happens here. If you have X1 : String renames Get_Line; X2 : String renames Get_Line; X3 : String renames Get_Line; the effect will be X1, X2, X3 all different objects. This should not be called renaming. Same is implementation of subprograms through renaming, which also creates a new object. But when I do: X : Element renames Collection (Key); I'd like to be certain that X indeed renames a container's element. > If I ran the circus, literals would "return" objects, too. > And there would be no syntactic distinction betweem "name" > and "expression". Sign me up! >>... it violates >> contracts, > > Not sure what you mean there. I guess the fact that constraints on T > are ignored, above. If so, it doesn't violate any contract, so long as > you understand that "X: Positive renames..." is not a contract requiring > positive numbers. ;-) (:-)) The problem is then, what the meaning has the subtype specification in renaming? Nobody would object if renaming were: This : renames That; -- Guess what is the subtype and constraints Interestingly, but the "constant" (in/out/in out) constraint indeed need not to and cannot be specified in renaming: X : Integer renames Y; So whatever naive theory we'd invent Ada's renaming conforms to neither. >>...it introduces names conflicts. > > Yes. We considered fixing that during Ada 9X. But not 200X? > Here's another small complaint about renaming: It's often used as an > "import", as in: > > function Blah (...) return ... renames Some.Library.Package.Blah; Yep, and the diamond diagram: package A is X : T; end A; with A; package B is X : T renames A.X; end B; with A; package C is X : T renames A.X; end C; with B, C; use B, C; package D is -- X is hidden end D; > We do not wish to change the name of Blah, just to import it into > another scope. But mentioning Blah twice is error-prone in that > context. The programmer really wants to say something like > "import Blah from Some.Library.Package". Consider: > > function "+"(...) return ... renames Some_Package."+"; > function "-"(...) return ... renames Some_Package."+"; > > Note cut&paste error on second line. Yes, there is no mechanism to merge declaration parts of packages. IMO there should be some way to import things of one package specification into another without tedious renamings, especially, without renaming things which cannot be renamed at all, like types. But I don't think that renaming should be used for that. I would prefer multiple parent packages and something for flattening nested and separate packages: package My_IO is ... with new Ada.Text_IO.Integer_IO (...); -- Merge all declarations from this instance with My_Io's public -- and private parts ---------------- There are three separate issues too difficult to handle by just one construct: 1. Renaming of objects 2. Operations on packages specification 3. Delegation -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de