CVS difference for ai05s/ai05-0092-1.txt

--- ai05s/ai05-0092-1.txt	2011/01/28 02:58:11	1.15
+++ ai05s/ai05-0092-1.txt	2011/01/29 06:14:08	1.16
@@ -1,8 +1,10 @@
-!standard  3.3.1(20.4/2)                             11-01-27  AI05-0092-1/13
+!standard  3.3.1(20.4/2)                             11-01-28  AI05-0092-1/14
 !standard  3.3.1(23)
 !standard  3.9(25.1/2)
 !standard  6.3.1(21.1/2)
 !standard  7.6(9.3/2)
+!standard  9.6(6)
+!standard  9.6(8)
 !standard  9.6(22)
 !standard 13.3(75/1)
 !standard 13.13.2(55/2)
@@ -74,6 +76,8 @@
 
 18) Replace "P" in D.14.2(4/3) and D.14.2(21/3).
 
+19) Ada.Real_Time.Time is a time-type.
+
 !question
 
 1) Generally, "must" shall not be used in normative rules of the standard. However,
@@ -131,6 +135,17 @@
 representating a processor. AI05-0169-1 uses "P" instead. Should these be the
 same? (Yes.)
 
+19) The second sentence of 9.6(6) (a Legality Rule) says, "The type of the
+delay_expression in a delay_until_statement shall be a time
+type--either the type Time defined in the language-defined package
+Calendar (see below), or some other implementation-defined time type
+(see D.8)."
+
+Ada.Real_Time.Time is supposed to be one of those possible
+time types (and D.8(18) says so explicitly), but since it's defined by
+the language, it isn't "implementation-defined", so strictly speaking
+this rule doesn't allow it. Should this be fixed? (Yes.)
+
 [Other questions here.]
 
 !recommendation
@@ -192,6 +207,12 @@
 18) Replace "P" by "CPU" in D.14.2(4/3) and replace
 "processor P" by "CPU" in D.14.2(21/3).
 
+19) Modify 9.6(6) as "... package Calendar (see below), 
+{the type Time in the package Real_Time (see D.8), } or some other implementation-defined
+time type[(see D.8)]."
+
+Delete "implementation-defined" from 9.6(8).
+
 !discussion
 
 1) 3.3.1(20.4/2) uses "must precede", while 3.3.1(20.1-3/2) use "is preceded by".
@@ -254,6 +275,37 @@
 
 18) These two AIs should use similar names.
 
+19) Clearly, Real_Time.Time is supposed to be a time type. There is even a
+cross-reference in the rule in question - but it isn't implementation-defined.
+Since the cross-reference is already there, we might as well go all the way and
+identify the type, too, and then we don't need to weasel about what we mean.
+
+OTOH, this will make the language a bit more fragile; if another language-defined
+time type is ever created, we'd need to update this paragraph again.
+
+An alternative that we considered was to simply echo 9.5.1(18):
+
+"... package Calendar (see below), or some other type that is identified as a
+time type where it is defined (see D.8)."
+
+This isn't as fragile, but no longer includes the indication that
+implementation-defined time types are expected. Moreover, the cross-reference
+is still mysterious.
+
+We could also just add language defined to the existing rule:
+
+"... package Calendar (see below), or some other language-defined or
+implementation-defined time type (see D.8)."
+
+but here the cross-reference seems to associate with "implementation-defined"
+which makes no sense. Reversing the two hyphenated terms fixes that, but then
+they are in a weird order.
+
+So we chose the wording given above.
+
+Note that we also fix 9.6(8). There is no need to mention where the time type is
+defined in this sentence, so we just drop it.
+
 !corrigendum 3.3.1(20.4/2)
 
 @drepl
@@ -320,6 +372,29 @@
 @dby
 @xbullet<it has a component whose type needs finalization; or>
 
+!corrigendum 9.6(6)
+
+@drepl
+There can be multiple time bases, each with a corresponding clock, and a corresponding @i<time
+type>. The type of the @i<delay_>@fa<expression> in a @fa<delay_until_statement> shall be a
+time type @emdash either the type Time defined in the language-defined package Calendar
+(see below), or some other implementation-defined time type (see D.8).
+@dby
+There can be multiple time bases, each with a corresponding clock, and a corresponding @i<time
+type>. The type of the @i<delay_>@fa<expression> in a @fa<delay_until_statement> shall be a
+time type @emdash either the type Time defined in the language-defined package Calendar
+(see below), the type Time in the package Real_Time (see D.8), or some other
+implementation-defined time type.
+
+!corrigendum 9.6(8)
+
+@drepl
+A value of the type Time in package Calendar, or of some other implementation-defined time type,
+represents a time as reported by a corresponding clock.
+@dby
+A value of the type Time in package Calendar, or of some other time type,
+represents a time as reported by a corresponding clock.
+
 !corrigendum 9.6(22)
 
 @drepl
@@ -1280,3 +1355,25 @@
 
 ****************************************************************
 
+!topic Mistake in "delay until" legality rule
+!reference 9.6(6)
+!from Adam Beneschan 10-12-16
+!discussion
+
+This came up from a comp.lang.ada thread and was noticed by "BrianG".
+The second sentence of 9.6(6) (a Legality Rule) says, "The type of the
+delay_expression in a delay_until_statement shall be a time
+type--either the type Time defined in the language-defined package
+Calendar (see below), or some other implementation-defined time type
+(see D.8)."
+
+Obviously, Ada.Real_Time.Time is supposed to be one of those possible
+time types (and D.8(18) says so explicitly), but since it's defined by
+the language, it can't really be considered "implementation-defined",
+and thus it isn't allowed by a literal reading of 9.6(6).  I recommend
+changing the last phrase of 9.6(6) to "or some other language-defined
+or implementation-defined time type (see D.8)."
+
+Maybe this can be dumped into AI05-0092.
+
+****************************************************************