* Extending discriminant types @ 2008-11-15 9:16 Stefan Bellon 2008-11-15 18:50 ` Jeffrey R. Carter ` (2 more replies) 0 siblings, 3 replies; 68+ messages in thread From: Stefan Bellon @ 2008-11-15 9:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-15 9:16 Extending discriminant types Stefan Bellon @ 2008-11-15 18:50 ` Jeffrey R. Carter 2008-11-17 16:30 ` Adam Beneschan 2008-11-19 9:49 ` anon 2 siblings, 0 replies; 68+ messages in thread From: Jeffrey R. Carter @ 2008-11-15 18:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-15 9:16 Extending discriminant types Stefan Bellon 2008-11-15 18:50 ` Jeffrey R. Carter @ 2008-11-17 16:30 ` Adam Beneschan 2008-11-18 11:02 ` christoph.grein 2008-11-19 9:49 ` anon 2 siblings, 1 reply; 68+ messages in thread From: Adam Beneschan @ 2008-11-17 16:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-17 16:30 ` Adam Beneschan @ 2008-11-18 11:02 ` christoph.grein 2008-11-18 23:24 ` Adam Beneschan 0 siblings, 1 reply; 68+ messages in thread From: christoph.grein @ 2008-11-18 11:02 UTC (permalink / raw) > Var : Base_Access := new Child'Base' (K => A); Attribute 'Base exists for scalar types only. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-18 11:02 ` christoph.grein @ 2008-11-18 23:24 ` Adam Beneschan 0 siblings, 0 replies; 68+ messages in thread From: Adam Beneschan @ 2008-11-18 23:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-15 9:16 Extending discriminant types Stefan Bellon 2008-11-15 18:50 ` Jeffrey R. Carter 2008-11-17 16:30 ` Adam Beneschan @ 2008-11-19 9:49 ` anon 2008-11-19 10:15 ` christoph.grein ` (2 more replies) 2 siblings, 3 replies; 68+ messages in thread From: anon @ 2008-11-19 9:49 UTC (permalink / raw) -- 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 > ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-19 9:49 ` anon @ 2008-11-19 10:15 ` christoph.grein 2008-11-19 19:19 ` Georg Bauhaus 2008-11-19 11:38 ` Martin 2008-11-20 7:21 ` anon 2 siblings, 1 reply; 68+ messages in thread From: christoph.grein @ 2008-11-19 10:15 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-19 10:15 ` christoph.grein @ 2008-11-19 19:19 ` Georg Bauhaus 0 siblings, 0 replies; 68+ messages in thread From: Georg Bauhaus @ 2008-11-19 19:19 UTC (permalink / raw) 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" ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-19 9:49 ` anon 2008-11-19 10:15 ` christoph.grein @ 2008-11-19 11:38 ` Martin 2008-11-20 7:21 ` anon 2 siblings, 0 replies; 68+ messages in thread From: Martin @ 2008-11-19 11:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-19 9:49 ` anon 2008-11-19 10:15 ` christoph.grein 2008-11-19 11:38 ` Martin @ 2008-11-20 7:21 ` anon 2008-11-20 8:30 ` christoph.grein 2008-11-20 9:55 ` Martin 2 siblings, 2 replies; 68+ messages in thread From: anon @ 2008-11-20 7:21 UTC (permalink / raw) 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 >> > ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-20 7:21 ` anon @ 2008-11-20 8:30 ` christoph.grein 2008-11-20 8:36 ` Ludovic Brenta 2008-11-20 22:59 ` anon 2008-11-20 9:55 ` Martin 1 sibling, 2 replies; 68+ messages in thread From: christoph.grein @ 2008-11-20 8:30 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-20 8:30 ` christoph.grein @ 2008-11-20 8:36 ` Ludovic Brenta 2008-11-20 11:45 ` Georg Bauhaus 2008-11-20 22:59 ` anon 1 sibling, 1 reply; 68+ messages in thread From: Ludovic Brenta @ 2008-11-20 8:36 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-20 8:36 ` Ludovic Brenta @ 2008-11-20 11:45 ` Georg Bauhaus 2008-11-20 11:46 ` Georg Bauhaus ` (3 more replies) 0 siblings, 4 replies; 68+ messages in thread From: Georg Bauhaus @ 2008-11-20 11:45 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-20 11:45 ` Georg Bauhaus @ 2008-11-20 11:46 ` Georg Bauhaus 2008-11-20 23:01 ` anon 2008-11-20 14:03 ` Dmitry A. Kazakov ` (2 subsequent siblings) 3 siblings, 1 reply; 68+ messages in thread From: Georg Bauhaus @ 2008-11-20 11:46 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-20 11:46 ` Georg Bauhaus @ 2008-11-20 23:01 ` anon 2008-11-21 11:54 ` Ludovic Brenta 0 siblings, 1 reply; 68+ messages in thread From: anon @ 2008-11-20 23:01 UTC (permalink / raw) -- -- 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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-20 23:01 ` anon @ 2008-11-21 11:54 ` Ludovic Brenta 0 siblings, 0 replies; 68+ messages in thread From: Ludovic Brenta @ 2008-11-21 11:54 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-20 11:45 ` Georg Bauhaus 2008-11-20 11:46 ` Georg Bauhaus @ 2008-11-20 14:03 ` Dmitry A. Kazakov 2008-11-20 15:03 ` Robert A Duff 2008-11-20 16:11 ` Adam Beneschan 3 siblings, 0 replies; 68+ messages in thread From: Dmitry A. Kazakov @ 2008-11-20 14:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-20 11:45 ` Georg Bauhaus 2008-11-20 11:46 ` Georg Bauhaus 2008-11-20 14:03 ` Dmitry A. Kazakov @ 2008-11-20 15:03 ` Robert A Duff 2008-11-20 15:57 ` Stefan Bellon 2008-11-20 16:11 ` Adam Beneschan 3 siblings, 1 reply; 68+ messages in thread From: Robert A Duff @ 2008-11-20 15:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-20 15:03 ` Robert A Duff @ 2008-11-20 15:57 ` Stefan Bellon 2008-11-21 0:32 ` Adam Beneschan 0 siblings, 1 reply; 68+ messages in thread From: Stefan Bellon @ 2008-11-20 15:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-20 15:57 ` Stefan Bellon @ 2008-11-21 0:32 ` Adam Beneschan 0 siblings, 0 replies; 68+ messages in thread From: Adam Beneschan @ 2008-11-21 0:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-20 11:45 ` Georg Bauhaus ` (2 preceding siblings ...) 2008-11-20 15:03 ` Robert A Duff @ 2008-11-20 16:11 ` Adam Beneschan 3 siblings, 0 replies; 68+ messages in thread From: Adam Beneschan @ 2008-11-20 16:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-20 8:30 ` christoph.grein 2008-11-20 8:36 ` Ludovic Brenta @ 2008-11-20 22:59 ` anon 2008-11-21 0:29 ` Adam Beneschan ` (2 more replies) 1 sibling, 3 replies; 68+ messages in thread From: anon @ 2008-11-20 22:59 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-20 22:59 ` anon @ 2008-11-21 0:29 ` Adam Beneschan 2008-11-21 7:25 ` anon 2008-11-21 6:11 ` christoph.grein 2008-11-21 11:44 ` Martin 2 siblings, 1 reply; 68+ messages in thread From: Adam Beneschan @ 2008-11-21 0:29 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-21 0:29 ` Adam Beneschan @ 2008-11-21 7:25 ` anon 2008-11-21 9:19 ` Jean-Pierre Rosen ` (2 more replies) 0 siblings, 3 replies; 68+ messages in thread From: anon @ 2008-11-21 7:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-21 7:25 ` anon @ 2008-11-21 9:19 ` Jean-Pierre Rosen 2008-11-21 10:11 ` christoph.grein 2008-11-21 12:00 ` Ludovic Brenta 2 siblings, 0 replies; 68+ messages in thread From: Jean-Pierre Rosen @ 2008-11-21 9:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-21 7:25 ` anon 2008-11-21 9:19 ` Jean-Pierre Rosen @ 2008-11-21 10:11 ` christoph.grein 2008-11-21 12:00 ` Ludovic Brenta 2 siblings, 0 replies; 68+ messages in thread From: christoph.grein @ 2008-11-21 10:11 UTC (permalink / raw) > 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! ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-21 7:25 ` anon 2008-11-21 9:19 ` Jean-Pierre Rosen 2008-11-21 10:11 ` christoph.grein @ 2008-11-21 12:00 ` Ludovic Brenta 2008-11-21 22:31 ` anon 2 siblings, 1 reply; 68+ messages in thread From: Ludovic Brenta @ 2008-11-21 12:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-21 12:00 ` Ludovic Brenta @ 2008-11-21 22:31 ` anon 2008-11-22 0:18 ` Stefan Bellon ` (2 more replies) 0 siblings, 3 replies; 68+ messages in thread From: anon @ 2008-11-21 22:31 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-21 22:31 ` anon @ 2008-11-22 0:18 ` Stefan Bellon 2008-11-23 4:06 ` anon 2008-11-22 13:10 ` Extending discriminant types Gautier 2008-11-24 8:24 ` christoph.grein 2 siblings, 1 reply; 68+ messages in thread From: Stefan Bellon @ 2008-11-22 0:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-22 0:18 ` Stefan Bellon @ 2008-11-23 4:06 ` anon 2008-11-23 5:39 ` Georg Bauhaus 2008-11-23 8:48 ` Compiler quality (was: Extending discriminant types) Ludovic Brenta 0 siblings, 2 replies; 68+ messages in thread From: anon @ 2008-11-23 4:06 UTC (permalink / raw) 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 > ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-23 4:06 ` anon @ 2008-11-23 5:39 ` Georg Bauhaus 2008-11-23 8:00 ` anon 2008-11-23 8:48 ` Compiler quality (was: Extending discriminant types) Ludovic Brenta 1 sibling, 1 reply; 68+ messages in thread From: Georg Bauhaus @ 2008-11-23 5:39 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-23 5:39 ` Georg Bauhaus @ 2008-11-23 8:00 ` anon 2008-11-24 10:08 ` Georg Bauhaus 0 siblings, 1 reply; 68+ messages in thread From: anon @ 2008-11-23 8:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-23 8:00 ` anon @ 2008-11-24 10:08 ` Georg Bauhaus 2008-11-24 22:16 ` anon 0 siblings, 1 reply; 68+ messages in thread From: Georg Bauhaus @ 2008-11-24 10:08 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-24 10:08 ` Georg Bauhaus @ 2008-11-24 22:16 ` anon 2008-11-25 10:37 ` Martin 0 siblings, 1 reply; 68+ messages in thread From: anon @ 2008-11-24 22:16 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-24 22:16 ` anon @ 2008-11-25 10:37 ` Martin 2008-11-25 11:24 ` Georg Bauhaus 0 siblings, 1 reply; 68+ messages in thread From: Martin @ 2008-11-25 10:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-25 10:37 ` Martin @ 2008-11-25 11:24 ` Georg Bauhaus 2008-11-25 20:49 ` Jeffrey R. Carter 0 siblings, 1 reply; 68+ messages in thread From: Georg Bauhaus @ 2008-11-25 11:24 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-25 11:24 ` Georg Bauhaus @ 2008-11-25 20:49 ` Jeffrey R. Carter 2008-11-25 21:01 ` Adam Beneschan 0 siblings, 1 reply; 68+ messages in thread From: Jeffrey R. Carter @ 2008-11-25 20:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-25 20:49 ` Jeffrey R. Carter @ 2008-11-25 21:01 ` Adam Beneschan 2008-11-25 22:09 ` Georg Bauhaus 0 siblings, 1 reply; 68+ messages in thread From: Adam Beneschan @ 2008-11-25 21:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-25 21:01 ` Adam Beneschan @ 2008-11-25 22:09 ` Georg Bauhaus 2008-11-25 22:33 ` Jeffrey R. Carter 0 siblings, 1 reply; 68+ messages in thread From: Georg Bauhaus @ 2008-11-25 22:09 UTC (permalink / raw) 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); ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-25 22:09 ` Georg Bauhaus @ 2008-11-25 22:33 ` Jeffrey R. Carter 2008-11-26 0:58 ` Adam Beneschan 0 siblings, 1 reply; 68+ messages in thread From: Jeffrey R. Carter @ 2008-11-25 22:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-25 22:33 ` Jeffrey R. Carter @ 2008-11-26 0:58 ` Adam Beneschan 2008-11-26 1:45 ` Jeffrey R. Carter 0 siblings, 1 reply; 68+ messages in thread From: Adam Beneschan @ 2008-11-26 0:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-26 0:58 ` Adam Beneschan @ 2008-11-26 1:45 ` Jeffrey R. Carter 2008-11-26 9:31 ` Martin 0 siblings, 1 reply; 68+ messages in thread From: Jeffrey R. Carter @ 2008-11-26 1:45 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-26 1:45 ` Jeffrey R. Carter @ 2008-11-26 9:31 ` Martin 2008-11-26 9:38 ` Stefan Bellon 0 siblings, 1 reply; 68+ messages in thread From: Martin @ 2008-11-26 9:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-26 9:31 ` Martin @ 2008-11-26 9:38 ` Stefan Bellon 2008-11-26 9:48 ` Martin 2008-11-26 11:10 ` Niklas Holsti 0 siblings, 2 replies; 68+ messages in thread From: Stefan Bellon @ 2008-11-26 9:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-26 9:38 ` Stefan Bellon @ 2008-11-26 9:48 ` Martin 2008-11-26 10:16 ` Stefan Bellon 2008-11-26 11:10 ` Niklas Holsti 1 sibling, 1 reply; 68+ messages in thread From: Martin @ 2008-11-26 9:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-26 9:48 ` Martin @ 2008-11-26 10:16 ` Stefan Bellon 2008-11-26 11:05 ` Ludovic Brenta 0 siblings, 1 reply; 68+ messages in thread From: Stefan Bellon @ 2008-11-26 10:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-26 10:16 ` Stefan Bellon @ 2008-11-26 11:05 ` Ludovic Brenta 2008-11-26 11:33 ` Stefan Bellon 2008-11-26 15:49 ` Adam Beneschan 0 siblings, 2 replies; 68+ messages in thread From: Ludovic Brenta @ 2008-11-26 11:05 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-26 11:05 ` Ludovic Brenta @ 2008-11-26 11:33 ` Stefan Bellon 2008-11-26 15:49 ` Adam Beneschan 1 sibling, 0 replies; 68+ messages in thread From: Stefan Bellon @ 2008-11-26 11:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-26 11:05 ` Ludovic Brenta 2008-11-26 11:33 ` Stefan Bellon @ 2008-11-26 15:49 ` Adam Beneschan 2008-11-26 16:15 ` Ludovic Brenta 1 sibling, 1 reply; 68+ messages in thread From: Adam Beneschan @ 2008-11-26 15:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-26 15:49 ` Adam Beneschan @ 2008-11-26 16:15 ` Ludovic Brenta 0 siblings, 0 replies; 68+ messages in thread From: Ludovic Brenta @ 2008-11-26 16:15 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-26 9:38 ` Stefan Bellon 2008-11-26 9:48 ` Martin @ 2008-11-26 11:10 ` Niklas Holsti 1 sibling, 0 replies; 68+ messages in thread From: Niklas Holsti @ 2008-11-26 11:10 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 68+ messages in thread
* Compiler quality (was: Extending discriminant types) 2008-11-23 4:06 ` anon 2008-11-23 5:39 ` Georg Bauhaus @ 2008-11-23 8:48 ` Ludovic Brenta 2008-11-24 23:33 ` anon 1 sibling, 1 reply; 68+ messages in thread From: Ludovic Brenta @ 2008-11-23 8:48 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Compiler quality (was: Extending discriminant types) 2008-11-23 8:48 ` Compiler quality (was: Extending discriminant types) Ludovic Brenta @ 2008-11-24 23:33 ` anon 2008-11-25 6:54 ` christoph.grein 2008-11-25 10:01 ` Ludovic Brenta 0 siblings, 2 replies; 68+ messages in thread From: anon @ 2008-11-24 23:33 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Compiler quality (was: Extending discriminant types) 2008-11-24 23:33 ` anon @ 2008-11-25 6:54 ` christoph.grein 2008-11-25 10:01 ` Ludovic Brenta 1 sibling, 0 replies; 68+ messages in thread From: christoph.grein @ 2008-11-25 6:54 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Compiler quality (was: Extending discriminant types) 2008-11-24 23:33 ` anon 2008-11-25 6:54 ` christoph.grein @ 2008-11-25 10:01 ` Ludovic Brenta 2008-11-26 23:34 ` anon 1 sibling, 1 reply; 68+ messages in thread From: Ludovic Brenta @ 2008-11-25 10:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Compiler quality (was: Extending discriminant types) 2008-11-25 10:01 ` Ludovic Brenta @ 2008-11-26 23:34 ` anon 2008-11-27 10:24 ` Compiler quality Georg Bauhaus 0 siblings, 1 reply; 68+ messages in thread From: anon @ 2008-11-26 23:34 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Compiler quality 2008-11-26 23:34 ` anon @ 2008-11-27 10:24 ` Georg Bauhaus 2008-11-27 14:46 ` Ludovic Brenta 0 siblings, 1 reply; 68+ messages in thread From: Georg Bauhaus @ 2008-11-27 10:24 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Compiler quality 2008-11-27 10:24 ` Compiler quality Georg Bauhaus @ 2008-11-27 14:46 ` Ludovic Brenta 2008-11-28 9:13 ` Martin 0 siblings, 1 reply; 68+ messages in thread From: Ludovic Brenta @ 2008-11-27 14:46 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Compiler quality 2008-11-27 14:46 ` Ludovic Brenta @ 2008-11-28 9:13 ` Martin 2008-11-28 10:28 ` Georg Bauhaus 0 siblings, 1 reply; 68+ messages in thread From: Martin @ 2008-11-28 9:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Compiler quality 2008-11-28 9:13 ` Martin @ 2008-11-28 10:28 ` Georg Bauhaus 2008-12-02 3:51 ` Randy Brukardt 0 siblings, 1 reply; 68+ messages in thread From: Georg Bauhaus @ 2008-11-28 10:28 UTC (permalink / raw) 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.) ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Compiler quality 2008-11-28 10:28 ` Georg Bauhaus @ 2008-12-02 3:51 ` Randy Brukardt 0 siblings, 0 replies; 68+ messages in thread From: Randy Brukardt @ 2008-12-02 3:51 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-21 22:31 ` anon 2008-11-22 0:18 ` Stefan Bellon @ 2008-11-22 13:10 ` Gautier 2008-11-24 8:24 ` christoph.grein 2 siblings, 0 replies; 68+ messages in thread From: Gautier @ 2008-11-22 13:10 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-21 22:31 ` anon 2008-11-22 0:18 ` Stefan Bellon 2008-11-22 13:10 ` Extending discriminant types Gautier @ 2008-11-24 8:24 ` christoph.grein 2 siblings, 0 replies; 68+ messages in thread From: christoph.grein @ 2008-11-24 8:24 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-20 22:59 ` anon 2008-11-21 0:29 ` Adam Beneschan @ 2008-11-21 6:11 ` christoph.grein 2008-11-21 21:12 ` Jeffrey R. Carter 2008-11-21 11:44 ` Martin 2 siblings, 1 reply; 68+ messages in thread From: christoph.grein @ 2008-11-21 6:11 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-21 6:11 ` christoph.grein @ 2008-11-21 21:12 ` Jeffrey R. Carter 2008-11-22 16:41 ` sjw 0 siblings, 1 reply; 68+ messages in thread From: Jeffrey R. Carter @ 2008-11-21 21:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-21 21:12 ` Jeffrey R. Carter @ 2008-11-22 16:41 ` sjw 0 siblings, 0 replies; 68+ messages in thread From: sjw @ 2008-11-22 16:41 UTC (permalink / raw) 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 ...) ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-20 22:59 ` anon 2008-11-21 0:29 ` Adam Beneschan 2008-11-21 6:11 ` christoph.grein @ 2008-11-21 11:44 ` Martin 2 siblings, 0 replies; 68+ messages in thread From: Martin @ 2008-11-21 11:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Extending discriminant types 2008-11-20 7:21 ` anon 2008-11-20 8:30 ` christoph.grein @ 2008-11-20 9:55 ` Martin 1 sibling, 0 replies; 68+ messages in thread From: Martin @ 2008-11-20 9:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 68+ messages in thread
end of thread, other threads:[~2008-12-02 3:51 UTC | newest] Thread overview: 68+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-11-15 9:16 Extending discriminant types Stefan Bellon 2008-11-15 18:50 ` Jeffrey R. Carter 2008-11-17 16:30 ` Adam Beneschan 2008-11-18 11:02 ` christoph.grein 2008-11-18 23:24 ` Adam Beneschan 2008-11-19 9:49 ` anon 2008-11-19 10:15 ` christoph.grein 2008-11-19 19:19 ` Georg Bauhaus 2008-11-19 11:38 ` Martin 2008-11-20 7:21 ` anon 2008-11-20 8:30 ` christoph.grein 2008-11-20 8:36 ` Ludovic Brenta 2008-11-20 11:45 ` Georg Bauhaus 2008-11-20 11:46 ` Georg Bauhaus 2008-11-20 23:01 ` anon 2008-11-21 11:54 ` Ludovic Brenta 2008-11-20 14:03 ` Dmitry A. Kazakov 2008-11-20 15:03 ` Robert A Duff 2008-11-20 15:57 ` Stefan Bellon 2008-11-21 0:32 ` Adam Beneschan 2008-11-20 16:11 ` Adam Beneschan 2008-11-20 22:59 ` anon 2008-11-21 0:29 ` Adam Beneschan 2008-11-21 7:25 ` anon 2008-11-21 9:19 ` Jean-Pierre Rosen 2008-11-21 10:11 ` christoph.grein 2008-11-21 12:00 ` Ludovic Brenta 2008-11-21 22:31 ` anon 2008-11-22 0:18 ` Stefan Bellon 2008-11-23 4:06 ` anon 2008-11-23 5:39 ` Georg Bauhaus 2008-11-23 8:00 ` anon 2008-11-24 10:08 ` Georg Bauhaus 2008-11-24 22:16 ` anon 2008-11-25 10:37 ` Martin 2008-11-25 11:24 ` Georg Bauhaus 2008-11-25 20:49 ` Jeffrey R. Carter 2008-11-25 21:01 ` Adam Beneschan 2008-11-25 22:09 ` Georg Bauhaus 2008-11-25 22:33 ` Jeffrey R. Carter 2008-11-26 0:58 ` Adam Beneschan 2008-11-26 1:45 ` Jeffrey R. Carter 2008-11-26 9:31 ` Martin 2008-11-26 9:38 ` Stefan Bellon 2008-11-26 9:48 ` Martin 2008-11-26 10:16 ` Stefan Bellon 2008-11-26 11:05 ` Ludovic Brenta 2008-11-26 11:33 ` Stefan Bellon 2008-11-26 15:49 ` Adam Beneschan 2008-11-26 16:15 ` Ludovic Brenta 2008-11-26 11:10 ` Niklas Holsti 2008-11-23 8:48 ` Compiler quality (was: Extending discriminant types) Ludovic Brenta 2008-11-24 23:33 ` anon 2008-11-25 6:54 ` christoph.grein 2008-11-25 10:01 ` Ludovic Brenta 2008-11-26 23:34 ` anon 2008-11-27 10:24 ` Compiler quality Georg Bauhaus 2008-11-27 14:46 ` Ludovic Brenta 2008-11-28 9:13 ` Martin 2008-11-28 10:28 ` Georg Bauhaus 2008-12-02 3:51 ` Randy Brukardt 2008-11-22 13:10 ` Extending discriminant types Gautier 2008-11-24 8:24 ` christoph.grein 2008-11-21 6:11 ` christoph.grein 2008-11-21 21:12 ` Jeffrey R. Carter 2008-11-22 16:41 ` sjw 2008-11-21 11:44 ` Martin 2008-11-20 9:55 ` Martin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox