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,99ab4bb580fc34cd X-Google-Attributes: gid103376,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: Q: access to subprogram Date: 1996/07/11 Message-ID: #1/1 X-Deja-AN: 168313137 references: <4rb9dp$qe6@news1.delphi.com> <4rr5tu$sap@watnews1.watson.ibm.com> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-07-11T00:00:00+00:00 List-Id: Jon said "irrelevant nonsense (that would just be plain stupid), I said that most programs don't have much nesting and that without nesting no cost is incurred and therefore any argument about distributed cost in the user model as a reason for not having them was nonsense. And that is still just plain true." Just to be absolutely clear on this, since it seems to have caused a lot of confusion :-) The Steelman (and hence Ada 83) reasoning for not allowing procedure parameters was indeed influenced by concerns about distributed cost of uplevel reference mechanisms (if you read Steelman, you will see that concern expressed in black-and-white). Whether this concern is legitimate or not probably can't be settled without some hard data on existing Ada programs (what you need is dynamic traces that show how many calls are to outer level procedures, and how many calls are to procedures that contain no nested procedures). At least that will allow you to track the cost of display/static-chain handling. If you think uplevel references themselves are a significant factor, as some do in this thread, then you also need dynamic data on the number of such references and how deep they go (by procedure invocation, so that you can factor out optimization effects). As is clear from the thread, Jon and I simply disagree on the bottom line here, but I don't think any more arguments without data can illuminate this discussion further (it is by the way a *very* old discussion). The Ada 95 reasoning for not allowing completely general procedure parameters (that would handle the case where nested procedures are involved in all cases), has NOTHING to do with distributed cost. It had solely to do with concerns about the cost of implementation, and if you want to track Norman's very nice precis of the written discussion on this issue, you will see how the back-and-forth went on this issue. Again, the question of whether the trade-off was made correctly can be discussed. That's more of a subjective issue, but it would be influenced in retrospect by nice examples of things you can't do but would be nice to be able to do, but you can't do in any other convenient way, and one would think that if there are such, some of them might have surfaced by now.