[wg11] Declarations inside algorithms

[Ed Barkmeyer]

Alan R Williams wrote:

> I've a few questions about what should happen if an entity, for example, is 
> declared inside a function/procedure/rule.

I think Alan has generated a sufficient number of pathological cases to 
demonstrate that declaring an Entity data type inside a FUNCTION is 
nonsense and should not be permitted.  Of course, declaring a 
record/struct data type inside a procedure is not meaningless, and 
should be permitted.  And since EXPRESS can't tell the difference, we 
permit it, and make it clear what happens when the modeler generates 
syntactically valid nonsense.

> (A)
> 
> SCHEMA s;
> 
> FUNCTION f : STRING;
>   ENTITY e_in_f;
>   END_ENTITY;
>   
>   LOCAL
>     v : e_in_f := e_in_f ();
>   END_LOCAL;
>   
>   RETURN (TYPEOF (v));
> END_FUNCTION;
> 
> END_SCHEMA;
> 
> What should a call of f return?  The description of TYPEOF only covers types 
> declared inside a schema.

That TYPEOF is defined to return only types declared in the immediate 
scope of a schema is correct.

TYPEOF(v) should return the empty SET OF STRING because the actual data 
type of v is not declared or interfaced into the schema in which f is 
defined.  So f always returns [].

That subclause 15.25 of Part 11 (TYPEOF) doesn't deal with the case in 
which the named data type is declared within a FUNCTION is a problem.

Step (a) should be revised to state explicitly that
"-- if the data type that V explicitly belongs to by declaration is 
declared within the scope of a procedure or function, an empty SET is 
returned."

> (B)
> 
> Similarly for
> 
> SCHEMA s;
> 
> ENTITY e_outside_f;
> END_ENTITY;
> 
> FUNCTION f : STRING;
>   ENTITY e_in_f
>       SUBTYPE OF (e_outside_f);
>   END_ENTITY;
>   
>   LOCAL
>     v : e_in_f := e_outside_f() || e_in_f ();
>   END_LOCAL;
>   
>   RETURN (TYPEOF (v));
> END_FUNCTION;
> 
> END_SCHEMA;
> 
> what should f return?

It should return ["S.E_OUTSIDE_F"].  But the proposed change to clause 
15.25 would return the empty set, and we should be content with that.

Because of the way the algorithm in 15.25 is stated (step (b) begins 
"for each item in the current set, ..."), significant revision to 15.25 
would be needed to return a supertype of a type that itself cannot go 
into the list.  And since we are talking about nonsense models, GIGO 
should apply.

> (C)
> 
> SCHEMA s;
> 
> ENTITY identification;
>   s : STRING;
> END_ENTITY;
> 
> ENTITY identified_object;
>   id_number : INTEGER;
> DERIVE
>   id : identification := derive_numeric_identification (id_number);
> END_ENTITY;
> 
> 
> FUNCTION derive_numeric_identification (n : INTEGER) : identification;
>   ENTITY numeric_identification
>       SUBTYPE OF (identification);
>     x : INTEGER;
>   DERIVE
>     SELF\identification.s : STRING := FORMAT (x, '010I');
>   END_ENTITY;
>   
>   RETURN (identification (?) || numeric_identification (n));
> END_FUNCTION;
> 
> END_SCHEMA;
> 
> Yes it's an awful model :-)
> 
> Anyway, what does it mean to return an instance of a subtype 
> (numeric_identification) whose declaration is local to a function?
> 
> Is it invalid?
> Does it somehow strip away the subtype-ness of the instance?

IMHO, F returns an entity instance, say #666, that is an identification 
instance and actually has two attributes -- id_number and x.  However, 
because the subtype numeric_identification is not declared or interfaced 
into the schema, the fact that #666 is an instance of that subtype, and 
the attribute x, are not accessible/expressible elsewhere in the schema. 
  The same would be true of an instance of a subtype declared in an 
interfaced schema if only the supertype is interfaced.  (And unlike this 
model, that last is reasonable happenstance when integrating AIM schemas 
from multiple modules or APs.)

This means that TYPEOF(derive_numeric_identification(5)) will return 
"S.IDENTIFICATION".  This may come as a surprise when compared with 
example (B) above, but it is correct.  By definition, the result of 
derive_numeric_identification() is an "identification" instance.  It may 
be an instance of a subtype, but that information would not be available 
  as indicated above.

So yes, the return does "somehow strip away the subtype-ness of the 
instance".  The instance is a valid value of the return-type of the 
function, and it is not a valid value of any other data type known to 
the schema.

N.B.  Alan, please construct a SEDS for this.  Then WG11 can decide on 
and document the "clarification".  The WG may well disagree with my 
recommended change to 15.25 above.

-Ed

-- 
Edward J. Barkmeyer                        Email: edbark at nist.gov
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8264                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8264                FAX: +1 301-975-4694

"The opinions expressed above do not reflect consensus of NIST,
  and have not been reviewed by any Government authority."