Interesting effects in array renaming

Interesting effects in array renaming

[Dmitry A. Kazakov]

---------- test.adb
with Ada.Text_IO;  use Ada.Text_IO;

procedure Test is
   type Some_Array is array (Integer range <>) of Integer;

   procedure Foo (X : Some_Array) is
      subtype Constrained is Some_Array (1..X'Length);
      XX : Constrained renames X;
   begin
      Put_Line
      (  "XX'Range:"
      &  Integer'Image (XX'First)
      &  ".."
      &  Integer'Image (XX'Last)
      &  ", Constrained'Range:"
      &  Integer'Image (Constrained'First)
      &  ".."
      &  Integer'Image (Constrained'Last)
      );
   end Foo;

   Object : Some_Array (-3..2) := (-3, -2, -1, 0, 1, 2);
begin
   Foo (Object);
end Test;
---------- test.adb

Surprisingly the above produces different ranges for XX and its declared 
subtype. Isn't something wrong here?

I would expect either

1. XX'Range = Constrained'Range and indices are shifted

or

2. Raising Constraint_Error while renaming. How else could the compiler 
remove range checks for

X : Array_Subtype ...

for I in Array_Subtype'Range loop
   X (I) ...

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Interesting effects in array renaming

[Jeffrey Carter]

Dmitry A. Kazakov wrote:
> ---------- test.adb
> with Ada.Text_IO;  use Ada.Text_IO;
> 
> procedure Test is
>    type Some_Array is array (Integer range <>) of Integer;
> 
>    procedure Foo (X : Some_Array) is
>       subtype Constrained is Some_Array (1..X'Length);
>       XX : Constrained renames X;
>    begin
>       Put_Line
>       (  "XX'Range:"
>       &  Integer'Image (XX'First)
>       &  ".."
>       &  Integer'Image (XX'Last)
>       &  ", Constrained'Range:"
>       &  Integer'Image (Constrained'First)
>       &  ".."
>       &  Integer'Image (Constrained'Last)
>       );
>    end Foo;
> 
>    Object : Some_Array (-3..2) := (-3, -2, -1, 0, 1, 2);
> begin
>    Foo (Object);
> end Test;
> ---------- test.adb
> 
> Surprisingly the above produces different ranges for XX and its declared 
> subtype. Isn't something wrong here?

Note that you can also do

subtype Constrained is Some_Array (1..X'Length-1);

or

subtype Constrained is Some_Array (1..3);

with similar results. You can also do

XX : Some_Array renames X;

which perhaps demonstrates more clearly where the object's subtype comes 
from.

-- 
Jeff Carter
"English bed-wetting types."
Monty Python & the Holy Grail

Re: Interesting effects in array renaming

[Dmitry A. Kazakov]

Jeffrey Carter wrote:

> Dmitry A. Kazakov wrote:
>> ---------- test.adb
>> with Ada.Text_IO;  use Ada.Text_IO;
>> 
>> procedure Test is
>>    type Some_Array is array (Integer range <>) of Integer;
>> 
>>    procedure Foo (X : Some_Array) is
>>       subtype Constrained is Some_Array (1..X'Length);
>>       XX : Constrained renames X;
>>    begin
>>       Put_Line
>>       (  "XX'Range:"
>>       &  Integer'Image (XX'First)
>>       &  ".."
>>       &  Integer'Image (XX'Last)
>>       &  ", Constrained'Range:"
>>       &  Integer'Image (Constrained'First)
>>       &  ".."
>>       &  Integer'Image (Constrained'Last)
>>       );
>>    end Foo;
>> 
>>    Object : Some_Array (-3..2) := (-3, -2, -1, 0, 1, 2);
>> begin
>>    Foo (Object);
>> end Test;
>> ---------- test.adb
>> 
>> Surprisingly the above produces different ranges for XX and its declared
>> subtype. Isn't something wrong here?
> 
> Note that you can also do
> 
> subtype Constrained is Some_Array (1..X'Length-1);
> 
> or
> 
> subtype Constrained is Some_Array (1..3);
> 
> with similar results. You can also do
>
> XX : Some_Array renames X;
> 
> which perhaps demonstrates more clearly where the object's subtype comes
> from.

I see no link with subtypes. ARM clearly states: 8.5.1(6)

"... any constraint implied by the subtype_mark of the 
object_renaming_declaration is ingored)."

