User-Defined Reference in a Task Type Discriminant Compiler Bug?

User-Defined Reference in a Task Type Discriminant Compiler Bug?

[Eryndlia Mavourneen]

Dmitry spurred me to investigate user-defined references.

-----

1) The following code does not compile; however, it seems to abide by the LRM rules in 4.1.5:

   type Inc_Type is not null access procedure (To_Increment : in out Integer);
   
   task type T (Incrementing_Procedure : Inc_Type)
   with Implicit_Dereference => Incrementing_Procedure;

and fails with the error

   not an access discriminant of "T"

referencing the aspect clause.

-----

2) Adding "access" before the discriminant type in the task declaration compiles:

   type Inc_Type is not null access procedure (To_Increment : in out Integer);
   
   task type T (Incrementing_Procedure : access Inc_Type)
   with Implicit_Dereference => Incrementing_Procedure;

but I believe that this will produce an access of an access, no?  The declaration of Inc_Type is not possible, of course, without the keyword "access".

-----

3) I tried pleasing the compiler by splitting the declaration, as:

   type Inc_Type is access procedure (To_Increment : in out Integer);
   
   task type T (Incrementing_Procedure : not null Inc_Type)
   with Implicit_Dereference => Incrementing_Procedure;

but Gnat still produces the same error message for the aspect.

-----

Note that the declaration of Inc_Type in (1) is properly recognized as an access-to-subprogram type without the aspect clause.  I find it odd that the declaration of the discriminant + aspect clause given a similar circumstance will not compile.  It appears to prevent implicitly the type of construct in (1), which seems to me to be legal Ada code.

-----

Eryndlia F. Mavourneen

Re: User-Defined Reference in a Task Type Discriminant Compiler Bug?

[Shark8]

This is a bug in GNAT's GPL 2012, I submitted a report on a similar issue regarding implicit deference and they said the issue was fixed in the PRO edition, which means it *should* be fixes in the 2013 GPL release.

Re: User-Defined Reference in a Task Type Discriminant Compiler Bug?

[Adam Beneschan]

On Thursday, March 21, 2013 8:11:08 AM UTC-7, Eryndlia Mavourneen wrote:
> Dmitry spurred me to investigate user-defined references.
> 

> 1) The following code does not compile; however, it seems to abide by the LRM rules in 4.1.5:
>    type Inc_Type is not null access procedure (To_Increment : in out Integer);
> 
>    task type T (Incrementing_Procedure : Inc_Type)
>    with Implicit_Dereference => Incrementing_Procedure; 
>
> and fails with the error
>  
>    not an access discriminant of "T"
> 
> referencing the aspect clause.

Right.  An "access discriminant" isn't any old discriminant with an access type; 
3.7(9/2) says

"A discriminant that is defined by an access_definition is called an access discriminant and is of an anonymous access type."

So to be an "access discriminant" it has to have the word "access" in it, e.g.

task type T (Incrementing_Procedure : 
               not null access procedure (To_Increment : in out integer)) 
   with Implicit_Dereference => Incrementing_Procedure; 

 
> 2) Adding "access" before the discriminant type in the task declaration compiles:
> 
>    type Inc_Type is not null access procedure (To_Increment : in out Integer);
> 
>    task type T (Incrementing_Procedure : access Inc_Type)
>    with Implicit_Dereference => Incrementing_Procedure;
> 
> but I believe that this will produce an access of an access, no?

Right.  I don't think that's what you want.

                        -- Adam

Re: User-Defined Reference in a Task Type Discriminant Compiler Bug?

[Simon Wright]

Adam Beneschan <adam@irvine.com> writes:

> task type T (Incrementing_Procedure : 
>                not null access procedure (To_Increment : in out integer)) 
>    with Implicit_Dereference => Incrementing_Procedure; 

This still fails to compile with GCC 4.8.0 (prerelease).

This compiles:

   task type S (Disc : not null access Integer)
     with Implicit_Dereference => Disc;

so it looks like a bug related to the 'access procedure'.

Mind you, I've no idea what it's supposed to mean ...

Re: User-Defined Reference in a Task Type Discriminant Compiler Bug?

[Randy Brukardt]

"Eryndlia Mavourneen" <eryndlia@gmail.com> wrote in message 
news:4ef5e6b7-aab3-4229-a245-97dfc5861b8d@googlegroups.com...
...
>Note that the declaration of Inc_Type in (1) is properly recognized as an 
>access-to-subprogram
>type without the aspect clause.  I find it odd that the declaration of the 
>discriminant + aspect clause
>given a similar circumstance will not compile.  It appears to prevent 
>implicitly the type of construct
>in (1), which seems to me to be legal Ada code.

It's not, Adam explained why. "Access discriminant" only refers to 
discriminants with an anonymous access type. This is important because 
special accessibility rules apply to such discriminants, and those 
accessibility rules are what makes it safe to return these things. 
(Essentially, it is almost impossible to copy the access value, and that 
means that it can only be used for immediate dereferencing.)

As far as using an access-to-subprogram in one of these, I don't think we 
ever considered that. It's not particularly useful, either, as the primary 
intention was to provide convinient write-in-place for elements of 
containers. But you can never write to a subprogram call. You can get the 
same effect by just returning the access type from a function; you don't 
need the "Implicit_Dereference" mechanism for that. So it doesn't surprise 
me that it doesn't work in GNAT.

I don't understand your use-case, either. If you want to call the 
access-to-subprogram discriminant from inside the task, just do that -- the 
Implicit_Dereference is not necessary. And if you want the routine to 
somehow call the task, I don't think that's likely to work -- you won't be 
able to get access to the task object from inside the subprogram and thus 
you can't call an operation of the task from there. So I don't see any point 
to what you're trying to do.

                                  Randy.

Re: User-Defined Reference in a Task Type Discriminant Compiler Bug?

[Eryndlia Mavourneen]

Yes.  Thank you, everyone.  I agree with Randy that it is virtually useless; however, it seemed to me to be legal Ada and so I decided to see how far I could push the definition.  That little word "anonymous" makes a lot of sense.  I am coming to a much better appreciation of why Ada uses it.

I will play with it a little more in the morning.

-- Eryndlia F. Mavourneen