Re: Interesting effects in array renaming

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> 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