I.e. whatever subtype you, a programmer, might specify I, the compiler, will 
shamelessly ignore it!

How safe! Do you really think it is OK? Consider this:

X1 : Constrained := Constrained (X);
X2 : Constrained renames X;

What is OK here, that X1 and X2 have different constraints or that X2 is 
potentially invalid?

I see only two alternatives:

Either to add a dynamic semantics ensuring that the result of renaming is a 
valid object of the declared subtype. [X2 raises Constraint_Error if 
Constrained'Range /= X'Range]

Or [painful] to require X1 and X2 be same in all cases, and thus:

   XX : Some_Array renames X (X'First + 1 .. X'Last);

would have length different from X, so a new array dope has to be generated 
etc.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Interesting effects in array renaming

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: 
: "... any constraint implied by the subtype_mark of the 
: object_renaming_declaration is ingored)."
: 
: I.e. whatever subtype you, a programmer, might specify I, the compiler, will 
: shamelessly ignore it!
: 
: How safe! Do you really think it is OK? Consider this:
 [...]
: I see only two alternatives:
: 
: Either to add a dynamic semantics ensuring that the result of renaming is a 
: valid object of the declared subtype. [X2 raises Constraint_Error if 
: Constrained'Range /= X'Range]
 
I think the compiler could warn about possibly
"incompatible" constraints in a renaming declaration.

Have you written to the producers of your compiler?

Re: Interesting effects in array renaming

[Dmitry A. Kazakov]

Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> : 
> : "... any constraint implied by the subtype_mark of the
> : object_renaming_declaration is ingored)."
> : 
> : I.e. whatever subtype you, a programmer, might specify I, the compiler,
> : will shamelessly ignore it!
> : 
> : How safe! Do you really think it is OK? Consider this:
>  [...]
> : I see only two alternatives:
> : 
> : Either to add a dynamic semantics ensuring that the result of renaming
> : is a valid object of the declared subtype. [X2 raises Constraint_Error
> : if Constrained'Range /= X'Range]
>  
> I think the compiler could warn about possibly
> "incompatible" constraints in a renaming declaration.
> 
> Have you written to the producers of your compiler?

It is same in both GNAT and ObjectAda, but it is absolutely legal according 
to ARM. The problem is ARM itself. Which opens such a hole. What sense have 
our complains about buffer overruns in C/C++, in presense of this? It is 
also a range check optimization problem, because the compiler cannot rely 
on subtype information. Very bad.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Interesting effects in array renaming

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: It is same in both GNAT and ObjectAda, but it is absolutely legal according 
: to ARM. The problem is ARM itself. Which opens such a hole. What sense have 
: our complains about buffer overruns in C/C++, in presense of this? It is 
: also a range check optimization problem, because the compiler cannot rely 
: on subtype information. Very bad.

I don't think it is so bad, it is much more an issue of what
renaming means, maybe? Most prominently, you give another name
to an entity, you don't make a new entity. Why should the new
name denote an entity wich has its bounds changed, despite
being "just another name"?

-- georg

Re: Interesting effects in array renaming

[Robert I. Eachus]

Dmitry A. Kazakov wrote:

> I see no link with subtypes. ARM clearly states: 8.5.1(6)
> 
> "... any constraint implied by the subtype_mark of the 
> object_renaming_declaration is ingored)."
> 
> I.e. whatever subtype you, a programmer, might specify I, the compiler, will 
> shamelessly ignore it!
> 
> How safe! Do you really think it is OK? Consider this:

Let me give you a view into the the thinking behind this.  Renaming is 
just another way to create aliasing in Ada.  We couldn't do away with 
the aliasing provided by, for example, subprogram parameters, and all 
aliasing has the potential to create havoc.  The consensus was that Ada 
allows programmers to avoid aliasing, but it doesn't require programmers 
do so.

Why?  Because the havoc that can occur is only in the mind of the 
programmer.  There are a lot of validation tests that use aliasing to 
accomplish a particular purpose.  But the results of all those tests (at 
least in a conforming complier) is predictable.

The same applies in this case.  I often use aliasing "tricks" to make 
writing string handling code easier.  If a subprogam has a parameter say 
S: in String, you don't know that the S'First is 1.  But if you write: 
subtype S_String is String(1..S'Length); My_S: S_String renames S; now 
you can assume that the lower bound is 1.  But notice a detail here.  A 
renaming takes a subtype_mark rather than a subtype_indication.  In 
general when only a subtype mark is allowed in Ada, it indicates that 
what matters is the TYPE indicated by the subtype_mark.

In practice, I tend to write My_S: constant String(1..S'Length) := S; if 
that is what I want, because it also eliminates the possibility that S 
is passed by reference, and some other task modifies it.  But in general 
the question is how much (code and time) can I afford to spend making my 
library routine bulletproof.  Ada allows me to make that sort of 
tradeoff.

Also, it would seem to be a nice idea to either require that the 
constraints implied by subtype_mark in a renaming declaration be 
checked, or that the subtype_mark be a first named subtype.  The first 
doesn't work, because we already know that aliasing is going on. 
Checking the value at one point in time provides no real additional 
safety.  As for requiring the name be a first named subtype, I think 
that was in there at one point.  But it turned out to have problems, 
often the only subtype_mark available to you is an alias!  For example, 
renamings inside generics.  So this turns out to be one of those cases 
where Ada doesn't mandate good sense on the part of the programmer, and 
spends a lot of words covering all the different ways you MAY shoot 
yourself in the foot.

But as long as the semantics are defined, as I said way back at the top, 
the intended effect is the one in the programmers mind.  If that is not 
the required semantic effect, the programmer will be surprised. RM 
8.5.1(6) is pretty clear on what the programmer should expect: "An 
object_renaming_declaration declares a new view of the renamed object..."

If you expect a value conversion, sorry about that, what you get is a 
view conversion.  If you don't understand the difference between a value 
conversion and a view conversion, go reread RM 4.6.

Re: Interesting effects in array renaming

[Dmitry A. Kazakov]

Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> : It is same in both GNAT and ObjectAda, but it is absolutely legal
> : according to ARM. The problem is ARM itself. Which opens such a hole.
> : What sense have our complains about buffer overruns in C/C++, in
> : presense of this? It is also a range check optimization problem, because
> : the compiler cannot rely on subtype information. Very bad.
> 
> I don't think it is so bad, it is much more an issue of what
> renaming means, maybe?

No, it is an issue of which meaning has an explicit specifying of a subtype. 
I would not object if the syntax were:

X : renames Y;

But it isn't.

> Most prominently, you give another name
> to an entity, you don't make a new entity.

Really? To me a "view" is definitely an "entity". You probably mean that 
renaming should not create a new object. But it is no matter, imposing a 
constraint on an existing object does not change the object. It is merely a 
precondition.

> Why should the new
> name denote an entity wich has its bounds changed, despite
> being "just another name"?

The answer depends on whether bounds is a property of (1) a value or of (2) 
a type. For an unconstrained array type you have (1), for a constrained 
array [sub]type (2). So when you rename one to another you have a clash 
between (1) and (2). It has to be reconciled. In the example I gave

for I in Constrained'Range loop
   X2 (I) := 0;
end loop;

may raise Constraint_Error or else corrupt memory if range checks are 
suppressed. It is abolutely unacceptable. To put it in one sentence: either 
you change bounds or you check them.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Interesting effects in array renaming

[Dmitry A. Kazakov]

Robert I. Eachus wrote:

> Dmitry A. Kazakov wrote:
> 
>> I see no link with subtypes. ARM clearly states: 8.5.1(6)
>> 
>> "... any constraint implied by the subtype_mark of the
>> object_renaming_declaration is ingored)."
>> 
>> I.e. whatever subtype you, a programmer, might specify I, the compiler,
>> will shamelessly ignore it!
>> 
>> How safe! Do you really think it is OK? Consider this:
> 
> Let me give you a view into the the thinking behind this.  Renaming is
> just another way to create aliasing in Ada.  We couldn't do away with
> the aliasing provided by, for example, subprogram parameters, and all
> aliasing has the potential to create havoc.  The consensus was that Ada
> allows programmers to avoid aliasing, but it doesn't require programmers
> do so.
> 
> Why?  Because the havoc that can occur is only in the mind of the
> programmer.  There are a lot of validation tests that use aliasing to
> accomplish a particular purpose.  But the results of all those tests (at
> least in a conforming complier) is predictable.
> 
> The same applies in this case.  I often use aliasing "tricks" to make
> writing string handling code easier.  If a subprogam has a parameter say
> S: in String, you don't know that the S'First is 1.  But if you write:
> subtype S_String is String(1..S'Length); My_S: S_String renames S; now
> you can assume that the lower bound is 1.

(?) You mean that I cannot, because My_S'First = S'First.

> But notice a detail here.  A
> renaming takes a subtype_mark rather than a subtype_indication.  In
> general when only a subtype mark is allowed in Ada, it indicates that
> what matters is the TYPE indicated by the subtype_mark.

Oh yes, ARM consistently states inconsistent things! (:-))
 
> In practice, I tend to write My_S: constant String(1..S'Length) := S; if
> that is what I want, because it also eliminates the possibility that S
> is passed by reference,

I usually declare a nested subprogram which takes S_String and does the 
things.

> and some other task modifies it.

I would not rely on it.

> But in general
> the question is how much (code and time) can I afford to spend making my
> library routine bulletproof.  Ada allows me to make that sort of
> tradeoff.
> 
> Also, it would seem to be a nice idea to either require that the
> constraints implied by subtype_mark in a renaming declaration be
> checked, or that the subtype_mark be a first named subtype.  The first
> doesn't work, because we already know that aliasing is going on.
> Checking the value at one point in time provides no real additional
> safety.

It povides additional safety for the reader of a program. [Isn't a goal Ada 
design?] It would allow to omit range checks many cases like:

procedure Sum (L : in out Vector; R : Vector) is
   subtype Of_L is Vector (L'Range);
   RR : Of_L renames R; -- Checked here
begin
   for I in L'Range loop
      L (I) := L (I) + RR (I); -- No range check needed

Far clearer than the trick with a nested subprogram:

procedure Sum (L : in out Vector; R : Vector) is
   subtype Of_L is Vector (L'Range);
   procedure Do_Sum (LL : in out Of_L; RR : Of_L) is
   begin
      for I in Of_L'Range loop
         LL (I) := LL (I) + RR (I); -- No range check needed
      end loop;
   end Do_Sum;
begin
   Do_Sum (L, R);

Presently Ada has no easy way to help the compiler in optimizing programs 
like above. Perhaps it will be achieved with preconditions if they at last 
appear in Ada. But even then I would expect:

X : S renames Y;

be equivalent to

ensure Y in S;
X : S renames Y;

> As for requiring the name be a first named subtype, I think
> that was in there at one point.  But it turned out to have problems,
> often the only subtype_mark available to you is an alias!  For example,
> renamings inside generics.  So this turns out to be one of those cases
> where Ada doesn't mandate good sense on the part of the programmer, and
> spends a lot of words covering all the different ways you MAY shoot
> yourself in the foot.
> 
> But as long as the semantics are defined, as I said way back at the top,
> the intended effect is the one in the programmers mind.  If that is not
> the required semantic effect, the programmer will be surprised. RM
> 8.5.1(6) is pretty clear on what the programmer should expect: "An
> object_renaming_declaration declares a new view of the renamed object..."

That the new view is wellcome to be inconsistent does not follow from that. 
It is written pair lines below. BTW, for tagged types it is different and 
semantically consistent:

procedure Foo (X : Base'Class) is
   XX : Derived renames X;           -- Illegal
   XX : Derived renames Derived (X); -- Legal and *CHECKED*

> If you expect a value conversion, sorry about that, what you get is a
> view conversion.  If you don't understand the difference between a value
> conversion and a view conversion, go reread RM 4.6.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Interesting effects in array renaming

[Lutz Donnerhacke]

* Dmitry A. Kazakov wrote:
> It povides additional safety for the reader of a program. [Isn't a goal Ada 
> design?] It would allow to omit range checks many cases like:
> 
> procedure Sum (L : in out Vector; R : Vector) is
>    subtype Of_L is Vector (L'Range);
>    RR : Of_L renames R; -- Checked here
> begin
>    for I in L'Range loop
>       L (I) := L (I) + RR (I); -- No range check needed

Currently this is not the case:

$ cat > test.adb <<END
procedure Test is
   type Vector is array (Integer range <>) of Integer;

   procedure Sum (L : in out Vector; R : Vector) is
      subtype Of_L is Vector (L'Range);
      RR : Of_L renames R; -- Checked here
   begin
      for I in L'Range loop
	 L (I) := L (I) + RR (I); -- No range check needed
      end loop;
   end Sum;
   
   a : Vector := (4 .. 10 => 4);
   b : Vector := (1, 2, 3);
begin
   Sum(a, b);
end Test;
END
$ gnatmake test
gcc -c test.adb
gnatbind -x test.ali
gnatlink test.ali
gnatlink: warning: executable name "test" may conflict with shell command
$ ./test
raised CONSTRAINT_ERROR : test.adb:10
$ sed -n 10p test.adb
         L (I) := L (I) + RR (I); -- No range check needed
$ _

Re: Interesting effects in array renaming

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: That the new view is wellcome to be inconsistent does not follow from that. 
: It is written pair lines below. BTW, for tagged types it is different and 
: semantically consistent:
: 
: procedure Foo (X : Base'Class) is
:   XX : Derived renames X;           -- Illegal
:   XX : Derived renames Derived (X); -- Legal and *CHECKED*

I'm not sure, considering

   procedure Foo (X : in out Varying'Class) is
      subtype Nono is Changeant (false);
      X1 : Changeant renames X;           -- Illegal
      X2 : Nono renames Changeant(X); -- Legal and *CHECKED*
   begin
      X2.messy := 2 * X2.messy; 
	-- constraint_error when discriminant is true
   end Foo;
 
where
package Derivs is

   type Varying (special: Boolean)
   is
     tagged record
        comp: Natural;
     end record;


   type Changeant (very_special: Boolean)
   is
     new Varying(very_special) with
      record
         case very_special is
            when true =>
               another: Boolean;
            when false =>
               messy: Integer;
         end case;
      end record;


end Derivs;


-- Georg

Re: Interesting effects in array renaming

[Dmitry A. Kazakov]

Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> : That the new view is wellcome to be inconsistent does not follow from
> : that. It is written pair lines below. BTW, for tagged types it is
> : different and semantically consistent:
> : 
> : procedure Foo (X : Base'Class) is
> :   XX : Derived renames X;           -- Illegal
> :   XX : Derived renames Derived (X); -- Legal and *CHECKED*
> 
> I'm not sure, considering
> 
>    procedure Foo (X : in out Varying'Class) is
>       subtype Nono is Changeant (false);
>       X1 : Changeant renames X;           -- Illegal
>       X2 : Nono renames Changeant(X); -- Legal and *CHECKED*

You could make it even more scandalous:

   X2 : Nono renames Nono(X); -- !!!No discriminant checks!!!

>    begin
>       X2.messy := 2 * X2.messy;
> -- constraint_error when discriminant is true
>    end Foo;
>  
> where
> package Derivs is
> 
>    type Varying (special: Boolean)
>    is
>      tagged record
>         comp: Natural;
>      end record;
>
>    type Changeant (very_special: Boolean)
>    is
>      new Varying(very_special) with
>       record
>          case very_special is
>             when true =>
>                another: Boolean;
>             when false =>
>                messy: Integer;
>          end case;
>       end record; 
> end Derivs;

Clarification: I meant tags, not discriminants (of possibly tagged types). 
What happens in your example, is the following. Nono has two constraints:

1. The discriminant very_special => False
2. The tag => Changeant'Tag (viewed as a constraint for any of the classes: 
Varying'Class, Changeant'Class)

When you rename X, the constraint 2 is checked. The constraint 1 is silently 
ignored as ARM requires.

Here we are. Now, convince me that it is GOOD.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Interesting effects in array renaming

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: Georg Bauhaus wrote:
: 
:> I don't think it is so bad, it is much more an issue of what
:> renaming means, maybe?
: 
: No, it is an issue of which meaning has an explicit specifying of a subtype. 

Hm. 

  procedure foo(a: Apple) is
     p: Orange renames a;

may be correct, but confusing. Because, in my view a least, the
programmer is violating the usual meaning of "renames".
I think the bias is towards the wrong side/word if "Orange"
outweighs "renames".


:> Most prominently, you give another name
:> to an entity, you don't make a new entity.
: 
: Really? To me a "view" is definitely an "entity". You probably mean that 
: renaming should not create a new object.

Yes.

: But it is no matter, imposing a 
: constraint on an existing object does not change the object. It is merely a 
: precondition.

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. That's renaming for me.
It won't even change the sound of my name ;-)

: for I in Constrained'Range loop
:   X2 (I) := 0;
: end loop;
: 
: may raise Constraint_Error or else corrupt memory if range checks are 
: suppressed. It is abolutely unacceptable. To put it in one sentence: either 
: you change bounds or you check them.

But if you declare a subtype with constraints to be used in a renaming
declaration, then you know the constraints. You also know the bounds of
objects involved, by way of attributes. So you could make your intention
more explicit by using these known quantities if you want to avoid
copying.


-- sb463ba

Re: Interesting effects in array renaming

[Dmitry A. Kazakov]

Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> : Georg Bauhaus wrote:
> : 
> :> I don't think it is so bad, it is much more an issue of what
> :> renaming means, maybe?
> : 
> : No, it is an issue of which meaning has an explicit specifying of a
> : subtype.
> 
> Hm.
> 
>   procedure foo(a: Apple) is
>      p: Orange renames a;
> 
> may be correct, but confusing. Because, in my view a least, the
> programmer is violating the usual meaning of "renames".

But the "usual" meaning of "renames" is:

   p : renames a;

What meaning has Orange in renaming? Just a buzz word? Then I would propose 
to change the syntax to

   p: Orange or else renames a;

It would perfecly reflect the present semantics! (:-))

What I want is:

   p: Orange and then renames a;

> : But it is no matter, imposing a
> : constraint on an existing object does not change the object. It is
> : merely a precondition.
> 
> 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. That is the point. Consider 
renaming Mr.Smith to Mrs.Smith. Authorities in most contries would object, 
even if Mr.Smith had undergone a surgery. [Though, I could have missed the 
recent advances in "poltical correctness" and could be wrong] (:-))

> That's renaming for me.
> It won't even change the sound of my name ;-)

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.

> : for I in Constrained'Range loop
> :   X2 (I) := 0;
> : end loop;
> : 
> : may raise Constraint_Error or else corrupt memory if range checks are
> : suppressed. It is abolutely unacceptable. To put it in one sentence:
> : either you change bounds or you check them.
> 
> But if you declare a subtype with constraints to be used in a renaming
> declaration, then you know the constraints. You also know the bounds of
> objects involved, by way of attributes. So you could make your intention
> more explicit by using these known quantities if you want to avoid
> copying.

Oh, that's is the very C++ ideology to me:

"Wished it? Take it, idiot!" (:-))

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Interesting effects in array renaming

[Georg Bauhaus]

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

Re: Interesting effects in array renaming

[Dmitry A. Kazakov]

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

Re: Interesting effects in array renaming

[Randy Brukardt]

Dmitry A. Kazakov wrote in message ...
>Here we are. Now, convince me that it is GOOD.


I doubt anyone could do that, for the simple reason that you're right.
But there are a number of things about Ada that are wrong (the inability
to use "in out" parameters on functions is the most obvious to me), but
they're not going to be changed because of compatibility and/or
political reasons. That's the nature of the beast -- you'll never get
everything you want (or even close to it) -- and in total that might be
a good thing.

In the case of the renames, that would substantially change the
semantics of existing programs, both for renames themselves and for
generic in out parameters (which are defined in terms of renames). It
would be too much of a change - a lot of existing code would fail.

I find cases where the political process prevents needed fixes (like the
'in out' parameters on functions issue) much more annoying. At least in
the cases of compatibility, you can convince yourself that there really
is no choice...

                 Randy.

Re: Interesting effects in array renaming

[Vinzent Hoefler]

Randy Brukardt wrote:

>But there are a number of things about Ada that are wrong (the inability
>to use "in out" parameters on functions is the most obvious to me),

In fact the idea that a function shall have no (or at least very
limited) side effects is a quite good one. Well, you still can use
global variables or access-Parameters to circumvent this restriction,
so perhaps one can consider it as rather inconsequential, but wrong?
No, I don't think so.


Vinzent.

Re: Interesting effects in array renaming

[Georg Bauhaus]

Vinzent Hoefler <ada.rocks@jlfencey.com> wrote:
: Randy Brukardt wrote:
: 
:>But there are a number of things about Ada that are wrong (the inability
:>to use "in out" parameters on functions is the most obvious to me),
: 
: In fact the idea that a function shall have no (or at least very
                       pure
: limited) side effects is a quite good one.

Image the name of the beast wasn't function.

Re: Interesting effects in array renaming

[Vinzent Hoefler]

Georg Bauhaus wrote:

>Vinzent Hoefler <ada.rocks@jlfencey.com> wrote:
>: Randy Brukardt wrote:
>: 
>:>But there are a number of things about Ada that are wrong (the inability
>:>to use "in out" parameters on functions is the most obvious to me),
>: 
>: In fact the idea that a function shall have no (or at least very
>                       pure
>: limited) side effects is a quite good one.
>
>Image the name of the beast wasn't function.

Well, I was thinking of VHDL and there exists the concept of pure and
impure functions. "pure" says, regardless of what happens, this
function will *always* return the same value for the same parameter
set with which it is called, but the "impure" function might read some
signal, so its return value might be different from the previous even
when called with the same parameters.

So i.e. SPARK's functions that should be free of side effects, are
really the equivalent to VHDL's _im_pure function like this one:

|impure function Check_Signal (Signal : Std_Logic) return Std_Logic is
|begin
|   return Global_State xor Signal;
|end Check_Signal;

So, no. A pure function (in a more mathematical sense) was not what I
was talking about.
Impure functions look ok for me, but they still shouldn't be able to
change their parameters or (more generally) the state of the system.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.