Re: Generic private type declaration

["Alejandro R. Mosteo" <alejandro@mosteo.com>]

On 28/11/16 22:32, Randy Brukardt wrote:
> For what it's worth, Janus/Ada is wrong here (it probably isn't making the
> recheck of the instance; all of those have to be manually programmed and we
> pretty much only implemented the checks that we've seen in ACATS tests or in
> our own examples).
>
> The issue in this case is that type Y is a visible, tagged type outside of
> the instance. In that case, we can't allow a derivation without an extension
> (both for consistency reasons and I believe there also are semantic
> differences between tagged and untagged types).
>
> But this is the one rule that we intentionally do not use the standard
> boilerplate about the legality rule also applying in the private part.
> Therefore, your example is legal so long as the derived type is not visible
> outside of the generic.  Specifically, I think (I didn't try it) that:

Thanks for the explanation, Randy, I begin to see the rationale and 
ramifications of this. Although my example was simplified, it was from a 
actual case in which indeed the new type was in the public part. I guess 
I had never encountered this particular situation in 10+ years of Ada so 
it got me by surprise.

Cheers,
Alex.


>     generic
>        type X is private;
>     package Untagged is
>     private
>        type Y is new X;
>     end Untagged;
>
> In this case, there is no place where Y would ever be a tagged type, and
> thus it isn't a problem for this to be legal.
>
> The general principle is that all Ada legality rules are rechecked in the
> specification of an instance, using the properties of the actual parameters.
> In most cases (for most rules), this doesn't matter (nothing changes), but
> there are cases where it matters and those are potentially
> contract-breaking. That's annoying, but it is an intergral part of the Ada
> model for generics (the alternative would have been to use assume-the-worst
> rules in generic specifications, as is done in bodies, but that would make
> generics almost useless for tagged types -- no extensions could be done in
> generic specs under such a rule -- in particular, a mix-in generic would not
> be possible. So, yes, Dmitry, the language could strengthen contracts this
> way -- if one didn't care about usability [or compatibility]).
>
>                                            Randy.
>
> "Alejandro R. Mosteo" <alejandro@mosteo.com> wrote in message
> news:o1hh1b$13v$1@dont-email.me...
>> On 26/11/16 20:18, Tero Koskinen wrote:
>>> 26.11.2016, 10.45, Jacob Sparre Andersen wrote:
>>>> Alejandro R. Mosteo wrote:
>>>>
>>>>> I get in both gnat 4.9.3 and gpl2016 the following error:
>>>>>
>>>>> b001_tagged.adb:15:04: instantiation error at line 7
>>>>> b001_tagged.adb:15:04: type derived from tagged type must have
>>>>> extension
>>>>> gnatmake: "b001_tagged.adb" compilation error
>>> ...
>>>> I suspect that this is an error due to how GNAT expands generics.  It
>>>> might be useful to try to see how Janus/Ada and ICC/Ada treats it.  If I
>>>> remember correctly, Janus/Ada implements generics differently from GNAT.
>>>
>>> Janus/Ada 3.1.2c result here, just a warning on line 13:
>>> Input File Is C:\Work\mosteo-generic\B001_TAGGED.ADB
>>> Pass II
>>> Expected J2inst duplication to be the same
>>>
>>>
>>> In File C:\Work\mosteo-generic\B001_TAGGED.ADB(13)
>>> --------------
>>>    12:
>>>    13:     type Void is tagged null record;
>>> ----------------^
>>> *WARNING* Construct allowed only in a package specification (6.4.9)
>>> Expected J2inst duplication to be the same
>>> Bad or locked TREEFLAG.IN file -- see J3Tree_Debug
>>> Pass III - JCode
>>> Pass IV - 80386 Family
>>> Creating C:\Work\mosteo-generic\B001_TAG.SRL
>>> Thank You For Using JANUS/Ada
>>> (...)
>>
>> Thanks to everyone that answered/took the time to test.
>>
>> So, to summarize: Janus/Ada accepts it, Gnat does not, and some other
>> compiler used by G.B. also rejects it.
>>
>> Cheers,
>> Alex.
>>
>>>
>>>>
>>>> Greetings,
>>>>
>>>> Jacob
>>>>
>>>
>>> Yours,
>>>  Tero
>>>
>>
>
>