Waldek Hebisch wrote:
> At the bottom of page 41 (in 6.47) EP standard contains the following
> note:
> 'Extra' formal discriminants that do not occur in the type-denoter
> of the schema-definition can be used to create several distinct, but
> structurally-identical, types.
>
> This seem to have strange consequences for ordinal types. Take:
>
> type es(i: integer) = (c1, c2);
> es1 = es(1);
>
> Is the above legal?
Yes.
If yes, then what about c1 and c2? It seems that
> the schema definition should declare also c1 and c2, but than what is
> the type of c1 and c2? For me it looks more reasonable to define
> c1 and c2 as a side effect of defining es1, but 6.4.2.3 says that
> the occurence in enumerated-type (hence in the schema definition)
> should be the defining point for c1 and c2. OTOH 6.4.8 says nothing
> about enumeral types.
Why do you care about the type of C1 and C2?
Is it any different than
type
es(i:integer) = record
f1 : array [1..i] of char;
f2 : (c1,c2);
end;
You can't have more than one definition of C1 and C2 in any region, can
you? It should all just work out.
>
> Next, look at:
>
> type os(i: integer) = 0..100;
> os1 = os(1);
>
> From my reading of the standard os1 is a proper ordinal type, so
> it can be used for variant selectors, array indices,
> set elements and discriminants. It seems that with extra twist
> it can be used as subrange bounds. Morover, once we can sneak
> such types into subrange bounds we can reapeat the process recursively,
> so we can store arbitrarly complex data in a single schema discriminant.
> That adds a lot of complexity to the schema implementation. Is it
> really what the standard says?
The extra complexity comes from the fact that subrange expressions can
be full-blown run-time expressions. You can do
procedure a(i,j:integer);
var s : i+10..j*17;
begin
end;
Any ordinal subrange can now have run-time bounds. You don't need
schema types to do that (although the implementation may appear similar
to schema types).
It gets real confusing to do things like:
procedure b(i,j:integer);
type
sub1(a,b:integer) = a..b;
dsub1 = sub1(i,j);
sub2(c,d:dsub) = ...
dsub2 = sub2(50,100);
The checks for the validity of C and D against 50 and 100 indirectly
rely on dsub1 just like for
procedure c(i,j:integer);
type
dsub1 = i..j;
sub2(c,d:dsub) = ...
dsub2 = sub2(50,100);
>
> BTW, I got the impression that if we take a classic Pascal program
> and replace every type declaration:
>
> type t = ...
>
> by
> type t_s(i : integer) = ...
> t = t_s(1);
>
> then we should get correct EP program. Was that the intention of the
> standard?
>
I believe so.
--
John Reagan
HP Pascal/{A|I}MACRO for OpenVMS Project Leader
Hewlett-Packard Company
|
