At 12:01 PM 12/10/98 -0500, W. Wesley Groleau x4923 wrote:
>> nested procedures should sometimes
>> be used when they are really macros, ....
>
>By "really macros" do you mean something like the stuff below?

   No, I mean functions which would be implemented as macros in other
languages.
Often in Ada, a renames or constant declaration can replace these, but
there are times when a function declaration is clearer or easier to write:

   procedure Foo(X, Y, Z: Float) is
   ...
     function Bar(W: Float) is
     begin
       if W > Y and W <= Z then return X + W; else return X - W; end if;
     end Bar;
     pragma Inline(Bar);
   begin
     ...
   end Foo;

   Moving something like this to an outer scope requires adding several
parameters and allows errors to creep in.  And in Ada, with most compilers,
there is no penalty for writing it as a function.  In fact, most compilers
can generate better code for this than for a macro.


>I have often made code much more readable by using nested procedures to
>divide something into subtasks.  It is not "factoring common code" since
>each is only called once.  They don't belong at package spec level because
>no one else will (or should) call them.

    I disagree.  Your design may be improved by "nesting" the Trip
procedure in a package and "hiding all the stuff that is specific to Trip
in the private part, in private children, or in the package body.

>Putting them at package body level offers what benefit?  Emulating a
>language that can't nest procedures?  (I'd like to read the paper, but not
>if I have to buy the proceedings.  Is it online?)

     The benefit is to the next guy that has to modify the code.  If the
package is already there, then when something which was only used by a
single subprogram is needed by another, "lifting" the variable is much
easier.

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...