Controlled types as interfaces

Controlled types as interfaces

[Victor Porton]

I think in Ada 202X we can invent Limited_Controlled_Interface and 
Controlled_Interface types derived from which could become controlled.

The Limited_Controlled and Controlled types would also inherit from these 
interfaces.

I think, this is backward compatible.

Good idea?

-- 
Victor Porton - http://portonvictor.org

Re: Controlled types as interfaces

[Victor Porton]

Victor Porton wrote:
> I think in Ada 202X we can invent Limited_Controlled_Interface and
> Controlled_Interface types derived from which could become controlled.
> 
> The Limited_Controlled and Controlled types would also inherit from these
> interfaces.
> 
> I think, this is backward compatible.

A similar thing can be made with Root_Stream_Type making it derived from 
Root_Stream_Interface interface.

-- 
Victor Porton - http://portonvictor.org

Re: Controlled types as interfaces

[Victor Porton]

Victor Porton wrote:
> I think in Ada 202X we can invent Limited_Controlled_Interface and
> Controlled_Interface types derived from which could become controlled.
> 
> The Limited_Controlled and Controlled types would also inherit from these
> interfaces.
> 
> I think, this is backward compatible.
> 
> Good idea?

And then we would deprecate old types Limited_Controlled and Controlled 
because the interfaces do the job better.

-- 
Victor Porton - http://portonvictor.org

Re: Controlled types as interfaces

[Dmitry A. Kazakov]

On Wed, 20 Aug 2014 04:09:15 +0300, Victor Porton wrote:

> Victor Porton wrote:
>> I think in Ada 202X we can invent Limited_Controlled_Interface and
>> Controlled_Interface types derived from which could become controlled.

Yes, but that would be very complicated, because you could add an interface 
very late, making a descendant of a non-controlled type controlled.

A better solution would be fixing initialization (AKA constructors) and 
leaving controlled kludge as is.

>> The Limited_Controlled and Controlled types would also inherit from these
>> interfaces.
>> 
>> I think, this is backward compatible.
> 
> A similar thing can be made with Root_Stream_Type making it derived from 
> Root_Stream_Interface interface.

Yes, of course. It was proposed multiple times, as I remember. But rejected 
as "not backward compatible." Though the compatibility issue was quite 
minor if any.

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

Re: Controlled types as interfaces

[Victor Porton]

Dmitry A. Kazakov wrote:

> On Wed, 20 Aug 2014 04:09:15 +0300, Victor Porton wrote:
> 
>> Victor Porton wrote:
>>> I think in Ada 202X we can invent Limited_Controlled_Interface and
>>> Controlled_Interface types derived from which could become controlled.
> 
> Yes, but that would be very complicated, because you could add an
> interface very late, making a descendant of a non-controlled type
> controlled.
> 
> A better solution would be fixing initialization (AKA constructors) and
> leaving controlled kludge as is.

I don't see any reason not to make descendant of a non-controlled type 
controlled.

Let T is a non-controlled tagged type.

It descendant Q is like a record

record
   Old: T;
   Ext: Q1;
end record;

(where Q1 is the difference of Q and T).

Q1 is controlled.

As there is no problem that this record becomes controlled, there are no 
reason not to make Q controlled despite of T was non-controlled.

-- 
Victor Porton - http://portonvictor.org

Re: Controlled types as interfaces

[Victor Porton]

Dmitry A. Kazakov wrote:

>> A similar thing can be made with Root_Stream_Type making it derived from
>> Root_Stream_Interface interface.
> 
> Yes, of course. It was proposed multiple times, as I remember. But
> rejected as "not backward compatible." Though the compatibility issue was
> quite minor if any.

We can make Root_Stream_Type a descendant of Root_Stream_Interface.

So old code can derive from Root_Stream_Type and this is backward 
compatible.

-- 
Victor Porton - http://portonvictor.org

Re: Controlled types as interfaces

[Dmitry A. Kazakov]

On Wed, 20 Aug 2014 15:50:58 +0300, Victor Porton wrote:

> Dmitry A. Kazakov wrote:
> 
>>> A similar thing can be made with Root_Stream_Type making it derived from
>>> Root_Stream_Interface interface.
>> 
>> Yes, of course. It was proposed multiple times, as I remember. But
>> rejected as "not backward compatible." Though the compatibility issue was
>> quite minor if any.
> 
> We can make Root_Stream_Type a descendant of Root_Stream_Interface.

Yes that was exactly the proposal (and for the pool's root type as well).

> So old code can derive from Root_Stream_Type and this is backward 
> compatible.

No. It was a different case. I don't remember the details. But the example
was quite marginal and wrong code anyway, as I remember.

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

Re: Controlled types as interfaces

[Dmitry A. Kazakov]

On Wed, 20 Aug 2014 15:49:36 +0300, Victor Porton wrote:

> Dmitry A. Kazakov wrote:
> 
>> On Wed, 20 Aug 2014 04:09:15 +0300, Victor Porton wrote:
>> 
>>> Victor Porton wrote:
>>>> I think in Ada 202X we can invent Limited_Controlled_Interface and
>>>> Controlled_Interface types derived from which could become controlled.
>> 
>> Yes, but that would be very complicated, because you could add an
>> interface very late, making a descendant of a non-controlled type
>> controlled.
>> 
>> A better solution would be fixing initialization (AKA constructors) and
>> leaving controlled kludge as is.
> 
> I don't see any reason not to make descendant of a non-controlled type 
> controlled.

I don't see why any type cannot have initialization hooks either.

> Let T is a non-controlled tagged type.
> 
> It descendant Q is like a record
> 
> record
>    Old: T;
>    Ext: Q1;
> end record;
> 
> (where Q1 is the difference of Q and T).
> 
> Q1 is controlled.
> 
> As there is no problem that this record becomes controlled, there are no 
> reason not to make Q controlled despite of T was non-controlled.

It depends on concrete implementations, e.g. some might require the type
tag being at the record's first address.

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

Re: Controlled types as interfaces

[Brad Moore]

On 14-08-20 06:50 AM, Victor Porton wrote:
> Dmitry A. Kazakov wrote:
>
>>> A similar thing can be made with Root_Stream_Type making it derived from
>>> Root_Stream_Interface interface.
>>
>> Yes, of course. It was proposed multiple times, as I remember. But
>> rejected as "not backward compatible." Though the compatibility issue was
>> quite minor if any.
>
> We can make Root_Stream_Type a descendant of Root_Stream_Interface.
>
> So old code can derive from Root_Stream_Type and this is backward
> compatible.
>

There is an amendment AI for this already, for Ada 202x.

See AI12-0023-1
( 
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0023-1.txt?rev=1.3&raw=Y 
)

This AI has not been rejected (yet), as all amendment AI's that are 
proposals for Ada 202X are only proposals at this point. At some point 
in the future when it comes time to start selecting which proposals are 
worth having, this AI may or may not make the cut.

The incompatibilities are described in the discussion section of the AI, 
but these had to do with  problems of changing Root_Stream_Type into an 
interface.

However, I believe you are correct that if we modified Root_Stream_Type 
to remain an abstract type that inherits from a Root_Stream_Interface, 
then these incompatibilities would not exist.

Backward incompatibilities are to be avoided if at all possible, so I
think if we were to go forward with this AI, your suggestion to make 
Root_Stream_Type inherit from a Root_Stream_Interface, might be the way 
to go.

Brad

Re: Controlled types as interfaces

[Randy Brukardt]

"Brad Moore" <brad.moore@shaw.ca> wrote in message 
news:1O1Jv.11735$8G3.5145@fx12.iad...
> On 14-08-20 06:50 AM, Victor Porton wrote:
...
> The incompatibilities are described in the discussion section of the AI, 
> but these had to do with  problems of changing Root_Stream_Type into an 
> interface.
>
> However, I believe you are correct that if we modified Root_Stream_Type to 
> remain an abstract type that inherits from a Root_Stream_Interface, then 
> these incompatibilities would not exist.

No, sorry, they're the same. The problem is that Ada doesn't allow hidden 
inheritance (in any way) of an interface.

If Root_Stream_Type is an interface, or inherits from an interface, then it 
cannot be used in the full type definition of a private type. That's the 
backwards incompatibility.

> Backward incompatibilities are to be avoided if at all possible, so I
> think if we were to go forward with this AI, your suggestion to make 
> Root_Stream_Type inherit from a Root_Stream_Interface, might be the way to 
> go.

We've already discussed that as-nausem. My personal opinion (in the case of 
Root_Stream_Type) is that there isn't any good reason to use this in a 
hidden way, so we could just make it an interface and swallow the 
incompatibility. (When I suggested that at a meeting, though, it got no 
traction.)

But that's not true for Controlled. The vast majority of the types I define 
are tagged private where the full type is derived from Controlled (or 
Limited_Controlled).

The most recent versions of AI12-0023-1 were trying to find ways to lift the 
ban against hidden interfaces for a restricted set of interfaces. It's the 
only way to do this without incompatibilities for existing uses. My 
recollection is that it wasn't going well (but we haven't worked on that 
since the Stockholm meeting more than a year ago).

                                            Randy.

Re: Controlled types as interfaces

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:imjh3cg11wdr$.1hslpo3a68yxi.dlg@40tude.net...
> On Wed, 20 Aug 2014 15:49:36 +0300, Victor Porton wrote:
...
>> As there is no problem that this record becomes controlled, there are no
>> reason not to make Q controlled despite of T was non-controlled.
>
> It depends on concrete implementations, e.g. some might require the type
> tag being at the record's first address.

That's not exactly the problem, as Ada allows types with conflicting 
representation clauses to be rejected. (This particular problem can already 
happen for interfaces, so there are rules to handle it.)

The real problem is that some (many?) implementations include 
implementation-defined components in types Controlled and 
Limited_Controlled. (For instance, Janus/Ada includes chain components.) 
Interfaces of course don't have any components; thus making 
Controlled/Limited_Controlled into interfaces would require the back-door 
implementation of full MI (since it would require adding components to 
existing types, meaning that the components could not be assumed at a fixed 
offset). That is a leap too far.

Note that in the OP's example, Janus/Ada does NOT treat the enclosing record 
as controlled; each individual controlled object (including components) is 
managed separately. I did it that way to make unwinding an object in the 
face of exceptions during construction easier (each object is registered as 
it is constructed, so all successfully constructed objects get finalized and 
none that failed get finalized). GNAT, OTOH, does treat each object 
individibly and has to go through some handstands so that objects that 
aren't constructed aren't finalized.

                                                 Randy.

Re: Controlled types as interfaces

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> The real problem is that some (many?) implementations include 
> implementation-defined components in types Controlled and 
> Limited_Controlled. (For instance, Janus/Ada includes chain components.) 

GNAT used to do that, but actually only heap objects need to be chained,
and the current implementation does not declare the chain links as
components.  Controlled components and stack objects do not get
chained.  A heap object is allocated with some extra space at negative
offsets, where the chain links are stored.

> Interfaces of course don't have any components; thus making 
> Controlled/Limited_Controlled into interfaces would require the back-door 
> implementation of full MI (since it would require adding components to 
> existing types, meaning that the components could not be assumed at a fixed 
> offset). That is a leap too far.
>
> Note that in the OP's example, Janus/Ada does NOT treat the enclosing record 
> as controlled; each individual controlled object (including components) is 
> managed separately. I did it that way to make unwinding an object in the 
> face of exceptions during construction easier (each object is registered as 
> it is constructed, so all successfully constructed objects get finalized and 
> none that failed get finalized). GNAT, OTOH, does treat each object 
                                                   ^ not
> individibly and has to go through some handstands so that objects that 
> aren't constructed aren't finalized.

I think you're missing a "not" there.  Yes, there are some "handstands",
but it's not so bad.  I think the only reason it was so hard to
implement is that it was a re-implementation.  Doing it that way from
the start would not have been so bad (as is often the case).

The compiler generates a "deep_initialize" procedure for each type,
which either fully initializes everything, or else finalizes the parts
that got initialized before an exception.

Rational uses the same method as GNAT.

- Bob

Re: Controlled types as interfaces

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcc4mwv731x.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
...
>> Note that in the OP's example, Janus/Ada does NOT treat the enclosing 
>> record
>> as controlled; each individual controlled object (including components) 
>> is
>> managed separately. I did it that way to make unwinding an object in the
>> face of exceptions during construction easier (each object is registered 
>> as
>> it is constructed, so all successfully constructed objects get finalized 
>> and
>> none that failed get finalized). GNAT, OTOH, does treat each object
>                                                   ^ not
>> individibly and has to go through some handstands so that objects that
>> aren't constructed aren't finalized.
>
> I think you're missing a "not" there.

I don't think so, but I don't claim to understand what GNAT does that well.

> Yes, there are some "handstands",
> but it's not so bad.  I think the only reason it was so hard to
> implement is that it was a re-implementation.  Doing it that way from
> the start would not have been so bad (as is often the case).
>
> The compiler generates a "deep_initialize" procedure for each type,
> which either fully initializes everything, or else finalizes the parts
> that got initialized before an exception.

Initialize routines like that are fiendishly complex (we do initializes that 
way), especially because the combination of discriminant dependent 
components and recursion to handle subcomponents. Trying to include 
finalization in there would have caused madness, at a minimum when something 
goes wrong. (They're literally impossible to debug, and I always find 
something else to do rather than work on those routines. Sorry, Tero. :-)

Also, doing that requires that every call and check be effectively wrapped 
with an exception handler since one has to know the exact point of failure. 
For checks, that's not too bad as the check could be replaced by a branch. 
But for calls, that can be expensive depending on the exception handling 
scheme. (It's probably tractable for GNAT because of the zero-cost exception 
handling, although that is clearly an additional source of complexity; for 
Janus which uses a registration scheme, the cost would be way too expensive 
to use regularly.)

As always with compiler construction, YMMV.

                                           Randy.