[wg11] lost SEDS for part 11?

[Ed Barkmeyer]

Allison Barnard Feeney wrote:
> It appears that this SEDS has not been closed, yet it is not in the list 
> of open SEDS reports against Part 11.

It most definitely never made it onto the lists in recent times.
I had not seen it before.

> Problem Description: 
> Rule a in aggregate, generic and generic entity is too restrictive.
> It should allow the use of these three generalized data types as a
> formal parameter type of a function or procedure, or as the result
> type of a function, or as the type of a local variable within a
>  function, procedure or rule, or as the representation of an explicit
> or derived attribute in an abstract entity data type declaration.
> ...
> Proposed Solution (Optional): allow use of generic, generic entity
> and aggregate as the type of a local variable within a function,
> procedure or rule, or as the representation of an explicit or
> derived attribute in an abstract entity data type declaration.

This is most definitely NOT an editorial correction/clarification.
It requires support for two *features* that were formerly not permitted:
(1) use of Generalized types for variables in a RULE
(2) use of GENERIC as the data type of an "abstract attribute" ("an 
explicit or derived attribute of an abstract entity")

Discussion of (1):  generalized types in RULEs

Rule (b) in 9.5.3.x requires that when a variable is given a generalized 
data type, the generalized type must have a type label that refers to a 
type label on the (generalized) type of a formal parameter.
The effect is to require the data type of the variable (in an executable 
instantation of the function) to be the same as the data type of the 
actual parameter that corresponds to the formal parameter whose data 
type has that label.  (One can treat the function as a "macro" and do 
type substitution while doing parameter substitution, and then evaluate 
the "instantiated function" with the substituends.  This is one of the 
two "generic function" models for Ada.)

In a RULE, there are no formal parameters, and the actual parameters are 
the extents of entity data types, interpreted as having type
SET OF <entity-ref>.  So the above actual type instantiation model 
cannot apply.  No "formal parameter" can specify the intended actual type.

The authors of the SEDS failed to give any motivation for this change. 
But I am guessing that the intent of the SEDS is to allow a variable in 
RULE to be declared to be of the same type as the type of an attribute 
of one of the "parameter entities".  When the parameter entity is an 
abstract supertype ("abstract entity"), it is permitted to have 
attributes with generalized types.  And if the generalized type of an 
"abstract attribute" is labeled, the variable can be declared to be of 
the same type as the attribute.

The problem with this model is that it doesn't support the "macro 
instantiation model" for generic functions (described above).  The 
actual data type of the "abstract attribute" varies from instance to 
instance of the abstract entity type (actually from instantiable subtype 
to instantiable subtype, but the visible effect on the rule is instance 
to instance).  Consequently, the "actual data type" of the variable 
cannot be fixed during an evaluation of the rule body!

Moreover, the intended actual type for the variable isn't clear if two 
different instances are involved.  Consider:

ENTITY bunny ABSTRACT;
   food : GENERIC:f;
END_ENTITY;

RULE whatsupdoc FOR (bunny);
  LOCAL
    i: INTEGER;
    favorite: GENERIC:f;
  END_LOCAL;

  favorite := bunny[1].food;
  FOR i := 2 TO SizeOf(bunny);
   IF (favorite = bunny[i].food) ...
   ...
  LOOP
WHERE
  gr1: NOT favorite = "PICKLES";
END_RULE;

Now it turns out that the primary problem with the above is GENERIC.

It is possible to implement manipulations of instances of GENERIC_ENTITY 
and AGGREGATE without knowing until "runtime" what the actual data type 
is.  As long as entity instances are considered to expose their type 
identity, you can manipulate GENERIC_ENTITY with a "late-bound access" 
mechanism.  And you can manipulate instances of AGGREGATE data types 
with a common subscripting algorithm by turning them all into sequences. 
  And there are other features of EXPRESS that already force both of 
these capabilities to exist.  (This is the other Ada generic function 
model: allowing generalization only over data types with common 
manipulations.)

So I think that if we omit GENERIC from the variable types that are 
allowed in RULEs, the proposed change is workable.  But it does require 
the addition of a Rule like:

(b') If an AGGREGATE/GENERIC_ENTITY data type is used as the type of a 
local variable within a global rule, a type label reference is required 
for this usage.  The type label reference shall refer to a type label 
declared by an attribute of one of the entity data types to which the 
rule applies (see 9.6).


Discussion of (2):  GENERIC as data type of abstract attributes

GENERIC is currently explicitly not permitted as the data type of an 
attribute of an abstract entity.  From 9.2.1.1 Rules:
"c) An explicit attribute shall neither directly nor indirectly be 
declared to be of the data type GENERIC."

So the proposed change would have to include deleting 9.2.1.1 (c).

There is a reason for this limitation, which relates to exchange data 
sets and SDAI implementations.

In Part 21, an attribute of a supertype is required to be represented 
*in the representation of the supertype*.  Redeclaration in a subtype 
does not affect the representation, only the allowable values.  In Part 
21, all aggregate values have the same representation structure, and all 
entity instances have the same representation as values of an attribute. 
  But clearly this is not true of arbitrary values of GENERIC.  Now for 
the "internal mapping", the instantiable subtype is identified and the 
actual type is known.  But for the "external mapping", the instantiable 
subtypes are in other parts of the representation structure, and the 
parser has no idea what to expect in the value of the supertype 
attribute if it hasn't encountered them yet.

Similarly, in SDAI, the value of an attribute of the supertype is 
accessible through the supertype and has the data type given in the 
supertype.  And similarly, all entity instances are returned as 
"instance names" (pointers), and all aggregates have a common 
representation structure.  But it is not clear what data type should be 
returned if the supertype declares the attribute to be GENERIC.  And it 
means that a new "discriminated union" data type has to be constructed.

The proposed change, therefore, requires corresponding changes to Part 
21 and the several SDAI mappings, to ensure that the "representation in 
the supertype" of a GENERIC attribute is a "discriminated union", i.e a 
type indication always accompanies the value.

But the concept "type indication" is not simple, either, as an 
inspection of the CORBA exchange representation of type "any" will 
reveal.  If the data type has a name, it is easy to return a (name, 
value) pair, in which the representation (and interpretation) of the 
'value' can be determined from the 'name' of the type.  But what if the 
type is anonymous?  We could agree to use the keywords for Integer, 
String, etc., but what about ARRAY[1:3] OF LIST[0:?] OF STRING?  So 
considerable work has to be done, both in the 20-series standards and in 
their implementations, to define the representation of "type indication".

This anticipated impact on the 20-series is the reason why Part 11:2004 
does not permit GENERIC as the type of an "abstract attribute".  In 
WG11, we should debate this aspect of the SEDS only when the 
corresponding proposed changes to Part 21, 23, 24 and 27 are also available.

It is possible that this aspect of the SEDS was an unintended exercise 
in excessive generality.  But, whether intended or not, it is excessive, 
and (IMHO) should not be acted on.

-Ed

"Timeo Danaos, et dona ferentes."

-- 
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."