CVS difference for ais/ai-00261.txt

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

--- ais/ai-00261.txt	2001/02/23 20:43:09	1.5
+++ ais/ai-00261.txt	2001/03/22 22:24:53	1.6
@@ -54,17 +54,14 @@
 literal of the parent type. Each literal in the extension part shall be
 distinct from any literal inherited from the parent type.
 
+Parent_enumeration_subtype_mark shall denote an enumeration subtype,
+but not a formal derived enumeration type, nor a boolean type (see 3.5.3(1)).
+
 If parent_enumeration_subtype_mark denotes a first subtype, then the first
 subtype of a enumeration extension type is constrained to the base range of
 the type. Otherwise, the first subtype has the same constraint as the
 parent_enumeration_subtype_mark.
 
-The parent_enumeration_subtype_mark shall not denote a formal derived
-enumeration type.
-
-The parent_enumeration_subtype_mark shall not denote a Boolean type (see
-3.5.3(1)).
-
 Type conversions between an enumeration extension type and its parent are
 allowed. For a conversion from the extension to the parent, a check is made
 that the value belong to the parent type. Constraint_Error is raised if this
@@ -3055,6 +3052,79 @@
 their bounds were identical at run time.  Of course, this sort of behavior
 would occur for the "first named subtype" rule, but it seems less
 disturbing because the rule is frank about making a special case.
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Saturday, February 24, 2001 5:08 PM
+
+> 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), ...
+
+It may well be a language design error, but it was not an oversight.  It
+was entirely deliberate.  (Here, "language design error" = too much
+implementation trouble for too little benefit.)
+
+****************************************************************
+
+From: dewar@gnat.com
+Sent: Saturday, February 24, 2001 9:19 PM
+
+I am REALLY suprised to hear Bob say that. This is so clearly a MAJOR
+implementation difficulty. One can only hope that whoever did this
+"entirely deliberately" did not realize the implementation difficulty
+that was being caused.
+
+I would say that implementing LOGICAL right is considerably more work
+than implementing the entire remaining facilities of Interfaces.FORTRAN,
+all of which are trivial with this exception.
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Sunday, February 25, 2001 9:11 AM
+
+> Treat Boolean specially and don't allow extension. After all we don't
+> require even that rep clauses for Boolean be supported.
+
+Fine with me, so long as the generic contract problems are eliminated.
+
+Also, I suppose there are private-part contract problems to worry about:
+Eg, you derive from a private type (or from a type derived from a
+private type), and you may or may not later find out that the thing is
+"really" a boolean type (immediately within the immediate scope of blah
+blah blah, as 7.3.1 says).
+
+Historical note: There was a version of Ada (around 1981?) that
+disallowed deriving from Boolean.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February 26, 2001 4:13 PM
+
+> Fine with me, so long as the generic contract problems are eliminated.
+
+That's not a real problem: we already have to disallow any enumeration
+extension from formal types (at least in the generic body) to handle other
+problems; so this one rides along for free. (That makes this solution the
+preferred one, and I've revised the write-up accordingly.)
+
+> Also, I suppose there are private-part contract problems to worry about:
+> Eg, you derive from a private type (or from a type derived from a
+> private type), and you may or may not later find out that the thing is
+> "really" a boolean type (immediately within the immediate scope of blah
+> blah blah, as 7.3.1 says).
+
+You can't do an enumeration extension from a private type; the item has to
+be an enumeration type. And there isn't a way that I know of to get an
+enumeration type without know whether or not it is Boolean. (I suppose one
+could imagine private enumeration extensions, but they're not in the
+proposal I wrote up. Even if you had those, I don't think there is a
+problem, because the full type would have to be enumeration type.)
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent