From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 17 Jun 93 14:48:53 GMT From: cis.ohio-state.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!howland. reston.ans.net!noc.near.net!inmet!spock!stt@ucbvax.Berkeley.EDU (Tucker Taft) Subject: Re: Type declarations in a subprogram Message-ID: List-Id: In article <1993Jun17.131003@lglsun.epfl.ch> nebbe@lglsun.epfl.ch (Robb Nebbe) writes: > . . . >I was particularly interested in type declarations in procedures >because of some of the restrictions that Ada 9X is placing on tagged >types and access to subprogram types. > >If I'm not mistaken tagged types may not be declared or derived in the >declarative part of a subprogram. As Tucker is fond of saying this is >an engineering decision where the benefits were weighed against the >cost (in terms of implementation difficulty) and a decision made. This is not the actual 9X rule. The rule is that any extension of a tagged type must be at the same "accessibility" level as the parent type. ("Accessibility" level is essentially the lexical nesting level, but ignoring package nesting -- only subprograms and tasks create new levels of accessibility.) Tagged types may be declared in the declarative part of a subprogram, but they are then restricted to that "universe." Similarly, a value of an access-to-subprogram type may only designate subprograms declared at the same accessibility level as its type (or more global than its type). It may not designate subprograms more deeply nested than its type. These accessibility rules are designed to prevent "dangling" references. If one allowed a tagged type to be extended in nested scopes, or if one allowed a value of a global access type to point at a nested subprogram, references to nested scopes might persist past the end of the scope. Note that unlike access-to-subprogram values, generic formal subprograms have no accessibility restrictions, since one can't assign the "value" of a generic formal subprogram to a global variable. In this sense these two capabilities of dealing with subprograms as "parameters" are complementary. Access-to-subprogram values are good for storing references to subprograms in tables or other data structures, while generic formal subprograms allow a generic algorithm to incorporate a call on an arbitrary subprogram provided at instantiation time. In my own personal coding style, I tend to avoid nesting "significant" types and subprograms inside other subprograms, since such nested types and subprograms are inevitably less reusable. The ability to declare types and subprograms in package bodies in Ada satisfies the need for information hiding, while avoiding any run-time overhead associated with nesting. Be that as it may, there are reasons to build entire subsystems nested inside a subprogram, for example, to automatically reclaim all storage associated with the subsystem when the enclosing subprogram is exited. In Ada, this is probably more naturally done by coding the subsystem as a generic, and then instantiating it inside a subprogram. In any case, such "nested subsystems" are well supported in Ada 9X, since the accessibility rules are all based on relative accessiblity level, not on absolute accessibility level. You can take a set of global packages that represent a subsystem, and move them in their entirety into the declarative part of some subprogram and not run into problems with "accessibility" checks. You of course lose some of the nice advantages of separate compilation (though generics can be used to some extent to offset this). > . . . >C just avoids the problem (and any benefits) entirely by not permitting >the programmer to declare a type or functions inside a function. C allows types to be declared inside of functions. It doesn't allow nested functions (though GNU C does). GNU C goes to some trouble to allow pointers to nested functions to work, so long as the enclosing scope remains intact. This is consistent with the C philosophy of giving the programmer plenty of rope. The Ada philosophy is that the language features should be inherently reliable, and only through explicit escape hatches should reliability be compromisable. Ada 9X has retained (and in some cases strengthened) this focus on inherent reliability, while also making sure that the escape hatches (such as Unchecked_Access and Unchecked_Conversion) have well-defined and portable semantics when used appropriately. One inevitable downside of providing inherent reliability is that the language has more compile time restrictions and run time checks. However, if the restrictions are engineered carefully, the typical programmer will only run into a restriction when a check is in fact detecting a likely mistake in the submitted program. Hence the apparent added complexity in the language description mostly concerns the compiler-writer, while providing better compile time error detection for the programmer, and actually simplifying the description of the ultimate run time effect of a piece of code. In other words, the upside of having more consistency checks is that the actual run time effect of a piece of Ada code, presuming it survives the various compile time and run time checks, is well-defined and quite easy for the "reader" of the code to predict. If you look at a section of the Ada reference manual, you should find that it often reads roughly like "check this and this and this at compile-time, check this and this at run-time, and then do the obvious thing." Hence, in Ada the puzzle is more often "is the following legal?" whereas in languages with a more permissive set of compile time and run time rules, the puzzle is more often "what does this do?" In Ada 9X, we have tried to remove certain "arbitrary" Ada 83 restrictions that didn't add to reliability, while choosing a set of restrictions for the new 9X features that ensure that inherent reliability remains the hallmark for Ada. >Robb S. Tucker Taft stt@inmet.com Ada 9X Mapping/Revision Team Intermetrics, Inc. Cambridge, MA 02138