Task interface and entries with aliased parameters

Task interface and entries with aliased parameters

[Hadrien Grasland]

Hello,

Using GNAT GPL 2015, I am having some trouble with task interfaces which feature entries that take aliased parameters.

Whenever I try to implement one, GNAT refuses to compile the resulting code, claiming that my implementation does not match the associated interface. However, I am pretty convinced that it does. What I would like to know is if I am getting task interfaces wrong, or if this is a bug in GNAT that I should report.

Here is a basic code example that reproduces the problem :

===============================

procedure Main is

   -- Define a task interface with one method having an aliased output
   package Aliased_Entry_Params is
      type Aliased_Interface is task interface;
      procedure Aliased_Entry (Object : Aliased_Interface; Output : aliased out Integer) is abstract;
   end Aliased_Entry_Params;
   
   -- This task should implement the interface... but GNAT claims it doesn't
   task Aliased_Task is new Aliased_Entry_Params.Aliased_Interface with
      overriding entry Aliased_Entry (Output : aliased out Integer);
   end Aliased_Task;
   
   -- Dummy body
   task body Aliased_Task is
   begin
      accept Aliased_Entry (Output : aliased out Integer) do
         Output'Access.all := -256;
      end Aliased_Entry;
   end Aliased_Task;
   
begin
   null;
end Main;

===============================

And here is the GNAT compilation output on my computer :

main.adb:13:24: not subtype conformant with operation inherited at line 12
main.adb:13:24: aliased parameter mismatch
main.adb:13:24: not subtype conformant with declaration at line 7
main.adb:13:24: aliased parameter mismatch
gprbuild: *** compilation phase failed

Thanks in advance for your help !
Hadrien

Re: Task interface and entries with aliased parameters

[AdaMagica]

RM 9.1(9.8/2) seems to be fulfilled:
the inherited subprogram is implemented by a single entry of the task type; in which case its prefixed view profile shall be subtype conformant with that of the task entry. 

But I've never used task interfaces myself.

Re: Task interface and entries with aliased parameters

[Jeffrey R. Carter]

On 10/21/2015 01:54 AM, Hadrien Grasland wrote:
> 
> Using GNAT GPL 2015, I am having some trouble with task interfaces which feature entries that take aliased parameters.

"IMHO, Interfaces are worthless." -- Randy Brukardt

-- 
Jeff Carter
"That was the most fun I've ever had without laughing."
Annie Hall
43

Re: Task interface and entries with aliased parameters

[Hadrien Grasland]

> 
> "IMHO, Interfaces are worthless." -- Randy Brukardt

I would not agree with that, they are a nice way to express that multiple objects with different internals can be manipulated in the same way.

UNIX files, for example, are an interface. You have no idea what they represent, but you know that you can most likely sequentially stream bytes to and from them.

Re: Task interface and entries with aliased parameters

[Dmitry A. Kazakov]

On Wed, 21 Oct 2015 10:01:01 -0700, Jeffrey R. Carter wrote:

> On 10/21/2015 01:54 AM, Hadrien Grasland wrote:
>> 
>> Using GNAT GPL 2015, I am having some trouble with task interfaces which feature entries that take aliased parameters.
> 
> "IMHO, Interfaces are worthless." -- Randy Brukardt

He possibly meant Java interfaces as opposed to existing Ada 95 abstract
types. Ada 95 abstract type did everything Java interface do and more.

Interface as a separate type is indeed worthless. Interface as properties
of a type, a package, a subroutine is more than useful. It is impossible to
program anything without the concept of the interface.

If Ada were a better language you would be able to strip the implementation
from any type:

Interface = Type - Implementation

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

Re: Task interface and entries with aliased parameters

[Hadrien Grasland]

> He possibly meant Java interfaces as opposed to existing Ada 95 abstract
> types. Ada 95 abstract type did everything Java interface do and more.
> 
> Interface as a separate type is indeed worthless. Interface as properties
> of a type, a package, a subroutine is more than useful. It is impossible to
> program anything without the concept of the interface.
> 
> If Ada were a better language you would be able to strip the implementation
> from any type:
> 
> Interface = Type - Implementation

I like the idea of interfaces as separate types because it solves all the problems of multiple inheritance, and provides a very nice way to specify a shared interface to multiple objects and have the compiler enforce that shared interface as the objects are refactored, rewritten, etc.

Regarding the last point, would you mean having a type attribute like Type'Interface, that defines an interface composed of all of the type's primitive operations ?

But if so, is it really reasonable to define an interface from an implementation ? Shouldn't the interface be considered as a separate entity that is shared by multiple types ?

Re: Task interface and entries with aliased parameters

[Jeffrey R. Carter]

On 10/21/2015 12:21 PM, Dmitry A. Kazakov wrote:
> On Wed, 21 Oct 2015 10:01:01 -0700, Jeffrey R. Carter wrote:
>>
>> "IMHO, Interfaces are worthless." -- Randy Brukardt
> 
> He possibly meant Java interfaces as opposed to existing Ada 95 abstract
> types. Ada 95 abstract type did everything Java interface do and more.

He was referring to the Ada reserved word "interface".

-- 
Jeff Carter
"That was the most fun I've ever had without laughing."
Annie Hall
43

Re: Task interface and entries with aliased parameters

[Dmitry A. Kazakov]

On Wed, 21 Oct 2015 12:46:19 -0700, Jeffrey R. Carter wrote:

> On 10/21/2015 12:21 PM, Dmitry A. Kazakov wrote:
>> On Wed, 21 Oct 2015 10:01:01 -0700, Jeffrey R. Carter wrote:
>>>
>>> "IMHO, Interfaces are worthless." -- Randy Brukardt
>> 
>> He possibly meant Java interfaces as opposed to existing Ada 95 abstract
>> types. Ada 95 abstract type did everything Java interface do and more.
> 
> He was referring to the Ada reserved word "interface".

Surely no reserved word required either.

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

Re: Task interface and entries with aliased parameters

[Dmitry A. Kazakov]

On Wed, 21 Oct 2015 12:45:58 -0700 (PDT), Hadrien Grasland wrote:

>> He possibly meant Java interfaces as opposed to existing Ada 95 abstract
>> types. Ada 95 abstract type did everything Java interface do and more.
>> 
>> Interface as a separate type is indeed worthless. Interface as properties
>> of a type, a package, a subroutine is more than useful. It is impossible to
>> program anything without the concept of the interface.
>> 
>> If Ada were a better language you would be able to strip the implementation
>> from any type:
>> 
>> Interface = Type - Implementation
> 
> I like the idea of interfaces as separate types because it solves all the
> problems of multiple inheritance,

There is no problem with MI, whatsoever. MI problems is an urban legend.

> and provides a very nice way to specify
> a shared interface to multiple objects and have the compiler enforce that
> shared interface as the objects are refactored, rewritten, etc.

Dangerous and useless. The [public] interface is everything declared
publicly. If something publicly declared does not belong to the interface,
the language is poorly designed and broken.

> Regarding the last point, would you mean having a type attribute like
> Type'Interface, that defines an interface composed of all of the type's
> primitive operations ?

There is no need in such attribute. The type already denotes its interface. 

What you need is a construct to inherit from a type dropping the
implementation or some parts of. Presently in Ada you always inherit both
the interface and the implementation. The later can be slightly altered by
overriding operations and/or extending the representation. This is a very
limited model unsuitable for scalar and by-value types.

> But if so, is it really reasonable to define an interface from an
> implementation?

You simply could not do that. Implementation is not interface, per
definition of. If a language does not support clear syntactic separation of
interface and implementation, it is a bad language. Ada does support it,
with some exceptions, though. So, you should always be able to see what is
interface and what is an implementation of.

> Shouldn't the interface be considered as a separate
> entity that is shared by multiple types?

For each interface there exists single type it belongs to. You cannot have
a type interface without the type. Ada's declaration of an interface is
just a type declaration.

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

Re: Task interface and entries with aliased parameters

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1e09jksdqcfyv.8f80k06gl5ye$.dlg@40tude.net...
> On Wed, 21 Oct 2015 10:01:01 -0700, Jeffrey R. Carter wrote:
>
>> On 10/21/2015 01:54 AM, Hadrien Grasland wrote:
>>>
>>> Using GNAT GPL 2015, I am having some trouble with task interfaces which 
>>> feature entries that take aliased parameters.
>>
>> "IMHO, Interfaces are worthless." -- Randy Brukardt
>
> He possibly meant Java interfaces as opposed to existing Ada 95 abstract
> types. Ada 95 abstract type did everything Java interface do and more.

Yes, precisely. Ada 95 already had a more powerful feature needed to share 
implementations.

Sharing interfaces *sounds* nice, but it's impossible in practice because in 
almost all circumstances you need parameters of different types for 
different "instances" ("instances" not in the Ada sense). Think container 
interfaces, for example - the element type is almost always different.

Interfaces might work in a language where all types are necessarily tagged 
and all derived from a common ancestor, but that language is not at all Ada. 
(And you'd have forced most type checking to runtime, going the wrong way.)

                                      Randy.

Re: Task interface and entries with aliased parameters

[Bob Duff]

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

> Sharing interfaces *sounds* nice, but it's impossible in practice because in 
> almost all circumstances you need parameters of different types for 
> different "instances" ("instances" not in the Ada sense). Think container 
> interfaces, for example - the element type is almost always different.

Different from what?  Maybe you could show some code that illustrates
your point.

- Bob

Re: Task interface and entries with aliased parameters

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> Sharing interfaces *sounds* nice, but it's impossible in practice because in 
> almost all circumstances you need parameters of different types for 
> different "instances" ("instances" not in the Ada sense). Think container 
> interfaces, for example - the element type is almost always different.

Java has generics for that now.

Re: Task interface and entries with aliased parameters

[Dmitry A. Kazakov]

On Wed, 28 Oct 2015 12:48:05 -0500, Randy Brukardt wrote:

> Think container 
> interfaces, for example - the element type is almost always different.

It is always same. The interface of a container element is being copyable
(e.g. type T(<>) is private). For sets it also has "=". For ordered
containers must include "<" etc.

Other interfaces are irrelevant to the container. The question of
constraining a container to keep only elements of certain *other*
interfaces, e.g. basket of apples vs. one of oranges does not change the
fact that apples and oranges are both fruits, could be put in a basket etc.
They still share the "containment" interface.

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

Re: Task interface and entries with aliased parameters

[Randy Brukardt]

"Bob Duff" <bobduff@theworld.com> wrote in message 
news:87lham3hyu.fsf@theworld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> Sharing interfaces *sounds* nice, but it's impossible in practice because 
>> in
>> almost all circumstances you need parameters of different types for
>> different "instances" ("instances" not in the Ada sense). Think container
>> interfaces, for example - the element type is almost always different.
>
> Different from what?  Maybe you could show some code that illustrates
> your point.

Backing up a bit: an "interface" is just a type and its operations 
(primitive operations in Ada jargon). An interface (Ada term) just gives a 
single name to that set. The problem is, that it is rare that you have more 
than one "interface" in a program (or library, or anything) where the 
operations all have the same parameter profiles.

A container (say a map) is an example. A map interface sounds useful and 
attractive, but it's an illusion. Many of the operations of a map have 
parameters of the element type. And those are likely to be different, 
unrelated types. (Indeed, if your compiler doesn't share generic bodies, 
it's almost guaranteed as you'll want to have all containers with a 
particular element type share an instance in order to avoid code bloat -- in 
which case there would never be a use for an interface.)

The only way for such a map interface to be useful is to have one for some 
related hierarchy of types. But that either forces all the type checking to 
runtime (since the interface can only take Root'Class), or some sort of 
co-derivation scheme (not part of Ada) in order to derive multiple types in 
lock-step. (I've tried to figure out how to make such a scheme work in Ada 
terms, but I've failed; you get weird situations of inherited routines where 
the types don't work out.)

You could also put such an interface into a generic to parameterize the 
different types, but that doesn't buy you anything over using a similar 
generic directly.

I could see how interfaces might make some sense in a language where 
everything is descended from a single type (Object in Java), but Ada is far 
away from that. Thus, I put Ada interfaces with the group of mistaken 
features in Ada: anonymous access types, coextensions, interfaces. I fault 
myself in part for those mistakes, because I didn't recognize how truely 
useless (and even damaging) these things would turn out to be.

                                          Randy.

Re: Task interface and entries with aliased parameters

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87611qvkpr.fsf@jester.gateway.sonic.net...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> Sharing interfaces *sounds* nice, but it's impossible in practice because 
>> in
>> almost all circumstances you need parameters of different types for
>> different "instances" ("instances" not in the Ada sense). Think container
>> interfaces, for example - the element type is almost always different.
>
> Java has generics for that now.

Sure, and once you have generics, you have no need for interfaces. (At least 
if you assume, as I do, that static checking is better than dynamic 
checking.)

                                  Randy.

Re: Task interface and entries with aliased parameters

[Eryndlia Mavourneen]

On Wednesday, October 28, 2015 at 12:48:08 PM UTC-5, Randy Brukardt wrote:
> . . .
> Sharing interfaces *sounds* nice, but it's impossible in practice ...

I currently am building a design using a family of task interfaces.  I find this is a nice way to have related tasks working together, some entries' being the same among the tasks, and some entries' being specific to certain tasks.

Yes, there are other ways to manage this, but I find the family of tasks a clean, easy-to-understand concept; plus, it's fun.

It also is important to remember that in many ways we are limited by our tools:  The better abstractions that are available embodied in our tools the better our tools can help us to develop innovative ideas based on those tools.

Eryndlia Mavourneen
efmavourneen@hush.ai