Re: Package's private parts and protected types

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

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

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
> news:wccy6j2mpa0.fsf@shell01.TheWorld.com...
>> AdaMagica <christoph.grein@eurocopter.com> writes:
>>
>>> OK, but then you have a similar problem to Ada83's syntactically
>>> unneeded bodies which Ada95 solved with a pragma.
>>
>> I think that problem is an illusion.  There was a problem,
>> but it was a problem with implementations, not with the
>> language.  How do we know if a given package spec has
>> a body?  Simple: look on the disk and see if there's
>> a source file containing that body.  In GNAT, that would
>> mean looking for foo.adb.
>
> I think you're forgetting how this happens in practice. And the actual 
> problem with Ada 83, which was that a unneeded unit with an error had to be 
> ignored when linking.

Well, that's what the Ada 83 RM seemed to require.  I thought so
at the time.  But later I realized that the RM could be interpreted
to mean something different -- after all, it doesn't actually
talk about "linking".

>...(The ACVC used to insist on that.)

Yeah.  The implementers should have fought against that,
rather than damaging their compilers.

Or, they could at least have given warnings, which is good
enough to solve the problem.

Or fix the problem in the "build" command (I mean gnatmake
or whatever).

>... Ada surely needed a 
> fix to that problem, and it wasn't one with the implementations -- at least 
> not until they were changed to match the ACVC. (I remember doing that in 
> Janus/Ada, it was a lot of work and it made things worse for users. 
> Wonderful.)
>
> Moreover, it is easy to imagine errors that would cause the unit to no 
> longer be the body (such as misspelling the name, or misspelling "body"), at 

I see your point about misspelling the name.  But misspelling "body"?
That would just be a syntax error.

> which point the implementation would have to guess. But the problem of a 
> body that the programmer expected to be included being left out would 
> continue.

But the so-called "solution" in Ada 95 didn't actually solve anything.
Early versions of GNAT had the same bug -- they ignored a non-required
body, simply by saying it's not part of the program library.
That was fixed because it's bad behavior, not because it failed
to conform to the Ada 95 rules.

>...So while I don't doubt that implementations could have reduced the 
> problem (in the absense of the ACVC test - the main thing I wanted from Ada 
> 95 was to change the rules enough to repeal that stupid test!), they 
> couldn't have fixed it completely. Surely the same dynamic would occur for a 
> separate private part.
>
> I'm also dubious of the basic idea. I suppose you could keep the private 
> part in a separate file, but I can't imagine any useful way to *compile* it 
> separately (you'd have to have both parts available in order to do any sort 
> of code generation).

I don't think you need to look at the private part to generate code.
If you change it to "to generate efficient code", then I'll agree.

>...So there wouldn't be much, if any, advantage in terms 
> of development.

I disagree -- I think there are big advantages to storing the
private part in a separate file.  I don't much care what files
the compiler wants to look at, so long as it's not too slow.

The private part is part of the implementation.  It's useful
to manage it separately in your CM system (and CM systems
are file based).  Consider, for example, a visible part
that has multiple implementations (maybe target dependent),
selected by the build scripts.  It's really annoying to
have to duplicate the visible part.

>... (For Janus/Ada, at least, every source file is compiled 
> separately, and code is generated as necessary without needing anything 
> other than direct semantic dependencies to have been previously compiled. 
> That model is impossible for separate private parts; the specification would 
> not contain enough information to generate any code or any code for calls to 
> it.)

This seems backwards.  Of course you chose a compilation model
based on the rules of Ada (Ada 83, in fact).  But I'm speculating
about what Ada should have been -- a language very similar
to Ada, but slightly different.  You can't argue against such
a language by saying existing Ada compilers can't handle it.
If Ada had been designed differently, then so would the compilers
have been.

Ada allows recursion.  Therefore, an Ada implementation must
use a stack.  I can't say, "I want to statically allocate
all variables at link-time-known addresses."  Sorry, that's
just a wrong implementation of Ada.  It's not a valid argument
against allowing recursion.

- Bob