Re: Type declarations in a subprogram

[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)]

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