comp.lang.ada
 help / color / mirror / Atom feed
From: Brian Drummond <brian@shapes.demon.co.uk>
Subject: Re: Proposal: Auto-allocation of Indefinite Objects
Date: Wed, 29 Jul 2020 15:33:33 -0000 (UTC)	[thread overview]
Message-ID: <rfs4sd$bv0$1@dont-email.me> (raw)
In-Reply-To: rfpefq$17fm$1@gioia.aioe.org

On Tue, 28 Jul 2020 16:59:09 +0200, Dmitry A. Kazakov wrote:

> On 28/07/2020 16:28, Brian Drummond wrote:
>> 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;
> 
> Equivalent of C++ reference in Ada is renaming.

OK. Not quite sure how complete the correspondence between reference and 
renaming is, but I can see similarities.

>> Q : indefinite String := "hello";
> 
> I think the keyword is misleading. Maybe this:
> 
>     Q : new String := "hello";

Not sure I like. The reader has to make the mental jump from seeing "new" 
to thinking of this as an indefinite type. There may be a better keyword, 
open to suggestions, but let's stick to indefinite for now.

> And I don't like initialization. 

Initialisation is unnecessary for indefinite String. It was only used in 
that example for similarity with previous strings A,P.

>>     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.
> 
> The rule could be "same pool" as of the container. In the case of a
> block, the pool is the stack. In the case of a record member, the pool
> is the pool of where the record itself is allocated. So that you could
> allocate all object in the same pool.

Looks like a good rule. Saves the compiler having to plant deallocations 
if the whole pool is to be de-allocated.
 
>> 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.
> 
> It makes sense, but there are use cases for having it aliased:
> 
>     X : indefinite T;
      X : aliased indefinite T;
>     Y : indefinite S (X'Access); -- Access discriminant
As elsewhere, "aliased" indicates both to compiler and reader, that the 
rules are about to get more complicated. Specifically, if X is re-
allocated thanks to a different size assignment, all Y must be updated.

>>     A constant String := "done"; 
>>     Q : indefinite String;
>>   ...
>>     loop
>>        Q := Get_Line; 
>>        exit when Q = A;
>>     end loop;
> 
> I am not comfortable with the semantics of this and with possible
> implications too. I would keep it simple.

Interesting. Can you pin down some of that discomfort? It looks simple to 
me : 

"indefinite" indicates the size can vary (and the compiler knows whether 
it used the heap or stack), and in the absence of "aliased" we know there 
are no copies of the pointer (if heap). 

But of course my mind isn't wrapped round all the corner cases, and if 
you are uncomfortable, I'm probably missing a very good reason.

>> 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).
> 
> That would be inconsistent. IMO, it should be a deep copy, provided such
> a component would not make the type limited, of which I am not sure.

Honest question : Inconsistent with what?
I suggested shallow copy just for simplicity, and for no (ahh) deeper 
reason. But again, I'm probably missing something.

Thank you for your thoughts. I don't know if this is worth developing 
into an AI.

-- Brian

  reply	other threads:[~2020-07-29 15:33 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-03 22:48 Proposal: Auto-allocation of Indefinite Objects Stephen Davies
2020-04-03 23:45 ` Stephen Leake
2020-04-04 10:54   ` Jeffrey R. Carter
2020-04-04 20:55     ` Stephen Davies
2020-04-04  8:31 ` Dmitry A. Kazakov
2020-07-27  7:47 ` Yannick Moy
2020-07-27  9:21   ` J-P. Rosen
2020-07-27  9:49     ` Dmitry A. Kazakov
2020-07-27 17:48   ` Brian Drummond
2020-07-27 20:02     ` Dmitry A. Kazakov
2020-07-28 14:28       ` Brian Drummond
2020-07-28 14:59         ` Dmitry A. Kazakov
2020-07-29 15:33           ` Brian Drummond [this message]
2020-07-29 16:20             ` Dmitry A. Kazakov
2020-07-30 13:37               ` Stephen Davies
2020-07-30 14:23                 ` Dmitry A. Kazakov
2020-07-30 17:04               ` Brian Drummond
2020-07-30 18:28                 ` Dmitry A. Kazakov
2020-08-10  0:39                   ` Randy Brukardt
2020-08-10  8:57                     ` Dmitry A. Kazakov
2020-08-20  0:10                       ` Randy Brukardt
2020-08-20 17:49                         ` Dmitry A. Kazakov
2020-08-20 20:19                           ` Dennis Lee Bieber
2020-08-20 23:33                             ` Randy Brukardt
2020-08-21  6:45                               ` Dmitry A. Kazakov
2020-08-23  4:52                                 ` Randy Brukardt
2020-08-23 12:28                                   ` Dmitry A. Kazakov
2020-08-20 23:30                           ` Randy Brukardt
2020-08-21  6:46                             ` Dmitry A. Kazakov
2020-08-23  4:48                               ` Randy Brukardt
2020-08-23 12:29                                 ` Dmitry A. Kazakov
2020-08-10  0:31               ` Randy Brukardt
2020-08-10  8:58                 ` Dmitry A. Kazakov
2020-08-20  0:13                   ` Randy Brukardt
2020-08-20 17:49                     ` Dmitry A. Kazakov
2020-08-20 23:25                       ` Randy Brukardt
2020-08-21  7:08                         ` Dmitry A. Kazakov
2020-08-23  5:03                           ` Randy Brukardt
2020-08-23 12:28                             ` Dmitry A. Kazakov
2020-07-27 20:31     ` Jeffrey R. Carter
2020-07-31  9:25 ` Stephen Davies
2020-07-31 10:20   ` Dmitry A. Kazakov
2020-08-01 11:22     ` Stephen Davies
2020-08-01 12:58       ` Dmitry A. Kazakov
2020-08-01 20:35         ` Stephen Davies
2020-08-01 20:56           ` Dmitry A. Kazakov
2020-09-03  4:30 ` linda white
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox