From guerby@titan.enst-bretagne.fr Sat May 25 10:24:16 1996 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA10472; Sat, 25 May 96 10:24:16 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by inmet.camb.inmet.com (4.1/SMI-4.1) id AA13710; Sat, 25 May 96 10:24:30 EDT Received: from audrey.enst-bretagne.fr by sw-eng.falls-church.va.us (8.7.1/) id OAA18642; Sat, 25 May 1996 14:23:23 GMT Received: from titan.enst-bretagne.fr by audrey.enst-bretagne.fr (5.67b8/090294); Sat, 25 May 1996 16:23:35 +0200 Received: from leibniz.enst-bretagne.fr by titan.enst-bretagne.fr (5.x/SMI-SVR4) id AA29294; Sat, 25 May 1996 16:23:33 +0200 Received: by leibniz.enst-bretagne.fr (5.x/SMI-SVR4) id AA07337; Sat, 25 May 1996 16:23:32 +0200 Date: Sat, 25 May 1996 16:23:32 +0200 Message-Id: <9605251423.AA07337@leibniz.enst-bretagne.fr> From: Laurent Guerby To: ada-comment@sw-eng.falls-church.va.us Cc: Laurent.Guerby@enst-bretagne.fr, guerby@gnat.com Subject: User point of view on "Can an RCI unit be a library subprogram?" !topic Can an RCI unit be a library subprogram? !reference AI95-00048 !from Laurent Guerby 96-05-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 From bobduff@world.std.com Sat May 25 19:54:48 1996 Return-Path: Received: from europe.std.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA11378; Sat, 25 May 96 19:54:48 EDT Received: from world.std.com by europe.std.com (8.7.5/BZS-8-1.0) id TAA10356; Sat, 25 May 1996 19:54:47 -0400 (EDT) Received: by world.std.com (5.65c/Spike-2.0) id AA28248; Sat, 25 May 1996 19:54:47 -0400 Date: Sat, 25 May 1996 19:54:47 -0400 From: bobduff@world.std.com (Robert A Duff) Message-Id: <199605252354.AA28248@world.std.com> To: NCOHEN@watson.ibm.com Cc: ada9xmrt@dsd.camb.inmet.com In-Reply-To: <199605241920.PAA44385@mailhub1.watson.ibm.com> (NCOHEN@watson.ibm.com) Subject: Re: Comments on letter ballot !topic Can an RCI unit be a library subprogram? !reference AI95-00048 !reference 96-5574.a Norman H. Cohen 96-5-24 !from Bob Duff <> !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