separate embedded procedures?

separate embedded procedures?

[Marcel Hawtin]

Please help me out with this, the Ada books I've read say that you can declare
a procedure from a package body as separate and write its body in another file.
Neat idea!  So, can I have a procedure body in a package body that has a couple
of its own nested procedures and declare these procedures separte(ly)?  

I've tried, but my complier complains about it.


To try to make things clearer :


PACKAGE BODY Blah IS

  PROCEDURE Kludged_Mess IS

    PROCEDURE Small_Task IS SEPARATE;

  BEGIN

  <do some stuff using Small_Task>

  END Kludged_Mess;

END Blah;


In another file, the body of Small_Task :


SEPARATE(Blah)
PROCEDURE Small_Task IS

  <whatever>

END Small_Task;


Any help greatly appreciated,

Thanks in advance,

Marcel

replies to : hawtinml@aston.ac.uk

Re: separate embedded procedures?

[Tucker Taft]

Marcel Hawtin (hawtinml@aston.ac.uk) wrote:

: Please help me out with this, the Ada books 
: I've read say that you can declare
: a procedure from a package body as separate 
: and write its body in another file.
: Neat idea!  So, can I have a procedure body 
: in a package body that has a couple
: of its own nested procedures and declare these procedures separte(ly)?  

: I've tried, but my complier complains about it.

The language requires that the unit immediately enclosing
a subunit "stub" must itself be a compilation unit,
either a library unit body, or a subunit.

: To try to make things clearer :


: PACKAGE BODY Blah IS

:   PROCEDURE Kludged_Mess IS

:     PROCEDURE Small_Task IS SEPARATE;

:   BEGIN

:   <do some stuff using Small_Task>

:   END Kludged_Mess;

: END Blah;


: In another file, the body of Small_Task :


: SEPARATE(Blah)
: PROCEDURE Small_Task IS

:   <whatever>

: END Small_Task;

This should work if you first make "Kludged_Mess" into a subunit
as well:

    package body Blah is
       procedure Kludged_Mess is separate;
     ...
    end Blah;

    separate(Blah)
    procedure Kludged_Mess is
       procedure Small_Task is separate;
     ...
    end Kludged_Mess;

    separate(Blah.Kludged_Mess)
    procedure Small_Task is
       ...
    end Small_Task;

: Any help greatly appreciated,

: Thanks in advance,
: Marcel

: replies to : hawtinml@aston.ac.uk

By the way, in large systems I have found subunits
to generally be a pain, as well as nesting of units
inside subprograms.  In Ada 95 you have the alternative
of using child library units for what were subunits
of packages.  Nesting can generally be avoided by
moving the nested unit into the enclosing scope, and giving
it explicit parameters rather than having it rely on
up-level references.  As a side-effect you might discover
you have created a potentially reusable chunk of code.

By constrast, units nested in a subprogram cannot be reused from
outside the subprogram, which is too bad if they do something
useful.

Pascal tends to encourage nesting, but in Ada, I would
recommend avoiding nesting within subprograms.  The most
easily maintainable Ada systems I have worked on consist
of a set of library unit packages, each containing types and 
corresponding operations.  No nesting within subprograms was 
necessary, except occasionally for nested routines that were
so small that they almost qualified as local "macros."

-Tucker Taft  stt@Inmet.com
Intermetrics, Inc.

Re: separate embedded procedures?

[Jerome D. Rosen]

In article <D54r9E.4w4@inmet.camb.inmet.com>,
Tucker Taft <stt@henning.camb.inmet.com> wrote:
>
>By the way, in large systems I have found subunits
>to generally be a pain, as well as nesting of units
>inside subprograms...
>
>-Tucker Taft  stt@Inmet.com
>Intermetrics, Inc.

One exception we've found to Tucker's Rule (subunit = pain)
is that subunits can be useful in isolating compilation
dependencies ("with"-ing) in bodies.  That is, if you're
stuck with referencing a messy (SYSTEM, UNCHECKED_XXX,
MOTIF, X, etc.) or frequently changing (MY_SYSTEMS_
GLOBAL_DECLARATIONS_PKG) package spec somewhere in a body,
you can isolate the code requiring the dependency in a
procedure and then isolate the procedure in a subunit.  
This works best when for whatever reason the code in
question _must_ have visibility to declarations in the
enclosing unit (and thus can't be in a distinct package),
the enclosing unit itself is large, and because of the
aforementioned dependencies, you find yourself recompiling
that large original unit frequently.

JRo (Jerome D. Rosen)
Granite Sentry Program, Colorado Springs, CO