Prologue and epilogue aspects

Prologue and epilogue aspects

[Dmitry A. Kazakov]

While we are at [limited] controlled interfaces why not to make them safer?

I would propose a simple aspect Composition for primitive procedures 
(including interfaces). The aspect has values: Prologue | Override 
(default) | Epilogue | Final

    procedure First (...) with Composition => Prologue;

when overridden the parent type's body is called before the override.

    procedure Last (...) with Composition => Epilogue;

when overridden the parent's body is called after successful completion 
of the override.

    procedure Always (...) with Composition => Final;

when overridden the parent's body is always called after completion of 
the override. The exceptions from the override are re-raised after 
successful execution of the body.

The aspect is inherited if overriding does not change it.

[Variant: the aspect cannot be changed if the override does not have a 
full view of the type.]

The aspect inherited from interfaces is overridden by the aspect 
inherited from a full type [diamond inheritance].

Conflicting aspects from multiple interfaces must be explicitly overridden.

----------------------------------------------------------------
Now Ada.Finalization will declare Controlled as follows:

    type <anonymous> is interface;
    procedure Initialize (Object : in out <anonymous>) is
       abstract with Composition => Prologue;
    procedure Adjust (Object : in out <anonymous>) is
       abstract with Composition => Prologue;
    procedure Finalize (Object : in out <anonymous>)
       abstract with Composition => Epilogue;
--
-- Old code will continue "enjoying" manual calls to parent
-- Initialize, Adjust, Finalize
--
    type Controlled is abstract new <anonymous> with private;
    overriding
       procedure Initialize (Object : in out Controlled) is
          null with Composition => Override;
    overriding
       procedure Adjust (Object : in out Controlled) is
          null with Composition => Override;
    overriding
       procedure Finalize (Object : in out Controlled) is
          null with Composition => Override;
--
-- New code with have things as they should have been
--
    type Controlled_Interface is new <anonymous>;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Prologue and epilogue aspects

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:p4g15r$1s60$1@gioia.aioe.org...
...
>    type Controlled is abstract new <anonymous> with private;

This unfortunately doesn't fix anything. An interface never can be hidden 
(only in the private part), and deriving a concrete type from an interface 
doesn't change that.

We tried to define a special kind of interface that could be used in the 
private part in exchange for a promise never to add such an interface to a 
descendant of the private type. It didn't work out very well.

                              Randy.

Re: Prologue and epilogue aspects

[Dmitry A. Kazakov]

On 2018-01-27 08:17, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:p4g15r$1s60$1@gioia.aioe.org...
> ...
>>     type Controlled is abstract new <anonymous> with private;
> 
> This unfortunately doesn't fix anything. An interface never can be hidden
> (only in the private part), and deriving a concrete type from an interface
> doesn't change that.

But the interface is anonymous, it cannot be referenced in any way 
anywhere. It is mentioned only to be inherited from by a named interface.

         <anonymous>
           /     \
   Controlled   Controlled_Interface

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Prologue and epilogue aspects

[Randy Brukardt]

You mean sort of like "universal_controlled"? As previously noted, that 
might work for streams (and maybe pools),but controlled usually carries 
components along as well, so an interface (which cannot have components) is 
a bad match.

                       Randy.

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:p4hh1n$1qao$1@gioia.aioe.org...
> On 2018-01-27 08:17, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:p4g15r$1s60$1@gioia.aioe.org...
>> ...
>>>     type Controlled is abstract new <anonymous> with private;
>>
>> This unfortunately doesn't fix anything. An interface never can be hidden
>> (only in the private part), and deriving a concrete type from an 
>> interface
>> doesn't change that.
>
> But the interface is anonymous, it cannot be referenced in any way 
> anywhere. It is mentioned only to be inherited from by a named interface.
>
>         <anonymous>
>           /     \
>   Controlled   Controlled_Interface
>
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de 

Re: Prologue and epilogue aspects

[Dmitry A. Kazakov]

On 30/01/2018 00:08, Randy Brukardt wrote:
> You mean sort of like "universal_controlled"?

No, that would require a common base for old Ada.Finalization.Controlled 
and new Controlled_Interface. no that this is undesired, but it was 
rejected already. So the idea is an anonymous base, with the name nobody 
dare to call. (:-))

> As previously noted, that
> might work for streams (and maybe pools),but controlled usually carries
> components along as well, so an interface (which cannot have components) is
> a bad match.

That is an implementation detail. There is no components officially, so 
it is up to the compiler designer to stuck these somewhere and take care 
of the cases when both Ada.Finalization.Controlled and 
Controlled_Interface are inherited from.

BTW, I am not a fan of keeping lists of controlled objects and the rules 
to finalize objects implicitly. IMO it is a misfeature which adds no 
safety, just overhead. If Controlled_Interface would drop these rules I 
would be only happy. Then Controlled_Interface could be an interface 
without messy postmortem finalization rules, which would apply only if 
Ada.Finalization.Controlled inherited.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Prologue and epilogue aspects

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:p4pah6$1gan$1@gioia.aioe.org...
> On 30/01/2018 00:08, Randy Brukardt wrote:
>> You mean sort of like "universal_controlled"?
>
> No, that would require a common base for old Ada.Finalization.Controlled 
> and new Controlled_Interface. no that this is undesired, but it was 
> rejected already. So the idea is an anonymous base, with the name nobody 
> dare to call. (:-))
>
>> As previously noted, that
>> might work for streams (and maybe pools),but controlled usually carries
>> components along as well, so an interface (which cannot have components) 
>> is
>> a bad match.
>
> That is an implementation detail. There is no components officially, so it 
> is up to the compiler designer to stuck these somewhere and take care of 
> the cases when both Ada.Finalization.Controlled and Controlled_Interface 
> are inherited from.

Right, but implementing "implicit components" this way is the same work as 
supporting full multiple inheritance -- the components couldn't be at a 
fixed location in the object and you would have to use dispatching or 
something similar to find them. If you're going to implement that sort of 
thing, it would be criminal not to support it generally for all types -- and 
then you don't need a Controlled_Interface at all (or any other interface, 
for that matter).

Interfaces keep the runtime cost of multiple inheritance to solely dynamic 
dispatching. Pretty much everything else works the same as it always did, 
without other overhead. But if you are going to support general multiple 
inheritance -- implicit or explicit -- it has a distributed cost that makes 
all component accesses slower (at least, anything that could be used in 
multiple inheritance).

> BTW, I am not a fan of keeping lists of controlled objects and the rules 
> to finalize objects implicitly. IMO it is a misfeature which adds no 
> safety, just overhead. If Controlled_Interface would drop these rules I 
> would be only happy. Then Controlled_Interface could be an interface 
> without messy postmortem finalization rules, which would apply only if 
> Ada.Finalization.Controlled inherited.

Huh? If there is no implicit finalization, then there is no need for 
controlled types at all, as they serve no purpose. (If you want to 
explicitly finalize things, you can define any subprogram for that purpose. 
You could even call it "Finalize". And if you want an interface like that, 
write it yourself.) The only reason that there is a predefined type is to 
get the "magic" behavior. And that behavior is designed so that every object 
gets finalized. An abstraction that only finalizes when it is convinient is 
not interesting in an Ada context - it would be riddled with holes and 
composition would scary.

                                   Randy.

Re: Prologue and epilogue aspects

[Dmitry A. Kazakov]

On 30/01/2018 23:02, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:p4pah6$1gan$1@gioia.aioe.org...
>> On 30/01/2018 00:08, Randy Brukardt wrote:
>>> You mean sort of like "universal_controlled"?
>>
>> No, that would require a common base for old Ada.Finalization.Controlled
>> and new Controlled_Interface. no that this is undesired, but it was
>> rejected already. So the idea is an anonymous base, with the name nobody
>> dare to call. (:-))
>>
>>> As previously noted, that
>>> might work for streams (and maybe pools),but controlled usually carries
>>> components along as well, so an interface (which cannot have components)
>>> is
>>> a bad match.
>>
>> That is an implementation detail. There is no components officially, so it
>> is up to the compiler designer to stuck these somewhere and take care of
>> the cases when both Ada.Finalization.Controlled and Controlled_Interface
>> are inherited from.
> 
> Right, but implementing "implicit components" this way is the same work as
> supporting full multiple inheritance -- the components couldn't be at a
> fixed location in the object and you would have to use dispatching or
> something similar to find them. If you're going to implement that sort of
> thing, it would be criminal not to support it generally for all types -- and
> then you don't need a Controlled_Interface at all (or any other interface,
> for that matter).

There would be no components unless Ada.Finalization.Controlled inherited.

When inherited from Controlled_Interface only, all checks if to call 
Initialize, Finalize, Adjust will be static. No lists of objects.

>> BTW, I am not a fan of keeping lists of controlled objects and the rules
>> to finalize objects implicitly. IMO it is a misfeature which adds no
>> safety, just overhead. If Controlled_Interface would drop these rules I
>> would be only happy. Then Controlled_Interface could be an interface
>> without messy postmortem finalization rules, which would apply only if
>> Ada.Finalization.Controlled inherited.
> 
> Huh? If there is no implicit finalization, then there is no need for
> controlled types at all, as they serve no purpose. (If you want to
> explicitly finalize things, you can define any subprogram for that purpose.

"Implicit" meant called upon implicit destruction, e.g. when access 
types go out of the scope. That thing is not needed. I don't see other 
reason for the Controlled_Interface to induce hidden components.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Prologue and epilogue aspects

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:p4sm09$126n$1@gioia.aioe.org...
> On 30/01/2018 23:02, Randy Brukardt wrote:
...
>> Huh? If there is no implicit finalization, then there is no need for
>> controlled types at all, as they serve no purpose. (If you want to
>> explicitly finalize things, you can define any subprogram for that 
>> purpose.
>
> "Implicit" meant called upon implicit destruction, e.g. when access types 
> go out of the scope. That thing is not needed. I don't see other reason 
> for the Controlled_Interface to induce hidden components.

(1) Subpools and mutable types also need lists of some sort to properly do 
finalization.

(2) The reason for the "out of scope" rules is so that Finalization can be 
used for resource allocation beyond simply memory management. For instance, 
to return device (handles) to the OS when they won't be used any more. We 
felt that there shouldn't be any leaks in that.

(3) I think you would have to ban nested access types (that can go out of 
scope before program end) that designate type with parts of this kind of 
controlled type, lest the allocation of such objects lead to guarenteed 
storage leaks (one doesn't want to use Unchecked_Deallocation if they don't 
have to).

(4) Chains for all controlled objects work best with exception handling, as 
it isn't necessary to enter every scope to try to clean up objects, and in 
particular, one doesn't have to deal with the horror of partially 
initialized objects (whose initialization was interrupted by an exception).

To use your static implementation, you also have to use a static 
implementation of exceptions, and somehow keep track of initialization of 
objects (and every part of such objects) in each scope. It's possible (since 
AdaCore has managed it), but it's fiendishly complex and definitely beyond 
what I can do. Adopting rules that only AdaCore has enough smarts to 
implement would likely ensure that there never will be any other competing 
implementation. I think that's bad policy; even if no other implementation 
appears, closing the door seems like the wrong way to go.

                             Randy.

Re: Prologue and epilogue aspects

[Dmitry A. Kazakov]

On 01/02/2018 01:17, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:p4sm09$126n$1@gioia.aioe.org...
>> On 30/01/2018 23:02, Randy Brukardt wrote:
> ...
>>> Huh? If there is no implicit finalization, then there is no need for
>>> controlled types at all, as they serve no purpose. (If you want to
>>> explicitly finalize things, you can define any subprogram for that
>>> purpose.
>>
>> "Implicit" meant called upon implicit destruction, e.g. when access types
>> go out of the scope. That thing is not needed. I don't see other reason
>> for the Controlled_Interface to induce hidden components.
> 
> (1) Subpools and mutable types also need lists of some sort to properly do
> finalization.

No, they need not. The rule would be that all explicitly allocated 
objects of Controlled_Interface must be explicitly deallocated.

> (2) The reason for the "out of scope" rules is so that Finalization can be
> used for resource allocation beyond simply memory management. For instance,
> to return device (handles) to the OS when they won't be used any more. We
> felt that there shouldn't be any leaks in that.

I don't see how the feature would help. The only practical case when it 
takes effect is when exiting from the program. At that point it does not 
matter anyway.

> (3) I think you would have to ban nested access types (that can go out of
> scope before program end) that designate type with parts of this kind of
> controlled type, lest the allocation of such objects lead to guarenteed
> storage leaks (one doesn't want to use Unchecked_Deallocation if they don't
> have to).

Of course I would let them leak. No implicit deallocation.

> (4) Chains for all controlled objects work best with exception handling, as
> it isn't necessary to enter every scope to try to clean up objects, and in
> particular, one doesn't have to deal with the horror of partially
> initialized objects (whose initialization was interrupted by an exception).

It is always a controlled object that goes out the scope. All 
dynamically allocated controlled objects are in some kind of controlled 
container or other controlled structure responsible to deallocate them. 
Everything ultimately hooked on some scoped controlled object. That is 
the only sane design, IMO.

> To use your static implementation, you also have to use a static
> implementation of exceptions, and somehow keep track of initialization of
> objects (and every part of such objects) in each scope.

Then the scope can maintain a list of objects it initialized. I see no 
need to corrupt the object representation with list pointers in order to 
merely roll back the stack.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Prologue and epilogue aspects

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:p4ul5c$582$1@gioia.aioe.org...
> On 01/02/2018 01:17, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:p4sm09$126n$1@gioia.aioe.org...
>>> On 30/01/2018 23:02, Randy Brukardt wrote:
>> ...
>>>> Huh? If there is no implicit finalization, then there is no need for
>>>> controlled types at all, as they serve no purpose. (If you want to
>>>> explicitly finalize things, you can define any subprogram for that
>>>> purpose.
>>>
>>> "Implicit" meant called upon implicit destruction, e.g. when access 
>>> types
>>> go out of the scope. That thing is not needed. I don't see other reason
>>> for the Controlled_Interface to induce hidden components.
>>
>> (1) Subpools and mutable types also need lists of some sort to properly 
>> do
>> finalization.
>
> No, they need not. The rule would be that all explicitly allocated objects 
> of Controlled_Interface must be explicitly deallocated.

Yes, but you need a list to explicitly deallocate a subpool (as there are 
many objects in the subpool). Or you could just ban the use of subpools, but 
that's madness.

>> (2) The reason for the "out of scope" rules is so that Finalization can 
>> be
>> used for resource allocation beyond simply memory management. For 
>> instance,
>> to return device (handles) to the OS when they won't be used any more. We
>> felt that there shouldn't be any leaks in that.
>
> I don't see how the feature would help. The only practical case when it 
> takes effect is when exiting from the program. At that point it does not 
> matter anyway.

It does if the underlying manager is primitive (as some RTOSes are) and 
there is no automatic closing of handles. (That was the case on CP/M and 
early MS-DOS, if one left files open when a program exited, they never got 
closed at all. Which could lead to data loss or resource exhaustion.)

>> (3) I think you would have to ban nested access types (that can go out of
>> scope before program end) that designate type with parts of this kind of
>> controlled type, lest the allocation of such objects lead to guarenteed
>> storage leaks (one doesn't want to use Unchecked_Deallocation if they 
>> don't
>> have to).
>
> Of course I would let them leak. No implicit deallocation.

OK, but that's not the way Ada handles types with Storage_Size specified. 
I'd rather they were illegal (most of the accessibility madness comes from 
allowing such types, and they're nearly useless).

>> (4) Chains for all controlled objects work best with exception handling, 
>> as
>> it isn't necessary to enter every scope to try to clean up objects, and 
>> in
>> particular, one doesn't have to deal with the horror of partially
>> initialized objects (whose initialization was interrupted by an 
>> exception).
>
> It is always a controlled object that goes out the scope. All dynamically 
> allocated controlled objects are in some kind of controlled container or 
> other controlled structure responsible to deallocate them. Everything 
> ultimately hooked on some scoped controlled object. That is the only sane 
> design, IMO.
>
>> To use your static implementation, you also have to use a static
>> implementation of exceptions, and somehow keep track of initialization of
>> objects (and every part of such objects) in each scope.
>
> Then the scope can maintain a list of objects it initialized. I see no 
> need to corrupt the object representation with list pointers in order to 
> merely roll back the stack.

That's what I called "fiendishly complex". Sure, it can be done, but you 
have to have a handler in every master with none trivial objects (regardless 
of whether there is any explicit exception handlers, of even if there can 
be). With the exception handing in our compiler, that would be a horrible 
drag on performance even if no handlers were used (state snapshots would be 
needed for each implicit handler, and handlers block optimizations as well, 
so a lot of unneeded checks wouldn't be identified).

The only practical way to that is similar to the way that AdaCore does that 
(for both finalization and exception handling), which would be a 2-3 man 
year effort for any compiler vendor that isn't already using that scheme (so 
far as I know, that's most of the non-AdaCore vendors).

And I doubt that even the AdaCore scheme quite matches to your goals. Plus 
the lack of safety (there now are many ways to get skip finalization on 
objects), I don't see anyone being very interested. It makes more sense, 
honestly, to support full multiple inheritance.

                               Randy.

Re: Prologue and epilogue aspects

[Niklas Holsti]

On 18-02-02 01:47 , Randy Brukardt wrote:

    [about finalization, etc., with Dmitry A. Kazakov]

> The only practical way to that is similar to the way that AdaCore does that
> (for both finalization and exception handling), [...]
>
> And I doubt that even the AdaCore scheme quite matches to your goals. Plus
> the lack of safety (there now are many ways to get skip finalization on
> objects),

I ask for clarification: do you mean that AdaCore's finalization methods 
allow finalization to be skipped (which would be bad), or that skips 
could happen if Dmitry's suggestions were to be adopted?

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Prologue and epilogue aspects

[Dmitry A. Kazakov]

On 02/02/2018 00:47, Randy Brukardt wrote:

> Yes, but you need a list to explicitly deallocate a subpool (as there are
> many objects in the subpool). Or you could just ban the use of subpools, but
> that's madness.

If anybody wanted a sub-pool he would be responsible to make them work 
with his objects.

It is a stupid design anyway. When I must care about bulk deallocation I 
must be even more about bulk finalization.

>> I don't see how the feature would help. The only practical case when it
>> takes effect is when exiting from the program. At that point it does not
>> matter anyway.
> 
> It does if the underlying manager is primitive (as some RTOSes are) and
> there is no automatic closing of handles. (That was the case on CP/M and
> early MS-DOS, if one left files open when a program exited, they never got
> closed at all. Which could lead to data loss or resource exhaustion.)

I would never implement it that way. I don't know who would. If the OS 
does not collect dead resources, a responsible developer would design a 
resource manager for that, because most likely the OS handles would not 
work the way you described. There will be some obscure limitations 
regarding sharing them, contexts where you can create/release them, etc. 
The puny implicit finalization won't work anyway.

>> Of course I would let them leak. No implicit deallocation.
> 
> OK, but that's not the way Ada handles types with Storage_Size specified.

No problem either. It would be a bounded error. The memory would be 
reclaimed as for any plain type, Finalization not called, what you see 
is what you get.

> I'd rather they were illegal (most of the accessibility madness comes from
> allowing such types, and they're nearly useless).

I agree. The problem is that the access type is not a proper type with 
interfaces and classes. The language cannot manage referential semantics 
introduced by the programmer. There is no chance. So, it should leave 
that stuff alone.

Give me a plain pointer with no strings attached. And let me use a 
full-blown referential type in the contexts where an access type is 
expected. That is all, would cut the Ada RM in half, won't it? (:-))

>> Then the scope can maintain a list of objects it initialized. I see no
>> need to corrupt the object representation with list pointers in order to
>> merely roll back the stack.
> 
> That's what I called "fiendishly complex". Sure, it can be done, but you
> have to have a handler in every master with none trivial objects (regardless
> of whether there is any explicit exception handlers, of even if there can
> be). With the exception handing in our compiler, that would be a horrible
> drag on performance even if no handlers were used (state snapshots would be
> needed for each implicit handler, and handlers block optimizations as well,
> so a lot of unneeded checks wouldn't be identified).

I don't see why it so. It is trivial to allocate a list head in front of 
the stack allocated object rather than inside it.

> The only practical way to that is similar to the way that AdaCore does that
> (for both finalization and exception handling), which would be a 2-3 man
> year effort for any compiler vendor that isn't already using that scheme (so
> far as I know, that's most of the non-AdaCore vendors).
> 
> And I doubt that even the AdaCore scheme quite matches to your goals. Plus
> the lack of safety (there now are many ways to get skip finalization on
> objects), I don't see anyone being very interested. It makes more sense,
> honestly, to support full multiple inheritance.

I think almost all programmers are interested in safe initialization and 
finalization *with* rollback. This is the most important feature I can 
imagine. The present state when initialization and finalization is a 
minefield is simply unacceptable.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Prologue and epilogue aspects

[Niklas Holsti]

On 18-02-02 10:46 , Dmitry A. Kazakov wrote:

> Give me a plain pointer with no strings attached.

You want to forbid "access String" ??

:-) :-)

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Prologue and epilogue aspects

[Dmitry A. Kazakov]

On 02/02/2018 10:31, Niklas Holsti wrote:
> On 18-02-02 10:46 , Dmitry A. Kazakov wrote:
> 
>> Give me a plain pointer with no strings attached.
> 
> You want to forbid "access String" ??
> 
> :-) :-)

BTW:

    type Text (Length : Natural) is access String (1..Length);

    type Instance (Tag : Ada.Tags.Tag) is access Object_Type'Class (Tag);

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Prologue and epilogue aspects

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:fdighkFpkguU1@mid.individual.net...
> On 18-02-02 01:47 , Randy Brukardt wrote:
>
>    [about finalization, etc., with Dmitry A. Kazakov]
>
>> The only practical way to that is similar to the way that AdaCore does 
>> that
>> (for both finalization and exception handling), [...]
>>
>> And I doubt that even the AdaCore scheme quite matches to your goals. 
>> Plus
>> the lack of safety (there now are many ways to get skip finalization on
>> objects),
>
> I ask for clarification: do you mean that AdaCore's finalization methods 
> allow finalization to be skipped (which would be bad), or that skips could 
> happen if Dmitry's suggestions were to be adopted?

Only if Dmitry's suggestions were to be adopted. AdaCore uses lists in some 
cases, Dmitry wanted to get rid of those cases by saying that they don't 
finalize. So far as I'm aware, GNAT does the right thing for Ada 2012 in 
every case.

                           Randy.