Re: Possible Ada deficiency?

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

Nick Roberts <nick.roberts@acm.org> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
> > 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.

Well, I don't.  ;-)

I said "at least in optimizing mode", implying that the compiler could
choose a compile-time-efficient method of record layout (not looking at
the body) or a run-time-efficient one (looking at the body), depending
on some optimization switch.  But now that I think about it, that might
not be a good idea.  It might be disconcerting to programmers if record
layout changes depending on compiler switches, especially if those
records are written to files.  Hmm...

> I don't think it would have to be that fancy.

Well, I don't think incremental compilers are trivial.  (I've built
them, but not for Ada.)  But I agree they are feasible and desirable.
The granularity of incrementality need not be very fine in order to get
the benefits.

>... A simple but effective
> strategy would be for the compiler to remember the size of each private type

But it's not just the size of private types and a couple of other
things.  It's any piece of information that affects the generated code.
This depends on how much optimization is done, but it could include all
kinds of things: alignment, whether a type contains tasks, whether a
type has finalization, whether a parameter is small enough to pass in a
register, whether the value of a deferred constant is known at compile
time, and if so, the value, whether various dope (such as array bounds)
is known at compile time, and if so, the values, &c.

And if you forget one such item, you've got a very nasty compiler bug:
rebuilding misses some changes to your code.

The source-based compilation model of GNAT and AdaMagic seems much
simpler, although much less efficient at compile time.

Another problem with moving private-part stuff into the body would be
elaboration order problems.  The freezing rules wouldn't work at all.
(The freezing rules are an abomination, though, and I wouldn't mind a
total redesign of that area.)  But the point is, you need to prevent
things like creating an object of a given type before its full type has
been elaborated.  We do run-time checks for subprograms, which is
somewhat ugly in my opinion; I suppose that could work for private
types, too.

Another issue: I wonder if it would wreak havoc with representation
clauses.

> 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.

I've got lots of ideas.  ;-)

And I think programming language design is in its infancy.
There may never be a "perfect" language, but we can do a lot better
than any existing language.

>... (By the way, on a historical note JDI stands for
> 'Jean Ichbiah', the leader of the team who developed the Ada 83 standard.)

Yes, thank you.  I shouldn't have assumed everybody knows that.
And Tucker was the leader of the Ada 95 design team, of which I
was a member.

> 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.

Nick, I don't know how to say this politely: You're stark raving mad! ;-)

If Foo is overloaded, the above mechanism would be complicated beyond
belief.  And note that Bar could be a parameterless function.

If Ada allowed forward references, a two-pass semantic analysis
algorithm could work reasonably.  But the above-suggested method seems
completely infeasible to me.

Anyway, I think the main reason for disallowing forward references was
to make code more readable, not just to make the compiler's life easier.

Allowing forward references also introduces elaboration-order problems,
and circularity problems.  Probably solvable, but more rules would be
needed.  For example:

    type T1 is range 1..T2'Last; -- currently illegal
    type T2 is range 1..T1'Last;

> 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.

Package specs are not (primarily) for the benefit of the compiler.
They are there to provide a contract -- a definition of the interface
between a package and its clients.  The visible part is a Good Thing.
It's just the private part that seems kludgy.

- Bob