CVS difference for ais/ai-00261.txt

Differences between 1.7 and version 1.8
Log of other versions for file ais/ai-00261.txt

--- ais/ai-00261.txt	2003/03/04 04:56:22	1.7
+++ ais/ai-00261.txt	2003/06/07 04:58:56	1.8
@@ -3129,5 +3129,184 @@
 
 ****************************************************************
 
+From: Nick Roberts
+Sent: Monday, April 14, 2003  9:25 AM
+
+Having read AI-261 on enumeration extension types, I'd like to make my own
+proposal, which is very similar to AI-261, but not quite the same. I think
+my proposal solves all the problems that need solving, and I think the idea
+is worthwhile and should be added at the next revision.
+
+
+1. Changes to the Syntax Rules.
+
+[RM95 3.4]
+
+   derived_type_definition ::=
+      [ABSTRACT] NEW parent_subtype_indication [extension_part]
+
+   extension_part ::= record_extension_part | enumeration_extension_part
+
+[RM95 3.5.1]
+
+   enumeration_type_definition ::= enumeration_literal_list
+
+   enumeration_literal_list ::=
+      (enumeration_literal_specification {,
+enumeration_literal_specification})
+
+   enumeration_extension_part ::= WITH enumeration_literal_list
+
+[RM95 12.5.1]
+
+   formal_derived_type_definition ::=
+      [ABSTRACT] NEW subtype_mark [WITH extension_indicator]
+
+   extension_indicator ::= PRIVATE | (<>)
+
+
+2. Enumeration Extension Type Declaration
+
+An enumeration extension type declaration takes the general form:
+
+   type E2 is new E1 with (V1, ...);
+
+where E1 is an existing enumeration subtype (which may itself be an
+extension). This declaration creates a new enumeration type (which may be
+denoted E2'Base) which is derived from E1, and which has copies of the
+values of E1 plus an extra value for each enumeration literal V1 ...
+explicitly declared. The copies of the values of E1 are the 'inherited
+values' and the extra values V1 ... are the 'extended values' of E2'Base.
+The enumeration literal of each of the inherited values is that of the
+corresponding value of E1. (The enumeration literal of each of the extended
+values is as given.) The enumeration literals of the new (derived) type
+E2'Base must all be unique.
+
+The declaration creates a new subtype of E2'Base, E2, which has the
+constraint E2'Base'Range. The constraint of E1 must be static. The
+declaration declares E2 and all the enumeration literals of E2'Base.
+
+The position numbers of E2'Base are: the first inherited value has position
+number 0; the last inherited value has position number M-1, where M is the
+number of inherited values; the first extended value has position number M;
+the last extended value has position number M+N-1, where N is the number of
+extended values.
+
+The first important thing to note is that inherited values are those of the
+/subtype/ E1, taking into account any constraint it may have. Thus, if we
+have:
+
+   type Title is (Dr, Mr, Mrs, Miss);
+   subtype Common_Title is Title range Mr..Mrs;
+   type Correct_Title is new Common_Title with (Ms);
+
+then Correct_Title'Base has the three values Mr, Mrs, and Ms. Their
+position numbers are 0 (Mr), 1 (Mrs), and 2 (Ms), which do not correspond
+to those of Title'Base.
+
+The second important thing to note is that an enumeration extension type is
+a kind of derived type, and so the rules of RM95 3.4 will have to be
+altered and extended appropriately. This fits in with record extensions.
+
+
+3. Representation of Enumeration Extension Types
+
+If an enumeration representation clause is specified for an extended
+enumeration type, it must either specify all the extended values (and no
+others) or it must specify all the inherited and all the extended values.
+
+Clearly, in the example given above, the new type Correct_Title'Base is
+likely to have a representation with a 'hole' in it (where Miss was for the
+ancestor type Title), if no enumeration representation clause is specified
+for it. This kind of situation might produce object code which is
+significantly less efficient than for normal enumeration types, and
+implementations might offer the option to produce a warning in this kind of
+situation.
+
+
+4. Operations of an Enumeration Extension Type
+
+Conversions are defined as normal for derived types, except that conversion
+towards an ancestor type includes a check that the operand value can be
+converted to a value which lies in the set of values of the ancestor.
+Constraint_Error is raised if the check fails. [RM95 4.6 will be affected.
+Para 35 needs to be changed to "The result is the value of the target type
+with the same enumeration literal as that of the operand value."]
+
+Primitive subprograms are not inherited. [RM95 3.4 will be affected.]
+
+All the stream-oriented attributes have default implementations, and are
+never inherited. [RM95 13.13.2] They may be explicitly overridden as usual.
+
+Other predefined operations work as normal.
+
+Let me emphasise the point: NO PRIMITIVE SUBPROGRAMS ARE INHERITED. In
+practice, this simply means that if a subprogram of an ancestor type needs
+to be called, this can (and must) be achieved by conversion. I feel this
+rule will kill off a lot of unnecessary difficulties. It may seem drastic,
+but in the end I believe it's the solution which represents the least of
+many evils.
+
+
+5. Extension of Boolean Types
+
+An extension of a boolean type is NOT a boolean type. However, conversion
+to a boolean type does result in a boolean type [I hope this statement
+makes sense].
+
+To illustrate, if we have:
+
+   type Tri_Logic is new Boolean with (Unknown);
+   We_Are_Happy: Tri_Logic;
+
+then:
+
+   if We_Are_Happy then ...
+
+is (statically) illegal, but:
+
+   if Boolean(We_Are_Happy) then ...
+
+is legal, and will check that the value of We_Are_Happy is either False or
+True (and raise Constraint_Error if the check fails).
+
+
+6. Generic Formal Enumeration Extension Types
+
+There is a new form of formal type declaration specifically for enumeration
+extensions, which takes the general form:
+
+   type E2 is new E1 with (<>);
+
+which denotes a formal enumeration subtype E2 whose base type has been
+derived /or/ extended (directly or indirectly) from E1.
+
+The non-staticness of E2 would be as per AI-263.
+
+E2 is not a boolean type (regardless of whether E1'Base is a boolean type
+or not), but it can be converted to a boolean type (if E1'Base is a boolean
+type).
+
+I implore the ARG to accept this new formal type: it will not be very
+difficult to add to the RM; it will not be very difficult to add to
+existing Ada implementations; it will avoid any nastiness with regard to
+boolean derivation in generics; the syntax "with (<>)" is sure to help
+(novice) Ada programmers remember that the formal type could be an
+enumeration extension; finally, it will immediately give the programmer all
+the predefined operations for discrete types, albeit in non-static form, as
+well as all the enumeration literals inherited from E1.
+
+
+7. Character and Wide_Character
+
+The predefined type Standard.Wide_Character will be an extension of the
+predefined type Standard.Character.
+
+If a predefined type Standard.Universal_Character (representing the entire
+ISO 10646 UCS) is introduced, then it will be an extension of
+Wide_Character.
+
+****************************************************************
+
 
 

Questions? Ask the ACAA Technical Agent