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: stt@henning.camb.inmet.com (Tucker Taft) Subject: Re: Q: access to subprogram Date: 1996/07/11 Message-ID: #1/1 X-Deja-AN: 167781913 sender: news@inmet.camb.inmet.com (USENET news) x-nntp-posting-host: henning.camb.inmet.com references: organization: Intermetrics, Inc. newsgroups: comp.lang.ada Date: 1996-07-11T00:00:00+00:00 List-Id: Jon S Anthony (jsa@organon.com) wrote: : ... What's entertaining is that I : failed to make clear that it wasn't the actual leaving out of the : proposal that was "stupefying" but rather the purported reasons for : doing so. It is generally impossible to fully reconstruct the process by which decisions like this are made. But I will give it a try... We originally proposed a version of access-to-subprograms that would allow for downward closures. These were called "limited access types" because allowing assignment for these types would definitely create the possibility for dangling references. So these kinds of access types would need to disallow assignment, and hence be "limited." At the time of this original proposal (in 1990, I believe), the 9X reviewers were overwhelmed by the number of changes proposed for Ada 9X, and this just seemed like added complexity for less than comensurate gain. This was always the hard question: does the added functionality make up for the added complexity, and is the Ada 9X "complexity" boat reaching the point of sinking completely? We had to make a lot of hard decisions. If you look only at the "margin", taking one decision at a time, you can very frequently convince yourself that just this one more feature would have been a good idea. However, we were defintely struggling with the "overloaded boat" problem. It is also easy to say that you shouldn't worry about compiler implementation, but in fact, many of the problems of Ada 83 (and perhaps Algol 68, and other well-designed languages) were due to the pragmatic realities of getting a sufficient number of high-quality, fully-compliant compilers out the door in a reasonable time-frame. One of our goals was to minimize changes that required modifications to compiler back ends. We achieved this goal to a remarkable extent, in my view. Another sub-goal was to allow existing "C" compiler backends to be used with Ada 95 front ends, without major changes to the backend. Support for downward closures clearly began to run afoul of this goal. Finally, there was already very flexible support for downward closures in the form of generic formal subprograms. Admittedly, generics are more verbose. However, they don't have any of the limitations that would likely be associated with an access-to-subprogram approach. You can pass a predefined operator, an attribute, even an enumeration literal as a subprogram parameter to a generic. Hence, we now have a suggested feature that: 1) Adds semantic complexity (by requiring two kinds of access-to-subprogram types, limited and non-limited); 2) Is largely functionally redundant with an existing feature; 3) May require changes to many backends. Our main "competitors" in the language wars, C, C++, and now Java, have no support for this feature. Is this the feature we should spend our valuable Ada 9X "chips" on? I hope you will at least agree that the answer is not a trivially obvious "yes"... : Jon Anthony : Organon Motives, Inc. : 1 Williston Road, Suite 4 : Belmont, MA 02178 : 617.484.3383 : jsa@organon.com -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Cambridge, MA USA