CVS difference for ais/ai-00261.txt

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

--- ais/ai-00261.txt	2001/02/16 02:48:49	1.3
+++ ais/ai-00261.txt	2001/02/19 22:53:36	1.4
@@ -51,7 +51,13 @@
 corresponding literal for the new type (with the corresponding position and
 ordering). The position number of the first enumeration literal in the
 extension part is one more than the position number of the last enumeration
-literal of the parent type.
+literal of the parent type. Each literal in the extension part shall be
+distinct from any literal inherited from the parent type.
+
+[Open issue: range of the first subtype when the parent_subtype_mark does
+not denote the first subtype. Possibilities: Illegal (but watch the
+contract model violations); same as parent subtype; same as parent subtype
+except when Parent'Last = Parent'Base'Last (then extended).]
 
 The parent_enumeration_subtype_mark shall not denote a formal derived
 enumeration type.
@@ -62,6 +68,8 @@
 check fails. For conversions between enumeration types with a common ancestor,
 conversion is equivalent to converting to the ancestor, then to the target.
 
+All scalar formal types are non-static (modifying 4.9(26)).
+
 Stream attributes for enumeration extension type alway use the default
 implementation (they are not inherited).
 
@@ -71,9 +79,62 @@
 include all new literals, and no inherited literals; the coding of inherited
 literals is the same as that of the parent type.
 
+Wide_Character is defined as an extension of Character. Thus, type conversions
+directly allow conversions between the two.
+
+A ramification is that extending an enumeration type with a specified size
+clause may require specifying a size for the extension if the extension does
+not fit in the size specified for the parent.
+
+[Open Issue: What about extended Boolean types? Do they get all of the Boolean
+treatment?
+Three solutions have been proposed:
+   1) No extensions from Boolean types. (similar to the rule for rep. clauses;
+      but some users may want to define three-valued logic). This
+      requires disallowing at enumeration extensions from formal types at
+      least in the body [assume-the-best with recheck in the spec].
+   2) Extensions from Boolean types are not Boolean types. Must fix contract
+      model problems.
+      2a) Define formal derived Boolean type is not a Boolean type (but might
+         be incompatible in very rare cases).
+      2b) A new kind of generic formal for enumeration extensions (which
+         is never a Boolean type.); extensions don't match normal
+         generic derived types. (heavyweight solution for minor problem).
+   3) Define meaning for all Boolean operations, including if. Probably like
+      non-binary modular types; for "if", anything other than False is treated
+      as True. (very heavyweight).
+]
+
 !discussion
 
+Inherited primitive operations inherit the subtype according to whatever rule
+is adopted. Since 3.4(26) says that a conversion to the parent type is done
+as part of the conversion, there is no problem with such operations (they will
+raise Constraint_Error if any extension literals are used).
+
+Extending from formal derived enumeration type must be disallowed, because
+we have to preserve the property that there are no duplicate literals
+(else 'Value would need redefinition); we want static literals; and possibly
+to avoid contract model problems with extending from Boolean types.
+
+Instead, we could define an assume-the-best rule to allow such types in the
+spec (with a recheck on instantiation).
+
+4.9(26) needs to be modified to disallow the following example:
 
+          type E1 is (Aa, Bb, Cc);
+          generic
+              type E2 is new E1;
+          package G is
+              Static_Value : constant := E2'Pos (E2'Base'Last);
+          end G;
+          type E3 is new E1 with (Dd, Ee);
+          package I is new G (E2 => E3);
+
+This is most important if Static_Value is used in the body. Indeed, it probably
+is a mistake that such types are static in Ada 95.
+
+
 !example
 
 Claw contains a package similar to the following:
@@ -914,6 +975,20 @@
 
 ****************************************************************
 
+From: Tucker Taft
+Sent: Friday, February 16, 2001 3:25 PM
+
+I meant "the" parent.  The more distant relatives are called
+the "ancestors".
+
+>      for E2 use (1, 2, 3, 4); -- legal
+>      for E2 use (Foo => 5); -- legal
+>      for E2 use (Fie => 2, Foe => 3, Foo => 5); -- legal?
+
+No, I didn't mean for that to be legal.
+
+****************************************************************
+
 From: Christoph Grein
 Sent: Thursday, February 15, 2001 12:18 AM
 
@@ -1041,6 +1116,59 @@
 
 ****************************************************************
 
+From: Tucker Taft
+Sent: Friday, February 16, 2001 3:33 PM
+
+> Let's declare a nested function Wide_Character:
+>
+> package Something is
+>     function Wide_Character (C : Character) return Standard.Wide_Character
+> is ...
+
+You have a body in your spec?  Perhaps this is an instantiation of
+something ...
+>
+>     WC : Standard.Wide_Character;
+> end Something;
+>
+> package body Something is
+> begin
+>     WC := Wide_Character (C); -- OK if we have conversions?
+
+The local declaration of Wide_Character hides the Standard
+declaration, so there is no ambiguity.
+
+> end Something;
+>
+> with Something; use Something;
+> procedure Main is
+>    WC : Wide_Character;
+> begin
+>    WC := Wide_Character (C); -- Illegal now?
+
+The declaration in package Standard hides the one from the
+"use" clause, so this is illegal in Ada 95, but would be legal
+if Wide_Character were an extension of Character.  This
+is not an incompatibility, this is a pure language extension.
+
+> end Main;
+>
+> Humm...does the visibility or the overloading get applied first? If it's the
+> visibility, then it there is no problem here. And then I don't see how you
+> could have a problem.
+
+Type declarations are non-overloadable, so they never get mixed
+up with function declarations (or array declarations, or ...),
+so there really can't be any incompatibilities.  Any existing
+code that would resolve the name "Wide_Character" so that it
+referred to Standard.Wide_Character could not change in meaning
+due to this change.  Some illegal code could become legal, but
+that's it.
+
+Usual caveats apply -- I might be wrong ;-).
+
+****************************************************************
+
 From: Robert A Duff
 Sent: Thursday, February 15, 2001 6:31 PM
 
@@ -1324,3 +1452,1277 @@
 And extensible enumerated types later, or never.
 
 ****************************************************************
+
+From: dewar@gnat.com
+Sent: Thursday, February 15, 2001 11:34 PM
+
+<<There can't possibly be any question about the default behavior: it would be
+the same as any other elementary type. Why would it be different? The
+user-defined case is a bit more interesting. But there is no requirement
+(with the Corrigendum wording) that an attribute is inherited in any way, so
+I would suggest that it should simply always use the default implementation.
+I'll add that to the AI.>>
+
+One interesting point is that the represntation of the extended type may
+be quite different from the base type (e.g. wide character is 16 bits,
+and character is 8 bits). Would a size clause constrain the derived type?
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Friday, February 16, 2001 2:51 AM
+
+> That follows because there are no unconstrained enumeration subtypes. The
+> interesting part of the paragraph says:
+
+Randy, I believe that this statement is incorrect, as are the conclusions
+that you are drawing from it.
+
+If T is an enumeration subtype, T'Base is unconstrained, see RM95 3.5(15).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, February 16, 2001 9:18 PM
+
+Argghh, you're right of course. I always forget about 'Base. OTOH, there doesn't
+seem to be much benefit to an unconstrained enumeration type. It just messes up
+the rules.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, February 17, 2001 1:07 PM
+
+I believe one reason 'Base was defined as unconstrained was so that
+enumeration types would be more like integer types, where the
+base subtype is unconstrained, and the first subtype is constrained.
+This also makes the wording in 4.9 work for enumeration subtypes,
+which says that a static subtype is a subtype with a static constraint
+applied to a static unconstrained (base) subtype.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February 19, 2001 3:22 PM
+
+That's a circular argument, of course. The reason 4.9's wording works is because
+we have unconstrained enumeration subtypes, and the reason we have unconstrained
+enumeration subtypes is because we need the wording of 4.9 to work. :-)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, February 16, 2001 8:32 AM
+
+"Baird, Steve" wrote:
+>
+> The following is a list of some of the language issues that would
+> have to be addressed if enumeration type extensions were to be
+> added to the language (an action which I do not endorse).
+>
+> No one of these would be particularly difficult to deal with,
+> but this is just a sampling and undoubtedly there would be others.
+>
+> The point I am trying to make is that this would not be a "simple"
+> change.
+>
+>   1) How would stream-oriented attributes behave, both in the case
+>      where the corresponding attribute of the parent type has the
+>      default implementation and in the case where it has a
+>      user-defined implementation?
+
+I don't see the need for a special case here.  RM2000 13.13.2(8/1/1,25/1)
+say user-defined stream attributes are inherited for untagged
+derived types.  This seems like the simplest choice, since this
+just treats these attributes like any other user-defined
+primitive operation.  I can't imagine any kind of automatic
+"extension" the compiler could provide.  For tagged extensions,
+it is pretty clear how to construct an "extended" version of
+the stream attributes (i.e. use the user-defined op for the
+parent part, and use the default for the extension part).
+
+>
+>   2) It seems like the parent subtype must be unconstrained.
+>      What would this mean
+>           type E1 is (Aa, Bb, Cc);
+>           subtype S is E1 range Aa .. Bb;
+>           type E2 is new S with (Dd, Ee);
+>      ?
+
+The normal rules for type derivation say that you create
+a derived type based on the parent type, and then a derived
+subtype based on the parent subtype.  This would work the same here,
+making the above equivalent to:
+
+    type E2_Base is new E1 with (Dd, Ee);
+    subtype E2 is E2_Base range Aa .. Bb;
+
+Again, I don't see the need for a special case here.
+
+>
+>   3) Perhaps it falls out, but clarification might be needed
+>      to ensure that a case like
+>
+>          type E1 is (Aa, Bb, Cc);
+>          type Aa_Again is new E1 with (Dd, Aa);
+>
+>      is rejected (i.e. the explicit-takes-precedence-over-implicit
+>      rule would not apply here).
+
+This probably does need a special case, if we want
+to disallow it.  Otherwise, it would be interpreted
+as the inherited Aa is being overridden with a new one,
+which isn't the end of the world, but is probably a mistake
+that the user would like notification of.  We currently
+explicitly disallow duplicate names in record extensions,
+and perhaps the same would be appropriate here.
+
+
+>
+>      For similar reasons, enumeration extension of a formal derived
+>      (enumeration) type should be disallowed.
+
+I'm not convinced this is necessary.  I would treat it like
+record extensions, where it is OK in the body, but in the spec,
+you must check at instantiation time that there are no
+duplicates (presuming we decide to disallow duplicates at all).
+The definition of Enum'Value would have to indicate which
+one is chosen (presumably the latter one, since that is
+the only one the body "knows" about).
+
+>
+>   4) 4.6(28) "...this can only happen on conversion to a modular
+>      type" would require modification. It might be worth stating
+>      explicitly that extension values of two structurally similar
+>      extensions are not corresponding values. For example,
+>          type E1 is (Aa, Bb, Cc);
+>          type E2 is new E1 with (Dd);
+>          type E3 is new E1 with (Dd);
+>          X3 : E3 := E3 (E2'(Dd));
+>      the elaboration of X3 would raise Constraint_Error.
+
+As I suggested in an earlier note, I would recommend requiring that
+the type conversion perform a check against the base range of
+the nearest common ancestor, followed by a range check against
+the target subtype.
+
+>
+>   5) 3.4(9) and 13.1(5) would obviously require modification.
+>      Consider, for example, the attributes LAST and SIZE.
+
+Randy guessed you meant 13.1(15) which makes sense.  He also
+pointed out that 'Size is subtype specific, but it still seems
+that if 'Size is specified for the parent (first) subtype, then
+that specified 'Size would be inherited by the extended (first)
+subtype, and it will need to be overridden if it is too small.
+
+>
+>   6) This example should clearly be rejected,
+>
+>          type E1 is (Aa, Bb, Cc);
+>          generic
+>              type E2 is new E1;
+>          package G is
+>              Static_Value : constant := E2'Pos (E2'Base'Last);
+>          end G;
+>          type E3 is new E1 with (Dd, Ee);
+>          package I is new G (E2 => E3);
+
+I agree with your suggestion that we should make all scalar formal
+types non-static, rather than just "formal scalar types".
+
+I was wondering whether we should require a special formal
+type syntax for enumeration extensions, e.g:
+   type Possibly_Extended is new Base with (<>);
+
+However, this is probably unnecessary because the actual for
+a formal derived type could be a constrained subtype, so you
+can't make assumptions about 'First or 'Last anyway inside
+the generic.  As suggested above, 'Base'First or 'Base'Last
+might not be what is expected, but that seems OK.
+In fact, derived enumeration types are pretty rare anyway,
+so chances are all uses of formal derived enumeration types
+would be there primarily to deal with extensions. (This reminds
+me of the Ada 83 => Ada 95 situation, where derived types
+were pretty rare in Ada 83, and only became of widespread use
+once (tagged) extension was introduced.)
+
+>      but on what basis? Does the definition of "static scalar
+>      subtype" need to be changed (i.e. treat a formal derived
+>      scalar type the same as a formal scalar type in 4.9(26)), or
+>      should the matching rules of 12.5.1(7-10) be tightened up?
+
+Yes, I agree we should make all scalar formal types non static.
+
+>
+>   7) Would 3.4(19) require modification? Is it already clear
+>      (with no wording changes) that in this example
+>          package Pkg1 is
+>              type E1 is (Aa, Bb, Cc);
+>              procedure Proc (X : E1);
+>          end Pkg;
+>          package Pkg2 is
+>              type E2 is new Pkg1.E1 with (Dd, Ee);
+>          end;
+>      the subtype of Pkg2.Proc.X would have 3 values, not 5?
+
+Good point.  I claimed there was no special case here, but
+now it looks like if we derive from a subtype whose range
+matches the base range, then the first subtype of the
+extended enumeration type should also have a range that
+matches the base range.  On the other hand, if the parent
+subtype's range does not match the base range, then the
+derived subtype should have that same reduced range.
+
+Alternatively, we could say if the 'Last of the parent
+subtype equals 'Base'Last, then the 'Last of the derived
+subtype equals the new 'Base'Last.  This could be marginally
+more useful.
+
+****************************************************************
+
+From: Michael Yoder
+Sent: Friday, February 16, 2001 1:11 PM
+
+Tucker wrote:
+
+> >
+> >   3) Perhaps it falls out, but clarification might be needed
+> >      to ensure that a case like
+> >
+> >          type E1 is (Aa, Bb, Cc);
+> >          type Aa_Again is new E1 with (Dd, Aa);
+> >
+> >      is rejected (i.e. the explicit-takes-precedence-over-implicit
+> >      rule would not apply here).
+>
+>This probably does need a special case, if we want
+>to disallow it.  Otherwise, it would be interpreted
+>as the inherited Aa is being overridden with a new one,
+>which isn't the end of the world, but is probably a mistake
+>that the user would like notification of.  We currently
+>explicitly disallow duplicate names in record extensions,
+>and perhaps the same would be appropriate here.
+
+I'd recommend disallowing a duplicate value; otherwise, T'Value (T'Image
+(X)) = X fails.  Or, put another way, I think it's best to preserve the
+property that T'Image maps to distinct values always.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, February 16, 2001 9:38 PM
+
+Tuck wrote, responding to Steve Baird:
+
+> >   1) How would stream-oriented attributes behave, both in the case
+> >      where the corresponding attribute of the parent type has the
+> >      default implementation and in the case where it has a
+> >      user-defined implementation?
+>
+> I don't see the need for a special case here.  RM2000 13.13.2(8/1/1,25/1)
+> say user-defined stream attributes are inherited for untagged
+> derived types.  This seems like the simplest choice, since this
+> just treats these attributes like any other user-defined
+> primitive operation.  I can't imagine any kind of automatic
+> "extension" the compiler could provide.  For tagged extensions,
+> it is pretty clear how to construct an "extended" version of
+> the stream attributes (i.e. use the user-defined op for the
+> parent part, and use the default for the extension part).
+
+It's annoying that Tucker and I got exactly opposite answers to most of
+these questions. Seems to make Steve's point. :-)
+
+The parent type's user-defined stream attributes may not be prepared to
+handle the extra literals added by an extension. If you inherit the parent
+type's attributes, they simply might break when expected to handle those
+literals. I still think the best solution is to revert them.
+
+> >   2) It seems like the parent subtype must be unconstrained.
+> >      What would this mean
+> >           type E1 is (Aa, Bb, Cc);
+> >           subtype S is E1 range Aa .. Bb;
+> >           type E2 is new S with (Dd, Ee);
+> >      ?
+>
+> The normal rules for type derivation say that you create
+> a derived type based on the parent type, and then a derived
+> subtype based on the parent subtype.  This would work the same here,
+> making the above equivalent to:
+>
+>     type E2_Base is new E1 with (Dd, Ee);
+>     subtype E2 is E2_Base range Aa .. Bb;
+>
+> Again, I don't see the need for a special case here.
+
+Err, then you have to have a special case for the first subtype: otherwise,
+you'd end up with a constraint that didn't allow the new literals.
+
+I still prefer to simply ignore the constraint (all derived types ought to
+do that, but that's another story).
+
+> >   3) Perhaps it falls out, but clarification might be needed
+> >      to ensure that a case like
+> >
+> >          type E1 is (Aa, Bb, Cc);
+> >          type Aa_Again is new E1 with (Dd, Aa);
+> >
+> >      is rejected (i.e. the explicit-takes-precedence-over-implicit
+> >      rule would not apply here).
+>
+> This probably does need a special case, if we want
+> to disallow it.  Otherwise, it would be interpreted
+> as the inherited Aa is being overridden with a new one,
+> which isn't the end of the world, but is probably a mistake
+> that the user would like notification of.  We currently
+> explicitly disallow duplicate names in record extensions,
+> and perhaps the same would be appropriate here.
+
+OK, I added a sentence to that effect to the AI.
+
+> >      For similar reasons, enumeration extension of a formal derived
+> >      (enumeration) type should be disallowed.
+>
+> I'm not convinced this is necessary.  I would treat it like
+> record extensions, where it is OK in the body, but in the spec,
+> you must check at instantiation time that there are no
+> duplicates (presuming we decide to disallow duplicates at all).
+> The definition of Enum'Value would have to indicate which
+> one is chosen (presumably the latter one, since that is
+> the only one the body "knows" about).
+
+How do you assign the position numbers of the literals in the body? And in
+both cases, the position numbers of the literals aren't static (using my
+"generic code sharing" glasses). Best to disallow these.
+
+
+> >   5) 3.4(9) and 13.1(5) would obviously require modification.
+> >      Consider, for example, the attributes LAST and SIZE.
+>
+> Randy guessed you meant 13.1(15) which makes sense.  He also
+> pointed out that 'Size is subtype specific, but it still seems
+> that if 'Size is specified for the parent (first) subtype, then
+> that specified 'Size would be inherited by the extended (first)
+> subtype, and it will need to be overridden if it is too small.
+
+I suppose.
+
+> >   7) Would 3.4(19) require modification? Is it already clear
+> >      (with no wording changes) that in this example
+> >          package Pkg1 is
+> >              type E1 is (Aa, Bb, Cc);
+> >              procedure Proc (X : E1);
+> >          end Pkg;
+> >          package Pkg2 is
+> >              type E2 is new Pkg1.E1 with (Dd, Ee);
+> >          end;
+> >      the subtype of Pkg2.Proc.X would have 3 values, not 5?
+>
+> Good point.  I claimed there was no special case here, but
+> now it looks like if we derive from a subtype whose range
+> matches the base range, then the first subtype of the
+> extended enumeration type should also have a range that
+> matches the base range.  On the other hand, if the parent
+> subtype's range does not match the base range, then the
+> derived subtype should have that same reduced range.
+
+Tuck seems to have this backwards: for the declaration of a type, we don't
+want to inherit the subtype. However, for this case (a derived subprogram
+parameter), we *do* want to inherit the subtype. (Which is what happens
+without modifying 3.4(19)). That's because the inherited subprogram probably
+isn't prepared to deal with the extra literals; any call using them should
+raise Constraint_Error (see my large example).
+
+However, there is a (minor) problem if someone actually uses 'Base:
+
+   package Pkg1 is
+	... as before...
+      procedure Proc (X : E1'Base);
+   end Pkg1;
+   package Pkg2 is
+      type E2 is new Pkg1.E1 with (Dd, Ee);
+   end Pkg2;
+
+In this case, Proc would indeed get all of the literals, and that might be
+surprising. I claim that if someone actually uses the unconstrained type,
+they must have wanted anything possible, and thus we still don't need to
+change the rule.
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Friday, February 16, 2001 10:03 AM
+
+I believe according to the current wording, an extension of Boolean
+would be a boolean type, so the following would be legal:
+
+    type My_Boolean is new Boolean with (Maybe, Perhaps, Probably);
+
+    X: My_Boolean := Maybe;
+
+    if X then ...
+
+but it's not completely clear what it should do at run time.  ;-)
+
+There are other special things about boolean types that would need to be
+investigated.  Eg, does an array of one of these things get "xor"?
+
+Is this legal:
+
+    package P is
+	type T1 is (Red, Blue);
+	type T2 is new T1 with private;
+    private
+	type T2 is new T1 with (Green);
+    end P;
+
+?
+
+I'll repeat what I said before: This feature is not near the top of the
+priority list, IMHO.
+
+****************************************************************
+
+From: Michael Yoder
+Sent: Friday, February 16, 2001 2:21 PM
+
+>but it's not completely clear what it should do at run time.  ;-)
+
+I'd say it propagates Constraint_Error; of course I'm reasoning by
+analogy.  Alternatively, treat all non-False values as true.
+
+>There are other special things about boolean types that would need to be
+>investigated.  Eg, does an array of one of these things get "xor"?
+
+Well, presumably they map whatever these functions become for the type
+itself.  How about:
+
+     type T is new Boolean with (Another, ...);
+     -- X and Y = T'Min (X, Y)
+     -- X or Y = T'Max (X, Y)
+     -- X xor Y = T'Val ((T'Pos (X) + T'Pos(Y)) mod N) where
+     --      N = 1 + T'Pos (T'Last)
+     -- not X = T'Val (N - 1 - T'Pos (X))
+Alternatively,
+     -- not False = True
+     -- not True = False
+     -- not X = X otherwise
+
+This last definition of "not" may seem surprising, but my recollection is
+that it is used in some multivalued logics.  The first definition of "not"
+preserves de Morgan's rules.
+
+
+>Is this legal:
+>
+>     package P is
+>         type T1 is (Red, Blue);
+>         type T2 is new T1 with private;
+>     private
+>         type T2 is new T1 with (Green);
+>     end P;
+
+I'd assume so.  You may now cry "Aha!" and spring some horrible consequence
+on us if you like.  :-)
+
+>I'll repeat what I said before: This feature is not near the top of the
+>priority list, IMHO.
+
+I agree; but so far I think this issue is generating effort rather than
+soaking it from other activities.  I hope the discussion will continue
+until there is a complete proposal.  We can choose to shelve it until
+triage time if people like.
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Friday, February 16, 2001 5:10 PM
+
+> I'd say it propagates Constraint_Error; of course I'm reasoning by
+> analogy.  Alternatively, treat all non-False values as true.
+
+Hmm.  My first thought was to say that My_Boolean is not a "boolean
+type", so it's illegal to use it in if_stmts, and it doesn't get an
+"xor" operator, and so forth.  But depending no how Tuck's argument with
+Steve about generic formal parameters turns out, that might cause
+contract model problems to rear their ugly heads.
+
+> >There are other special things about boolean types that would need to be
+> >investigated.  Eg, does an array of one of these things get "xor"?
+>
+> Well, presumably they map whatever these functions become for the type
+> itself.  How about:
+>
+>      type T is new Boolean with (Another, ...);
+>      -- X and Y = T'Min (X, Y)
+>      -- X or Y = T'Max (X, Y)
+>      -- X xor Y = T'Val ((T'Pos (X) + T'Pos(Y)) mod N) where N = 1 + T'Pos
+> (T'Last)
+>      -- not X = T'Val (N - 1 - T'Pos (X))
+> Alternatively,
+>      -- not False = True
+>      -- not True = False
+>      -- not X = X otherwise
+>
+> This last definition of "not" may seem surprising, but my recollection is
+> that it is used in some multivalued logics.  The first definition of "not"
+> preserves de Morgan's rules.
+
+The above remind me of the definition of "not" for non-binary modular
+types.
+
+> >Is this legal:
+> >
+> >     package P is
+> >         type T1 is (Red, Blue);
+> >         type T2 is new T1 with private;
+> >     private
+> >         type T2 is new T1 with (Green);
+> >     end P;
+>
+> I'd assume so.  You may now cry "Aha!" and spring some horrible consequence
+> on us if you like.  :-)
+
+No, I didn't have any nasty thing up my sleeve.  But the syntactic
+proposals I've seen so far didn't include any mention of "with private",
+but it does seem natural to allow it.  It might even be useful (an enum
+type with some values hidden).
+
+> >I'll repeat what I said before: This feature is not near the top of the
+> >priority list, IMHO.
+>
+> I agree; but so far I think this issue is generating effort rather than
+> soaking it from other activities.  I hope the discussion will continue
+> until there is a complete proposal.  We can choose to shelve it until
+> triage time if people like.
+
+Besides, this is fun.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, February 16, 2001 10:07 PM
+
+> > Bob Duff wrote:
+> >
+> > At 11:02 AM 2/16/01 -0500, you wrote:
+> > >I believe according to the current wording, an extension of Boolean
+> > >would be a boolean type, so the following would be legal:
+> > >
+> > >     type My_Boolean is new Boolean with (Maybe, Perhaps, Probably);
+> > >
+> > >     X: My_Boolean := Maybe;
+> > >
+> > >     if X then ...
+> > >
+> > >but it's not completely clear what it should do at run time.  ;-)
+> >
+> > I'd say it propagates Constraint_Error; of course I'm reasoning by
+> > analogy.  Alternatively, treat all non-False values as true.
+>
+> Hmm.  My first thought was to say that My_Boolean is not a "boolean
+> type", so it's illegal to use it in if_stmts, and it doesn't get an
+> "xor" operator, and so forth.  But depending no how Tuck's argument with
+> Steve about generic formal parameters turns out, that might cause
+> contract model problems to rear their ugly heads.
+
+If the Corrigendum hadn't changed all of the Boolean operations to 'Base to
+fix some other problem, the Constraint_Error solution would fall out
+automatically.
+
+Extensions of generic scalar formal parameters will not be allowed. Mr.
+Code-shared generics forbids it. :-)
+
+Are you thinking of something like:
+
+    generic
+       type Some_Bool is new Boolean;
+    package Gen is
+       procedure Something;
+       B : Some_Bool := Some_Bool'Last;
+    end Gen;
+
+    package body Gen is
+       procedure Something is
+       begin
+           if B then -- Use of B as a Boolean type.
+              ...
+           end if;
+       end Something;
+    end Gen;
+
+    type Ext is new Boolean with (Whatever);
+
+    package A_Gen is new Gen (Ext);
+
+Yup, that's a problem, because we're doing an if on a Boolean type, and it's
+hidden in the body. Our options would be:
+   (1) Disallow the instantiation (if the formal is a Boolean type, then the
+actual must be a Boolean type).
+   (2) Say that the formal is not a Boolean type (disallowing the IF).
+   (3) Push the check to runtime (raising Constraint_Error as Mike
+suggested).
+   (4) Defining the meaning of "if <cond> then" to be "if <cond> /= False
+then". (And then using the rules for modular types to define all of the
+other logical operations.)
+
+I don't know which makes the most sense of these. (2) might be incompatible
+with somebodies program, but it's hard to imagine what they would be doing
+where they'd need a derived Boolean type. None of the others have an
+compatibility problem at all.
+
+> > I agree; but so far I think this issue is generating effort rather than
+> > soaking it from other activities.  I hope the discussion will continue
+> > until there is a complete proposal.  We can choose to shelve it until
+> > triage time if people like.
+>
+> Besides, this is fun.
+
+Well, it probably is taking some of my time away from other tasks, so it
+isn't completely harmless.
+
+But it is fun. :-)
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Saturday, February 17, 2001 9:30 AM
+
+> Are you thinking of something like:
+>
+>     generic
+>        type Some_Bool is new Boolean;
+>     package Gen is
+>        procedure Something;
+>        B : Some_Bool := Some_Bool'Last;
+>     end Gen;
+>
+>     package body Gen is
+>        procedure Something is
+>        begin
+>            if B then -- Use of B as a Boolean type.
+>               ...
+>            end if;
+>        end Something;
+>     end Gen;
+>
+>     type Ext is new Boolean with (Whatever);
+>
+>     package A_Gen is new Gen (Ext);
+
+Yes, that's the sort of thing I was thinking about.
+
+****************************************************************
+
+From: dewar@gnat.com
+Sent: Sunday, February 18, 2001 7:59 AM
+
+All this discussion of extensible enumerated types is very nice, but
+surely it simply shows this facility is not worth pursuing at this
+stage???
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February 19, 2001 2:23 PM
+
+But it's also obvious that people are interested in working on this feature,
+which is more than I can say for any number of so-called "more important"
+proposals. I think it makes the most sense for the full ARG to decide
+whether they want to persue this at the next meeting. It can't possibly be
+harmful to tease out as many problems as possible: at worst, it will provide
+a ready answer of "too complex" the next time someone brings it up.
+
+****************************************************************
+
+From: Deller, Steve
+Sent: Monday, February 19, 2001 12:13 AM
+
+I for one believe extensible enumerated types would have seen frequent use
+already, had they been available.
+
+To me that makes a strong argument for this being a very useful facility and
+therefore one worth pursuing at this time.
+
+The POSIX Ada committee tried to make POSIX.Error_Code and POSIX.Signal_Code
+enumerated types, but the requirement for independent extension kept raising
+its ugly head and in the end, we settled for a distinctly non-Ada
+"implementation defined integer type" with loads of defined constants.
+
+I have seen similar situations repeated with numerous applications, where
+there is some base list of enumerations that must be allowed to be extended
+independently.  The typical solution is to drop back to integers and play
+"other-language"-like games in Ada.
+
+As for Booleans, an extended Boolean is not a Boolean and should not be
+permitted in an if statement.  The alternative, as many have noted, is too
+gruesome to contemplate.
+
+For utility, it seems to me that if extensible enumeration types are
+defined, then there needs to be some way to define a formal for generics
+that explicitly *disallows* or *allows* extension of a derived enumeration
+type.  If I understood Pascal, that also solves the Boolean-generic issue.
+
+Extended Booleans are disallowed as expression results in an if statement.
+By extension :-),
+  generic
+    type X is new Boolean ;
+    type Y is new Boolean with (<>) ;
+
+means  X can be used in if statement expression, and Y cannot.
+
+Of course you can always do:
+  B : Y ;
+  ...
+  if Boolean(B) then ...
+
+and get a constraint error if B is neither True nor False.
+
+Below is one way I believe we might have used extensible enumeration types
+with POSIX.
+
+Regards,
+Steve
+
+
+package Posix is
+  type Error_Code is (No_Error, Argument_Too_Long, File_Does_Not_Exist ) ;
+end Posix ;
+
+with Posix ;
+package Posix_HPUX_Extensions is
+  type Error_Code is new Posix.Error_Code with ( Math_Domain_Error ) ;
+end Posix_HPUX_Extensions ;
+
+with Posix_HPUX_Extensions ;
+package Posix_HPUX_10_0_Extensions is
+  type Error_Code is new Posix_HPUX_Extensions.Error_Code with ( No_Thread )
+;
+end Posix_HPUX_Extensions ;
+
+with Posix ;
+package Posix_Solaris_Extensions is
+  type Error_Code is new Posix.Error_Code with ( Thread_Stopped ) ;
+end Posix_Solaris_Extensions ;
+
+
+-- Define a generic that can be instantiated with any "Error_Code" type
+with Posix ;
+generic
+  type P_E is new Posix.Error_Code with (<>) ;
+procedure Portable_Announce_Error ( Error : in P_E ) ;
+
+procedure Portable_Announce_Error ( Error : in P_E ) is
+    type Message is new String(1..43) ;
+
+    Known_Messages : array ( Posix.Error_Code'range ) of Message :=
+        ( No_Error =>            "There was no error                         " ,
+          Argument_Too_Long =>   "An argument is too long for call buffer    " ,
+          File_Does_Not_Exist => "The file is not in the specified directory " ) ;
+
+    Print_Message : Message :=   "Non-standard POSIX error code              " ;
+
+begin
+    case Error is
+      when P_E'Parent'Range => Print_Message :=
+           Known_Messages(Posix.Error_Code( Error)) ;
+      -- ?? Not sure 'Parent'Range has appropriate typing
+      -- ?? May need to use: when P_E( Posix.Error_Code'First) ..
+      --        P_E( Posix.Error_Code'Last) =>
+      when others => null ;
+    end case ;
+
+    Text_Io.Put_Line ( "Error: " & P_E'Image(Error) & ", " & Print_Message );
+
+end Announce_Error;
+
+****************************************************************
+From: Randy Brukardt [Randy@RRSoftware.Com]
+Sent: Monday, February 19, 2001 2:41 PM
+To: 'Ada-Comment List'
+Cc: 'Deller, Steve'
+Subject: Re: [Ada-Comment] Extensible Enumerated Types
+
+> For utility, it seems to me that if extensible enumeration types are
+> defined, then there needs to be some way to define a formal for generics
+> that explicitly *disallows* or *allows* extension of a derived enumeration
+> type.  If I understood Pascal, that also solves the Boolean-generic issue.
+
+Yes, it would, but...
+
+> Extended Booleans are disallowed as expression results in an if statement.
+> By extension :-),
+>   generic
+>     type X is new Boolean ;
+>     type Y is new Boolean with (<>) ;
+>
+> means  X can be used in if statement expression, and Y cannot.
+
+The "problem" with this is that the first form is almost completely useless.
+The only reason to add all of the baggage of a new kind of generic formal is
+to allow the 100% compatibility with the likely to be zero existing programs
+that use formals in the form of X above.
+
+I think it makes more sense to say that a generic derived formal type is
+never a Boolean type. The only program that that could break is one that
+uses both derived Boolean types *and* generic formal derived Boolean
+types -- I think that is the empty set.
+
+(Besides, that would eliminate the major problem with supporting
+representation clauses on derived Boolean types.)
+
+****************************************************************
+
+From: dewar@gnat.com
+Sent: Sunday, February 18, 2001 9:09 AM
+
+<<The above remind me of the definition of "not" for non-binary modular
+types.>>
+
+Indeed! One of the most horrible features of the language in my opinion.
+Orthogonality gone berserk :-)
+
+But then the whole presence of non-binary modular types is a mistake
+in my opinion (and for sure this feature only appeared in Ada 95
+through a misunderstanding -- the designers thought the URG had
+recommended this feature, when in fact they had overwhelmingly
+rejected it :-)
+
+****************************************************************
+
+From: dewar@gnat.com
+Sent: Sunday, February 18, 2001 8:46 AM
+To: ada-comment@ada-auth.org
+Subject: Re: [Ada-Comment] Extensible Enumerated Types
+
+<<I'd say it propagates Constraint_Error; of course I'm reasoning by
+analogy.  Alternatively, treat all non-False values as true.>>
+
+I really think that's horrible. Why add this completely unnecessary and
+useless feature for the purposes of misguided orthogonality.
+
+<<This last definition of "not" may seem surprising, but my recollection is
+that it is used in some multivalued logics.  The first definition of "not"
+preserves de Morgan's rules.>>
+
+Surprising indeed, again, why confuse things.
+
+Treat Boolean specially and don't allow extension. After all we don't
+require even that rep clauses for Boolean be supported.
+
+****************************************************************
+
+
+From: Pascal Leroy
+Sent: Saturday, February 17, 2001 5:04 AM
+
+> > Alternatively, treat all non-False values as true.
+
+Boy, that's disgusting.  I am told there are programming languages out there
+which treat non-zero values as True.  Do we really want to do the same?
+
+> Hmm.  My first thought was to say that My_Boolean is not a "boolean
+> type", so it's illegal to use it in if_stmts, and it doesn't get an
+> "xor" operator, and so forth.
+
+That seems like the best approach.
+
+> But depending no how Tuck's argument with
+> Steve about generic formal parameters turns out, that might cause
+> contract model problems to rear their ugly heads.
+
+Not if you have a new kind of generic formal parameter for an extended
+enumeration type.
+
+****************************************************************
+
+From: dewar@gnat.com
+Sent: Sunday, February 18, 2001 10:02 AM
+
+<<Boy, that's disgusting.  I am told there are programming languages out there
+which treat non-zero values as True.  Do we really want to do the same?>>
+
+Just as a side comment, GNAT actually implements zero/non-zero semantics
+for boolean types which have appropriate foreign conventions. We found
+we had to do this for the Fortran LOGICAL case (some would argue that
+making Fortran LOGICAL new Boolean when it has zero/non-zero semantics
+is a language design error -- or at least an oversite), so why not do
+it for C "boolean" as well. This has actually turned out quite useful,
+and is perhaps worth an AI.
+
+I wonder if other compilers properly handle the zero/non-zero semantics
+of Interfaces.Fortran.Logical? We had to fix this not because of an
+ACATS test (there is none, which is a big omission), but because of
+actual user complaints with interfacing to Fortran.
+
+****************************************************************
+
+From: Randy Brukardt [Randy@RRSoftware.Com]
+Sent: Monday, February 19, 2001 2:26 PM
+To: 'Ada-Comment List'
+Subject: Re: [Ada-Comment] Extensible Enumerated Types
+
+> I wonder if other compilers properly handle the zero/non-zero semantics
+> of Interfaces.Fortran.Logical? We had to fix this not because of an
+> ACATS test (there is none, which is a big omission), but because of
+> actual user complaints with interfacing to Fortran.
+
+Janus/Ada does (at least, it is *supposed* to; I don't know if anyone ever
+has used the Fortran interface in J/A). We mainly did that for C so that the
+Windows interface could use Boolean directly rather than having to define
+another type to represent that. Dunno if that was a good idea.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, February 17, 2001 1:23 PM
+
+Randy Brukardt wrote:
+>
+> Tuck wrote, responding to Steve Baird:
+>
+> > >   1) How would stream-oriented attributes behave, both in the case
+> > >      where the corresponding attribute of the parent type has the
+> > >      default implementation and in the case where it has a
+> > >      user-defined implementation?
+> >
+> > I don't see the need for a special case here.  RM2000 13.13.2(8/1/1,25/1)
+> > say user-defined stream attributes are inherited for untagged
+> > derived types.  This seems like the simplest choice, since this
+> > just treats these attributes like any other user-defined
+> > primitive operation.  I can't imagine any kind of automatic
+> > "extension" the compiler could provide.  For tagged extensions,
+> > it is pretty clear how to construct an "extended" version of
+> > the stream attributes (i.e. use the user-defined op for the
+> > parent part, and use the default for the extension part).
+>
+> It's annoying that Tucker and I got exactly opposite answers to most of
+> these questions. Seems to make Steve's point. :-)
+>
+> The parent type's user-defined stream attributes may not be prepared to
+> handle the extra literals added by an extension. If you inherit the parent
+> type's attributes, they simply might break when expected to handle those
+> literals. I still think the best solution is to revert them.
+
+They don't really break, presumably, because their semantics
+are defined in terms of conversion, and that would "weed out"
+any of the values outside the base range of the parent type.
+This is going to be true for all user-defined primitives.
+Perhaps they should all become abstract, requiring that they
+all be overridden, since the implicit conversion to the parent
+is bound to cause trouble.  Curiously enough, primitive functions
+that return the parent type and have no parameters of the type
+(e.g. the enumeration literals) and primitive procedures that have
+only OUT parameters of the type would be OK.  Any primitive with an
+IN or IN OUT parameter of the type should perhaps become abstract in
+an enumeration type extension.
+
+Weird...
+>
+> > >   2) It seems like the parent subtype must be unconstrained.
+> > >      What would this mean
+> > >           type E1 is (Aa, Bb, Cc);
+> > >           subtype S is E1 range Aa .. Bb;
+> > >           type E2 is new S with (Dd, Ee);
+> > >      ?
+> >
+> > The normal rules for type derivation say that you create
+> > a derived type based on the parent type, and then a derived
+> > subtype based on the parent subtype.  This would work the same here,
+> > making the above equivalent to:
+> >
+> >     type E2_Base is new E1 with (Dd, Ee);
+> >     subtype E2 is E2_Base range Aa .. Bb;
+> >
+> > Again, I don't see the need for a special case here.
+>
+> Err, then you have to have a special case for the first subtype: otherwise,
+> you'd end up with a constraint that didn't allow the new literals.
+
+Yes, I realized that later.
+
+>
+> I still prefer to simply ignore the constraint (all derived types ought to
+> do that, but that's another story).
+
+That seems pretty inconsistent.  I would rather complain
+at the point of derivation than ignore the constraint on the
+parent subtype.  I think the approach of imposing the same constraint
+unless the parent subtype'Last = parent_subtype'Base'Last is
+probably the best intermediate solution.
+
+> ...
+> How do you assign the position numbers of the literals in the body? And in
+> both cases, the position numbers of the literals aren't static (using my
+> "generic code sharing" glasses). Best to disallow these.
+
+Yes, I suppose we could disallow extension of a formal enumeration
+type in the body, in the same way we disallow extension of tagged
+types in a body.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February 19, 2001 3:14 PM
+
+> They don't really break, presumably, because their semantics
+> are defined in terms of conversion, and that would "weed out"
+> any of the values outside the base range of the parent type.
+
+You mean by raising Constraint_Error. Probably right.
+
+> This is going to be true for all user-defined primitives.
+> Perhaps they should all become abstract, requiring that they
+> all be overridden, since the implicit conversion to the parent
+> is bound to cause trouble.
+
+Tuck, *please* forget that "abstract" stuff: "must-be-overridden" hasn't
+been tied to abstract since Mapping 4.0. Indeed, "must-be-overridden"
+primitives are *not* abstract.
+
+As far as the idea itself, I think it is terrible. It would make these
+things too annoying to use; there's no benefit in forcing people to make
+things work perfectly when the language is safe in any case. I could see
+doing that for stream attributes specifically, but not for all primitives.
+
+> Curiously enough, primitive functions
+> that return the parent type and have no parameters of the type
+> (e.g. the enumeration literals) and primitive procedures that have
+> only OUT parameters of the type would be OK.  Any primitive with an
+> IN or IN OUT parameter of the type should perhaps become abstract in
+> an enumeration type extension.
+>
+> Weird...
+
+> > I still prefer to simply ignore the constraint (all derived types ought to
+> > do that, but that's another story).
+>
+> That seems pretty inconsistent.  I would rather complain
+> at the point of derivation than ignore the constraint on the
+> parent subtype.  I think the approach of imposing the same constraint
+> unless the parent subtype'Last = parent_subtype'Base'Last is
+> probably the best intermediate solution.
+
+Since Ada is a "name-equivalence" rather than a "structural-equivalence"
+language, I would prefer to make the special-case rule apply only to the
+first subtype itself, not to any accidentally matching subtypes.
+
+Your rule would break various subtypes I've used in Claw:
+
+    type System_Info_Kinds is
+      (Icon_Spacing, Double_Click_Time, Screen_Width, Screen_Height);
+    subtype Readable_System_Info_Kinds is
+        range Double_Click_Time .. Screen_Height;
+    subtype Writable_System_Info_Kinds is
+        range Icon_Spacing .. Double_Click_Time;
+
+    procedure Get_Info (Info_Kind : in Readable_System_Info_Kinds)
+        return Claw.Int;
+
+    ...
+
+    type Windows_2000_System_Info_Kinds is new System_Info_Kinds
+       with (Drag_Width, Drag_Height);
+
+with Tucker's rule, the inherited Get_Info would include the new literals,
+but that would be wrong (Drag_Height and Drag_Width are not readable here),
+and in any case, the routine would not be expecting any extra literals.
+
+To look at the results, let's look at all of the interesting cases:
+
+     type Alpha is (A, B, C, D);
+     subtype Head_Alpha is range A .. C;
+     subtype Tail_Alpha is range B .. D;
+     subtype All_Alpha  is range A .. D;
+
+     ...
+
+     type New1 is Alpha with (E, F); -- (1)
+     type New2 is Head_Alpha with (E, F); -- (2)
+     type New3 is Tail_Alpha with (E, F); -- (3)
+     type New4 is All_Alpha with (E, F); -- (4)
+
+What are the constraints of the first subtype? It's clear that for (1), we
+have to have a rule that makes the first subtype include E and F -- anything
+else would make the feature very hard to use. But what to do with (2)
+through (4)?
+
+Tucker's rule (Impose the same constraint unless the parent subtype'Last =
+parent_subtype'Base'Last) provides the following answers: (2) A .. C; (3) B
+.. F; (4) A .. F. I think (3) is unacceptable; (4) I dislike, but it
+probably could be gotten used to.
+
+I had suggested only expanding if the name denotes the first subtype. Then
+all of the (2) .. (4) include only their original range.
+
+However, *that* is very counter-intuitive: because there are additional
+literals declared, but you can't use them without resorting to 'Base. Thus,
+I find it crazy to inherit any constraint here; but for other uses (i.e.
+subtypes of primitive subprograms), we would inherit everything.
+
+Tucker suggested an alternative of disallowing deriving from a subtype. I
+would be happy to adopt such a rule, but it clearly would cause a contract
+model violation:
+
+    generic
+       type New_Alpha is new Alpha;
+    package Fooey is
+       type More_Alpha is new New_Alpha with (X, Y, Z);
+    end Fooey;
+
+    package Inst is new Fooey (New3);
+
+One could adopt an assume-the-best/assume-the-worst rule to deal with this
+(which would certainly require disallowing extensions in the body). But it
+would be ugly.
+
+> > ...
+> > How do you assign the position numbers of the literals in the body? And
+in
+> > both cases, the position numbers of the literals aren't static (using my
+> > "generic code sharing" glasses). Best to disallow these.
+>
+> Yes, I suppose we could disallow extension of a formal enumeration
+> type in the body, in the same way we disallow extension of tagged
+> types in a body.
+
+I don't think we have a choice; there are too many problems otherwise
+(meaning of 'Value, staticness of literals, the above problem, etc.)
+
+****************************************************************
+
+From: Baird, Steve
+Sent: Sunday, February 18, 2001 6:18 PM
+
+From: Randy Brukardt, replying to Steve Baird
+Sent: 2/15/2001 8:49 PM
+
+> >   5) 3.4(9) and 13.1(5) would obviously require modification.
+> >      Consider, for example, the attributes LAST and SIZE.
+
+> 3.4(9): of course. 13.1(5): I think you meant 13.1(15).
+
+Right. Sorry about any confusion.
+
+--------
+
+From: Randy Brukardt, replying to Steve Baird
+Sent: 2/15/2001 8:49 PM
+
+> >   6) This example should clearly be rejected,
+> >
+> >         type E1 is (Aa, Bb, Cc);
+> >         generic
+> >              type E2 is new E1;
+> >         package G is
+> >             Static_Value : constant := E2'Pos (E2'Base'Last);
+> >         end G;
+> >         type E3 is new E1 with (Dd, Ee);
+> >         package I is new G (E2 => E3);
+> >
+> >    but on what basis? Does the definition of "static scalar
+> >    subtype" need to be changed (i.e. treat a formal derived
+> >    scalar type the same as a formal scalar type in 4.9(26)), or
+> >    should the matching rules of 12.5.1(7-10) be tightened up?
+
+> I don't get it. What's the problem here?
+> I.Static_Value is clearly 5 in this case.
+
+It is not ok if an expression in a generic is static and the
+corresponding expression in some instance has a different static
+value.
+
+This would lead to problems.
+
+Suppose, for example that you have something like
+
+    generic
+        ...
+    package G is
+        ...
+        Static_Value : constant := ... ;
+    end G;
+
+    package body G is
+        type T is array (Boolean) of Integer;
+
+        X : T := (False => ..., (Static_Value = 3) => ...);
+        Y : Integer := ... ;
+    begin
+        case Y is
+            when Integer'First .. 2 | 4 .. Integer'Last => ... ;
+            when Static_Value => ... ;
+        end case;
+    end G;
+
+This will compile successfully as long as G.Static_Value = 3.
+But what does this mean if you have some instantiation I, of G, such
+that I.Static_Value = 5?
+
+If "I.Static_Value is clearly 5" in my original example
+(or in a modified version where
+    type E2 is new E1;
+is replaced with
+    type E2 is new E1'Base;
+) then it seems like there is a problem.
+
+Making all scalar formal types non-static, rather than just
+"formal scalar types", would also solve some similar problems that
+have nothing to do with enumeration type extension. Perhaps that
+warrants a separate AI.
+
+--------
+
+From: Randy Brukardt, replying to Steve Baird
+Sent: 2/16/2001 10:38 PM
+
+> However, there is a (minor) problem if someone actually uses 'Base:
+>
+>  package Pkg1 is
+>	... as before...
+>      procedure Proc (X : E1'Base);
+>  end Pkg1;
+>  package Pkg2 is
+>      type E2 is new Pkg1.E1 with (Dd, Ee);
+>  end Pkg2;
+>
+> In this case, Proc would indeed get all of the literals, and that
+> might be surprising. I claim that if someone actually uses the
+> unconstrained type, they must have wanted anything possible, and thus
+> we still don't need to change the rule.
+
+A call to Pkg2.Proc passing in an extension value (e.g. Pkg2.Dd) will
+raise Constraint_Error.
+
+3.4(27): "the normal conversion of each actual parameter to the subtype
+of the corresponding formal parameter ... performs any necessary type
+conversion as well".
+
+Given this, it seems a bit odd that the parameter subtype would include
+the extension values.
+
+On the other hand, I don't see that it introduces any language definition
+problems (although implementing it would be annoying - it means that
+checking an actual parameter against the subtype of the formal is not
+enough and additional constraint checking is needed).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February 19, 2001 2:31 PM
+
+Steve Baird said:
+
+> Making all scalar formal types non-static, rather than just
+> "formal scalar types", would also solve some similar problems that
+> have nothing to do with enumeration type extension. Perhaps that
+> warrants a separate AI.
+
+I tend to agree (although I couldn't think of an example off-hand). Do you
+have an example of a problem that occurs without enumeration type extension?
+(If you do, then we probably do need an AI on this, as it would imply a bug
+in the language.)
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent