Interfaces and private types

Interfaces and private types

[Philippe Tarroux]

Hi again,

There is no compilation problem with the following code :

package Test_Interfaces is
  
   type Int is synchronized interface;
   procedure Init (I : in out Int) is abstract;
  
   type T is new Int with private;
  
private
  
   task type T is
      entry Init;
   end T;
end Test_Interfaces;

but, in a main program when I declare an object (i can't see it is a 
task) of type T, the compiler tells me that Init must be overriden. It 
is of course overriden by the entry of the task which is not explicitly 
visible. Having to provide Init explicitly prevents to hide the type of 
T although the syntax of the call (Obj.Init) is the same for a task 
entry or a procedure.

Does anybody know if there is a reason why in this case one cannot admit 
that Init is implicitly defined?

Philippe Tarroux

Re: Interfaces and private types

[Georg Bauhaus]

Philippe Tarroux schrieb:
> Hi again,
> 
> There is no compilation problem with the following code :
> 
> package Test_Interfaces is
>  
>   type Int is synchronized interface;
>   procedure Init (I : in out Int) is abstract;
>  
>   type T is new Int with private;
>  
> private
>  
>   task type T is
>      entry Init;
>   end T;
> end Test_Interfaces;
> 
> 

What do you get for

   task type T is new Int with  -- which it is, a new Int
      overriding entry Init;  -- which it is, overriding I suppose
   end T;

Re: Interfaces and private types

[Randy Brukardt]

"Philippe Tarroux" <philippe.tarroux@limsi.fr> wrote in message
news:fnl2in$k49$1@news2.u-psud.fr...
> Hi again,
>
> There is no compilation problem with the following code :
>
> package Test_Interfaces is
>
>    type Int is synchronized interface;
>    procedure Init (I : in out Int) is abstract;
>
>    type T is new Int with private;
>
> private
>
>    task type T is
>       entry Init;
>    end T;
> end Test_Interfaces;

As written, this is illegal because type T does not have the interface Int.
Specifically, it violates 7.3(7.3/2): "the partial view shall be a
descendant of an interface type (see 3.9.4) if and only if the full type is
a descendant of the interface type."

Assuming that this is just a mistake in your interface and you meant

   task type T is new Int with

then your program is legal, and you should complain your your compiler
vendor about the bug. In no case should there be an error on the declaration
of the object, so that makes it pretty clear that there is a compiler bug.

You could work around the bug with something like:

package Test_Interfaces is

   type Int is synchronized interface;
   procedure Init (I : in out Int) is abstract;

   type T is new Int with private;
   overriding procedure Init (I : in out T);

private

   task type T is new Int with
      entry Init;
   end T;
end Test_Interfaces;

and then have
    procedure Init (I : in out T) is
    begin
          I.Init;
    end Init;
