Re: Possible Ada deficiency?

[Nick Roberts <nick.roberts@acm.org>]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote:

> Nick Roberts <nick.roberts@acm.org> writes:
> 
> > I've heard the same, and I think it might be correct. There's no real
> > technical barrier to types being completed in the body, other than it
> > might cause some compilers to have to (effectly) make an extra pass.
> > (Correct?)
> 
> I'm not sure what you mean by "extra pass".  The issue is whether the
> compiler looks at the body while compiling clients.

Yes, sorry, that's what I should have said.

> The main thing is that the compiler needs to know the size of a private
> type in order to allocate things, unless it treats all private types as
> dynamic-sized, which would be annoying -- you shouldn't have to pay an
> efficiency cost to get the benefits of encapsulation, information hiding,
> etc.  So if the full type were in the body, the compiler would have to
> look at the body (at least in optimizing mode).

I agree completely.

> And if the compiler looks at the body, then you have to recompile all the
> clients when the body changes (unless you're doing fancy incremental
> compilation -- that's the kind of compiler I'd really like to have!).

I don't think it would have to be that fancy. A simple but effective
strategy would be for the compiler to remember the size of each private type
(completed in the body), and recompile library units dependent on the
specification if any of these types changed size. In addition, it might
recompile library units which use (call or instantiate) an inline subprogram
or generic unit if the body of that subprogram or generic unit got changed.

> Another point is that the rules about whether to pass by copy or by
> reference depend on the full type.  I don't much like that, but anyway,
> the compiler would have to look at the body to find out, unless the
> decision is made at run time, which would be grossly inefficient.

Again, the compiler could simply remember the category of each full type
(elementary, tagged, task or protected, composite with by-reference
subcomponent), and recompile as necessary if it got changed.

> So I guess the Ada 83 designers invented the private part so the compiler
> wouldn't have to look at the body to generate efficient code. But the
> compiler has to look at the body anyway, in order to implement generics
> (unless they are always code-shared) and pragmas Inline. So the decision
> seems somewhat inconsistent to me.

Exactly. I couldn't agree more. And for a compiler that is to perform global
optimisations anyway, almost pointless. Obviously, the practicality of such
compilers was generally less in the early 1980s than it is now.

> If JDI had not invented private parts, so we just had spec and body, and
> all the hidden stuff goes in the body, then when Tucker came along and
> invented child packages, he would have given them visibility into the
> body.  And we'd be having this same discussion about how do you prevent
> evil children from seeing what they shouldn't.  I still think the right
> answer is to restrict which children are allowed, rather than to have yet
> another special visibility rule.

I suppose it is slightly idle speculation (not that I'm averse to idle
speculation ;-) but I think we all have our own ideas about how the perfect
language should have been. (By the way, on a historical note JDI stands for
'Jean Ichbiah', the leader of the team who developed the Ada 83 standard.)

One idea would have been to eliminate the principle of having to declare
things in advance of their use. Ada takes this approach to goto labels, in
fact. When something was used, for example a procedure call:

   Foo(Bar,Hum);

the compiler would simply note the need for an object Bar, and an object
Hum, and a procedure with profile Foo(Bar'Type,Hum'Type).

At the end of the compilation process, the compiler would say "Was there a
declaration of an object Bar?" Assuming there was, its type must now be
known, let's say T1. The compiler would do the same thing with Hum, let's
say its type was T2. Then the compiler would say "Was there a declaration of
a procedure fitting profile Foo(T1,T2)?" If there wasn't, or if there was an
ambiguity, it could report the error.

This way, package specifications wouldn't be needed. You would actually have
a private part in the body, which would contain the declarations of things
not to be exported.

Of course, this approach didn't fit the prevailing compilation model of
those days (the 1980s). Just an idle thought.

-- 
Nick Roberts