Re: Optional body for nested generic

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

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Adam Beneschan" <adam@irvine.com> wrote in message 
> news:8ad3b626-8608-4561-8d8f-bf11e7e8efc0@en1g2000vbb.googlegroups.com...
>>On Sep 20, 8:15 am, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
> ...
>>> However, I think the reasoning is bogus in the first place,
>>> although I didn't realize it at the time.
>
> [Lots of discussion of a source-based compiler model.]
>
>>> In a truly source-based program library, these problems just don't
>>> exist.
>
> Sure, but most Ada compilers aren't source-based! Assuming that is 
> essentially the same as saying Ada = GNAT, and not even AdaCore really wants 
> that situation.

OK, but clearly a non-source-based compiler can do the right thing,
too. [1]

>>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.
>
> This was NOT an implementation issue in Ada 83 -- the ACVC *required* the 
> unit be be ignored.

Then I claim the ACVC was broken.  Maybe the RM was broken, too (it was
surely unclear at best), but my claim is that the fix we added in Ada 95
was not necessary.

The attitude in the early days of Ada 83 was too rigid, as if the RM had
been handed down from Mount Sanai.  Nowadays, we're much more willing to
say "the RM requires something idiotic (or is unclear about it);
therefore that's not what it means".

>...Janus/Ada had given an error message in this case, and I 
> had to spend a week or so figuring out how to change our binder so that it 
> could silently (other than a warning) drop the offending unit.

OK, that's proof of my statement [1] above.  You did it right.
You should have disputed the test, because it's truly idiotic
to silently ignore things like that.  (And I claim that the
Ada 83 RM didn't really require the bad behavior -- I rewrote
chapter 10 mainly to CLARIFY that fact, not to change it.)

On the other hand, warnings are just as good as errors, IMHO,
especially if you have a "treat warnings as errors" switch,
as GNAT does.

> And having done so, I was repeatedly bitten by programs that didn't work 
> because some body was no longer elaborating the initialization (especially 
> the Janus/Ada compiler). We eventually abandoned doing almost anything at 
> elaboration time; besides this problem, we also were having a lot of trouble 
> keeping things happening in the "right" order. Unfortunately, elaboration, 
> at least as defined in Ada 83, seemed a lot more useful than it really was.

Elaboration is rather broken in Ada.  The rules should be checked
statically (compile/link time).  And the allowance for different
compilers to choose different orders of elaboration is just Wrong.
AdaCore customers have no end of trouble with that, when porting code.

> The Ada 95 rule would have prevented most of that trouble.

Yes, it's sufficient, but not 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.
>
> Yup. And having the rule gave us a good reason to get rid of the ACVC test 
> that was causing all of the pain in the first place. I'm not sure the 
> relaxation of the rules would have allowed that - it would have allowed 
> automatic recompilation, but I'm not sure it would have allowed an error in 
> that case (and it *should* be an error if it is not automatically 
> recompiled, IMHO).

Agreed.

- Bob