CVS difference for ais/ai-00172.txt

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

--- ais/ai-00172.txt	2000/08/18 19:44:11	1.3
+++ ais/ai-00172.txt	2000/10/05 02:47:30	1.4
@@ -446,3 +446,152 @@
 portability problems.
 
 ****************************************************************
+
+From: Robert A Duff
+Sent: Monday, August 28, 2000 8:49 AM
+
+This !summary is wrong:
+
+> A main subprogam is optional -- the implementation may provide
+> a way to create and run an active partition without a main
+> subprogram.
+
+In the above, "may" should be "must".
+
+"Optional" means that the user is allowed to use the feature or not, at
+the user's option.  It does *not* mean that the implementer can choose
+not to support it.
+
+Example: the initialization expression in a variable declaration is
+"optional".  This means the user can write "X: Integer := 123;" or just
+"X: Integer;".  The user has the choice; the implementation *must*
+support both.
+
+The same is true of optional main subprograms: the user may choose to
+have one, or not.  The implementation *must* support both possibilities.
+To me, the RM is crystal clear on this point (it says, "The *user* can
+optionally designate...").
+
+I admit that this feature (the ability not to have a main subprogram) is
+somewhat silly.  But the RM clearly requires implementations to support
+it.  If the ARG changes that, it shouldn't be called a "confirmation" --
+it's a language change (ie binding interpretation).  There are
+interactions with the DS annex, if that path is chosen.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, August 28, 2000 1:34 PM
+
+> This !summary is wrong:
+>
+> > A main subprogam is optional -- the implementation may provide
+> > a way to create and run an active partition without a main
+> > subprogram.
+>
+> In the above, "may" should be "must".
+
+This change is directly from the minutes of the March 1999 ARG meeting. As I
+recall, you were at the meeting at the time (it was at Averstar), and certainly
+you made all of the points you make below...
+
+Legalistically, I agree with you, but I wasn't willing to ignore the resolutions
+from an ARG meeting.
+
+> "Optional" means that the user is allowed to use the feature or not, at
+> the user's option.  It does *not* mean that the implementer can choose
+> not to support it.
+>
+> Example: the initialization expression in a variable declaration is
+> "optional".  This means the user can write "X: Integer := 123;" or just
+> "X: Integer;".  The user has the choice; the implementation *must*
+> support both.
+>
+> The same is true of optional main subprograms: the user may choose to
+> have one, or not.  The implementation *must* support both possibilities.
+> To me, the RM is crystal clear on this point (it says, "The *user* can
+> optionally designate...").
+>
+> I admit that this feature (the ability not to have a main subprogram) is
+> somewhat silly.  But the RM clearly requires implementations to support
+> it.  If the ARG changes that, it shouldn't be called a "confirmation" --
+> it's a language change (ie binding interpretation).  There are
+> interactions with the DS annex, if that path is chosen.
+
+So far s I can tell, the feature should only be required for implementations
+supporting the DS annex. Such an implementation needs a complex mechanism to
+choose the contents of a partition. Other implementations probably simply use
+the closure of the main subprogram to choose the contents of the program
+partition.
+
+Supporting no main subprogram requires some other method to select the contents
+of the program. One possibility is to designate some package as the main for the
+purposes of closure -- but this offers no benefit over having an empty main
+subprogram withing that package. We couldn't have been intending all
+implementations to support some sort of partitioning tool even if they don't
+support the DS annex. So the feature is not just silly; it makes vendors spend
+no-benefit effort.
+
+So, call it what we may, but I don't think we should be requiring this unless
+the DS annex is supported. I'd be happy to call it a BI, and add a line to the
+DS annex saying that it must support no main subprogram partitions. That would
+be pretty simple to do. Or we can leave it as it is.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, August 28, 2000 11:10 AM
+
+<<I admit that this feature (the ability not to have a main subprogram) is
+somewhat silly.  But the RM clearly requires implementations to support
+it.  If the ARG changes that, it shouldn't be called a "confirmation" --
+it's a language change (ie binding interpretation).  There are
+interactions with the DS annex, if that path is chosen.
+>>
+
+Furthermore, an implementation can support this simply be requiring a user
+to create a dummy main program, called a DUMMY_PROGRAM instead of a
+MAIN_PROGRAM (to stay legalisticailly) correct, so it is a silly requirement.
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Monday, August 28, 2000 5:54 PM
+
+Formally speaking, quite true.
+
+But also formally speaking, an implementation can require the user to
+type in the appropriate machine language, as the only way of invoking
+the compiler.  ;-) Shall we say implementations need not do anything at
+all, on the grounds that they could have required the user to type in
+the actual machine code as part of invoking the compiler?!  So the Unix
+'cat' program is a correct implementation of Ada!?
+
+Half ;-)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, August 28, 2000 6:41 PM
+
+The difference here is that having no main program is not a useful feature
+if you ask me, I have only ever seen it used in ACVC programs. Most
+Ada programmers don't even know it is possible.
+
+Yes, of course in the Annex E situation, there are paritions with no
+main program, but that's a rather different situation.
+
+Allowing a single partition program to have no main program is not
+very useful, so it is quite reasonable for Ada compilers not to pay
+too much attention to making this convenient.
+
+What we do in GNAT is require that such a parition be built with the
+standard no-main program option, then a dummy main program is required
+that looks like
+
+  adainit();
+  adafinal();
+
+:-)
+
+****************************************************************

Questions? Ask the ACAA Technical Agent