Re: Interesting effects in array renaming

[Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de>]

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; ?)
 
:> 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.

: 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!"

: 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? 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.


-- georg