From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,baa6871d466e5af9
X-Google-Attributes: gid103376,public
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: AQ&S Guidance on pragma Elaborate_Body
Date: 1997/04/28
Message-ID: <EACHUS.97Apr28154951@spectre.mitre.org>#1/1
X-Deja-AN: 237972224
References: <528878564wnr@diphi.demon.co.uk>
 <dewar.861642821@merv><E940xu.62B@world.std.com>
 <dewar.861854112@merv><E95IKB.4Gx@world.std.com>
 <dewar.861936524@merv><336089AF.6046@elca-matrix.ch>
 <EACHUS.97Apr25151539@spectre.mitre.org>
 <01bc5260$373835e0$28f982c1@xhv46.dial.pipex.com> <dewar.862079640@merv>
Organization: The Mitre Corp., Bedford, MA.
Newsgroups: comp.lang.ada
Date: 1997-04-28T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <dewar.862079640@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

  > Well of coruse this is true, and is why a purely static solution
  > cannot be 100% accurate. But It is *very* rare, I would say
  > non-existent almost, for anything other than specially constructed
  > tests to run into this, and the limitation in expressive power
  > from forbidding such cycles is negligible.

  I thought that Robert Dewar did provide an example from GNAT where
the pragmas were needed?  In any case, the reality is not that there
are very few programs which can be written so that the pragmas are not
needed, but that the pragmas and the error messages help Ada
programmers find a livable elaboration order, and to live with the
situations where proper execution requires a certain elaboration order.

  I spent most of Friday afternoon doing just that.  Now the real
problem in my case was a place where the Ada rules are slightly too
restrictive.  (And no, I am not suggesting that they be fixed...)  The
problem was that I have a tagged type call it Foo, and an access type
say Bar:

      type Foo is new Foob with private;
      type Bar is access all Foo'Class;

  So far so good, but now I want to instantiate a generic with:

     generic
       type Foobar is abstract new Foob with private;
       type Barf is access all Foobar;
     package Barfoo is ...

    Even though Foobar is not used within package Barfoo, I can't
instantiate the generic for Foo and Bar until after the completion of
the declaration Foo.  (And note that abstract, it is not just that I
don't declare an object of type Foobar, I can't.  But there could be a
(non-abstract) type derived from Foobar so it would take new syntax
for something of very marginal utility.  "type Foobar is abstract
final new Foo with private;" for example.

    As I said, not worth fixing.  But to get my program to compile
cleanly, I had to introduce a new unit with a "programmer knowledge
only" elaboration dependency.  Of course I documented the reason as a
comment on the pragma Elaborate_All.

    And, yes, I have worked with programs where the "right"
elaboration order could only be determined from files read at
execution time.  Of course the programming team knew the right order
and embedded it in Elaborates and project documentation.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...