!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 {shared passive library unit} A library package or generic library package is called a shared passive library unit if a Shared_Passive pragma applies to it. {remote types library unit} A library package or generic library package is called a remote types library unit if a Remote_Types pragma applies to it. {remote call interface} A library package or generic library package is called a remote call interface if a Remote_Call_Interface pragma applies to it. {normal library unit} 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 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. 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) @drepl A library package or generic library package is called a @i library unit if a Shared_Passive pragma applies to it. A library package or generic library package is called a @i library unit if a Remote_ Types pragma applies to it. A library package or generic library package is called a @i if a Remote_Call_Interface pragma applies to it. A @i is one to which no categorization pragma applies. @dby A library package or generic library package is called a @i library unit if a Shared_Passive pragma applies to it. A library package or generic library package is called a @i library unit if a Remote_ Types pragma applies to it. A library unit is called a @i if a Remote_Call_Interface pragma applies to it. A @i is one to which no categorization pragma applies. !corrigendum E.02.03(7) @drepl A @i 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 @i. @dby A @i 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 @i. !corrigendum E.02.03(9) @drepl In addition, the following restrictions apply to the visible part of an RCI library unit: @dby In addition, the following restrictions apply to an RCI library unit: !corrigendum E.02.03(10) @drepl @xbullet @dby @xbullet !corrigendum E.02.03(11) @drepl @xbullet @dby @xbullet !corrigendum E.02.03(12) @drepl @xbullet;> @dby @xbullet;> !corrigendum E.02.03(13) @drepl @xbullet @dby @xbullet !corrigendum E.02.03(14) @drepl @xbullet @dby @xbullet !corrigendum E.02.03(19) @drepl 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. @dby 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 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. 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. ****************************************************************