Re: Extending discriminant types

[anon@anon.org (anon)]

First, the second specification package that I use was written by 
"Pascal Leroy". another editor of the Ada 2005 RM. "Randy Brukardt" 
skip this topic.

QUOTE
Our compiler currently rejects the following code fragment because it 
complains that the overriding "=" is not subtype conformant with the 
inherited "=" (3.9.2(10)):

       package P is
                type T is tagged private;
                function "=" (Left, Right : T'Base) return Boolean;
        private
                type T is tagged null record;
        end P;


T is a constrained subtype as per 3.2(9), so as far as I understand, T is
different from the "T italic" used in 4.5.2(7).

I hope that there is flaw in my reasoning, because if it is correct, it 
looks like we have a pretty severe problem...

Pascal
UNQUOTE


And since both RM 95 and RM 2005, do not clarify that the "Base" attribute  
is for scalar types only, then you must assume that the "Base' attribute 
can apply to other types as well. Else either "Pascal Leroy" or may be 
"Randy Brukardt" would have correct the misunderstanding of this 
attribute, especially since, Pascal implied the understanding in the 
first place by use of his example.


Now to the RM.

From the RM 95, Annex N:

38   Subtype.  A subtype is a type together with a constraint, which
constrains the values of the subtype to satisfy a certain condition.  The
values of a subtype are a subset of the values of its type.

With that in mind. The definition of the "Base attribute" in Annex K: 

18   S'Base denotes an unconstrained subtype of the type of S. This 
     unconstrained subtype is called the base subtype of the type.
     See 3.5.

and from RM 3.5

S'Base:  denotes an unconstrained subtype of the type of S. This 
         unconstrained subtype is called the base subtype of
         the type.

Also Annex K says "For every scalar subtype S:" it does not say for 
"For every scalar subtypes S only:". 

And even though GNAT stops the programmers ability to create new 
attributes, it does not stop the programmer from using those that have 
been predefined for a more general meaning.

So, as long as you define the the "Base attribute" as an unconstrained 
subtype of a type. You have compiled with the RM and should be allowed 
in GNAT. So, the RM does not force the "Base" attribute to be for 
Scalar only and neither should GNAT.  

Plus, since that example is from Ada-auth.org one of the governing 
body of Ada, with the second being the Ada RM that is stored at 
IEEE. I choose to say that the Ada-auth.org is more likely to be 
correct on these matters.


Also, since both Duff and Beneschan weigh in on this one back then:
I kind of like what Robert said! Especially since it came from 
his Adacore email account!

As "Robert A Duff" stated to Adam Beneschan back in 2002.

QUOTE
Robert's Rule, which says that no matter what the RM says, it "really" 
says what we mean! 
UNQUOTE

I know he was trying to be funny or was he. One problem though, that 
saying works both ways!



Now, what makes you think that using GNAT 2008 with "-gnat95" would 
fix the problem. It the error is not govern by "-gnatxx" switch in GNAT 
then the error will show up regardless of what specification used.

For your information I used "GNAT 3.15p" first, then tried "GNAT GPL 2007", 
and "GNAT GPL 2008" and last night pulled out my CD of old GNAT compilers, 
and used two DOD certified compilers. And the only compilers that create 
this error are those that contain the Ada 2005 specifications, 
"GNAT GPL 2007", and "GNAT GPL 2008". So, the cause of this error is in 
the Ada 2005 specifications or changes to the compiler for the new specs. 

The true correction will occur after IBM releases their version of Ada 
2005. And we are able to compare GNAT 2008/9 to IBM's Ada. Of course, 
if someone has the IBM Ada 95 version then we could compare, the results.

Note: Back in april IBM stated, it would release the Ada 2005 compiler by 
the end of year. But, that was before the big meltdown, so we might have 
to add another year or two.


In <26f0cb8c-eb3e-4c0d-85d1-f45e2c1ba4c6@j38g2000yqa.googlegroups.com>, christoph.grein@eurocopter.com writes:
>On 20 Nov., 08:21, a...@anon.org (anon) wrote:
>> Since, the orginal post suggest that the poster was using GNAT Ada 95
>> compiler. Because the poster states that he can compiler the code. So,
>> I used Gnat 3.15p using Ada 95 specs.
>>
>> Plus, the RM does not limited the "Base" attribute to only Scalar Types.
>> Any defined type can use the "Base" attribute.
>
>Wrong, it does. Please see the RM. You can take the 95 version, the 95
>consolidated version, or the 2005 version. They all show you that
>'Base is valid for scalar types only.
>
>In my last post, I gave you chapter and verse, I repeat it here: K
>(17).
>This refers back to 3.5 Scalar Types, especially 3.5(15).
>
>Form the kind of reference, you can deduce that there has been no
>change since the very first publication of Ada 95. [Reference is in
>the form C.V(p), where p is the paragraph number, here 15. It is
>adorned with /1, if this paragraph was changed in the consolidated
>version; with /2, if it was changed in the 2005 version.] So here you
>see no change.
>
>> Then you also have RM 2005 3.8.1 (17).
>
>This is irrelevant in this context.
>
>> --
>> -- This specification was found on Ada-auth.org web site.
>> --
>> package U is
>> =A0 type T is tagged private ;
>>
>> =A0 function "=3D" ( Left, Right : T'Base ) return Boolean ;
>>
>> private
>> =A0 type T is tagged null record ;
>> end U ;
>
>Hm, then this should never have compiled - GNAT is in error here (I
>guess there are mistakes in every compiler on the world).
>
>> the previous code is valid in Ada 95 but will not compile using GNAT
>> Ada 2005 (2007 or 2008 versions).
>
>OK, AdaCore have corrected the bug.
>
>> And since a few here, like the "wiki" web sites:
>>
>> From: =A0 =A0 =A0 =A0http://en.wikibooks.org/wiki/Ada_Programming/Types
>
>Please note that wiki has no normative force. You always have to be
>suspicious about the contents. You have a good example here. The
>chapter is partly wrong!
>
>Now it was me who wrote lots of the stuff you quote here, so I'm the
>culprit. I wrote the chapter with scalar types in mind - and in fact,
>all this is true only for scalar types, not for composite types.