John Reagan <john.reagan@[EMAIL PROTECTED]
> wrote:
> 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?
>
I want to faithfully implement EP typechecking rules.
> Is it any different than
>
> type
> es(i:integer) = record
> f1 : array [1..i] of char;
> f2 : (c1,c2);
> end;
>
I wanted minimal example...
> You can't have more than one definition of C1 and C2 in any region, can
> you? It should all just work out.
>
But I can have multiple types produced from the same schema in the same
region. I can export renamed C1 and C2 from a module, and then import
different versions in a single region. I can pass C1 to a procedure
with schematic value parameter and inquire about it type. I can get
from C1 corresponding discriminat value. For example:
procedure p;
var va2 : es(2);
procedure tc(par : es);
var va1 : type of par;
begin
va1 := c1;
writeln(va1.i);
va2 := va1;
end;
begin
va2 := c2;
tc(c1)
end;
All would be clear if the constants c1 and c2 are defined in the process
of discriminating the schema. Then tc would print 2. However, if c1 and
c2 are defined by the schema definition (which is my literal reading
of the standard) then it is not clear what value tc should print (and
in particular if the above is legal).
Or put it differently:
var v2 : es(2);
v3 : es(3);
begin
v2 := c1;
v3 := c1;
end;
Is the above legal? If c1 and c2 are defind by the schema definition
then nothing stops as from producing many different types from the
schema. On the other hand for the first assignment to be valid v2 and c1
must be of the same type while for the second assignment to be valid v3
and c1 must be of the same type. Since v2 and v3 have different types
so one of the assignment must be illegal.
Again, if we decide that discriminating schema defines c1 and c2 then
already declaration of v3 is illegal (because of duplicate definition
of c1 and c2).
Now, if we decide that discriminating schema defines enumeration
constants,
then it in natural tu appropriate exception to 6.2.2.7 like:
"or both identifers are denote constants defined by discriminating the
same
schema with the same tuple"
> >
> > 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
>
OK. GPC allows run-time expressions as subrange bounds and the
corresponding
type in an integer type. However schema are internally represented as
records, storing together discriminants nad the proper schmatic value.
Internally many things have to be an integer type, so allowing ordinal
schema as array bounds requires a lot of internal conversions between
the whole schema (record) and the integer value. I wanted to know that
this work is required to fully support EP.
--
Waldek Hebisch
hebisch@[EMAIL PROTECTED]
|
