A question to the EP experts? Is the following program valid EP, and if so, what should its output be?
program Foo (Output);
type i23 = 2 .. 3 value 2; a = record b: Integer value 1; case c: i23 of 2: (d: Integer value 4); 3: (e: Integer value 5) end value [b: 6; case c: 3 of [e: 7]];
var v: ^a;
begin New (v, 2); WriteLn (v^.b, ' ', v^.c, ' ', v^.d) end.
: 6.7.5.3 Dynamic allocation procedures : : The domainÂtype of the newÂpointerÂtype denoting the type possessed by p : shall contain a typeÂidentifier, which shall denote the recordÂtype, the : bindability, and except as otherwise noted below, the initial state of the : created variable. : : The caseÂconstant c 1 shall correspond to the variantÂpart of the : fieldÂlist of the recordÂtype. For 1 < i <= n, c i shall correspond to the : variantÂpart of the fieldÂlist of the variantÂdenoter denoting the variant : specified by c i Â1. For 1 <= i <= n, the variantÂpart corresponding to c i : shall closestÂcontain a tagÂtype. For 1 <= i <= n, the initial state of the : selector of the variant corresponding (see above) with the caseÂconstant c : i shall be the state bearing the value associated (see 6.4.3.4) with the : variant corresponding (see 6.4.3.4) to the value denoted by c i . : : It shall be an error if a variant of a variantÂpart within the new variable : is active and a different variant of the variantÂpart is one of the : specified variants. : : NOTE --- 1 Since the initial state of each selector is determined by the : corresponding caseÂconstant, any corresponding tagÂfield is also attributed : the value of the caseÂconstant (see 6.4.3.4).
According to the first paragraph v^.b must be 6 IIUIC (i.e., the initial state of the record, not of the field, prevails).
According to paragraphs 2 and 4, v^.c must be 2 which should be quite clear.
But what about v^.d? AFAICS, paragraphs 2 and 4 don't state it, so according to the first paragraph, it would have the initial state it has in the type a. But in a, the second variant is active, so field d is undefined.
Does this mean that indeed v^.d is undefined after `New' (despite specifying initial values wherever possible, i.e. *omitting* the initial state of a would result in v^.d being defined)? Or did I overlook some reason it is defined (in this case, presumably, as 4)?
Or is this `New' statement invalid? If anything, paragraph 3 might be a reason, but AFAICS it's meant to forbid invalid combinations of selectors in nested variant records, and doesn't apply here.
The more general question is whether the initial states of the components of a structured type can have any influence when the structured type itself has a `value' specification. (Since I don't see another way how they could.)
Frank
Frank Heckenbach wrote:
A question to the EP experts? Is the following program valid EP, and if so, what should its output be?
program Foo (Output);
type i23 = 2 .. 3 value 2; a = record b: Integer value 1; case c: i23 of 2: (d: Integer value 4); 3: (e: Integer value 5) end value [b: 6; case c: 3 of [e: 7]];
var v: ^a;
begin New (v, 2); WriteLn (v^.b, ' ', v^.c, ' ', v^.d) end.
...
: 6.7.5.3 Dynamic allocation procedures : : It shall be an error if a variant of a variantpart within the new variable : is active and a different variant of the variantpart is one of the : specified variants. :
IMHO the above means that the program is incorrect. Since the type specifies the initial state, variant corresponding to 3 is active nad you are not allowed to specify different variant to `new'.
Or is this `New' statement invalid? If anything, paragraph 3 might be a reason, but AFAICS it's meant to forbid invalid combinations of selectors in nested variant records, and doesn't apply here.
From 6.4.3.4
: The value of the selector of the variant type shall cause the associated : variant of the variant-part to be designated active.
So once we apply the inital state corresponding variant is designated active and by the paragraph 3 if we specify different variant, we have an error.
The more general question is whether the initial states of the components of a structured type can have any influence when the structured type itself has a `value' specification. (Since I don't see another way how they could.)
AFAICS no -- it seem that `value' specification is required to be complete.
Waldek Hebisch wrote:
Frank Heckenbach wrote:
A question to the EP experts? Is the following program valid EP, and if so, what should its output be?
program Foo (Output);
type i23 = 2 .. 3 value 2; a = record b: Integer value 1; case c: i23 of 2: (d: Integer value 4); 3: (e: Integer value 5) end value [b: 6; case c: 3 of [e: 7]];
var v: ^a;
begin New (v, 2); WriteLn (v^.b, ' ', v^.c, ' ', v^.d) end.
...
: 6.7.5.3 Dynamic allocation procedures : : It shall be an error if a variant of a variantÂpart within the new variable : is active and a different variant of the variantÂpart is one of the : specified variants.
IMHO the above means that the program is incorrect. Since the type specifies the initial state, variant corresponding to 3 is active nad you are not allowed to specify different variant to `new'.
Or is this `New' statement invalid? If anything, paragraph 3 might be a reason, but AFAICS it's meant to forbid invalid combinations of selectors in nested variant records, and doesn't apply here.
From 6.4.3.4
: The value of the selector of the variant type shall cause the associated : variant of the variant-part to be designated active.
So once we apply the inital state corresponding variant is designated active and by the paragraph 3 if we specify different variant, we have an error.
But 6.7.5.3 says:
: The domainÂtype of the newÂpointerÂtype denoting the type possessed by p : shall contain a typeÂidentifier, which shall denote the recordÂtype, the : bindability, and except as otherwise noted below, the initial state of the : created variable. : : [...] For 1 <= i <= n, the initial state of the : selector of the variant corresponding (see above) with the caseÂconstant c : i shall be the state bearing the value associated (see 6.4.3.4) with the : variant corresponding (see 6.4.3.4) to the value denoted by c i .
AFAIUI, the initial state of the selector is overriden by the case-constant (here, 2).
The more general question is whether the initial states of the components of a structured type can have any influence when the structured type itself has a `value' specification. (Since I don't see another way how they could.)
AFAICS no -- it seem that `value' specification is required to be complete.
For normal records and arrays, clearly so. For variant records, it can only specify one variant while other variants may have initializers themselves. But anyway it seems that they don't matter, both in your interpretation (program incorrect) and mine (field uninitialized).
BTW, another example:
program Foo (Output);
type i23 = 2 .. 3 value 2; a = record b: Integer value 1; case c: i23 of 2: (d: Integer value 4); 3: (e: Integer value 5) end value [b: 6; case c: 3 of [e: 7]];
var v: ^a;
begin New (v, 3); WriteLn (v^.b, ' ', v^.c, ' ', v^.d) end.
(The same as the previous one, except for the `3' in `New'.)
Here field d has value 7 in a, so also after the `New' (and not 5), right?
Frank
Frank Heckenbach wrote:
Waldek Hebisch wrote:
Frank Heckenbach wrote:
A question to the EP experts? Is the following program valid EP, and if so, what should its output be?
program Foo (Output);
type i23 = 2 .. 3 value 2; a = record b: Integer value 1; case c: i23 of 2: (d: Integer value 4); 3: (e: Integer value 5) end value [b: 6; case c: 3 of [e: 7]];
var v: ^a;
begin New (v, 2); WriteLn (v^.b, ' ', v^.c, ' ', v^.d) end.
...
: 6.7.5.3 Dynamic allocation procedures : : It shall be an error if a variant of a variantpart within the new variable : is active and a different variant of the variantpart is one of the : specified variants.
Let me call this rule 6.7.5.3-act
IMHO the above means that the program is incorrect. Since the type specifies the initial state, variant corresponding to 3 is active nad you are not allowed to specify different variant to `new'.
Or is this `New' statement invalid? If anything, paragraph 3 might be a reason, but AFAICS it's meant to forbid invalid combinations of selectors in nested variant records, and doesn't apply here.
From 6.4.3.4
: The value of the selector of the variant type shall cause the associated : variant of the variant-part to be designated active.
So once we apply the inital state corresponding variant is designated active and by the paragraph 3 if we specify different variant, we have an error.
But 6.7.5.3 says:
: The domaintype of the newpointertype denoting the type possessed by p : shall contain a typeidentifier, which shall denote the recordtype, the : bindability, and except as otherwise noted below, the initial state of the : created variable.
^^^^^^^^^ I think that main problem is the intended scope of the "otherwise"
: : [...] For 1 <= i <= n, the initial state of the : selector of the variant corresponding (see above) with the caseconstant c : i shall be the state bearing the value associated (see 6.4.3.4) with the : variant corresponding (see 6.4.3.4) to the value denoted by c i .
AFAIUI, the initial state of the selector is overriden by the case-constant (here, 2).
Well, if initial state is undefined, then clearly yes. But AFAICS 6.7.5.3-act is useless if you assume that overriding selector overrides active variant too. In fact, since we are creating new variable active variant must be due to initial state.
Well, I would say that standard is not 100% clear here. But when one interpretation makes a rule useless and gives bizzare behaviour and another uses all rules and looks reasonable I pick the second one...
BTW, another example:
program Foo (Output);
type i23 = 2 .. 3 value 2; a = record b: Integer value 1; case c: i23 of 2: (d: Integer value 4); 3: (e: Integer value 5) end value [b: 6; case c: 3 of [e: 7]];
var v: ^a;
begin New (v, 3); WriteLn (v^.b, ' ', v^.c, ' ', v^.d) end.
(The same as the previous one, except for the `3' in `New'.)
Here field d has value 7 in a, so also after the `New' (and not 5), right?
You mean field e? AFAICS d is undefined and e is 7.
-
Frank Heckenbach -
Waldek Hebisch