comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Generic private type declaration
Date: Mon, 28 Nov 2016 15:32:34 -0600
Date: 2016-11-28T15:32:34-06:00	[thread overview]
Message-ID: <o1i7nt$3m1$1@franka.jacob-sparre.dk> (raw)
In-Reply-To: o1hh1b$13v$1@dont-email.me

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:

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


  reply	other threads:[~2016-11-28 21:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-25 17:36 Generic private type declaration Alejandro R. Mosteo
2016-11-25 19:17 ` Dmitry A. Kazakov
2016-11-28 14:54   ` Alejandro R. Mosteo
2016-11-25 19:18 ` AdaMagica
2016-11-28 14:57   ` Alejandro R. Mosteo
2016-11-25 19:38 ` G.B.
2016-11-26  8:45 ` Jacob Sparre Andersen
2016-11-26 19:18   ` Tero Koskinen
2016-11-28 15:05     ` Alejandro R. Mosteo
2016-11-28 21:32       ` Randy Brukardt [this message]
2016-11-29 11:12         ` Alejandro R. Mosteo
2016-11-29 11:42         ` Dmitry A. Kazakov
2016-11-29 23:48           ` Randy Brukardt
2016-11-28 23:25 ` Robert Eachus
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox