Re: Interesting effects in array renaming

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

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