in the body. (But note that this runs into a known bug in the Ada standard,
so it isn't clear that the code will work right.)

                              Randy.

Re: Interfaces and private types

[Philippe Tarroux]

Randy Brukardt wrote:
> Specifically, it violates 7.3(7.3/2): "the partial view shall be a
> descendant of an interface type (see 3.9.4) if and only if the full type is
> a descendant of the interface type."
>   
> As written, this is illegal because type T does not have the interface 
> Int.
As it is written the compiler i use doesn't mention any error and i 
interpreted this construct as legal because :

1/ the interface is synchronized thus allowing to derive concurrent or 
non concurrent types
2/ The partial view is a descendant of the interface type
3/ The full view precises that the partial view correspond to a 
concurrent type but hides this detail to the user

Writing, as you propose

task type T is new Int with private;

tells the user that T is a concurrent type, what precisely i wanted to 
avoid.
> Assuming that this is just a mistake in your interface and you meant
>
>    task type T is new Int with
>
> then your program is legal, and you should complain your your compiler
> vendor about the bug. In no case should there be an error on the declaration
> of the object, so that makes it pretty clear that there is a compiler bug.
>
> You could work around the bug with something like:
>
> package Test_Interfaces is
>
>    type Int is synchronized interface;
>    procedure Init (I : in out Int) is abstract;
>
>    type T is new Int with private;
>    overriding procedure Init (I : in out T);
>
> private
>
>    task type T is new Int with
>       entry Init;
>    end T;
> end Test_Interfaces;
>
> and then have
>     procedure Init (I : in out T) is
>     begin
>           I.Init;
>     end Init;
> in the body. (But note that this runs into a known bug in the Ada standard,
> so it isn't clear that the code will work right.)
>   
But the overriding procedure Init needs to be redefined both as an entry 
of T and as a procedure. I assume that when i will be trying to call 
O.Init with O a type T task there will be a mistake due to the double 
definition.

But, anyway, thanks a lot for the comments. I am waiting for comments 
from the guys who are in charge of the gnat compiler.

Philippe Tarroux

Re: Interfaces and private types

[Georg Bauhaus]

Philippe Tarroux schrieb:
> Randy Brukardt wrote:
>> Specifically, it violates 7.3(7.3/2): "the partial view shall be a
>> descendant of an interface type (see 3.9.4) if and only if the full 
>> type is
>> a descendant of the interface type."
>>   As written, this is illegal because type T does not have the 
>> interface Int.
> As it is written the compiler i use doesn't mention any error and i 
> interpreted this construct as legal because :
> 
> 1/ the interface is synchronized thus allowing to derive concurrent or 
> non concurrent types
> 2/ The partial view is a descendant of the interface type
> 3/ The full view precises that the partial view correspond to a 
> concurrent type but hides this detail to the user

I'd rather think that the compiler should diagnose conflicting
declaration of T in the private part as the private T does not
declare a relation with the public T.


If you do not want to derive T publicly, why not

package Test_Interfaces is

   type Int is synchronized interface;
   procedure Init (I : in out Int) is abstract;

   type T is limited private;

private

   task type T is new Int with
      overriding entry Init;
   end T;
end Test_Interfaces;

Re: Interfaces and private types

[Philippe Tarroux]

Georg Bauhaus a �crit :
> Philippe Tarroux schrieb:
>> Randy Brukardt wrote:
>>> Specifically, it violates 7.3(7.3/2): "the partial view shall be a
>>> descendant of an interface type (see 3.9.4) if and only if the full 
>>> type is
>>> a descendant of the interface type."
>>>   As written, this is illegal because type T does not have the 
>>> interface Int.
>> As it is written the compiler i use doesn't mention any error and i 
>> interpreted this construct as legal because :
>>
>> 1/ the interface is synchronized thus allowing to derive concurrent 
>> or non concurrent types
>> 2/ The partial view is a descendant of the interface type
>> 3/ The full view precises that the partial view correspond to a 
>> concurrent type but hides this detail to the user
>
> I'd rather think that the compiler should diagnose conflicting
> declaration of T in the private part as the private T does not
> declare a relation with the public T.
Yes I agree if one adopt the principle that an explicity declaration is 
more readable (and more in accordance with the general Ada philosophy). 
It is indeed true that the relation between the public and private T's 
was implicit in my example.
>
> If you do not want to derive T publicly, why not
>
> package Test_Interfaces is
>
>   type Int is synchronized interface;
>   procedure Init (I : in out Int) is abstract;
>
>   type T is limited private;
>
> private
>
>   task type T is new Int with
>      overriding entry Init;
>   end T;
> end Test_Interfaces;
>
I agree too.Your solution removes the ambiguity.

Philippe Tarroux

Re: Interfaces and private types

[Randy Brukardt]

"Philippe Tarroux" <philippe.tarroux@limsi.fr> wrote in message
news:fnmruc$ive$1@news2.u-psud.fr...
> Randy Brukardt wrote:
> > Specifically, it violates 7.3(7.3/2): "the partial view shall be a
> > descendant of an interface type (see 3.9.4) if and only if the full type
is
> > a descendant of the interface type."
> >
> > As written, this is illegal because type T does not have the interface
> > Int.
> As it is written the compiler i use doesn't mention any error and i
> interpreted this construct as legal because :
>
> 1/ the interface is synchronized thus allowing to derive concurrent or
> non concurrent types

Sure.

> 2/ The partial view is a descendant of the interface type

Sure.

> 3/ The full view precises that the partial view correspond to a
> concurrent type but hides this detail to the user

Sure.

> Writing, as you propose
>
> task type T is new Int with private;

That's not what I proposed. You have to repeat the interface name on the
full type declaration, and you did not write that in your original question.

package Test_Interfaces is

   type Int is synchronized interface;
   procedure Init (I : in out Int) is abstract;

   type T is new Int with private;

private
   --task type T is -- This is what you originally had, and it is illegal.
   type type T is new Int with -- This is legal, and presumably is what you
meant.
      entry Init;
   end T;
end Test_Interfaces;

I again refer you to 7.3(7.3/2) in the RM.

...
> > You could work around the bug with something like:
...
> But the overriding procedure Init needs to be redefined both as an entry
> of T and as a procedure. I assume that when i will be trying to call
> O.Init with O a type T task there will be a mistake due to the double
> definition.

You shouldn't assume that (although you'd be right as the language stands).
The intent was the prefixed notation only be used when no other
interpretation is possible (that is, it works like a use clause). Thus the
direct call to the entry would be prefered. Unfortunately, the rules for
that aren't actually in the RM.

Thus you might be right, in that you would have a risk of running into
another compiler bug. Of course, there is no requirement that the procedure
and the entry have the same name in this case, so the issue is easily
avoided.

> But, anyway, thanks a lot for the comments. I am waiting for comments
> from the guys who are in charge of the gnat compiler.

If you want that, you probably have to report a bug to them. This is an Ada
discussion group, not a bug reporting forum!

                                                   Randy.