From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,29fe9a340e0d180d X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Depending on passing mechanism Date: 1997/10/22 Message-ID: #1/1 X-Deja-AN: 282385443 References: X-Complaints-To: usenet@news.nyu.edu X-Trace: news.nyu.edu 877515096 643 (None) 128.122.140.58 Organization: New York University Newsgroups: comp.lang.ada Date: 1997-10-22T00:00:00+00:00 List-Id: Brian Rogoff wrote: > The Ada flaws in Henry Bakers papers that I personally find >just as annoying in (the non-concurrent subset of ) Ada 95 are > > (1) No out mode in functions > (2) No ability to interleave public and private parts in > package specs > (3) No mutually recursion across package specs > (4) No "downward funargs" (fixed in GNAT with Unrestricted_Access > attribute) Interesting list. Let's look at them. (1) No out mode in functions This restriction is there because of a pretty clear consensus that it would be a bad idea to allow out mode in functions. Yes, it is true that Robert Dewar, and Bob Duff, and Brian as well disagree, but we are in a clear minority. Furthermore a significant section of the majority is VERY vocal on this issue. When the Ada 9X requirements were written, we included removing this restriction as an example of a possible restriction to be removed. The only reactions we got at all from the general list on the requirements were several violent reactions against this suggestion. When the matter was discussed several times in WG9, there was always a very strong majority against any change. So you may not like this, but it is pretty clear what people's taste is here. Note that in GNAT, we have implemented the Valued_Procedure pragmas from DEC Ada, which allow you to at least solve the most pressing case of this problem in connection with imported functions that have out parameters (you can even use this with convention Ada, but that would be a bit naughty). (2) No ability to interleave public and private parts in package specs Again, this is a very strong and intentional part of the design, for which there has never been any consensus for change (though certainly implementors would far prefer a style in which individual declarations were marked private :-) (3) No mutually recursion across package specs Extensively discussed. As per these discussions, not such an easy problem to solve, but Tuck's "with type" proposal is interesting. As a point of interest, not one of our customers has even suggested this as a desirable extension to GNAT, let alone suggested that they would be willing to pay for it, so I wonder just how much it affects things in practice. One thing to remember about CLA, is that most Ada programmers do not spend time reading it. The population of CLA is very heavily over- weighted with people who like to play with the language, and debate entertaining uses of abstractions, as opposed to people actually building large applications, who tend to have different concerns. (4) No "downward funargs" (fixed in GNAT with Unrestricted_Access attribute) This was a quite different case. It arose from concern about existing implementations using displays for implementing subprograms. It is quite clear to me that in Ada 83, displays are definitely more efficient than static links. This is because you only pay an overhead for calling a subprogram that *contains* nested subprograms, rather than an overhead for calling a nested subprogram. The former is dyanamically much less common than the latter. Steelman in fact understood the efficiency gain to be obtained here, and one of many reasons for Steelman prohibiting subprogram pointers was to avoid inefficiencies in uplevel reference handling, since Steelman correctly anticipates that nested subprograms would be very common in Ada programs. Since major implementations did in fact use displays, and would have been significantly impacted by a decision that would require a change. In particular, the Alsys implementations (now Object Ada) would have been negatively impacted, and indeed it is interesting to note that there is no simple way for Object Ada to provide the equivalent of GNAT's Unrestricted_Access. Was this the right decision? Hard to say. Certainly GNAT uses static links anyway, since GNU C made this decision (after all C does most certainly have function pointers :-) But Object Ada could well have been significantly affected. Remember that the Ada 9X revision was already large enough to knock one major player out of the ring (as Bevin will tell you, the extent of the Ada 95 changes was a major factor in DEC's decision to withdraw from the Ada implementation arena). As for Bob Duff's concerns about the inherent lack of safety in Unrestricted_Access, I think in practice it is more theory than practice. One tends to use Unrestricted_Access in very stylized manners within abstractions where it is safe. We have not seen one bug in our own code, or in customers code, from the use of this attribute in GNAT. Robert Dewar Ada Core Technologies