CVS difference for ais/ai-00362.txt

Differences between 1.10 and version 1.11
Log of other versions for file ais/ai-00362.txt

--- ais/ai-00362.txt	2005/06/16 23:47:35	1.10
+++ ais/ai-00362.txt	2005/10/31 05:18:37	1.11
@@ -118,10 +118,10 @@
 Change C.7.1(2) to
    package Ada.Task_Identification is
       pragma Preelaborate(Task_Identification);
-      type Task_ID is private;
+      type Task_Id is private;
       pragma Preelaborable_Initialization (Task_Id);
-      Null_Task_ID : constant Task_ID;
-      function  "=" (Left, Right : Task_ID) return Boolean;
+      Null_Task_Id : constant Task_Id;
+      function  "=" (Left, Right : Task_Id) return Boolean;
 
 Change D.5(3) to
    with System;
@@ -599,10 +599,10 @@
 @dby
 @xcode<@b<package> Ada.Task_Identification @b<is>
    @b<pragma> Preelaborate(Task_Identification);
-   @b<type> Task_ID @b<is private>;
+   @b<type> Task_Id @b<is private>;
    @b<pragma> Preelaborable_Initialization (Task_Id);
-   Null_Task_ID : @b<constant> Task_ID;
-   @b<function>  "=" (Left, Right : Task_ID) @b<return> Boolean;>
+   Null_Task_Id : @b<constant> Task_Id;
+   @b<function>  "=" (Left, Right : Task_Id) @b<return> Boolean;>
 
 !corrigendum D.5(03)
 
@@ -628,7 +628,7 @@
 
 @drepl
 @xcode<@b<with> Ada.Task_Identification;
-@b<package> Ada.Asynchronous_Task_Control is
+@b<package> Ada.Asynchronous_Task_Control @b<is>
    @b<procedure> Hold(T : @b<in> Ada.Task_Identification.Task_ID);
    @b<procedure> Continue(T : @b<in> Ada.Task_Identification.Task_ID);
    @b<function> Is_Held(T : Ada.Task_Identification.Task_ID)
@@ -636,11 +636,11 @@
 @b<end> Ada.Asynchronous_Task_Control;>
 @dby
 @xcode<@b<with> Ada.Task_Identification;
-@b<package> Ada.Asynchronous_Task_Control is
+@b<package> Ada.Asynchronous_Task_Control @b<is>
    @b<pragma> Preelaborate(Asynchronous_Task_Control);
-   @b<procedure> Hold(T : @b<in> Ada.Task_Identification.Task_ID);
-   @b<procedure> Continue(T : @b<in> Ada.Task_Identification.Task_ID);
-   @b<function> Is_Held(T : Ada.Task_Identification.Task_ID)
+   @b<procedure> Hold(T : @b<in> Ada.Task_Identification.Task_Id);
+   @b<procedure> Continue(T : @b<in> Ada.Task_Identification.Task_Id);
+   @b<function> Is_Held(T : Ada.Task_Identification.Task_Id)
       @b<return> Boolean;
 @b<end> Ada.Asynchronous_Task_Control;>
 
@@ -660,5 +660,371 @@
 Eilers (Irvine): Already Pure.
 Nielsen (DDCI): Already Pure.
 Brukardt (RRS): Categorization of built-in packages unchecked; effectively Pure.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, May 14, 2005  8:25 PM
+
+I really think it would be useful if Text_IO were Preelaborate.
+I don't buy at all Pascal's concern about difficulty of
+implementation. There is nothing to say that the run time
+has to be written in Ada, so rules about code generated
+in Preealborate units simply don't apply to the run-time,
+and an easy implmentation is just to suppress complaints
+in this context.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Sunday, May 15, 2005  2:36 AM
+
+For the record, and despite what the AI seems to imply, I was not
+particularly opposed to the notion of making the I/O units Preelaborable.
+I was just mentioning some of the implementation work that would be needed
+in our case.  It didn't seem terrible, but it seemed sizeable.
+
+We are trying to stay in touch with reality here.  There is nothing that
+says that the runtime has to be written in Ada, but if it is, then you
+have to cope with the elaboration rules somehow.  Simply suppressing
+complaints would in general not work in our technology.  I know because
+there are a few places where we do suppress complaints, and it bites us
+from time to time because the runtime or the predefined units start in an
+environment that is incompletely elaborated, and that wreaks havoc.
+
+The bottom line is that because significant rework was required in our
+implementation, and probably in others as well, the ARG felt uncomfortable
+with the change.  Note that only DDC/I and IBM Rational replied to the
+call for comments on implementation complexity, so it was hard to get a
+clear picture of the impact.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, May 15, 2005  6:20 AM
+
+Well from the GNAT point of view
+
+a) it is out of the question to implement AI-362 in pure Ada. Many of
+the units involved rely on elements of the tasking run time that most
+certainly need elaboration. Suppressing the diagnostics works fine.
+There is no guarantee that if you with a unit in the run time which
+is marked pragma Preelaborate that there will be no elaboration
+activity, since the behavior of the run time in such respects is out
+of scope for the standard (e.g. if the run time was written in C++,
+it would be fine to have constructors, since the Ada standard has
+nothing to say about constructors).
+
+b) It works just fine in GNAT to simply ignore the associated
+diagnostics. Of course it is the case that proper elaboration
+is required, but that falls out free if there are non-preelaborate
+units in the closure (the fact that they have been with'ed by
+preelaborate units is irrelevant for us).
+
+> The bottom line is that because significant rework was required in our
+> implementation, and probably in others as well, the ARG felt uncomfortable
+> with the change.  Note that only DDC/I and IBM Rational replied to the
+> call for comments on implementation complexity, so it was hard to get a
+> clear picture of the impact.
+
+I would like to see it at least allowed to make Text_IO preelaborate
+as implementatioun permission. You might worry that this causes non-
+portability, but in practice if you don't do this, then people end
+up using GNAT.IO in any case which is just as non-portable (GNAT.IO
+is a subset of Text_IO provided soley because of this preelaborate
+problem, which is pretty fierce in practice.
+
+It is quite reasonable to make a basic coding standard that all
+packages in an application be preealborate. In the absence of
+something like the GNAT model of static elaboration, it is a
+reasonable way to ensure freedom from the nightmare of elaboration
+problems so common in legacy Ada 83 applications. It is too bad if
+a decision like this, which is otherwise reasonable, makes it
+impossible to use Text_IO.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, May 15, 2005  4:15 PM
+
+...
+> a) it is out of the question to implement AI-362 in pure Ada. Many of
+> the units involved rely on elements of the tasking run time that most
+> certainly need elaboration.
+
+I can believe the last statement, but I don't see how it has anything to do
+with AI-362. The tasking system clearly has to be available for Pure and
+Preelaborated units (as they both allow the declaration of task objects), so
+either they have to be elaborated early (with some sort of permission), or
+they have to be completely outside of the Ada system. The whole reason that
+we felt comfortable requiring most of the tasking units to be Preelaborated
+is that already has to be true.
+
+...
+> > The bottom line is that because significant rework was required in our
+> > implementation, and probably in others as well, the ARG felt uncomfortable
+> > with the change.  Note that only DDC/I and IBM Rational replied to the
+> > call for comments on implementation complexity, so it was hard to get a
+> > clear picture of the impact.
+>
+> I would like to see it at least allowed to make Text_IO preelaborate
+> as implementatioun permission. You might worry that this causes non-
+> portability, but in practice if you don't do this, then people end
+> up using GNAT.IO in any case which is just as non-portable (GNAT.IO
+> is a subset of Text_IO provided soley because of this preelaborate
+> problem, which is pretty fierce in practice.
+>
+> It is quite reasonable to make a basic coding standard that all
+> packages in an application be preealborate. In the absence of
+> something like the GNAT model of static elaboration, it is a
+> reasonable way to ensure freedom from the nightmare of elaboration
+> problems so common in legacy Ada 83 applications. It is too bad if
+> a decision like this, which is otherwise reasonable, makes it
+> impossible to use Text_IO.
+
+My experience is that because of Text_IO/Stream_IO and Calendar, essentially
+nothing can be made Preelaborated. I would have liked to require all of
+those to be Preelaborated, but the implementation complexity seems to be
+significant in all cases. (I have no idea how to deal with
+Current_Input/Current_Output without using initialization at elaboration.)
+Anyway, there wasn't sufficient support for a change.
+
+Moreover, it is really late right now. The last time this subject was
+discussed (Feb. 2004), you (Robert Dewar) tried to get us to adopt something
+like GNAT.IO. That idea was still-born, probably because there was no
+agreement on what such a package ought to contain. If you had instead tried
+then to push for a Preelaborable Text_IO, we would have had time to properly
+study the idea. But it's way too late to do that now. All of the runtimes
+that were studied (and there were four) would have had substantial work to
+support a preelaborable Text_IO.
+
+My personal feeling is that an Implementation Permission would be even a
+harder sell. Moreover, it doesn't seem necessary; the default mode of a
+compiler could certainly allow that (certainly Gnat has not been shy about
+deviating from the Standard by default when it seems valuable). And I doubt
+that there are going to be ACATS tests checking that you *can't* use Text_IO
+in a preelaborated unit! I'm certain that any effort spent will be on
+ensuring that you *can* use Ada.Exceptions, etc. in a preelaborated unit.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, May 15, 2005  4:45 PM
+
+>>a) it is out of the question to implement AI-362 in pure Ada. Many of
+>>the units involved rely on elements of the tasking run time that most
+>>certainly need elaboration.
+
+> I can believe the last statement, but I don't see how it has anything to do
+> with AI-362. The tasking system clearly has to be available for Pure and
+> Preelaborated units (as they both allow the declaration of task objects), so
+> either they have to be elaborated early (with some sort of permission), or
+> they have to be completely outside of the Ada system. The whole reason that
+> we felt comfortable requiring most of the tasking units to be Preelaborated
+> is that already has to be true.
+
+Right, so that just goes to show that it does not matter whether or not
+things can be implemented in pure Ada or not. The run time can always be
+considered to be completely outside the Ada system, even if it appears
+to a casual eye to be implemented in Ada. It is always allowed to implement
+the run time in Ada++ where you get to decide the ++ :-)
+
+> My experience is that because of Text_IO/Stream_IO and Calendar, essentially
+> nothing can be made Preelaborated. I would have liked to require all of
+> those to be Preelaborated, but the implementation complexity seems to be
+> significant in all cases. (I have no idea how to deal with
+> Current_Input/Current_Output without using initialization at elaboration.)
+> Anyway, there wasn't sufficient support for a change.
+
+There is zero implementation difficulty, just ignore categorization errors
+in the run-time, there is no RM requirement for such checks, and there is
+no requirement that the executable file not have any initialization at
+elaboration, since the RM cannot talk about code written in a language
+other than Ada.
+
+> Moreover, it is really late right now. The last time this subject was
+> discussed (Feb. 2004), you (Robert Dewar) tried to get us to adopt something
+> like GNAT.IO. That idea was still-born, probably because there was no
+> agreement on what such a package ought to contain. If you had instead tried
+> then to push for a Preelaborable Text_IO, we would have had time to properly
+> study the idea. But it's way too late to do that now. All of the runtimes
+> that were studied (and there were four) would have had substantial work to
+> support a preelaborable Text_IO.
+
+For us it would be zero effort
+
+> My personal feeling is that an Implementation Permission would be even a
+> harder sell. Moreover, it doesn't seem necessary; the default mode of a
+> compiler could certainly allow that (certainly Gnat has not been shy about
+> deviating from the Standard by default when it seems valuable).
+
+Hey, I don't know ANY cases where we have deviated from the standard. That's
+a serious charge, and should not be thrown around lightly. Please retract
+it or say what you mean. We have no deliberate deviations of this kind
+from the standard
+in GNAT and I am completely shocked that you would charge us
+with duplicity (obviously we could not validate if we had known deliberate
+deviations from the standard).
+
+Now of course we could have a switch. In fact I guess the most useful form
+of that switch would be to allow ANY unit in the run time to be with'ed
+from a Pure or Preelaborate unit, but that would not be a deviation from
+the standard.
+
+> And I doubt
+> that there are going to be ACATS tests checking that you *can't* use Text_IO
+> in a preelaborated unit! I'm certain that any effort spent will be on
+> ensuring that you *can* use Ada.Exceptions, etc. in a preelaborated unit.
+
+Sorry, we are not in the business of this kind of deliberate deviation. And I
+would severely criticize any implementor who took this kind of casual attitude
+that it is OK to deviate deliberately since the ACATS does not test for it.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, May 15, 2005  5:23 PM
+
+...
+> > My personal feeling is that an Implementation Permission would be even a
+> > harder sell. Moreover, it doesn't seem necessary; the default mode of a
+> > compiler could certainly allow that (certainly Gnat has not been shy about
+> > deviating from the Standard by default when it seems valuable).
+>
+> Hey, I don't know ANY cases where we have deviated from the standard. That's
+> a serious charge, and should not be thrown around lightly. Please retract
+> it or say what you mean. We have no deliberate deviations of this kind
+> from the standard
+> in GNAT and I am completely shocked that you would charge us
+> with duplicity (obviously we could not validate if we had known deliberate
+> deviations from the standard).
+
+Sorry if I confused you, but I was *very* careful in what I said. The
+"default mode" certainly doesn't have to be the "standard mode". If a
+compiler deviated in "standard mode", that would be a bad thing; but I said
+nor meant such a thing. I very carefully said "default mode". And the
+"default mode" of GNAT deviates in a number of ways - off the top of my
+head:
+  * GNAT defaults to its "static elaboration model", which means that it
+will not compile some legal, correct Ada programs without a switch;
+  * GNAT does not check for integer overflow by default, so some programs do
+things not allowed by the standard at runtime (unless a switch is used).
+
+Since GNAT has done these things by default, it certainly be possible to
+treat Text_IO as preelaborated by default, and have a switch to get to
+"standard mode" (a switch that would be a lot less necessary than -gnatE
+or -gnatO). That would get the effect of an Implementation Permission
+without having successfully herding the cats of the ARG.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, May 15, 2005  5:40 PM
+
+> Sorry if I confused you, but I was *very* careful in what I said. The
+> "default mode" certainly doesn't have to be the "standard mode". If a
+> compiler deviated in "standard mode", that would be a bad thing; but I said
+> nor meant such a thing. I very carefully said "default mode". And the
+> "default mode" of GNAT deviates in a number of ways - off the top of my
+> head:
+>   * GNAT defaults to its "static elaboration model", which means that it
+> will not compile some legal, correct Ada programs without a switch;
+>   * GNAT does not check for integer overflow by default, so some programs do
+> things not allowed by the standard at runtime (unless a switch is used).
+
+Oh sure, if you are just making a comment about default options, that's true,
+but irrelevant to real users, who set the options they want in their project
+files in any case.
+>
+> Since GNAT has done these things by default, it certainly be possible to
+> treat Text_IO as preelaborated by default, and have a switch to get to
+> "standard mode" (a switch that would be a lot less necessary than -gnatE
+> or -gnatO). That would get the effect of an Implementation Permission
+> without having successfully herding the cats of the ARG.
+
+Perhaps, not clear this is a good idea.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Sunday, May 15, 2005  5:41 PM
+
+> > My personal feeling is that an Implementation Permission would be even a
+> > harder sell. Moreover, it doesn't seem necessary; the default mode of a
+> > compiler could certainly allow that (certainly Gnat has not been shy about
+> > deviating from the Standard by default when it seems valuable).
+                                ^^^^^^^^^^
+> Hey, I don't know ANY cases where we have deviated from the standard. That's
+> a serious charge, and should not be thrown around lightly.
+
+Note that Randy said "by default".  He's not accusing GNAT of malfeasance.
+
+For example, I believe GNAT omits overflow checks by default.  If you
+want standard conformance, you have to say "-gnato" or something.
+The gnatmake command, without -gnato, does not properly conform to the
+Ada standard.  No big deal, because *with* -gnato (and maybe some other
+switches) it *does* conform (modulo some unintended bugs, perhaps).
+
+>...Please retract
+> it or say what you mean. We have no deliberate deviations of this kind
+> from the standard
+> in GNAT and I am completely shocked that you would charge us
+> with duplicity (obviously we could not validate if we had known deliberate
+> deviations from the standard).
+
+No charge of duplicity here -- just the observation that GNAT's
+*standard* mode is not the *default* mode.
+
+> Now of course we could have a switch. In fact I guess the most useful form
+> of that switch would be to allow ANY unit in the run time to be with'ed
+> from a Pure or Preelaborate unit, but that would not be a deviation from
+> the standard.
+
+Agreed.  I think that's all Randy meant.  Plus the fact that you
+(AdaCore) can freely choose whether to make this non-standard mode the
+default, or not.  I would advise "not".
+
+> Sorry, we are not in the business of this kind of deliberate deviation. And I
+> would severely criticize any implementor who took this kind of casual attitude
+> that it is OK to deviate deliberately since the ACATS does not test for it.
+
+Hear, hear!  I would say, that if there's a significant chance that some
+implementer will violate the rule (either by accident or on purpose),
+then an ACATS test is valuable (to encourage portability, at least in
+the standard mode).
+
+I will be happy if Text_IO is preelab, or if it's not preelab, in the
+RM.  But I don't much like an "implementation permission" which says it
+can be preelab or not, according to implementer's whim.  The point of
+standards is portability, so I prefer nailing down the semantics, when
+possible.
+
+I have no complaint about the fact that "gcc [switches] foo.adb" obeys
+the Ada standard, whereas "gcc foo.c" grossly violates the Ada standard!
+
+****************************************************************
+
+From: Robert I. Eachus
+Sent: Sunday, May 15, 2005  6:06 PM
+
+>Since GNAT has done these things by default, it certainly be possible to
+>treat Text_IO as preelaborated by default, and have a switch to get to
+>"standard mode" (a switch that would be a lot less necessary than -gnatE
+>or -gnatO). That would get the effect of an Implementation Permission
+>without having successfully herding the cats of the ARG.
+
+ Much, much easier to create a 'non-standard' package say, Gnat.Text_IO
+that is preelaborated.  This should take just a few minutes if the
+source of Text_IO is compatible with pragma Preelaborate.  (Just cut and
+paste.)  But this doesn't address the bigger concern that it would be
+nice for all programmers to be able to assume that Text_IO could be
+called from preelaborated units.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, May 15, 2005  6:31 PM
+
+That's what GNAT.IO is about :-)
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent