Version 1.7 of ais/ai-00048.txt

Unformatted version of ais/ai-00048.txt version 1.7
Other versions for file ais/ai-00048.txt

!standard E.2.3 (07)          00-04-11 AI95-00048/10
!standard E.2.3 (09-14)
!standard E.2.3 (19)
!standard E.2 (04)
!class binding interpretation 95-06-25
!status Corrigendum 2000 99-05-24
!status WG9 approved 96-12-07
!status ARG approved 12-0-0 96-10-07
!status ARG approved (subj. ed. rev., letter ballot was 11-0-1) 96-10-03
!status letter ballot requested 96-06-17
!status work item (letter ballot was 5-4-2) 96-06-05
!status ARG approved (subject to letter ballot) 5-0-5 95-11-01
!status received 95-06-25
!priority High
!difficulty Medium
!qualifier Error
!subject An RCI unit can be a library subprogram
!summary
A shared passive or remote types library unit must be a package or generic package, not a subprogram or generic subprogram. However, a remote call interface library unit may be a package, generic package, subprogram, or generic subprogram.
!question
The rules for pragma Shared_Passive (E.2.1(3)), pragma Remote_Types (E.2.2(3)), and pragma Remote_Call_Interface (E.2.3(3)) seem to allow them to apply to any library unit. However, the definitions in E.2(4) seem to imply that only packages and generic packages are allowed:
4 A library package or generic library package is called a shared passive library unit if a Shared_Passive pragma applies to it. A library package or generic library package is called a remote types library unit if a Remote_Types pragma applies to it. A library package or generic library package is called a remote call interface if a Remote_Call_Interface pragma applies to it. A normal library unit is one to which no categorization pragma applies.
What is the intent? Can a subprogram or generic subprogram be a shared passive or remote types library unit? (No.) Can a subprogram or generic subprogram be a remote call interface library unit? (Yes.)
!recommendation
(See summary.)
!wording
Modify wording as follows (@i<...> marks italics, {...} marks insertions, [...] marks deletions):
E.2.3(7):
A @i<remote call interface (RCI)> is a library unit to which the pragma Remote_Call_Interface applies. A subprogram declared in the visible part of such a library unit{, or by such a library unit,} is called a @i<remote subprogram>.
E.2.3(9 .. 15):
In addition, the following restrictions apply to [the visible part of] an RCI library unit:
o [it] {its visible part} shall not contain the declaration of a
variable;
o [it] {its visible part} shall not contain the declaration of a
limited type;
o [it] {its visible part} shall not contain a nested
generic_declaration;
o it shall not {be, nor shall its visible part} contain{,} the
declaration of a subprogram to which a pragma Inline applies;
o it shall not {be, nor shall its visible part} contain{,} a
subprogram (or access-to-subprogram) declaration whose profile has an access parameter, or a formal parameter of a limited type unless that limited type has user-specified Read and Write attributes;
o any public child of the library unit shall be a remote call
interface library unit.
E.2.3(19):
If a pragma All_Calls_Remote applies to a given RCI library [package] {unit}, then the implementation shall route any call to a subprogram of the RCI [package] {unit} from outside the declarative region of the [package] {unit} through the Partition Communication Subsystem (PCS); see E.5. Calls to such subprograms from within the declarative region of the [package] {unit} are defined to be local and shall not go through the PCS.
!discussion 96-07-23
The wording is ambiguous, and the intent is unclear. Clearly, shared passive subprograms and remote types subprograms make no sense. However, RCI subprograms make sense. We have two choices:
Option 1: A shared passive, remote types, or remote call interface library unit must be a package or generic package, not a subprogram or generic subprogram.
Option 2 (as in the summary above): A shared passive or remote types library unit must be a package or generic package, not a subprogram or generic subprogram. However, a remote call interface library unit may be a package, generic package, subprogram, or generic subprogram. A main subprogram may be an RCI unit.
The argument for Option 1 is that RCI subprograms are not particularly important, the original designers apparently intended to allow only packages, and the wording changes are easier if this choice is chosen.
The argument for Option 2 is that RCI subprograms make sense (given that library subprograms are allowed in the first place), and it would seem like an ugly and arbitrary restriction to disallow them.
We choose Option 2.
Note that, given the above wording changes, 10.2(29) without changes implies that main subprograms that are RCI subprograms must be supported. We see no implementation difficulty in that.
!corrigendum E.02(4)
Replace the paragraph:
A library package or generic library package is called a shared passive library unit if a Shared_Passive pragma applies to it. A library package or generic library package is called a remote types library unit if a Remote_ Types pragma applies to it. A library package or generic library package is called a remote call interface if a Remote_Call_Interface pragma applies to it. A normal library unit is one to which no categorization pragma applies.
by:
A library package or generic library package is called a shared passive library unit if a Shared_Passive pragma applies to it. A library package or generic library package is called a remote types library unit if a Remote_ Types pragma applies to it. A library unit is called a remote call interface if a Remote_Call_Interface pragma applies to it. A normal library unit is one to which no categorization pragma applies.
!corrigendum E.02.03(7)
Replace the paragraph:
A remote call interface (RCI) is a library unit to which the pragma Remote_Call_Interface applies. A subprogram declared in the visible part of such a library unit is called a remote subprogram.
by:
A remote call interface (RCI) is a library unit to which the pragma Remote_Call_Interface applies. A subprogram declared in the visible part of such a library unit, or declared by such a library unit, is called a remote subprogram.
!corrigendum E.02.03(9)
Replace the paragraph:
In addition, the following restrictions apply to the visible part of an RCI library unit:
by:
In addition, the following restrictions apply to an RCI library unit:
!corrigendum E.02.03(10)
Replace the paragraph:
by:
!corrigendum E.02.03(11)
Replace the paragraph:
by:
!corrigendum E.02.03(12)
Replace the paragraph:
by:
!corrigendum E.02.03(13)
Replace the paragraph:
by:
!corrigendum E.02.03(14)
Replace the paragraph:
by:
!corrigendum E.02.03(19)
Replace the paragraph:
If a pragma All_Calls_Remote applies to a given RCI library package, then the implementation shall route any call to a subprogram of the RCI package from outside the declarative region of the package through the Partition Communication Subsystem (PCS); see E.5. Calls to such subprograms from within the declarative region of the package are defined to be local and shall not go through the PCS.
by:
If a pragma All_Calls_Remote applies to a given RCI library unit, then the implementation shall route any call to a subprogram of the RCI unit from outside the declarative region of the unit through the Partition Communication Subsystem (PCS); see E.5. Calls to such subprograms from within the declarative region of the unit are defined to be local and shall not go through the PCS.
!ACATS test
BXE2013 checks that Shared_Passive and Remote_Types units cannot be library subprograms. CXE2002 checks that Remote_Call_Interface units can be library subprograms.
!appendix

!section E.2.3(07)
!subject Can an RCI unit be a library subprogram?
!reference RM95-E.2.3(7);6.0
!from Norman Cohen
!reference as: 95-5134.c Norman H. Cohen 95-5-4>>
!discussion

Is it intended that an RCI unit can only be a package?  I cannot find
any such restriction in the RM.  In particular, given the definition of
the visible part of a callable entity in 8.2(6), a subprogram is
"declared in the visible part of" a library subprogram, thus qualifying
as a remote subprogram according to E.2.3(7).

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

!section E.2.3(07)
!subject Can an RCI unit be a library subprogram?
!reference RM95-E.2.3(7);6.0
!reference 95-5134.c Norman Cohen 95-05-04
!from Tucker Taft 95-05-05
!reference as: 95-5136.c Tucker Taft 95-5-5>>
!discussion

> Is it intended that an RCI unit can only be a package?  I cannot find
> any such restriction in the RM.  In particular, given the definition of
> the visible part of a callable entity in 8.2(6), a subprogram is
> "declared in the visible part of" a library subprogram, thus qualifying
> as a remote subprogram according to E.2.3(7).

Yes, a single library subprogram can be an RCI unit, as can a generic
library unit.

-Tuck

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

!section E.2.3(07)
!subject Can an RCI unit be a library subprogram?
!reference RM95-E.2.3(7);6.0
!from Offer Pazy 95-5-6
!reference 95-5134.c Norman H. Cohen 95-5-4
!reference as: 95-5140.b Offer Pazy 95-5-6>>
!discussion

> Is it intended that an RCI unit can only be a package?  I cannot find
> any such restriction in the RM.  In particular, given the definition of
> the visible part of a callable entity in 8.2(6), a subprogram is
> "declared in the visible part of" a library subprogram, thus qualifying
> as a remote subprogram according to E.2.3(7).
>

First, I don't think that the term RCI unit is defined by the language, I
guess you mean RCI library unit.  E.2 (4) says: "A library generic package
or generic library package is called remote call interface if a Remote_Call_
Interface pragma applies to it." (and similarly for the othere categ
pragmas).  Which means the subp's cannot be RCI's. Note that this is an
unfortunate omittion in this paragraph: For all other categ pragmas, the
text says: "is called a xxxx library unit if the xxx pragma applies to it".
For some reason this is different for RCIs where it says "is called rci
package if the pragma..."  So maybe formally, rci linrray unit is an
undefined term, but I guess the intention is clear.

Offer Pazy
31 Robinwood Ave.
Boston, MA. 02130
USA
(617)522-5988
pazy@world.std.com

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

!section E.2.3(07)
!subject Can an RCI unit be a library subprogram?
!reference RM95-E.2.3(7);6.0
!reference 95-5134.c Norman Cohen 95-05-04
!reference 95-5136.c Tucker Taft 95-5-5
!reference 95-5140.b Offer Pazy 95-5-6
!from ADEPT Team 95-05-17
!reference as: 95-5142.a Anthony Gargaro  95-5-17>>
!discussion

The question is asked in 5134.c:
> Is it intended that an RCI unit can only be a package?  I cannot find
> any such restriction in the RM.  In particular, given the definition of
> the visible part of a callable entity in 8.2(6), a subprogram is
> "declared in the visible part of" a library subprogram, thus qualifying
> as a remote subprogram according to E.2.3(7).

The response in 5136.c:
> Yes, a single library subprogram can be an RCI unit, as can a generic
> library unit.

The response in 5140.b:
> First, I don't think that the term RCI unit is
> defined by the language, I guess you mean RCI library unit.  E.2 (4) says: "A
> library generic package or generic library package is called remote call
> interface if a Remote_Call_ Interface pragma applies to it." (and similarly
> for the othere categ pragmas).  Which means the subp's cannot be RCI's. Note
> that this is an unfortunate omittion in this paragraph: For all other categ
> pragmas, the text says: "is called a xxxx library unit if the xxx pragma
> applies to it".  For some reason this is different for RCIs where it says "is
> called rci package if the pragma..."  So maybe formally, rci linrray unit is
> an undefined term, but I guess the intention is clear.

It appears that Annex E does not provide a definitive answer to the question
of 5134.c. While there is no explicit statement that pragma
Remote_Call_Interface may only be applied to library packages, there are
statements, as indicated by 5140.b, that lead the reader to believe that this
is implied; e.g., E.4(7). Nevertheless, because of the omission of the wording
"library unit" in E.2(4), these statements seem insufficient lacking a
binding interpretation from the ARG.

Consequently, towards achieving a binding interpretation it is perhaps
worthwhile to consider this question in terms of uniformity, functionality,
and implementation issues.

Allowing the pragma to apply to library subprograms raises the uniformity
issue whether or not the two other categorization pragmas may be applied to
library subprograms. Concerns of uniformity may be viewed in several ways. If
categorization pragmas may only be applied to packages, then there is a
non-uniformity introduced with respect to other library unit pragmas. In
contrast, if only Remote_Call_Interface may apply to library subprograms then
there is a non-uniformity issue both with library unit pragmas and
categorization pragmas. Thus, to resolve the uniformity issue it seems that
all three categorization pragmas must be allowed to apply to library
subprograms; however, this would be counterintuitive to what is stated in
E.2.1(1) and E.2.2(1) regarding shared passive and remote types library units.

The increase in functionality provided by allowing the pragma to apply to
library subprograms is small. Enclosing the subprogram within a package has no
discernible difference other than perhaps contravening some preferred
methodological principle. For example, if the notion of starting a partition
through a main subprogram is important then allowing the main subprogram to be
called remotely may be advantageous.

Potential implementation difficulties may arise allowing the pragma to apply
to library subprograms. One difficulty is that the name of the remote call
interface library unit is not necessarily unique (in the presence of
overloaded subprogram names). As a result, the generation of stubs may become
more complicated; e.g., at least one known implementation would be required to
change. In addition, the partitioning tools would need to become sensitive to
subprogram name overloading; simply supporting the assignment of library units
to partitions using the library unit name would no longer suffice.



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

!section E.2.3(07)
!subject Can an RCI unit be a library subprogram?
!reference RM95-E.2.3(7);6.0
!reference 95-5134.c Norman Cohen 95-05-04
!reference 95-5136.c Tucker Taft 95-5-5
!reference 95-5140.b Offer Pazy 95-5-6
!reference 95-5142.a ADEPT Team (Anthony Gargaro) 95-05-17
!from Tucker Taft 95-05-18
!reference as: 95-5143.a Tucker Taft 95-5-18>>
!discussion

> The question is asked in 5134.c:
> > Is it intended that an RCI unit can only be a package?  I cannot find
> > any such restriction in the RM.  In particular, given the definition of
> > the visible part of a callable entity in 8.2(6), a subprogram is
> > "declared in the visible part of" a library subprogram, thus qualifying
> > as a remote subprogram according to E.2.3(7).
>
> The response in 5136.c:
> > Yes, a single library subprogram can be an RCI unit, as can a generic
> > library unit.
>
> The response in 5140.b:
> > First, I don't think that the term RCI unit is
> > defined by the language, I guess you mean RCI library unit.  E.2 (4) says: "A
> > library generic package or generic library package is called remote call
> > interface if a Remote_Call_ Interface pragma applies to it." (and similarly
> > for the othere categ pragmas).  Which means the subp's cannot be RCI's.

> ...
> It appears that Annex E does not provide a definitive answer to the question
> of 5134.c. While there is no explicit statement that pragma
> Remote_Call_Interface may only be applied to library packages, there are
> statements, as indicated by 5140.b, that lead the reader to believe that this
> is implied; e.g., E.4(7). Nevertheless, because of the omission of the wording
> "library unit" in E.2(4), these statements seem insufficient lacking a
> binding interpretation from the ARG.

Although I agree with Anthony's conclusion that RCI subprograms are
more trouble than they are worth, the following point is not
relevant:

> Potential implementation difficulties may arise allowing the pragma to apply
> to library subprograms. One difficulty is that the name of the remote call
> interface library unit is not necessarily unique (in the presence of
> overloaded subprogram names). ...

Library subprograms may not be overloaded.  By contrast, subprograms
nested in an RCI package *may* be overloaded.  So if anything, this
aspect should be simpler for an RCI subprogram.

Be that as it may, RCI subprograms would clearly only be an annoying
curiousity if we allowed them, and they provide no new functionality,
so it seems simplest to use the wording identified by Offer as reason
enough to outlaw them.  By contrast, we have gone out of our way to
make sure that pragma Pure can be applied to library subprograms.
If I remember correctly, Anthony was to first to point out the
original unfortunate limitation to packages only for Pure.
Pragma Pure seems moderately useful on library subprograms, but I would
agree that RCI (or shared passive) is unnecessary overkill for
library subprograms.

-Tuck

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

!section E.2.3(07)
!subject Can an RCI unit be a library subprogram?
!reference RM95-E.2.3(7);6.0
!reference 95-5134.c Norman Cohen 95-05-04
!reference 95-5136.c Tucker Taft 95-5-5
!reference 95-5140.b Offer Pazy 95-5-6
!reference 95-5142.a Anthony Gargaro  95-5-17
!from Offer pazy 95-05-18
!reference as: 95-5144.a Offer Pazy 95-5-18>>
!discussion

I understand that Tucker and I differ in our interpretation of the curernt
wording. Fo robvious reasons, I am wielding on this intetpretation.
However, based on the referenced messages, there is some unclarity in this
area.

I find Anthony arguments quite compeling and I support the idea of *not*
allowing the RCI pragma on lib-unit procedures.  As he said much more
eloquently:

1. It is not clear that allowing it, would significantly add to the
functionality of the feature.

2.  We will have to decide (probably disallow) about the meaning of the SP
and RT pramas for such lib units (I wonder what will they mean if we allow
them).

3. Most importantly: requiring the post-compilation tools to deal with
overloaded subprograms will be, in my opinion, a huge increase of
complexity.  Furthermore, the method used by the compiler to name overloaded
subp's at link time will have to be integrated with these tools.  For
example, unless we require the link name pragma on every such subp, the user
will have to write something like:

assign $My_Proc0002_xyz.32 to partion Par1

which is quite error prone.

4.  Related to #3:  The design and implementation of the RPC receiver will
also suffer as it will now have to deal with those overloaded subp's.  (This
should not be to big a problem, I think, but still an unwelcome complexity.)

Offer

P.S.  There have been several interpretation requests (followed by
discussions) in the past several weeks. Is somebody working on a process to
start address those?

Offer Pazy
31 Robinwood Ave.
Boston, MA. 02130
USA
(617)522-5988
pazy@world.std.com

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

!section E.2.3(07)
!subject Can an RCI unit be a library subprogram?
!reference RM95-E.2.3 (07)
!reference AI95-00048
!from Pascal Leroy 95-10-20
!reference 95-5359.d Pascal Leroy 95-10-20>>
!discussion

A library subprogram should be allowed to be a RCI unit.

I don't find in the discussion of this AI any convincing argument to forbid
library subprograms as RCIs.  I don't think that it presents any
implementation difficulty: if we say that the user can easily enclose the
subprogram in a package, the implementation can equally easily do the
equivalent "behind the scenes."

This is typically one of these restrictions which are supposed to help the
implementers, don't really help them, but may in some circumstances complicate
the programmer's life.  For instance, it makes it annoying to turn a main
subprogram into a RCI unit.  Of course you just have to wrap the subprogram in
a package, but that may be a nuisance from the stanpoint of CM (you now have
two different sources instead of one).

>From the standpoint of uniformity, it seems very artificial to say that a
library subprogram is different from a subprogram declared in a library
package, in that it cannot be called remotely.  (I would hate to have to
explain that when teaching Ada 95.)

Of course, the pragmas SP and RT don't make sense for subprograms.

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

!section E.2.3(07)
!subject Can an RCI unit be a library subprogram?
!reference RM95-E.2.3 (07)
!reference AI95-00048
!reference as: 95-5359.d Pascal Leroy 95-10-20
!from Anthony Gargaro 95-10-22
!reference 95-5362.a Anthony 95-10-22>>
!discussion

> From the standpoint of uniformity, it seems very artificial to say that a
> library subprogram is different from a subprogram declared in a library
> package, in that it cannot be called remotely.  (I would hate to have to
> explain that when teaching Ada 95.)

On the contrary, I believe it is easier to explain  that categorization
pragmas  apply only to library level packages. Furthermore, if the remote call
interface pragma is applied to a library level subprogram, then it would seem a
further issue is raised as to why the All_Calls_Remote pragma cannot be applied
to a library level subprogram.


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

!section E.2.3(07)
!subject Can an RCI unit be a libaray subprogram
!reference AI95-00048
!reference E.2.3(7)
!from Tucker Taft 95-10-30
!reference 95-5373.f Tucker Taft 95-10-30>>
!discussion

I don't care one way or another on this one.  Mostly, I think
it is not worth wasting ARG time on it.

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

!section E.2.3(07)
!subject Can an RCI unit be a library subprogram?
!reference AI95-00048
!from Norman Cohen
!reference 96-5574.a Norman H. Cohen 96-5-24>>
!discussion

I strongly object to the recommendation of AI95-00048/3--that a library
subprogram is not allowed as an RCI unit--and to the reasoning behind
it--"The user can get by without it, so why bother?"  This kind of
reasoning could be applied equally well to allowing library subprograms
as ordinary program units!

It is an ugly nonuniformity without justification.  I saw no convincing
case made of any implementation difficulties.  Anthony mentioned
overloading, but that is not an issue since overloaded library units are
not allowed in the same environment anyway.   What the AI proposes is an
irrational and unexpected exception to the rules, with no real gain.
It's as if the RM had somehow been ambiguous about whether enumeration
types were allowed in a for-loop iteration scheme and the ARG had
responded, "Why make implementers support this?  Programmers can achieve
the same effect with while loops anyway."


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

!section E.2.3(07)
!subject Can an RCI unit be a library subprogram?
!reference AI95-00048
!from Laurent Guerby 96-05-25
!reference 96-5575.a Laurent Guerby  96-5-25>>
!discussion

   As a programmer looking at the annex E, I currently don't see any
useful way of using a library subprogram as an RCI unit. Why? Because
there's no state associated to library subprogram (taken alone, and as
far as I understand it). I can imagine a server with a single entry
point (providing unique ID for example) but without state or user
elaboration code, it's hard to implement. If the subprogram "with" RCI
packages to achieve state and elaboration, is that a good way of doing
such a thing and isn't it better to put the subprogram in the
appropriate RCI package? And if there's no state and elaboration, why
making it RCI instead of Pure (ok, want to "with" a Remote_Types)?
(May be more in the philosophy of Ada to disallow such use.)

   Another point (needing RM lawyers ;-), if RCI library subprograms
are allowed, can such a unit be the main subprogram if a partition ?
May be it's not that simple to define, and then (note that I don't use
"or else" ;-) to implement.

Note: my use of "xx unit" or other terms may be wrong (or looking
suspect), but I hope the idea is right.

--  Laurent Guerby


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

!section E.2.3(07)
!subject Can an RCI unit be a library subprogram?
!reference AI95-00048
!reference 96-5574.a Norman H. Cohen 96-5-24
!from Bob Duff
!reference 96-5576.a Robert A Duff 96-5-25>>
!discussion

> I strongly object to the recommendation of AI95-00048/3--that a library
> subprogram is not allowed as an RCI unit--and to the reasoning behind
> it--"The user can get by without it, so why bother?"

Shrug.  It's hard for me to see how anyone can feel "strongly" either
way on this issue.

>...This kind of
> reasoning could be applied equally well to allowing library subprograms
> as ordinary program units!

As well it should have been.  Library subprograms are a horrible kludge
that have caused no end of trouble.  Unfortunately, Ada 9X was just a
wee bit too late for that -- upward compatibility reared its ugly head.

> It is an ugly nonuniformity without justification.  I saw no convincing
> case made of any implementation difficulties.  Anthony mentioned
> overloading, but that is not an issue since overloaded library units are
> not allowed in the same environment anyway.   What the AI proposes is an
> irrational and unexpected exception to the rules, with no real gain.
> It's as if the RM had somehow been ambiguous about whether enumeration
> types were allowed in a for-loop iteration scheme and the ARG had
> responded, "Why make implementers support this?  Programmers can achieve
> the same effect with while loops anyway."

The above is pretty much correct -- there's no significan implementation
difficulty, and the rule is an ugly nonuniformity (given the existence
of library subprograms in the first place).

The argument that convinced people at the meeting, if I remember, was
just that the current wording of the RM doesn't make sense for library
subprograms.  If we rule the opposite of the current AI, then we have to
worry about all that wording.  For example, E.2.3(7) would *not* define
such a library subprogram to be a remote subprogram, since the
subprogram is not declared "in the visible part of ...".  This wording
would have to be corrected.  Similarly, E.2.3(13,14) would incorrectly
talk about a subprogram contained in the visible part of the subprogram,
which misses the subprogram itself.

If we were still writing the RM, it might make sense to go to the
trouble of fixing all this.  Although, even then, it would complicate
the wording, for the purpose of supporting a feature that people don't
really want to use.

As far as uniformity goes, note that shared passive and remote types
don't make sense for subprograms -- you might as well make the thing
Pure.  Another uniformity issue: You can't declare a private child that
is a library subprogram without a spec.  But you *can* declare a
*public* child that is a library subprogram without a spec.  Again, an
ugly non-uniformity, but it was dropped just to simplify the description
of the language, given that the functionality is not important.

Bottom line: I don't care much one way or the other.  We could waste a
lot of time arguing about it, though, if we're not careful.

- Bob


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

!section E.2.3(07)
!subject Can an RCI unit be a library subprogram?
!reference AI95-00048
!reference 96-5574.a Norman H. Cohen 96-5-24
!reference 96-5576.a Robert A Duff 96-5-25
!reference 96-5575.a Laurent Guerby  96-5-25
!from Norman Cohen
!reference 96-5577.a Norman H. Cohen 96-5-28>>
!discussion

Bob writes:

 > Shrug.  It's hard for me to see how anyone can feel "strongly" either
 > way on this issue.

The inability to have standalone RCI subprograms is no big deal in the
sense that it is easily worked around.  It is a big deal in the sense
that it is an embarassing blemish that makes the language definition
appear arbitrary and inconsistent, like the -1 .. 1  blemish in Ada 83
(which was also easily worked around).

 > >...This kind of
 > > reasoning could be applied equally well to allowing library subprograms
 > > as ordinary program units!
 >
 > As well it should have been.  Library subprograms are a horrible kludge
 > that have caused no end of trouble.  Unfortunately, Ada 9X was just a
 > wee bit too late for that -- upward compatibility reared its ugly head.

I'm sympathetic to this view, but it's irrelevant.  Given that the
decision was made to preserve library subprograms in Ada 95, we should do
so consistently and wholeheartedly.  Had library subprograms been listed
as an obsolescent feature, then it might have been justifiable for new
features not to support them.

 > The above is pretty much correct -- there's no significan implementation
 > difficulty, and the rule is an ugly nonuniformity (given the existence
 > of library subprograms in the first place).
 >
 > The argument that convinced people at the meeting, if I remember, was
 > just that the current wording of the RM doesn't make sense for library
 > subprograms.  If we rule the opposite of the current AI, then we have to
 > worry about all that wording.  For example, E.2.3(7) would *not* define
 > such a library subprogram to be a remote subprogram, since the
 > subprogram is not declared "in the visible part of ...".  This wording
 > would have to be corrected.  Similarly, E.2.3(13,14) would incorrectly
 > talk about a subprogram contained in the visible part of the subprogram,
 > which misses the subprogram itself.
 >
 > If we were still writing the RM, it might make sense to go to the
 > trouble of fixing all this.  Although, even then, it would complicate
 > the wording, for the purpose of supporting a feature that people don't
 > really want to use.

It's a shame: 8.2(6) does define the "visible part" of a callable entity,
but not in quite the right way to suit a pedantic reading of E.2.3.

I don't think "all that wording" is particularly voluminous or
particularly hard to fix.  I also see no basis for your assertion that
people "don't really want to use" this feature.  (One data point:  I
stumbled into the use of this feature in one of the examples in a draft
of Ada as a Second Language because it was the obivous straightforward
approach.  Anthony reviewed the chapter and told me that RCI library
subprograms were disallowed.  After rereading the RM, I was not convinced
that this was the case, so I submitted the comment that spawned AI-48.
I was amused to see different members of the MRT quickly respond with
different answers, and concluded that to be safe, I had better enclose
the RCI subprogram of the example in a package.)

Anyway, unlike those present at the last meeting, I feel it is
worthwhile to "go to the trouble of fixing all this"--indeed, that it is
inexcusable to impose an arbitrary restriction on programmers because we
couldn't be bothered to come up with the right wording for the more
sensible rule--so here's a first attempt ( @i< > marks italics, { } marks
insertions, [ ] marks deletions):

E.2.3(7):

   A @i<remote call interface (RCI)> is a library unit to which the
   pragma Remote_Call_Interface applies.  A subprogram declared in the
   visible part of such a library unit{, or by such a library unit,} is
   called a @i<remote subprogram>.

E.2.3(9 .. 15):

   In addition, the following restrictions apply to [the visible part of]
   an RCI library unit:

      o [it] {its visible part} shall not contain the declaration of a
        variable;

      o [it] {its visible part} shall not contain the declaration of a
        limited type;

      o [it] {its visible part} shall not contain a nested
        generic_declaration;

      o it shall not {be, nor shall its visible part} contain{,} the
        declaration of a subprogram to which a pragma Inline applies;

      o it shall not {be, nor shall its visible part} contain{,} a
        subprogram (or access-to-subprogram) declaration whose profile
        has an access parameter, or a formal parameter of a limited type
        unless that limited type has user-specified Read and Write
        attributes;

      o any public child of the library unit shall be a remote call
        interface library unit.

That's it.  Bullets 4 and 5 are a little awkward, but not more so than
much of the surrounding text, and as a bonus, the nonparallel
construction in Bullet 6 is eliminated.  (In the original wording, the
bulleted list was a list of restrictions on the visible part of an RCI
unit, but Bullet 6 is not really about visble parts.)

Of course there may be other places Bob did not mention that also have to
be fixed.

 > Bottom line: I don't care much one way or the other.  We could waste a
 > lot of time arguing about it, though, if we're not careful.

Right.  We should just adopt my position and be done with it. ;-)

Laurent writes:

 >    As a programmer looking at the annex E, I currently don't see any
 > useful way of using a library subprogram as an RCI unit. Why? Because
 > there's no state associated to library subprogram (taken alone, and as
 > far as I understand it).

It arises naturally as a remote callback.  Suppose I have a short
standalone main subprogram Respond_To_Event that I would like to have
invoked by some server every time that server detects a particular kind
of event.  The remote server has an RCI subprogram

   procedure Register (Event: Event_Type; Handler: Event_Handler_Type);

where Event_Handler_Type is declared in some remote-types package as
follows:

   type Event_Handler_Type is access procedure;

By E.2.2(12), I cannot issue the call

   Register (..., Respond_To_Event'Access);

unless Respond_To_Event is subject to the Remote_Call_Interface pragma.
According to AI95-00048/3, Respond_To_Event cannot be a short standalone
main subprogram after all; I have to enclose it in a package.  That's a
nuisance.


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

!section E.2.3(07)
!subject Can an RCI unit be a library subprogram?
!reference AI95-00048
!reference 96-5574.a Norman H. Cohen 96-5-24
!reference 96-5576.a Robert A Duff 96-5-25
!reference 96-5575.a Laurent Guerby  96-5-25
!reference 96-5577.a Norman H. Cohen 96-5-28
!from Bob Duff
!reference 96-5584.a Robert A Duff 96-5-29>>
!discussion

My main feeling on this issue is that we should make a ruling ASAP, once
and for all, and be done with it.  It is important that all compilers
agree on this point.  It is *not* important which alternative they agree
on.

>  > As well it should have been.  Library subprograms are a horrible kludge
>  > that have caused no end of trouble.  Unfortunately, Ada 9X was just a
>  > wee bit too late for that -- upward compatibility reared its ugly head.
>
> I'm sympathetic to this view, but it's irrelevant.

Agreed -- it's irrelevant.  Sorry, I was just venting my frustration.  ;-)

> I don't think "all that wording" is particularly voluminous or
> particularly hard to fix. ...

I'll let others judge "voluminosity".  I believe Norm's wording
changes are correct.

>...  I also see no basis for your assertion that
> people "don't really want to use" this feature.  (One data point:  I
> stumbled into the use of this feature in one of the examples in a draft
> of Ada as a Second Language because it was the obivous straightforward
> approach.

OK.  (Computer "scientists" are happy to have *one* data point -- we
usually make decisions based on zero data points.  ;-) )

> Of course there may be other places Bob did not mention that also have to
> be fixed.

Two places:

    - E.2.3(19) is worded in terms of "packages".

    - We need to decide whether implementations are required to support
      main subprograms that are remote subprograms.  I believe this was
      pointed out by Laurent Guerby.

No big deal, I admit.  Since Norm has done most of the work, I would be
happy to incorporate his wording, plus corrections to the above two
points, into the AI.  I would also be happy to let the AI stand as is.

>  > Bottom line: I don't care much one way or the other.  We could waste a
>  > lot of time arguing about it, though, if we're not careful.
>
> Right.  We should just adopt my position and be done with it. ;-)

Fine with me.  ;-)

- Bob

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

From: Randy Brukardt
Sent: October 8, 1999

The proposed wording does not address the original problem (that E.2(4) says
"package" instead of "unit".) I've updated the wording to address this.

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

Questions? Ask the ACAA Technical Agent