Variant records (EP)

[Waldek Hebisch]

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 variant­part within the new variable
> > > : is active and a different variant of the variant­part 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 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.
                               ^^^^^^^^^
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 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).
> 

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.

-- 
                              Waldek Hebisch
hebisch at math.uni.wroc.pl