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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,af3dada69080e420 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-25 11:58:03 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!fu-berlin.de!uni-berlin.de!dialin-145-254-042-032.arcor-ip.NET!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Interesting effects in array renaming Date: Wed, 25 Jun 2003 21:00:40 +0200 Organization: At home Message-ID: References: <3EF5E6B8.3030203@spam.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-042-032.arcor-ip.net (145.254.42.32) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: fu-berlin.de 1056567480 29039343 145.254.42.32 (16 [77047]) User-Agent: KNode/0.7.1 Xref: archiver1.google.com comp.lang.ada:39735 Date: 2003-06-25T21:00:40+02:00 List-Id: Georg Bauhaus wrote: > Dmitry A. Kazakov wrote: > : > : But the "usual" meaning of "renames" is: > : > : p : renames a; > > Opening the question of why theree is a subtype mentioned > in a renaming declaration. (Which I cannot answer, but I > find it consistent with other declarations, which involves > a subtypes name most of the times. Would you like > p: constant := a; ?) Not as a replacement to renaming, but probably as an enhancement towards type inference. It should have other semantics than renaming. It should create a new object if "a" is not constant in the context. Consider: procedure Foo (a : in out Apple) is p : constant := a; begin Eat (a); -- What happens with p? Compare it with looking at a first glance reasonable: p : constant Apple renames a; -- p view allows no changes on a But it is a bad idea, because the contract here can be easily violated through the aliased view. Aliasing is not much compatible with invariants. So we should not pretend them existing. Thus renaming should not only check whether the renamed object has the declared subtype, but also that this cannot be changed within the scope of the created view. For example: type Vary (I : Integer) record case I is ...; subtype Fixed is Vary (0); X : Vary := ...; Y : Fixed renames X; -- Illegal, one could change X.I in Y's scope. > :> Should renaming be for imposing constraints? > :> If I rename myself as Bouwhouws, that won't change me I think, > :> and it doesn't impose a constraint on me. > : > : It imposes a constraint on people calling you. > > I'd rather say it offers them the freedom to call me by that other > name, which additional freedom is not a constraint. The constraint is that when they say "Bouwhouws", they should mean you. If "Bouwhouws" has any additional meaning it should be applicable to you, or at least not insult you. Otherwise, other people may think silly things of you. This does not impose any constraint on you. It only requires that a name fits you. So it imposes a constraint on the view. > : Consider > : renaming Mr.Smith to Mrs.Smith. > > I think this is an example of changing the type (in some humans typing > scheme), or, if not, of changing the view, but _not_ the name, > which is "Smith". "Smith, come here, carry that chair!" My Webster says that a name is "a word or combination of words by which a person or thing is reqularly known". Anyway the point was that though applying Mrs. to Mr.Smith would not change Smith, it would definitely insult him. So is it worth to try? > : I give you another example. When you rename a routine: > : > : procedure Baz (A : Apple); > : procedure Foo (B : Apple) renames Baz; > : > : the compiler checks the specified parameter profile. According to your > : theory it should not. Indeed > : > : procedure Foo (B : Orange) renames Baz; > : > : by no means changes Baz. > > Well, if constraints and parameter profiles should get the same > treatment for reasons of consistency wrt to the criterion "checked" > in renaming declarations, then, have you checked the implications > of such a change? Technically I see no problems with additional subtype check. I cannot imagine any useful code which would rely on subtype violation in case of renaming. More interesting would be to allow "violating" the constraints in a consitent way. I.e. to allow: procedure Foo (B : Orange) renames Baz; and change the semantics of p : Orange renames a; by corresponding subtype conversions: procedure Foo (B : Orange) is -- generated by the compiler begin Baz (Apple (B)); end Foo; function Get_p return Orange is -- generated by the compiler begin return Orange (a); end Get_p; procedure Set_p (p : Orange) is -- generated by the compiler begin a := Apple (p); end Set_p; But that would be much too radical to many. > I can't do this but after reading Robert's comments, > I trust this has been considered, with the result known. > > I still think that a compiler warning will be useful. Better than nothing. Unfortunately it cannot be statically checked. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de