Re: Possible Ada deficiency?

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

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

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
> news:wccbrbx3qbp.fsf@shell01.TheWorld.com...
> > "Randy Brukardt" <randy@rrsoftware.com> writes:
> ...
> > >... inline is a hint and the
> > > dependencies need not (and should not) be used. Do any inlining/macro
> > > expansion at link-time.
> >
> > I don't see link-time as an improvement.  Whether you do this work at
> > compile time or link time, it still costs in terms of rebuild time.
> > And either way, you have to redo the work when the body changes.
> 
> Sure, but if the extra rebuild time isn't significant, who cares?

It's still significant today.  I won't be completely satisfied until my
rebuild time (after changing one or several files) is less than 0.2
second (because 0.2 second is unnoticeable at the human interaction
level).

I've used incremental Lisp and Smalltalk compilers that achieved such
compile-time efficiency years ago.  It's really nice (although there are
many things I don't like about those languages).

> > >...Certainly I wasn't the only one who thought that was
> > > the intent.
> >
> > But you're the only one who implemented it that way!
> 
> I certainly wasn't the only one to share generics by default.

I have no problem with sharing by default.  But I wonder if Ichbiah's
team had viewed that as the philosophy, why didn't they define the
semantics that way?  (Analogy with procedure calls: the RM does not
define them in terms of copying the called procedure to the call site,
and then expect pragma Not_Inline to turn that off!)

And why did they forbid recursive instantiations?

>... I'm pretty
> sure the old Rational compiler worked the same way. I'm the only one
> bull-headed enough to maintain that approach in the face of Ada 95, though.
> :-)
> 
> > >...Machines of the era weren't really powerful enough to implement
> > > that intent, thus the hacks of the generic dependency and the inline
> > > dependency were allowed.
> > >
> > > Of course, Ada 95 came along and changed that intent.
> >
> > I don't understand that.  Maybe I don't understand what you mean by
> > "that intent".  Which rules of Ada 95 are you talking about, here?
> 
> There are many rules of Ada 95 that make sharing impractical (not
> impossible, just impractical).

I've heard the same comment from some folks at Rational.
It surprised me at the time, because the design team really
tried to make generic body sharing *easier* in Ada 95.  Honest.

One thing that makes sharing hard (in Ada 83) is the semantics of
exceptions declared in generics.  Tucker pushed quite hard to change
that rule, but it was seen as too incompatible, so we gave up on that
idea.

But don't we get a little credit for tightening up the generic contract
model?  ;-)

>... For instance, there was no reason in Ada 83
> to make the size of generic formal types the same as the actual type. (Ada
> 95 requires that because of aliased objects.) Whereas, Ada 83 had just one
> (the previously mentioned parameter passing style), and there never has been
> a test written that could show the difference (such a test would be very
> dubious anyway).
> 
> > >... Which is too bad, as
> > > machines now are powerful enough to implement the Ada 83 intent!
> >
> > I don't understand that, either.  Are you saying that the run-time
> > overhead of the always-share model is now acceptable?
> 
> No, I was thinking of the time/space requirements for building such a
> compiler "properly". We didn't really implement my design because our hosts
> didn't have enough memory to store the intermediate code for the entire
> program, and a disk-based solution would be way too slow. It would be
> practical on modern machines (other than that I can't predict the
> performance of the optimization pass, which would be critical to making the
> scheme work. We'd have to build it to see).
> 
> Note that with the design that I had in mind, the run-time overhead of
> "always share" (as you put it) would be greatly reduced by partial
> evaluation and inlining optimizations -- done at link-time so that all of
> the instantiations and calls are known. Plus, pragma Inline could be used to
> reduce the overhead to nearly nil on critical stuff. The problem isn't the
> run-time overhead so much as it is supporting the optimizations necessary to
> mitigate it.

If you're doing that sort of inlining, I wouldn't call it "always share"
anymore.  I'd call it "sometimes share" or "partial sharing".  The whole
point would be to reduce or eliminate what I called "the run-time
overhead of the always-share model".

- Bob