comp.lang.ada
 help / color / mirror / Atom feed
From: Adam Beneschan <adam@irvine.com>
Subject: Re: Optional body for nested generic
Date: Wed, 21 Sep 2011 08:01:30 -0700 (PDT)
Date: 2011-09-21T08:01:30-07:00	[thread overview]
Message-ID: <8ad3b626-8608-4561-8d8f-bf11e7e8efc0@en1g2000vbb.googlegroups.com> (raw)
In-Reply-To: wcc8vpj8cto.fsf@shell01.TheWorld.com

On Sep 20, 8:15 am, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
>
> 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.

I think there was a problem in Ada 83, because it had more
(apparently) concrete concepts of the program library, compilations,
recompilations, program units becoming obsolete and being removed from
the library.  The Ada 95 Rationale pointed out a real problem: if a
library package specification that does not require a body has a body,
then when the specification is recompiled, the body, according to the
language rules, becomes obsolete and is removed from the library.  If
you forget to submit the body for recompilation, this changes the
meaning of the program if the body contains an initialization part or
declares any tasks.  So in that context, I think the new rule (that a
library package body cannot be present unless it's required) was
needed.

However, Ada 95 also removed a lot of the concepts that had been IMHO
overspecified in Ada 83 (AARM 10.1(4.c): "The interactions between
language issues and environmental issues are left open in Ada 95....
In Ada 83, the concept of the program library, for example, appeared
to be quite concrete, although the rules had no force...").  Now, I
think the basic rule about recompilations and obsolete units and such
is just that the implementation has to get it right.  (E.g. if a
library spec is recompiled, and it has been changed in a way that
makes the body illegal, the body can't become part of the final
program, and a partition can't be created if the body is required; the
notion of an "obsolete" unit isn't necessary at all.)  Because of this
change, the other new rule (that disallowed a body unless required)
probably wasn't necessary.

Still, I'm not unhappy with the rule, since it can prevent accidents.
Suppose, for example, that a specification of P declares some
procedures, and the body contains the code for those procedures.  Then
the user decides he wants the procedures moved somewhere else, so he
eliminates them so that P now declares only types.  It's too easy to
make a mistake that causes P's body to be included in the final
executable anyway.  I think it's beneficial to force the programmer to
take some action (in this case, adding a pragma) if P's body is still
supposed to be included.

                           -- Adam





  reply	other threads:[~2011-09-21 15:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-20 12:48 Optional body for nested generic Simon Wright
2011-09-20 15:00 ` Adam Beneschan
2011-09-20 15:18   ` Simon Wright
2011-09-20 15:15 ` Robert A Duff
2011-09-21 15:01   ` Adam Beneschan [this message]
2011-09-22  3:43     ` Randy Brukardt
2011-09-22 14:28       ` Robert A Duff
2011-09-22 23:03         ` Randy Brukardt
2011-09-23  0:03           ` Adam Beneschan
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox