Re: AQ&S Guidance on pragma Elaborate_Body

[mheaney@ni.net (Matthew Heaney)]

In article <JSA.97Apr24162056@alexandria>, jsa@alexandria (Jon S Anthony) wrote:

>>>A trivial example is two packages, each of whose bodies with's the others
>> >spec, which is not that uncommon.
>> 
>> It may be true that it "is not that uncommon," but mutual dependency of
>> packages indicates that you have a pair of highly cohesive abstractions,
>> and they should really be combined into a single package.
>
>Hmmm, you're probably about the only one left here that believes this.
>The "withing problem" (and this is for SPECS, not just the above sort
>of case) has been discussed here extensively and the general consensus
>is that this inability (to define mutually dependent types across
>package boundaries) is a hole in the language.

You're right, I'm not especially passionate about wanting to define
mutually recursive types across package boundaries.

I think it's a cool idea, though.  One of the tricks C++ programmers do is
to pass a reference to an object as a method parameter.  That way, you
don't have to #include the other class because you know an address is going
to get passed.

Knowing that tagged types are passed by reference, perhaps we could avoid a
spec dependency on the package containing a tagged type's declaration:

with Q.T is tagged limited private;
package P is

   type S is private;

   procedure Op (OS : in out S; OT : in Q.T);  -- OT is passed by reference
...

In this example, spec deferral makes sense.  Sometimes, though, you have
closely-related abstractions - maybe the dependency is in one direction
only, or maybe they're "merely" logically cohesive - and they just sort of
belong together.

Of course, avoiding unnecessary compilation dependencies is A Very Good
Thing, especially in Ada, where value semantics is the norm, and heap
allocation is to be avoided.

So there is a very real tension between the need to minimize compilation
dependencies, and the desire to minimize the "declaration span" between
closely-related types.  Yes, we have to program real systems on real
computers, but it's still humans that have to do it.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271