Extending discriminant types

Extending discriminant types

[Stefan Bellon]

Hi,

I stumbled across some behaviour when extending an unconstrained
discriminant type while providing the constraint when extending. Assume
the following code:

   type Kind is (A, B);

   type Base (K : Kind) is abstract tagged record
      case K is
         when A => null;
         when B => Dummy : Natural;
      end case;
   end record;

   type Base_Access is access all Base'Class;

   type Child is new Base (B) with null record;

In this case I would have thought that type Child is now constrained to
Kind B and no object of type Child with Kind A can be created.

However, the following compiles (with GNAT) and does not throw an
exception at runtime:

   Var : Base_Access := new Child'(K => A);

Am I misunderstanding the Ada semantics? If so, is there a way to
achieve what I'm trying, i.e. that I can determine the Kind while
extending and not change it when creating objects?

Greetings,
Stefan

Re: Extending discriminant types

[Jeffrey R. Carter]

Stefan Bellon wrote:
> 
>    type Kind is (A, B);
> 
>    type Base (K : Kind) is abstract tagged record
>       case K is
>          when A => null;
>          when B => Dummy : Natural;
>       end case;
>    end record;
> 
>    type Base_Access is access all Base'Class;
> 
>    type Child is new Base (B) with null record;
> 
> In this case I would have thought that type Child is now constrained to
> Kind B and no object of type Child with Kind A can be created.
> 
> However, the following compiles (with GNAT) and does not throw an
> exception at runtime:
> 
>    Var : Base_Access := new Child'(K => A);
> 
> Am I misunderstanding the Ada semantics? If so, is there a way to
> achieve what I'm trying, i.e. that I can determine the Kind while
> extending and not change it when creating objects?

The following does not compile:

Var : Child (K => A);

You probably don't need the access type that is causing you this confusion.

-- 
Jeff Carter
"In the frozen land of Nador they were forced to
eat Robin's minstrels, and there was much rejoicing."
Monty Python & the Holy Grail
70

Re: Extending discriminant types

[Adam Beneschan]

On Nov 15, 1:16 am, Stefan Bellon <bel...@software-erosion.org> wrote:
> Hi,
>
> I stumbled across some behaviour when extending an unconstrained
> discriminant type while providing the constraint when extending. Assume
> the following code:
>
>    type Kind is (A, B);
>
>    type Base (K : Kind) is abstract tagged record
>       case K is
>          when A => null;
>          when B => Dummy : Natural;
>       end case;
>    end record;
>
>    type Base_Access is access all Base'Class;
>
>    type Child is new Base (B) with null record;
>
> In this case I would have thought that type Child is now constrained to
> Kind B and no object of type Child with Kind A can be created.
>
> However, the following compiles (with GNAT) and does not throw an
> exception at runtime:
>
>    Var : Base_Access := new Child'(K => A);
>
> Am I misunderstanding the Ada semantics?

No, I think GNAT is wrong here.  The semantics of allocators is that
an object is created with K=A, and then it tries to convert this
object to the subtype Child, but since Child has a constraint and the
object violates that constraint, a Constraint_Error should be raised.
However, I think this would be OK and would not raise an exception:

    Var : Base_Access := new Child'Base' (K => A);

since there are no constraints to violate.  I'm not 100% sure I'm
right about this, though.

                                 -- Adam

Re: Extending discriminant types

[christoph.grein]

>     Var : Base_Access := new Child'Base' (K => A);

Attribute 'Base exists for scalar types only.

Re: Extending discriminant types

[Adam Beneschan]

On Nov 18, 3:02 am, christoph.gr...@eurocopter.com wrote:
> >     Var : Base_Access := new Child'Base' (K => A);
>
> Attribute 'Base exists for scalar types only.

Aaargh, missed that.  'Base was defined for record types in Ada 83
(although 'Base could never be used in Ada 83 without some other
attribute following it).  I hardly ever use it anyway, so I guess the
fact that it's no longer defined for records escaped me for the last
13 years......

Thanks for pointing this out.

                              -- Adam

Re: Extending discriminant types

[anon]

--  Your talking about "Variant Parts and Discrete Choices" (RM 3.8.1) 
--  which is validated during runtine, if the variable is reference.
--
--  Now with a smart compiler it could detect the error, but the 
--  compiler in GNAT is not that smart.

procedure t is

   --  Change "Base" to "KBase" to prevent confusion with predefine 
   --  Attribute 'Base, which als works.

   type Kind is (A, B);

   type KBase (K : Kind) is abstract tagged record   
      case K is
         when A => null;
         when B => Dummy : Natural;
      end case;
   end record;

   type Base_Access is access all KBase'Class;

   --  type "Child" is bound to KBase ( K => B ) so any reference 
   --  of "Child" to ( K => A ) should cause an error condition 
   --  but this only happens during runtime.

   type Child is new KBase (B) with null record;


   --  Var2 is in error and should cause a Constaint_Error
   -- once referenced.
   
   Var  : Base_Access := new Child ;
   Var0 : Base_Access := new Child'(K => B, Dummy => 5);
   Var1 : Base_Access := new Child'Base(K => B);  -- Just for Adam, this works

   Var2 : Base_Access := new Child'Base(K => A);


begin -- t

  Var.Dummy := 2 ;
  Var0.Dummy := 4 ;
  Var1.Dummy := 8 ; -- Just for Adam, this works

  --  Uncommenting the following line will result in a Constraint_Error 
  --  during runtine. But until Var2 is reference the validation of 
  --  type is not performed.

--  Var2.Dummy := 16 ;

end t ;



In <20081115101632.5f98c596@cube.tz.axivion.com>, Stefan Bellon <bellon@software-erosion.org> writes:
>Hi,
>
>I stumbled across some behaviour when extending an unconstrained
>discriminant type while providing the constraint when extending. Assume
>the following code:
>
>   type Kind is (A, B);
>
>   type Base (K : Kind) is abstract tagged record
>      case K is
>         when A => null;
>         when B => Dummy : Natural;
>      end case;
>   end record;
>
>   type Base_Access is access all Base'Class;
>
>   type Child is new Base (B) with null record;
>
>In this case I would have thought that type Child is now constrained to
>Kind B and no object of type Child with Kind A can be created.
>
>However, the following compiles (with GNAT) and does not throw an
>exception at runtime:
>
>   Var : Base_Access := new Child'(K => A);
>
>Am I misunderstanding the Ada semantics? If so, is there a way to
>achieve what I'm trying, i.e. that I can determine the Kind while
>extending and not change it when creating objects?
>
>Greetings,
>Stefan
>

Re: Extending discriminant types

[christoph.grein]

On 19 Nov., 10:49, a...@anon.org (anon) wrote:
>    Var1 : Base_Access := new Child'Base(K => B);  -- Just for Adam, this works
>
>    Var2 : Base_Access := new Child'Base(K => A);

I don't know which compiler anon uses, but this is wrong: RM K(17).

GNAT Pro 6.0.1 rejects this code.

Re: Extending discriminant types

[Martin]

On Nov 19, 9:49 am, a...@anon.org (anon) wrote:
[snip]
>    Var1 : Base_Access := new Child'Base(K => B);  -- Just for Adam, this works
[snip]
>   Var1.Dummy := 8 ; -- Just for Adam, this works
[snip]

Not for "GNAT GPL 2008 (20080521)" it doesn't:

34:30     prefix of Base attribute must be scalar type
36:30     prefix of Base attribute must be scalar type

Cheers
-- Martin

Re: Extending discriminant types

[Georg Bauhaus]

christoph.grein@eurocopter.com wrote:
> On 19 Nov., 10:49, a...@anon.org (anon) wrote:
>>    Var1 : Base_Access := new Child'Base(K => B);  -- Just for Adam, this works
>>
>>    Var2 : Base_Access := new Child'Base(K => A);
> 
> I don't know which compiler anon uses, but this is wrong: RM K(17).
> 
> GNAT Pro 6.0.1 rejects this code.

FWIW, another, unrelated compiler says that the
"the prefix to the BASE attribute must be a scalar subtype"

Re: Extending discriminant types

[anon]

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.

Then you also have RM 2005 3.8.1 (17).

--
-- This specification was found on Ada-auth.org web site.
--
package U is
  type T is tagged private ;

  function "=" ( Left, Right : T'Base ) return Boolean ;

private
  type T is tagged null record ;
end U ;

--
-- Dummy body package to comply with the specification package.
--
package body U is

  function "=" ( Left, Right : T'Base ) return Boolean is
    begin
      return False ;
    end ;
end U ;

the previous code is valid in Ada 95 but will not compile using GNAT 
Ada 2005 (2007 or 2008 versions). 


And since a few here, like the "wiki" web sites:

From:        http://en.wikibooks.org/wiki/Ada_Programming/Types

Under the section "Defining new types and subtypes". The page defines that 
for all T, "there is also a base type called T'Base, which encompasses all 
values of T."

And under section "Base type" it says "In Ada, all types are anonymous and 
only subtypes may be named. There is a special subtype of the anonymous 
type, called the base type, which is nameable with the 'Base attribute. The 
base type comprises all values of the first subtypes."

That states that the "Base" attribute not only included in all Scalar Types 
but all defined types as well. Which means that the Non Scalar defined 
"Access" type has a special subtype aka "Base" attribute that can be used.

Plus, the concept of using the 'Base attribute and the 'Class attribute are 
the a part of the core of "Object-oriented" programming in Ada 95. With 
the "with record" part indicates the extension to the base type. But without 
this design it defect the purpose of some "Object-oriented" programming. 
There must be a base type for all types as well as all objects. 

So, either the definition of the "Base" attribute has been altered or 
limited by GNAT in the Ada 2005 specification. Or the GNAT Ada Pro 6.01 
and GNAT Ada 2007 and 2008 now contains an error for the "Base" attribute. 


Now, back to the example! The type "Child" is defined in the following 
statement:

   type Child is new KBase (B) with null record;

And the "Child" type is constrained by the record "KBase (B)" but the 
"Base" type or unconstrained subtype of type "Child" is the complete 
range of values, that is, a set comprising of a KBase(A) record and 
a KBase(B) record.


So the statement 

   Var1 : Base_Access := new Child'Base(K => B);

used with the statement

   type Base_Access is access all KBase'Class;

is legal because the statement generates an access value that has a 
Base type ("Base" attribute) value that is within the range of 
values of all Base_Access values. A variant define as "K => A" is 
illegal only during runtime when the value is assigned to the Var1 
variable which is limited to a Base_Access that has a "KBase (B)" 
define by the type "Child".



In <oiRUk.141685$Mh5.126924@bgtnsc04-news.ops.worldnet.att.net>, anon@anon.org (anon) writes:
>
>--  Your talking about "Variant Parts and Discrete Choices" (RM 3.8.1) 
>--  which is validated during runtine, if the variable is reference.
>--
>--  Now with a smart compiler it could detect the error, but the 
>--  compiler in GNAT is not that smart.
>
>procedure t is
>
>   --  Change "Base" to "KBase" to prevent confusion with predefine 
>   --  Attribute 'Base, which als works.
>
>   type Kind is (A, B);
>
>   type KBase (K : Kind) is abstract tagged record   
>      case K is
>         when A => null;
>         when B => Dummy : Natural;
>      end case;
>   end record;
>
>   type Base_Access is access all KBase'Class;
>
>   --  type "Child" is bound to KBase ( K => B ) so any reference 
>   --  of "Child" to ( K => A ) should cause an error condition 
>   --  but this only happens during runtime.
>
>   type Child is new KBase (B) with null record;
>
>
>   --  Var2 is in error and should cause a Constaint_Error
>   -- once referenced.
>   
>   Var  : Base_Access := new Child ;
>   Var0 : Base_Access := new Child'(K => B, Dummy => 5);
>   Var1 : Base_Access := new Child'Base(K => B);  -- Just for Adam, this works
>
>   Var2 : Base_Access := new Child'Base(K => A);
>
>
>begin -- t
>
>  Var.Dummy := 2 ;
>  Var0.Dummy := 4 ;
>  Var1.Dummy := 8 ; -- Just for Adam, this works
>
>  --  Uncommenting the following line will result in a Constraint_Error 
>  --  during runtine. But until Var2 is reference the validation of 
>  --  type is not performed.
>
>--  Var2.Dummy := 16 ;
>
>end t ;
>
>
>
>In <20081115101632.5f98c596@cube.tz.axivion.com>, Stefan Bellon <bellon@software-erosion.org> writes:
>>Hi,
>>
>>I stumbled across some behaviour when extending an unconstrained
>>discriminant type while providing the constraint when extending. Assume
>>the following code:
>>
>>   type Kind is (A, B);
>>
>>   type Base (K : Kind) is abstract tagged record
>>      case K is
>>         when A => null;
>>         when B => Dummy : Natural;
>>      end case;
>>   end record;
>>
>>   type Base_Access is access all Base'Class;
>>
>>   type Child is new Base (B) with null record;
>>
>>In this case I would have thought that type Child is now constrained to
>>Kind B and no object of type Child with Kind A can be created.
>>
>>However, the following compiles (with GNAT) and does not throw an
>>exception at runtime:
>>
>>   Var : Base_Access := new Child'(K => A);
>>
>>Am I misunderstanding the Ada semantics? If so, is there a way to
>>achieve what I'm trying, i.e. that I can determine the Kind while
>>extending and not change it when creating objects?
>>
>>Greetings,
>>Stefan
>>
>

Re: Extending discriminant types

[christoph.grein]

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
>   type T is tagged private ;
>
>   function "=" ( Left, Right : T'Base ) return Boolean ;
>
> private
>   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:        http://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.

Re: Extending discriminant types

[Ludovic Brenta]

On Nov 20, 9:30 am, christoph.gr...@eurocopter.com wrote:
> 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.

One can also try GNAT GPL Edition 2008 or GCC 4.3 (or even 4.4) and
pass it the -gnat95 option which is documented in the Secret GNAT
User's Guide.

--
Ludovic Brenta.

Re: Extending discriminant types

[Martin]

On Nov 20, 7:21 am, 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.

GNAT 3.15p is /very/ old...and not without bugs but no matter as I
used the "secret" -gnat95 option with GNAT GPL 2008 and it still
catches the errors.

>  Plus, the RM does not limited the "Base" attribute to only Scalar Types.

Er, yes it does.

Cheers
-- Martin

Re: Extending discriminant types

[Georg Bauhaus]

Ludovic Brenta schrieb:
> On Nov 20, 9:30 am, christoph.gr...@eurocopter.com wrote:
>> 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.
> 
> One can also try GNAT GPL Edition 2008 or GCC 4.3 (or even 4.4) and
> pass it the -gnat95 option which is documented in the Secret GNAT
> User's Guide.

GNAT has -gnat83 as well, but rejects, too, because there are
neither tagged nor abstract types in Ada 83.

Just out of curiosity, given

   type T is tagged ...;
   type D is new T with ...;
   type E is new D with ...;

what would E'Base be?

Assuming that D is privately tagged, would E'Base
have different effects depending on whether E's tag
is visible or not?

Re: Extending discriminant types

[Georg Bauhaus]

Georg Bauhaus schrieb:
> Ludovic Brenta schrieb:
>> On Nov 20, 9:30 am, christoph.gr...@eurocopter.com wrote:
>>> 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.
>> One can also try GNAT GPL Edition 2008 or GCC 4.3 (or even 4.4) and
>> pass it the -gnat95 option which is documented in the Secret GNAT
>> User's Guide.
> 
> GNAT has -gnat83 as well, but rejects, too, because there are
> neither tagged nor abstract types in Ada 83.
> 
> Just out of curiosity, given
> 
>    type T is tagged ...;
>    type D is new T with ...;
>    type E is new D with ...;
> 
> what would E'Base be?
> 
> Assuming that D is privately tagged, would E'Base
> have different effects depending on whether E's tag
> is visible or not?

D's tag, ie.

Re: Extending discriminant types

[Dmitry A. Kazakov]

On Thu, 20 Nov 2008 12:45:27 +0100, Georg Bauhaus wrote:

> Just out of curiosity, given
> 
>    type T is tagged ...;
>    type D is new T with ...;
>    type E is new D with ...;
> 
> what would E'Base be?

In Ada 83 S'Base was meant as something like "a least constrained
supertype", assuming specialization as a types algebra operation. Under
generalization is should be E itself. When inheritance both specializes,
generalizes and deviates a bit, there might be no S'Base. So the concept
was wrong.

Alternatively S'Base could mean the closest parent of S, different from S.
Then there is no problem, except that it would not work with MI. Wrong
again.

[ The right concept is class-wide (contravariant) operations, when
specialization need to be dealt with. E.g.

   function "+" (L, R : Integer) return Integer'Class;
      -- Contravariant in the result. This is not Ada!
]

> Assuming that D is privately tagged, would E'Base
> have different effects depending on whether E's tag
> is visible or not?

Visibility of S'Base is of no concern, because S'Base is itself visible.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Extending discriminant types

[Robert A Duff]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> Just out of curiosity, given
>
>    type T is tagged ...;
>    type D is new T with ...;
>    type E is new D with ...;
>
> what would E'Base be?

There seems to be some confusion between "base subtype"
and "parent type".

E'Base is illegal in Ada 95 and Ada 2005.  If it were legal, I suppose
it would be the same as E, since for scalar types, X'Base basically
means "X without constraints", and E has no discriminants and hence no
constraints.

I think the original example in this thread confused things by calling
the root type "Base".  It would be better to say "type Root is ..."
in an example like that.

- Bob

Re: Extending discriminant types

[Stefan Bellon]

On Thu, 20 Nov, Robert A Duff wrote:

> I think the original example in this thread confused things by calling
> the root type "Base".  It would be better to say "type Root is ..."
> in an example like that.

Mea culpa. ;-)

-- 
Stefan Bellon

Re: Extending discriminant types

[Adam Beneschan]

On Nov 20, 3:45 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> Ludovic Brenta schrieb:
>
> > On Nov 20, 9:30 am, christoph.gr...@eurocopter.com wrote:
> >> 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.
>
> > One can also try GNAT GPL Edition 2008 or GCC 4.3 (or even 4.4) and
> > pass it the -gnat95 option which is documented in the Secret GNAT
> > User's Guide.
>
> GNAT has -gnat83 as well, but rejects, too, because there are
> neither tagged nor abstract types in Ada 83.
>
> Just out of curiosity, given
>
>    type T is tagged ...;
>    type D is new T with ...;
>    type E is new D with ...;
>
> what would E'Base be?

Type declarations define both "types" and "subtypes".  Only subtypes
have constraints; types don't.  Subtypes and types are different kinds
of entities---a subtype isn't a special case of a type.  So the
declaration of T defines both a type T, and a "first subtype" T.  The
declaration of D defines a derived type D whose parent type is the
*type* T; and it also defines a "first subtype" D of the *type* D..
Similarly for E: it defines a type E whose parent type is D, and a
first subtype E of the type E.  If E'Base were defined the same way
it's defined for scalars, then it would refer to an unconstrained
subtype of the *type* E.  As Bob pointed out, that would be
essentially the same as the "first subtype" E, since there are no
discriminants on that type.  But one could imagine something like

   type U (Disc : Integer) is record ... end record;
   type F is new U(7);
   type G is new F;

The *types* U, F, and G aren't constrained, so if G'Base were allowed,
it would be an unconstrained subtype of G---i.e. Disc could be
anything.  I don't really know why E'Base or G'Base isn't allowed.  As
far as I can tell, it wouldn't cause any semantic problems to allow
it, but it might prevent some useful optimizations in variant record
cases.  But I'm just guessing.


> Assuming that D is privately tagged, would E'Base
> have different effects depending on whether [D's] tag
> is visible or not?  [corrected]

I don't think this question makes sense unless you mistakenly think
that 'Base has something to do with the parent type of a type.  But as
we've pointed out, it doesn't.  By the way, I believe there was a
proposal for a 'Parent attribute or something like that to refer to a
derived type's parent (or its first subtype), but it didn't make it
into the language.

                                 -- Adam

Re: Extending discriminant types

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

Re: Extending discriminant types

[anon]

--
--  Compiles and Runs using GNAT 3.15p
--
--  This works in Ada 95 compilers because all types including a tag type 
--  has a discriminant value of at least 2 aka itself and Null. And that 
--  suggest that ALL types have a constraint of at least two. 
--
procedure V is

    type Point is tagged record
                           X : Float := 0.0 ;
                           Y : Float := 0.0 ;
                         end record ;
    type Point_Acesss is access all Point'Class ;

    type D is new Point with record
                           Z : Float := 0.0 ;
                         end record ;

    type E is new D with null record;
 
    Var : Point_Acesss ;

begin -- V
  Var := new E'Base ;
end V ;

In <49254e2d$0$30232$9b4e6d93@newsspool1.arcor-online.net>, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:
>Georg Bauhaus schrieb:
>> Ludovic Brenta schrieb:
>>> On Nov 20, 9:30 am, christoph.gr...@eurocopter.com wrote:
>>>> 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.
>>> One can also try GNAT GPL Edition 2008 or GCC 4.3 (or even 4.4) and
>>> pass it the -gnat95 option which is documented in the Secret GNAT
>>> User's Guide.
>> 
>> GNAT has -gnat83 as well, but rejects, too, because there are
>> neither tagged nor abstract types in Ada 83.
>> 
>> Just out of curiosity, given
>> 
>>    type T is tagged ...;
>>    type D is new T with ...;
>>    type E is new D with ...;
>> 
>> what would E'Base be?
>> 
>> Assuming that D is privately tagged, would E'Base
>> have different effects depending on whether E's tag
>> is visible or not?
>
>D's tag, ie.

Re: Extending discriminant types

[Adam Beneschan]

On Nov 20, 2:59 pm, a...@anon.org (anon) wrote:
> 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.

The Annotated Ada Reference Manual does clarify this, though.  See
AARM 3.5(63.a).  http://www.adaic.org/standards/05aarm/html/AA-3-5.html


 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.

Either that, or both Pascal and Randy are human and both erred by
missing the problem.  It happens.

                                -- Adam

Re: Extending discriminant types

[Adam Beneschan]

On Nov 20, 7:57 am, Stefan Bellon <bel...@software-erosion.org> wrote:
> On Thu, 20 Nov, Robert A Duff wrote:
> > I think the original example in this thread confused things by calling
> > the root type "Base".  It would be better to say "type Root is ..."
> > in an example like that.
>
> Mea culpa. ;-)

Naah, I don't think so.  The original question didn't have anything to
do with the 'Base attribute at all, and there wouldn't have been any
confusion until I decided to bring the attribute up.  And I didn't
even notice that the type name was named "Base", so I wasn't confused
about that, just about whether the attribute was legal.  But if it's
anybody's culpa, it's probably mea.

                                  -- Adam

Re: Extending discriminant types

[christoph.grein]

On 20 Nov., 23:59, a...@anon.org (anon) wrote:
> 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.

and so on and so on. This is all a blatant big pile of fetid crap...

What can you do with a chap like this? He simply cannot read nor
listen nor understand, but accuses others of this inability. (I
remember well some mails only a few days ago where anon with rather
strong words accused one of our much valued contributors.)

Big sigh...

Re: Extending discriminant types

[anon]

Adam,

Try an explain this. Since I downloaded my binary version of GNAT-3.15p 
direct from Adacore. And someone else has said the GNAT-3.15p is old but 
it has been fully tested and found to be correct. So, that means that time 
Adacore agreed that "Base" attribute could be used outside of scalars and 
that was years after the RM and AARM for Ada 95 was written.


Now, both in the AARM 95 and AARM 2005. contains a section 3.2.3 (8.a) 
beside yoyur (63.a):

quote
                        Incompatibilities With Ada 83

    8.a   {incompatibilities with Ada 83} The attribute S'Base is no longer
          defined for non-scalar subtypes. Since this was only permitted as
          the prefix of another attribute, and there are no interesting
          non-scalar attributes defined for an unconstrained composite or
          access subtype, this should not affect any existing programs.
unquote

First, there is a  "interesting non-scalar attributes defined for an 
unconstrained composite or access subtype", it used in "Object-oriented
programming" (OOP). But back in 90s, Ada was a late starter for OOP and 
even with the Ada 2005 OOP extensions some might still say its late to 
the plate or should that be table. 

Secondly, there is another side to 3.2.3 (8.a) and others listed in the 
AARM, and that is the clarifying statement "incompatibilities with Ada 
83". But that does not say that "X'Base" or "T'Base" can not exist. If 
that was the case, a form of this statement would also be listed in 
"Annex J: Obsolescent Features" of the official RM.

   In my example the syntax for "Base" attribute would be more like:

        T'Base  T'Base denotes an unconstrained subtype of the 
                type of T also called the base subtype of the 
                type T.

and not "S'Base".



In <3f77e490-2f54-4441-828e-6c6e68d245df@a17g2000prm.googlegroups.com>, Adam Beneschan <adam@irvine.com> writes:
>On Nov 20, 2:59 pm, a...@anon.org (anon) wrote:
>> 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.
>
>The Annotated Ada Reference Manual does clarify this, though.  See
>AARM 3.5(63.a).  http://www.adaic.org/standards/05aarm/html/AA-3-5.html
>
>
> 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.
>
>Either that, or both Pascal and Randy are human and both erred by
>missing the problem.  It happens.
>
>                                -- Adam

Re: Extending discriminant types

[Jean-Pierre Rosen]

anon a �crit :
> And someone else has said the GNAT-3.15p is old but 
> it has been fully tested and found to be correct. 
No, not found to be incorrect. This is not the same thing.

> Secondly, there is another side to 3.2.3 (8.a) and others listed in the 
> AARM, and that is the clarifying statement "incompatibilities with Ada 
> 83". But that does not say that "X'Base" or "T'Base" can not exist. If 
> that was the case, a form of this statement would also be listed in 
> "Annex J: Obsolescent Features" of the official RM.
Wrong. Annex J is for features that are still there, but whose use is 
discouraged. 'Base for non-scalar types has been *removed*, that's why 
it is /not/ in Annex J.
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Extending discriminant types

[christoph.grein]

> Since I downloaded my binary version of GNAT-3.15p
> direct from Adacore. And someone else has said the GNAT-3.15p is old but
> it has been fully tested and found to be correct.
> So, that means that time Adacore agreed that "Base" attribute could be
> used outside of scalars and that was years after the RM and AARM for
> Ada 95 was written.

Having tested and delivered a compiler does by no means imply that
there are no bugs in it. Implying such a statement is silly. License
agreements take care of this.

> First, there is a  "interesting non-scalar attributes defined for an
> unconstrained composite or access subtype", it used in "Object-oriented
> programming" (OOP). But back in 90s, Ada was a late starter for OOP and
> even with the Ada 2005 OOP extensions some might still say its late to
> the plate or should that be table.

Ada was the first ISO standardized OO language (admittedly, there were
many OO languages before, but none standardized).

> Secondly, there is another side to 3.2.3 (8.a) and others listed in the
> AARM, and that is the clarifying statement "incompatibilities with Ada
> 83". But that does not say that "X'Base" or "T'Base" can not exist. If
> that was the case, a form of this statement would also be listed in
> "Annex J: Obsolescent Features" of the official RM.

Please see:
RM 1.1.1(6)  Permissible variations
   1.1.2(36) Implementation permissions
   1.1.3(6)  No variations

So there is nowhere a statement that 'Base may exist for other types.

Implementations may define other attributes, but they are not allowed
to use attribute names defined in the standard.

So please accept that if some compilers accept 'Base, this is a
mistake!

Re: Extending discriminant types

[Martin]

On Nov 20, 10:59 pm, a...@anon.org (anon) wrote:
[snip]
> 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:".

But the section heading for 3.5 kind of gives it away doesn't
it..."Scalar Types"! If it applied to other kinds of type then it
would be mentioned in those sections.

And why would K(17) have to include the word "only" when it already
includes "scalar"?

None of the other entries in Annex K use "only" to limit their
applicability - they just state what they are applicable to. Would you
really then read on from K(17) and think K(19) "S'Bit_Order For every
specific record subtype S:" means that 'Bit_Order could apply to
something other than a record subtype??? Or K(181) 'Pred applies to
something other than scalars??? etc

Cheers
-- Martin

Re: Extending discriminant types

[Ludovic Brenta]

On Nov 21, 12:01 am, a...@anon.org (anon) wrote:
> --  Compiles and Runs using GNAT 3.15p
> --
> --  This works in Ada 95 compilers because all types including a tag type
> --  has a discriminant value of at least 2 aka itself and Null. And that
> --  suggest that ALL types have a constraint of at least two.
> procedure V is
>     type Point is tagged record
>                            X : Float := 0.0 ;
>                            Y : Float := 0.0 ;
>                          end record ;
>     type Point_Acesss is access all Point'Class ;
>     type D is new Point with record
>                            Z : Float := 0.0 ;
>                          end record ;
>     type E is new D with null record;
>     Var : Point_Acesss ;
> begin -- V
>   Var := new E'Base ;
> end V ;

This compiles and runs with GNAT 3.15p only because GNAT 3.15p has a
bug.

--
Ludovic Brenta.

Re: Extending discriminant types

[Ludovic Brenta]

On Nov 21, 8:25 am, a...@anon.org (anon) wrote:
> Adam,
>
> Try an explain this. Since I downloaded my binary version of GNAT-3.15p
> direct from Adacore. And someone else has said the GNAT-3.15p is old but
> it has been fully tested and found to be correct. So, that means that time
> Adacore agreed that "Base" attribute could be used outside of scalars and
> that was years after the RM and AARM for Ada 95 was written.

Your reasoning is incorrect because (a) it is impossible to "fully
test" a program as complex as a compiler and (b) testing can prove the
presence of bugs but not their absence. Therefore, even though GNAT
3.15p did pass the ACATS and many thousands of tests beyond the ACATS,
you may not assume that it contains no bugs. In fact, during my years
maintaining GNAT 3.15p in Debian, various people reported
approximately 110 bugs in it. A few of these bugs are still present in
the latest releases of GNAT; yet, the ACATS does not find them.

It would be nice to add a test to the ACATS so that compilers that
accept T'Base where T is non-scalar get rejected.

--
Ludovic Brenta.

Re: Extending discriminant types

[Jeffrey R. Carter]

christoph.grein@eurocopter.com wrote:
> 
> What can you do with a chap like this? He simply cannot read nor
> listen nor understand, but accuses others of this inability. (I
> remember well some mails only a few days ago where anon with rather
> strong words accused one of our much valued contributors.)

You can killfile the moron, as I did long ago. Then you never see its ravings 
unless someone else replies to it.

-- 
Jeff Carter
"No one is to stone anyone until I blow this whistle,
do you understand? Even--and I want to make this
absolutely clear--even if they do say, 'Jehovah.'"
Monty Python's Life of Brian
74

Re: Extending discriminant types

[anon]

>So please accept that if some compilers accept 'Base, this is a
>mistake!

And to Ludovic Brenta:

This type of statement works with GNAT-3.15p, even in GNAT-3.01 as 
well as GNAT-3.12. All which are GNAT compilers that use the Ada 95 
specification.  That's just too many compilers and programmers testing for 
Adacore over a period of 5 to 10 years to be a design flaw in one version 
of a compiler.  And that does not include the 100s to 1000s of GCC 
people and students with the general public added in that have tested 
possible every combination of every type of statement (may be to general 
but you get the idea). The odds that this type of statement not being 
found until now and at least written up, is astronautical. 

So, until there is a second and possible a third compiler that is not 
based on Adacore GNAT, such as the "IBM Ada" compiler based on 
the Ada 2005 specs, that states this is an error! I have to say "No!" I 
will not accept this type of statement as an error.

Also if you wanted a ACATS test you could just modify one of the code 
I posted to fit the ACATS design test structure.


>So there is nowhere a statement that 'Base may exist for other types.

But there is no place it say that it can not exist either! It up to the 
programmer! Plus "Base" is not a reserved word so it can be use in other
places. 

>Implementations may define other attributes, but they are not allowed
>to use attribute names defined in the standard.

  Disprove by example RM 13.13 (84)

    function My_Read(Stream : access Ada.Streams.Root_Stream_Type'Class)
      return T;
    for T'Read use My_Read; -- see 13.13.2

Where the standard "Read" attribute is reassigned. In GNAT you are limited 
to the standard attributes only and that attribute structural definition but you 
can reassign them to user's code.

Also, If you are correct it would of been listed in "RM Annex J" since it 
is valid under the Ada 83 specs.



In <4d75603c-2f61-46c9-8c62-df4b6f49b2f7@13g2000yql.googlegroups.com>, Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
>On Nov 21, 8:25 am, a...@anon.org (anon) wrote:
>> Adam,
>>
>> Try an explain this. Since I downloaded my binary version of GNAT-3.15p
>> direct from Adacore. And someone else has said the GNAT-3.15p is old but
>> it has been fully tested and found to be correct. So, that means that time
>> Adacore agreed that "Base" attribute could be used outside of scalars and
>> that was years after the RM and AARM for Ada 95 was written.
>
>Your reasoning is incorrect because (a) it is impossible to "fully
>test" a program as complex as a compiler and (b) testing can prove the
>presence of bugs but not their absence. Therefore, even though GNAT
>3.15p did pass the ACATS and many thousands of tests beyond the ACATS,
>you may not assume that it contains no bugs. In fact, during my years
>maintaining GNAT 3.15p in Debian, various people reported
>approximately 110 bugs in it. A few of these bugs are still present in
>the latest releases of GNAT; yet, the ACATS does not find them.
>
>It would be nice to add a test to the ACATS so that compilers that
>accept T'Base where T is non-scalar get rejected.
>
>--
>Ludovic Brenta.

Re: Extending discriminant types

[Stefan Bellon]

On Fri, 21 Nov, anon wrote:

> This type of statement works with GNAT-3.15p, even in GNAT-3.01 as 
> well as GNAT-3.12. All which are GNAT compilers that use the Ada 95 
> specification.  That's just too many compilers and programmers
> testing for Adacore over a period of 5 to 10 years to be a design
> flaw in one version of a compiler.  And that does not include the
> 100s to 1000s of GCC people and students with the general public
> added in that have tested possible every combination of every type of
> statement (may be to general but you get the idea). The odds that
> this type of statement not being found until now and at least written
> up, is astronautical. 

Are you trying to say that GNAT 3.15p must have been a BUG FREE
compiler because lots of people have used it for a very long time, so
that each possible combination of statements MUST HAVE been encountered
by someone?

Are you serious? You know that it just takes someone to name one known
bug in GNAT 3.15p to prove you wrong?

I once reported two bugs related to negation on a value of a private
type whose full view is a modular type (and then either producing wrong
results or crashing GNAT depending whether the modulus was a basis of
two or not). That was with GNAT 5.04. You could argue that those kind
of problems must have been spotted years ago, but fact is, they weren't.

-- 
Stefan Bellon

Re: Extending discriminant types

[Gautier]

anon wrote:

> This type of statement works with GNAT-3.15p, even in GNAT-3.01 as 
> well as GNAT-3.12. All which are GNAT compilers that use the Ada 95 
> specification.  That's just too many compilers and programmers testing for 
> Adacore over a period of 5 to 10 years to be a design flaw in one version 
> of a compiler.  And that does not include the 100s to 1000s of GCC 
> people and students with the general public added in that have tested 
> possible every combination of every type of statement (may be to general 
> but you get the idea). The odds that this type of statement not being 
> found until now and at least written up, is astronautical. 

Yeah - similarily, so many big banks have traded so large sums on 
mortgage-based securities and credit derivatives, over 5 to 10 years or 
more, that it's clear there can't be a flaw there ( ;-) ).
_________________________________________________________
Gautier's Ada programming -- http://sf.net/users/gdemont/

NB: For a direct answer, e-mail address on the Web site!

Re: Extending discriminant types

[sjw]

On Nov 21, 9:12 pm, "Jeffrey R. Carter"
<spam.jrcarter....@spam.acm.org> wrote:
> christoph.gr...@eurocopter.com wrote:

> You can killfile the moron, as I did long ago. Then you never see its ravings
> unless someone else replies to it.

Is there a killfile facility in Google Groups? (my ISP's news support
has been spotty of late ...)

Re: Extending discriminant types

[anon]

What I am saying is that ALL BUG have been seen and reported by now for the
GNAT-3.xx compilers, because of the volume of users and the amount of time 
that GNAT 3.xx series has been around. Also, professors may or may not call 
Adacore if they find a BUG, but they normally note the error for future 
reference. 

And that until 1997, all Ada compiler including the GNAT-3.xx series were 
under the control of the US's DOD and the RM and only the RM. All newer 
compilers are not under such strong arm control or limitation, rather that's 
the US gov't or the direct rules of the RM. So, you may see a more relax view 
on applying the RM, which mean that newer compiler nay have this and others 
types of an error, not found in the GNAT 3.xx series. 

Also, I am saying that "Pascal Orb", "Thomas Quinot", "Tucker Taft", and 
even the prof "Robert Dewar" are better programmers than that. And 
"Stephen Baird" as an Ada genius and a one time co-programming partner 
would never allow this type of misunderstanding to occur either. Then there 
"Robert A Duff", I may have my differences with him from time to time, 
but even he is better than that as well.  Yes, I know that is only a small 
group of the 50 plus staff at Adacore, but these guys do have a lot of respect 
of the Ada community and their Ada reputation are always on the line.

But every since 2002-2003 when the shift to Ada 2005 specs started, it 
seams that the GNAT Ada team has been using a non-certified form of the 
RM.  Which should never be allowed.

Here is another thought. Since, the use of "base" attribute (as Adam stated) 
was used in this way and legal in Ada 83 specs. Then "GNAT 2005-2008" 
should still allow this statement, if the statement "Pragma Ada_83 ;" or 
command line "-gnat83" option is use.  But as someone else reported this is 
not the case, which kind of suggest that GNAT 2005-2008 compilers are the 
ones in error and leads to the idea that the GNAT 3.15p may be correct 
compiler for Ada 83/95 specs. 

Plus, the complete Ada 2005 specification compiler aka GNAT 2008, has only 
been around a few months and has yet to be fully tested by the Ada community 
which can take years. 

As for GNAT 5.01 and GNAT Pro 6.01, well they were not written under the 
DOD and the RM only control. And they have not been around 10 to 14 years 
yet, for someone to say that 5.01 or 6.01 have been fully checked.


In <20081122011825.5354d1c1@cube.tz.axivion.com>, Stefan Bellon <bellon@software-erosion.org> writes:
>On Fri, 21 Nov, anon wrote:
>
>> This type of statement works with GNAT-3.15p, even in GNAT-3.01 as 
>> well as GNAT-3.12. All which are GNAT compilers that use the Ada 95 
>> specification.  That's just too many compilers and programmers
>> testing for Adacore over a period of 5 to 10 years to be a design
>> flaw in one version of a compiler.  And that does not include the
>> 100s to 1000s of GCC people and students with the general public
>> added in that have tested possible every combination of every type of
>> statement (may be to general but you get the idea). The odds that
>> this type of statement not being found until now and at least written
>> up, is astronautical. 
>
>Are you trying to say that GNAT 3.15p must have been a BUG FREE
>compiler because lots of people have used it for a very long time, so
>that each possible combination of statements MUST HAVE been encountered
>by someone?
>
>Are you serious? You know that it just takes someone to name one known
>bug in GNAT 3.15p to prove you wrong?
>
>I once reported two bugs related to negation on a value of a private
>type whose full view is a modular type (and then either producing wrong
>results or crashing GNAT depending whether the modulus was a basis of
>two or not). That was with GNAT 5.04. You could argue that those kind
>of problems must have been spotted years ago, but fact is, they weren't.
>
>-- 
>Stefan Bellon
>

Re: Extending discriminant types

[Georg Bauhaus]

anon wrote:

> Since, the use of "base" attribute (as Adam stated) 
> was used in this way and legal in Ada 83 specs. Then "GNAT 2005-2008" 
> should still allow this statement, if the statement "Pragma Ada_83 ;" or 
> command line "-gnat83" option is use.  But as someone else reported this is 
> not the case.

GNAT does handle 'Base specially when the user specifies
-gnat83 on the command line. And, this is easily demonstrated
by trying corresponding source with any of the versions of
GNAT that have been mentioned, preventing the spread of false
allegations.

> As for GNAT 5.01 and GNAT Pro 6.01, well they were not written under the 
> DOD and the RM only control.

Huh? In DoD we trust. The rest of us is bugs.

Re: Extending discriminant types

[anon]

Georg Bauhaus

Actually on the 20th you stated this:

quote:
  GNAT has -gnat83 as well, but rejects, too, because there are
  neither tagged nor abstract types in Ada 83.
unquote:

So, which post is correct, Georg? Or is it you,  who is speading 
"false allegations"!


In <4928ecad$0$32681$9b4e6d93@newsspool2.arcor-online.net>, Georg Bauhaus <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de> writes:
>anon wrote:
>
>> Since, the use of "base" attribute (as Adam stated) 
>> was used in this way and legal in Ada 83 specs. Then "GNAT 2005-2008" 
>> should still allow this statement, if the statement "Pragma Ada_83 ;" or 
>> command line "-gnat83" option is use.  But as someone else reported this is 
>> not the case.
>
>GNAT does handle 'Base specially when the user specifies
>-gnat83 on the command line. And, this is easily demonstrated
>by trying corresponding source with any of the versions of
>GNAT that have been mentioned, preventing the spread of false
>allegations.
>
>> As for GNAT 5.01 and GNAT Pro 6.01, well they were not written under the 
>> DOD and the RM only control.
>
>Huh? In DoD we trust. The rest of us is bugs.

Compiler quality (was: Extending discriminant types)

[Ludovic Brenta]

On Nov 23, 5:06 am, a...@anon.org (anon) wrote:
> What I am saying is that ALL BUG have been seen and reported by now for the
> GNAT-3.xx compilers, because of the volume of users and the amount of time
> that GNAT 3.xx series has been around.

Like I said i my earlier post, this is wrong, as has just been proven
when we discovered a previously inknown bug in GNAT 3.15p just a
couple of days ago. The bug is that GNAT 3.15p accepts T'Base for non-
scalar T, in the default (Ada 95) mode. Even 100 years from now, if a
single person still uses GNAT 3.15p, it will be possible for them to
discover a previously unknown bug.

Even an infinite amount of testing cannot prove a program to be bug-
free; it can only uncover an infinite amount of bugs. If you want to
prove a program correct, you must use formal methods, not testing.

> Also, professors may or may not call
> Adacore if they find a BUG, but they normally note the error for future
> reference.

I certainly hope professors (or any other user) don't keep their
records secret but instead report the bugs publicly, either in the
Debian bug tracking system (for GNAT 3.15p) or the GCC bugzilla (for
later versions).

> And that until 1997, all Ada compiler including the GNAT-3.xx series were
> under the control of the US's DOD and the RM and only the RM. All newer
> compilers are not under such strong arm control or limitation, rather that's
> the US gov't or the direct rules of the RM. So, you may see a more relax view
> on applying the RM, which mean that newer compiler nay have this and others
> types of an error, not found in the GNAT 3.xx series.

No, there is no "more relaxed view of the RM". The one thing that is
more relaxed is the trademark control over the name "Ada". All
versions of GNAT, in fact, undergo a constantly growing suite of tests
that includes and extends the ACATS. Every bug ever fixed has an
associated test to ensure the bug is never reintroduced. Of course,
bugs that are not yet fixed do not yet have such a test.

[...]
> Plus, the complete Ada 2005 specification compiler aka GNAT 2008, has only
> been around a few months and has yet to be fully tested by the Ada community
> which can take years.

Correct but that does not make GNAT 3.15p bug-free.

> As for GNAT 5.01 and GNAT Pro 6.01, well they were not written under the
> DOD and the RM only control. And they have not been around 10 to 14 years
> yet, for someone to say that 5.01 or 6.01 have been fully checked.

Like I said, even if you would use, say, GNAT Pro 5.01 for an infinite
amount of time, you could discover and correct an infinite number of
bugs and never be sure that the program is bug-free.

That's what first year CS students ought to learn, anyway.

--
Ludovic Brenta.

Re: Extending discriminant types

[christoph.grein]

On 21 Nov., 23:31, a...@anon.org (anon) wrote:
> But there is no place it say that it can not exist either! It up to the
> programmer! Plus "Base" is not a reserved word so it can be use in other
> places.

???? I gave the refrences in RM where deviations are allowed. This is
not one of them.

> >Implementations may define other attributes, but they are not allowed
> >to use attribute names defined in the standard.
>
>   Disprove by example RM 13.13 (84)
>
>     function My_Read(Stream : access Ada.Streams.Root_Stream_Type'Class)
>       return T;
>     for T'Read use My_Read; -- see 13.13.2
>
> Where the standard "Read" attribute is reassigned. In GNAT you are limited
> to the standard attributes only and that attribute structural definition but you
> can reassign them to user's code.

anon just makes himself sound awfully stupid. This is not a
redefinition of the 'Read attribute proper, but its proper use.

> Also, If you are correct it would of been listed in "RM Annex J" since it
> is valid under the Ada 83 specs.

No, Annex J just lists the obsolescent features, not the ones removed.
(This has already been stated before - and with the appropriate (AA)RM
references, but anon just refuses to understand).

> Georg Bauhaus
> Actually on the 20th you stated this:
> quote:
>   GNAT has -gnat83 as well, but rejects, too, because there are
>   neither tagged nor abstract types in Ada 83.
> unquote:
>
> So, which post is correct, Georg? Or is it you,  who is speading
> "false allegations"!

Of course it's you, anon, because -gnat83 must of course refuse the
use of tagged types.

Re: Extending discriminant types

[Georg Bauhaus]

anon schrieb:
> Georg Bauhaus
> 
> Actually on the 20th you stated this:
> 
> quote:
>   GNAT has -gnat83 as well, but rejects, too, because there are
>   neither tagged nor abstract types in Ada 83.
> unquote:

As I stated in parts missing from your quote, the compiler
rejects. But it rejects because of the presence of "tagged"
and "abstract", as it should. Not becuase of 'Base.

Again, this is easiest to see by actually trying the code
with any of the mentioned editions of GNAT, and -gnat83.

Re: Extending discriminant types

[anon]

Even if you delete the "tagged" word it reject that statement if you use 
"-gnat83", in either version in both GNAT-3.15p or GNAT GPL 2007. But as 
Adam and others have stated this is suppose to be legal in 83 only.  In 
checking with the Ada RM 83 and "DEC LRM 83. the Base was a concept only 
not a usable attribute, which is also stated in book "Ada Problem Solving and 
Program Design", 1990.  The "Base" attribute was introduce and added to the 
list of predefine attribute in the Ada 95 specs. 

That makes the paragraph that Adam listed from the AARM in Error.

gnat compile -gnat83 u.adb
 gcc -c -gnat83 u.adb
 u.ads:4:33: (Ada 83) Base attribute not allowed in subtype mark
 compilation abandoned due to previous error
 gnatmake: "u.adb" compilation error

package U is
  type T is private ; 

                     -- Replacing T with Integer will still result in an error 
                     -- for the 83 specs. Because Base is not an attribute 
                     -- in Ada 83.
  function "=" ( Left, Right : T'Base ) return Boolean ;

private
  type T is null record ;
end U ;


--
-- Dummy body package to comply with the specification package.
--
package body U is

  function "=" ( Left, Right : T'Base ) return Boolean is
    begin
      return False ;
    end ;
end U ;



In <492a7d07$0$30236$9b4e6d93@newsspool1.arcor-online.net>, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:
>anon schrieb:
>> Georg Bauhaus
>> 
>> Actually on the 20th you stated this:
>> 
>> quote:
>>   GNAT has -gnat83 as well, but rejects, too, because there are
>>   neither tagged nor abstract types in Ada 83.
>> unquote:
>
>As I stated in parts missing from your quote, the compiler
>rejects. But it rejects because of the presence of "tagged"
>and "abstract", as it should. Not becuase of 'Base.
>
>Again, this is easiest to see by actually trying the code
>with any of the mentioned editions of GNAT, and -gnat83.

Re: Compiler quality (was: Extending discriminant types)

[anon]

As I stated to G.B. The "Base" was a concept in 83, and the usage was 
illegal in 83.  See previous post.  

You also forget that Adacore has 100s may be even 1,000,000s of simple 
files they use for syntax checking for each Ada specifications.  That can 
trap all syntax type of errors. And that group of files grows yearly, if not 
daily.

But the way your statements sounds, you think the group of programmers at 
Adacore are lazy and allow bugs to pop up! I disagree with that of thinking! 

As for testing,  you might have been correct back in the 1950s to the early 
90s or if one uses other languages, such as C. But in using Ada with its 
finite set of strict syntax rules the number of test require to test the 
complete system is cut down to a more manageable level. And in today world 
it has become financial feasible for programmers to write and employ a 
group of programs to generate every combination of finite test for each of 
Ada rules and use a group of computers in parallel or multi-tasking to test 
every rule.  In that way the concept of releasing an Ada compiler with a 
syntax BUG goes way down to almost zero for a company like Adacore, because 
the nature and usage of Ada in the real world, it has too. 

Even Microsoft, with it 1000s of BUGs in its OSs and apps has very few 
BUGs in its compilers and link editors. And a few Microsoft compilers are 
even are clarified as BUG free.

Also even here, in "comp.lang.ada". There has been a number of posters that 
have stated they found a BUG or ask if this or that was a BUG. Most of those 
are logic or code generation type of errors, which this group shows that the 
error is not a compiler BUG. Even the syntax errors that are report here are 
shown by a number of regularly poster to be the fault of the programmer.  So, 
the concept of BUGs is kind of outdated, unless you have too many programmer
that are not working in tandem, that are not using a testing library.

And one reason is that most programmers reuse the old "syntax parsing" 
routines in the updated program, only changing the code to insert the new 
statements. Like inserting the rules for handling a "union" statement and or 
other new statements in the Ada 95 syntax routine which update that syntax
routine to handle the Ada 2005 specs. Then the programmers writes and adds 
the a set of new testing programs to the testing libraries.  But sometime 
adding new code does introduce a logic error into the existing syntax 
parser. but that not a syntax BUG it a logical programmer error.  And in 
Adacore the testing libraries are used to find and help correct the logic 
error before Adacore ever releases the next version of this compiler or 
package.

An example of this type of logical error was listed here a few months back 
when someone stated that the "pragma Unreferenced" was not working, but on 
the previous compiler it was. So, someone logical turn off the compiler 
usages of that statement. But that person forgot to turn it back on when they 
finish modifying the compiler. And that's a logic mistake not a BUG and if 
the person would of, used a testing library after they finish the modications 
of the compiler they would have found that mistake before they packaged 
and release the code.

And in the next generation of compiler, programs will construct the new 
compilers Testing is going on for this type of program now at schools and 
companies around the world, now.  And in this compiler the concept of a 
syntax BUG will not exist at all. Even today one can construct such a 
partition that can create an Ada 2005 compiler which contain no BUGs in the 
syntax parsing routine. But how many people want to create that program 
which put x number of people out of work, including themselves.

Now, this does not mean there are not BUGS, it just that they are 
becoming more of an hardware error, something that a program should be 
aware of but is hard to program for.


As for professors not reporting, well as any person that has attended a 
college knows professor are too busy. It a wonder how they get anything 
done. This is one of the minor reason that the education system needs 
a complete overhaul.



In <6691d418-5ce8-4584-8a09-3eb6bbc6d17f@v13g2000yqm.googlegroups.com>, Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
>On Nov 23, 5:06 am, a...@anon.org (anon) wrote:
>> What I am saying is that ALL BUG have been seen and reported by now for the
>> GNAT-3.xx compilers, because of the volume of users and the amount of time
>> that GNAT 3.xx series has been around.
>
>Like I said i my earlier post, this is wrong, as has just been proven
>when we discovered a previously inknown bug in GNAT 3.15p just a
>couple of days ago. The bug is that GNAT 3.15p accepts T'Base for non-
>scalar T, in the default (Ada 95) mode. Even 100 years from now, if a
>single person still uses GNAT 3.15p, it will be possible for them to
>discover a previously unknown bug.
>
>Even an infinite amount of testing cannot prove a program to be bug-
>free; it can only uncover an infinite amount of bugs. If you want to
>prove a program correct, you must use formal methods, not testing.
>
>> Also, professors may or may not call
>> Adacore if they find a BUG, but they normally note the error for future
>> reference.
>
>I certainly hope professors (or any other user) don't keep their
>records secret but instead report the bugs publicly, either in the
>Debian bug tracking system (for GNAT 3.15p) or the GCC bugzilla (for
>later versions).
>
>> And that until 1997, all Ada compiler including the GNAT-3.xx series were
>> under the control of the US's DOD and the RM and only the RM. All newer
>> compilers are not under such strong arm control or limitation, rather that's
>> the US gov't or the direct rules of the RM. So, you may see a more relax view
>> on applying the RM, which mean that newer compiler nay have this and others
>> types of an error, not found in the GNAT 3.xx series.
>
>No, there is no "more relaxed view of the RM". The one thing that is
>more relaxed is the trademark control over the name "Ada". All
>versions of GNAT, in fact, undergo a constantly growing suite of tests
>that includes and extends the ACATS. Every bug ever fixed has an
>associated test to ensure the bug is never reintroduced. Of course,
>bugs that are not yet fixed do not yet have such a test.
>
>[...]
>> Plus, the complete Ada 2005 specification compiler aka GNAT 2008, has only
>> been around a few months and has yet to be fully tested by the Ada community
>> which can take years.
>
>Correct but that does not make GNAT 3.15p bug-free.
>
>> As for GNAT 5.01 and GNAT Pro 6.01, well they were not written under the
>> DOD and the RM only control. And they have not been around 10 to 14 years
>> yet, for someone to say that 5.01 or 6.01 have been fully checked.
>
>Like I said, even if you would use, say, GNAT Pro 5.01 for an infinite
>amount of time, you could discover and correct an infinite number of
>bugs and never be sure that the program is bug-free.
>
>That's what first year CS students ought to learn, anyway.
>
>--
>Ludovic Brenta.

Re: Compiler quality (was: Extending discriminant types)

[christoph.grein]

On 25 Nov., 00:33, a...@anon.org (anon) wrote:
> As I stated to G.B. The "Base" was a concept in 83, and the usage was
> illegal in 83.  See previous post.  

Nonsense again - it is a predefined language attribute "for every type
or subtype", but only as a prefix for another attribute like
T'Base'First. See RM83 A(4).

Ada95 removed 'Base for any type other than scalar and made 'Base
usable by itself for scalar types.

anon has a very peculiar way to read the RMs, to say the least.

Re: Compiler quality (was: Extending discriminant types)

[Ludovic Brenta]

On Nov 25, 12:33 am, a...@anon.org (anon) wrote:
> You also forget that Adacore has 100s may be even 1,000,000s of simple
> files they use for syntax checking for each Ada specifications.  That can
> trap all syntax type of errors. And that group of files grows yearly, if not
> daily.

Apparently you also forgot to read what I wrote earlier:

> Even an infinite amount of testing cannot prove a program to be bug-
> free; it can only uncover an infinite amount of bugs. If you want to
> prove a program correct, you must use formal methods, not testing.

The rest of your rantings are only a consequence of this basic
misunderstanding of yours.

--
Ludovic Brenta.

Re: Extending discriminant types

[Martin]

On Nov 24, 10:16 pm, a...@anon.org (anon) wrote:
[snip]
>                      -- Replacing T with Integer will still result in an error
>                      -- for the 83 specs. Because Base is not an attribute
>                      -- in Ada 83.
>   function "=" ( Left, Right : T'Base ) return Boolean ;

That's not legal Ada83.

Look at Appendix A:

    * P'BASE
      For a prefix P that denotes a type or subtype:

                  This attribute denotes the base type of P.   It  is
only
                  allowed  as  the prefix of the name of another
attribute:
                  for example, P'BASE'FIRST.  (See 3.3.3.)

You can't ever use 'Base on its own in Ada83.

Cheers
-- Martin

Re: Extending discriminant types

[Georg Bauhaus]

Martin schrieb:

> You can't ever use 'Base on its own in Ada83.

The collection of multifocal arguments given
for or against 'Base, and/or GNAT, is, I guess,
multitargetting some other, ideas (that, frankly,
I find slightly elusive):

"the Base was a concept only not a usable attribute,
 which is also stated in book "Ada Problem  Solving and
 Program Design", 1990"  -- anon

However, 'Base can designate something very regular in
"Ada 83 mode",  it is not "just a concept", at
least in sofar as this would imply "not in the language".
(I don't have a copy of Mike Feldman's book, which anon
has been referencing in its enterity, so I can't check,
but I' guess that the author has not spun that many
arguments on loosly related issues around 'Base.)


As you point out, 'Base *is* an attribute (and nothing else)
in Ada 83, with a restriction on where and how to use it.
'Base can be applied to record type names in suitable context.

Other constructs of current and past editions of Ada
have similar restrictions, haven't they?

So here are two uses of 'Base.  The unit compiles fine,
it seems.

generic
   type N is (<>);
package U is

   type T (Len: Integer) is private ;
   type Count is new N range 0 .. N'Base'Last;  -- 'BASE

   function "=" ( Left, Right :  Count) return Boolean ;


private
   type T (Len: Integer) is record
      null;
   end record;

   X: T (Len => T'Base'Size) ; -- 'BASE, TOO
end U ;


A sequence of attributes is still part of Ada, so their
sequencing is not just Ada 83.

Re: Extending discriminant types

[Jeffrey R. Carter]

Georg Bauhaus wrote:
> 
> generic
>    type N is (<>);
> package U is
> 
>    type T (Len: Integer) is private ;
>    type Count is new N range 0 .. N'Base'Last;  -- 'BASE

It's interesting that this compiles, since N is not an integer type. I suspect 
you've uncovered a compiler error.

-- 
Jeff Carter
"C's solution to this [variable-sized array parameters] has real
problems, and people who are complaining about safety definitely
have a point."
Dennis Ritchie
25

Re: Extending discriminant types

[Adam Beneschan]

On Nov 25, 12:49 pm, "Jeffrey R. Carter"
<spam.jrcarter....@spam.acm.org> wrote:
> Georg Bauhaus wrote:
>
> > generic
> >    type N is (<>);
> > package U is
>
> >    type T (Len: Integer) is private ;
> >    type Count is new N range 0 .. N'Base'Last;  -- 'BASE
>
> It's interesting that this compiles, since N is not an integer type.
> I suspect
> you've uncovered a compiler error.

It also compiles if you remove the 'Base attribute.

                                -- Adam

Re: Extending discriminant types

[Georg Bauhaus]

Adam Beneschan wrote:
> On Nov 25, 12:49 pm, "Jeffrey R. Carter"
> <spam.jrcarter....@spam.acm.org> wrote:
>> Georg Bauhaus wrote:
>>
>>> generic
>>>    type N is (<>);
>>> package U is
>>>    type T (Len: Integer) is private ;
>>>    type Count is new N range 0 .. N'Base'Last;  -- 'BASE
>> It's interesting that this compiles, since N is not an integer type.
>> I suspect
>> you've uncovered a compiler error.
> 
> It also compiles if you remove the 'Base attribute.

In fact, GNAT has let me instantiate this unit in Ada 2005 mode
after I had commented the object declaration mentioning T'Base:

WITH u;
PACKAGE uu IS NEW u(N => INTEGER);

But I'm lost here, is this really a bug?  (I vaguely remember an
issue with using integer types for enum I/O, see below.)
Another compiler complains about N's range using inappropriate
operands. The Ada 83 RM explains generic formal (<>) type in terms
of their operations. And then, in 12.3 on Generic Instantiation,

"For each occurrence, within the generic unit, of a name that denotes a
 given entity, the following list defines which entity is denoted by the
 corresponding occurrence within the instance.
...
"4. For a name that denotes a generic formal type: The corresponding
    name denotes the subtype named by the associated generic actual
    parameter (the actual subtype). "

(Which, I believe, is INTEGER in the instantiation above.) The
following unit is accepted by two different compilers:

with Ada.Text_IO;
package I is new Ada.Text_IO.Enumeration_IO(Integer);

Re: Extending discriminant types

[Jeffrey R. Carter]

Georg Bauhaus wrote:
> 
> But I'm lost here, is this really a bug?

True, a discrete formal ["(<>)"] allows an integer actual. But consider

package P is new U (N => Boolean);

What is the range of Count? 0 .. True? Generic rules are supposed to be 
pessimistic; a compiler should not allow the declaration of Count just because 
the actual for N might be an integer type. So I think this is really an error.

-- 
Jeff Carter
"C's solution to this [variable-sized array parameters] has real
problems, and people who are complaining about safety definitely
have a point."
Dennis Ritchie
25

Re: Extending discriminant types

[Adam Beneschan]

On Nov 25, 2:33 pm, "Jeffrey R. Carter"
<spam.jrcarter....@spam.acm.org> wrote:
> Georg Bauhaus wrote:
>
> > But I'm lost here, is this really a bug?
>
> True, a discrete formal ["(<>)"] allows an integer actual. But consider
>
> package P is new U (N => Boolean);
>
> What is the range of Count? 0 .. True? Generic rules are supposed to be
> pessimistic; a compiler should not allow the declaration of Count just because
> the actual for N might be an integer type. So I think this is really an error.

It definitely is.  See 12.3(11); when a generic declaration and body
are compiled, the legality rules are enforced.  I won't go into which
Legality Rules apply to this specific example, but it's enough to say
that since N (a generic formal discrete type) is not an integer type,
you can't use a universal_integer where the expected type is N.

                                -- Adam

Re: Extending discriminant types

[Jeffrey R. Carter]

Adam Beneschan wrote:
> 
> It definitely is.  See 12.3(11); when a generic declaration and body
> are compiled, the legality rules are enforced.  I won't go into which
> Legality Rules apply to this specific example, but it's enough to say
> that since N (a generic formal discrete type) is not an integer type,
> you can't use a universal_integer where the expected type is N.

This still exists in GNAT Pro 6.1.1, so I've reported it.

-- 
Jeff Carter
"C's solution to this [variable-sized array parameters] has real
problems, and people who are complaining about safety definitely
have a point."
Dennis Ritchie
25

Re: Extending discriminant types

[Martin]

On Nov 26, 1:45 am, "Jeffrey R. Carter"
<spam.jrcarter....@spam.acm.org> wrote:
> Adam Beneschan wrote:
>
> > It definitely is.  See 12.3(11); when a generic declaration and body
> > are compiled, the legality rules are enforced.  I won't go into which
> > Legality Rules apply to this specific example, but it's enough to say
> > that since N (a generic formal discrete type) is not an integer type,
> > you can't use a universal_integer where the expected type is N.
>
> This still exists in GNAT Pro 6.1.1, so I've reported it.

Oh no, that's can't be right...I'm sure I read recently that compilers
were "bug free" these days... ;-)

Cheers
-- Martin

Re: Extending discriminant types

[Stefan Bellon]

On Wed, 26 Nov, Martin wrote:
> On Nov 26, 1:45 am, "Jeffrey R. Carter"
> <spam.jrcarter....@spam.acm.org> wrote:

> > This still exists in GNAT Pro 6.1.1, so I've reported it.
> 
> Oh no, that's can't be right...I'm sure I read recently that compilers
> were "bug free" these days... ;-)

No, in this case, you misinterpreted anon. He said that 3.15p must be
bug free, just because it is released such a long time and so many
people have used it, that there just can't be any more bugs in it.

And indeed I am curious whether this bug exists in 3.15p or not.

-- 
Stefan Bellon

Re: Extending discriminant types

[Martin]

On Nov 26, 9:38 am, Stefan Bellon <bel...@software-erosion.org> wrote:
> On Wed, 26 Nov, Martin wrote:
> > On Nov 26, 1:45 am, "Jeffrey R. Carter"
> > <spam.jrcarter....@spam.acm.org> wrote:
> > > This still exists in GNAT Pro 6.1.1, so I've reported it.
>
> > Oh no, that's can't be right...I'm sure I read recently that compilers
> > were "bug free" these days... ;-)
>
> No, in this case, you misinterpreted anon. He said that 3.15p must be
> bug free, just because it is released such a long time and so many
> people have used it, that there just can't be any more bugs in it.
>
> And indeed I am curious whether this bug exists in 3.15p or not.

Sorry, the joke was lost in typing...or perhaps it was just a bad
joke... (I hoped the smiley would have given it away...)

Cheers
-- Martin

Re: Extending discriminant types

[Stefan Bellon]

On Wed, 26 Nov, Martin wrote:

> Sorry, the joke was lost in typing...or perhaps it was just a bad
> joke... (I hoped the smiley would have given it away...)

No, it is a good one. Especially because GNAT 3.15p seems to exhibit
this bug as well. ;-)

-- 
Stefan Bellon

Re: Extending discriminant types

[Ludovic Brenta]

On Nov 26, 11:16 am, Stefan Bellon <bel...@software-erosion.org>
wrote:
> On Wed, 26 Nov, Martin wrote:
> > Sorry, the joke was lost in typing...or perhaps it was just a bad
> > joke... (I hoped the smiley would have given it away...)
>
> No, it is a good one. Especially because GNAT 3.15p seems to exhibit
> this bug as well. ;-)

Yes indeed.

anon's theorem: the number of bugs in a program decreases with time
and eventually reaches zero, whether or not anyone maintains the
program. (However, to observe this theorem, someone must use the
program.)

I'd be interested in anon's proof of that theorem. That would
definitely make it into the Jargon file :)

--
Ludovic Brenta.

Re: Extending discriminant types

[Niklas Holsti]

Stefan Bellon wrote:

> And indeed I am curious whether this bug exists in 3.15p or not.

Yes, it seems to exist in 3.15p. Under Debian gnat 3.15p (gnatgcc 
2.8.1), this package declaration compiles without error messages:

    generic
       type N is (<>);
    package U is
       type Count is new N range 0 .. N'Last;
    end U;

Compiling an instantiation "is new U (N => Boolean)" gives error 
messages:

m.adb:6:04: instantiation error at u.ads:4
m.adb:6:04: expected type "Standard.Boolean"
m.adb:6:04: instantiation error at u.ads:4
m.adb:6:04: found type universal integer

So at least the error is detected before run-time.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Extending discriminant types

[Stefan Bellon]

On Wed, 26 Nov, Ludovic Brenta wrote:

> On Nov 26, 11:16 am, Stefan Bellon <bel...@software-erosion.org>
> wrote:

> > No, it is a good one. Especially because GNAT 3.15p seems to exhibit
> > this bug as well. ;-)
> 
> Yes indeed.

His only escape could be to prove that GNAT 3.15p is in fact correct in
accepting it because it is no bug at all.

-- 
Stefan Bellon

Re: Extending discriminant types

[Adam Beneschan]

On Nov 26, 3:05 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:

> anon's theorem: the number of bugs in a program decreases with time
> and eventually reaches zero, whether or not anyone maintains the
> program. (However, to observe this theorem, someone must use the
> program.)
>
> I'd be interested in anon's proof of that theorem. That would
> definitely make it into the Jargon file :)

I'm not sure that it could be proven mathematically, but perhaps it
could be tested.  In particular, we could test whether this theory or
the contrary theory is true, the contrary theory being one that you
posted earlier in this thread:

## Even an infinite amount of testing cannot prove a program to be
bug-
## free; it can only uncover an infinite amount of bugs.

While this may not be literally true---I suspect it is mathematically
impossible for a finite compiler to have an infinite number of bugs---
it could be reformulated in a way that makes it amenable to testing.
My proposal, then, is that if anon can't prove his theory formally, we
should ask him to do it empirically by performing an infinite amount
of testing on GNAT, and then coming back to comp.lang.ada and
reporting on the results once this testing process is complete.

                                -- Adam

Re: Extending discriminant types

[Ludovic Brenta]

On Nov 26, 4:49 pm, Adam Beneschan <a...@irvine.com> wrote:
> On Nov 26, 3:05 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>
> > anon's theorem: the number of bugs in a program decreases with time
> > and eventually reaches zero, whether or not anyone maintains the
> > program. (However, to observe this theorem, someone must use the
> > program.)
>
> > I'd be interested in anon's proof of that theorem. That would
> > definitely make it into the Jargon file :)
>
> I'm not sure that it could be proven mathematically, but perhaps it
> could be tested.  In particular, we could test whether this theory or
> the contrary theory is true, the contrary theory being one that you
> posted earlier in this thread:
>
> ## Even an infinite amount of testing cannot prove a program to be
> bug-
> ## free; it can only uncover an infinite amount of bugs.
>
> While this may not be literally true---I suspect it is mathematically
> impossible for a finite compiler to have an infinite number of bugs---
> it could be reformulated in a way that makes it amenable to testing.
> My proposal, then, is that if anon can't prove his theory formally, we
> should ask him to do it empirically by performing an infinite amount
> of testing on GNAT, and then coming back to comp.lang.ada and
> reporting on the results once this testing process is complete.

I'd second that. In order not to overburden anon, I'd not require him
to report on his progress until he's finished.

--
Ludovic Brenta.
Eternity is long, especially towards the end.

Re: Compiler quality (was: Extending discriminant types)

[anon]

Your not understanding the concept finite for programs. And this explanation 
does not the finite concept of hardware.

The Ada RM states in 2.2 (15) that the implementation must support at least 
200 character in a line length and lexical elements. But the RM allows the 
implementation to set the default maximum size.

So, by definition a identifier (a lexical elements) is define as:

RM 2.3 (2)   identifier ::=   identifier_letter {[underline] letter_or_digit}
RM 2.3 (3)   letter_or_digit ::= identifier_letter | digit


RM 2.1 (7)   identifier_letter
                upper_case_identifier_letter | lower_case_identifier_letter

RM 2.1 (8)   upper_case_identifier_letter
                Any character of Row 00 of ISO 10646 BMP whose name begins
                ``Latin Capital Letter''.

RM 2.1 (9)   lower_case_identifier_letter
                Any character of Row 00 of ISO 10646 BMP whose name begins
                ``Latin Small Letter''.

RM 2.1 (10)  digit =>   One of the characters 0, 1, 2, 3, 4, 5, 6, 7, 8, or 9.



So, identifier has only a finite number of characters that may be use, with the 
length set by the vendor there exist only a finite number of identifiers that the 
vendor's compiler can use. That number may be large by the RM definition but 
it is still finite value.

Which means there is NO infinite number of identifier, so your are in error 
about infinite.

So anyone can create a program that can create a single to multi set of 
programs to test every identifier that a vendors's compiler can use.

And every statement type is defined in the RM and because the vendor also set 
limits, there exist only a finite number of statements.

Also, for testing identifier in GNAT you can use the "-gnatMxx" where xx is a 
smaller number such as 10 to 15 another finite number. That way, the number 
of identifier is more manageable.


The problem is, do you need to generate every statement to prove there is no 
syntax BUGs in a computer. 
The answer is no! 

An example is like using the following statement

                   X := Sin ( A ) + Cos ( W ) ;

do use need to also create the statement

                   X := Cos ( W ) + Sin ( A ) ;

to prove that a simple mathematical statement is BUG free.  The answer is no! 
So a vendor may use one not both to perform the test, to say the statement 
checking is BUG free.  

And using every statement that can be created is just overkill, but it can be 
done. There are places in a compiler that are tested to the point of being 
BUG free and that number of testing is finite. 


In <9cb27caa-8e9f-4123-ad36-4980c3032722@20g2000yqt.googlegroups.com>, Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
>On Nov 25, 12:33 am, a...@anon.org (anon) wrote:
>> You also forget that Adacore has 100s may be even 1,000,000s of simple
>> files they use for syntax checking for each Ada specifications.  That can
>> trap all syntax type of errors. And that group of files grows yearly, if not
>> daily.
>
>Apparently you also forgot to read what I wrote earlier:
>
>> Even an infinite amount of testing cannot prove a program to be bug-
>> free; it can only uncover an infinite amount of bugs. If you want to
>> prove a program correct, you must use formal methods, not testing.
>
>The rest of your rantings are only a consequence of this basic
>misunderstanding of yours.
>
>--
>Ludovic Brenta.

Re: Compiler quality

[Georg Bauhaus]

anon schrieb:
> Your not understanding the concept finite for programs. And this explanation 
> does not the finite concept of hardware.

(Just for clarity, a program text is finite by definition.)

Please, could you give the cardinality of the set of 4kB-Ada programs
that a given compiler, such as GNAT 3.15p, can process, and decide,
on a PC of 1GB RAM, 200GB file space, within 1h?  I'd like to be
realistic, so I'll be glad to learn the factor F and an exponent
N in F*10**N.

How does this number compare to the cardinality of the set of Ada
programs of 6_000 .. 10_000 SLOC?  (That's roughly the size
of a book.)

How long does it take to demonstrate that a single Ada program
should map to one sequence of CPU instructions? (Else we have
not a single, complete, test case, because a compiled program may
just happen to produce expected results in some cases.)



> An example is like using the following statement
> 
>                    X := Sin ( A ) + Cos ( W ) ;
> 
> do use need to also create the statement
> 
>                    X := Cos ( W ) + Sin ( A ) ;
> 
> to prove that a simple mathematical statement is BUG free.  The answer is no! 
> So a vendor may use one not both to perform the test, to say the statement 
> checking is BUG free.  

Good example, because the order of FPT operations may affect
the result of the statements. So the answer is yes, you may
have to test both statements, with all kinds of inputs for W and A...
(Note that I'm not saying you need all *possible* inputs, just
those that one needs within the given FPT framework. They have been
named in extensive literature.)


> And using every statement that can be created is just overkill, but it can be 
> done. There are places in a compiler that are tested to the point of being 
> BUG free and that number of testing is finite. 

By your previous argument about bug free compilers,
a compiler is therefore the same as a place in a compiler,
as far as testing goes...

Re: Compiler quality

[Ludovic Brenta]

anon schrieb:
> An example is like using the following statement
>                    X := Sin ( A ) + Cos ( W ) ;
> do use need to also create the statement
>                    X := Cos ( W ) + Sin ( A ) ;

Yes, as evidenced by http://gcc.gnu.org/PR16095 among others.
Schematically, this bug is triggered by "A = B" but not by "B = A".
And incidentally, it is present in the "bug-free" GNAT 3.15p.

--
Ludovic Brenta.

Re: Compiler quality

[Martin]

On Nov 27, 2:46 pm, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> anon schrieb:
>
> > An example is like using the following statement
> >                    X := Sin ( A ) + Cos ( W ) ;
> > do use need to also create the statement
> >                    X := Cos ( W ) + Sin ( A ) ;
>
> Yes, as evidenced byhttp://gcc.gnu.org/PR16095among others.
> Schematically, this bug is triggered by "A = B" but not by "B = A".
> And incidentally, it is present in the "bug-free" GNAT 3.15p.

To be fair to anon...that's not a SYNTAX bug. His claim was that
compilers should be able to be 100% tested for syntax bugs by limiting
the input so much that's it becomes practical to do on current
machines.

Cheers
-- Martin

Re: Compiler quality

[Georg Bauhaus]

Martin wrote:

> To be fair to anon...that's not a SYNTAX bug. His claim was that
> compilers should be able to be 100% tested for syntax bugs by limiting
> the input so much that's it becomes practical to do on current
> machines.

Considering the Ada 83 rule that 'Base must be prefixed to
'Another_Attribute (i.e., have context), do Ada compilers
typically  check this rule in the parts handling syntax?
(In the case of GNAT, the sem*.ad? files refer to the 'Base
attribute, AFAICS.)

Re: Compiler quality

[Randy Brukardt]

"Georg Bauhaus" <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de> wrote in 
message news:492fc7bc$0$31869$9b4e6d93@newsspool3.arcor-online.net...
> Martin wrote:
>
>> To be fair to anon...that's not a SYNTAX bug. His claim was that
>> compilers should be able to be 100% tested for syntax bugs by limiting
>> the input so much that's it becomes practical to do on current
>> machines.
>
> Considering the Ada 83 rule that 'Base must be prefixed to
> 'Another_Attribute (i.e., have context), do Ada compilers
> typically  check this rule in the parts handling syntax?
> (In the case of GNAT, the sem*.ad? files refer to the 'Base
> attribute, AFAICS.)

I don't think so; the typical syntax for attributes is something like:

    prefix APOSTROPHE IDENTIFIER

where the capitalized items are terminals ' and an identifier. The only 
"identifier"s that have special handling in the syntax are the reserved 
words, and "base" is not reserved.

A data point about anon's more general point. We discovered a syntax 
processing error (in our case, an error in the grammar input to the table 
generator for the syntax part of Janus/Ada 95) more than 6 1/2 years after 
the Ada 95 grammar was completed (and the associated compiler was in use by 
many people during the time period of February 1996 to November 2002). The 
error was allowing the declaration of abstract subprograms in places that 
they are not allowed, such as generic formal parameters.

The point is that no amount of (sane) testing can find unintended additional 
capabilities -- because the only way to do that is to guess the possible 
errors, and that is not a practical thing to do as there is a very low 
probability of actually finding any errors. Thus such testing is not a good 
use of limited testing effort; there are many more things that are better 
uses of effort. For this reason, the ACATS does not test separately for 
syntax errors unless there is a significant probability that the error will 
be detected outside of the syntax portion of the compiler. After all, most 
compiler parsers are generated by tools these days, so the errors will 
almost certainly be limited to simple errors (omission, transposition, or 
substitution) in the input to those tools and can be detected by pretty much 
any use of a particular feature of the language. Thus the tests for other 
language rules provide enough testing for the syntax proper. (I believe that 
GNAT uses a hand-coded parser, and thus is at somewhat more risk for syntax 
processing errors than most other compilers, but that still seems to be a 
low priority error to detect compared to violations of other language 
rules.)

Testing in general is a poor way to eliminate errors in a compiler. Back in 
1997, I ran some coverage tests to determine what code in Janus/Ada has been 
executed in tests. (That doesn't prove that such code will work in all 
circumstances, but code that is executed is more likely to be correct than 
code that has never been known to be executed.) I ran pretty much every test 
and program that we had access to at the time (more than a thousand in-house 
tests, plus the ACATS, plus Claw and its tests, plus the compiler source 
code), and still was able only to show coverage on about 70% of the code in 
the part of the compiler I was testing. While some of the unreached paths 
detected internal compiler errors (that is, represented redundant checks), 
many of them represented combinations of language features that had simply 
not been tested. (Looking at a randomly selected piece of the compiler, some 
such cases are a timed internal protected entry call; selection of a 
component from a formal parameter of an unconstrained record type; and 
selection of a component using the "current instance" of a protected 
object.) My original idea was to write some test cases to try to reach the 
untouched code, but the magnitude of the task made it impractical. (It would 
make more sense to use "white box" unit tests to force coverage, but that 
brings up the possibility of spending a lot of time testing things that 
can't happen in real input programs. Not a great choice either way.)

                                        Randy.