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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2907a68906511623 X-Google-Attributes: gid103376,public From: Brian Rogoff Subject: Re: Idea for Ada 200x: Arguments that are procedures Date: 1998/07/03 Message-ID: X-Deja-AN: 368460251 References: <6nh9f0$66i@netline.jpl.nasa.gov> Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: 899489589 13308 bpr 206.184.139.132 Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-07-03T00:00:00+00:00 List-Id: On Fri, 3 Jul 1998, Steve Whalen wrote: > Van, > > I'd vote for "fixing" this deficiency in the Ada200x version of the > language. The way you suggested using "limited" for procedures as > parameters seems like a reasonable syntax to me. > > Compared to GNAT's Unrestricted_Access attribute I would MUCH prefer > your approach because (to me) such attributes are way too powerful > (and implementation dependant). I think you would agree with Robert Duff, who floated the limited access type for procedure parameters a while ago, in http://sw-eng.falls-church.va.us/AdaIC/standards/95lsn/LSN1083.GeneralAccess as I pointed out in my reply to Van Snyder. If you really want to go digging, I've appended a post from Norman Cohen on this topic; you can use the thread title to trace the entire thread under DejaNews. > This is about the only language issue I've seen raised on > comp.lang.ada that actually causes me problems in *my* "real world". > It seems silly to keep requiring workarounds for a deceased > implementation. I think more than one implementation uses displays, and there is also the issue of problems caused in implementations with shared generics. FWIW, I started out with your view (omission of downward closures was an egregious mistake) and ended up agreeing that it was the only right thing to do for Ada *95*. However, I have wanted this in code I write and I think the workarounds are really clumsy and impair readability. I'd rather that generics were never shared, if the interaction of the two features is problematic! I guess the thing to do is to ask your Ada compiler vendor to provide this feature in some form, so that even if we have N variants for N vendors at least the economic argument will be weakened. -- Brian >From ncohen@watson.ibm.com Thu Jul 11 10:13:24 1996 From: ncohen@watson.ibm.com (Norman H. Cohen) Newsgroups: comp.lang.ada Subject: Re: Q: access to subprogram Date: 11 Jul 1996 00:49:51 GMT Organization: IBM T.J. Watson Research Center Distribution: world Reply-To: ncohen@watson.ibm.com NNTP-Posting-Host: rios8.watson.ibm.com In article , rogoff@sccm.Stanford.EDU (Brian Rogoff) writes: |> ncohen@watson.ibm.com (Norman H. Cohen) writes: ... |> Bill Taylor had made what I considered an |> irrefutable case for downward closures, showing how much easier it would |> be to write iterators if downward closures were allowed. It came down to |> a conflict between the interests of Ada programmers and the interests of |> a minority of Ada implementors, and in this case the interests of the few |> implementors using displays prevailed.) |> |> Could you summarize or provide a reference to Bill Taylor's work? Does it |> answer the objection that downward closures impose an inefficiency on programs |> that don't use them? Bill Taylor's contribution was part of an ongoing discussion in the form of comments sent to the Mapping/Revision Team during the design of Ada 9X. All of these comments from June 1992 on are publicly available in the following directory: ftp://sw-eng.falls-church.va.us/public/AdaIC/standards/95com/mrtcomments/ All the comments through April 1994 are in files with names of the form YYMMmrt.zip, where YY and MM are the year and month the comment was received. (Thus all comments from May 1993 are in 9305mrt.zip.) Starting with May 1994, there are individual daily files, such as 94.0501 for all comments received on May 1, 1994. The discussion on downward closures and their impact on display implementations included the following comments: Date Comment ID Author My summary April 29, 1993 93.2622.b Bill Taylor The initial message about iterators mentioned above. May 1, 1993 93-2628.b Robert Duff Says he likes the feature, but Robert Dewar has frightened WG9 members about the cost, and the MRT won't add downward closures until someone convinces WG9 otherwise. Claims the size of a display is not known at compile time. May 3, 1993 93-2634.a Norman Cohen Reply to Duff, asserting that the size of a display IS known at compile time. Foreshadows an identical exchange that will take place on comp.lang.ada in July 1996. :-) May 3, 1993 93-2635.a Robert Duff Reply to Cohen. Size of a display is not known at the site of a call through a pointer. Says he hates arguing against a feature he likes. May 3, 1993 93-2637.a Randy Brukardt Reports that Janus/Ada uses (RR Software) displays. Proposes a workaround involving unchecked conversion. May 3, 1993 93-2638.a Robert Duff Reply to Brukardt, asking him to explain workaround. May 4, 1993 93-2644.a Antoine Bertier Reports that Alsys uses (Alsys) displays for most of its compilers. May 4, 1993 93-2645.a Ted Baker Calls displays an "anachronism", except on register-poor machines. May 4, 1993 93-2646.a Randy Brukardt Reply to Duff, explaining his workaround and conceding that it is not portable to compilers that do NOT use displays. May 5, 1993 93-2647.a Brian Dobbing Also reports that Alsys (Alsys) uses displays, states that Alsys cannot afford any more language changes with such great impact on their compilers, and states that neither the display approach nor the static link approach is always the right choice. May 5, 1993 93-2651.a Bill Taylor Points out that Brukhardt's proposed workaround does not work when the pointed- to procedures reference data in surrounding scopes, as they do in his iterators example. May 5, 1993 93-2655.a Robert Dewar Reply to Baker, defending displays and asserting that they can be quite efficient. May 5, 1993 93-2656.a Robert Eachus Experiments (with a compiler that was altered to send Eachus e-mail every time code was generated for a call on a nested subprogram!) show that calls on nested procedure are rare, so the expense of supporting this feature is not justified. May 6, 1993 93-2661.a Ted Baker Reply to Dewar, claiming that downward closures were important for the kind of applications that justified ANY inclusion of 'Access for nested subprograms in Ada 9X, and worth the cost; but admitting that Brian Dobbing's economic argument might be the deciding consideration. May 11, 1993 93-2676.a Randy Brukardt Reply to Baker. May 11, 1993 93-2676.b Randy Brukardt States that downward closures impose a distributed overhead on all uses of generics when generics are implemented by shared code for all instances, as in Janus/Ada. January 14, 1994 94-3669.a Bjorn Kallberg An eloquent case for the importance of downward closures, pointing out that their omission would create the only case in which Ada is not a functional superset of Pascal. February 15, 1994 LSN 1083 Robert Duff A dispassionate analysis of all sides of the issue, explaining why the MRT decided not to include downward closures in Ada 9X. March 4, 1994 94-3985.a David Tombs An empassioned plea to reconsider this decision. -- Norman H. Cohen ncohen@watson.ibm.com