Re: Private extension of a synchronized interface

["Randy Brukardt" <randy@rrsoftware.com>]

"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.