Re: Proposal: Auto-allocation of Indefinite Objects

[Brian Drummond <brian@shapes.demon.co.uk>]

On Mon, 27 Jul 2020 22:02:57 +0200, Dmitry A. Kazakov wrote:

> On 27/07/2020 19:48, Brian Drummond wrote:
> 
>> 2) can be implemented internally using pointers, but externally appears
>> to be a data object, just like Unbounded_String does, with similar
>> semantics.
> 
> No, the point is that Unbounded_String is exactly opposite to what is
> required. In no case it should appear as an object of a different type!
> 
> Compare access to string P with unbounded string U:
> 
>     for I in P'Range loop -- This is OK 
>        P(J) := 'a' -- This is OK
> 
> Now would you do:
> 
>     To_String (U) (J) := 'a' -- Garbage!

That wasn't the aspect of Unbounded I was getting at. I agree ... garbage.

What I meant was that Unbounded doesn't load New, dereferencing, 
deallocation etc onto the programmer, but hides the access details, and 
our indefinite type should do the same (the compiler can probably to a 
better job than the programmer anyway).

I'm suggesting something more like the C++ reference, signalling (perhaps 
by adding a reserved word "indefinite") that fixed size allocation won't 
work; and implementation is more in line with a controlled type but with 
system-provided Initialise,Adjust,Finalize providing the required 
operations (no need for the programmer to provide them).

A : String := "hello" -- a definite string
P : access String := new String'("hello");
Q : indefinite String := "hello";

... 
   begin
     for I in P'Range loop -- This is OK 
        P(J) := 'a'; -- This is OK
        Q(J) := 'a'; -- also OK. But index out of range would raise 
Constraint Error
...
     Q := "hello_world"; -- deallocates, allocates with new bounds
...
   end;    -- deallocate Q here.

It follows that "indefinite" cannot also be "aliased" unless we want to 
implement smart pointers. For simplicity I'd suggest disallowing "aliased 
indefinite" on the grounds that "access" can (should) be used instead.

Records (including tagged, class wide, discriminated) should work the 
same, but probably with shallow copy on assignment if they contain access 
types.

If there is no re-allocation (no different size assignment) the compiler 
is free to substitute direct (stack) storage instead of heap allocation 
and implicit access types. So for example instead of
   
   A constant String := "done";
 ...
   loop
      declare
         P : String := Get_Line;
      begin
         exit when P = A;
      end;
   end loop;

   A constant String := "done";
   Q : indefinite String;
 ...
   loop
      Q := Get_Line;
      exit when Q = A;
   end loop;

the implementation can be either an implicit declare block or an implicit 
access type. However, where Q has several reassignments within a block, 
and the compiler can't determine the size, an implicit access type must 
be used. (If it can, it can warn that "indefinite " is unnecessary).

> What if the original object must be a class-wide object, task, protected
> object, limited object etc?
> 
> Ada's access types delegate all operations to the target object, except
> assignment. This is the key property that the proposal in my view must
> retain.

Indefinite can also be applied to records (discriminated, class wide, etc) 
here the size is indeterminate and may vary on reassignment. Assignment 
would always be shallow copy (where the record contained access types).

-- Brian