Re: Optional body for nested generic

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Simon Wright <simon@pushface.org> writes:

> I was surprised to find that GNAT makes it optional to have a body for a
> nested generic package (in the code below, gpack1 has an empty body,
> gpack2 doesn't have a body at all).
>
> package Pack is
>    pragma Elaborate_Body;
>    generic
>    package Gpack1 is
>       procedure Proc;
>       pragma Import (C, Proc, "proc");
>    end Gpack1;
>    generic
>    package Gpack2 is
>       procedure Proc;
>       pragma Import (C, Proc, "proc");
>    end Gpack2;
> end Pack;
>
> package body Pack is
>    package body Gpack1 is
>    end Gpack1;
> end Pack;
>
> I suppose that the reasoning for disallowing unrequired bodies (roughly,
> making it impossible to obsolete the ada library by adding/removing
> something with no other impact) only applies at library level, where
> there's a correspondence to a file?

Yes, the reasoning only applies at library level.  That was the
thinking during the Ada 9X project.

However, I think the reasoning is bogus in the first place,
although I didn't realize it at the time.

Suppose there were no Elab_Body above.
If a file pack.adb (using the GNAT convention) exists,
then it should be compiled and linked in as part of the program.

If you delete pack.adb, then it should vanish.  The problem was
that Ada 83 compilers didn't do that -- they would link in the
obsolete object code for Pack body.

Likewise, if you created a new pack.adb, they wouldn't notice unless
you explicitly "compiled it into the program library".  Note that very
early versions of GNAT had this same "bug", thus proving that this
is an implementation issue, not a language issue.  (Those early
versions defined pack.adb to NOT exist in the program library unless
pack.ads required it for some reason, completely defeating the purpose.)
Long since fixed!

In a truly source-based program library, these problems just don't
exist.

- Bob