TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

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

Print Reply
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
From: "W. Wesley Groleau x4923" <[log in to unmask]>
Date: Thu, 10 Dec 1998 12:01:50 -0500
Reply-To: "W. Wesley Groleau x4923" <[log in to unmask]>
Parts/Attachments: text/plain (46 lines)
> nested procedures should sometimes
> be used when they are really macros, ....

By "really macros" do you mean something like the stuff below?

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.

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?)

Web search with the word "nesting" gets mostly hits on ornithology and
genealogy.  :-) (Even if I add "Ada" and "Clarke")

procedure Trip is   -- example

   procedure Leave_For_Grandmas is -- could even be separate...
   begin
      Load_Car;
      Back_Out;
      Drive_North (Blocks => 4);
      Take_Onramp (Interstate => 95,
                   Direction  => North);
   end Leave_For_Grandmas;

   procedure Go_To_Grandmas is-- could even be separate...
   begin
      Over_The_River;
      Through_The_Woods;
      Avoid_Wolf;   -- sorry, couldn't resist
      ....
   end Go_To_Grandmas;

   procedure ... etc.

begin  -- Trip
   Leave_For_Grandmas;
   Go_To_Grandmas;
   Stop_At_Gas_Station_And_Lecture_Kids
   (Topics => (Manners, Fighting, Begging_For_Candy));
   Arrive_At_Grandmas;
end Trip;

ATOM RSS1 RSS2