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: hbaker@netcom.com (Henry Baker) Subject: Re: Depending on passing mechanism Date: 1997/10/23 Message-ID: #1/1 X-Deja-AN: 282642201 Sender: hbaker@netcom10.netcom.com References: Organization: nil Newsgroups: comp.lang.ada Date: 1997-10-23T00:00:00+00:00 List-Id: In article , dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > 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. The academics who wrote this into the original specifications for Ada were more interested in doing research in _automatic_ software verification than in actually programming real systems that did real things. Their research failed miserably, but we are left with their misguided attempts to simplify their efforts in Ada. You will notice that in other languages where people actually had to get programs written and systems delivered, this restriction has been dropped, mainly because of my previous posting -- that the language wasn't sophisticated enough to distinguish between 'benign'/'hidden' side-effects and not-so-hidden side-effects. This is an example of a 'fascist' attitude for style over substance that Dilbert gets so much mileage out of. > (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 :-)\ As I have shown through examples before, this is not merely a stylistic issue. If it were, I would be much less adamant. But through the various non-orthogonal interactions of the features of Ada, you actually lose significant expressive power. This is another example of style over substance. > (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. This is a most insidious restriction, because one spends a huge amount of time performing very unnatural acts upon packages to try to get around it. It is a serious flaw, that reduces the amount of intelligence that one can put into buttoned-up, prepackaged, off-the-shelf solutions for others. > (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. You haven't seen 'lambda-lifting', have you. > 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. Ada people didn't listen to their critics in this case. SRI and MIT evaluated Ada and specifically pointed out this lack (in writing) as a serious problem for large scale systems. Without closures -- even downward closures -- you can't do call-backs. (They weren't called call-backs in the mid-1970's, but they were extensively used, non-the-less.)