Version 1.4 of ais/ai-00172.txt

Unformatted version of ais/ai-00172.txt version 1.4
Other versions for file ais/ai-00172.txt

!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 Questions about main subprograms
!summary
A main subprogam is optional -- the implementation may provide a way to create and run an active partition without a 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.
!question
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 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.)
Must an implementation support a library unit renames of a parameterless procedure as a main subprogram? (No.)
!response
(See summary.)
!appendix

!section 10.2(07)
!subject Optional main subprogram?
!reference RM95-10.2(7,7.a-d,23,34.e)
!from Laurent Guerby 96-10-30
!keywords main subprogram, partition
!reference 96-5738.a Laurent Guerby  96-10-30>>
!discussion

   RM95-10.2(7) states:

"The user can optionally designate (in an implementation-defined
manner) one subprogram as the main subprogram for the partition. [...]"

   Does it mean that an implementation must provide a way to bind and
link a program without a main subprogram (for example giving a package
or a list of units)?

   Note that there's an ACVC 9XBASIC L test (LA1001F) checking:

-- OBJECTIVE:
--     CHECK THAT A PACKAGE CANNOT BE NAMED AS A MAIN PROGRAM.

   An implementation must provide a script that "compile and bind"
each test, so I'm wondering that if the answer to my question is yes,
this test may be invalid in Ada 95 (or may need some extra precision
about what is actually checked).

--
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

****************************************************************

!section 10.2(07)
!subject Optional main subprogram?
!reference RM95-10.2(7,7.a-d,23,34.e)
!from Laurent Guerby 96-10-30
!keywords main subprogram, partition
!reference 96-5738.a Laurent Guerby  96-10-30
!from Bob Duff
!reference 96-5741.a Robert A Duff  96-10-31>>
!discussion

>    RM95-10.2(7) states:
>
> "The user can optionally designate (in an implementation-defined
> manner) one subprogram as the main subprogram for the partition. [...]"
>
>    Does it mean that an implementation must provide a way to bind and
> link a program without a main subprogram (for example giving a package
> or a list of units)?

Yes.

>    Note that there's an ACVC 9XBASIC L test (LA1001F) checking:
>
> -- OBJECTIVE:
> --     CHECK THAT A PACKAGE CANNOT BE NAMED AS A MAIN PROGRAM.
>
>    An implementation must provide a script that "compile and bind"
> each test, so I'm wondering that if the answer to my question is yes,
> this test may be invalid in Ada 95 (or may need some extra precision
> about what is actually checked).

It is up to the implementation to decide how one specifies what the main
subprogram is, and whether there is one.  Since the usual case is to
have a main subprogram, a -no-main switch might make sense, but the RM
has nothing to say about that.

- Bob

****************************************************************

!section 10.2(07)
!subject Optional main subprogram?
!reference RM95-10.2(7,7.a-d,23,34.e)
!keywords main subprogram, partition
!reference 96-5738.a Laurent Guerby  96-10-30
!reference 96-5741.a Robert A Duff  96-10-31
!from Keith Thompson 96-11-08
!reference 96-5754.a Keith Thompson 96-11-8>>
!discussion

Laurent Guerby wrote:

>    RM95-10.2(7) states:
>
> "The user can optionally designate (in an implementation-defined
> manner) one subprogram as the main subprogram for the partition. [...]"
>
>    Does it mean that an implementation must provide a way to bind and
> link a program without a main subprogram (for example giving a package
> or a list of units)?

Bob Duff replied:

> Yes.

I can understand a partition not having a main subprogram, but what does
it mean for a program (e.g., one consisting of a single partition) not
to have a main subprogram?  I know of no implementations that support
this kind of thing.

****************************************************************

!section 10.2(07)
!subject Optional main subprogram?
!reference RM95-10.2(7,7.a-d,23,34.e)
!keywords main subprogram, partition
!reference 96-5738.a Laurent Guerby  96-10-30
!reference 96-5741.a Robert A Duff  96-10-31
!reference 96-5754.a Keith Thompson 96-11-8
!from Bob Duff
!reference 96-5757.a Robert A Duff  96-11-9>>
!discussion

> I can understand a partition not having a main subprogram, but what does
> it mean for a program (e.g., one consisting of a single partition) not
> to have a main subprogram?  I know of no implementations that support
> this kind of thing.

Well, if an implementation doesn't support main-subprogram-less
programs, then it's not a correct implementation of Ada 95.  RM-10.2(7)
says so, and AARM-10.2(34.e) points out that this is an extension
w.r.t. Ada 83.

The purpose is for certain programs that do all their work in library
packages, and tasks created by library packages.  (And of course, as you
note, it makes sense for shared passive partitions and so forth.)  In
any case, the run-time semantics is described in 10.2(10-17,25).  Note
"if there is one" in 10.2(12).

- Bob

****************************************************************

From: 	Robert Dewar
Sent: 	Monday, March 22, 1999 9:32 AM

it is worth mentioning the child unit case here (main program can be a child
unit).

****************************************************************

From: 	Robert I. Eachus
Sent: 	Monday, March 22, 1999 10:04 AM

   Okay, will do, but I assume that the main program can only be a child of
a library package or an instance of a generic subprogram due to other rules.

                                        Robert I. Eachus

****************************************************************

From: 	Robert A Duff
Sent: 	Monday, March 22, 1999 10:05 AM

Several occurrences of "main program" (the Ada 83 term) should be "main
subprogram", including one inside an RM quote.  (By the way, I suggest
that when quoting from the RM, everybody cut and paste from the on-line
version, to avoid typos.)

> An implementation, may, but need not, allow a subprogram declared
> within a package to serve as the main program.

The original e-mail isn't included in the AI.  Did the questioner ask
about this?  My memory is that the questioner asked *only* about the
optionality.  It's not a good idea to answer questions that weren't
asked, IMHO.  The ARG isn't in the business of publishing random
interesting facts about the RM.

- Bob

****************************************************************

From: 	Robert I. Eachus
Sent: 	Monday, March 22, 1999 1:21 PM

   The original question was about an ACVC test which attempted to create
a executable without a main program.  I added the part about the subprogram
within a package so that the AI didn't create more confusion than it
eliminated, because it does answer the original question as worded. Saying
that as the main program cannot be a package but can be part of one is even
more confusing.

                                        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.

****************************************************************

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