Private extension of a synchronized interface

Private extension of a synchronized interface

[Jere]

I'll get to my ultimate goal later, but while following various
rabbit trails, I came across a situation I couldn't solve.  GNAT
allows you to make private extensions to synchronized interfaces
and it allows you to complete those private extensions with 
protected types.  I can't, however, figure out how it overrides
the abstract procedures and functions of the synchronized interface.

If I don't specify an override and try to call the procedure, it complains
that the procedure is abstract.  If I try to override the abstract
function, it complains that the signature doesn't match the one in
the protected body.  I don't know if this is a GNAT issue or 
something that Ada doesn't allow.  Here is some test code.  It
compiles as is, but there are two parts that if you uncomment 
either one of those it fails to compile.

***********************************************************

with Ada.Text_IO; use Ada.Text_IO;

procedure Hello is

    package Example is
    
        type An_Interface is synchronized interface;
        procedure p1(Self : in out An_Interface) is abstract;
        
        type Instance is synchronized new An_Interface with private;
        
        -- The following lines give the errors:
        -- "p1" conflicts with declaration at line xxx
        -- and
        -- missing body for "p1"
        
        --overriding
        --procedure p1(Self : in out Instance);
        
    private
    
        -- Some hidden implementation types, constants, etc.
    
        -- Instance full view is a protected type
        protected type Instance is new An_Interface with
            procedure p1;
        private
            -- some hidden stuff;
        end Instance;
    
    end Example;
    
    package body Example is
    
        protected body Instance is
            procedure p1 is
            begin
                Put_Line("Did Something");
            end p1;
        end Instance;
    
    end Example;
    
    v : Example.Instance;
    
begin
  Put_Line("Hello, world!");
  
  -- The following line gives the error:
  -- call to abstract procedure must be dispatching
  
  --v.p1;
end Hello;

***********************************************************

My ultimate goal is not having to declare a bunch of extra
types and packages in the public view to only use them in the
private view of the protected object.  I'd prefer that all
of the private stuff actually be in a private section.  So
I'm not tied to interfaces, but it was one attempt at getting
stuff moved down to the private section.  But while I went
down the interfaces rabbit hole, I just found the issue I 
ran into odd.

Does anyone know how to create the correct overrides for
the example above?
 

Re: Private extension of a synchronized interface

[Dmitry A. Kazakov]

On 2019-02-16 01:52, Jere wrote:
> I'll get to my ultimate goal later, but while following various
> rabbit trails, I came across a situation I couldn't solve.  GNAT
> allows you to make private extensions to synchronized interfaces
> and it allows you to complete those private extensions with
> protected types.  I can't, however, figure out how it overrides
> the abstract procedures and functions of the synchronized interface.
> 
> If I don't specify an override and try to call the procedure, it complains
> that the procedure is abstract.  If I try to override the abstract
> function, it complains that the signature doesn't match the one in
> the protected body.  I don't know if this is a GNAT issue or
> something that Ada doesn't allow.  Here is some test code.  It
> compiles as is, but there are two parts that if you uncomment
> either one of those it fails to compile.

Reading RM 9.5.2 (13.2/2) does not really help:

"if the overriding_indicator is overriding, then the entry shall 
implement an inherited subprogram;"

An inherited subprogram is already implemented per, well, inheritance. 
May be it means:

1. shall implement a primitive operation (it overrides here);

2. shall implement an overridden primitive operation (it implements 
overriding declared earlier).

Neither #1 nor #2 work.

But synchronized interfaces are totally bogus from the software design 
POV. It is a pure implementation aspect exposed. Why do you care? 
Aggregate a protected object and delegate primitive operations to it.

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

Re: Private extension of a synchronized interface

[Jere]

On Sunday, February 17, 2019 at 4:50:24 AM UTC-5, Dmitry A. Kazakov wrote:
> 
> But synchronized interfaces are totally bogus from the software design 
> POV. It is a pure implementation aspect exposed. Why do you care? 
> Aggregate a protected object and delegate primitive operations to it.
> 

That's what I am doing as my own solution.  I was intrigued with the code
above as an alternate solution because it could potentially give a 
compile time indication that a procedure was a protected operation (as
opposed to me relying on simply providing that via comments).  A delegate 
non protected procedure has to rely on the comment.  I didn't even want
the interface to use as an interface, just as a means to at the API level
to have a compiler enforced indication that the procedure was from a 
protected object.  I started with a protected object in the public view
but the implementation details of the private part of the protected object
led to about 10 lines of code (type declarations and a couple of package
specifications) that had no use to the public view but had to be there 
because of how protected object declarations work.  I saw this as a potential
means of information hiding.  My actual solution is as you suggested with
delegate operations that call the protected object.  However, I honestly
wanted to know why Ada allowed one to setup the private extension but not 
allow you to actually provide the functions (or if this was a GNAT issue or
if I was just not using the right syntax).  So the reason I care was a
thirst for knowledge of how things work.

Re: Private extension of a synchronized interface

[Dmitry A. Kazakov]

On 2019-02-17 14:46, Jere wrote:
> On Sunday, February 17, 2019 at 4:50:24 AM UTC-5, Dmitry A. Kazakov wrote:
>>
>> But synchronized interfaces are totally bogus from the software design
>> POV. It is a pure implementation aspect exposed. Why do you care?
>> Aggregate a protected object and delegate primitive operations to it.
>>
> 
> That's what I am doing as my own solution.  I was intrigued with the code
> above as an alternate solution because it could potentially give a
> compile time indication that a procedure was a protected operation (as
> opposed to me relying on simply providing that via comments).

Given to who? The compiler knows already, the user should not care. It 
is an implementation aspect which simply does not belong here.

What could make sense is an entry interface, a primitive operation which 
could be queued/requeued to, used in timed entry call etc.

> A delegate non protected procedure has to rely on the comment.

There is no contract that could require it protected. It is a property 
of the object/task and no property of an operation. You could not do 
anything with a task or protected object that would not resolve into a 
protected action anyway.

[...]

> However, I honestly
> wanted to know why Ada allowed one to setup the private extension but not
> allow you to actually provide the functions (or if this was a GNAT issue or
> if I was just not using the right syntax).  So the reason I care was a
> thirst for knowledge of how things work.

Ada 2005 stuff, most of it makes little sense to me. It was some 
halfhearted attempt to unite tagged types with tasks and protected 
objects with no desire to actually do that...

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

Re: Private extension of a synchronized interface

[Jere]

On Sunday, February 17, 2019 at 9:52:42 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2019-02-17 14:46, Jere wrote:
> > On Sunday, February 17, 2019 at 4:50:24 AM UTC-5, Dmitry A. Kazakov wrote:
> >>
> >> But synchronized interfaces are totally bogus from the software design
> >> POV. It is a pure implementation aspect exposed. Why do you care?
> >> Aggregate a protected object and delegate primitive operations to it.
> >>
> > 
> > That's what I am doing as my own solution.  I was intrigued with the code
> > above as an alternate solution because it could potentially give a
> > compile time indication that a procedure was a protected operation (as
> > opposed to me relying on simply providing that via comments).
> 
> Given to who? The compiler knows already, the user should not care. It 
> is an implementation aspect which simply does not belong here.
> 
The compiler cannot always tell depending on how and where you call buried
protected operations.  I always prefer compile time catching over run time 
catching.


> > A delegate non protected procedure has to rely on the comment.
> 
> There is no contract that could require it protected. It is a property 
> of the object/task and no property of an operation. You could not do 
> anything with a task or protected object that would not resolve into a 
> protected action anyway.

Protected procedures/functions/entries are particularly heavy operations.
I don't know if you generally work in low level embedded environments, 
but being able know and plan for that can be very critical.  It can
change how you approach your design.  When you work in systems where
your system clock is 1-4MHz, timing of operations does start to matter.

> > However, I honestly
> > wanted to know why Ada allowed one to setup the private extension but not
> > allow you to actually provide the functions (or if this was a GNAT issue or
> > if I was just not using the right syntax).  So the reason I care was a
> > thirst for knowledge of how things work.
> 
> Ada 2005 stuff, most of it makes little sense to me. It was some 
> halfhearted attempt to unite tagged types with tasks and protected 
> objects with no desire to actually do that...
> 
I'm just curious if or why the process was stopped half way instead of
abandoned or completed (again that is assuming I didn't use the wrong
syntax, in which case it's simply that I'm structuring the syntax wrong).

I don't really need to marry them with tagged types.  I do appreciate
the ability to dispatch over a group of related but different tasks
much more easily and the interfaces give that.  The way that Ada chose
to implement interfaces is one of many ways (not all of which would 
have required tagged types).

Re: Private extension of a synchronized interface

[Dmitry A. Kazakov]

On 2019-02-17 16:36, Jere wrote:
> On Sunday, February 17, 2019 at 9:52:42 AM UTC-5, Dmitry A. Kazakov wrote:
>> On 2019-02-17 14:46, Jere wrote:
>>> On Sunday, February 17, 2019 at 4:50:24 AM UTC-5, Dmitry A. Kazakov wrote:
>>>>
>>>> But synchronized interfaces are totally bogus from the software design
>>>> POV. It is a pure implementation aspect exposed. Why do you care?
>>>> Aggregate a protected object and delegate primitive operations to it.
>>>>
>>>
>>> That's what I am doing as my own solution.  I was intrigued with the code
>>> above as an alternate solution because it could potentially give a
>>> compile time indication that a procedure was a protected operation (as
>>> opposed to me relying on simply providing that via comments).
>>
>> Given to who? The compiler knows already, the user should not care. It
>> is an implementation aspect which simply does not belong here.
>>
> The compiler cannot always tell depending on how and where you call buried
> protected operations.

But it is the reverse. You do not promise not to implement it as a 
protected operation, you promise to do it protected straight away!

> I always prefer compile time catching over run time catching.

It is a weaker precondition, nothing to catch at all.

>>> A delegate non protected procedure has to rely on the comment.
>>
>> There is no contract that could require it protected. It is a property
>> of the object/task and no property of an operation. You could not do
>> anything with a task or protected object that would not resolve into a
>> protected action anyway.
> 
> Protected procedures/functions/entries are particularly heavy operations.
> I don't know if you generally work in low level embedded environments,
> but being able know and plan for that can be very critical.  It can
> change how you approach your design.  When you work in systems where
> your system clock is 1-4MHz, timing of operations does start to matter.

Again, you are talking about the reverse:

    type T is not synchronized but still limited interface; -- (:-))

and there is no actual use for this either.

As a general note, "heaviness" is non-functional, ergo cannot be in a 
contract.

>>> However, I honestly
>>> wanted to know why Ada allowed one to setup the private extension but not
>>> allow you to actually provide the functions (or if this was a GNAT issue or
>>> if I was just not using the right syntax).  So the reason I care was a
>>> thirst for knowledge of how things work.
>>
>> Ada 2005 stuff, most of it makes little sense to me. It was some
>> halfhearted attempt to unite tagged types with tasks and protected
>> objects with no desire to actually do that...
>>
> I'm just curious if or why the process was stopped half way instead of
> abandoned or completed (again that is assuming I didn't use the wrong
> syntax, in which case it's simply that I'm structuring the syntax wrong).

I think nobody had an idea how to make protected objects/tasks 
extensible. How would you override entries of a task buried in accept 
statements of the parent's task body?

Javaesque interface with a one-set inheritance seemed simple to do. It 
is no half way, you basically not even left the house.

> I don't really need to marry them with tagged types.  I do appreciate
> the ability to dispatch over a group of related but different tasks
> much more easily and the interfaces give that.  The way that Ada chose
> to implement interfaces is one of many ways (not all of which would
> have required tagged types).

Yet another half measure. If only tagged types may have classes then 
tasks must be kind of tagged.

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

Re: Private extension of a synchronized interface

[Jere]

On Sunday, February 17, 2019 at 11:28:40 AM UTC-5, Dmitry A. Kazakov wrote:
> <SNIPPED>
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

While dancing around the verbage and what defines a contract
is an interesting conversation, what I have taken away from 
the combination of your responses is that in Ada there is no
way to finish the declaration I provided that allows for the
operations to be overriden?  Is that correct?  Or is there a
syntax that I need to use to do this that I haven't figured
out?

Re: Private extension of a synchronized interface

[Simon Wright]

Jere <jhb.chat@gmail.com> writes:

>   -- The following line gives the error:
>   -- call to abstract procedure must be dispatching
>   
>   --v.p1;

If you replace this with the dispatching call

   Example.An_Interface'Class (v).p1;

it compiles & works just fine.

I'm far from being an expert on this, because I've never found the need
to use 'interface' at all, but when you say

      type An_Interface is synchronized interface;
      procedure p1(Self : in out An_Interface) is abstract;

      type Instance is synchronized new An_Interface with private;

you know that Instance provides a procedure p1, but you don't know
whether it's a task or protected entry or a protected procedure (or
even, to my surprise, a plain procedure with that profile, see Ada 2005
Rationale).

Of course the compiler knows, so you'd have thought that your v.p1 call
would be OK (and it _is_ OK if the full declaration of Example.Instance
is public).

But the actual problem comes from ARM 3.9.3(7)[1],

   A call on an abstract subprogram shall be a dispatching call;
   nondispatching calls to an abstract subprogram are not allowed.

... which has been the case since Ada 95!

[1] http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-3-9-3.html#p7

Re: Private extension of a synchronized interface

[Jere]

On Sunday, February 17, 2019 at 5:36:41 PM UTC-5, Simon Wright wrote:
> Jere writes:
> 
> >   -- The following line gives the error:
> >   -- call to abstract procedure must be dispatching
> >   
> >   --v.p1;
> 
> If you replace this with the dispatching call
> 
>    Example.An_Interface'Class (v).p1;
> 
> it compiles & works just fine.

Good Point!  Thanks!

> 
> I'm far from being an expert on this, because I've never found the need
> to use 'interface' at all, but when you say
> 
>       type An_Interface is synchronized interface;
>       procedure p1(Self : in out An_Interface) is abstract;
> 
>       type Instance is synchronized new An_Interface with private;
> 
> you know that Instance provides a procedure p1, but you don't know
> whether it's a task or protected entry or a protected procedure (or
> even, to my surprise, a plain procedure with that profile, see Ada 2005
> Rationale).
> 
> Of course the compiler knows, so you'd have thought that your v.p1 call
> would be OK (and it _is_ OK if the full declaration of Example.Instance
> is public).
> 
> But the actual problem comes from ARM 3.9.3(7)[1],
> 
>    A call on an abstract subprogram shall be a dispatching call;
>    nondispatching calls to an abstract subprogram are not allowed.
> 
> ... which has been the case since Ada 95!
> 
> [1] http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-3-9-3.html#p7

In the other part that I commented out I was trying to add a publically
available override to the interface operation, but haven't been successful.
Do you know of any syntax changes I might need to do to:

        -- The following lines give the errors:
        -- "p1" conflicts with declaration at line xxx
        -- and
        -- missing body for "p1"
       
        --overriding
        --procedure p1(Self : in out Instance); 

So I don't need to always dispatch?

Re: Private extension of a synchronized interface

[Dmitry A. Kazakov]

On 2019-02-18 01:36, Jere wrote:

> In the other part that I commented out I was trying to add a publically
> available override to the interface operation, but haven't been successful.
> Do you know of any syntax changes I might need to do to:
> 
>          -- The following lines give the errors:
>          -- "p1" conflicts with declaration at line xxx
>          -- and
>          -- missing body for "p1"
>         
>          --overriding
>          --procedure p1(Self : in out Instance);
> 
> So I don't need to always dispatch?

You never need dispatch. When a type is derived it inherits all 
primitive operations regardless overridings.

1. The type Instance in your example has p1

2. Since Instance is not abstract p1 of Instance cannot be abstract.

Therefore x.p1 must be legal.

The actual behavior is certainly a bug in the language or in the 
compiler or in both.

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

Re: Private extension of a synchronized interface

[Simon Wright]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

Jere <jhb.chat@gmail.com> writes:

> Do you know of any syntax changes I might need to do to:
>
>         -- The following lines give the errors:
>         -- "p1" conflicts with declaration at line xxx
>         -- and
>         -- missing body for "p1"
>        
>         --overriding
>         --procedure p1(Self : in out Instance); 
>
> So I don't need to always dispatch?

I'm not 100% sure why this works & the other doesn't - I think because
Instantiation.P1 is actually publicly visible.

Also not sure whether you could do away with the inner Instantiation.

Anyway,


[-- Attachment #2: Working example --]
[-- Type: test/plain, Size: 1137 bytes --]

Re: Private extension of a synchronized interface

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> You never need dispatch. When a type is derived it inherits all
> primitive operations regardless overridings.
>
> 1. The type Instance in your example has p1
>
> 2. Since Instance is not abstract p1 of Instance cannot be abstract.
>
> Therefore x.p1 must be legal.
>
> The actual behavior is certainly a bug in the language or in the
> compiler or in both.

You ought to distinguish between behaviour you disapprove of and
behaviour which is illegal in Ada-as-it-is when people are sking for
help with a current problem.

Re: Private extension of a synchronized interface

[Simon Wright]

[-- Attachment #1: Type: text/plain, Size: 731 bytes --]

Jere <jhb.chat@gmail.com> writes:

> In the other part that I commented out I was trying to add a publically
> available override to the interface operation, but haven't been successful.
> Do you know of any syntax changes I might need to do to:
>
>         -- The following lines give the errors:
>         -- "p1" conflicts with declaration at line xxx
>         -- and
>         -- missing body for "p1"
>        
>         --overriding
>         --procedure p1(Self : in out Instance); 
>
> So I don't need to always dispatch?

I'm not 100% sure why this works & the other doesn't - I think because
Instantiation.P1 is actually publicly visible.

Also not sure whether you could do away with the inner Instantiation.

Anyway,


[-- Attachment #2: working example --]
[-- Type: text/plain, Size: 1137 bytes --]

with Ada.Text_IO; use Ada.Text_IO;

procedure Hello is

   package Example is

      type An_Interface is synchronized interface;
      procedure P1 (Self : in out An_Interface) is abstract;

      package Instantiation is

         type Instance is synchronized new An_Interface with private;

         overriding
         procedure P1 (Self : in out Instance);

      private

         protected type Instance is new An_Interface with
            procedure Actual_P1;
         private
         end Instance;

      end Instantiation;

   end Example;

   package body Example is

      package body Instantiation is

         protected body Instance is
            procedure Actual_P1 is
            begin
               Put_Line("Did Something");
            end Actual_P1;
         end Instance;

         procedure P1 (Self : in out Instance) is
         begin
            Self.Actual_P1;
         end P1;

      end Instantiation;

   end Example;

   V : Example.Instantiation.Instance;

begin
   Put_Line("Hello, world!");

   --  dispatching ...
   Example.An_Interface'Class (V).P1;

   --  not dispatching
   V.P1;
end Hello;

Re: Private extension of a synchronized interface

[Dmitry A. Kazakov]

On 2019-02-18 09:29, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> You never need dispatch. When a type is derived it inherits all
>> primitive operations regardless overridings.
>>
>> 1. The type Instance in your example has p1
>>
>> 2. Since Instance is not abstract p1 of Instance cannot be abstract.
>>
>> Therefore x.p1 must be legal.
>>
>> The actual behavior is certainly a bug in the language or in the
>> compiler or in both.
> 
> You ought to distinguish between behaviour you disapprove of and
> behaviour which is illegal in Ada-as-it-is when people are sking for
> help with a current problem.

Right. Therefore I has not excluded possibility of a language bug.

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

Re: Private extension of a synchronized interface

[Jere]

On Monday, February 18, 2019 at 3:33:38 AM UTC-5, Simon Wright wrote:
> Jere writes:
> 
> > In the other part that I commented out I was trying to add a publically
> > available override to the interface operation, but haven't been successful.
> > Do you know of any syntax changes I might need to do to:
> >
> >         -- The following lines give the errors:
> >         -- "p1" conflicts with declaration at line xxx
> >         -- and
> >         -- missing body for "p1"
> >        
> >         --overriding
> >         --procedure p1(Self : in out Instance); 
> >
> > So I don't need to always dispatch?
> 
> I'm not 100% sure why this works & the other doesn't - I think because
> Instantiation.P1 is actually publicly visible.
> 
> Also not sure whether you could do away with the inner Instantiation.
> 
> Anyway,

Thanks!  That gives me something to work with.  I appreciate it.  I know
my questions can get frustrating, but I learn a lot better when I test
boundaries like this.  Even if other ways might be better, there may
come a time where the people who really know Ada are less in number so 
things like this can serve as teaching moments for mechanics of the
language.  Though the outstanding part of this is we don't know if this
is a language issue/feature or a GNAT issue (the original problem that is).

Maybe someone from the Arg can comment on what is intended to be allowed
and not allowed when it comes to extending synchronized interfaces.

Re: Private extension of a synchronized interface

[Jere]

On Monday, February 18, 2019 at 3:33:38 AM UTC-5, Simon Wright wrote:
> 
> Also not sure whether you could do away with the inner Instantiation.
> 
> Anyway,

Messed around with it.  The inner package isn't needed, at least for
GNAT.

Re: Private extension of a synchronized interface

[Simon Wright]

Jere <jhb.chat@gmail.com> writes:

> Though the outstanding part of this is we don't know if this is a
> language issue/feature or a GNAT issue (the original problem that is).
>
> Maybe someone from the Arg can comment on what is intended to be
> allowed and not allowed when it comes to extending synchronized
> interfaces.

I think perhaps there is a bug in GNAT after all, and I apologise to all
concerned for hasty remarks.

THIS COMPILES (not with -gnat95, which says 'no selector "V" for private
type "U" defined at line 6'):

   procedure Abstractedness is

      package Sample is
         type T is abstract tagged null record;
         --  or 'type T is interface;'
         procedure V (Self : in out T) is abstract;
         type U is new T with private;
      private
         type U is new T with null record;
         procedure V (Self : in out U);
      end Sample;

      package body Sample is
         procedure V (Self : in out U) is
         begin
            null;
         end V;
      end Sample;

      W : Sample.U;
   begin
      W.V;
   end Abstractedness;

----

The fact that you can implement an abstract operation of a synchronized
interface in a subprogram of the implementation is discussed in the Ada
2005 Rationale 5.3[1]:

   Unlike tagged record types we cannot derive a task or protected type
   from another task or protected type as well. So the derivation
   hierarchy can only be one level deep once we declare an actual task
   or protected type.

   The operations of these various interfaces are declared in the usual
   way and an interface composed of several interfaces has the
   operations of all of them with the same rules regarding duplication
   and overriding of an abstract operation by a null one and so on as
   for normal tagged types.

   When we declare an actual task or protected type then we must
   implement all of the operations of the interfaces concerned. This can
   be done in two ways, either by declaring an entry or protected
   operation in the specification of the task or protected object or by
   declaring a distinct subprogram in the same list of declarations (but
   not both). Of course, if an operation is null then it can be
   inherited or overridden as usual.

[1] https://www.adaic.org/resources/add_content/standards/05rat/html/Rat-5-3.html

Re: Private extension of a synchronized interface

[Randy Brukardt]

"Jere" <jhb.chat@gmail.com> wrote in message 
news:fd975d66-8e70-4e86-8a75-efc6061ef25c@googlegroups.com...
> I'll get to my ultimate goal later, but while following various
> rabbit trails, I came across a situation I couldn't solve.  GNAT
> allows you to make private extensions to synchronized interfaces
> and it allows you to complete those private extensions with
> protected types.  I can't, however, figure out how it overrides
> the abstract procedures and functions of the synchronized interface.
>
> If I don't specify an override and try to call the procedure, it complains
> that the procedure is abstract.  If I try to override the abstract
> function, it complains that the signature doesn't match the one in
> the protected body.  I don't know if this is a GNAT issue or
> something that Ada doesn't allow.  Here is some test code.  It
> compiles as is, but there are two parts that if you uncomment
> either one of those it fails to compile.
>
> ***********************************************************
>
> with Ada.Text_IO; use Ada.Text_IO;
>
> procedure Hello is
>
>    package Example is
>
>        type An_Interface is synchronized interface;
>        procedure p1(Self : in out An_Interface) is abstract;
>
>        type Instance is synchronized new An_Interface with private;
>
>        -- The following lines give the errors:
>        -- "p1" conflicts with declaration at line xxx
>        -- and
>        -- missing body for "p1"
>
>        --overriding
>        --procedure p1(Self : in out Instance);
>
>    private
>
>        -- Some hidden implementation types, constants, etc.
>
>        -- Instance full view is a protected type
>        protected type Instance is new An_Interface with
>            procedure p1;
>        private
>            -- some hidden stuff;
>        end Instance;
>
>    end Example;
>
>    package body Example is
>
>        protected body Instance is
>            procedure p1 is
>            begin
>                Put_Line("Did Something");
>            end p1;
>        end Instance;
>
>    end Example;
>
>    v : Example.Instance;
>
> begin
>  Put_Line("Hello, world!");
>
>  -- The following line gives the error:
>  -- call to abstract procedure must be dispatching
>
>  --v.p1;
> end Hello;
>
> ***********************************************************
>
> My ultimate goal is not having to declare a bunch of extra
> types and packages in the public view to only use them in the
> private view of the protected object.  I'd prefer that all
> of the private stuff actually be in a private section.  So
> I'm not tied to interfaces, but it was one attempt at getting
> stuff moved down to the private section.  But while I went
> down the interfaces rabbit hole, I just found the issue I
> ran into odd.
>
> Does anyone know how to create the correct overrides for
> the example above?
> 

Re: Private extension of a synchronized interface

[Randy Brukardt]

"Jere" <jhb.chat@gmail.com> wrote in message 
news:fd975d66-8e70-4e86-8a75-efc6061ef25c@googlegroups.com...
> I'll get to my ultimate goal later, but while following various
> rabbit trails, I came across a situation I couldn't solve.  GNAT
> allows you to make private extensions to synchronized interfaces
> and it allows you to complete those private extensions with
> protected types.  I can't, however, figure out how it overrides
> the abstract procedures and functions of the synchronized interface.
>
> If I don't specify an override and try to call the procedure, it complains
> that the procedure is abstract.

This appears to be a GNAT bug, although I'm not 100% certain.

When you inherit abstract routines for a concrete type, the routines 
"require overriding" routines. (Se 3.9.3(6/4). Such routines have to be 
overridden (somewhere), which can happen in the private part. And the 
ultimate routine should be treated as concrete - that is, you should be able 
to call it.

Since your private extension doesn't include the keyword "abstract", that 
makes the routines "shall be overridden". So I think this is a GNAT bug.

Almost everyone (and every compiler) confuses inheriting abstract 
subprograms with subprograms that require overriding; I know that the 
terminology and requirements were different in early Ada 9x, but why current 
compilers continue that mistake is a mystery to me.

The reason I don't say this for 100% certain is that "implemented by" is not 
exactly the same as "overriding" (for reasons that have nothing to do with 
this issue), and it's not clear to me that the 3.9.3(6) rule actually allows 
"implemented by". But, it's clear that the intent is that these are 
equivalent in such cases, and if someone disagress, I'd expect the ARG to 
take it up and fix the language.

What I'd suggest in this case is to create a self-testing example as a 
potential ACATS test. I'd guess that a case like this doesn't happen in the 
ACATS, but this a fundemental enough capabilitity that is makes sense for an 
example to be in the test suite. (Generally, we don't try to test 
combinations of rules in the ACATS, and this is such a combination. But 
there are cases where testing the individidual rules don't prove anything 
about the combination, and this appears to be such a case. That is, the 
implementation of protected type abstract rules are probably quite different 
from the normal subprogram rules, so just testing the normal case doesn't 
prove much. (You can find out details about writing ACATS tests at 
http://www.ada-auth.org/acats-files/4.1/docs/UG-E.HTM, although getting 
everything perfect is neither necessary nor likely).

Then submit the test to either the agent (agent@ada-auth.org) or to the 
ACATS-Test@ada-auth.org mailing list. And of course report the issue to 
AdaCore as well.

Since this is an Ada 2005 issue, it applies to a variety of other Ada 
compilers, and it should be checked for everyone. Moreover, having a test 
makes it easy to bring any objections to the ARG.

Your concrete subprogram declaration is legal, but I would expect that it 
needs a body. So forget that, it shouldn't be necessary in any case. (The 
inherited subprogram should be concrete by 3.9.3(6), and then either the 
type is legal (if properly overriding happens) or the unit is illegal --  
there are no other possibilities allowed by the language.)

                                             Randy.

Re: Private extension of a synchronized interface

[Egil H H]

On Monday, February 18, 2019 at 11:35:15 PM UTC+1, Randy Brukardt wrote:
> 
> This appears to be a GNAT bug, although I'm not 100% certain.

There's definitely at least one GNAT bug here.
Forcing a dispatching call on the interface (as suggested by Simon) works,
  Example.An_Interface'Class(v).p1; 

but forcing a dispatching call on the private extension, does not
  Example.Instance'Class(v).p1; 

It compiles and runs, but seems to call a null body...


-- 
~egilhh

Re: Private extension of a synchronized interface

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> I think perhaps there is a bug in GNAT after all, and I apologise to
> all concerned for hasty remarks.

Shall I report this? or will you, Jere?

Re: Private extension of a synchronized interface

[Simon Wright]

Egil H H <ehh.public@gmail.com> writes:

> On Monday, February 18, 2019 at 11:35:15 PM UTC+1, Randy Brukardt wrote:
>> 
>> This appears to be a GNAT bug, although I'm not 100% certain.
>
> There's definitely at least one GNAT bug here.
> Forcing a dispatching call on the interface (as suggested by Simon) works,
>   Example.An_Interface'Class(v).p1; 
>
> but forcing a dispatching call on the private extension, does not
>   Example.Instance'Class(v).p1; 
>
> It compiles and runs, but seems to call a null body...

Worse than that: it leaves the PO mangled! GCC 9.0.0 (which is built
with internal checks enabled: released versions aren't) raises an ICE
(internal compiler error),

+===========================GNAT BUG DETECTED==============================+
| 9.0.0 20190115 (experimental) (x86_64-apple-darwin15) Assert_Failure sem_disp.adb:491|

so the released version (CE, 8) rambles past this error, resulting in
the next call saying

raised PROGRAM_ERROR :
System.Tasking.Protected_Objects.Entries.Lock_Entries_With_Status:
protected object is finalized

Will report.

Re: Private extension of a synchronized interface

[Egil H H]

On Tuesday, February 19, 2019 at 12:29:23 PM UTC+1, Simon Wright wrote:
> Egil H H writes:
> 
> > On Monday, February 18, 2019 at 11:35:15 PM UTC+1, Randy Brukardt wrote:
> >> 
> >> This appears to be a GNAT bug, although I'm not 100% certain.
> >
> > There's definitely at least one GNAT bug here.
> > Forcing a dispatching call on the interface (as suggested by Simon) works,
> >   Example.An_Interface'Class(v).p1; 
> >
> > but forcing a dispatching call on the private extension, does not
> >   Example.Instance'Class(v).p1; 
> >
> > It compiles and runs, but seems to call a null body...
> 
> Worse than that: it leaves the PO mangled! GCC 9.0.0 (which is built
> with internal checks enabled: released versions aren't) raises an ICE
> (internal compiler error),
> 
> +===========================GNAT BUG DETECTED==============================+
> | 9.0.0 20190115 (experimental) (x86_64-apple-darwin15) Assert_Failure sem_disp.adb:491|
> 
> so the released version (CE, 8) rambles past this error, resulting in
> the next call saying
> 
> raised PROGRAM_ERROR :
> System.Tasking.Protected_Objects.Entries.Lock_Entries_With_Status:
> protected object is finalized
> 
> Will report.


Oh, that's worse, indeed.
I didn't investigate that far.


-- 
~egilhh

Re: Private extension of a synchronized interface

[Jere]

On Monday, February 18, 2019 at 5:35:15 PM UTC-5, Randy Brukardt wrote:
> "Jere" wrote in message 
> > I'll get to my ultimate goal later, but while following various
> > rabbit trails, I came across a situation I couldn't solve.  GNAT
> > allows you to make private extensions to synchronized interfaces
> > and it allows you to complete those private extensions with
> > protected types.  I can't, however, figure out how it overrides
> > the abstract procedures and functions of the synchronized interface.
> >
> > If I don't specify an override and try to call the procedure, it complains
> > that the procedure is abstract.
> 
> This appears to be a GNAT bug, although I'm not 100% certain.
> 
> <SNIPPED Explaination
Ok, thank you!  That makes it clearer.

> 
> What I'd suggest in this case is to create a self-testing example as a 
> potential ACATS test. I'd guess that a case like this doesn't happen in the 
> ACATS, but this a fundemental enough capabilitity that is makes sense for an 
> example to be in the test suite. (Generally, we don't try to test 
> combinations of rules in the ACATS, and this is such a combination. But 
> there are cases where testing the individidual rules don't prove anything 
> about the combination, and this appears to be such a case. That is, the 
> implementation of protected type abstract rules are probably quite different 
> from the normal subprogram rules, so just testing the normal case doesn't 
> prove much. (You can find out details about writing ACATS tests at 
> http://www.ada-auth.org/acats-files/4.1/docs/UG-E.HTM, although getting 
> everything perfect is neither necessary nor likely).
> 
> Then submit the test to either the agent (agent@ada-auth.org) or to the 
> ACATS-Test@ada-auth.org mailing list. And of course report the issue to 
> AdaCore as well.
> 
I'll take a look.  I've never dealt with ACATS before directly, so this
will be new territory for me.

Re: Private extension of a synchronized interface

[Jere]

On Tuesday, February 19, 2019 at 6:04:26 AM UTC-5, Simon Wright wrote:
> Simon Wright <simon@pushface.org> writes:
> 
> > I think perhaps there is a bug in GNAT after all, and I apologise to
> > all concerned for hasty remarks.
> 
> Shall I report this? or will you, Jere?

I can send something to Adacore if you like.  I'll link the google
groups page of this discussion in addition to the sample that fails.
If you think reporting it to FSF's GCC bug website is better, I'd 
defer to you instead.  I don't generally have good luck submitting
things to them without messing something up.  Last time I got fussed
at.  Which do you think is the better location:  Adacore or FSF GCC?

Re: Private extension of a synchronized interface

[Simon Wright]

Jere <jhb.chat@gmail.com> writes:

> On Tuesday, February 19, 2019 at 6:04:26 AM UTC-5, Simon Wright wrote:
>> Simon Wright <simon@pushface.org> writes:
>> 
>> > I think perhaps there is a bug in GNAT after all, and I apologise to
>> > all concerned for hasty remarks.
>> 
>> Shall I report this? or will you, Jere?
>
> I can send something to Adacore if you like.  I'll link the google
> groups page of this discussion in addition to the sample that fails.
> If you think reporting it to FSF's GCC bug website is better, I'd 
> defer to you instead.  I don't generally have good luck submitting
> things to them without messing something up.  Last time I got fussed
> at.  Which do you think is the better location:  Adacore or FSF GCC?

In this case, definitely AdaCore. Remember to put GNAT in the subject
line.

Re: Private extension of a synchronized interface

[Simon Wright]

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

> What I'd suggest in this case is to create a self-testing example as a
> potential ACATS test. I'd guess that a case like this doesn't happen
> in the ACATS, but this a fundemental enough capabilitity that is makes
> sense for an example to be in the test suite.

The only C test occurences of 'synchronized' are in c950001 and c954027;
both use class-wide objects or accesses.

Re: Private extension of a synchronized interface

[Jere]

On Wednesday, February 20, 2019 at 5:46:06 AM UTC-5, Simon Wright wrote:
> Jere writes:
> 
> > On Tuesday, February 19, 2019 at 6:04:26 AM UTC-5, Simon Wright wrote:
> >> Simon Wright <simon@pushface.org> writes:
> >> 
> >> > I think perhaps there is a bug in GNAT after all, and I apologise to
> >> > all concerned for hasty remarks.
> >> 
> >> Shall I report this? or will you, Jere?
> >
> > I can send something to Adacore if you like.  I'll link the google
> > groups page of this discussion in addition to the sample that fails.
> > If you think reporting it to FSF's GCC bug website is better, I'd 
> > defer to you instead.  I don't generally have good luck submitting
> > things to them without messing something up.  Last time I got fussed
> > at.  Which do you think is the better location:  Adacore or FSF GCC?
> 
> In this case, definitely AdaCore. Remember to put GNAT in the subject
> line.

Sent it to them.  

Re: Private extension of a synchronized interface

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lyo976mv2j.fsf@pushface.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> What I'd suggest in this case is to create a self-testing example as a
>> potential ACATS test. I'd guess that a case like this doesn't happen
>> in the ACATS, but this a fundemental enough capabilitity that is makes
>> sense for an example to be in the test suite.
>
> The only C test occurences of 'synchronized' are in c950001 and c954027;
> both use class-wide objects or accesses.

Makes sense. This case has to do with the 3.9.3 rules and how they apply to 
protected (and presumably task) interfaces. I doubt very much that was 
tested, or is even on the list of possible things to test. But of course 
real Ada user bugs are always of interest. Especially if they are rather 
fundemental to the feature. (Too bad I don't have a spell check on this 
reader. ;-)

                         Randy.