CVS difference for ais/ai-00172.txt

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

--- ais/ai-00172.txt	1999/03/22 23:42:40	1.2
+++ ais/ai-00172.txt	2000/08/18 19:44:11	1.3
@@ -1,41 +1,53 @@
-!standard 10.02    (07)                               99-03-21  AI95-00172/02
+!standard 10.02    (07)                               00-08-18  AI95-00172/03
 !class confirmation 96-11-16
 !status work item 97-03-19
 !status received 96-11-16
 !priority High
 !difficulty Easy
-!subject Which units can be designated as a main program?
+!subject Questions about main subprograms
 
-!summary 99-03-21
+!summary
 
-A main subprogam is optional -- the implementation must provide
-a way to create and run an active partition with no main
+A main subprogam is optional -- the implementation may provide
+a way to create and run an active partition without a main
 subprogram.
 
-A main subprogram must be a subprogram -- the implementation
-must report an error if the programmer somehow requests that
-a package or generic declaration be used as the main subprogram.
+An implementation must support a parameterless child procedure as
+the main subprogram. However, how main subprograms are designated is
+implementation-defined; implementations are not required to be able
+to use any view of a parameterless child procedure as a main subprogram.
+In particular, an implementation is not required to support a library unit
+renames of a parameterless procedure as the main subprogram.
 
-An implementation, may, but need not, allow a subprogram declared
-within a package to serve as the main program.
+!question
 
-!question 99-03-21
-
 RM95-10.2(7) states:
 
-"The user can optionally designate (in an implementation-defined
-manner) one subprogram as the main subprogram for the partition.
-A main program if specified, shall be a subprogram."
+  The user can optionally designate (in an implementation-defined
+  manner) one subprogram as the main subprogram for the partition.
+  A main subprogram if specified, shall be a subprogram.
 
      Must there be a main subprogram?  (No.)
+
+     Can a package serve as a main subprogram?  (No.)
+
+RM-10.2(29) states:
+
+   An implementation may restrict the kinds of subprograms it supports as
+   main subprograms.  However, an implementation is required to support all
+   main subprograms that are public parameterless library procedures.
+
+     Must an implementation support a parameterless child procedure as
+     a main subprogram? (Yes.)
 
-     Can a package serve as a main program?  (No.)
+     Must an implementation support a library unit renames of a parameterless
+     procedure as a main subprogram? (No.)
 
-!response 97-03-21
+!response
 
 (See summary.)
 
-!appendix 99-03-21
+!appendix
 
 !section 10.2(07)
 !subject Optional main subprogram?
@@ -224,5 +236,213 @@
 
                                         Robert I. Eachus
 
+****************************************************************
+
+From the minutes of the March 1999 ARG meeting (on draft 2):
+
+The first and last paragraphs of summary will be a surprise to most users.
+The requirement was added to support shared passive partitions and seemed
+harmless to add in the Core.  Randy argues that it is unnecessary work for
+implementors and ACVCs to test for this.
+
+To prevent poor press about this and extra work for implementors and the
+ACVCs, it was decided to change the title and to reduce the summary to the
+first paragraph only, where the "must" is changed to "may".
+
+Editorials: ,program" (in several places) -> ,subprogram".  ,with no" ->
+,without a".
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, August 04, 2000 2:36 PM
+Subject: [Ada-Comment] Main subprograms...
+
+An ACATS test created by Bob Duff contains the following:
+
+procedure C761010_1.Main is
+begin
+    -- Report.Test is called by the elaboration of C761010_1.
+    Result;
+end C761010_1.Main;
+
+with C761010_1.Main;
+procedure C761010 renames C761010_1.Main;
+
+This brings up two questions:
+
+1) Can a main subprogram be a child library unit? Must an implementation
+support a parameterless child procedure as a main subprogram?
+
+2) Can a main subprogram be a library unit renames? Must an implementation
+support a renames of a parameterless procedure as a main subprogram?
+
+(OK, that's four questions!)
+Bob added the renames is to meet the naming conventions of ACATS tests. (A
+test whose objective was to test child unit main procedures could violate
+the naming conventions, but a test with an unrelated objective cannot.)
+
+An implementor objected to the renames, citing AARM 10.2:
+
+29   An implementation may restrict the kinds of subprograms it supports as
+main subprograms.  However, an implementation is required to support all
+main
+subprograms that are public parameterless library procedures.
+
+        29.a   Ramification:  The implementation is required to support main
+        subprograms that are procedures declared by generic_instantiations,
+        as well as those that are children of library units other than
+        Standard.  Generic units are, of course, not allowed to be main
+        subprograms, since they are not subprograms.
+
+        29.b   Note that renamings are irrelevant to this rule.  This rules
+        says which subprograms (not views) have to be supported.  The
+        implementation can choose any way it wants for the user to indicate
+        which subprogram should be the main subprogram.  An implementation
+        might allow any name of any view, including those declared by
+        renamings.  Another implementation might require it to be the
+        original name.  Another implementation still might use the name of
+        the source file or some such thing.
+
+This gives the answers to the questions I posed as:
+
+1) Can a main subprogram be a child library unit? (Yes.) Must an
+implementation support a parameterless child procedure as a main subprogram?
+(Yes.)
+
+2) Can a main subprogram be a library unit renames? (Yes.) Must an
+implementation support a renames of a parameterless procedure as a main
+subprogram? (No.)
+
+However, I don't follow 29.b (apparently, Bob didn't either, at least when
+he wrote the test). It seems to say that a renames is not a subprogram for
+this purpose, which seems odd, to say the least. OTOH, it is clear that
+there is no rule stating how the main subprogram is identified, so I suppose
+the renames could be ignored for that purpose. So perhaps it isn't possible
+to meaningfully answer (2).
+
+---
+
+I would like to add these questions to AI-172 (which is discussing a related
+issue, and has not been finished). We discussed that AI at the March 1999
+ARG meeting, and decided that we didn't want to answer questions that no one
+has asked. Well, now someone has asked them. :-)
+
+If there is an objection to that, I can open a new AI (probably a
+confirmation).
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, August 04, 2000 4:14 PM
+
+<<1) Can a main subprogram be a child library unit? Must an implementation
+support a parameterless child procedure as a main subprogram?
+
+2) Can a main subprogram be a library unit renames? Must an implementation
+support a renames of a parameterless procedure as a main subprogram?
+>>
+
+A straightforward reading of the RM says
+
+1, yes
+
+2. no, what does this mean, the answer is yes if the renames is of a
+library unit main program, i.e. something that could be used as the
+main program, but in this case the implementation can require that
+you designate the original view as the main, since it is ID how
+you specify the main anyway.
+
+You cannot require that a renames of a procedure within a package be
+accepted, when the procedure itself would not be accepted.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, August 04, 2000 7:05 PM
+
+> 2. no, what does this mean, the answer is yes if the renames is of a
+> library unit main program, i.e. something that could be used as the
+> main program, but in this case the implementation can require that
+> you designate the original view as the main, since it is ID how
+> you specify the main anyway.
+
+That was the case I was interested in. Of course, in such a case, the
+renames is at most useless; but it is always legal to provide it.
+
+> You cannot require that a renames of a procedure within a package be
+> accepted, when the procedure itself would not be accepted.
+
+That can't happen anyway: a library unit renames cannot be used to rename a
+non-library unit: see 10.1.1(14).
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Sunday, August 06, 2000 4:38 PM
+
+I agree with Robert's response.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, August 05, 2000 1:36 AM
+
+<<That was the case I was interested in. Of course, in such a case, the
+renames is at most useless; but it is always legal to provide it.
+>>
+
+Yes, it is legal to provide it, but to even imply that an implementation
+should be able to use the name of the renaming unit in its designation
+of the main program is misleading!
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Monday, August 07, 2000 8:16 AM
+
+> However, I don't follow 29.b (apparently, Bob didn't either, at least when
+> he wrote the test). It seems to say that a renames is not a subprogram for
+> this purpose, which seems odd, to say the least. OTOH, it is clear that
+> there is no rule stating how the main subprogram is identified, so I suppose
+> the renames could be ignored for that purpose. So perhaps it isn't possible
+> to meaningfully answer (2).
+
+I agree it's odd.  User's would expect the renaming to be usable, and I
+think it would be friendly to do so.  On the other hand, it's not all
+that important, so I wouldn't blame a compiler-writer for being lazy in
+this case.  I don't remember what our compiler does.
+
+But in any case, as Robert pointed out, according to the RM, the
+renaming does not declare a subprogram, but just a view of a subprogram
+with a new name.  The implementation is free to require that you type
+the original name on the command line (or type it in all caps, or
+backwards, or in Pig Latin, for that matter), because the RM says
+nothing about the command line (or other user interface).
+
+I suggest you change the renaming in that test to be a wrapper
+procedure.
+
+But I also strongly suggest there be at least one test where the main
+procedure is a child.  This is something that is "clearly" required by
+the RM, and some implementations have not supported it.  I discussed
+this with Randy before, and I think he agreed to that, but I don't
+remember for sure.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, August 07, 2000 10:11 AM
+
+<<I agree it's odd.  User's would expect the renaming to be usable, and I
+think it would be friendly to do so.  On the other hand, it's not all
+that important, so I wouldn't blame a compiler-writer for being lazy in
+this case.  I don't remember what our compiler does.
+>>
+
+It is not being lazy to avoid supporting something that is not required
+by the RM in a case like this. Since no useful fucntionality is involved,
+supporting the renaming as main program adds nothing, and may create
+portability problems.
+
 ****************************************************************
-
\ No newline at end of file

Questions? Ask the ACAA Technical Agent