[wg11] Is an empty extensible select a specialization of another type?

[Lothar Klein]

Please find below a discussion on the AP210 bugzilla system to the
question whether or not an empty extensible select is a specialisation
of another type in EXPRESS?

Do you think we have to do something on this?

-- 
// Lothar Klein, LKSoftWare GmbH
// Steinweg 1, 36093 Kuenzell, Germany
// +49 661 933933-0, Fax: -2
// url: http://www.lksoft.com


Opened: 2006-04-29 17:31 by Lothar Klein

While looking to bug #2038 I detected another severe Express issue which is
clearly wrong, even if the Express compiler don't catch it yet. Currently we have:

  ENTITY Shape_element; ...
      containing_shape : Item_shape; ...

  ENTITY Non_feature_shape_element
    SUBTYPE OF (Shape_element); ...
      SELF\Shape_element.containing_shape RENAMED scope :
ee_product_definition_with_annotation_elements; ...

  TYPE ee_product_definition_with_annotation_elements = EXTENSIBLE
GENERIC_ENTITY SELECT ;
  END_TYPE; -- ee_product_definition_with_annotation_elements

ee_product_definition_with_annotation_elements is not a specialization of
Item_shape and so this express is not valid. But fortunately all the elements in
the extensions are Item_shape.

Proposal is to simply remove the redeclaration of containing_shape in the
Non_feature_shape_element and remove the select with its extensions.


------- Additional Comment #1 From Tom Thurman 2006-04-30 15:10 -------

Actually this is not a problem in EXPRESS.  As long as the items are subtypes 
of Item_shape the EXPRESS is legal.


------- Additional Comment #2 From Lothar Klein 2006-04-30 17:59 -------

Sorry, but this is really a bug and I have to re-open it. We may not be able to
solve this for ed2.

The items are only added at a later time. Within schema
Non_feature_shape_element_arm the extenable select
ee_product_definition_with_annotation_elements can't be considered as a
specialization of Item_shape. At least I can't see which statement in part11,
e.g. "9.2.7 Specialization" would allow this. If you see then please provide here.


------- Additional Comment #3 From Tom Thurman 2006-05-01 12:32 -------

re-assign to Lothar to write SEDS against part 11 for clarification.
-----------------------
here is the definition of a SELECT type:
8.4.2 Select data type
A select data type defines a data type that enables a choice among several 
named data types.
The select data type is a generalization of these named data types in its 
domain. The defined
type for which the select data type is the underlying representation, may add 
constraints on
its domain by declaring local rules. A select data type may be extensible or 
not.
-------------
here is the applicable clause from 9.2.7:
a select of a, b, c is a specialization of a select of d, e, f if a, b, c are 
specializations of
d, e, f;
— a select of a, b, c is a specialization of a supertype if a, b, c are 
subtypes of the supertype;
------------------
The interpretation of this by the compiler writers is that the bullet from 
9.2.6 that specifies the behavior of select applies.
I have seen this behavior where the compiler will allow the use of EXTENSIBLE 
SELECT as long as the leaf elements are subtypes of the original type 
referenced by the attribute.
I would suggest you write a SEDS against part 11, clause 9.2.7 to get 
clarification or maybe a note to the wg11 exploder.
--------------------------
Another way of looking at this is the "expectation" that the modules are all 
compiled into a long form and this is something that will be resolved there.
------------------------------