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,16e3a8dd4f3ab3f3 X-Google-Attributes: gid103376,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: Elaboration order Date: 1996/03/20 Message-ID: #1/1 X-Deja-AN: 143461422 references: <314701A1.469D@lfwc.lockheed.com> <4io8rn$gfn@newsbf02.news.aol.com> <4ipdfj$1fv2@watnews1.watson.ibm.com> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-03-20T00:00:00+00:00 List-Id: Norm says: "In fact, for a library generic unit, Elaborate is always sufficient, since the elaboration of a generic body does not have any semantic effect (other than to mark the generic body as ready for instantiation). In particular, it cannot call a subprogram or instantiate a generic with a still-unelaborated body. There is a small chance that Elaborate_All will introduce too many constraints on the elaboration order, making it impossible to find an acceptable order." Actually we have found that pragma Elaborate_All *often* introduces bogus circularities. Elaborate_All is pessimistic, it assumes that every possible function call that could be made will be made. You are certainly safe if EA works, but it may well be TOO pessimistic. Indeed it was our early experience in GNAT with Elaborate_All that lead to the suggestion to retain Elaborate as a non-obsolescent feature.