TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Proportional Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Robert I. Eachus" <[log in to unmask]>
Reply To:
Robert I. Eachus
Date:
Thu, 10 Dec 1998 15:28:43 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (52 lines)
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...

ATOM RSS1 RSS2