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

Differences between 1.6 and version 1.7
Log of other versions for file ai05s/ai05-0170-1.txt

--- ai05s/ai05-0170-1.txt	2010/10/19 03:51:18	1.6
+++ ai05s/ai05-0170-1.txt	2010/10/20 23:41:52	1.7
@@ -1,4 +1,4 @@
-!standard  D.14(9/2)                                10-10-07    AI05-0170-1/05
+!standard  D.14(9/2)                                10-10-20    AI05-0170-1/06
 !standard  D.14(11/2)
 !standard  D.14(13/2)
 !standard  D.14(18/2)
@@ -14,7 +14,7 @@
 
 !summary
 
-Facilities are added to enable the time spent in interrupt handlers to be 
+Facilities are added to enable the time spent in interrupt handlers to be
 accounted for separately from time spent in tasks.
 
 !problem
@@ -114,18 +114,18 @@
 
 with Ada.Interrupts;
 package Ada.Execution_Time.Interrupts is
-   function Clock (I : Ada.Interrupts.Interrupt_ID)
+   function Clock (Interrupt : Ada.Interrupts.Interrupt_Id)
         return CPU_Time;
-   function Supported (I : Ada.Interrupts.Interrupt_ID)
+   function Supported (Interrupt : Ada.Interrupts.Interrupt_Id)
         return Boolean;
 end Ada.Execution_Time.Interrupts;
 
-The execution time or CPU time of a given interrupt I is defined as the time
-spent by the system executing interrupt handlers identified by I, including
-the time spent executing run-time or system services on its behalf.
-The mechanism used to measure execution time is implementation defined.
-Time spent executing interrupt handlers is distinct from time spent
-executing any task.
+The execution time or CPU time of a given interrupt Interrupt is defined as the
+time spent by the system executing interrupt handlers identified by Interrupt,
+including the time spent executing run-time or system services on its behalf.
+The mechanism used to measure execution time is implementation defined. Time
+spent executing interrupt handlers is distinct from time spent executing any
+task.
 
 For each interrupt, the execution time value is initially set to zero.
 
@@ -133,13 +133,14 @@
 Dynamic Semantics
 
 The function Clock returns the current cumulative execution time of the
-interrupt identified by I. If Separate_Interrupt_Clocks_Supported is
+interrupt identified by Interrupt. If Separate_Interrupt_Clocks_Supported is
 set to False the function raises Program_Error.
 
-The function Supported returns True if the implementation is monitoring
-the execution time of the interrupt identified by I. Otherwise it returns
-False. For any interrupt_Id I for which Supported(I) returns False, the
-function Clock(I) will return a value equal to Ada.Execution_Time.Time_Of(0).
+The function Supported returns True if the implementation is monitoring the
+execution time of the interrupt identified by Interrupt. Otherwise it returns
+False. For any interrupt_Id Interrupt for which Supported(Interrupt) returns
+False, the function Clock(Interrupt) will return a value equal to
+Ada.Execution_Time.Time_Of(0).
 
 
 !discussion
@@ -169,7 +170,7 @@
 such as Set_Priority would need to treat them as a special case,
 adding the need for new checks in potentially many places.
 
-We believe that using Interrupt_ID for identifying the execution time
+We believe that using Interrupt_Id for identifying the execution time
 clocks is compatible with the proposed approach for attaching
 interrupts to a specific processor in multiprocessor systems. It seems
 that using pseudo-task IDs instead would require defining these for
@@ -371,31 +372,32 @@
 
 @xcode<@b<with> Ada.Interrupts;
 @b<package> Ada.Execution_Time.Interrupts @b<is>
-   @b<function> Clock (I : Ada.Interrupts.Interrupt_ID)
+   @b<function> Clock (Interrupt : Ada.Interrupts.Interrupt_Id)
         @b<return> CPU_Time;
-   @b<function> Supported (I : Ada.Interrupts.Interrupt_ID)
+   @b<function> Supported (Interrupt : Ada.Interrupts.Interrupt_Id)
         @b<return> Boolean;
 @b<end> Ada.Execution_Time.Interrupts;>
 
-The execution time or CPU time of a given interrupt I is defined as the time
-spent by the system executing interrupt handlers identified by I, including
-the time spent executing run-time or system services on its behalf.
-The mechanism used to measure execution time is implementation defined.
-Time spent executing interrupt handlers is distinct from time spent
-executing any task.
+The execution time or CPU time of a given interrupt Interrupt is defined as the
+time spent by the system executing interrupt handlers identified by Interrupt,
+including the time spent executing run-time or system services on its behalf.
+The mechanism used to measure execution time is implementation defined. Time
+spent executing interrupt handlers is distinct from time spent executing any
+task.
 
 For each interrupt, the execution time value is initially set to zero.
 
 @s8<@i<Dynamic Semantics>>
 
 The function Clock returns the current cumulative execution time of the
-interrupt identified by I. If Separate_Interrupt_Clocks_Supported is
+interrupt identified by Interrupt. If Separate_Interrupt_Clocks_Supported is
 set to False the function raises Program_Error.
 
-The function Supported returns True if the implementation is monitoring
-the execution time of the interrupt identified by I. Otherwise it returns False.
-For any interrupt_Id I for which Supported(I) returns False, the function Clock(I)
-will return a value equal to Ada.Execution_Time.Time_Of(0).
+The function Supported returns True if the implementation is monitoring the
+execution time of the interrupt identified by Interrupt. Otherwise it returns
+False. For any interrupt_Id Interrupt for which Supported(Interrupt) returns
+False, the function Clock(Interrupt) will return a value equal to
+Ada.Execution_Time.Time_Of(0).
 
 
 !ACATS test
@@ -404,6 +406,213 @@
 
 
 !appendix
+
+From: Randy Brukardt
+Sent: Tuesday, October 19, 2010  7:06 PM
+
+Brad Moore sent an editorial comment on AI05-0170-1:
+
+>!wording and !corrigendum sections:
+>
+>Replace the "I" of "Ada.Interrupts.Interrupt_ID" with "Interrupt" to be
+>consistent with the rest on the RM (such as C.3.2)
+
+I tend to agree with this comment, but as it is a significant amount of work to change ("I" appears throughout the wording of this AI, and I'll also have to update the RM draft, and of course search and replace won't do any good for "I"), I wanted to chec
k if there were any objections before proceeding with the change. If there are any, I'll put the AI on the agenda for Fairfax, and we can decide what to do then.
+
+****************************************************************
+
+From: Alan Burns
+Sent: Wednesday, October 20, 2010  3:02 AM
+
+  I feel
+
+Interrupt : Ada.Interrupts.Interrupt_ID
+
+has just too many interrupts - my vote would be to keep it as I
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, October 20, 2010  6:43 AM
+
+I would change to Interrupt. I personally dislike ANY use of the identifier I (we don't allow it in our style guidelines), because depending on the font, it can be far to close to the digit 1.
+
+Of course one of the extra Interrupts comes from the entirely unnecessary qualification. A name like Interrupt_Id is designed IMO to be used with use clauses. You want either
+
+   Interrupts.ID
+
+if you are not going to use USE clauses, or
+
+   Interrupt_ID
+
+if you are going to use USE clauses.
+
+Interrupt.Interrupt_Id is plain annoying in itself
+
+****************************************************************
+
+From: Bob Duff
+Sent: Wednesday, October 20, 2010  8:14 AM
+
+>   I feel
+>
+> Interrupt : Ada.Interrupts.Interrupt_ID
+>
+> has just too many interrupts - my vote would be to keep it as I
+
+Alan was about to type " eschew redundancy.", but he was Interrupted by martians who snatched him from the keyboard in midsenten
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, October 20, 2010  1:08 PM
+
+...
+> I would change to Interrupt. I personally dislike ANY use of the
+> identifier I (we don't allow it in our style guidelines), because
+> depending on the font, it can be far to close to the digit 1.
+
+Our guidelines only allow I to be used as a for loop index. Since I started programming in FORTRAN, I get uncomfortable with loop indexes that aren't "I", then "J", then "K". :-)  But in other circumstances, I agree with Robert.
+
+After all, one of the important uses of parameter names is in calls. Which would you rather see in code:
+
+     Clock (I => Overflow);
+
+or
+
+
+     Clock (Interrupt => Overflow);
+
+???
+
+> Of course one of the extra Interrupts comes from the entirely
+> unnecessary qualification. A name like Interrupt_Id is designed IMO to
+> be used with use clauses. You want either
+>
+>    Interrupts.ID
+>
+> if you are not going to use USE clauses, or
+>
+>    Interrupt_ID
+>
+> if you are going to use USE clauses.
+>
+> Interrupt.Interrupt_Id is plain annoying in itself
+
+Ada library packages almost never use "use" clauses, but generally they are designed so it doesn't matter. (Either the declarations are local or they are in parents.) In this case, there are only two uses, so it probably would be more confusing than helpf
ul to use a "use" clause.
+
+As to the general problem of naming, it's unfortunate that it is so hard to find good names that work both ways. When you are building a general purpose library, you really don't want to be making that decision for clients. We struggled with this with Cla
w, and there are places where we ended up with some redundancy (mostly for the type declarations) because the alternative was names that couldn't be meaningfully used with use clauses. (Just because I don't like or use use clauses much doesn't mean I want 
to make it hard for those who do.)
+
+P.S. What to do here?? So far, we have 3 votes to change to Interrupt and one to stay as I. Please weight in if you care at all (else this will have to go back to the ARG to make a decision).
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, October 20, 2010  1:54 PM
+
+> Our guidelines only allow I to be used as a for loop index. Since I
+> started programming in FORTRAN, I get uncomfortable with loop indexes
+> that aren't "I", then "J", then "K". :-)  But in other circumstances,
+> I agree with Robert.
+
+I start at J, and Fortran allows you to go further than K if you have to :-)
+
+****************************************************************
+
+From: Bob Duff
+Sent: Wednesday, October 20, 2010  1:20 PM
+
+> ...Please weight in if you care at all (else this will have to go back
+> to the ARG to make a decision).
+
+I slightly prefer Interrupt.
+
+I'd prefer you flip a coin, over having a big discussion at an ARG meeting.  ;-)
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Wednesday, October 20, 2010  1:40 PM
+
+> After all, one of the important uses of parameter names is in calls.
+> Which would you rather see in code:
+>
+>      Clock (I => Overflow);
+>
+> or
+>
+>
+>      Clock (Interrupt => Overflow);
+>
+> ???
+
+I definitely prefer the latter.
+
+> P.S. What to do here?? So far, we have 3 votes to change to Interrupt
+> and one to stay as I. Please weight in if you care at all (else this
+> will have to go back to the ARG to make a decision).
+
+I vote for changing to Interrupt.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, October 20, 2010  1:56 PM
+
+Well we have 4-1 vote for interrupt, which I would say is decisive unless there is a last minute groundswell of s support for I :)
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Wednesday, October 20, 2010  2:00 PM
+
+> ...Please weight in if you care at all (else this will have to go back
+> to the ARG to make a decision).
+
+Ban the I, go with Interrupt.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, October 20, 2010  2:03 PM
+
+sounds like an executive decision from the chair to me :-)
+
+****************************************************************
+
+From: Steve Baird
+Sent: Wednesday, October 20, 2010  2:08 PM
+
+> Ban the I, go with Interrupt.
+Agreed.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Wednesday, October 20, 2010  3:51 PM
+
+Count me for Interrupt too. I think that named notation in calls is the strongest argument.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Wednesday, October 20, 2010  5:09 PM
+
+Count me for "Interrupt".
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, October 20, 2010  5:36 PM
+
+I think we can count this as decided!
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, October 20, 2010  6:02 PM
+
+I agree. Consider this issue closed; I'll update the AI and draft RM accordingly and send the AI on to WG 9.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent