comp.lang.ada
 help / color / mirror / Atom feed
From: Robert A Duff <bobduff@world.std.com>
Subject: Re: generic package dilemma
Date: 1999/11/29
Date: 1999-11-29T00:00:00+00:00	[thread overview]
Message-ID: <wccvh6l3wva.fsf@world.std.com> (raw)
In-Reply-To: 81cru4$url$1@nnrp1.deja.com

Robert Dewar <robert_dewar@my-deja.com> writes:

> In article <wcczow6flxa.fsf@world.std.com>,
>   Robert A Duff <bobduff@world.std.com> wrote:
> > I've thought about the problem a lot since 1995, and I have
> > yet to come up with an upward compatible solution that is also
> > "good" in all the other respects I'd like.
> 
> What don't you like about the GNAT scheme, it seems to work
> remarkably well in practice. There is of course no fully
> upwards compatible solution (there are halting problem issues),
> but so what?

"So what?" you say?!  The Upward Compatibility Police would have jailed
us, and thrown away the key, if we had proposed the current method GNAT
uses by default, as the Ada 9X standard way!  ;-)

The GNAT-default is pretty good, but it's not upward compatible.  My
statement was that I don't know how to do it "right", and still remain
compatible with Ada 83 -- so the GNAT-default method doesn't contradict
that, even if it were perfect in every other regard.

The GNAT-default method also doesn't meet all of my goals.  One example
is: All elaboration checks should be done at compile time, or at link
time.  No run-time checks.  The GNAT-default method fails to achieve
this for dispatching calls.  Since the compiler cannot usually tell
where a class-wide object came from, and whether a given call might
happen at elaboration time, pretty-much every dispatching call needs a
run-time check.  I think I know how to solve this problem, but not in a
way that is compatible with Ada -- I would need to change the syntax and
semantics too much.

The same issue applies to access-to-subprogram types.

Another goal is portability: I don't like the fact that elaboration
order is nondeterministic.  This offers no benefit to the user, and
causes trouble during porting, when the original programmers have long
since been run over by trucks.  I'm not sure how the GNAT-default method
relates to this -- is it specified to be deterministic?  Certainly it
*could* be -- just look at the code, and write down whatever arbitrary
choices it makes.

----------------------------------------------------------------

By the way, Robert has stated that the GNAT-default method works fine
for all but one of the ACVC tests.  But that's not nearly as impressive
as it might seem.  The vast majority of ACVC tests are very simple with
respect to elaboration.  In particular, they have a single main
procedure (which, like any procedure, doesn't call anything at
elaboration time), plus the Report package, which doesn't do anything
much interesting at elaboration time.  The first call to the Report
package comes after all library units have been elaborated.  (ACVC's
also include predefined stuff like Text_IO, but that's irrelevant here
-- it's the implementer's responsibility to make Text_IO work at
elaboration time, using whatever magic is necessary.)

In fact, the Report package has a design flaw -- it doesn't even work
properly if you call it at elaboration time.

So the ACVC isn't interesting.  What's interesting is real programs with
hundreds (or more) of library packages, all trying to initialize
themselves at elaboration time in the most natural way.

- Bob




  reply	other threads:[~1999-11-29  0:00 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-11-17  0:00 generic package dilemma Riyaz Mansoor
1999-11-17  0:00 ` Matthew Heaney
1999-11-17  0:00   ` Mats Weber
1999-11-17  0:00     ` Matthew Heaney
1999-11-18  0:00       ` Mats Weber
1999-11-18  0:00         ` Matthew Heaney
1999-11-19  0:00           ` Mats Weber
1999-11-19  0:00             ` Matthew Heaney
1999-11-19  0:00               ` Robert Dewar
1999-11-19  0:00                 ` Matthew Heaney
1999-11-20  0:00                   ` Mats Weber
1999-11-19  0:00                 ` Robert I. Eachus
1999-11-22  0:00                   ` Robert Dewar
1999-11-22  0:00                     ` Matthew Heaney
1999-11-19  0:00               ` Mats Weber
1999-11-22  0:00                 ` Robert Dewar
1999-11-22  0:00                   ` Larry Kilgallen
1999-11-23  0:00                     ` Robert Dewar
1999-11-22  0:00                   ` Mats Weber
1999-11-22  0:00                     ` Robert A Duff
1999-11-23  0:00                       ` Robert Dewar
1999-12-01  0:00                       ` Robert I. Eachus
1999-12-01  0:00                         ` Robert I. Eachus
1999-11-22  0:00                   ` Robert A Duff
1999-11-23  0:00                     ` Robert Dewar
1999-11-29  0:00                       ` Robert A Duff [this message]
1999-12-01  0:00                         ` Robert Dewar
1999-12-01  0:00                       ` Robert A Duff
1999-12-02  0:00                         ` Mats Weber
1999-12-03  0:00                           ` Robert Dewar
1999-12-03  0:00                             ` Ted Dennison
1999-12-04  0:00                               ` Robert Dewar
1999-12-03  0:00                             ` Robert A Duff
1999-12-06  0:00                               ` Robert Dewar
1999-11-22  0:00                   ` Mats Weber
1999-11-22  0:00                     ` Bryce Bardin
1999-11-23  0:00                     ` Robert Dewar
1999-11-19  0:00             ` Vladimir Olensky
1999-11-18  0:00       ` Robert A Duff
1999-11-18  0:00         ` Matthew Heaney
1999-11-19  0:00       ` Robert Dewar
1999-11-18  0:00   ` Riyaz Mansoor
1999-11-19  0:00     ` Robert Dewar
1999-11-19  0:00   ` Robert Dewar
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox