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/03 Message-ID: #1/1 X-Deja-AN: 163959608 references: <4rb9dp$qe6@news1.delphi.com> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-07-03T00:00:00+00:00 List-Id: Jon asks: "Is there an "elevator version" of why people didn't want this in? Tucker, if you are reading this, what swayed you to not let this in???? It's not one of those things that bothers me all that much (well, it hasn't) but it is indeed curious..." The history is as follows. Ada 83 is carefully designed so that a display model can be efficienctly used for uplevel references (I am talking about a single global display, or more accurately one display per task). The above is fact, and is not open to question or opinion :-) Many people, me included, feel that the display model is more efficient, especially for Ada programs which are often deeply nested and often contain up level references. That however is open to argument (although I think the case for displays is pretty solid). Anyway the correctness of this argument is not relevant to the point at hand. Several implementations (notably Alsys and RR), accepting this argument, use displays for up level references. Once you introduce unrestricted access to procedures, displays are a bit of a menace, and probably this tips the scales in favor of static links (if you believe like me that displays are more efficient, this can also be read as meaning that the introduction of unrestricted access to procedures would introduce distributed inefficiency -- but that still is NOT the reason this feature was excluded). However, there was a real concern that existing implementations not be too badly discombobulated by Ada 95, *especially* in the code generatoin department (remember that a typical vendor like Alsys has one front end and dozens of backends -- not all compilers are like this, GCC has only one back end, but many compilers do have myultiple backends). The discussion centered around this implementation compatibility issue, with several people (me included) arguing that it would be a serious barrier to Ada 95 if existing display implementations had this obstacle thrown up. And that argument carried the day, especially considering that reasonable work arounds could be found in almost all cases of proposed use. Note that this compatibility issue is not just theoretical. The about to be released version of Ada 95 for NT/Win95 from Tompson (using the Intermetrics front end), uses displays for uplevel addressing (a consequence is that it would NOT be easy in this compiler to implement the Unrestricted_Access attribute).