* Assignment access type with discriminants @ 2023-03-22 9:19 Dmitry A. Kazakov 2023-03-22 9:31 ` Björn Lundin ` (2 more replies) 0 siblings, 3 replies; 11+ messages in thread From: Dmitry A. Kazakov @ 2023-03-22 9:19 UTC (permalink / raw) I stumbled on a curious fact. The value of an object with a discriminant can be changed to a value with a different discriminant if the type's discriminants are defaulted. Right? Wrong! Not through an access type! procedure Test is type F is (F1, F2, F3); type Foo (K : F := F1) is record case K is when F1 => X1 : Integer; when F2 => X2 : Float; when F3 => X3 : String (1..2); end case; end record; type Foo_Ptr is access all Foo; X : aliased Foo; P : Foo_Ptr := X'Access; begin X := (F2, 1.0); -- OK P.all := (F1, 3); -- Error! end Test; Is this a compiler bug or intentional language design? Any language lawyers? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Assignment access type with discriminants 2023-03-22 9:19 Assignment access type with discriminants Dmitry A. Kazakov @ 2023-03-22 9:31 ` Björn Lundin 2023-03-22 14:10 ` G.B. 2023-03-23 17:04 ` J-P. Rosen 2 siblings, 0 replies; 11+ messages in thread From: Björn Lundin @ 2023-03-22 9:31 UTC (permalink / raw) On 2023-03-22 10:19, Dmitry A. Kazakov wrote: > I stumbled on a curious fact. .... > Is this a compiler bug or intentional language design? Any language > lawyers? > I get Execution of ./test terminated by unhandled exception raised CONSTRAINT_ERROR : test.adb:18 discriminant check failed Call stack traceback locations: 0x402c33 0x402b27 0x7f335b5cfd8e 0x7f335b5cfe3e 0x402b63 0xfffffffffffffffe bnl@hp-t510:/usr2$ gnatls -v GNATLS Pro 22.2 (20220605-103) Linux 64bit - ubuntu 22.04 So it is (also) present on that platform at least -- /Björn ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Assignment access type with discriminants 2023-03-22 9:19 Assignment access type with discriminants Dmitry A. Kazakov 2023-03-22 9:31 ` Björn Lundin @ 2023-03-22 14:10 ` G.B. 2023-03-23 11:51 ` Dmitry A. Kazakov 2023-03-23 17:04 ` J-P. Rosen 2 siblings, 1 reply; 11+ messages in thread From: G.B. @ 2023-03-22 14:10 UTC (permalink / raw) On 22.03.23 10:19, Dmitry A. Kazakov wrote: > I stumbled on a curious fact. > > The value of an object with a discriminant can be changed to a value with a different discriminant if the type's discriminants are defaulted. > > Right? > > Wrong! Not through an access type! > > procedure Test is > type F is (F1, F2, F3); > type Foo (K : F := F1) is record > case K is > when F1 => > X1 : Integer; > when F2 => > X2 : Float; > when F3 => > X3 : String (1..2); > end case; > end record; > type Foo_Ptr is access all Foo; > X : aliased Foo; > P : Foo_Ptr := X'Access; > begin > X := (F2, 1.0); -- OK > P.all := (F1, 3); -- Error! > end Test; Some experiments point at the general access type. type Foo_Ptr is access Foo; -- sans `all` X : Foo; P : Foo_Ptr := new Foo; type Foo1 is new Foo_Ptr (K => F1); begin X := (F2, 1.0); -- OK P.all := (F1, 3); -- _no_ Error! Foo1 (P).all := (F1, 3); end Test; (Doesn't rejection for general access types seem reasonable if assignment would otherwise require adjusting the storage layout of a variable, including all access paths to components? Just guessing.) ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Assignment access type with discriminants 2023-03-22 14:10 ` G.B. @ 2023-03-23 11:51 ` Dmitry A. Kazakov 2023-03-23 16:53 ` AdaMagica 0 siblings, 1 reply; 11+ messages in thread From: Dmitry A. Kazakov @ 2023-03-23 11:51 UTC (permalink / raw) On 2023-03-22 15:10, G.B. wrote: > Some experiments point at the general access type. > > type Foo_Ptr is access Foo; -- sans `all` > X : Foo; > P : Foo_Ptr := new Foo; > type Foo1 is new Foo_Ptr (K => F1); > begin > X := (F2, 1.0); -- OK > P.all := (F1, 3); -- _no_ Error! > Foo1 (P).all := (F1, 3); > end Test; You get no error because you do not change the discriminant. Change your code to: P.all := (F2, 1.0); -- Error! > (Doesn't rejection for general access types seem reasonable > if assignment would otherwise require adjusting the storage > layout of a variable, including all access paths to components? > Just guessing.) I guess that an implementation must allocate memory for any value unless you constraint the discriminants in a subtype. But I am not a language lawyer to judge. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Assignment access type with discriminants 2023-03-23 11:51 ` Dmitry A. Kazakov @ 2023-03-23 16:53 ` AdaMagica 2023-03-23 18:09 ` Niklas Holsti 0 siblings, 1 reply; 11+ messages in thread From: AdaMagica @ 2023-03-23 16:53 UTC (permalink / raw) I do hope, this answers the question: 3.10(14/3) … The first subtype of a type defined by … an access_to_object_definition is unconstrained if the designated subtype is an ... discriminated subtype; otherwise, it is constrained. 4.8(6/3) If the designated type is composite, then … the created object is constrained by its initial value (even if the designated subtype is unconstrained with defaults). ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Assignment access type with discriminants 2023-03-23 16:53 ` AdaMagica @ 2023-03-23 18:09 ` Niklas Holsti 0 siblings, 0 replies; 11+ messages in thread From: Niklas Holsti @ 2023-03-23 18:09 UTC (permalink / raw) On 2023-03-23 18:53, AdaMagica wrote: > I do hope, this answers the question: > > 3.10(14/3) … The first subtype of a type defined by … an > access_to_object_definition is unconstrained if the designated > subtype is an ... discriminated subtype; otherwise, it is > constrained. What do you infer from this, relating to Dmitry's original example code and the error? The "first subtype .. defined" here is the access subtype, and I don't see how that affects an assignment /via/ this access subtype to the accessed object. (It is not clear to me how an access subtype that is constrained differs from one that is unconstrained. Can someone clarify?) > 4.8(6/3) If the designated type is composite, then … the created > object is constrained by its initial value (even if the designated > subtype is unconstrained with defaults). That rule applies to objects created by allocators, but the original example code has no allocators (some later variants do). The object in question is created by a declaration (which includes the "aliased" keyword), not by an allocator. Also, AARM 3.10 contains the following notes on "Wording Changes from Ada 1995": 26.d/2 {AI95-00363-01} Most unconstrained aliased objects with defaulted discriminants are no longer constrained by their initial values. [...] 26.k/2 {AI95-00363-01} The rules about aliased objects being constrained by their initial values now apply only to allocated objects, and thus have been moved to 4.8, “Allocators”. This seems to mean that aliased objects created by declarations are /not/ constrained by the initial value, so it should be possible to change the discriminant. This seems to be a change from Ada 95 to Ada 2005. I don't see why that change could not be done via an access to the object. I added some output to Dmitry's original code, with this result: X'Constrained = FALSE P'Constrained = TRUE P.all'Constrained = TRUE The first two values of 'Constrained (for X and P) are as expected by the RM rules, and the third value (for P.all) is consistent with the error, and seems valid for Ada 95, but the wording change quoted above suggests that it is wrong for Ada 2005 and later. This leads me to suspect that GNAT has not been fully updated for this RM change, so it would be a GNAT bug. Still, the addition of subtype Foo2_Ptr is Foo_Ptr (K => F2); to Dmitry's original example provokes this error message: fuf.adb:16:24: access subtype of general access type not allowed fuf.adb:16:24: discriminants have defaults which suggests that at least this part of AI95-00363 has been implemented, as noted in AARM 3.10: 14.b/2 Reason: {AI95-00363-01} [...] Constraints are not allowed on general access-to-unconstrained discriminated types if the type has defaults for its discriminants [...] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Assignment access type with discriminants 2023-03-22 9:19 Assignment access type with discriminants Dmitry A. Kazakov 2023-03-22 9:31 ` Björn Lundin 2023-03-22 14:10 ` G.B. @ 2023-03-23 17:04 ` J-P. Rosen 2023-03-23 18:55 ` Niklas Holsti 2 siblings, 1 reply; 11+ messages in thread From: J-P. Rosen @ 2023-03-23 17:04 UTC (permalink / raw) Le 22/03/2023 à 10:19, Dmitry A. Kazakov a écrit : > I stumbled on a curious fact. > > The value of an object with a discriminant can be changed to a value > with a different discriminant if the type's discriminants are defaulted. > > Right? > > Wrong! Not through an access type! > (...) > Is this a compiler bug or intentional language design? Any language > lawyers? > An access value is always constrained by its initial value; this is necessary because of constrained access subtypes. Here is a slightly modified version of your example: procedure Test is type F is (F1, F2, F3); type Foo (K : F := F1) is record case K is when F1 => X1 : Integer; when F2 => X2 : Float; when F3 => X3 : String (1..2); end case; end record; type Foo_Ptr is access all Foo; type Foo_Ptr2 is access Foo; X : aliased Foo; P : Foo_Ptr := X'Access; PF2: Foo_PTR2 (F2); begin X := (F2, 1.0); -- OK PF2 := new Foo (F2); P := PF2.all'Access; P.all := (F1, 3); -- Error! end Test; Without this rule, PF2.all would now designate a value whose discriminant is F1! -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX https://www.adalog.fr https://www.adacontrol.fr ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Assignment access type with discriminants 2023-03-23 17:04 ` J-P. Rosen @ 2023-03-23 18:55 ` Niklas Holsti 2023-03-23 19:53 ` Dmitry A. Kazakov 2023-03-24 9:41 ` J-P. Rosen 0 siblings, 2 replies; 11+ messages in thread From: Niklas Holsti @ 2023-03-23 18:55 UTC (permalink / raw) On 2023-03-23 19:04, J-P. Rosen wrote: > Le 22/03/2023 à 10:19, Dmitry A. Kazakov a écrit : >> I stumbled on a curious fact. >> >> The value of an object with a discriminant can be changed to a value >> with a different discriminant if the type's discriminants are defaulted. >> >> Right? >> >> Wrong! Not through an access type! >> > (...) >> Is this a compiler bug or intentional language design? Any language >> lawyers? >> > An access value is always constrained by its initial value; this is > necessary because of constrained access subtypes. But constrained access subtypes are not allowed for general access types like Foo_Ptr in the example. > Here is a slightly > modified version of your example: > > procedure Test is > type F is (F1, F2, F3); > > type Foo (K : F := F1) is record > case K is > when F1 => > X1 : Integer; > when F2 => > X2 : Float; > when F3 => > X3 : String (1..2); > end case; > end record; > type Foo_Ptr is access all Foo; > type Foo_Ptr2 is access Foo; > X : aliased Foo; > P : Foo_Ptr := X'Access; > PF2: Foo_PTR2 (F2); > begin > X := (F2, 1.0); -- OK > PF2 := new Foo (F2); > P := PF2.all'Access; > P.all := (F1, 3); -- Error! > end Test; > > Without this rule, PF2.all would now designate a value whose > discriminant is F1! This error is understandable and valid, because now P.all is PF2.all which is an allocated object and therefore constrained by its initial value with K = F2. But why should the same apply when P designates X, which is unconstrained? Is it just an optimization (in the RM) so that a general access value does not have to carry around a flag showing whether its designated object is constrained or unconstrained? Perhaps it would be better to make the assignment P := PF2.all'Access illegal, because it in effect converts a constrained access value (PF2) to an unconstrained access subtype (P), and so in some sense violates the prohibition of constrained subtypes of general access types. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Assignment access type with discriminants 2023-03-23 18:55 ` Niklas Holsti @ 2023-03-23 19:53 ` Dmitry A. Kazakov 2023-03-24 9:41 ` J-P. Rosen 1 sibling, 0 replies; 11+ messages in thread From: Dmitry A. Kazakov @ 2023-03-23 19:53 UTC (permalink / raw) On 2023-03-23 19:55, Niklas Holsti wrote: > Perhaps it would be better to make the assignment P := PF2.all'Access > illegal, because it in effect converts a constrained access value (PF2) > to an unconstrained access subtype (P), and so in some sense violates > the prohibition of constrained subtypes of general access types. Yes this is substitutability violation. Such cases never go without a punishment. In this case it is an implementation overhead. Consider: procedure Set (Destination : in out Foo; Source : Foo) is begin Destination := Source; end Set; The compiler cannot implement Set in a natural way, because Destination might be arbitrarily constrained by the caller. E.g. when the actual for Destination is P.all. So, the constraint must be passed together with the actual. A quite burden. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Assignment access type with discriminants 2023-03-23 18:55 ` Niklas Holsti 2023-03-23 19:53 ` Dmitry A. Kazakov @ 2023-03-24 9:41 ` J-P. Rosen 2023-03-25 8:51 ` Randy Brukardt 1 sibling, 1 reply; 11+ messages in thread From: J-P. Rosen @ 2023-03-24 9:41 UTC (permalink / raw) Le 23/03/2023 à 19:55, Niklas Holsti a écrit : > >> Here is a slightly modified version of your example: >> >> procedure Test is >> type F is (F1, F2, F3); >> >> type Foo (K : F := F1) is record >> case K is >> when F1 => >> X1 : Integer; >> when F2 => >> X2 : Float; >> when F3 => >> X3 : String (1..2); >> end case; >> end record; >> type Foo_Ptr is access all Foo; >> type Foo_Ptr2 is access Foo; >> X : aliased Foo; >> P : Foo_Ptr := X'Access; >> PF2: Foo_PTR2 (F2); >> begin >> X := (F2, 1.0); -- OK >> PF2 := new Foo (F2); >> P := PF2.all'Access; >> P.all := (F1, 3); -- Error! >> end Test; >> >> Without this rule, PF2.all would now designate a value whose >> discriminant is F1! > > > This error is understandable and valid, because now P.all is PF2.all > which is an allocated object and therefore constrained by its initial > value with K = F2. > > But why should the same apply when P designates X, which is > unconstrained? Is it just an optimization (in the RM) so that a > general access value does not have to carry around a flag showing > whether its designated object is constrained or unconstrained? I didn't dig in the RM in all details, but I think this comes from the fact that being constrained (always) is a property of the pointer (more precisely, its subtype), not of the pointed-at object. -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX https://www.adalog.fr https://www.adacontrol.fr ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Assignment access type with discriminants 2023-03-24 9:41 ` J-P. Rosen @ 2023-03-25 8:51 ` Randy Brukardt 0 siblings, 0 replies; 11+ messages in thread From: Randy Brukardt @ 2023-03-25 8:51 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2961 bytes --] The rule is question is 4.1(9/3): If the type of the name in a dereference is some access-to-object type T, then the dereference denotes a view of an object, the nominal subtype of the view being the designated subtype of T. If the designated subtype has unconstrained discriminants, the (actual) subtype of the view is constrained by the values of the discriminants of the designated object, except when there is a partial view of the type of the designated subtype that does not have discriminants, in which case the dereference is not constrained by its discriminant values. We have to do that so as otherwise the access value would have to carry a designation as to whether the object was allocated or not. ------- This rule was inherited from Ada 83. IMHO, this rule is stupid. It's even more stupid with the hole for types that have partial views without discriminants. The *proper* solution is to get rid of the rarely used and mostly useless access constraints, and then have no extra restrictions on access values. But that's considered too incompatible. Randy. "J-P. Rosen" <rosen@adalog.fr> wrote in message news:tvjr7l$1js79$1@dont-email.me... > Le 23/03/2023 à 19:55, Niklas Holsti a écrit : > > > >> Here is a slightly modified version of your example: > >> > >> procedure Test is > >> type F is (F1, F2, F3); > >> > >> type Foo (K : F := F1) is record > >> case K is > >> when F1 => > >> X1 : Integer; > >> when F2 => > >> X2 : Float; > >> when F3 => > >> X3 : String (1..2); > >> end case; > >> end record; > >> type Foo_Ptr is access all Foo; > >> type Foo_Ptr2 is access Foo; > >> X : aliased Foo; > >> P : Foo_Ptr := X'Access; > >> PF2: Foo_PTR2 (F2); > >> begin > >> X := (F2, 1.0); -- OK > >> PF2 := new Foo (F2); > >> P := PF2.all'Access; > >> P.all := (F1, 3); -- Error! > >> end Test; > >> > >> Without this rule, PF2.all would now designate a value whose > >> discriminant is F1! > > > > > > This error is understandable and valid, because now P.all is PF2.all > > which is an allocated object and therefore constrained by its initial > > value with K = F2. > > > > But why should the same apply when P designates X, which is > > unconstrained? Is it just an optimization (in the RM) so that a > > general access value does not have to carry around a flag showing > > whether its designated object is constrained or unconstrained? > > I didn't dig in the RM in all details, but I think this comes from the > fact that being constrained (always) is a property of the pointer (more > precisely, its subtype), not of the pointed-at object. > > -- > J-P. Rosen > Adalog > 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX > https://www.adalog.fr https://www.adacontrol.fr > ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2023-03-25 8:51 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-03-22 9:19 Assignment access type with discriminants Dmitry A. Kazakov 2023-03-22 9:31 ` Björn Lundin 2023-03-22 14:10 ` G.B. 2023-03-23 11:51 ` Dmitry A. Kazakov 2023-03-23 16:53 ` AdaMagica 2023-03-23 18:09 ` Niklas Holsti 2023-03-23 17:04 ` J-P. Rosen 2023-03-23 18:55 ` Niklas Holsti 2023-03-23 19:53 ` Dmitry A. Kazakov 2023-03-24 9:41 ` J-P. Rosen 2023-03-25 8:51 ` Randy Brukardt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox