Re: AQ&S Guidance on pragma Elaborate_Body

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <9704301359.AA06917@most> "W. Wesley Groleau (Wes)" <wwgrol@PSESERV3.FW.HAC.COM> writes:

  > The suggestion seemed to be making it less likely to crash a program
  > due to elaboration order problems.  The answer was that it would cause
  > serious incompatibilities in legacy code.

  > Tell me I didn't understand the suggestion, or I didn't understand the
  > answer, or even tell me I'm very confused... but please clarify, because
  > it sure looks like (to me) that this says it's a serious incompatibility
  > for a program to run that could not run before.

   You may not have understood, although the discussion did wander a
little.  The compatibility problem is that if you replace the current
dynamic rule with a static rule, you either remove some dependency
rules or replace them with others.  Then either programs that are now
legal with some elaboration order would have new legal elaboration
orders, or programs which are now legal would be illegal.  In the
first case, if the compiler happened to choose one of these
orders--and remember the original order may now be illegal--then you
have an upward incompatibility.  How serious an incompatibility?
Don't know, it would depend on the rules.  But due to the halting
problem mapping, we know that they would have to be different in some
way.

   In the second case, the problem of undetected errors wouldn't
occur, but you would have existing (and often large) programs that
would not legally link.  How big an issue?  Even one major program
that required a major software redesign would probably be an
unacceptable incompatibility.  And since, as I said, I know of
existing DoD software programs that would almost certainly fall in
this category, this option is unacceptable.

   You may think that programs which read config files during
elaboration and need a specific elaboration order that matches the
content of those files is horrible design.  I agree, but I am talking
reality here, not best practice.  (And in the actual I know of, it is
not as bad as it sounds--a client/server system where the clients
require one elaboration order and the server requires another.  The
clients and the server have different main programs, but you do have
library packages which differ only in the elaboration pragmas.
Clients and server are two different CSCIs.)
--

					Robert I. Eachus

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